Оптимизация расходов

Совет «выберите модель подешевле» помогает не всегда. Ниже способы оптимизации перечислены по тому, насколько сильно они обычно влияют на счёт.

1. Ограничьте длину ответа

Почти у всех моделей выходные токены стоят в несколько раз дороже входных. Если вы не задали ограничение, длину ответа выбирает сама модель.

{ "model": "claude-sonnet-5", "max_tokens": 800, "messages": [...] }

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

2. Подбирайте модель под каждый шаг

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

def model_for(step):
    if step in ("route", "classify", "extract"):
        return "glm-5.3-flash"
    if step == "draft":
        return "claude-sonnet-5"
    return "claude-fable-5-1"

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

3. Повторно используйте начало запроса для кэширования

Кэшированные входные токены значительно дешевле новых. Стабильный системный промпт и неизменяемое начало документа, помещённые в начало запроса и побайтово совпадающие между вызовами, позволяют использовать кэш.

Кэшированию мешают метки времени, ID запросов и перемешанные списки в начале. Всё, что меняется, помещайте в конец.

4. Учитывайте условия изменения тарифа

Есть два условия повышенной стоимости, которые легко пропустить:

Пиковые часы. Две модели DeepSeek HC (high-cache) удваивают тарифы по будням с 09:00 до 12:00 и с 14:00 до 18:00 по Пекину. Обычные платные модели DeepSeek используют единый тариф круглосуточно. У Hunyuan hy3 своё ежедневное окно. Ночная пакетная обработка дешевле той же обработки во вторник в 10:00.
Длина контекста. У семейств GPT-5.6 и Grok тариф повышается после определённого порога контекста. Длительная сессия агента может пересечь его без уведомления в клиенте.

Точные часы и пороги приведены в примечаниях на странице цен. Применённый тариф указан в данных об использовании для каждого ответа. Чтобы перенести пакетную обработку за пределы пикового окна, достаточно изменить расписание cron.

5. Отправляйте меньше контекста

Контекст оплачивается на каждом ходе диалога, а не один раз. Особенно полезны два приёма:

Сокращайте историю. Если на 40-м ходе отправлять весь разговор, за первый ход вы заплатите сорок раз. Используйте краткое содержание или ограниченное окно истории.
Отправляйте выделение, а не весь файл. Для инструментов программирования это один из самых действенных способов экономии: Cursor и Cline могут отправлять содержимое всего открытого файла.

6. Используйте потоковый ответ, чтобы вовремя остановиться

stream: true не меняет стоимость полностью полученного ответа. Но если ответ пошёл не в ту сторону, его можно прервать после нескольких сотен токенов, не оплачивая весь оставшийся текст. Кроме того, приложение воспринимается как более быстрое, что полезно и без экономии.

7. Сначала измеряйте, потом оптимизируйте

Создайте отдельный API-ключ для каждого приложения, инструмента и окружения. Поле by_api_key в GET /v1/usage покажет расходы без дополнительного учёта с вашей стороны, а by_model поможет найти модель, на которую они приходятся.

curl https://api.beatapi.io/v1/usage \
  -H "Authorization: Bearer $BEATAPI_API_KEY"

Угадать самую дорогую интеграцию трудно. Расширение для перевода с тысячами маленьких вызовов и агент с несколькими огромными запросами создают совершенно разную структуру расходов.

8. Учитывайте возвраты

Средства за неудачные задачи возвращаются. Если ваша система записывает резервирование, но не учитывает возврат, расходы будут завышены и оптимизация опираться на неверные цифры. Поэтому GET /v1/usage отдельно возвращает credits_settled и credits_refunded.

Что не помогает

Слишком частые повторы. Повтор 400 не исправляет неверный запрос и не меняет его цену. Повторяйте только 429 и 5xx; см. руководство разработчика.
Более частый опрос. Проверки статуса не ускоряют выполнение задачи. Соблюдайте poll_after_seconds, а не запрашивайте один и тот же статус непрерывно.
Слабая модель, которой нужны две попытки. Повторное выполнение дешёвой моделью или исправление её результата дорогой может стоить больше, чем одна правильная попытка. Измеряйте стоимость всего процесса, а не только цену одного вызова.