Контекст в миллион токенов: для чего он реально нужен

Модели Claude и GPT в каталоге — от claude-opus-5-5 до gpt-5.6-luna — идут с контекстом 1 000 000 токенов (у glm-5.3 и glm-5.3-flash — 128K; актуальный список — GET https://api.zukko.pro/v1/models). Это ощутимо больше, чем нужно для обычного чата, и вопрос не «доступно ли», а «когда это вообще стоит использовать».

Что реально помещается в миллион токенов

Грубый ориентир: обычный текст — это примерно 1.3-1.5 токена на слово, код — обычно ближе к токену на слово или чуть больше из-за скобок и отступов. Миллион токенов — это условно несколько тысяч страниц текста или монорепозиторий среднего размера с исходниками без node_modules. Точное число зависит от языка и типа контента, поэтому вместо прикидок считайте по факту:

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-opus-5-5",
    "messages": [{"role": "user", "content": "<содержимое вашего файла или репозитория>"}]
  }'

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

Где это реально решает проблему

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

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

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

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

Где это не нужно и просто дороже

Для классификации, извлечения одного поля, короткого ответа на вопрос контекст 1M ничего не даёт, но токены на входе всё равно тарифицируются по факту отправленного объёма. Если задача про один абзац, отправлять весь документ целиком — не «на всякий случай надёжнее», а просто лишние деньги за каждый токен, который модель прочитала, но не использовала.

Обрыв ответа — это не лимит токенов

При работе с большим входом легко перепутать симптомы. Если ответ обрывается на середине, это почти всегда таймаут HTTP-клиента или сети, а не то, что контекст исчерпан — окно в 1M токенов редко выбирается полностью. Стоит проверить:

• max_tokens в запросе — не занижен ли он для ответа такой длины, какую вы ожидаете;
• таймаут HTTP-клиента — большой вход обрабатывается дольше, и клиентский таймаут в 30 секунд, рассчитанный на короткие запросы, может сработать раньше, чем модель закончит.

Кэш и повторная отправка большого контекста

Кэш шлюза (заголовок X-Zukko-Cache: true; temperature: 0 тоже его включает, но только у моделей, которые принимают этот параметр, — Claude-модели могут отклонить temperature, отличную от 1, с ошибкой 400) срабатывает только при полном совпадении тела запроса: если тот же большой документ отправляется с тем же системным промптом и теми же сообщениями без изменений, повтор засчитывается как cache hit (для чата — на срок до 7 суток), не тарифицируется заново и не пишется в /v1/usage. В длинном диалоге, где к тому же файлу спецификации добавляются новые сообщения, это не работает: общий префикс или «почти одинаковый» запрос в кэш не попадают, и каждый ход оплачивает весь отправленный контекст заново. Учтите и разницу с вендорами: у них чтение из кэша промптов стоит ~10% цены входа, а в Zukko кэшированные токены идут по обычной цене — для агентов и диалогов с большим повторяющимся контекстом реальная разница в цене меньше, чем при сравнении прайсов «в лоб».

Лимит по ключу защищает от случайного перерасхода

Запрос с контекстом в сотни тысяч токенов стоит заметно больше короткого, и если такие запросы уходят из кода, зациклившегося на ретраях по ошибке, можно быстро съесть месячный бюджет. Задайте дневной или месячный лимит расхода в долларах прямо на ключе, на странице ключа в кабинете — при достижении лимита запросы начнут возвращать 429 с кодом key_daily_limit_reached или key_monthly_limit_reached, а не тихо продолжат списывать деньги.

Текст и изображения в одном большом запросе

Модели Claude и GPT принимают изображения (у GLM vision нет) — это можно сочетать с большим контекстом в одном запросе: например, отправить скриншоты нескольких экранов интерфейса вместе с полным исходным кодом компонентов, которые их рендерят, и попросить найти несовпадение между тем, что нарисовано, и тем, что написано в коде. Раздельная отправка текста и картинок в разных запросах теряет именно эту связь между «что видно» и «что написано».

Практический вывод

Спрашивайте себя не «поместится ли», а «нужен ли модели весь этот объём одновременно, чтобы ответить». Если да — считайте токены заранее через /v1/messages/count_tokens, включайте кэш для полностью повторяющихся запросов и проверяйте таймауты клиента. Если нет — режьте вход до того, что реально нужно, и не переплачивайте за контекст, который не читается.