Технічний контекст
Я зачепився не за гучний анонс, а за приземлений біль розробника: людина на свіжій 5-годинній квоті Claude Code Max 5x дала просту команду зробити commit вечірніх змін і одразу втратила близько 6% ліміту. І це не якийсь екзотичний сценарій, а звичайна рутина, якою забитий будь-який робочий день.
Я трохи копнув, що є по фактах. В Anthropic досі немає чітко опублікованих точних числових лімітів для Claude Code Max 5x. У публічній комунікації фігурує логіка «приблизно в 5 разів більше за Pro», а за звітами тестувальників це близько 225 повідомлень на 5-годинне вікно, але не як жорстка гарантія, а радше як орієнтир.
І ось тут починається найнеприємніше. Коли ліміт рахується не в стилі «у вас стільки-то запитів на хвилину», а через плаваюче 5-годинне вікно, та ще й з окремою внутрішньою логікою по токенах і агентних діях, передбачуваність зникає. Для чату це терпимо. Для production-розробки — вже ні.
З git-операціями картина особливо нервова. Commit, review, редагування файлів, прогін по контексту репозиторію, спроба сформулювати повідомлення коміту, іноді ще приховані ретраї або перерахунок контексту, і команда раптово перетворюється на дорогу агентську сесію. За відгуками користувачів, такі завдання можуть випалювати не 1-2%, а помітно більше, особливо в пікові години.
Anthropic у березні вже визнавала, що частина користувачів впирається в ліміти швидше, ніж очікувалося. Були тимчасові послаблення квот, потім вони закінчилися. Паралельно з'являлися скарги на баги з prompt cache, дивні стрибки витрат і відчуття, що інструмент живе своїм життям, а не за зрозумілими правилами.
Що це ламає в реальній автоматизації
Мене в таких історіях цікавить не сам факт скарги, а те, що вона говорить про архітектуру. Якщо один commit здатний з'їсти 6% вікна, це означає, що Claude Code поки що погано підходить як надійний шар для довгих dev-циклів: гілка, пачка правок, коміти, рефакторинг, тести, follow-up команди. Ланцюжок занадто швидко впирається в rate limiting.
Для одного розробника це роздратування. Для команди це вже ризик для процесу. Не можна нормально планувати ШІ-автоматизацію, якщо вартість типових операцій плаває в рази залежно від години, довжини контексту чи внутрішніх евристик моделі.
Виграють тут поки що ті, у кого короткі, точкові сценарії: запитати по файлу, швидко накидати функцію, локально пояснити помилку. Програють power users, агентні пайплайни та команди, які хочуть зробити ШІ-автоматизацію частиною щоденної розробки, а не іграшкою «допоможи кілька разів на день».
Саме тому я все частіше дивлюся на такі інструменти не як на «заміну IDE», а як на нестабільний обчислювальний ресурс. Якщо ресурс нестабільний, його не можна ставити в центр AI-архітектури. Йому потрібна обв'язка: fallback-моделі, лімітні політики, тротлінг, розбиття завдань, іноді навіть перемикання на API з більш прозорою економікою.
Ми в Nahornyi AI Lab регулярно впираємося в це на проєктах, де йде впровадження штучного інтелекту в розробку та внутрішні інженерні процеси. На папері все красиво: агент комітить, лагодить, пише тести. На практиці без контролю контексту, бюджетів і точок відмови система починає палити гроші або просто зупиняти команду посеред дня.
Звідси й інтерес до альтернатив на зразок Codex або API-моделей OpenAI з більш зрозумілими лімітами. Не тому що «одна модель розумніша за іншу», а тому що передбачуваність часто важливіша за сирий вау-ефект. Бізнесу потрібен не найартистичніший агент, а той, кого можна вбудувати в процес і не гадати, чи переживе він ще три команди до обіду.
Цей розбір зробив я, Вадим Нагорний з Nahornyi AI Lab. Я власноруч збираю ШІ-рішення для бізнесу, проєктую архітектуру ШІ-рішень і дивлюся на такі новини крізь призму експлуатації, а не маркетингу. Якщо хочете обговорити ваш кейс, де потрібна ШІ-інтеграція без сюрпризів по лімітах і бюджету, напишіть мені, разом прикинемо робочу схему.