Конспект встреч и звонков через API

Транскрипцию звонка сегодня получить не проблема — это делает почти любой инструмент видеоконференций или отдельный сервис speech-to-text. Проблема начинается на следующем шаге: как из сырого текста на 40 минут получить структурированный конспект с решениями и задачами, и чтобы это не стоило неадекватных денег на длинных встречах.

Какой запрос и какая модель

Готовую транскрипцию отправляем текстом в /v1/chat/completions (если инфраструктура уже завязана на OpenAI-формат) или в /v1/messages (если удобнее Anthropic-стиль). Для часовой встречи транскрипция — это обычно 8-15 тысяч слов, то есть 12-20 тысяч токенов, что укладывается в контекст любой модели из линейки с запасом в разы: у Claude и GPT контекст 1,000,000 токенов, у GLM — 128K, так что даже трёхчасовой воркшоп с несколькими спикерами проходит одним запросом без нарезки на части.

curl https://api.zukko.pro/v1/chat/completions \
  -H "Authorization: Bearer fetch_ваш_ключ" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6-sol",
    "messages": [
      {"role": "system", "content": "Сделай конспект встречи: раздел Решения, раздел Задачи с ответственными, раздел Открытые вопросы. Не пересказывай реплики дословно."},
      {"role": "user", "content": "'"$(cat transcript.txt | jq -Rs .)"'"}
    ]
  }'

gpt-5.6-sol здесь — просто пример: в Zukko он стоит столько же, сколько claude-opus-5-5 ($0.30/$0.30 за 1M токенов входа/выхода). Если для конспектов важнее цена на объём, проверьте на своих записях gpt-5.6-luna или glm-5.3 (обе — $0.10/$0.10).

Структурированный вывод вместо простыни текста

Конспект без разбивки на секции бесполезен: его никто не читает целиком. Хороший способ получить машиночитаемый результат — попросить модель вернуть JSON и дальше рендерить его в шаблон (например, карточку в Notion или сообщение в Telegram):

import requests, json

resp = requests.post(
    "https://api.zukko.pro/v1/chat/completions",
    headers={"Authorization": "Bearer fetch_ваш_ключ"},
    json={
        "model": "gpt-5.6-sol",
        "messages": [
            {"role": "system", "content": (
                "Верни строго JSON вида "
                '{"decisions": [...], "tasks": [{"who": "", "what": ""}], "open_questions": [...]}. '
                "Без пояснений вокруг JSON."
            )},
            {"role": "user", "content": open("transcript.txt").read()},
        ],
    },
)
summary = json.loads(resp.json()["choices"][0]["message"]["content"])

Идемпотентность там, где транскрипция приходит вебхуком

Если конспект запускается по вебхуку от сервиса видеоконференций (например, по событию «запись завершена»), вебхуки нередко доставляются повторно при таймауте на стороне получателя. Без защиты один и тот же звонок будет законспектирован и оплачен дважды. Решение — Idempotency-Key на основе ID встречи:

curl https://api.zukko.pro/v1/chat/completions \
  -H "Authorization: Bearer fetch_ваш_ключ" \
  -H "Idempotency-Key: meeting-$MEETING_ID" \
  -H "Content-Type: application/json" \
  -d @payload.json

Повторная доставка вебхука с тем же телом за 24 часа вернёт готовый ответ без нового списания — это ровно тот сценарий, для которого заголовок и придуман.

Длинные многочасовые записи и цена

Для регулярных многочасовых воркшопов имеет смысл прикинуть стоимость заранее через бесплатный подсчёт токенов, если используется Anthropic-режим:

curl https://api.zukko.pro/v1/messages/count_tokens \
  -H "Authorization: Bearer fetch_ваш_ключ" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"model": "claude-sonnet-5", "messages": [{"role": "user", "content": "..."}]}'

Если счёт идёт на сотни встреч в месяц (например, у call-центра или отдела продаж), заметная экономия — включить кэш ответов на повторные операции: если один и тот же транскрипт конспектируется дважды полностью одинаковым запросом (например, ретрай пайплайна из-за таймаута на стороне клиента), запрос с заголовком X-Zukko-Cache: true (temperature: 0 тоже включает кэш, но только у моделей, которые принимают этот параметр; Claude-модели — claude-sonnet-5, claude-opus-5-5 — могут отклонить temperature, отличную от 1, с ошибкой 400, поэтому им его не передавайте) вернёт закэшированный ответ бесплатно и мгновенно, с пометкой X-Zukko-Cache: hit в ответе; кэш срабатывает только при полном совпадении тела запроса, а такие попадания не пишутся в /v1/usage. Для чата кэш живёт до 7 суток — этого достаточно, чтобы покрыть типичные повторные запуски пайплайна в течение дня.

Контроль бюджета на отдел

Если конспекты встреч запускает несколько команд (продажи, поддержка, разработка), логично выдать каждой отдельный ключ с собственным месячным лимитом в кабинете (https://zukko.pro/app/api-keys). Это защита от перерасхода. А вот разделить траты по отделам через GET /v1/usage не получится: история там общая на весь аккаунт (все ключи вместе), фильтра по ключу нет, и баланс тоже один на аккаунт:

curl https://api.zukko.pro/v1/usage \
  -H "Authorization: Bearer fetch_ключ_отдела_продаж"

Эндпоинт отдаёт историю списаний аккаунта с курсорной пагинацией (поля created_at, model, input_tokens, output_tokens, total_tokens, cost_cents, next_cursor). Чтобы разделить расход по отделам, логируйте у себя X-Zukko-Cost-Micros из каждого нестримингового ответа вместе с именем ключа — или заведите отдельный аккаунт на отдел.

Ошибки, характерные для этого сценария

429 key_daily_limit_reached — вероятнее всего означает, что кто-то поставил конспектирование не только финальной записи, но и каждого промежуточного чанка стрима. 402 с сообщением о недостаточном балансе означает, что запрос до модели не дошёл вообще — конспект просто не будет создан, и это стоит обрабатывать в пайплайне явным уведомлением ответственному, а не тихим падением джобы. Если ответ обрывается на середине конспекта — почти всегда дело в max_tokens, а не в лимите по токенам аккаунта: для длинной встречи с подробным списком задач стоит заранее выставлять max_tokens с запасом, например 4000, а не оставлять значение по умолчанию.

Итог: одна модель, подобранная по цене и качеству на своих записях, JSON на выходе, идемпотентность на ID встречи и отдельные ключи по командам с лимитами (плюс свой учёт расходов по ключам) — с этим набором конспекты встреч работают на потоке без сюрпризов в счёте и без дублей в базе.