Claude Fable 5.2 vs Opus 5.5 for C#: 6 Real Tasks, Measured

Byadmin

Last updated November 10, 2026 · Claude Code 2.1.322 (claude-fable-5-2, effort high and medium) vs Claude Code 2.1.319 (claude-opus-5-5, effort medium) · .NET SDK 10.0.401 · Windows 11

Short answer: on six real C#/.NET 10 tasks in Claude Code, Fable 5.2 wrote better code than Opus 5.5 where it mattered, and cost two to three times as much per task. I ran the same tasks I used for the Claude Code CLAUDE.md test on November 8: 24 runs on Fable 5.2 at High effort, 12 at Medium, against the 24 Opus 5.5 runs from that test. My review found no bugs in any of the 36 Fable runs. Opus 5.5 had 5 in 24. The biggest one was a circuit breaker that failed 142 of 200 requests under load in all four Opus runs of that task. All six Fable versions of that task answered 194 to 198 of 200. Cost per run, at the list price Claude Code reports, was $0.23 median for Opus, $0.46 for Fable at Medium and $0.72 for Fable at High.

Fable 5.2 also brought one new problem. It likes to wait and watch: in 3 of 4 caching runs at High effort it decided to wait a minute to see a cache entry expire, and the headless session ended in the middle of that wait, with the server still running. One run said nothing was left running when three processes were.

If you write C# with Claude Code: use Opus 5.5 for routine work and switch to Fable 5.2 at Medium when a task has a policy decision in it (retries, timeouts, caching, background work). That’s where it was clearly better here. Neither model fixed the two .NET 10 errors both of them hit first, so you still need to run the result yourself.

What’s New in Claude Fable 5.2

Anthropic released Claude Fable 5.2 on November 9, 2026 (announcement). The facts that matter for this test, from the models overview and the release notes:

Claude Fable 5.2Claude Fable 5.1Claude Opus 5.5
Model IDclaude-fable-5-2claude-fable-5-1claude-opus-5-5
Price per million tokens (input / output)$8 / $40$10 / $50$4 / $20
Default effort (API)highhighmedium
Context / max output1M / 128K1M / 128K1M / 128K

So Fable 5.2 is 20% cheaper than Fable 5.1 but still twice the per-token price of Opus 5.5. Anthropic says it writes output up to 30% faster than Fable 5.1, uses fewer tokens at Medium effort (the default in Claude apps and Claude Code), and at High effort roughly matches Opus 5.5 at Max effort on its FrontierCode 2.0 benchmark at about half the cost per task. That last claim is Opus at Max. My Opus runs were at Medium, so this test checks a different question: what you get for the money at the settings people actually use.

If you call the API directly, three breaking changes come with 5.2: the thinking-block prefix check is enforced for every account (edit an earlier message or the tools and send back a later thinking block, and you get a 400), computer use needs computer_toolset_20260801, and a Fable 5.2 executor only accepts Fable 5.2 or Mythos 5.2 as its advisor. None of that affects Claude Code users.

How I Tested It

The same six tasks as the CLAUDE.md test, each in a fresh copy of a small starting project:

  1. xUnit v3 tests for an OrderPricing class with three planted bugs. The prompt says not to change the class.
  2. An EF Core 10 + SQLite query (top 5 customers in 30 days) that must translate to one SQL statement.
  3. Fix a minimal API that doesn’t build.
  4. A background job that expires unpaid orders every few seconds.
  5. HTTP resilience: call a flaky forecast service with retries, and don’t let a slow upstream hang the endpoint.
  6. Caching for a slow product repository.

Two conditions, two runs each: A is the prompt only, B adds the same 30-line CLAUDE.md as before (versions, test runner, “run it”, “stop what you start”, “list the policy choices you made”). Every run used the same headless command, with only the model and effort changed:

    "--output-format", "stream-json", "--verbose",
    "--setting-sources", "project", "--strict-mcp-config", "--disable-slash-commands",
    "--no-session-persistence", "--permission-mode", "acceptEdits", "--max-budget-usd", "3",
    "--model", os.environ.get("CC_MODEL", "claude-opus-5-5"), "--effort", os.environ.get("CC_EFFORT", "medium"),

After each run I built and ran the final code myself: dotnet test for task 1, the generated SQL and the totals for task 2, HTTP calls against the API for tasks 3, 4 and 6, and for task 5 a 200-request load test against a fresh flaky stub. I read every diff for bugs.

What isn’t equal: the Opus runs are from November 8 on Claude Code 2.1.319, the Fable runs are from today on 2.1.322. Fable at Medium ran prompt-only (A) only, and 8 of those 12 runs overlapped with other runs on the same machine, so their times are a little high. Costs are the list price Claude Code reports in its result (total_cost_usd); I ran on a subscription, so I didn’t pay these amounts.

Results: Fable 5.2 vs Opus 5.5

Opus 5.5 Medium
prompt only		Opus 5.5 Medium
+ CLAUDE.md		Fable 5.2 High
prompt only		Fable 5.2 High
+ CLAUDE.md		Fable 5.2 Medium
prompt only
Runs1212121212
Bugs found in my review23000
Resilience task: OK under 200-request load0 of 20 of 22 of 22 of 22 of 2
Runs with no failed dotnet command9108119
Left a process running30211
Listed its policy choices0120110
Median turns1415192014
Median time per run82 s78 s108 s108 s80 s
Median cost per run$0.23$0.22$0.72$0.74$0.46
Total cost, 12 runs$3.06$2.80$8.50$9.31$5.71

Fable 5.2 at Medium took the same number of turns and about the same time as Opus 5.5, wrote 9% more output tokens over the 12 prompt-only runs (69,080 vs 63,641), and cost 1.9 times as much. Most of the cost difference is the per-token price, not extra work. High effort added about five turns per run and another 50% on top.

Per task, prompt only, average cost per run:

TaskOpus 5.5 MediumFable 5.2 MediumFable 5.2 High
1. xUnit v3 tests$0.28$0.67$0.79
2. EF Core query$0.22$0.42$0.72
3. Fix the API$0.15$0.25$0.33
4. Background job$0.23$0.42$0.50
5. HTTP resilience$0.42$0.66$1.14
6. Caching$0.23$0.43$0.76

On tasks 1 to 4 and 6, both models ended with working code in every run. Task 2 gave the right totals (Litware 921.96) in one SQL statement every time, task 4 had exactly the expected order statuses after 15 seconds every time, and both models picked IServiceScopeFactory, PeriodicTimer and ExecuteUpdate for the background job on their own. On those tasks, the extra money bought nothing I could measure. Task 5 is where the models differed.

The Resilience Task: Where Fable 5.2 Earned Its Price

The forecast stub fails about one request in three and makes some requests very slow. Every Opus 5.5 run used the standard resilience handler, set the retry and timeouts, and kept the default circuit breaker:

    .AddStandardResilienceHandler(o =>
    {
        // A single attempt that takes longer than this is abandoned and retried.
        o.AttemptTimeout.Timeout = TimeSpan.FromSeconds(2);

        o.Retry.MaxRetryAttempts = 3;
        o.Retry.BackoffType = DelayBackoffType.Exponential;
        o.Retry.UseJitter = true;
        o.Retry.Delay = TimeSpan.FromMilliseconds(200);

        // Hard ceiling for the whole call including all retries: our endpoint never waits longer.
        o.TotalRequestTimeout.Timeout = TimeSpan.FromSeconds(8);

Each run tested itself with about ten requests, one at a time, and passed. Under 200 requests, 8 at a time, the default breaker opened, because so many individual attempts fail here, and most callers got a fast 503:

# t5-resilience_A_r1: 200 requests to /weather/london, 8 concurrent, fresh FlakyForecast
elapsed 6.1s  status codes: {200: 58, 503: 142}
first non-200 at request #35

The two Fable 5.2 runs with a CLAUDE.md also used the standard handler, but changed the breaker, and one of them wrote down why:

        // The upstream fails a large share of requests even when healthy, so the default 10% threshold
        // would keep the circuit open under load. Only break when it is mostly down.
        options.CircuitBreaker.FailureRatio = 0.8;
        options.CircuitBreaker.MinimumThroughput = 20;
        options.CircuitBreaker.SamplingDuration = TimeSpan.FromSeconds(30);
        options.CircuitBreaker.BreakDuration = TimeSpan.FromSeconds(5);

The other set the same values from appsettings.json with a ratio of 0.9, and both put the breaker settings in their list of policy choices. Same load test:

# t5-resilience_B_r2: 200 requests to /weather/london, 8 concurrent, fresh FlakyForecast
elapsed 21.9s  status codes: {200: 197, 502: 1, 504: 2}

All four prompt-only Fable runs, at both efforts, went the other way. They built their own pipeline with no circuit breaker at all: a total timeout, three retries and a 2-second timeout per attempt.

    .AddResilienceHandler("forecast", pipeline =>
    {
        // Outermost: hard cap on the whole operation, retries and backoff included.
        pipeline.AddTimeout(TimeSpan.FromSeconds(10));

        // Retries 5xx, 408, 429, connection failures and per-attempt timeouts.
        // Safe here because the upstream call is an idempotent GET.
        pipeline.AddRetry(new HttpRetryStrategyOptions
        {
            MaxRetryAttempts = 3,
            Delay = TimeSpan.FromMilliseconds(200),
            BackoffType = DelayBackoffType.Exponential,
            UseJitter = true,
        });

        // Innermost: each individual attempt is abandoned after 2 s so a slow
        // response is retried instead of being waited on.
        pipeline.AddTimeout(TimeSpan.FromSeconds(2));

That answered 194 to 198 of 200 under load. The price is the “upstream is down” case: with the stub stopped, a request took 6 to 9 seconds to fail with a 504, where a breaker would answer in milliseconds once it’s open. The prompt didn’t ask for a breaker, so leaving it out is a fair reading of the task, but none of the four runs said they had left it out. If you want the breaker, ask for it.

Fable also added an HttpClient.Timeout as a backstop in 5 of its 6 versions, and four of them say why in a comment: the pipeline ends when the response headers arrive, so a slow response body isn’t covered. None of the Opus versions set one.

The Same Two .NET 10 Errors as Opus

The extra capability didn’t help with the two errors that come from .NET 10 itself. Without a CLAUDE.md, Fable 5.2’s first dotnet test on the xUnit v3 project failed in both High runs and one Medium run, the same way Opus’s did:

C:\Users\rajni\.nuget\packages\microsoft.testing.platform.msbuild\2.5.2\buildMultiTargeting\Microsoft.Testing.Platform.MSBuild.targets(395,5): error : Testing with VSTest target is no longer supported by Microsoft.Testing.Platform on .NET 10 SDK and later. If you use dotnet test, you should opt-in t

Each time it fixed it by adding a global.json with the Microsoft.Testing.Platform runner. With the CLAUDE.md, which names the runner, it didn’t happen (0 of 2). The EF Core query failed to translate on its first run in 3 of 4 High runs (Opus: 2 of 4):

     })' could not be translated. Additional information: Translation of 'Select' which contains grouping parameter without composition is not supported. Either rewrite the query in a form that can be translated, or switch to client evaluation explicitly by inserting a call to 'AsEnumerable', 'AsAsyncEnumerable', 'ToList', or 'ToListAsync'. See https://go.microsoft.com/fwlink/?linkid=2101038 for m

Every run then rewrote the query until it translated, and every final version kept money as decimal. (One Opus run had switched to double.) Neither Medium run hit the translation error. One of them hit a C# gotcha instead: it named a variable from and used it inside LINQ query syntax. I reproduced it:

var asOf = new DateTime(2026, 11, 10);
var from = asOf.AddDays(-30);
DateTime[] placed = [new(2026, 10, 18), new(2026, 9, 1)];

var recent = from d in placed
             where d >= from && d < asOf
             select d;
error CS1525: Invalid expression term '&&'

Inside a query expression, from starts a new from clause, so the compiler stops reading it as your variable. Rename it (since) and it prints 1. Fable renamed it to windowStart on the next try.

The New Failure: Waiting for Something After the Session Ends

On the caching task, all four Fable 5.2 runs at High wanted to prove that the cache entry expires, not only that the second call is fast. That’s a good instinct. In three of them it started the API in the background, scheduled a wait of about a minute, and ended its turn. In headless mode (claude -p), the end of the turn is the end of the session, so the check never happened and the server kept running. These are the complete final messages of two of those runs:

Speedup confirmed (≈500 ms → ≈2 ms). Waiting about a minute to confirm the cached entry really expires and reloads.
Waiting about a minute for the cache entry to expire, then I'll time product 1 again and stop the server.

The second one had the CLAUDE.md that says “Never leave a server running”. It meant to stop it. It just didn’t get the turn. That’s 3 of 4 High caching runs with a server left up. Opus 5.5 never tried to wait out a cache entry, and with the CLAUDE.md it left nothing running in 12 of 12 runs.

The other leftover was worse because the report was wrong. A Medium resilience run finished with “the three processes are no longer running, so there is nothing to stop by hand”. Eight seconds later my harness found FlakyForecast.exe and two Weather.Api.exe processes still running. Most likely the shells Claude Code started had exited, but the apps they launched hadn’t. In an interactive session you’d probably catch both problems. In CI or a scripted run, kill the process tree yourself after the agent finishes, and don’t trust its “nothing left running”.

Fable 5.2 vs Opus 5.5: Which One for C#?

  • Routine C# work (tests, a query, a bug fix, a hosted service): Opus 5.5. Both models got every one of these right, and Opus cost half as much at Medium.
  • Tasks with a policy decision in them (resilience, caching, timeouts, anything that only fails under load): Fable 5.2 at Medium. It noticed the upstream’s failure rate and tuned for it. Opus kept a default that failed 70% of requests under load in all four of its runs.
  • Fable 5.2 at High: in this test it cost about 50% more than Medium, took longer, and was no more correct: the Medium runs had no bugs either. Keep High for problems where Medium visibly struggles.
  • Either model: keep a CLAUDE.md with the test runner and “stop what you start”, ask it to list its policy choices, and load-test anything with retries before you trust it.

To try it in Claude Code, pass the model and effort the same way I did, or pick Fable 5.2 with /model in an interactive session:

claude --model claude-fable-5-2 --effort medium

Anthropic says plans that include Fable get up to 50% of their weekly usage limit on Fable for Pro and standard Team seats as a launch promotion. Check your own plan’s limits before switching a whole team over.

What I Didn’t Test

  • Fable 5.1. I compared against Opus 5.5 because that’s the default for most people. The 5.1 vs 5.2 numbers in this post are Anthropic’s, not mine.
  • Opus 5.5 at High or Max. Anthropic’s “half the cost” claim compares Fable 5.2 High with Opus 5.5 Max. I compared both at the levels Claude Code users get by default.
  • Large codebases and long sessions. These are small, single-project tasks of one to four minutes. Fable is sold for long-horizon work, and this test doesn’t measure that.
  • Fast mode ($16 / $80 per million tokens) and the API changes for direct callers.
  • Two runs per condition is a small sample. The resilience result (0 of 4 vs 6 of 6 under load) and the cost ratio are clear. Differences of one or two failed commands are noise.

FAQ

Is Claude Fable 5.2 better than Opus 5.5 for coding? In my C# test it was better on the one task that needed judgment (HTTP resilience under load) and equal on the other five. My review found 0 bugs in 36 Fable runs and 5 in 24 Opus runs. It cost 1.9 times as much at Medium effort and about 3 times as much at High.

How much does Fable 5.2 cost? $8 per million input tokens and $40 per million output tokens on the API, down from $10 / $50 for Fable 5.1. Opus 5.5 is $4 / $20. In Claude Code my runs cost a median of $0.46 at Medium and $0.72 at High, against $0.23 for Opus 5.5.

Which effort should I use with Fable 5.2 in Claude Code? Medium, which is also Claude Code’s default for Fable 5.2. High added about five turns and about 50% to the cost per run here, with no better results.

What’s the model ID? claude-fable-5-2, the same on the Claude API, Bedrock (with the anthropic. prefix), Google Cloud and Microsoft Foundry.

Related: Claude Code for C# and .NET: does a CLAUDE.md help? · Best AI tools for C# coding · HttpClient and IHttpClientFactory in .NET 10 · TDD with xUnit v3

This article is part of the AI in .NET guide (LLMs, agents, RAG, ML.NET and AI coding tools).

Similar Posts

One Comment

  1. Pingback: Claude Code for C# and .NET: Does a CLAUDE.md Help? - CSharp-Coder

Leave a Reply

Your email address will not be published. Required fields are marked *