Claude Fable 5 and Mythos 5: What the New Models Change, and How They Perform

Anthropic has quietly redrawn the top of its model lineup. Claude Fable 5 is now the most capable model the company has released to a general audience, sitting above the Opus 4.x family for the most demanding reasoning and long-horizon agentic work. Alongside it, Claude Mythos 5 ships the same engine — identical capabilities, pricing, and API behavior — but only through Project Glasswing, where it succeeds the invitation-only Mythos Preview. If you have been building on Opus, this is the first release in a while where the migration is less about swapping a model string and more about rethinking how you talk to the model.

I want to walk through what genuinely changed, because a lot of the differences are not cosmetic. Some of them will break code that worked fine on Opus, and a few of them quietly improve results if you stop fighting the model's defaults.

One model, two names

The simplest thing to get straight first: Fable 5 and Mythos 5 are the same model behind two IDs. claude-fable-5 is the general-availability route; claude-mythos-5 is reachable only if your organization participates in Project Glasswing, where it replaces the older claude-mythos-preview. Everything below applies to both — context window, output limits, pricing, and the behavioral shifts. Unless you are specifically in Glasswing, the model you want is Fable 5.

Both run a 1M-token context window, which is also the default rather than an opt-in, and emit up to 128K output tokens per request. Pricing lands above Opus tier — $10 per million input tokens and $50 per million output — so this is not the model you reach for to summarize a support ticket. It is the model you reach for when the task is hard enough that a cheaper model would fail it.

Thinking is always on now

This is the change most likely to surprise people coming from Opus. On Fable 5, extended thinking is no longer something you configure — it is always active. The old thinking parameter is essentially gone: passing {"type": "enabled", "budget_tokens": N} returns a 400, and even an explicit {"type": "disabled"} is rejected. You simply omit the field entirely. Depth is controlled instead through output_config.effort, which spans low through high, xhigh, and max.

The raw chain of thought is never returned, which is a deliberate design choice. What you get back are regular thinking blocks: with display: "summarized" you receive a readable summary of the reasoning, and the default "omitted" leaves the field empty. If your product streams reasoning to users, that default looks like a long pause before output — so set the display mode explicitly.

The other parameters people lean on are also gone. Sampling controls — temperature, top_p, top_k — all return errors, and assistant-message prefills are not supported. Anthropic's guidance is blunt about this: steer the model through prompting, not knobs.

Refusals, fallbacks, and a retention requirement

Fable 5 runs safety classifiers on incoming requests, and a declined request comes back as a successful HTTP 200 with stop_reason: "refusal" rather than an error. That matters for code hygiene — if you read response.content[0] without checking the stop reason first, a refused request will crash on an empty array. The recommended pattern is to opt into server-side fallbacks so a refusal is transparently re-served by a fallback model inside the same call:

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

if response.stop_reason == "refusal":
    handle_refusal()
else:
    print(response.content[0].text)

One operational footgun worth flagging: Fable 5 requires 30-day data retention and is not available under zero data retention. If a migration suddenly starts throwing 400 invalid_request_error on every request with no obvious payload problem, check your organization's retention configuration before debugging the request body. On the upside, the tokenizer is identical to Opus 4.8, so token counts are roughly unchanged when you move from Opus 4.7 or 4.8 — only the per-token price differs.

What the performance actually feels like

The headline gains are not in the benchmarks you already know how to read. They are in work that sits above what previous models could reliably do: long autonomous runs that complete without human correction, first-shot implementations of well-specified systems, end-to-end enterprise deliverables like financial models and slide decks, and durable coordination across parallel sub-agents. Anthropic explicitly trained it to use bash and crop tools to handle flipped, blurry, or noisy images, and it reliably sustains communication with long-running sub-agents rather than spawning and blocking.

The teams with the best early results gave Fable 5 their hardest unsolved problems first — not the tasks previous models already handled.

Two practical notes change how you should use it. First, individual requests on hard tasks can run for many minutes at higher effort — a 15-minute single request is normal when the task involves gathering context, building, and self-verifying. Plan your timeouts, streaming, and progress UX around that, and structure work so callers check in asynchronously instead of blocking inside one call. Second, lower effort settings still perform remarkably well — often exceeding the xhigh or even max output of previous models — so the instinct to crank effort to the ceiling is usually wrong. Start at high, sweep down to medium and low for routine work, and reserve max for the genuinely hardest cases.

There is a softer lesson buried in the migration notes that I think is the most important one: prompts and skills written for earlier models are often too prescriptive for Fable 5, and that over-specification actively reduces output quality. The model is good enough now that enumerating every step gets in its way. State the goal and the constraints, give it the reason behind the request, and let it plan. The shift from Opus to Fable 5 is partly an API migration, but mostly it is learning to trust a more capable model with less hand-holding.