Технический контекст
Я зацепился не за громкий анонс, а за приземлённую боль разработчика: человек на свежей 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. Я руками собираю ИИ решения для бизнеса, проектирую архитектуру ИИ-решений и смотрю на такие новости через призму эксплуатации, а не маркетинга. Если хотите обсудить ваш кейс, где нужна ИИ интеграция без сюрпризов по лимитам и бюджету, напишите мне, вместе прикинем рабочую схему.