Claude Fable 5 in Claude Code: A Hands-On Test Against Opus 5

What is Fable 5?

Fable 5 is a coding-focused model in Anthropic's Claude 5 family, released on June 9, 2026. It shipped alongside Mythos 5, a sibling model with no safety classifiers that Anthropic offered only to a small set of vetted organizations. For a full walkthrough of the release and how Fable 5 stacks up across benchmarks, check our dedicated Fable 5 guide.

Fable 5 sits above Opus 5 in price and is aimed at the harder coding work. The main difference in feel is that it runs thinking on every request and can't turn it off, so it comes across as slower and more deliberate. Opus 5 decides for itself whether a prompt is worth the extra thinking.

Specs and pricing

The two models share a context window and a max output size. They differ on price and on how thinking works.

Fable 5 costs about twice as much per token as Opus 5. Because its thinking is always on, a single run also tends to emit more tokens, so the price gap in real use is wider than the per-token rate suggests. In the head-to-head build later in this guide, Fable emitted 74% more output tokens than Opus for a smaller program.

For a deep comparison including benchmark differences, read our Claude Opus 5 vs Claude Fable 5 guide.

The refusal behavior you have to code for

One universally annoying aspect of Fable 5 is its built-in safety classifier. Since the model is deemed too powerful, the classifier doesn't let it handle requests that are even a tiny bit related to fields like biology or cybersecurity.

For one immunologist, the word "cancer" alone tripped a biosecurity filter, making Claude Code fall back to Opus 4.8.

I hit this myself recently on a login bug in a personal project. The flow used the Telegram Gateway API for OTP sign-in, and Fable 5 flat-out refused to touch it. Opus 5 got the job done, which is the whole problem: nothing about that bug was a security risk.

Automatic, zero-config fallback only happens inside Claude Code and the Claude apps. If you are using Fable through the API, you will get a stop_reason field in the response despite receiving a 200 success code.

The response looks like this:

{
  "stop_reason": "refusal",
  "stop_details": {
	"category": "bio",
	"explanation": "The request was declined by a safety classifier."
  }
}

So, you have to check stop_reason before you touch the response content. 

To enable server-side fallback, pass a fallbacks array (e.g. "fallbacks": [{"model": "claude-opus-4-8"}]) and send the anthropic-beta: server-side-fallback-2026-06-01 header. Set it on every request; there's no account-level switch.

Note on the fallback model

You might wonder why some sources say Fable 5 falls back to Opus 4.8 while others point to Opus 5. Both are right, because the target depends on the category and the surface. 

In Claude Code, a biology-flagged request now re-runs on Opus 5, while a cybersecurity-flagged one still re-runs on Opus 4.8. On the API, the server-side fallbacks feature currently supports Opus 4.8 only. 

The split is a timing artifact: at Fable's June launch, everything fell back to Opus 4.8, and the biology path was later re-pointed to Opus 5 once that model shipped on July 24.

The Fable 5 controversy

Fable 5 has had a rocky start, even with the safety classifier out of the question.

The silent throttle and the false refusals

Days after launch, Fortune reported that Anthropic had quietly weakened Fable 5's answers on about 0.03% of AI and ML infrastructure traffic without telling anyone.

A lot of researchers, and developers included, were furious because they expected a workhorse of a frontier model that can tackle any task when they are paying the $200 subscription for it.

Anthropic caved in to the community pressure within a day, saying it "made the wrong tradeoff." What it changed was the visibility, not the throttle. Flagged requests now surface the same way a refusal does, and the degradation itself stayed. Anthropic's reasoning is that its terms already prohibit using Claude to build competing AI systems, which is defensible. Doing it silently for a month was not.

The export-control suspension

Then came the bigger one. A disclosed jailbreak triggered a Commerce export-control order on June 12, and Anthropic pulled both Fable 5 and Mythos 5 offline worldwide for 19 days.

Anthropic pushed back hard on the recall the whole time. It argued the jailbreak was narrow rather than universal, and findable by weaker models too, so the recall standard looked opaque from where it sat. It had a fair point about the bar itself. Nobody has ever built a universal jailbreak, and no model today clears that standard. The UK AI Safety Institute has reported progress toward one, but nothing that actually works.

It had a fair point about the bar itself, though not the way it framed it. Universal jailbreaks do exist: the UK AI Security Institute reports finding them for every frontier system it has tested, and its red-teamers built one against Fable 5 itself, single-turn within hours and extended to multiturn agentic workflows within days, per Fable 5's model card.

What's genuinely contested is whether that bar should trigger a recall, not whether such jailbreaks are possible.

Restoration, with new limits

Anthropic shipped a stronger classifier and reported a block rate above 99%, and on the strength of that, Commerce lifted the controls around June 30.

General access returned on July 1, but on tighter terms. The promised two-week unrestricted window shrank to about one, and a new 50% weekly cap meant that once you crossed it, more Fable 5 usage was billed as credits at the full $10 and $50 rate. That was enough to get subscribers grumbling on Reddit.

Anthropic extended the deadline twice, then split the policy by plan on July 20: Max and Team Premium keep Fable 5 at 50% of weekly limits with no end date, while Pro and Team Standard get a one-time $100 credit and pay the API rate after that. Mythos 5 came back to only about 100 vetted US organizations, down from a broader international program.

All of which leaves Fable 5 as a strong model wrapped in an access policy that keeps shifting month to month. Plan for the occasional false refusal, and don't count on this month's rate limits holding into the next.

Claude Fable 5 vs Opus 5 on the same project

To see how the two models behave under identical conditions, I gave each one the same job in a fresh Claude Code session. Afterward, I read the full session transcripts, the internal JSONL files, and graded both finished apps in a browser.

My first attempt at this comparison used a URL shortener. That was a mistake. Both models produced near-identical apps, all the way down to the theme and feature set, because a URL shortener has one obvious answer sitting in every model's training data. The test measured nothing.

Setting up a one-shot living ecosystem in Fable 5 and Opus 5

So I picked a task with no canonical answer: a living ecosystem simulation. Three species in a food web, agents that flock and hunt and starve, 5000 of them on screen at once, all of it deterministic from a seed. The prompt bans libraries that would handle the hard parts, so each model has to write its own spatial queries, steering, and population dynamics.

Here is the prompt both models received, word for word:

Build a living ecosystem simulation that runs in the browser, and ship it end-to-end in one shot, without asking me any questions or pausing for confirmation. Make all decisions yourself and only stop when it is fully built, tested, and pushed to GitHub.
 
Requirements:
 
- A real-time canvas simulation of an ecosystem with at least three species in a food web (for example producers, herbivores, predators). Species interact: they eat, they are eaten, they reproduce, and they die.
- Agents move with steering behaviour — flocking among their own kind, and avoidance or pursuit across species.
- Each agent has an energy budget. Moving and reproducing cost energy, eating restores it, and running out kills the agent. Population levels must emerge from these rules rather than being scripted.
- The simulation must stay stable and interactive at 5000 agents. Show a live FPS counter and a live population graph per species.
- The whole world is generated from a numeric seed. The same seed must always produce the same run.
- Controls to pause, resume, reset, reseed, and tune the key simulation parameters live while it runs.
- Implement the simulation yourself: the steering, the spatial queries, the integration, and the population dynamics. Do not use a physics engine, a flocking library, a game engine, or a charting library. Plain canvas and your own code.
- Tests covering the core simulation logic.
- A README with setup and run instructions.
 
The simulation should run in the browser and be usable by someone who has never seen it before.
 
When it is complete, create a new GitHub repository with the gh CLI (which is already installed and authenticated) and push the project to it.

The no-questions rule is the point. It shows how far each model carries a build on its own, with nobody around to catch a wrong turn. Each ran in its own empty directory with no hint that a second model had the same task.

The task also hides four objective tests inside an output that looks purely visual. 

• Neighbor search has to use a spatial index, or the frame rate dies at 5000 agents. 
• The world has to wrap or clamp correctly, or agents tunnel through walls. 
• Randomness has to run through a seeded generator, or the same seed gives a different run. 
• And the birth and death rates have to balance, or the population either flatlines at zero or explodes. 

Every one of those failures is visible on screen, which is what makes a pretty demo gradeable.

Both builds are live, so you can run this comparison yourself instead of taking my word for it. Open them side by side and reseed each one:

• Fable 5's build: ecosystem-fable-5.vercel.app (source)
• Opus 5's build: ecosystem-opus-5.vercel.app (source)

Screenshots of both are further down, in case you would rather read than click. But a fair note: the screenshots are zoomed out to fit the entire screen, so details may not be crystal clear.

Which model actually served each run

Before the results, one methodological note that matters for reading them.

Claude Code can fall back to Opus when Fable 5's safety classifier declines a request, so a run labeled Fable is not guaranteed to be all Fable. Rather than assume, I recorded the model field on every assistant event in both transcripts.

Fortunately, in my comparison, every event in the Fable run came back claude-fable-5, all 103 of them. Every event in the Opus run came back claude-opus-5, all 247. No fallback fired in either direction. The numbers below describe the models on the label.

How Fable 5 and Opus 5 worked the problem

Fable worked quietly. It ran 56 tool calls and printed 429 words of commentary across the whole build, in 2 blocks of text.

Opus worked in the open. It ran 137 tool calls, more than twice as many, and printed 4,808 words across 110 blocks. Both models revised at a similar rate once you account for volume, near 2 edits per file written.

They also split on tooling. Fable shipped plain ES modules with a python3 -m http.server start script and no node_modules at all. Opus installed Vite and Vitest and built against a real toolchain.

The build times below measure active work only. I took each run from its first assistant event to its last and subtracted any idle stretch where the session sat waiting rather than building.

Results: speed, cost, and correctness

Fable cost 43% more and produced 74% more output tokens for a smaller program. Since it can't turn off its thinking, it keeps billing even when the work doesn't need it.

Both models cleared every objective check: 

• Same seed reproduces the same world.
• Different seeds diverge.
• Nothing reaches NaN.
• No agent escapes the world at maximum speed.
• Both hold 60 FPS in the browser with zero console errors.

Opus's simulation is 2.3x faster per tick. It stores agents in typed arrays, one flat array per property, and keeps a separate spatial grid per species. Fable gives each agent its own object and shares one uniform grid across all three species. Both are correct, but Opus' is the faster data layout.

The defect Fable shipped

Fable's npm test script does not run. It shipped node --test test/, which Node 26 resolves as a module path rather than a directory, so the command dies before a single test executes. The 16 tests underneath are fine and pass when you name the files explicitly. The entry point in package.json is broken.

It's a small bug with an outsized cost, because the one command a reader will actually type is the one that fails. Fable also never caught it, which is the part that matters: the prompt asked for tests, and it verified them by a route its own users won't take.

Opus has no equivalent failure. Its 58 tests run from npm test and pass. Both suites test the things that matter here, seeded determinism, energy conservation, torus wrapping, and long-run species survival, so the gap is depth rather than kind. The one check only Opus wrote is the 5000-agent stress test, which is also the requirement most likely to break.

What the screenshots show

The two apps look nothing alike, which is the whole reason for changing the task.

Fable 5: controls on the left, agents as flat squares, species named Plants, Herbivores, and Predators.

Opus 5: controls on the right, agents as triangles that point where they are heading, species named Plankton, Grazers, and Hunters.

On the UI side of things, these are the biggest differences:

• Fable put its control panel on the left and draws every agent as a flat square, and named its species Plants, Herbivores, and Predators.
• Opus put its panel on the right and draws directional triangles, so you can read which way a flock is moving. It invented an aquatic theme and went with Plankton, Grazers, and Hunters.

Reading the population graphs

The population graphs are where the design difference gets sharp.

Fable 5's graph, linear scale. The plant line takes the full height and the predator line is pinned to the bottom.

Opus 5's graph, log scale. All three species stay readable, and the hunter line crosses the grazer line.

Both simulations oscillate the way a predator-prey system should. Fable's plants swing between 520 and 7,061 across 5 minutes while herbivores and predators cycle behind them, predators peaking at 248 exactly as herbivores bottom out at 119.

On a linear scale, the plant line eats the whole vertical range, herbivores compress to a thin band, and predators sit flat against the axis.

That is why Opus put its graph on a log scale and labeled the peak. All three species stay legible, and you can watch the hunter line rise, cross the grazer line, and fall as grazers recover. Same class of data, and only one of the two charts is readable.

How the two ecosystems behave

The underlying ecosystems differ, too. Opus caps its producer layer at 4,229 plankton, so that population pins to the ceiling and only the upper two species cycle. Fable leaves all three coupled, which gives wider swings and a livelier world. We got stability against dynamism without asking for it in the prompt.

Fable 5's parameter panel: 13 sliders in the simulation's own units.

Opus 5's parameter panel: 9 sliders, each a multiplier starting at 1.00, grouped into World and Behaviour.

Fable exposes 13 parameters in real units: plant growth 5, perception radius 60, separation 1.5, and per-species metabolism. Opus exposes 9, all normalized multipliers starting at 1.00, split into World and Behaviour groups. 

In one sentence: Fable gives you more control, while Opus gives you a panel that won't allow you to easily break the ecosystem balance.

Should You Choose Fable 5 or Opus 5?

Use Opus 5 as the default. On this build, it cost 30% less, ran a simulation 2.3x faster, and wrote better test coverage. Fable won on speed, finishing in about half the time.

Go to Fable 5 when you want a build finished in one pass with minimal supervision, or when the dependency footprint matters. Fable shipped a zero-dependency program 42% smaller than the alternative, and it got there in 103 assistant turns against 247. That terseness has real value on a task you plan to read yourself afterward.

Final Thoughts

Two builds of one project type still isn't a benchmark. Real-world performance can vary greatly despite what existing benchmarks say.

For example, even though our comparison showed Fable using more tokens than Opus, most developers are sharing the reverse: Opus 5 burning far more tokens than either Fable or Sol on similar tasks. The suspicion is that Opus 5's RL pre-training made it too optimized for racking up token costs instead of being helpful while concise. Outside the comparison, I've certainly felt this in my own work. Opus family models are becoming increasingly more verbose on the surface and harder to read.

Personally, I will keep using Fable 5 for almost all my coding projects, including for clients, as it wins in accuracy in the long run. I am on the latest Max plan, and I am yet to hit my usage limits, even when using Fable in multiple sessions (though I don't run Claude Code non-stop). I will use Opus when the token bill matters, or when I want a running commentary on the ongoing task for my own understanding.

For more on the models and the tooling around them, I recommend reading our full Claude Fable 5 guide, along with tutorials on Claude Code and Claude Code best practices.