контекст-рот: почему 1 миллион токенов — это маркетинг

один миллион токенов контекстного окна — это чистой воды маркетинг.

сейчас практически все ведущие разработчики моделей соревнуются цифрами в пресс-релизах: у Claude, Kimi, GLM окно выросло до 1 миллиона токенов, а у Grok и вовсе заявляли 2 миллиона. со стороны кажется, что наступило будущее: можно загрузить в один тред всю кодовую базу целиком, скормить агенту десятки логов, документацию, скриншоты и вести одну непрерывную сессию неделями.

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

у этого феномена есть точное инженерное название — контекст-рот (context rot), или гниение контекста.

внутри больших языковых моделей (LLM) механизм внимания (attention) распределяется крайне неравномерно. на графике качества работы агента от длины контекста отчетливо видны три характерные зоны.

качество
  ↑
  │   [ рабочая зона: до 200k ]
  │  ┌───────────────────────┐
  │  │  высокая точность     │     [ зона деградации: 200k–500k ]
  │  │  помнит все детали    │╲
  │  │  четко держит стек    │ ╲   галлюцинации, потеря файлов
  │  └───────────────────────┘  ╲
  │                              ╲     [ перегруз: 500k–1M+ ]
  │                               └─── потеря середины (lost in the middle)
  └──────────────────────────────────────────────────────────→ токены
     0                      200k        500k             1M

1. зеленая зона (до 200 000 токенов)

это честное рабочее пространство. пока объем диалога, системных инструкций и прочитанных файлов укладывается в 150–200 тысяч токенов, агент работает предельно эффективно:

• •он точно помнит архитектурные договоренности из начала задачи;
• •видит зависимости между измененными файлами;
• •аккуратно применяет патчи и не ломает соседние модули.

2. желтая зона (200 000 – 300 000 токенов)

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

3. красная зона перегруза (свыше 300 000 токенов)

включается классический эффект «потери середины» (Lost in the Middle). трансформерная архитектура фундаментально лучше удерживает информацию в самом начале контекста (системный промпт, первичные инструкции) и в самом его конце (последняя реплика пользователя и свежий вывод инструмента).

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

если окно в 300 тысяч токенов заполнено на две трети полезной рабочей зоной, то в окне на 1 миллион токенов эффективная рабочая зона составляет едва ли пятую часть. увеличив окно в пять раз, производители не увеличили емкость устойчивого внимания — они просто расширили емкость «мусорного бака».

когда вы работаете в агентском режиме (Claude Code, Cursor Composer, Codex), контекст заполняется молниеносно. вам кажется, что вы написали всего пять сообщений, а контекстное окно уже забито на 150k токенов.

откуда берутся эти токены:

• •чтение файлов целиком: агент прочитал три файла по тысяче строк — улетело 15 000 токенов;
• •вызовы терминала и логи сборки: упавший стек-трейс сборщика или лог npm test легко добавляет от 20 000 до 50 000 токенов за один запуск;
• •diffs и результаты правок: каждый шаг редактирования дублирует куски кода в истории сообщений;
• •скрытые размышления (reasoning tokens): если модель рассуждает на высоком уровне effort, ее внутренние монологи также занимают объем окна.

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

когда контекст приближается к лимиту, харнесс обязан его сжать. и вот здесь между инструментами кроется фундаментальная инженерная разница, о которой редко говорят маркетологи.

как сжимает контекст Claude Code

в Claude (особенно на моделях вроде Opus или Sonnet) автокомпакт работает как классический конспектировщик:

1. 01когда контекст переваливает за безопасную границу, агент берет всю историю переписки;
2. 02генерирует текстовое резюме: «пользователь попросил сделать X, мы изменили файл Y, возникла ошибка Z, сейчас пробуем исправить W»;
3. 03выбрасывает всю сырую историю и подставляет этот текстовый конспект вместо прежнего контекста.

в чем проблема: текстовый пересказ неизбежно теряет технические нюансы. стираются точные сигнатуры вызовов, теряются фрагменты вывода компилятора, исчезает контекст вызовов инструментов (tool calls). после такого сжатия Claude часто «прозревает заново» и начинает задавать вопросы, на которые вы уже подробно отвечали сорок минут назад.

как устроен автокомпакт в Codex

у Codex есть неоспоримое архитектурное преимущество, потому что в процессе участвует серверная инфраструктура OpenAI.

в Codex автокомпакт — это не просто текстовое саммари. при достижении порога агент обращается к специальному серверному эндпоинту. сервер берет полную траекторию сессии — сообщения пользователя, ответы модели и, главное, вызовы инструментов (tool calls) и их результаты — и формирует сжатый зашифрованный блок (compaction), сохраняющий латентные связи задачи.

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

независимо от того, каким агентом вы пользуетесь — Claude Code, Cursor или Codex, — надеяться на «умное бесконечное окно» нельзя. эффективная работа с AI строится на жесткой гигиене контекста.

вот правила, по которым работаю я:

1. гигиена первого контакта: AGENTS.md, CLAUDE.md и чистка скиллов

гниение контекста начинается не в середине диалога — оно часто закладывается на самом первом шаге.

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

• •файлы инструкций проекта: в Codex и универсальных агентах это AGENTS.md, в Claude Code — CLAUDE.md (или .cursorrules в Cursor). если этот файл превратился в свалку на 1500 строк с историей коммитов, чужими сниппетами и банальными советами, агент сразу стартует с забитым окном. держите его предельно лаконичным: только архитектурный стек, строгие правила форматирования и запреты.
• •ревизия активных скиллов: многие агентские среды автоматически подгружают в системный промпт описания всех установленных скиллов и MCP-серверов. если у вас подключено двадцать скиллов «на всякий случай», агент съедает от 20k до 40k токенов только на перечисление доступных инструментов. регулярно вычищайте неиспользуемые скиллы, оставляя только то, что нужно для текущего спринта.

2. правило 200k токенов в Claude Code

если вы работаете в Claude Code, не ждите, пока окно забьется до предела. после 250–300 тысяч токенов качество рассуждений начинает заметно падать. лучшим решением будет не вызывать принудительный текстовый compact, а зафиксировать промежуточный результат и начать абсолютно чистый тред.

3. правило трех компактов в Codex

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

4. сброс контекста через GitHub Issues

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

контекст не должен храниться в оперативной памяти языковой модели. контекст должен храниться в репозитории:

старый чат перегружен (250k токенов)
        │
        ▼
1. агент делает коммит в Git
2. агент пишет status-update в GitHub Issue задачи:
   - что конкретно сделано;
   - какие файлы изменены;
   - текущий статус тестов;
   - следующий атомарный шаг.
        │
        ▼
kill session (закрываем чат)
        │
        ▼
новый чистый чат:
«прочитай задачу #41 и сделай следующий шаг»

когда промежуточный итог зафиксирован в комментарии к GitHub Issue, вы начинаете новую сессию с нулевым объемом токенов. модель получает идеальную зеленую зону, четкую формулировку следующего шага и чистую кодовую базу.

5. локальные файлы памяти и specs

если задача объемная, держите в корне проекта или папки задачи короткие файлы спецификаций:

• •архитектурный контракт или бриф;
• •правила проекта (AGENTS.md), где зафиксированы строгие ограничения;
• •лог текущего плана.

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

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

не позволяйте агенту вариться в собственном мусоре:

1. 01наведите порядок на входе: сократите AGENTS.md / CLAUDE.md и отключите лишние скиллы;
2. 02держите в голове границу эффективной зеленой зоны (до 200k токенов);
3. 03помните о потере середины: старые логи и промежуточные рассуждения убивают внимание трансформера;
4. 04используйте преимущество Codex на длинных сессиях, но не злоупотребляйте им больше трех компактов;
5. 05фиксируйте состояние в Git и GitHub Issues и безжалостно сбрасывайте сессии в чистые треды.

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