Снижение квоты Claude Code: создают ли агенты новые «горы устаревшего кода»?

Квота Claude Code на неделю была продлена, что привлекло внимание; в статье анализируется механизм потребления токенов агентами. Длительная работа агента приводит к постоянному расширению рабочего набора, поскольку на каждом этапе накапливаются исторические состояния, а даже при попадании в кэш они всё ещё занимают контекст, что вызывает накопительный рост вычислительных затрат. Чрезмерная очистка вызывает «семантические страницы», из-за чего агенту необходимо заново получать информацию. В статье отмечается, что несоответствие между состоянием кода и точностью сохранения проектного состояния может привести к появлению «наследственного кода», сгенерированного ИИ: последующие агенты не смогут понять причинно-следственные связи раннего кода, в результате чего сформируется сложный код с взаимной компенсацией очередей, обходов и повторных попыток.

Автор статьи, источник: LeFeng.com

Код действительно написан агентом, но последующие агенты уже не знают, почему предыдущий агент написал его так.

+50% недельная надбавка к лимиту для Claude Code, первоначально запланированная на завершение 19 августа, была продлена Anthropic до 31 августа. Примерно в тот же период, когда истекал первоначальный срок завершения, на Hacker News развернулась дискуссия о стоимости использования Claude Code: многие обнаружили, что даже несложная задача, при нескольких циклах работы агента, быстро истощает лимит.

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

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

У обычного чат-кодинга четкие вычислительные границы. Вводится фрагмент кода, модель его прочитывает и предоставляет объяснение или предложение по доработке — этот цикл в основном завершается.

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

Чтение исходного кода, поиск ссылок, запуск тестов, просмотр Git diff, изменение файлов — всё это выглядит как непрерывное действие, но на стороне модели это серия независимых запросов на вывод. Официальная документация Claude Code также рассматривает этот цикл «модель принимает решение — вызывает инструмент — на основе результата принимает следующее решение» как основной способ работы агента.

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

Возможно, именно сейчас он начал писать эти несколько строк кода. Поэтомуdiff между размером и объемом вычислений почти не существует стабильного соотношения: за 5 строк патча может быть всего 3 шага рассуждения, а может — уже 30 взаимодействий с инструментами.

Если разбить одну задачу агента, можно получить две переменные: одна — количество шагов, то есть сколько шагов агент сделал для завершения задачи; другая — рабочий набор, то есть сколько состояний элементов модель должна знать на текущем шаге.

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

Это также начало изменения структуры затрат Coding Agent: объем вычислений теперь зависит от «сколько шагов × сколько весит каждый шаг», а не от того, сколько строк кода написано.

Запрос модели агента можно условно разделить на три части. Относительно стабильные части включают system prompt, CLAUDE.md, определения инструментов и правила проекта; постоянно изменяющиеся части включают файлы кода, результаты поиска, журналы тестирования, Git diff и предыдущую траекторию задач; наконец, в этой итерации генерируются рассуждения, текст и код модели.

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

Кэш подсказок может смягчить эту проблему. Официальная документация Claude Code явно указывает, что без кэширования подсказок каждый запрос требует повторной обработки всей истории; при попадании в кэш уже обработанные стабильные префиксы можно повторно использовать, что снижает повторные вычисления и затраты.

Но кэш решает вопрос «можно ли дешевле повторно использовать ту же историю», но не решает вопрос «нужно ли продолжать сохранять эту историю». После попадания в кэш старое состояние 100K Token стало дешевле, но оно всё ещё занимает контекст и остаётся состоянием, на котором строится текущее рассуждение.

Таким образом, длинную задачу можно приблизительно описать как: размер входных данных на шаге t примерно равен стабильному префиксу S, плюс текущий рабочий набор W_t, плюс новые данные, сгенерированные на этом цикле Δ_t.

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

В крайне упрощенной модели без кэширования и очистки, если каждый цикл добавляет примерно одинаковое количество действительных состояний, общий объем обработки будет иметь накопительную структуру, близкую к 1 + 2 + 3 + … + n. То есть, если количество шагов удвоилось, общий объем обработанных исторических состояний может увеличиться быстрее.

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

Таким образом, очень короткий пользовательский запрос в длинной задаче быстро теряет свою значимость. На первый план выходят рабочие наборы данных, которые модель постоянно несет для обеспечения непрерывности задачи.

Почему рабочий набор так быстро растет? Вывод инструментов — один из основных источников. Исходный код хотя бы имеет структуру, а логи часто — нет.

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

Предположим, что тест на шаге 10 сгенерировал 8K токенов логов. При первом попадании в контекст это всего лишь 8K токенов. Однако агенту необходимо продолжить проверку исходного кода, внесение изменений и повторное тестирование; пока этот лог остается в действительной истории, он увеличивает базовый вес для многих последующих запросов.

Это похоже на запись-усиление в системах хранения: одно логическое записывание вызывает последующие дополнительные операции на нижнем уровне. В случае с агентом: один вывод инструмента записывается в историю выполнения, а затем перемещается вместе с последующими рассуждениями.

Таким образом, даже при использовании одних и тех же 8K токенов, размещение их в последнем цикле перед завершением задачи или в самом начале задачи приводит к совершенно разному общему эффекту. Claude Code теперь также активно снижает такое загрязнение. Официальные рекомендации предлагают изолировать задачи с высоким объемом вывода с помощью суб-агентов и прямо указывают, что результаты поиска, логи и большой объем содержимого файлов потребляют контекст основной сессии; сами определения инструментов также занимают место, поэтому чрезмерно большой набор инструментов также увеличивает нагрузку на состояние.

Но здесь возникает обратная проблема: нельзя удалять все логи только потому, что они дорогие. В логе из 3000 строк может быть только 20 строк, связанных с корневой причиной. Система заранее не знает, какие именно 20 строк. Если очистка произойдет слишком рано, а агенту позже понадобится одна из этих деталей, ему придется повторно запускать тест или заново открывать файл.

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

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

Это также объясняет, почему управление контекстом нельзя упростить до «меньше вставлять токенов». Настоящая проблема — выбор рабочего набора: какие данные должны оставаться в рабочей области прямо сейчас, а какие являются уже выполненными промежуточными результатами.

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

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

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

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

Через несколько шагов, если эта информация сжата до: «Проблема с состоянием была решена с помощью service», фактически ничего не изменится, но информация уже изменилась. Исходный контент содержал constraint, а в последующем резюме сохранен только event.

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

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

Memory пытается решить проблему долгосрочного сохранения знаний. Файлы CLAUDE.md и auto memory в корневой директории проекта позволяют извлекать из кратковременного диалога такие элементы, как команды сборки, спецификации проекта и опыт отладки, а затем перезагружать их в начале сессии. Однако Anthropic четко указывает: эти memory по-прежнему являются контекстом и не являются обязательной конфигурацией.

Это различие крайне важно. Если фраза «База данных не может быть доступна напрямую» написана только в памяти, она остается естественным языком, который модель должна понять и соблюдать. Только если это же правило реализовано в виде проверки зависимостей, типовых ограничений или проверки CI, оно становится программным инвариантом, который невозможно легко обойти.

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

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

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

Какие состояния требуют сохранения с высокой точностью, а какие достаточно сохранять в виде краткого описания. Этот вопрос напрямую повлияет на качество последующего кода.

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

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

Claude Code использует ограничения по прокрутке и еженедельные лимиты; Codex теперь четко рассчитывает кредиты на основе input token, кэшированных input token и output token; пакеты Cursor предоставляют Agent разные пулы использования, а расходы на сторонние модели зависят от цен на API моделей.

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

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

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

Эта аналогия не может быть приравнена. Разные модели имеют разную вычислительную стоимость для обработки одинакового количества токенов, и стоимость input, кэшированного input и output также различается. Но с точки зрения разработчика их функции становятся все более похожими: все они описывают, сколько вычислительных ресурсов занимает задача для продолжения работы.

Когда Anthropic в этом году увеличила лимит использования Claude Code, она напрямую связала повышение лимита с добавлением вычислительных ресурсов. Это приведет к интересному изменению показателя. Раньше при оценке Coding Agent было удобно сравнивать, кто лучше справится с одной и той же задачей за один проход. В будущем более значимым может стать вопрос: кто потребляет меньше эффективных вычислений для достижения того же изменения состояния проекта?

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

А именно этот неэффективный процесс восстановления состояния в точности пересекается с техническим долгом на следующем уровне.

Здесь программное обеспечение, поддерживаемое Coding Agent, можно абстрагировать как две одновременно развивающиеся состояния. Одно — состояние кода R_t. Файлы, типы, интерфейсы, тесты, Git-коммиты относятся к этому уровню. Строка retry, добавленная агентом на 20-м шаге, сохраняется в полном виде и при открытии файла на 100-м шаге, если она не была удалена. Код сохраняет высокую точность всех прошлых изменений.

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

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

Так возникает критически важный дисбаланс: результаты могут накапливаться с высокой точностью, тогда как причинно-следственные связи, приводящие к этим результатам, постоянно уменьшаются в выборке. Это гораздо серьезнее, чем просто сказать, что «агент забывает».

При возникновении проблемы с параллелизмом агент после анализа добавил его в очередь. На тот момент его полный вывод был следующим: конкуренция существует только в пути записи A, поэтому очередь может включать только A; путь записи B требует низкой задержки и не может быть добавлен в эту очередь.

Код полностью сохранил очередь. После длительного выполнения состояние может свестись к «здесь очередь используется для решения гонки».

Позже B также столкнулся с случайной ошибкой. Когда агент снова прочитал код, он естественно подключил B к существующей очереди.

Затем задержка увеличилась, поэтому добавили bypass. Bypass вызвал случайные несогласованности состояния, поэтому добавили retry на периферии. На этом этапе ни одна из изменений не была явно абсурдной; каждый патч при том локальном состоянии, которое было видно в тот момент, мог казаться вполне разумным. Однако код уже превратился из «четкой модели параллелизма» в систему, где queue, bypass и retry взаимно компенсируют друг друга.

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

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

Агент по кодированию превратил «передачу обязанностей» в «передачу контекста». Шаги 20 и 100 выглядят как одна и та же сессия Claude Code, но полученные ими состояния дизайна уже не совпадают полностью. С точки зрения информации, это больше похоже на двух инженеров, которые поддерживают один и тот же репозиторий через постоянно сокращающийся документ передачи.

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

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

Возникает сложное инженерное состояние: тесты всё ещё зелёные, а код становится всё труднее объяснить. Ещё более опасно то, что здесь существует обратная связь.

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

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

Это системная проблема, а не проблема отдельной модели, связанная с несоответствием точности сохранения состояния кода и состояния проектирования.

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

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

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

Его можно назвать степенью сохранения состояния.

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

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

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

Если точность низкая, чем дольше работает агент, тем больше мин он закладывает в систему.

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

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

Частая фраза в традиционном наследственном коде: «Не трогай этот участок — неизвестно, почему он взрывается.»

Старый код, написанный ИИ, может быть еще более странным: код действительно был написан агентом, но последующие агенты уже не знают, почему предыдущий агент написал его именно так.