Fable 5.1's Cache Read Cut and Effort Parameter Are the Two Changes Every Gateway Operator Must Price In

Two changes in Claude Fable 5.1 have operational weight that the launch announcement buries under benchmark numbers. One is a pricing restructure that makes prompt caching four times more valuable on this model than on any other Claude. The other is a new API parameter that turns thinking depth into a per-request routing dimension. Neither is loud, but both will show up in your billing and your latency distribution within a week of switching traffic.

What the cache read price change actually means

Prompt cache reads on claude-fable-5-1 and claude-mythos-5-1 cost $0.25 per million tokens — 0.025× the base input price of $10/MTok. Every other Claude model prices cache reads at 0.1× input, which works out to $1.00/MTok at the same $10 base. That is a 4× difference on the cache read line.

For a typical agentic workflow that sends a 100k-token system prompt on every tool-call turn, the math is:

The cache write price is unchanged. The savings only compound if you are already writing to cache correctly — if you are not, this change gives you a stronger reason to start.

Anthropic's headline claim of "~25% lower cost for typical workloads, ~45% for highly agentic work" comes almost entirely from this repricing. The base input and output rates ($10/$50 per MTok) are identical to Fable 5. Teams that run short, stateless calls will see close to no savings. Teams running long-context multi-step agent loops with stable system prompts will see the most.

The effort parameter: a new routing dial

output_config.effort is not new — it landed with Fable 5 — but it gains a more important role on Fable 5.1 because adaptive thinking is always on and the effort level directly controls how many thinking tokens the model uses.

Three values: low, medium, high. No beta header required for the top-level parameter.

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

The defaults are not uniform across surfaces: High in Claude Code, Medium in Claude Cowork and claude.ai. If you are routing to claude-fable-5-1 through a gateway without setting output_config.effort explicitly, your requests inherit the API default, which may not match what your users expect from the product surfaces they tested against.

There is now a beta extension: per-message effort (anthropic-beta: per-message-effort-2026-05-19), which lets the effort level change turn by turn inside a single conversation. A multi-step research agent can open at high for a complex planning turn, drop to low for a web-fetch summary, and return to high before the final synthesis. That kind of fine-grained control changes how you design cost ceilings and latency budgets for long-running agent sessions.

Gateways that proxy output_config passthrough without modification already support this. Gateways that strip or normalize output_config will need to add it to the allowlist.

What changes for teams currently on Fable 5

Three breaking changes exist. Two are already well-documented. The one operators most commonly miss is the thinking block model-binding rule: thinking blocks produced by claude-fable-5-1 cannot be read by earlier models. If your system sends a Fable 5.1 response through a fallback chain that could land on an older model for continuation, the downstream model will receive truncated or malformed context. The fix is to pin continuation calls to the same model family, or to strip thinking blocks before handing off.

The practical upgrade path:

1. Update model ID: claude-fable-5 → claude-fable-5-1.
2. Remove any tool_choice: {type: "any"} or tool_choice: {type: "tool"} — these return 400 on Fable 5.1. Move to strict tool use or structured outputs.
3. Audit your fallback chain for thinking-block handoff points.
4. Set output_config.effort explicitly — do not rely on surface-default inheritance.
5. If you cache system prompts, recheck your cache write/read accounting against the new $0.25/MTok read rate.

Multi-platform implications

claude-fable-5-1 is available on the Claude API, Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Azure Foundry. Cache read pricing and the effort parameter apply consistently across all four surfaces where prompt caching and adaptive thinking are supported.

Teams routing Fable 5.1 traffic through a multi-cloud setup should verify that their billing reconciliation layer uses the 0.025× cache read multiplier, not the 0.1× inherited from previous models. Providers report cache reads as a separate line item in their billing APIs; the coefficient is model-specific and needs to be updated in any cost-projection tooling.

What TheRouter users should watch

The effort parameter is a model-level config that belongs in routing policy, not just in individual prompts. A gateway that forwards output_config unchanged lets callers control effort per request. A gateway that normalizes or strips output_config makes effort invisible to downstream apps, which means the model always runs at its default and you lose the cost-latency dial entirely.

If you are evaluating whether to move production traffic to Fable 5.1, run your heaviest-caching workload first. That is where the pricing change will be immediately legible in your billing, and it is the clearest signal for whether the upgrade pays for the migration effort.