Если коротко, паника 19 февраля не взялась из воздуха. Люди увидели новые формулировки в документации Anthropic про запрет стороннего использования OAuth токенов. Дальше Reddit, GitHub issues, чаты разработчиков, все загорелось за часы.

Я в тот день тоже сидел в консоли и смотрел, как агенты стопорятся почти на старте. Причем квота по подписке вроде живая. Деньги списаны. План Max 20x. А сессия стоит.

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

Давай разложу как есть. Что именно ломается, почему ломается и что реально помогает в проде, когда у тебя не демка, а рабочий контур с дедлайнами.

Что именно произошло 19-20 февраля

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

Через несколько часов представитель Anthropic в X написал, что это кривой апдейт документации, не смена реальной политики. На следующий день вышли публикации в медиа с похожим посылом, мол пользоваться пока можно.

Но что важно. Документация и фактическое поведение не до конца совпали. Отсюда главная боль. Технически люди продолжают работать. Юридически нервничают. Операционно получают 429 чаще, чем привыкли.

230+
апвоутов у треда в r/ClaudeAI
97
комментариев за сутки
429
самая частая ошибка недели

У нас в команде вывод был простой. Верить только официальному статусу нельзя. Нужно иметь запасной маршрут и не завязывать всю работу на один тип доступа к модели.

Главная путаница: люди смешивают два разных лимита

Большинство смотрит на недельную или пятичасовую квоту и думает, что запас большой. Да, большой. Но агент упирается в другое.

Первый лимит, per-minute. Это RPM, ITPM, OTPM. Сколько запросов и токенов ты можешь съесть прямо сейчас, в скользящем окне.

Второй лимит, длинный. Недельная или пятичасовая квота плана Pro или Max. Это общий бюджет на период.

План Max 20x расширяет длинный бюджет. Но не гарантирует, что минутный потолок вырастет в двадцать раз. В этом и ловушка. Ты вроде в богатом тарифе, а агент получает 429 на старте.

Видел такое лично. Сессия свежая, задача тяжелая, контекст толстый. Первый большой запрос и сразу красная строка в логе. Знакомо?

Почему агент тратит лимиты быстрее человека

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

Когда входной пакет прыгает к 40-80 тысячам токенов, минутный лимит пробивается одним-двумя запросами. Особенно на Opus, где люди любят широкий контекст.

Практика: один агентный шаг с большим контекстом легко съедает столько, сколько ручной оператор не потратит за десять минут.

И еще нюанс. Лимит работает как token bucket. Это не таймер на ровной минуте. Нет магического сброса в 00 секунд. Восстановление идет плавно. Значит серия быстрых запросов почти всегда больнее, чем один такой же объем, но с паузой.

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

Почему даже Max 20x не спасает

Потому что Max 20x чаще про объем за длинный отрезок. А ты умираешь на пике здесь и сейчас. Это как большой бак бензина с тонкой топливной магистралью. Бак полный, машина дергается.

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

У нас был похожий эпизод ночью на релизе. Два почти параллельных тяжелых сценария и одна дополнительная проверка поверх. Квота по плану оставалась жирной. Минутный канал схлопнулся.

После этого мы перестали запускать параллельный Anthropic-heavy поток в пиковые часы. Развели нагрузку между провайдерами. Часть задач ушла в Codex, часть в Gemini, часть оставили на Claude для точечных решений.

Отдельная боль: ложные 429 и баги в обвязке

Еще один неприятный момент. Иногда ты видишь "Rate limit", а корень в другом месте. Например safety фильтр. Ошибка маскируется и уводит диагностику не туда.

Плюс есть известные истории, когда cooldown в клиенте распространялся слишком широко и блокировал весь провайдер, хотя лимит ловила одна модель. Итог простой, дебаг занимает больше времени, чем сама задача.

Как мы выкручивались:

Когда это включили в рутину, фраза "непонятно, что упало" почти исчезла.

Рабочая схема, которая пережила реальный прод

Ниже не теория. Это то, что мы используем сейчас в PROSTUDIO.NET для стабильной работы агентного контура.

Сжимаем контекст раньше, чем становится больно

Если сессия растет, не ждем момента, когда модель начнет задыхаться. Делаем compaction заранее. Ранний trim сильно режет ITPM, а качество ответа падает меньше, чем боятся новички.

Тяжелые задачи не пускаем пачкой

Даже если хочется параллелить, минутный лимит не обманешь. Сложные шаги идут очередью. Между ними короткая пауза. Это дешевле, чем ловить каскад 429 и потом все переигрывать.

Один провайдер не держит весь бизнес

Claude отличный, но не единственный. Рутину и массовые операции выносим в альтернативные модели. Claude оставляем там, где реально нужна глубина рассуждения.

API ключ держим как страховку

Подписка удобна, API дает более предсказуемую механику лимитов и биллинга. Когда вокруг шум по policy, такой fallback спасает нервы и сроки.

60%
снижение всплесков ITPM после ранней compaction
5-10с
пауза между тяжелыми запросами
3
провайдера в рабочем стеке вместо одного

Короткий разбор заголовков, которые нужно логировать

Если ты до сих пор не сохраняешь rate-limit headers, ты работаешь вслепую. Серьезно. Там почти вся правда про текущее состояние лимита.

Нужны минимум эти поля:

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

Что делать команде сегодня, если дедлайн горит

Не буду рисовать идеальный мир. На горящем проекте нужно быстрое решение.

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

Если после этого все еще трясет, включаешь fallback через API-ключ и спокойно закрываешь релиз. Красота не в том, чтобы никогда не падать. Красота в том, чтобы подниматься за минуты.

Проверочный вопрос для команды. Если Anthropic на час встанет в жесткий cooldown, какой кусок вашей системы продолжит работать без ручного спасения?

Если ответа нет, значит не архитектура, а надежда.

Мой вывод как техдиректора

История с лимитами в феврале показала простую вещь. Рынок AI в 2026 зрелый ровно настолько, насколько зрелы твои внутренние процессы. Не чужой пресс-релиз, не пост в X, не обещание в лендинге.

У нас после этой турбулентности правила стали жестче. Меньше романтики, больше измерений. Любая агентная цепочка проходит через бюджет токенов, лимит по минуте, fallback маршрут и контроль деградации качества.

Это скучно? Да. Это спасает прод? Еще как.

Ты можешь собрать сильный AI-стек и не бояться утренних сюрпризов. Но для этого придется считать, логировать и проектировать под сбои заранее. Другого пути я пока не видел.

Мини-чеклист перед каждым тяжелым запуском

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

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

Кейс из практики, как один промах в архитектуре бьет по срокам

Недавний кейс. Нужно было за короткое окно прогнать исследование, контент, публикацию и проверку ссылок. Мы сначала пустили цепочку слишком бодро. Три больших шага почти подряд на одном Anthropic-контуре. Итог ты уже угадываешь. Пошли 429, потом повторные попытки, потом залипание очереди.

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

Самый полезный вывод тут не технический. Он управленческий. Когда система упирается в лимит, команда под стрессом начинает хаотично жать "retry". Это ухудшает ситуацию. Нужен сценарий действий заранее, чтобы люди не делали лишних движений.

Вопрос тебе. В твоем процессе есть такой сценарий? Или каждый инцидент решается по наитию, кто первый проснулся в чате?

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

Хочешь проверить идею до того, как сжечь месяцы разработки

DeathScore за пару минут показывает слабые места, риски и точки роста. Без иллюзий и без лишнего пафоса.

Проверить идею →

Фёдор Слюсаренко, техдиректор PROSTUDIO.NET. Пишу о том, что реально проходит прод, а не только красиво выглядит в презентациях.