Цена API за длинный контекст: пороги и переплата

У Gemini и Grok ставка удваивается, когда запрос переходит 200 тысяч токенов, причём пересчитывается весь запрос, а не превышение. Разница между обращением на 199 тысяч и на 201 тысячу — двукратная. У Gemini 3.1 Pro это 2 доллара за миллион входных токенов против 4, у Grok 4.5 — те же 2 против 4 при выходе 6 против 12. В каталоге KeyDealer такого порога нет: ставка привязана к модели, а не к размеру запроса. Самое неприятное в этой механике то, что к порогу вас двигает не только ваш текст — туда же считаются история диалога, описания инструментов и служебный контекст маршрута, а их обычно никто не измеряет.

Разберём, как устроен порог, что двигает вас к нему незаметно и как перестать переплачивать.

У кого есть порог и какой

Данные с официальных страниц вендоров на 10 августа 2026 года, доллары за миллион токенов.

Порог у обоих вендоров одинаковый — 200 тысяч токенов. Совпадение не случайное: длинный контекст дороже в обслуживании, потому что внимание модели растёт нелинейно с длиной входа, и вендоры выносят это в отдельную ставку.

Обратите внимание на разницу в поведении выхода. У Gemini 3.1 Pro выход растёт в полтора раза, у Grok 4.5 — вдвое. То есть одинаковый порог не означает одинаковый штраф.

Главная ловушка: пересчитывается весь запрос

Это тот момент, из-за которого стоит читать статью до конца.

Порог работает не как прогрессивная шкала. Не «первые 200 тысяч по базовой ставке, остальное по повышенной», а «превысил — значит весь запрос по повышенной».

Посчитаем на Gemini 3.1 Pro:

Две тысячи токенов разницы во входе дают удвоение счёта. В процентах: запрос вырос на 1%, цена — на 102%.

На тысяче таких запросов в месяц это разница в 406 долларов на ровном месте, и появиться она может от одного документа, который кто-то добавил в контекст «чтобы наверняка».

Что двигает вас к порогу незаметно

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

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

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

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

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

Как измерить и что делать

Порядок из четырёх шагов.

1. Измерьте фактический размер. Отправьте типовой запрос и посмотрите prompt_tokens в ответе. Это то самое число, которое сравнивается с порогом. Прикидка по длине текста в символах ошибается систематически.
2. Найдите сценарии в опасной зоне. Опасная зона — не 200 тысяч, а примерно от 150 тысяч: именно оттуда обычный рост истории или пара лишних документов выбрасывают вас за порог.
3. Поставьте жёсткий потолок на размер запроса. Не «постараемся не превышать», а проверка перед отправкой с обрезкой истории или уменьшением числа фрагментов. Потолок должен быть в коде, а не в договорённостях.
4. Считайте бюджет по худшему случаю. Если ваши запросы гуляют вокруг порога, средняя цена вводит в заблуждение. Планируйте по повышенной ставке или уводите размер гарантированно ниже.

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

И ещё один, неочевидный: логируйте prompt_tokens вместе с идентификатором операции. Тогда вопрос «почему в этом месяце счёт вырос» решается выборкой, а не догадками, и видно, какой именно сценарий пополз вверх.

Когда порог выгоднее плоского тарифа

Стоит сказать и обратное, иначе получится однобоко.

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

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

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

Как это устроено в каталоге

На 10 августа 2026 года порога по контексту в каталоге KeyDealer нет. GET /v1/models возвращает по одной паре чисел на модель — вход и выход, — и она не зависит от размера запроса.

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

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

Оговорка по-честному: тарифные сетки меняются у всех, и наша не исключение. Актуальная всегда лежит в GET /v1/models, личные условия аккаунта — в GET /v1/balance, контракт описан в документации API.

Почему вообще существуют такие пороги

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

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

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

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

Что держать в голове

Порог 200 тысяч токенов у Gemini и Grok удваивает ставку на весь запрос, а не на превышение. Разница между 199 и 201 тысячей — двукратная.

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

В каталоге KeyDealer порога нет, ставка привязана к модели. Но привычку измерять размер запроса это не отменяет: она нужна всегда, а на пороговых тарифах просто стоит дороже.

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

Один ключ ко всему каталогу без порогов по контексту: keydealer.ru/login.