Технічний контекст
Я люблю такі історії не за драму, а за те, як швидко вони викривають слабкі місця в архітектурі ШІ. На початку квітня користувачі Claude Code почали масово писати, що звичний режим роботи раптово перестав вписуватися в 5-годинні ліміти. І йдеться не про шалені навантаження, а про досить звичайну генерацію коду в кілька потоків.
За початковими скаргами картина неприємна: на дорожчому плані ліміт раніше було важко вичерпати навіть за активної роботи, а після даунгрейду в 5 разів люди майже одразу впираються в стелю. Один із найпоказовіших кейсів: після повного скидання сесії користувач надіслав близько 130 тисяч токенів, продовжив попередній контекст, що випав із годинного кешу, і майже миттєво побачив списання близько 5% 5-годинного ліміту.
Я тут одразу роблю дві позначки. Перша: це не схоже на просте “люди стали більше користуватися”. Друга: підозра на сміттєві токени під час створення кешу звучить правдоподібно, тому що схожі стрибки лічильника вже обговорювали раніше.
Зовнішній фон теж збігається. Після кінця березня Anthropic прибрав частину послаблень, включно з промо з підвищеними лімітами в години низького навантаження, і на тлі дефіциту GPU почав помітно сильніше стримувати навантаження. Звідси й подвійний удар: з одного боку реальне посилення rate limits, з іншого, можливо, некоректний підрахунок токенів або невдала логіка кешування промптів.
Для тих, хто будує інтеграції ШІ в розробці, проблема не абстрактна. Коли ліміт згорає не від корисної генерації, а від внутрішньої механіки кешу чи повторної обробки довгого контексту, вся економіка пайплайну починає давати збій.
Вплив на бізнес та автоматизацію
Якщо я створюю рішення на базі ШІ для команди розробки, я не можу спиратися на “ну, начебто вистачає”. Мені потрібна передбачуваність: скільки коштує одне завдання, скільки паралельних сесій тримає команда, що відбувається з довгими ланцюжками агентів, як швидко деградує продуктивність під навантаженням.
І ось тут Claude Code зараз виглядає гірше саме для інтенсивного використання. Не тому, що модель раптово стала поганою, а тому що шар білінгу та лімітів б'є по реальному UX сильніше, ніж самі якості моделі. Коли розробник боїться відкрити другий потік або продовжити довгу сесію, AI automation перетворюється з прискорювача на лотерею.
Хто виграє? Ті, у кого короткі сесії, прості завдання та запасний стек із кількох провайдерів. Хто програє? Команди, які звикли тримати довгий інженерний контекст, запускати дослідницькі гілки та будувати напівавтономних кодинг-агентів за підпискою.
Я б зараз не закладав підписку на Claude як єдиний фундамент для внутрішніх інженерних процесів. Краще проєктувати маршрутизацію: короткі завдання на один рівень, довгий кодовий контекст на інший, критичні пайплайни через API з окремим контролем витрат і логуванням фактичного спалювання токенів. Інакше один несподіваний перерахунок кешу ламає не тільки бюджет, а й терміни.
У Anthropic, найімовірніше, тут суміш із двох проблем: нестача потужностей для інференсу та спірна реалізація лімітування під реальні сценарії кодингу. Це можна пережити, але тільки якщо архітектура від початку не зав'язана на один канал доступу та одну красиву підписку.
Ми в Nahornyi AI Lab якраз розбираємо такі вузькі місця на практиці: де підписка годиться для прототипу, а де вже потрібна нормальна AI-імплементація з маршрутизацією моделей, стратегією кешування та захистом від раптових лімітів. Якщо ваша розробка чи сапорт вже спотикаються об ці обмеження, можна спокійно переглянути ваш workflow і зібрати AI automation так, щоб команда не залежала від чужих сюрпризів кожні п'ять годин.