Claude Fable 5: field notes and integration gotchas

Anthropic shipped a new model this week, and its API does something no previous Claude could: decline your request with a perfectly successful response. HTTP 200, stop_reason: "refusal", empty content. Opt into the new fallback system and it gets stranger still: the answer comes back from a different model than the one you named. The benchmarks got the headlines, but if you build on the Claude API, this is the part that changes your integration.

The model is Claude Fable 5. I switched my own coding setup to it on launch day and spent the evening in the API docs working out what actually moved. Here’s what I found.

What Fable 5 is

Anthropic trained a frontier model in its Mythos line and decided parts of it were too risky to ship raw. So the release is split in two. Claude Mythos 5, the same model with the safeguards lifted in some areas, goes to approved cyberdefenders and infrastructure providers under “Project Glasswing”. Claude Fable 5 has safety classifiers in front, and that’s the one the rest of us get.

The capability jump is real, with the caveat that most of the numbers are Anthropic’s own: they report 80.3% on SWE-bench Pro against GPT-5.5’s 58.6%, and Cognition independently put it at the top of their FrontierCode eval, a result Anthropic says it managed at medium effort. Stripe says it ran a migration across their 50-million-line Ruby codebase in a day that would have taken a team more than two months by hand, and Ethan Mollick reports a 9.5-hour unbroken autonomous run. The pattern across all of it: the longer and messier the task, the bigger the lead. For balance, METR’s independent evaluation judged it likely still unable to reliably automate multi-week R&D projects, so the “days of work” stories have a ceiling.

Pricing is $10 per million input tokens and $50 per million output, half that on the batch API. Context is 1M tokens by default, with up to 128k output tokens per request. On Pro, Max, Team, and seat-based Enterprise plans it’s included at no extra cost through June 22; from June 23 it needs usage credits.

The fallback system is the real story

Fable 5 runs safety classifiers over requests in three areas: offensive cybersecurity, biology and life sciences, and attempts to extract its internal reasoning. In the Claude apps, a flagged query is answered by Opus 4.8 automatically. On the API, you see the mechanism: a normal HTTP 200 with stop_reason: "refusal" and no content:

{
  "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 }
}

Anthropic’s headline number is that fewer than 5% of sessions hit this. The system card tells a sharper story for our profession: on Terminal-Bench agentic runs, a third-party read of the card found 20.9% of trials hit a safety refusal and fell back mid-trajectory. One pre-launch tester on HN put it plainly: the classifiers are “super aggressive and sensitive… for very benign, non-security coding tasks”. If your work so much as smells of security or the life sciences, expect friction.

The remedy is the new fallbacks parameter (beta), which retries the request on Opus 4.8 server-side and returns one response:

from anthropic import Anthropic

client = Anthropic()

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

# A fallback_message entry in usage.iterations means a fallback model ran;
# stop_reason stays "refusal" only if every model in the chain declined too.
served_by_fallback = any(
    i.type == "fallback_message" for i in response.usage.iterations or []
) and response.stop_reason != "refusal"

Six things in the docs that will catch integrators off guard:

Your monitoring can’t see refusals. A refusal is an HTTP 200, so any dashboard built on error rates is blind to it. Emit one event per refusal and one per fallback-served response, and alert on the gap between the counts. I wrote about treating agent output as untrusted in Guardrails over trust; this is the same principle one layer down.
Sub-agents don’t inherit fallbacks. The parameter doesn’t propagate into model calls made inside tool execution. Every request path needs its own, including retry handlers and background workers, which are exactly the paths most likely to need it.
Your fallback model needs rate-limit headroom. If Opus 4.8 is rate-limited when the retry fires, the attempt simply isn’t made and you get the refusal back, with stop_details.recommended_model naming a model to retry directly. Size the fallback model’s limits for the refusal volume you expect, or the safety net degrades exactly when it’s load-bearing.
Sticky routing will confuse your evals. Once a conversation falls back, later requests that include fallbacks can be served by the fallback model directly, without trying Fable 5 first. The decision lives for about an hour, keyed on a content hash of the conversation prefix, scoped to your organisation. It’s also best-effort, so the requested model can still reappear at any time. Currently non-streaming requests only. If the model field looks wrong in an eval, check this before filing a bug.
Mid-stream refusals behave differently with and without fallbacks. Without them, a refusal can cut a stream mid-output; treat the partial output as incomplete and discard it. With server-side fallback on a stream, nothing is discarded: a fallback content block marks the boundary and Opus 4.8 continues from where Fable 5 stopped. On a non-streaming request the fallback model instead answers from scratch.
Flagged requests pay the declined attempt in latency. On a pre-output decline, message_start waits for the fallback attempt to begin, so time-to-first-byte includes the failed hop. Budget for it on user-facing paths.

Billing is more nuanced than “refusals are free”: a refusal before any output costs nothing and doesn’t count against rate limits, but a mid-stream refusal bills the input and everything already streamed, at $50 per million output tokens. The retry is softened by fallback credit, which reprices the fallback’s input at cache-read rates; server-side it’s automatic, and if you roll your own retry you redeem a credit token within five minutes with a byte-identical request body.

One platform caveat before you design around fallbacks: it exists only on the Claude API and Claude Platform on AWS, and it’s rejected on the Batch API. On Bedrock, Vertex AI, and Microsoft Foundry you use the SDK’s refusal-fallback middleware instead (BetaRefusalFallbackMiddleware in Python, with equivalents in TypeScript, Go, Java, and C#). You configure one or the other, never both. There’s no deterministic test trigger in the docs either, so before trusting your pipeline, send a staging request that plausibly trips the cyber classifier and assert that your refusal event fires and served_by_fallback flips true.

Your timeouts are now wrong

The docs say it plainly: individual requests on hard tasks “can run for many minutes” at higher effort, and autonomous runs can extend for hours. If your HTTP client has a 60-second timeout, Fable 5 will blow through it on the exact tasks it’s best at. Streaming stops being optional, and anything that blocks on a response wants restructuring into a check-back-later shape.

Related: the raw chain of thought is never returned, and thinking.display defaults to "omitted", so thinking blocks arrive with an empty thinking field. If you stream responses to users, the default experience is now a long, silent pause before output starts. Set display: "summarized" to get readable progress back.

Migrate by deleting prompts

Anthropic’s guidance on refactoring existing prompts and skills is blunt: material written for prior models is often “too prescriptive for Claude Fable 5 and can degrade output quality”. Years of accumulated prompt engineering, all those carefully enumerated edge cases, can now be dead weight. The recommended migration is to remove instructions and check whether the defaults are better. I have a system-prompt file I’ve been growing for over a year; the first deletion candidates are a fourteen-rule communication digest and a mandatory tool-order list the model now mostly gets right on its own. I haven’t fully forgiven them.

Three specific prompt-level traps from the docs:

“Show your thinking” is now a liability. One of the three refusal categories is reasoning_extraction: prompts that ask the model to echo or explain its internal reasoning in the response can trigger it. Follow the chain: a reflection instruction fires the classifier, the request silently falls back, and a weaker model answers. That’s a quality regression no log line will ever show you. “Think step by step and show your work” has been the most common prompt pattern of the last three years. Audit your prompt library for it before migrating.

Hide token counters from the model. If your harness shows Fable 5 a remaining-context countdown, it can start wrapping up early, summarising its own work, or suggesting a new session. The model gets context anxiety. Hide the counter, or reassure it: “You have ample context remaining. Do not stop, summarize, or suggest a new session on account of context limits. Continue the work.”

The anti-fabrication instruction actually works. For long autonomous runs, Anthropic reports this snippet “nearly eliminated fabricated status reports even on tasks designed to elicit them”:

Before reporting progress, audit each claim against a tool result from this
session. Only report work you can point to evidence for; if something is not
yet verified, say so explicitly. Report outcomes faithfully: if tests fail,
say so with the output; if a step was skipped, say that; when something is
done and verified, state it plainly without hedging.

The system card shows why this matters: on failing sessions, Fable 5 writes a dishonest summary slightly more often than Opus 4.8 (4.6% against 3.7%, per the same third-party read). More capable does not mean more honest about failure. It’s the same lesson as making agents show receipts instead of vibes.

Effort is the only knob left

You can’t disable thinking on Fable 5; adaptive thinking is always on. The effort parameter, which runs from low up to xhigh and max, is therefore your entire cost-quality lever. The docs recommend high as the default, xhigh for capability-sensitive work, and medium or low for routine tasks.

The spread is bigger than those labels suggest. Simon Willison ran an identical small prompt at both ends and got 1,929 output tokens at low against 14,430 at max, roughly 7.5× the spend for one knob turn. In the other direction, that FrontierCode result above was at medium effort, and the HN tester quoted earlier reported “better results with about half the tokens, making it cost the ~same as Opus 4.8 price-wise”. Routine work at medium may get you frontier output at last-generation prices.

Two tools for tuning it: the new usage.output_tokens_details.thinking_tokens field tells you how much of your bill went to invisible reasoning, and thinking is steerable per-message in plain text: appending “Please think hard before responding.” encourages it on that turn, and “Answer directly without deliberating.” suppresses it. No parameter change needed.

If you live in Claude Code

Five things specific to the CLI. When you first switch to Fable 5, Claude Code applies the model’s default effort (high) even if you’d set a different level for your previous model, so run /effort after switching. The thinking toggles you may have relied on, like alwaysThinkingEnabled or MAX_THINKING_TOKENS=0, have no effect on Fable 5 at all. /fast mode is currently Opus-only, so switching to Fable 5 means giving it up. If your first request in a repo falls back mysteriously, try claude --safe-mode: a security-flavoured CLAUDE.md or repo can trip the cyber classifier on workspace context alone, before you’ve asked anything. And a fallback is sticky here too: after one fires, the session carries on with Opus until you run /model fable yourself.

One economics note: subscription weekly caps were not raised for Fable 5, and its always-on thinking counts against them; Max-plan users are already reporting hitting weekly limits mid-week. The free window and the cap are separate budgets; the window ends June 22, the cap can bite sooner.

Smaller things worth knowing

Give it a memory file. Fable 5 is notably good at recording lessons from previous runs and using them. A Markdown file of one-lesson-per-note is enough; the docs even suggest having it bootstrap the file by reviewing your past sessions.
Verify with fresh eyes. For long builds, Anthropic recommends separate, fresh-context verifier subagents over self-critique. The model checking its own work in the same context is the weaker pattern.
Give the reason, not just the request. It tends to perform better when told why you’re asking. “I’m working on X for Y, they need Z, with that in mind:” is cheap context with real returns.
Deep into long sessions it occasionally announces an action without doing it. “I’ll now run X”, then silence. A plain “go ahead and do it end to end” unsticks it.
Prompt caching got cheaper to enter. The minimum cacheable prefix dropped to 512 tokens on Fable 5, down from 1,024 on Opus 4.8, so prompts previously too short to cache now cache with no code change.
No zero-data-retention. Fable 5 is a “Covered Model”: 30-day data retention, not available under ZDR agreements. In GitHub Copilot it’s off by default for Business and Enterprise until an admin enables it. Check before wiring it into anything regulated.

When not to bother

For routine, high-volume work, GPT-5.5 at $5/$30 or Opus 4.8 at $5/$25 are cheaper and entirely adequate. For chat-shaped workloads the same HN tester “didn’t really notice a difference vs 4.8”. And the meter runs fast: Simon Willison’s first day of testing clocked $82.92 in API-priced tokens, covered by his subscription for now; from June 23 that same day costs real credits. Fable 5 earns its price on long, ambiguous work with heavy tool use, the kind you’d previously have broken into pieces because no model could hold it together.

So test it on exactly that. Anthropic says testing only simple workloads “tends to undersell its capability range”. Pick the task you shelved as impossible and hand it over whole.

The migration checklist

The condensed version, for the bookmark:

Add fallbacks (or the SDK middleware on Bedrock/Vertex/Foundry) to every request path, including sub-agents, retries, and background workers.
Emit a metric per refusal and per fallback-served response; alert on the gap.
Test the refusal path in staging before trusting it; there’s no built-in trigger.
Raise client timeouts and move long tasks to streaming or async check-ins.
Set thinking: {display: "summarized"} if users watch responses arrive.
Audit prompts for “show your reasoning” instructions (reasoning_extraction risk).
Remove prescriptive instructions; test whether defaults beat your old scaffolding.
Hide remaining-context counters from the model, or add the reassurance line.
Add the anti-fabrication snippet to long-running agent prompts.
Re-tune effort per task type; watch thinking_tokens to see where the money goes.
Confirm 30-day retention is acceptable; ZDR is off the table.

Comments & Reactions

Got a thought, a war story, or a “well, actually”? Sign in with GitHub and jump in.

Loading comments…