Снижение цены на cache reads в Fable 5.1 и параметр effort: что пересчитать операторам gateway

Анонс Claude Fable 5.1 акцентирует внимание на benchmark-результатах, но два изменения с наибольшими операционными последствиями оказались на втором плане. Первое — структурное изменение цены, которое делает prompt caching на этой модели в четыре раза выгоднее, чем на любой другой Claude. Второе — новый API-параметр, превращающий глубину thinking в регулируемое измерение routing. Оба незаметны при прочтении пресс-релиза, но проявятся в billing и распределении latency уже через неделю после переключения трафика.

Что изменилось в стоимости cache reads

Cache reads на claude-fable-5-1 и claude-mythos-5-1 стоят $0.25 за миллион токенов — 0.025× от базовой цены входных токенов $10/MTok. На всех остальных моделях Claude ставка cache reads составляет 0.1× от входной цены, то есть при той же базе — $1.00/MTok. Разница в четыре раза только по строке cache reads.

Для типичного agentic-воркфлоу, где каждый вызов инструмента отправляет system prompt объёмом 100 тыс. токенов, расчёт выглядит так:

Цена cache write не изменилась. Экономия реализуется только там, где prompt caching уже корректно настроен. Если вы его ещё не используете, это изменение — хороший повод начать.

Заявленные Anthropic цифры «~25% экономии для типичных нагрузок, ~45% для высоко-agentic воркфлоу» объясняются почти исключительно этим перепрайсингом. Базовые ставки на входные и выходные токены ($10/$50 за MTok) остались теми же, что у Fable 5. Команды, работающие с короткими stateless-вызовами, практически не почувствуют разницы. Наибольший эффект у тех, кто запускает длинноконтекстные многошаговые agent-циклы со стабильным system prompt.

Параметр effort как инструмент routing

output_config.effort появился ещё с Fable 5, но его роль на Fable 5.1 стала весомее: adaptive thinking здесь работает постоянно, и уровень effort напрямую определяет, сколько thinking-токенов тратит модель.

Доступны три значения: low, medium, high. Beta-заголовок для верхнего уровня не нужен.

{
  "model": "claude-fable-5-1",
  "max_tokens": 4096,
  "output_config": { "effort": "medium" },
  "messages": [...]
}

Значения по умолчанию различаются в зависимости от поверхности: High в Claude Code, Medium в Claude Cowork и claude.ai. Если вы маршрутизируете трафик на claude-fable-5-1 через gateway, не выставляя output_config.effort явно, запросы наследуют API-дефолт — результат может не совпадать с тем, что пользователи видели при тестировании в продуктовых интерфейсах.

Параллельно появилось beta-расширение: per-message effort (заголовок anthropic-beta: per-message-effort-2026-05-19), позволяющее менять уровень effort от хода к ходу внутри одного разговора. Многошаговый research-агент может открыть сессию на high для сложного шага планирования, переключиться на low при суммировании контента страниц и вернуться на high перед финальным синтезом. Такой контроль меняет подход к проектированию cost ceiling и latency-бюджетов для длительных agent-сессий.

Gateway, прозрачно передающие output_config, поддерживают это без изменений. Те, что нормализуют или обрезают output_config, потребуют добавить поле в allowlist.

Что проверить при переходе с Fable 5

Есть три breaking change. Два из них уже широко обсуждались. Одно, которое операторы упускают чаще всего — правило привязки thinking blocks к модели: thinking blocks, созданные claude-fable-5-1, не могут быть прочитаны более ранними моделями. Если ваш стек отправляет ответ Fable 5.1 в fallback-цепочку, где может оказаться старая модель для продолжения диалога, она получит усечённый или некорректный контекст. Решение — зафиксировать continuation-вызовы на одном семействе моделей или удалять thinking blocks перед передачей.

Практический план upgrade:

1. Обновить model ID: claude-fable-5 → claude-fable-5-1.
2. Убрать все tool_choice: {type: "any"} и tool_choice: {type: "tool"} — на Fable 5.1 они возвращают 400. Перейти на strict tool use или structured outputs.
3. Проверить fallback-цепочку на наличие точек передачи thinking blocks.
4. Явно задавать output_config.effort — не полагаться на наследование поверхностных дефолтов.
5. Если вы кэшируете system prompts, пересчитать cost-модель с учётом новой ставки $0.25/MTok на reads.

Мультиплатформенный контекст

claude-fable-5-1 доступен через Claude API, Amazon Bedrock, Google Cloud Vertex AI и Microsoft Azure Foundry. Там, где поддерживаются prompt caching и adaptive thinking, цена cache reads и поведение effort-параметра одинаковы на всех платформах.

Командам, распределяющим трафик Fable 5.1 между несколькими облаками, нужно убедиться, что billing-reconciliation использует коэффициент 0.025× для cache reads, а не унаследованный 0.1×. Каждый провайдер выставляет cache reads отдельной строкой в billing API; коэффициент специфичен для модели и требует ручного обновления во всех инструментах cost-прогнозирования.

На что смотреть при оценке перехода

Параметр effort относится к уровню routing policy, а не только к отдельным промптам. Gateway, прозрачно пробрасывающий output_config, отдаёт контроль над effort каждому вызывающему. Gateway, убирающий output_config, делает effort невидимым для downstream-приложений: модель всегда работает на дефолтном уровне, и регулятор стоимость-latency исчезает полностью.

Если вы оцениваете переход production-трафика на Fable 5.1, начните с воркфлоу с наиболее интенсивным caching. Именно там ценовые изменения будут видны в billing сразу — это самый чёткий сигнал для оценки целесообразности перехода.