Claude Code дважды ушёл в сжатие контекста: разбор кейса на Opus с окном в миллион токенов

Кейс описывает команда, которая ведёт несколько крупных проектов на подписке Claude Code за 100 долларов в месяц. Роли разделены: у каждой собственное рабочее пространство, задачи декомпозируются, крупные исследования выносятся в отдельные сессии. Архитектор продукта работал на модели Opus с контекстным окном в один миллион токенов и дважды ушёл в compaction — сжатие истории разговора, когда сессия приближается к пределу окна.

Первый симптом выглядел странно: на экране агента появилось сообщение Compacting conversation… (24m 47s · ↓ 85.5k tokens). Механизм compaction полезен — Claude Code создаёт краткое описание предыдущей работы и продолжает уже с ним, иначе новые сообщения перестанут помещаться. Но здесь возникли два вопроса: почему сжатие заняло почти 25 минут и как агент успел исчерпать миллион токенов. После сжатия интерфейс показывал около 110 тысяч токенов — примерно 11% окна. Что происходило до compaction, интерфейс не объяснял.

Разбор поручили ИИ CTO команды — отдельной роли, которая тоже работает в Claude Code. Получилась ироничная схема: один Claude Code-агент расследует, почему другой Claude Code-агент потерял контекст. Сначала проверили конфигурацию: модель, effort, переменные окружения, локальные и глобальные настройки. Подтвердилось, что проблемная сессия работала на Opus и что окно не было искусственно уменьшено проектной настройкой. Затем ИИ CTO нашёл транскрипт сессии ArchitectProduct и восстановил объём входного контекста по usage каждого запроса.

Картина оказалась странной. В 07:39:55 учтённый входной контекст составлял 536 845 токенов, в 07:40:04 — 537 433, а в 07:40:09 — уже 1 077 204. После сжатия, в 07:51:41, осталось 114 828. Контекст не рос постепенно до миллиона: он увеличился примерно на 540 тысяч токенов за один запрос. Отношение 537 433 к 1 077 204 — почти идеальное удвоение.

Первой версией стал слишком большой результат инструмента. Она выглядела разумно: ИИ-агент мог прочитать огромный файл, вывести целый контракт, развернуть документацию или случайно отправить в stdout содержимое большого набора артефактов. ИИ CTO так и ответил: искать нужно крупный tool result, а массовые развёртки лучше выполнять через субагентов и возвращать в основную сессию только выводы. Совет разумный, но причина была не в этом.

Когда usage разложили на составляющие, версия с огромным выводом начала разваливаться. В 07:40:04 input_tokens составили 253, cache_read_input_tokens — 536 843, cache_creation_input_tokens — 588. В 07:40:09 input_tokens выросли до 41, cache_read_input_tokens — до 1 075 384, cache_creation_input_tokens — до 1 816. Свежий input вырос всего на два токена. Почти весь скачок пришёлся на cache_read_input_tokens — повторное использование уже закешированного контекста.

Соседние события в JSONL это подтвердили. Перед выбросом агент проверял наличие PlantUML, затем извлёк 26 диаграмм. Результаты двух команд занимали 174 и 109 символов. После скачка был обычный FileNotFoundError примерно на тысячу символов. Ни одного результата на полмиллиона токенов рядом не было. Сам ИИ CTO сформулировал важную мысль: скачок ровно вдвое подозрителен, надо убедиться, что это реальный контент, а не двойной счёт.

Для читателя, который впервые слышит о compaction, стоит пояснить механику. Контекстное окно — это предельный объём текста, который модель может учитывать за один проход. Когда история разговора приближается к этому пределу, Claude Code сжимает её в краткое описание и продолжает работу уже с ним. Побочный эффект — потеря деталей: агент может забыть, какие файлы уже читал, какие решения принял и какие зависимости проверил. Если сжатие срабатывает неожиданно рано, это сигнал, что контекст расходуется неэффективно.

В этом кейсе ключевая деталь — природа скачка. Рост произошёл не за счёт нового содержимого, а за счёт повторного чтения уже закешированного контекста. Кеш нужен, чтобы не платить за повторную обработку одних и тех же токенов, но в отчётности usage он может выглядеть как реальный объём. Если смотреть только на текущий экран после compaction, всё выглядит спокойно: занято примерно 11%, впереди огромный запас. Но эти 11% — уже после сжатия, и интерфейс не показывает, что было до него.

Практический вывод для команд, которые ведут несколько проектов на Claude Code, — не полагаться на индикатор заполнения окна после compaction. Полезно сверять usage по каждому запросу из транскрипта, разделяя input_tokens, cache_read_input_tokens и cache_creation_input_tokens. Скачок ровно вдвое — характерный признак двойного счёта, а не реального роста контента. И если compaction занимает десятки минут, это отдельный сигнал: сжатие большого объёма истории стоит дорого по времени, даже когда окно формально позволяет продолжать.