Claude Fable 5 Is Live: What the New Model ID, Refusal Semantics, and Token Accounting Mean for Your Routing Layer

On June 9, 2026, Anthropic made Claude Fable 5 (claude-fable-5) generally available across the Claude API, AWS Bedrock, Vertex AI, and Microsoft Foundry. It is the most capable model Anthropic has released to the general public — and it ships with a set of API-level changes that require deliberate migration work from any team running it through a routing layer.

Claude Mythos 5 (claude-mythos-5) launches the same day but is not generally available; it is restricted to Project Glasswing customers.

This article documents every API change that matters for multi-provider routing teams and explains what to update before pointing traffic at claude-fable-5.

The New Model ID and Tokenizer

The production model ID is claude-fable-5. There is no dated suffix in the first release.

One gotcha for teams migrating from pre-4.7 models: Claude Fable 5 uses the tokenizer introduced with Claude Opus 4.7. The same prompt produces roughly 30% more tokens compared to models released before that generation. If you bill downstream users based on input token counts, or enforce hard context limits, you need to revalidate those limits before routing live traffic to claude-fable-5. A prompt that fits in a 60k-token budget under Sonnet 4.6 may exceed it under Fable 5.

Context window: 1M tokens. Max output: 128k tokens. Both are consistent with what Opus 4.8 offers.

Pricing: $10 per million input tokens / $50 per million output tokens — 2× the cost of Opus 4.8 ($5/$25) and more than 3× the cost of Sonnet 4.6 ($3/$15). Make sure your cost-routing thresholds account for this tier.

Adaptive Thinking Is Always On — and Raw Chains Are Never Returned

This is the most consequential API change for routing layers that inspect or log response structure.

Adaptive thinking is the only thinking mode on Claude Fable 5. You cannot disable it with thinking: {"type": "disabled"}. The thinking parameter itself still exists and is accepted, but "disabled" is silently treated as the default (adaptive). Use the effort parameter to control thinking depth instead.

More importantly: raw chain-of-thought is never returned. The thinking.display field defaults to "omitted", which returns thinking blocks with an empty thinking field. If your routing proxy logs or inspects message content blocks for thinking text, those blocks will now appear structurally present but empty. To receive readable reasoning summaries, set display: "summarized". Raw thinking text — as available on older Claude reasoning models — is not accessible at any setting.

This affects:

• Observability pipelines that extract thinking blocks for debugging
• Prompts that rely on thinking text appearing in content for downstream parsing
• Any logic that counts non-empty thinking blocks as a signal

When building multi-turn conversations, pass thinking blocks back unchanged in subsequent requests, exactly as you would for other Claude models.

The New stop_reason: "refusal" — Handle It, Don't Ignore It

Claude Fable 5 includes safety classifiers. When a classifier declines a request, the Messages API returns a successful HTTP 200 response with stop_reason: "refusal" — not a 4xx or 5xx error.

A minimal refusal response looks like this:

{
  "stop_reason": "refusal",
  "stop_details": {
    "type": "refusal",
    "category": "cyber",
    "explanation": "This request was declined because it could enable cyber harm."
  },
  "content": [],
  "usage": {
    "input_tokens": 412,
    "output_tokens": 0
  }
}

The stop_details.category field can be "cyber", "bio", "reasoning_extraction", or null. The explanation text is not stable — display it to users, do not parse it programmatically. When stop_details itself is null, the refusal occurred but does not map to a named category.

What this means for your routing layer: if you currently treat any HTTP 200 response as success and pass the model output downstream, you will silently deliver empty content when a refusal fires. Gating on stop_reason !== "stop" is not enough — you must also handle "refusal" explicitly, either by surfacing it, falling back to another model, or retrying with a reformulated prompt.

Server-Side and Client-Side Fallback for Refused Requests

Anthropic has introduced a fallbacks parameter in beta that lets the API automatically retry a refused request on an alternative model, within a single API call:

await client.beta.messages.create({
  model: "claude-fable-5",
  max_tokens: 1024,
  messages,
  betas: ["server-side-fallback-2026-06-01"],
  fallbacks: [{ model: "claude-opus-4-8" }]
});

When Fable 5 refuses the request, the API retries it with claude-opus-4-8 transparently. The response you receive is from the fallback model; the model field in the response reflects which model actually served it.

This is a beta on the Claude API and Claude Platform on AWS only. On Bedrock and Vertex AI, you need client-side fallback: catch stop_reason: "refusal" in your SDK middleware and re-issue the request to a different model.

Billing note: if a request is refused before any output is generated, you are not billed for it. When you retry on a fallback model, prompt-cache costs from the first attempt are credited back — so you do not pay twice for prompt caching when switching models mid-chain.

For AI routing layers that implement their own fallback logic, this means refusal-driven fallback is now part of your normal retry path alongside timeout, quota, and provider errors.

Zero Data Retention Is Not Available

Claude Fable 5 and Claude Mythos 5 are designated Covered Models with mandatory 30-day data retention. Zero data retention (ZDR) is not available, regardless of your account or enterprise plan configuration.

If your routing policy enforces ZDR for any data-classification tier, you must exclude claude-fable-5 from routes carrying that data. This applies equally on the Claude API, Bedrock, and Vertex AI.

Bedrock and Vertex AI Model IDs

For teams routing through cloud providers:

Claude Mythos 5 is listed as limited availability on Bedrock and Vertex. Contact your AWS or Google Cloud account team for access.

What to Update Before Routing Traffic

Checklist for AI routing teams:

• Revalidate token budget assumptions — same prompts produce ~30% more tokens than pre-4.7 models.
• Handle stop_reason: "refusal" explicitly — do not silently pass empty content arrays downstream.
• Audit thinking-block logging — raw thinking text is never returned; only summarized or empty blocks.
• Configure fallback chain — use server-side fallbacks (beta) on direct Claude API, or implement client-side refusal handling on Bedrock/Vertex.
• Verify cost routing — at $10/$50 per MTok, Fable 5 is 2× Opus 4.8 and 3.3× Sonnet 4.6; ensure your cost tiers route accordingly.
• Exclude from ZDR routes — 30-day retention is mandatory; no opt-out available.

TheRouter's provider routing layer handles OpenAI-compatible requests across Anthropic, AWS Bedrock, Vertex AI, and other providers. When you route requests through a multi-provider AI gateway, the stop_reason: "refusal" response shape is treated as a non-error 200 and passed through — make sure your downstream client handles it, or configure TheRouter fallback rules to catch it before it reaches your application. See the provider routing docs for details on Claude routing configuration.

Related

• Anthropic official launch docs
• Refusals and fallback guide
• Models overview
• TheRouter provider routing docs