Самая дешёвая модель под конкретную задачу

Название модели ничего не говорит о цене. glm-5.3-flash не обязательно дешевле claude-sonnet-5 для вашей конкретной задачи — зависит от того, сколько токенов уходит на вход и выход, и от текущей цены в каталоге, которая может измениться. Разбираю, как проверять это фактами, а не интуицией.

Смотреть цену в каталоге, а не в памяти

Актуальная цена и лимиты каждой модели — в одном запросе, без ключа:

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-Cost-Micros — точную стоимость именно этого запроса в микродолларах (1 000 000 = $1); у ответов с stream: true этого заголовка нет. Логируйте его на каждый вызов, и через день-два у вас будет честная таблица «модель → задача → средняя стоимость», а не догадка.

Если нужна история за период — /v1/usage отдаёт список списаний по всему аккаунту (все ключи вместе) с курсорной пагинацией:

curl "https://api.zukko.pro/v1/usage?limit=100" \
  -H "Authorization: Bearer fetch_ваш_ключ"

Пройдитесь по курсору и сгруппируйте вручную по модели — так видно, какая модель на самом деле съедает бюджет на конкретном типе задач.

Кэш убирает часть расходов совсем

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

Не путать «дешевле» с «хуже»

Разница между дорогой и дешёвой моделью — прежде всего в цене за токен, а не в базовых возможностях, но две вещи стоит сверить: у Claude и GPT контекст 1 000 000 токенов и есть vision, а у glm-5.3 и glm-5.3-flash — 128K и без vision. Если задача текстовая и укладывается в 128K — например, «вытащить дату из текста» или «проверить, что ответ клиента — жалоба, а не вопрос», — смело пробуйте модели с «flash»-подобными именами в линейке — вроде glm-5.3-flash ($0.04 за 1M токенов входа и выхода) — и сравнивайте по своим данным.

Ограничить траты на тестах ключом

Прежде чем гонять сравнение на десяти моделях, поставьте дневной лимит на тестовый API-ключ в кабинете, на странице ключа. Так эксперимент с «какая модель дешевле» не превратится в неожиданный счёт: даже если один из кандидатов окажется неожиданно прожорливым, лимит остановит расход раньше, чем вы заметите проблему сами.

Идемпотентность при повторных прогонах

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

Разделять задачу на этапы вместо одной модели на всё

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

Запретить дорогие модели на ключе явно

Если сервис по задумке должен работать только с дешёвыми моделями, не полагайтесь на то, что код случайно не позовёт что-то другое — задайте список разрешённых моделей прямо на ключе в кабинете. Тогда попытка вызвать модель не из списка вернёт 403 model_not_allowed_for_key ещё до того, как запрос дойдёт до биллинга, а не тихо спишет деньги за случайно захардкоженный дорогой идентификатор в отладочной ветке кода.

Итоговый порядок действий

Смотрите цену в /v1/models/info, считаете токены через /v1/messages/count_tokens, замеряете фактический расход по X-Zukko-Cost-Micros и /v1/usage, включаете кэш там, где вход повторяется, и ограничиваете тестовый ключ лимитом. Это займёт минут двадцать и даст точный ответ для конкретной задачи, вместо общего совета «берите модель подешевле».