Компания Anthropic с 19 по 31 августа продлила недельную надбавку для Claude Code на 50 %. При этом пользователи Hacker News отмечают: даже несложные задачи быстро расходуют квоту.
Claude Code функционирует через agent loop: модель оценивает текущее состояние, выбирает следующий шаг (например, чтение файла или выполнение команды), получает результат от инструмента и делает следующий вывод. Процесс включает множество действий: чтение исходного кода, поиск ссылок, запуск тестов, просмотр Git diff, изменение файлов. Каждый шаг — отдельный запрос на рассуждение.
Рассмотрим пример работы Agent. При проблеме со случайным сбоем логина Agent находит точку входа, читает service, ищет, кто записывает данные в кэш, запускает тесты, сталкивается с другим исключением, изучает fixture, вносит исправления, проверяет — и только потом пишет код. При этом размер diff и объём вычислений не имеют стабильного соотношения: для 5 строк патча может потребоваться от 3 до 30 взаимодействий с инструментами.
При анализе задачи можно выделить два ключевых параметра:
* step count — количество шагов, которые Agent делает для выполнения задачи;
* working set — объём состояния проекта, который модель должна учитывать на текущем шаге.
Увеличение step count уже повышает расход ресурсов, а рост working set усугубляет ситуацию. Например, если на 3‑м шаге требуется обработать несколько тысяч токенов, то на 30‑м шаге модель может учитывать правила проекта, исходный код, результаты тестов, историю изменений и ответы инструментов.
Структура затрат на Coding Agent изменилась: теперь объём вычислений зависит от произведения количества шагов на объём данных на каждом шаге, а не от количества написанных строк кода. Часть данных (system prompt, CLAUDE.md, инструменты, правила проекта) стабильна, часть (код, результаты поиска, логи тестов, Git diff, история задач, рассуждения модели) меняется. Между запросами к LLM нет общего внутреннего хранилища — если информация из прошлого нужна в текущем запросе, её нужно включать в контекст. Prompt cache снижает затраты: уже обработанные стабильные части можно повторно применять. Без него каждый запрос требует полной обработки истории.
Входной объём на шаге t примерно равен сумме: стабильного префикса S + текущего рабочего набора Wt + новой информации Δt за раунд. Главная сложность — рост W_t: если старые данные не удаляются, рабочий набор увеличивается по мере выполнения задачи. Без кэша и очистки общий объём обработки может расти по схеме 1 + 2 + 3 + … + n: при удвоении количества шагов объём обработанной истории может увеличиваться быстрее.
Выход инструментов (tool output) сильно увеличивает рабочий набор: логи без структуры, grep может вернуть сотни ссылок, сборка — много предупреждений, сбой теста — полный stack trace, Docker, компилятор и менеджеры пакетов генерируют много нерелевантного текста. Например, на 10‑м шаге тест создал 8K Token логов. При первом попадании в контекст это 8K Token, но пока логи остаются в истории, они увеличивают вес последующих запросов. Это похоже на write amplification в системах хранения: одно логическое действие вызывает множество последующих обработок.
Claude Code предпринимает действия по снижению такого «загрязнения». Для изоляции высоконагруженных задач рекомендуется использовать sub-agent. Результаты поиска, логи и большой объём файлов потребляют контекст основной сессии. Большой набор инструментов увеличивает нагрузку на состояние. В логе из 3000 строк может быть только 20 строк, связанных с корневой причиной проблемы; система не знает заранее, какие это строки. Ранняя очистка логов может привести к semantic page fault: при необходимости детали Agent будет вынужден повторно запускать тесты, открывать файлы или анализировать проблему заново.
Возникает дилемма для длительных задач: сохранение избыточного объёма истории усложняет последующие шаги, а слишком агрессивная очистка заставляет Agent повторно получать уже известные данные. Проблема управления контекстом не сводится к сокращению количества токенов — необходимо решать задачу выбора working set (какие данные должны оставаться в рабочей области, а какие являются промежуточными результатами).
Claude Code при приближении к границе контекста автоматически сжимает сессию и очищает старые результаты инструментов. В длительных сессиях нерелевантные диалоги, содержимое файлов и результаты команд могут перегружать окно и влиять на работу модели. Compaction аналогична семантической сборке мусора, однако Agent должен определять не наличие ссылок на объект, а его будущую значимость. Например, изначальное ограничение о том, что модуль не может самостоятельно кэшировать состояние пользователя, со временем может быть сведено к краткому упоминанию события — «проблема с состоянием решена через service». При новой проблеме с производительностью Agent может снова добавить кэширование, так как изначальный запрет уже не будет в активном контексте.
Memory предназначен для долгосрочного хранения знаний: CLAUDE.md в корне проекта и auto memory позволяют извлекать команды сборки, спецификации проекта, опыт отладки из краткосрочных диалогов и перезагружать их в начале сессии. При этом Anthropic подчёркивает: memory остаётся частью контекста, а не является принудительной конфигурацией. Данные в memory по-прежнему представляют собой естественный язык, который модель должна понимать и соблюдать.
Sub-agent решает задачу изоляции рабочего набора: независимый агент сканирует репозиторий или анализирует длинные логи, а затем передаёт сжатые результаты главному агенту, избегая попадания исходного шума в основной поток. Claude Code использует sub-agent для изоляции контекста (context isolation). При этом главный агент получает более чистое состояние, но теряет часть исходных данных; одновременная работа нескольких агентов создаёт отдельные контексты. Compaction, memory и sub-agent вместе образуют подобие иерархии памяти в эпоху агентов: текущий контекст — это дорогая рабочая память, compaction отвечает за сжатие, memory сохраняет состояние между сессиями, sub-agent изолирует шум в отдельном адресном пространстве.
Возникает вопрос: какие состояния нужно сохранять с высокой точностью, а какие достаточно представить в виде краткого изложения — это влияет на качество кода. В Claude Code сложно измерять работу агента по количеству сообщений, так как одно сообщение может означать как изменение имени переменной, так и рефакторинг целого модуля аутентификации — ресурсы, требуемые для выполнения запроса, могут существенно различаться.
Claude Code использует скользящие ограничения и недельные лимиты. Codex рассчитывает кредиты на основе input token, cached input token и output token; Cursor предоставляет агентам разные пулы использования, при этом затраты на сторонние модели зависят от цен API модели. Три продукта имеют разный интерфейс, но решают схожие задачи: как распределить ресурсы рассуждения для интеллектуальной программы с неопределённой продолжительностью выполнения.
Трудно заранее определить, сколько времени займёт работа Coding Agent: модель может быстро найти причину проблемы или попасть в цикл отладки, может потребоваться один агент или несколько sub-agent. Token в этом контексте начинает напоминать CPU time, хотя это не полное равенство: разные модели имеют разную вычислительную стоимость обработки одинакового количества токенов, при этом input, cached input и output имеют разную стоимость. Anthropic при повышении лимита использования Claude Code связал увеличение лимита с добавлением вычислительных мощностей.
Coding Agent поддерживает два типа состояний:
* код (Rt) — файлы, типы, интерфейсы, тесты, Git commit;
* дизайн (Mt) — причинно-следственные связи решений (например, почему нужен retry, где разместить кэш и т. д.).
Rt сохраняет изменения с высокой точностью (например, добавленная на 20‑м шаге строка retry остаётся в силе на 100‑м шаге). Mt не имеет надёжного хранения вроде Git — информация рассеяна в диалогах, рассуждениях, возвращаемых данных инструментов, памяти, правилах и сводках сжатия; часть данных удаляется, суммируется или требует повторного поиска. Возникает асимметрия: результаты сохраняются точно, а причинно‑следственные связи постепенно упрощаются. Например, Agent добавляет queue для решения проблемы параллелизма, изначально понимая, что queue нужна только для пути A, а путь B не должен попадать в очередь из‑за требований к задержкам. Со временем в M_t остаётся только факт «queue решает race condition». Позже при появлении ошибки в B Agent автоматически включает B в queue, что приводит к росту задержек, добавлению bypass, retry и накоплению несогласованностей.
Каждый патч может быть обоснован в локальном контексте, но в итоге код превращается в набор взаимодополняющих элементов (queue, bypass, retry) вместо чёткой модели параллелизма. «AI код‑мусор» формируется через накопление локальных исправлений при утрате общей модели. Это похоже на накопление технического долга в традиционном ПО из‑за смены разработчиков, но в случае Coding Agent проблема проявляется как несовпадение контекстов (например, между 20‑м и 100‑м шагом Claude Code session).
Тесты решают часть проблем (защищают поведение: корректность возвращаемых значений, отсутствие падений при определённых входах, недопущение повторного появления багов), но не покрывают все архитектурные ограничения, не выраженные через входы и выходы. Существуют ограничения: один owner у состояния, отсутствие обратной зависимости уровня домена от UI, запрет прямого подключения пакета к базе данных, все операции записи должны проходить через единый транзакционный барьер. Если эти ограничения существуют только в документации или памяти Agent, они могут быть нарушены при локальных исправлениях, что приведёт к усложнению кода и системы. Возникает обратная связь: архитектура становится хаотичной, Agent при следующем понимании функции должен читать больше файлов, увеличивается рабочий набор данных, система требует очистки и сжатия. Сложность кода растёт, увеличивается стоимость токенов, что стимулирует более короткое сохранение состояния и локальные исправления. Проблема «чем больше итераций, тем больше проблем» в Agent coding связана с несоответствием точности сохранения состояния кода и дизайна.
Важен показатель «точности сохранения состояния» (state fidelity) — он показывает, сколько ключевой информации о дизайне остаётся доступной после вызовов инструментов, сжатия, межсессионного и мемориального поиска. Долгосрочная память Agent не должна полагаться только на увеличение контекста: часть знаний должна храниться в memory (например, способ сборки проекта и привычки разработки), часть решений — в структурированных ADR или индексе кода, а критически важные для системы ограничения архитектуры — в типах, тестах, lint, правилах зависимостей и CI. Если точность сохранения состояния низкая, длительное выполнение Agent создаёт риски для системы. Переход от «умеет писать код» к «способен долго поддерживать ПО» требует переноса проектных знаний из вероятностной языковой памяти в извлекаемое, проверяемое и исполняемое состояние ПО. В противном случае при увеличении времени автономной работы Agent будет периодически вынужден заново понимать ранее созданный контекст. Может возникнуть ситуация, когда последующие Agent не понимают решений, принятых предыдущими Agent.
Доступ к группе через добавление в WeChat: Qvv0909777, в примечании указать: учреждение/вуз + фамилия + направление. Возможность просмотра материалов глобальных AI конференций: выступления экспертов, PPT, полные отчёты конференций, разборы популярных статей, интервью с молодыми учёными. Сканировать QR‑код или нажать «чтение оригинала» для подписки на раздел.
Подписаться в Макс
