Как сократить расходы на Claude API: практическое руководство по стоимости токенов

Как понимать бюджет токенов

Стоимость каждого запроса определяется двумя факторами:

• Число входных токенов: системный промпт, сообщение пользователя, история разговора, определения инструментов, найденные документы и любой кешированный префикс, который по-прежнему учитывается, если не взят из кеша.
• Выходные токены: ответ модели, включая непреднамеренную многословность и повторные попытки.

Полезная формула для понимания:

request_cost ≈ input_tokens × input_rate + output_tokens × output_rate

Это звучит очевидно, но меняет подход к анализу расходов. Если средний запрос «дешёвый» по объёму вывода, но дорогой по объёму ввода, то сокращение системного промпта на 400 токенов может быть важнее, чем просьба к модели отвечать кратко.

Начните с выбора модели

Не каждой задаче нужна самая мощная модель. В реальных системах выбор модели часто оказывается самым недорогим способом оптимизации.

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

• Haiku для быстрой классификации, извлечения JSON, разметки журналов и первичного разбора.
• Sonnet для большинства задач с агентами или инструментами разработчика.
• Opus только когда задаче действительно нужны более сильные рассуждения, тонкое обобщение или когда вы оценили стоимость ошибок.

Хорошо работает простое правило:

1. Пробуйте Haiku для недорогих структурированных задач.
2. Переходите на Sonnet, если уверенность низкая или ответ имеет неверный формат.
3. Переходите на Opus только для действительно сложных случаев.

Такая цепочка переходов обычно дешевле, чем оплата каждого запроса по тарифам Opus.

Безжалостно сокращайте системный промпт

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

Что удалить

• Дублирующиеся инструкции, выполнение которых уже обеспечивает приложение.
• Длинные призывы «быть полезным», которые не меняют поведение.
• Старые примеры для пограничных случаев, которые больше не актуальны.
• Текст правил, повторяющийся в каждом запросе.
• Многословные описания инструментов, когда достаточно компактной схемы.

Что сохранить

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

На практике я видел, как команды убирали сотни или тысячи токенов из повторяющегося префикса без изменения качества работы модели. Секрет в том, чтобы относиться к системному промпту как к коду в продакшене: удалять неиспользуемый текст, устранять дубли правил и оставлять только то, что влияет на поведение.

Лучше задавать структуру вместо описания обычным текстом:

{
  "style": "concise",
  "output": "json",
  "must_include": ["root_cause", "next_steps"],
  "must_avoid": ["speculation", "apologies"]
}

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

Используйте кеширование промптов для стабильных префиксов

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

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

Что хорошо подходит для кеширования

• Системные промпты, общие для всего продукта
• Большие определения функций и инструментов
• Повторно используемые инструкции по поиску информации
• Статичные примеры форматирования или стиля
• Базовая структура агента, которая редко меняется

Что плохо подходит для кеширования

• Пользовательский контекст отдельного запроса
• Новые найденные документы
• Быстро меняющиеся инструкции
• Содержимое рабочих заметок конкретной сессии

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

Пример структуры запроса:

{
  "system": "Stable application prompt + tool definitions + output contract",
  "messages": [
    { "role": "user", "content": "New ticket text here" }
  ]
}

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

Задайте max_tokens Со всей серьёзностью

Один из самых незаметных источников лишних расходов — слишком высокий лимит генерации. Если вы задаёте max_tokens огромное значение «на всякий случай», вы создаёте условия для длинных ответов, особенно когда модель не уверена или многословна.

Используйте минимальный лимит, которого всё ещё достаточно для задачи.

Практические диапазоны

• Извлечение / классификация: 32–128 токенов
• Краткие сводки: 128–256 токенов
• Изменения кода / объяснения: 256–800 токенов
• Генерация без заданного объёма: не больше, чем необходимо

Если задача — «вернуть один объект JSON», задайте жёсткий верхний предел. Если задача — «объяснить эту архитектуру», не оставляйте модели возможности написать роман, если только он вам не нужен.

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

Объединяйте небольшие задачи в пакеты

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

Вместо этого:

• 50 отдельных запросов на классификацию
• 50 повторяющихся системных промптов
• 50 повторяющихся определений инструментов

Сделайте так:

• Один запрос, содержащий 50 элементов
• Один общий блок инструкций
• Одна компактная схема вывода

Пример шаблона промпта:

Classify each item into one of: bug, feature, question, billing.

Items:
1. "App crashes after login"
2. "Can you add dark mode?"
3. "How do I reset my password?"

И контракт ответа:

[
  {"id": 1, "label": "bug"},
  {"id": 2, "label": "feature"},
  {"id": 3, "label": "question"}
]

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

Потоковая передача улучшает отзывчивость, но не снижает стоимость токенов

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

Потоковая передача действительно помогает при досрочной остановке:

• Пользователь раньше видит ход выполнения.
• Приложение может отменить генерацию, как только получит достаточно контента.
• Вы можете остановить чрезмерно длинный ответ до того, как он достигнет заданного лимита.

Последний пункт важен. Если вы генерируете ответ для последующего разбора и первые 120 токенов уже содержат нужный JSON, не продолжайте собирать ещё 800 токенов объяснений.

На практике потоковая передача оправдана, когда приложение может реагировать прямо во время генерации. Если вы просто записываете поток в журнал и всё равно ждёте полного ответа, вы получаете преимущества для пользовательского опыта, но расходы снижаются незначительно.

Измеряйте стоимость каждого запроса, а не только расходы за месяц

Месячные расходы показывают, что у вас есть проблема. Метрики отдельных запросов показывают, где она находится.

Отслеживайте как минимум:

• input_tokens
• output_tokens
• cache_hit_tokens если доступно
• название модели
• эндпоинт / путь выполнения функции
• задержку
• число повторных попыток
• частоту усечения ответов или ошибок разбора

Простая структура данных для журналирования может выглядеть так:

usage = response["usage"]

record = {
    "model": response["model"],
    "input_tokens": usage["input_tokens"],
    "output_tokens": usage["output_tokens"],
    "latency_ms": latency_ms,
    "cache_hit_tokens": usage.get("cache_read_input_tokens", 0),
    "request_type": "ticket_summary",
}
print(record)

Затем рассчитывайте стоимость централизованно:

def estimate_cost(input_tokens, output_tokens, input_rate, output_rate):
    return (input_tokens * input_rate) + (output_tokens * output_rate)

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

• «Небольшой» промпт с огромным скрытым префиксом
• Вызов инструмента, который на каждом шаге повторно отправляет документы целиком
• Лимит генерации, который составляет 10x от необходимого для задачи
• Цикл повторных попыток, незаметно удваивающий потребление
• Маршрут, на котором следует использовать Haiku, но всегда используется Opus

Избегайте незаметного перерасхода

Большинство случаев напрасного расходования токенов выглядят обыденно, поэтому их и пропускают при проверке кода.

Типичные причины

• Повторная отправка одной и той же длинной истории разговора на каждом шаге
• Включение полных исходных файлов, когда нужны только изменения
• Запрос текста в свободной форме, когда достаточно структурированного JSON
• Возврат многословных объяснений системам, обрабатывающим ответ автоматически
• Передача схем инструментов, объём которых превышает объём самой задачи
• Повторное выполнение того же дорогостоящего промпта при автоматических повторных попытках
• Хранение журналов или внутренних заметок в контексте модели

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

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

Практический подход к построению запроса

Вот шаблон, который хорошо подходит для многих задач в рабочей среде:

request = {
    "model": "claude-sonnet-4.6",
    "max_tokens": 180,
    "system": "Extract the root cause and next action. Return strict JSON.",
    "messages": [
        {
            "role": "user",
            "content": "Investigate this incident summary: ... "
        }
    ]
}

Почему такая структура работает:

• Выбранная модель достаточно сильна для рассуждений умеренной сложности.
• Лимит вывода сдерживает чрезмерное многословие.
• Системный промпт короткий и конкретный.
• Формат вывода удобен для машинной обработки.
• Пользовательские данные содержат только необходимые входные данные задачи.

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

Что действительно влияет на расходы

Если бы мне пришлось ранжировать наиболее эффективные меры, список был бы таким:

1. Выбирайте более дешёвую модель для простых задач
2. Убирайте лишнее из промптов
3. Ограничивайте max_tokens жёстко
4. Используйте кэширование промптов для стабильных префиксов
5. Объединяйте небольшие независимые задачи в пакеты
6. Измеряйте потребление на уровне отдельных запросов
7. Не допускайте удвоения расходов из-за циклов повторных попыток

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

Практические рекомендации

• Используйте Haiku для простого извлечения данных и маршрутизации, Sonnet для большинства продуктовых задач, а Opus только тогда, когда задача это оправдывает.
• Воспринимайте системный промпт как источник расходов; удаляйте повторяющийся текст и оставляйте только инструкции, влияющие на поведение.
• Включите кэширование промптов для стабильных префиксов, таких как правила, схемы инструментов и примеры для обучения по нескольким образцам.
• Задайте max_tokens до минимального полезного предела и пересматривайте его для каждой задачи.
• Объединяйте в пакеты небольшие независимые задачи, когда преобладают накладные расходы на инструкции.
• Отслеживайте входные токены, выходные токены, попадания в кэш, повторные попытки и задержку для каждого запроса.
• Следите за незаметным перерасходом: повторяющейся историей, избыточным объёмом извлекаемых данных, многословными ответами и циклами автоматических повторных попыток.

Если хотите, я могу подготовить к этому материалу дополнительную статью с конкретным примером панели мониторинга расходов и несколькими правилами маршрутизации для Haiku/Sonnet/Opus.