Сколько на самом деле стоит запрос к LLM: формулы, кэш промптов, reasoning-токены и длинный контекст

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

Все цены и условия ниже я сверил с официальными страницами тарифов и документацией OpenAI, Anthropic и Google 18 октября 2026 года. Они меняются часто, поэтому перед своими расчётами откройте страницы из списка источников в конце.

С чего начинается расчёт

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

cost = ( N_in_uncached × P_in
       + N_cache_read  × P_in × r
       + N_cache_write × P_in × w
       + (N_visible + N_reasoning) × P_out ) / 1 000 000

Здесь P_in и P_out — цены входа и выхода за миллион токенов. Множитель r показывает, во сколько раз дешевле обходится чтение из кэша, обычно это 0,1, а у части новых моделей и меньше. Множитель w — цена записи в кэш относительно обычного входа. У пятиминутного кэша Anthropic и у моделей OpenAI с платной записью он равен 1,25, у часового кэша Anthropic — 2. Там, где запись бесплатна, формально получается единица: вы просто платите за вход как обычно. Наконец, N_reasoning — это токены рассуждений, которых вы не видите в ответе, но оплачиваете по цене выхода.

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

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

Откуда брать числа и почему их легко прочитать неправильно

Все количества токенов из формулы есть в ответе API, в объекте usage. Беда в том, что у каждого провайдера поля называются по-своему и, что хуже, по-своему считаются. Вот как они соотносятся (таблица, на мой взгляд, тут честнее любого абзаца):

Самая коварная разница во входе. У OpenAI и Gemini общий вход уже содержит кэшированные токены, и чтобы получить ту часть, за которую вы платите полную цену, кэш надо вычесть. У Anthropic всё наоборот: input_tokens — это только хвост после последней точки кэширования. Полный вход складывается из него, прочитанного и записанного кэша. Представьте, что вы написали один обработчик для всех провайдеров и вычитаете кэш из входа Anthropic. Если в запросе 2 000 токенов хвоста и 20 000 токенов кэша, вы получите отрицательное число. Если сделать ошибку в обратную сторону и не вычитать кэш у OpenAI, 10 тысяч кэшированных токенов будут посчитаны по полной цене, и прикидка разойдётся со счётом на порядок.

С выходом похожая история, только в зеркальном виде. У OpenAI и Anthropic рассуждения уже включены в выходные токены, а у Gemini их надо прибавлять отдельно. Если забыть об этом, Gemini в ваших отчётах будет выглядеть заметно дешевле, чем на самом деле.

Я довольно долго держал эту логику в голове, пока не свёл её в одну функцию. Привожу её, потому что это ровно тот случай, когда код короче и точнее любого описания:

def normalize(u: dict, api: str) -> dict:
    """Приводит usage разных API к виду: uncached, cache_read, cache_write, output."""
    if api == "openai_chat":
        cached = u.get("prompt_tokens_details", {}).get("cached_tokens", 0)
        return dict(uncached=u["prompt_tokens"] - cached, cache_read=cached,
                    cache_write=0, output=u["completion_tokens"])
    if api == "anthropic":  # input_tokens — только хвост после точки кэша
        return dict(uncached=u["input_tokens"],
                    cache_read=u.get("cache_read_input_tokens") or 0,
                    cache_write=u.get("cache_creation_input_tokens") or 0,
                    output=u["output_tokens"])
    if api == "gemini":     # thoughtsTokenCount НЕ входит в candidatesTokenCount
        cached = u.get("cachedContentTokenCount", 0)
        return dict(uncached=u["promptTokenCount"] - cached, cache_read=cached,
                    cache_write=0,
                    output=u.get("candidatesTokenCount", 0) + u.get("thoughtsTokenCount", 0))
    raise ValueError(api)

Responses API у OpenAI устроен так же, как Chat Completions, только с полями input_tokens и output_tokens. Для моделей OpenAI с платной записью в кэш и для часового кэша Anthropic нужно ещё отдельно вытащить записанные токены и умножить их на свою цену. Дальше остаётся подставить результат в формулу.

Есть и третья тонкость, не связанная с полями. Один и тот же текст разные модели режут на разное число токенов. Anthropic на странице тарифов прямо пишет, что токенизатор Claude 4.7 и новее выдаёт примерно на 30% больше токенов на тот же текст, чем у предыдущих моделей. Значит, если новая модель стоит столько же за миллион токенов, на ваших данных она всё равно будет дороже. Поэтому я давно перестал сравнивать модели по строчке в прайсе. Я прогоняю один и тот же набор реальных промптов и сравниваю итоговую стоимость, посчитанную по usage.

Рассуждения, которые вы не видите, но оплачиваете

Рассуждающие модели перед ответом генерируют внутренний ход мыслей. В руководстве OpenAI по reasoning-моделям сказано, что эти токены не видны через API, но занимают место в контекстном окне и тарифицируются как выходные. У Anthropic то же самое: thinking-токены оплачиваются как output. Google и вовсе пишет это в строке тарифа: «Output price (including thinking tokens)».

Есть деталь, которую я сначала пропустил. Anthropic и Google могут вернуть вам краткое изложение рассуждений, и легко решить, что платишь за то, что видишь. Это не так: оплачивается полное рассуждение, а не его summary. Поэтому число оплаченных выходных токенов может сильно расходиться с объёмом текста на экране.

Насколько сильно, удобно показать на примере. Возьмём gpt-5.6-terra по прайсу OpenAI: вход $2, выход $12 за миллион токенов. Допустим, задача требует, чтобы модель подумала. Во входе 3 000 токенов, видимый ответ — 400 токенов. При высоком уровне усилий модель тратит на рассуждения 6 000 токенов, при низком — 800. Объёмы условные, но порядок типичный.

В первом случае вход стоит $0,006, а 6 400 выходных токенов — $0,0768. Во втором вход тот же, а выход всего 1 200 токенов, или $0,0144. Пользователь получает один и тот же ответ из 400 токенов, но первый вариант в четыре раза дороже, и почти вся разница приходится на рассуждения. Если умножить это на сотни тысяч запросов в день, становится понятно, почему уровень усилий — первый рычаг, за который стоит браться.

Называется этот рычаг у всех по-разному. У OpenAI это reasoning.effort в Responses API или reasoning_effort в Chat Completions. Допустимые значения и значение по умолчанию зависят от модели: в документации встречаются варианты от none и minimal до xhigh и max. У новых моделей Anthropic есть adaptive thinking с параметром output_config.effort. У старых задаётся явный бюджет thinking.budget_tokens: минимум 1024 токена, и он должен быть меньше max_tokens. У Gemini это thinking_level с набором значений, который тоже зависит от модели.

Есть соблазн сэкономить по-другому: просто поставить маленький лимит на выход. Я так делал, и это плохая идея. Параметры max_output_tokens, max_completion_tokens и max_tokens ограничивают сумму рассуждений и ответа, а не только ответ. Если лимит маленький, модель может потратить его целиком на размышления и не успеть ничего сказать. У OpenAI такой ответ приходит со статусом incomplete и причиной max_output_tokens. Видимого текста может не быть вовсе, а вход и рассуждения всё равно будут оплачены. Получается, что вы заплатили за пустоту и вдобавок должны повторить запрос. Google описывает такое же поведение у Gemini и советует снижать thinking_level, а не урезать лимит. OpenAI для начала экспериментов рекомендует оставлять под рассуждения и ответ не меньше 25 000 токенов.

Для себя я вывел простое правило. Стоимостью управляю через уровень усилий, а лимит на выход держу как предохранитель от аварий, а не как инструмент экономии. И отдельно задаю себе вопрос, нужна ли тут вообще рассуждающая модель. Для классификации, извлечения полей из документа или перевода высокий effort обычно ничего не даёт. Я беру тестовый набор, постепенно снижаю уровень усилий и смотрю, в какой момент начинает падать качество. Чаще всего эта точка оказывается ниже, чем я ожидал.

Кэш промптов: когда он экономит, а когда нет

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

Простая арифметика окупаемости

Перед тем как включать кэш, полезно понять, когда он вообще выгоден, ведь запись часто стоит дороже обычного входа. Пусть у нас n запросов с одинаковым префиксом. Первый платит за запись по множителю w, остальные — за чтение по множителю r. Без кэша каждый запрос платил бы единицу. Значит, кэш выгоден, когда w + (n − 1) × r меньше n. Если немного переставить слагаемые, условие получается такое: n > (w − r) / (1 − r).

Подставим реальные цифры. У пятиминутного кэша Anthropic w = 1,25 и r = 0,1, и условие даёт n > 1,28. То есть кэш окупается уже на втором запросе. У часового кэша w = 2, получается n > 2,11, и окупаемость наступает на третьем запросе. Это совпадает с тем, что пишет сама Anthropic в документации по ценам. Там, где запись бесплатна, вопрос окупаемости не стоит: кэш не стоит ничего сверху, и любое попадание — чистая экономия.

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

Как это устроено у OpenAI

У OpenAI кэширование для поддерживаемых моделей включено по умолчанию, ничего настраивать не нужно. Для GPT-5.6 и новее минимальная длина кэшируемого префикса — 1024 токена. Чтение из кэша стоит 0,1 от цены входа, хотя у отдельных моделей и меньше: например, у gpt-6.1-sol в прайсе кэшированный вход стоит $0,10 при обычном $2, то есть 0,05. Запись у этих моделей стоит 1,25 от цены входа и живёт минимум 30 минут после последнего использования. У более ранних моделей отдельной платы за запись нет, скидка на чтение зависит от модели. Срок жизни там задаётся режимом: in_memory держит запись обычно 5–10 минут простоя, до часа, а 24h — до суток.

Ещё один полезный параметр — prompt_cache_key. Он помогает направлять запросы с общим префиксом на одну и ту же машину, и для моделей до GPT-5.6 это заметно повышает долю попаданий. Стоит помнить и о том, что кэшированные токены всё равно учитываются в лимитах TPM. Кэш экономит деньги, но не пропускную способность.

Как это устроено у Anthropic

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

{
  "system": [
    { "type": "text", "text": "Длинные стабильные инструкции и справочник...",
      "cache_control": { "type": "ephemeral" } }
  ],
  "messages": [{ "role": "user", "content": "Вопрос пользователя" }]
}

По умолчанию запись живёт пять минут, и каждое попадание продлевает её без доплаты. Если запросы идут реже, можно указать "ttl": "1h", но тогда запись стоит вдвое дороже обычного входа, а не на четверть. Чтение стоит 0,1 от базовой цены входа. На дату проверки были исключения: у Claude Opus 5.5 и Sonnet 5.5 чтение стоит 0,05, а у Claude Fable 5.1 и Mythos 5.1 — 0,025.

Самое неприятное в кэше Anthropic — то, как он ломается молча. Минимальная длина префикса зависит от модели, от 512 до 4096 токенов. Если префикс короче, запрос просто выполнится без кэша, никакой ошибки не будет. Единственный признак — нули в cache_creation_input_tokens и cache_read_input_tokens. Я однажды неделю был уверен, что кэш работает, пока не посмотрел на эти поля. Иногда выгоднее дописать в слишком короткий префикс пару полезных примеров, чтобы перешагнуть порог.

Префикс у Anthropic собирается в порядке «инструменты, затем системный промпт, затем сообщения», и изменение на любом уровне сбрасывает его и всё, что идёт после. Кэш сбрасывают и менее очевидные вещи: смена tool_choice, добавление или удаление изображений, изменение параметров thinking и effort. Точек кэша в одном запросе может быть не больше четырёх. И ещё одна ловушка для тех, кто любит параллелизм. Запись становится доступна только после того, как начался первый ответ. Если сразу отправить пачку одинаковых запросов, ни один из них в кэш не попадёт: правильнее сначала дождаться начала первого ответа, а потом уже отправлять остальные.

Как это устроено у Gemini

У Gemini два механизма. Неявное кэширование включено по умолчанию для моделей 2.5 и новее, и скидка применяется сама. Явный контекстный кэш устроен иначе: вы создаёте объект кэша с заданным временем жизни и ссылаетесь на него в запросах. Помимо сниженной цены за токены, тут появляется плата за хранение — за миллион токенов в час. У Gemini 2.5 Pro хранение стоит $4,50 за миллион токенов в час, при этом обычный вход стоит $1,25, а кэшированный — $0,125, если промпт меньше 200 тысяч токенов.

Поэтому и окупаемость считается по-другому: вы платите не за запись, а за время. Каждый запрос экономит разницу между обычной и кэшированной ценой, то есть $1,125 за миллион токенов. Хранение стоит $4,50 в час. Делим одно на другое и получаем четыре. Значит, явный кэш Gemini 2.5 Pro имеет смысл, если к нему обращаются хотя бы пять раз в час. Если реже, хватит неявного кэша.

Пример: агент на Claude Sonnet 4.6

Чтобы почувствовать масштаб, разберу агента на Claude Sonnet 4.6. Цены: вход $3, запись в пятиминутный кэш $3,75, чтение $0,30, выход $15 за миллион токенов. Агент делает десять шагов. На каждом шаге стабильный префикс из инструментов и системного промпта занимает 20 000 токенов, новый хвост — 2 000, ответ — 800. Для простоты считаю, что хвост не накапливается.

Без кэша каждый шаг стоит одинаково: 22 000 входных токенов дают $0,066, 800 выходных — $0,012, всего $0,078. За десять шагов выходит $0,78.

С кэшем первый шаг дороже: префикс записывается по $3,75, это $0,075, хвост стоит $0,006, ответ $0,012, итого $0,093. Зато каждый следующий шаг читает префикс из кэша за $0,006, и шаг обходится в $0,024. Девять таких шагов и первый дают вместе $0,309.

Первый шаг с кэшем дороже на 19%, но весь прогон дешевле на 60%. В настоящем агенте история растёт с каждым шагом, и выигрыш обычно ещё больше, если дописывать её в конец и не трогать начало.

Как я строю промпт под кэш

Всё, что я узнал о кэше, сводится к одному принципу: стабильное должно стоять в начале, изменчивое — в конце. Инструменты, системные инструкции, справочники и примеры идут первыми. Дата и время, имя пользователя, идентификатор запроса и сам вопрос — последними. Временная метка в системном промпте — самая частая причина, по которой кэш «почему-то не работает».

Второе, за чем я слежу, — набор инструментов. Он должен быть одинаковым и стоять в одном и том же порядке во всех запросах. Если инструмент нужно временно отключить, у OpenAI для этого есть tool_choice: "none" или allowed_tools, и лучше пользоваться ими, чем убирать инструмент из списка. Сюда же относится сериализация JSON: она должна быть детерминированной. Anthropic отдельно предупреждает, что в некоторых языках, например в Swift и Go, порядок ключей может перемешиваться, и кэш из-за этого ломается без видимых причин.

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

Длинный контекст и обрыв на пороге

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

На дату проверки картина такая. В прайсе OpenAI есть две колонки: короткий контекст, до 272 тысяч входных токенов, и длинный — больше. У gpt-5.6-terra за порогом вход дорожает с $2 до $4, кэшированный вход — с $0,20 до $0,40, выход — с $12 до $18. У Google ступенька стоит на 200 тысячах токенов: у Gemini 2.5 Pro вход растёт с $1,25 до $2,50, выход с $10 до $15, у Gemini 3.1 Pro Preview вход с $2 до $4, выход с $12 до $18. Кэшированный вход выше порога тоже дорожает. Anthropic в этом смысле проще: у Claude 4.6 и новее всё окно в миллион токенов тарифицируется по стандартной цене, и запрос на 900 тысяч токенов стоит за токен столько же, сколько на 9 тысяч. Исключение — Claude Haiku 5.5: для промптов длиннее 100 000 токенов у него действуют повышенные цены.

Главный подвох в том, что повышенная ставка применяется ко всему запросу, а не только к токенам сверх порога. И порог считается по всему входу, включая кэшированную часть. Anthropic для Haiku 5.5 пишет это прямо: длина промпта учитывает все входные токены, включая чтение и запись кэша, и запрос выше порога платит повышенную цену, даже если часть промпта попала в кэш.

Как это выглядит в деньгах, проще всего показать на примере. Возьмём тот же gpt-5.6-terra, ответ в 2 000 токенов, без кэша.

В первом случае вход стоит $0,54, выход — $0,024. Во втором вход стоит уже $1,096, а выход $0,036. Мы добавили 4 000 токенов, полтора процента входа, а заплатили вдвое больше. С Gemini 2.5 Pro картина та же: 199 000 входных токенов и 2 000 выходных стоят $0,269, а 201 000 — уже $0,533. Это тот случай, когда пара лишних страниц логов в контексте агента незаметно удваивает счёт.

Чтобы не попадать на это, я считаю размер входа до отправки: эндпоинты подсчёта токенов есть у всех трёх провайдеров. И держу запас до порога, а не подбираюсь к нему вплотную. Вместо того чтобы складывать в контекст всё подряд, я ищу релевантные фрагменты и подставляю только их. В агентах я сжимаю старую историю и самые шумные результаты инструментов: логи, HTML-страницы, большие JSON. Правда, сжатие меняет префикс и сбивает кэш, так что я каждый раз сравниваю общую стоимость до и после, а не верю, что меньше токенов значит дешевле. Наконец, всё, что не требует ответа в реальном времени, я отправляю через Batch API. У OpenAI, Anthropic и Google это скидка 50% по их прайсам.

Собираем всё вместе на одном ответе

Посмотрим, как все эти соображения сходятся на одном реальном вызове. Допустим, Chat Completions вернул такие числа: 12 000 входных токенов, из них 10 240 прочитаны из кэша, 1 900 выходных, из них 1 500 приходятся на рассуждения. Модель та же gpt-5.6-terra.

Сначала нормализуем. Некэшированный вход — 12 000 минус 10 240, то есть 1 760 токенов по $2 за миллион, это $0,00352. Кэшированные 10 240 токенов по $0,20 стоят $0,002048. Весь выход, 1 900 токенов по $12, стоит $0,0228. Итого около $0,0284.

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

Для одного шага агента на Claude Sonnet 4.6 из примера выше, где 2 000 токенов хвоста, 20 000 прочитаны из кэша и 800 токенов на выходе, тот же расчёт даёт $0,024 — ровно то, что получилось в таблице.

На практике я не считаю такие вещи руками. Я пишу в лог каждый объект usage целиком, вместе с названием API и модели, а раз в неделю прогоняю лог через функцию нормализации и формулу. Если отдельно разложить стоимость по слагаемым, видно, куда уходят деньги. На некэшированный вход, который можно было закэшировать. На промахи кэша из-за плавающего префикса. На запись в кэш, которая не окупается. Или на рассуждения, которые не нужны для этой задачи. В каждом из этих случаев способ экономии свой, и без такой разбивки легко чинить не то.

У этого подхода есть ограничения, о которых стоит помнить. Плата за хранение явного кэша Gemini почасовая, и в расчёт по отдельным запросам она не попадает, её надо считать отдельно. Серверные инструменты вроде веб-поиска или исполнения кода тарифицируются сами по себе. На дату проверки у OpenAI и Anthropic для новых моделей была надбавка в 10% за региональную обработку, а режимы Batch, Flex и Fast меняют цены в другую сторону. Если вы пользуетесь чем-то из этого, в формулу нужно добавить соответствующие множители.

Что я вынес из всего этого

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

И последнее. Модели стоит сравнивать по стоимости своих реальных запросов, а не по строчке в прайсе: токенизаторы и аппетит к рассуждениям у них слишком разные. А прайсы стоит перепроверять. За последний год у всех трёх провайдеров менялись цены, правила кэширования и параметры, и к моменту, когда вы читаете этот текст, какие-то цифры выше наверняка уже устарели.

Эти расчёты выросли из работы над учётом расходов в нашем проекте Heli, но всё описанное выше одинаково применимо к любому коду, который ходит в API языковых моделей.

Источники

Страницы проверены 18.10.2026.

OpenAI: Pricing, Prompt caching, Reasoning models, Chat Completions API reference.

Anthropic: Pricing, Prompt caching, Extended thinking, Thinking.

Google: Gemini Developer API pricing, Context caching, Gemini thinking, generateContent API reference.