Зниження квоти Claude Code: чи створюють агенти нові «гори застарілого коду»?

Клас Code отримав продовження тижневого ліміту, що привернуло увагу; стаття аналізує механізм споживання токенів агентами. Довготривала робота агента призводить до постійного збільшення робочого набору, оскільки кожен крок накопичує історичні стани, а кешовані дані все ще займають місце в контексті, що призводить до накопичувального зростання обчислювальних витрат. Занадто часте очищення викликає «семантичні сторінкові помилки», через які агенту потрібно знову отримувати інформацію. У статті зазначається, що така невідповідність між станом коду та точністю збереження проектного стану може призвести до того, що AI створить «спадковий код»: наступні агенти не зможуть зрозуміти причинно-наслідкові зв’язки ранніх версій коду, що в кінцевому підсумку призведе до складного коду з взаємними компенсаціями між чергою, обхідними шляхами та повторними спробами.

Автор статті, джерело: 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 взаємодій з інструментами.

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

Просто збільшення кількості кроків вже підвищує споживання. Якщо робочий набір продовжує збільшуватися в процесі синхронізації, ситуація зовсім інша. На кроці 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, чому цей кеш може бути лише в service, чому цей стан не може мати двох власників, чому це здається надлишкове порівняння тимчасово не можна видалити — ця інформація належить до проектних причин.

M_tНемає природного безвтратного зберігання, як у Git. Він розподілений між діалогами, міркуваннями, поверненнями інструментів, пам’яттю, файлами правил та стислими підсумками. Після продовження завдань частина інформації видаляється, частина скорочується, а частину потрібно знову знайти.

Так виникає дуже важлива асиметрія: результати можуть накопичуватися з високою точністю, тоді як причинно-наслідкові зв’язки, що їх породили, постійно зменшуються. Це набагато серйозніше, ніж просто сказати: «Агент забуває речі».

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

Код повністю зберіг queue. Після довготривалого виконання стан проекту може звестися лише до «використання queue для вирішення race condition».

Пізніше B також виникла випадкова помилка. Коли агент знову прочитав код, він природньо під’єднав B до існуючої черги.

Після цього затримка зросла, тому додали bypass. Bypass викликав випадкову незбіжність станів, тому зовні додали retry. На цьому етапі жодна з змін не була обов’язково абсурдною; кожен патч у той момент, коли його бачили, навіть міг здаватися досить логічним. Але код вже перетворився з «чіткої моделі паралелізму» на систему, де queue, bypass і retry взаємно компенсують один одного.

Сміттєвий код штучного інтелекту, ймовірно, виникає саме так. Він не обов’язково проявляється у вигляді раптового генерування моделлю сміття — частіше він проявляється як накопичення локально правильних елементів, при якому загальна модель поступово зникає.

У традиційному програмному забезпеченні такі проблеми зазвичай утворюються поступово під час передачі обов’язків. Коли автор виходить, нові розробники бачать старий код, але не знають, чому він існує, і додають зовнішній шар сумісності.

Агент з кодування перетворив «передачу обов’язків» на «передачу контексту». Кроки 20 і 100 здаються частиною однієї сесії Claude Code, але отримані ними стани проекту вже не зовсім однакові. З інформаційної точки зору це схоже на двох інженерів, які підтримують один і той самий репозиторій за допомогою документа з постійно зменшуючоюся кількістю даних.

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

Статус може мати лише одного власника, шар домену не може залежати від UI, певний пакет не може підключатися безпосередньо до бази даних, операції запису повинні проходити через єдину межу транзакцій — ці обмеження, якщо існують лише в документах або пам’яті агента, легко можуть бути обійдені під час локальних виправлень.

Виникає складна інженерна ситуація: тести все ще зелені, а код стає все важче пояснити. Ще більш небезпечним є те, що тут існує зворотний зв’язок.

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

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

Це не проблема окремої моделі, а системна проблема, пов’язана з неузгодженістю точності збереження стану коду та стану проекту.

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

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

Наступне питання буде таким: скільки причинно-наслідкової інформації, корисної для подальших рішень, зберігає агент після 50 кроків, 100 кроків?

Це можна назвати ступенем збереження стану.

Оскільки він вимірює не те, скільки токенів можна вмістити в контекст, а те, скільки ключової інформації про проект залишається у доступній формі після виклику інструментів, стиснення, перекладу між сесіями та пошуку в пам’яті. Це також означає, що довгострокова пам’ять агента не може залежати лише від більш довгого контексту.

Деякі знання краще зберігати в memory, наприклад, спосіб побудови проекту та розробницькі звички; деякі рішення слід включати до структурованих ADR або індексу коду; а ті, порушення яких може зруйнувати архітектурні межі системи, краще прямо вписувати у типи, тести, lint, правила залежностей та CI.

Якщо правило вже перетворено на обмеження, які може виконувати програмне забезпечення, агенту не потрібно «пам’ятати» його. У наступному циклі агент може забути діалог, але не зможе легко обійти компілятор і тести.

Якщо точність низька, тим довше працює агент, тим більше мін встановлюється в систему.

Це може бути та сама межа, яку Coding Agent повинен подолати, щоб перейти від «вміння писати код» до «здатності тривалий час підтримувати програмне забезпечення»: перенести знання про проектування з ймовірнісної мовної пам’яті до програмного стану, який можна знайти, перевірити та виконати.

Інакше чим довше він працює самостійно, тим більш абсурдною стає ситуація: Agent все швидше пише код, проект швидко змінюється, але через певні інтервали йому потрібно знову розуміти світ, залишений попереднім періодом.

Одна зі звичних фраз у традиційному коді: «Цю частину не чіпати, не відомо, чому вона вибухає.»

Наслідковий код ШІ може бути ще дивнішим: код дійсно написаний агентом, але наступні агенти вже не знають, чому попередній агент написав його саме так.