Технічний контекст
Я зачепився не за абстрактні скарги, а за дуже приземлений кейс: зранку даєш Claude Code команду зробити commit вечірніх змін, і з нуля зникає 6% п'ятигодинної квоти. На тарифі Max 5x це вже не дрібна похибка, а прямий удар по робочому ритму.
Якщо орієнтуватися на Max 5x, йдеться приблизно про 88 тисяч токенів у ковзному вікні на 5 годин. Шість відсотків від цього — це близько 5,3 тисячі токенів. Для операції рівня «збери diff, вигадай нормальний message і закоміть» цифра виглядає дико завищеною.
Я дослідив, як це пояснюють самі користувачі та спостерігачі екосистеми Anthropic. Картина повторюється: холодний старт (cold start) тягне в сесію зайвий контекст, кешування промптів (prompt caching) місцями працює нестабільно, а автоматичні повтори та внутрішні службові кроки непомітно роздувають витрати.
Тобто проблема не в одному невдалому запиті. Схоже, що Claude Code має високий базовий оверхед на старті сесії, і на простих завданнях він особливо помітний. Коли інструмент витрачає тисячі токенів до того, як реально виконав корисну роботу, економіка починає тріщати.
Окремий нюанс у тому, що квота не місячна, а п'ятигодинна. Впертися в стелю можна вже в першій половині дня, а далі ти не перерозподіляєш бюджет, а просто сидиш і чекаєш. Для розробки це дратує сильніше, ніж звичайний pay-per-use, тому що блокується сам потік роботи.
Anthropic вже визнавав, що частина користувачів впирається в ліміти швидше, ніж очікувалося. Але з позиції інженера мені важливий не сам факт визнання, а те, чи полагодили поведінку на практиці. За поточними відгуками видно, що для частини команд відповідь поки що така: ні, не полагодили.
Вплив на бізнес та автоматизацію
Мене тут хвилює не побутова незручність, а архітектурний висновок. Якщо проста операція на кшталт commit непередбачувано спалює значний шматок вікна, я не можу спокійно проєктувати на цьому надійну ШІ-інтеграцію в дев-процес, CI або внутрішні агентні сценарії.
У демо все виглядає бадьоро. У проді раптово з'ясовується, що агент, який має економити час, сам стає дефіцитним ресурсом.
Особливо погано це б'є по тих, хто хоче зробити ШІ-автоматизацію навколо рутинної інженерії: генерація commit message, розбір diff, рев'ю, changelog, тріаж завдань. Коли вартість одного кроку гуляє в рази через холодний старт або зламаний кеш, передбачуваність бюджету зникає. А без неї впровадження штучного інтелекту швидко перетворюється на дорогий експеримент.
Хто виграє на цьому тлі? Інструменти зі зрозумілішою економікою: pay-per-token без жорстких вікон, стабільний кеш, прозорі ліміти, нормальна телеметрія. Не дивно, що люди вже дивляться в бік Codex та інших альтернатив, де хоча б простіше зрозуміти, за що саме ти платиш.
Хто програє? Команди, які зав'язали критичні частини процесу на один агентний інструмент без запасного маршруту. Я таке вже бачив: спочатку всі радіють швидкості, потім впираються в ліміти в середині спринту, і далі починається ручний пожежний режим.
Саме тому ми в Nahornyi AI Lab зазвичай не будуємо архітектуру ШІ-рішень навколо одного вендора та однієї цінової моделі. Для бізнесу я майже завжди закладаю fallback-маршрути, роздільні контури для дорогих і дешевих завдань, кешування контексту та жорсткий контроль юніт-економіки. Інакше будь-яка AI-архітектура розсипається на першому ж стрибку лімітів.
Мій висновок простий: Claude Code все ще може бути корисним інструментом, але якщо базові операції на Max 5x починають їсти по 6% вікна, це вже не дрібний баг, а сигнал переглядати стек. Для особистого використання це дратує. Для бізнесу це ризик, який треба прораховувати заздалегідь.
Цей розбір робив я, Вадим Нагорний з Nahornyi AI Lab. Я не переказую пресрелізи, а збираю та перевіряю такі речі в реальних сценаріях AI-автоматизації та розробки ШІ-рішень для команд.
Якщо хочете, я можу допомогти розібрати ваш кейс: де у вас зараз згорають токени, як перебудувати впровадження ШІ та чим підстрахувати критичні процеси. Напишіть мені, і подивимося ваш проєкт разом.