Как на практике снизить расход токенов

Расход токенов редко снижается одним приёмом. Обычно это набор мелких решений — какую модель выбрать, что не отправлять в контексте, где использовать кэш, — которые вместе дают заметную разницу в конце месяца. Ниже — то, что реально работает и опирается на функции, которые есть в шлюзе.

Выбирайте модель под задачу, а не по умолчанию

Сейчас в каталоге шесть моделей разной цены (за 1M токенов, вход/выход): claude-opus-5-5, claude-sonnet-5 и gpt-5.6-sol — $0.30/$0.30, gpt-5.6-luna и glm-5.3 — $0.10/$0.10, glm-5.3-flash — $0.04/$0.04; дешёвые модели логично пробовать для простых и частых вызовов вроде классификации или коротких переформулировок — какая справится с вашей задачей, проверьте на своих задачах. Держать самую дорогую модель на рутинных операциях, которые этого не требуют, — самый прямой способ переплачивать. Актуальный список моделей — GET https://api.zukko.pro/v1/models, цены и лимиты:

curl https://api.zukko.pro/v1/models/info

Считайте токены до отправки, а не после счёта

Метод /v1/messages/count_tokens бесплатный и не выполняет сам запрос — только считает:

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

Если промпт собирается программно из шаблонов и вложений, полезно проверять его размер на этом шаге, а не после того, как счёт за месяц уже вырос.

Используйте кэш для повторяющихся запросов

Если часть запросов у вас типовая — одинаковые классификации, шаблонные проверки, повторяющиеся вопросы к одному и тому же контенту — включайте кэш явно заголовком X-Zukko-Cache: true (temperature: 0 тоже включает кэш, но только у моделей, которые его принимают, — модели Claude могут отклонить temperature, отличный от 1). Повтор полностью идентичного запроса (совпадает всё тело) от того же пользователя в течение 7 суток (для чата) вернётся мгновенно и бесплатно, с пометкой X-Zukko-Cache: hit в ответе. Это особенно полезно для пайплайнов, где одни и те же данные проверяются несколько раз за день.

Не раздувайте контекст без необходимости

Это самая частая причина неожиданно высокого счёта у агентов. Несколько конкретных правил:

• не передавайте файл целиком, если нужен один фрагмент — читайте и вставляйте только релевантную часть;
• обрезайте историю диалога до нужного минимума на каждом шаге, а не пересылайте её всю по инерции;
• не дублируйте одну и ту же информацию в системном промпте и в сообщении пользователя.

Каждая лишняя тысяча токенов в системном промпте умножается на число шагов агента — это компонент расхода, который проще всего проглядеть, потому что он «фоновый» и не выглядит как большая переменная часть.

Не завышайте max_tokens про запас

max_tokens — это потолок генерации, а не гарантированная длина ответа, но некоторые модели склонны его заполнять, особенно если формулировка задачи допускает многословный ответ. Если ответ по факту должен быть коротким — классификация, да/нет, короткий JSON, — ставьте реалистичный лимит, а не крупное число «на всякий случай».

Настройте лимиты на ключ, а не полагайтесь на дисциплину

Для каждого API-ключа в кабинете на странице ключа можно задать дневной и месячный лимит расхода в долларах и список разрешённых моделей. Это не столько про экономию в моменте, сколько про защиту от сценария, где сорвавшийся агент или баг в ретраях тихо съедает баланс за ночь. Отдельный ключ с жёстким лимитом на эксперименты и черновые прогоны — дешевле, чем разбираться с последствиями постфактум.

Используйте идемпотентность при ретраях

Если ваш код или библиотека повторяет запрос при сетевой ошибке, добавляйте заголовок Idempotency-Key с одним и тем же значением на попытку одного и того же логического действия — уникальным для каждого логического запроса и заданным в конкретном вызове, а не в заголовках клиента по умолчанию (иначе следующий запрос получит 422 idempotency_conflict). Повтор с тем же ключом в течение 24 часов вернёт сохранённый ответ без повторного списания — без этого заголовка каждый ретай после реально прошедшего, но не полученного клиентом ответа, будет отдельным платным запросом.

Смотрите за расходом по факту, а не по прикидке

Каждый обычный (не потоковый) ответ несёт заголовок X-Zukko-Cost-Micros — стоимость именно этого запроса в микродолларах, и X-Fetch-Balance-Cents — остаток после списания (несмотря на название, тоже в микродолларах: 1 000 000 = $1; точный баланс в центах — GET /v1/balance, поле balance_cents). У потоковых ответов (stream: true) этих заголовков нет. Логирование этих двух полей в свою систему мониторинга даёт точную картину без дополнительных вызовов API. Для сводной картины за период есть /v1/usage с курсорной пагинацией — удобно строить отчёт по дням; история там общая на весь аккаунт, фильтра по ключу нет, поэтому разбивку по проектам делайте по своим логам X-Zukko-Cost-Micros (для нестриминговых запросов).

Пересматривайте системные промпты время от времени

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

Итог

Ни один из этих приёмов не даёт кратного снижения расхода в одиночку. Модель под задачу экономит на объёме вызовов, кэш — на повторах, аккуратный контекст — на размере каждого запроса, лимиты ключа — на рисках, идемпотентность — на ретраях. Вместе они складываются в разницу, которая на реальной нагрузке заметна уже за первую неделю.