Anthropic унифицирует лимиты API Claude: что означает паритет Sonnet/Haiku/Opus для команд маршрутизации

26 июня Anthropic тихо выпустила самое значимое обновление лимитов с момента запуска Mythos 5: Claude Sonnet 4.x и Claude Haiku 4.5 теперь имеют идентичные потолки RPM, ITPM и OTPM с Claude Opus 4.x на каждом уровне использования. Параллельно пять старых уровней объединены в три — Start, Build и Scale — с фиксированным ежемесячным лимитом расходов. Если ваша политика маршрутизации строилась на разных лимитных бюджетах для разных моделей, эти допущения больше не актуальны.

Что изменилось 26 июня

До этого обновления Haiku имела отдельный, более низкий токен-бюджет по сравнению с Sonnet и Opus. Команды, строившие цепочки fallback, намеренно направляли трафик высокого объёма к Haiku, чтобы сохранить квоту Opus. Эта возможность исчезла.

Новые единые лимиты для Opus 4.x / Sonnet 4.x / Haiku 4.5:

Важно: лимиты по-прежнему применяются отдельно для каждой модели — трафик Opus не расходует квоту Sonnet — но внутри каждой модели лимиты симметричны на всех уровнях.

Claude Fable 5 остаётся на собственном расписании (Start: 500K ITPM, Build: 1,5M, Scale: 4M), отражая более высокую стоимость вычислений.

Консолидация также устранила промежуточные уровни. Организации на промежуточных уровнях автоматически переведены на ближайший; Anthropic подтвердила, что ни одна организация не получила лимиты ниже прежних.

Лимиты расходов по уровням

Трёхуровневая структура включает ежемесячные потолки расходов:

Custom-уровень (договорной) лимита не имеет. Для команд на Scale $200K/месяц — солидный запас, однако помните о примечании про accelerator-лимиты: резкие всплески трафика вызывают 429 независимо от уровневого лимита, поэтому наращивайте нагрузку плавно.

Преимущество кэш-aware ITPM

Самый недооценённый аспект дизайна лимитов Anthropic — что именно не считается. Для всех актуальных моделей Claude (кроме снятой с поддержки Haiku 3.5) cache_read_input_tokens не учитываются в лимите ITPM. Квоту расходуют только некэшированные входящие токены (input_tokens + cache_creation_input_tokens).

Практически: на уровне Build с 5M ITPM при доле кэш-попаданий 80% эффективная пропускная способность составит ~25M токенов в минуту. Это структурное преимущество для workload-ов маршрутизации, которые делятся большими system prompt-ами, определениями инструментов или контекстами документов между запросами.

Команды, использующие архитектуру общего кэша, могут поддерживать значительно более высокий concurrency без повышения уровня. Rate Limits API (/manage-claude/rate-limits-api) позволяет программно опрашивать остаток квоты, что делает возможной динамическую маршрутизацию: деградировать к лёгкой модели только при реальном давлении на ITPM, а не по статическому прогнозу.

Влияние на политику fallback-маршрутизации

При старой мультиуровневой схеме многие команды строили цепочки так:

1. Основной: Opus 4.x (лучшее качество, меньший лимит)
2. Fallback: Sonnet 4.x (средний лимит, отдельный бюджет)
3. Аварийный fallback: Haiku 4.5 (высокий RPM, дешевле, изолированный лимит)

Это позволяло сохранять квоту Opus за счёт объёмного трафика в отдельный бюджет Haiku.

При паритете стратегия сегрегации моделей для разделения бюджета больше не работает. Каждая модель сохраняет независимый бюджет, поэтому трафик Haiku не блокирует трафик Opus — лимиты остаются per-model. Но логика «накапливать квоту Haiku для перелива» устарела, ведь потолок теперь одинаков.

Правильная логика маршрутизации теперь строится на:

• Эффективности по стоимости задачи: Haiku для объёмной суммаризации, Opus/Fable для reasoning-цепочек. Бюджет симметричен, выбор — только качество и цена.
• Доле кэш-попаданий: проектируйте system prompt-ы и схемы инструментов для переиспользования через кэш — расширяйте эффективный ITPM без апгрейда уровня.
• Близости к лимиту расходов: отслеживайте ежемесячные расходы относительно потолка; жёсткая пауза на $500/$1K/$200K — риск для надёжности. Установите workspace-подлимит ниже потолка, чтобы избежать внезапных сбоев.

Нюанс AWS, который часто упускают

Организации, обращающиеся к Claude через Claude Platform on AWS (путь Bedrock), помещаются на уровень Start и не повышаются автоматически. Для запроса более высоких лимитов необходимо обращаться к представителю Anthropic. Конфигурация лимитов на уровне workspace и fast mode на этом пути также недоступны.

Если вы маршрутизируете трафик Claude через AWS-нативную инфраструктуру и ожидаете автоматического повышения уровня — проверьте условия с представителем аккаунта.

Что проверить сейчас

1. Просмотрите лимиты workspace на странице Limits в Claude Console — убедитесь, на каком уровне вы находитесь и меняет ли паритет ваши допущения о fallback.
2. Проверьте долю кэш-попаданий на странице Usage. Если для workload-ов с общими system prompt-ами она ниже 50%, эффективный ITPM используется не полностью.
3. Установите workspace-подлимит расходов ниже потолка уровня — это защита от жёстких пауз при достижении лимита.
4. Пересмотрите логику fallback-цепочки: если разнообразие моделей служило способом сегрегации бюджета, замените обоснование на стоимость и качество.
5. Операторы AWS: подтвердите уровень и при необходимости подайте заявку на повышение лимитов через представителя аккаунта.

Изменения 26 июня — структурное упрощение: меньше уровней, симметричные лимиты, прозрачный потолок расходов. Для команд маршрутизации выбор модели теперь должен определяться стоимостью и возможностями, а не тем, у какой модели был бОльший лимитный бюджет.