Not a Ladder, a Fork: What I Learned Researching Claude Sonnet 5.5 vs Opus 5.5

Here is the whole argument up front. Claude Sonnet 5.5 is not a cheaper Opus 5.5. It is a cheaper model at low, medium and high effort, an equally expensive one at max, and a different model in the one way that matters for routing: no other model can read a Sonnet 5.5 thinking block, and Sonnet 5.5 cannot read an Opus 5.5 block S3S4. So the ladder I built last week, where a conversation climbs from Opus 5.5 to Fable 5.1 and keeps its reasoning S26, cannot be extended downward. Between Sonnet 5.5 and Opus 5.5 there is no climb. There is a fork, and you take it before the first token, per task, based on whether the task has a spec and a check.

I started this as the obvious sequel: a routing rule with one more rung. Sonnet 5.5 landed on September 28, six days after Opus 5.5 S1S2, at exactly half of Opus's input and output prices S5S21, with a launch table that shows it beating Opus on one benchmark and sitting within two or three points on most of the rest S1. Every source I read after that took a piece out of that plan, starting with the benchmark I misread first.

FIG. 01 · Terminal-Bench 4.0 as the system card reports it · scores, effort levels, fallback share and standard error S7

Why did the one benchmark Sonnet wins almost fool me?

The first number I wrote down was 70.6. That is Sonnet 5.5's Terminal-Bench 4.0 score in Anthropic's launch table, against 66.4 for Opus 5.5 S1. Read as a headline, the cheaper model beats the flagship on the benchmark closest to what Claude Code actually does. Half of the day-one comparison posts led with it, and so did my first draft.

Then I opened section 8.5 of the system card, and the win shrank three separate times. First, effort: the 70.6 is Sonnet 5.5 at max, while the 66.4 is Opus 5.5 at xhigh, because that is Opus's highest score on this benchmark; at max, Opus 5.5 scores 64.8, which Anthropic calls within noise of xhigh S7. Second, safeguards: both runs had cyber safeguards on, and requests the classifiers flagged were answered by a fallback model. For Sonnet 5.5 that touched 1.5% of trials. For Opus 5.5 it touched 10% S7. Third, noise: with 330 trials per model, the standard error is ±2.5 points for Sonnet 5.5 and ±2.6 for Opus 5.5 S7. A 4.2-point gap with a tenth of one side's trials answered by an older model is not a result I would put in a routing rule.

A Hacker News commenter got there before me, pointing to the same section and concluding that the fallback gap alone could explain the difference S14. Two independent write-ups also report a Vals run in which the order reverses, with Opus 5.5 ahead of Sonnet 5.5 on Terminal-Bench 4.0; I could not open the Vals page myself, so I am flagging that as secondhand rather than building on it S23S24.

The rest of the table points one way. Opus 5.5 leads on FrontierCode (54.4% against 46.2% at max, or 52.1% at Sonnet's best setting, xhigh), CursorBench (57.8% against 55.5%), Humanity's Last Exam with tools (67.7% against 64.5%), OSWorld 2.1 (81.8% against 80.1%) and Chartography (64.4% against 61.6%) S1. The system card adds SWE-Bench Pro at 89.9% against 81.3% S7. The two knowledge-work rows are within a rounding error: 1846 against 1844 on GDPval-AA and 1822 against 1811 on AA-Briefcase S1. And the footnote on FrontierCode is the most instructive line on the page: at max effort Sonnet 5.5 scores lower than at xhigh, because it more often ran Claude Code's code-review skill across many subagents, which in two cases produced a timeout or out-of-scope edits S1. More thinking, worse score, higher bill.

Anthropic's own caption says it plainly: on several evaluations Sonnet 5.5 at max performs comparably to Opus 5.5, but in its own and external testers' hands, Opus 5.5 remains clearly stronger at complex, open-ended work requiring sustained judgment S1. The lesson I am keeping from last week still holds and now has a fourth item. Before reading any benchmark number, pin the version, the harness, the effort level, and the fallback rate.

Why is "half the price" true per token and false per task?

List prices first, because they are the only numbers nobody disputes.

FIG. 02 · List price per million tokens on the Claude API · Sonnet 5.5 vs Opus 5.5, September 2026 S5S8

Sonnet 5.5 costs $2 per million input tokens and $10 per million output tokens, with five-minute cache writes at $2.50, one-hour cache writes at $4, and cache reads at $0.20 S5. Opus 5.5 costs $4 and $20, with five-minute cache writes at $5, one-hour writes at $8, and cache reads at $0.20 S8. Every line is exactly double except the last one, which is identical. The reason is a pricing choice I covered last week: Opus 5.5's cache read sits at 5% of its input price, while Sonnet 5.5 keeps the usual 10% multiplier, and the two land on the same $0.20 S26. Sonnet 5.5's prices are unchanged from Sonnet 5 S1.

In an agentic session, that shared line is most of your input. Here is the arithmetic on the illustrative session shape Anthropic prices in its Opus 5.5 cost guide: 2 million cache-read tokens, 200 thousand fresh input tokens, 60 thousand output tokens S9.

// Claude API list prices, USD per million tokens.
const PRICES = {
  "claude-sonnet-5-5": { input: 2, output: 10, cacheRead: 0.2 },
  "claude-opus-5-5":   { input: 4, output: 20, cacheRead: 0.2 },
} as const;
 
type Usage = { cacheRead: number; freshInput: number; output: number };
 
function sessionCost(model: keyof typeof PRICES, u: Usage): number {
  const p = PRICES[model];
  return (u.cacheRead * p.cacheRead + u.freshInput * p.input + u.output * p.output) / 1_000_000;
}
 
// Illustrative Claude Code session shape from Anthropic's cost guide.
const session: Usage = { cacheRead: 2_000_000, freshInput: 200_000, output: 60_000 };
 
sessionCost("claude-sonnet-5-5", session); // 1.40
sessionCost("claude-opus-5-5", session);   // 2.40, so Sonnet is 42% cheaper, not 50%
 
// Push the cache share up, the way long sessions do.
const longSession: Usage = { cacheRead: 5_000_000, freshInput: 100_000, output: 60_000 };
 
sessionCost("claude-sonnet-5-5", longSession); // 1.80
sessionCost("claude-opus-5-5", longSession);   // 2.60, now only 31% cheaper

Same tokens, 42% cheaper on the standard shape and 31% cheaper on a cache-heavy one. A Hacker News reader spotted the same line in the launch table within minutes: with cache reads priced the same as Opus, there will not be that much price difference in agentic coding S14.

Then the two models stop using the same tokens, and this is where the "up to 30% less" claim needs its footnote. Anthropic's 30% compares Sonnet 5.5 with Sonnet 5, not with Opus, and it comes from needing fewer tokens and fewer tool calls for the same work rather than from any price cut S1S20. Against Opus 5.5 the token story runs the other way at the top of the range. Artificial Analysis measured about 193 thousand output tokens per Intelligence Index task for Sonnet 5.5 at max, the highest it has ever recorded, roughly 60% more than Opus 5.5 at max S10. The result is a cost per task of $7.60 for Sonnet 5.5 at max against $5.98 for Opus 5.5 at max S10S12. Half the price per token, 27% more per task.

Lower down the curve the picture flips back. Sonnet 5.5 at low costs $0.41 per index task, at medium $0.59, at high $1.08 S11. Opus 5.5 at its own default, medium, costs $1.34 S12. So "cheaper" is a true statement about three of Sonnet's five effort levels and a false one about the top of the curve. Artificial Analysis's summary is blunter than Anthropic's: at its $2 and $10 pricing, Sonnet 5.5 sits off the intelligence-versus-cost frontier, behind Opus 5.5 at the high effort levels, with the high setting its most competitive S10.

What happens when you put both models on one chart?

This is the chart I wish I had drawn before writing the first draft. Every point comes from Artificial Analysis Intelligence Index v4.3.2, run with Anthropic's default fallback on, and the Opus points are from the snapshot I took for last week's post S10S11S12.

FIG. 03 · Artificial Analysis Intelligence Index v4.3.2 vs cost per task · Opus 5.5 snapshot 27 September, Sonnet 5.5 snapshot 29 September 2026 S10S11S12

Read it left to right. Sonnet 5.5 at low scores 36 for $0.41 and at medium 41 for $0.59 S11. Opus 5.5 at low scores 42 for $0.55 S12. So the cheapest Opus setting outscores the two cheapest Sonnet settings for about the price of Sonnet's medium. At high, Sonnet 5.5 scores 47 for $1.08 S11; Opus 5.5 at medium scores 51 for $1.34 S12. Then the right edge: Sonnet 5.5 at max scores 56 for $7.60, which is exactly the score of Opus 5.5 at xhigh, for $3.46 S10S12. Same index score, 2.2 times the cost. A Hacker News commenter asked the question the chart asks: why run Sonnet 5.5 at xhigh when Opus 5.5 at high scores higher for less S14? On this index, I do not have a good answer.

I left one point off. Artificial Analysis publishes a Sonnet 5.5 page for each of the five effort levels, and the xhigh page would not load for me on two attempts, so the chart has four Sonnet points, not five S11. I would rather show the gap than guess the number.

Two caveats travel with the chart. Artificial Analysis ran a pre-release deployment of Sonnet 5.5 that Anthropic says had a bug affecting structured-output requests, since fixed; both parties expect the effect to be small and to understate Sonnet's scores S1S10. And the index rewards breadth: on its AA-Omniscience knowledge test Sonnet 5.5 scores 54% accuracy against 66% for Opus 5.5, with a lower hallucination rate (47% against 59%), and it sits about six points lower on Humanity's Last Exam and SciCode S10. A smaller model knows less and makes things up less. Both halves of that sentence matter for routing, and Anthropic said as much on launch day: Sonnet 5.5 does not advance the frontier of its models' capabilities S1S21.

The right side of the chart also has last week's failure mode. Simon Willison ran his pelican-on-a-bicycle prompt on Sonnet 5.5 at max, and the model thought for 128,000 tokens, at $1.28, before running out of output room and producing no SVG, the same bug he hit on Opus 5.5 S13. At xhigh the same prompt cost 5.74 cents, took 41 seconds, and drew a correct bicycle S13. Max is where over-thinking shows up first on both models, and on Sonnet it costs more than on Opus.

What are engineers reporting after day one?

Benchmarks tell you where to look. Practitioners tell you what breaks. Sonnet 5.5 is a day old as I write this, so the reports are launch-day reports, from engineers in the US and Europe, and I have weighted the ones that come with numbers.

The efficiency story is real and consistent. GitHub's Copilot team found Sonnet 5.5 matched Sonnet 5 on coding tasks while using significantly fewer steps, tokens and tool calls, and finishing noticeably faster S18. CodeRabbit measured it at 6 of 13 known issues found in code review against 4 for Sonnet 5, at a slightly higher precision, and plans to move simple and moderate reviews over now S19. Lovable's evals showed a third fewer tool calls and roughly half the shell runs per task S1. Base44 ran 118 real app builds and found Sonnet 5.5 reached Opus 5-level app quality in 3.6 iterations per build where Opus 5 took 7.7, with the fewest failed tool calls of any model they compared S1. Balyasny's finance suite used about 121 thousand tokens per answer against 497 thousand for Sonnet 5 S1. Those are all vendor-supplied quotes in a launch post, but the direction is the same in every independent test I found.

The most useful head-to-head came from a small shop that ran the same coding task three times each on Sonnet 5.5, Sonnet 5, Opus 5.5 and GPT-6 Sol. The two Anthropic models behaved almost identically, about six steps each, every hidden test passed, but Opus 5.5 took 68 seconds and $0.33 per run against 48 seconds and $0.19 for Sonnet 5.5. Their conclusion: on a task that size, Opus bought nothing extra S23. That is the fork in one sentence. When the task is scoped and checkable, the extra judgment has nothing to do.

Writing is the surprise. Dan Shipper at Every reported that Sonnet 5.5 dramatically improved on writing even against Opus 5.5 in his tests, that GPT-6 Astra remains his favourite for drafting, and that Sonnet 5.5 beats it at revision, which is why Every's engineers reach for it for quick iterative coding S16. Every's own headline verdict is more careful: a more capable partner than Sonnet 5, so long as you keep a hand on the wheel and know when to call in Opus S15. Simon Willison's read is similar: almost as good as Opus 5.5 on some coding tasks, and now the model behind claude.ai's free tier, replacing Sonnet 5 as the default for Free and Pro users, which he thinks gives Anthropic a much more capable free offering than ChatGPT's S13S22.

The dissent clusters in two places. The first is the Opus 5.5 subscriber who does not see a reason to switch. One Hacker News developer on the 5x plan wrote that Opus 5.5's efficiency makes the limits sufficient for everyday work, even running two or three sessions at once, and wondered when Sonnet 5.5 would ever come up S14. Another said the only advantage he could anticipate was that he still hits session limits with Opus 5.5, and Sonnet 5.5 is a better fallback for those than Sonnet 5 S14. The second is the cost-per-task crowd, who read the same chart I drew above and concluded Sonnet is, in one commenter's words, a far worse version of Opus at every point on the cost and speed curve, and that what Anthropic needs is something competitive with GPT-6 Luna or Gemini Flash S14. Another summed up Sonnet 5 as bad, Sonnet 5.5 as a lot better, and neither as close to Fable S14.

Then there is the safeguard noise, which is louder than for any Sonnet before it. The system card says users should expect increased refusals with Sonnet 5.5, even on benign cybersecurity-related tasks, and that blocked requests fall back to Sonnet 5 automatically in Anthropic's apps but only if you opt in on the API S7S17. Launch-day reports from developers include a write-ahead-log durability review flagged and rerouted, a parser task flagged for using the word fuzz, an ESP32 Bluetooth presence-detection project bounced to an older model, and a paying member of the Cyber Verification Program who still cannot use either 5.5 model for authorized bounty work S14. Anthropic says the expanded program will cover Sonnet 5.5 soon S1. Until it does, the fallback is a cost and latency event you should expect to see in logs.

Why can't you bolt Sonnet onto the bottom of the ladder?

This is the part of the research that turned a sequel into a correction.

Last week's post ended with an escalation ladder: run Opus 5.5, raise its effort, and move to Fable 5.1 only after xhigh fails the same check twice, because Fable can read Opus 5.5's thinking blocks and the climb keeps its reasoning S26. The obvious sequel adds Sonnet 5.5 as rung zero. Start cheap, climb when the check fails.

The docs close that door in both directions. Sonnet 5.5 reads thinking blocks from Sonnet 5, Opus 4.8, Haiku 4.5 and earlier models. It does not read blocks from Opus 5, Opus 5.5, or any Fable or Mythos model. And no other model reads Sonnet 5.5's blocks S3. Opus 5.5's blocks, in turn, are readable only by Fable 5.1 and Mythos 5.1 S6. When a request carries a block the target model cannot read, the API drops it before the model sees it; the request still succeeds, and dropped blocks are not billed, which means a router that switches models mid-conversation loses the reasoning silently S3S4.

FIG. 04 · Who can read whose thinking blocks · the Opus to Fable climb keeps reasoning, the Sonnet to Opus switch drops it both ways S3S6

I nearly got this wrong from a secondary source. One comparison post published within hours of launch states that Opus 5.5 can read thinking blocks from Sonnet models, so a Sonnet-to-Opus escalation keeps its reasoning S25. The platform docs say the opposite in one sentence: no other model reads Claude Sonnet 5.5 thinking blocks S3. Addy Osmani's day-one guide repeats it word for word S8. I checked because the claim was load-bearing for the ladder, and the ladder fell over.

Four more constraints shape the fork.

• Switching models costs a cache write. The cache belongs to the previous model, so the first turn on the new one pays the write price on the whole conversation S9. On a Sonnet-to-Opus switch that write is at Opus prices.
• The defaults are not equal. Sonnet 5.5 defaults to high effort on the Claude API and medium in Claude Code and the apps; Opus 5.5 defaults to medium S1S5S8. An A/B test that never sets output_config.effort compares Sonnet at high against Opus at medium.
• Changing effort at the top level invalidates the cache. To run one turn at a different level, use per-message effort, which is in beta and keeps the cache, and which Sonnet 5.5 supports and Sonnet 5 does not S3S8.
• Keep the conversation append-only. For accounts created on or after August 31, 2026, a request that replays a Sonnet 5.5 thinking block after an edit to earlier history returns a 400 error, on the Claude API, Bedrock and Google Cloud S3S4. Same rule as Opus 5.5, same fix: mid-conversation system messages instead of edits.

One breaking change is Sonnet-only and worth knowing before you migrate. Sonnet 5 turned thinking off with disabled; on Sonnet 5.5 that returns a 400, and the lowest setting is between_tools, which skips up-front thinking, still emits short progress-update thinking blocks between tool calls, only works at low, medium and high, and does not allow effort to change mid-conversation S3S4. The other breaking changes line up with Opus 5.5: forced tool use returns an error, the old computer_20251124 tool is rejected on the Claude API and Google Cloud, and the advisor tool rejects Opus 4.8, Opus 4.7 and Sonnet 5 as advisors S3. One request builder still serves both models, as long as it never sends disabled.

How would I encode the fork?

Here is the rule as code. It uses plain fetch against the Messages API so every field is visible, and it only uses parameters the docs confirm for both models: adaptive thinking, effort under output_config, and the default tool choice S3S6. The one Sonnet-only field, between_tools, is used where the docs say it belongs: low-latency, tool-heavy runs at high effort or below S3.

type Effort = "low" | "medium" | "high" | "xhigh" | "max";
type Model = "claude-sonnet-5-5" | "claude-opus-5-5";
type Rung = { model: Model; effort: Effort; upFrontThinking: boolean };
type Message = { role: "user" | "assistant"; content: unknown };
type Verdict = { ok: true } | { ok: false; feedback: string };
 
// The fork happens here, before the first token, from what the task looks like.
// scoped: a spec exists and a check (test, build, script) can grade the result.
// judgment: open-ended, no pattern in the codebase, or the deliverable must be right first time.
type TaskShape = { scoped: boolean; latencySensitive: boolean; usesTools: boolean };
 
function pickLane(t: TaskShape): Rung[] {
  if (t.scoped) {
    // Sonnet lane. between_tools only where tools drive the work and speed matters.
    const quick = t.latencySensitive && t.usesTools;
    return [
      { model: "claude-sonnet-5-5", effort: "medium", upFrontThinking: !quick },
      { model: "claude-sonnet-5-5", effort: "high",   upFrontThinking: true },
    ];
  }
  // Opus lane. No Sonnet rung below it: the reasoning would not carry up anyway.
  return [
    { model: "claude-opus-5-5", effort: "medium", upFrontThinking: true },
    { model: "claude-opus-5-5", effort: "high",   upFrontThinking: true },
    { model: "claude-opus-5-5", effort: "xhigh",  upFrontThinking: true },
  ];
}
 
async function callClaude(rung: Rung, messages: Message[]) {
  const res = await fetch("https://api.anthropic.com/v1/messages", {
    method: "POST",
    headers: {
      "x-api-key": process.env.ANTHROPIC_API_KEY ?? "",
      "anthropic-version": "2023-06-01",
      "content-type": "application/json",
    },
    body: JSON.stringify({
      model: rung.model,
      max_tokens: 64000,                       // thinking is billed as output; leave room
      thinking: rung.upFrontThinking
        ? { type: "adaptive" }                 // the only mode on Opus 5.5
        : { type: "between_tools" },           // Sonnet 5.5 only, high effort or below
      output_config: { effort: rung.effort },
      messages,
    }),
  });
  if (!res.ok) throw new Error(`Claude API ${res.status}: ${await res.text()}`);
  return res.json();
}
 
export async function runForked(
  task: string,
  shape: TaskShape,
  verify: (reply: any) => Promise<Verdict>,
) {
  const lane = pickLane(shape);
  // Append-only history. Editing earlier turns invalidates bound thinking blocks.
  const messages: Message[] = [{ role: "user", content: task }];
 
  for (const rung of lane) {
    const reply = await callClaude(rung, messages);
 
    // Refusals exit. Escalating a refusal to Opus buys a refusal at Opus prices.
    if (reply.stop_reason === "refusal") return { status: "refused", rung, reply };
    if (reply.stop_reason === "max_tokens") continue;
 
    // Same model within a lane, so thinking blocks stay readable. Pass them back untouched.
    messages.push({ role: "assistant", content: reply.content });
 
    const verdict = await verify(reply);
    if (verdict.ok) return { status: "done", rung, reply };
 
    messages.push({
      role: "user",
      content: `The check failed:\n${verdict.feedback}\nFind the root cause and fix it.`,
    });
  }
 
  // The Sonnet lane ran out. Do not append Opus to this history: its reasoning is gone
  // the moment the model changes. Hand Opus the task, the diff and the failed checks, fresh.
  return { status: "reroute-fresh", messages };
}

A few decisions in there are deliberate.

• The fork is a function of the task, not of the previous failure. Anthropic's own guide draws the line the same way: Sonnet 5.5 for well-scoped everyday coding, high-volume development, polished documents and repeatable agent tasks; Opus 5.5 for complex work requiring careful judgment, long-horizon agentic coding, and the hardest problems S8. The AWS launch post puts it in one line: Opus 5.5 takes the judgment calls, Sonnet 5.5 takes the work where the approach is already clear S27.
• No max rung on either lane, and no xhigh on Sonnet. Max over-thinks on both models S13, and Sonnet at max costs more per task than Opus at max while scoring lower S10S12. Sonnet at xhigh exists, but on the index Opus at high beats it on cost and score, so the lane stops at high S11S12.
• A reroute is a fresh start, not an append. When the Sonnet lane fails, the code returns the history for a human or an orchestrator to summarise into a new Opus request. That is uglier than a ladder, and it is honest about what the API does.
• The verify function is still the real work. Anthropic's cost guide argues the cheapest fix is giving the model a way to check its own work before paying for more effort S9, and its Sonnet 5.5 guide adds that at low effort the model sometimes skips a check that exercises the change, with a system-prompt paragraph to fix it S8. The fork is only as good as the check that decides which lane a task belongs in.

In Claude Code the fork already exists as a keystroke. The default model stays Opus 5.5 on every plan, /model sonnet switches to Sonnet 5.5 at medium effort, and Sonnet 5.5 has no fast mode there S8. Nothing in the docs suggests the two share reasoning when you switch mid-session, so I now treat that command the way I treat a new terminal: fine at the start of a task, not in the middle of one.

What does the side-by-side look like?

Which one should you reach for?

Sonnet 5.5 is the right lane if:

• The task has a spec and a check: a bug fix with a failing test, a feature with acceptance criteria, a review against a rubric S8.
• You run the same agent task repeatedly and the win is throughput: review bots, investigation, drafting, high-volume development S8S19.
• The deliverable is a document, deck, spreadsheet or interface, where testers rate its eye for design and its prose above Sonnet 5 and, for revision, above Opus 5.5 S1S16.
• Latency matters more than the last two index points, and you can run at medium or high S8S11.
• You keep hitting Opus session limits on a subscription and need a second lane that is not Sonnet 5 S14.

Opus 5.5 is the right lane if:

• The problem has no existing pattern in the codebase, or the run is long and unsupervised S9.
• The deliverable has to be right the first time, or the task is graded on breadth of knowledge, where Opus leads by 12 points on AA-Omniscience S10.
• You would otherwise reach for Sonnet at xhigh or max. On the index, Opus at high scores higher for less, and Opus at max is cheaper per task than Sonnet at max S10S12.
• The work is repository-scale coding, where Opus leads SWE-Bench Pro by nine points and FrontierCode by two to eight depending on effort S1S7.

Neither lane is the fix if:

• You planned to start on Sonnet and escalate mid-conversation. The reasoning does not travel in either direction; reroute fresh instead S3.
• You keep hitting cyber refusals on legitimate security work. Both models fall back to older models, and the answer is the verification program, not the model picker S7S17.
• You have not set output_config.effort. The API defaults differ, so any comparison at defaults is a comparison of two effort levels, not two models S5.
• The job needs a Luna-class price. Haiku 5.5 is the model Anthropic says is coming for that, in the coming weeks S1.

What would I do differently next time?

Three things, in the order I would do them.

First, I would read the system card before the launch table. The launch table gave me a 4.2-point Sonnet win; the system card gave me the effort mismatch, the 10% fallback share and the standard error that put the win inside the noise S1S7. Every headline number needs its footnote, and the footnotes live in the card.

Second, I would verify any claim about thinking-block compatibility against the model's own "what's new" page, and only there. A secondary source told me the ladder worked; the docs told me no other model reads Sonnet 5.5's blocks S3S25. That one sentence changed the structure of the post, and it would have changed the structure of a router.

Third, I would set effort explicitly in every request I compare, and I would start the sweep at the surface default rather than the API default. Sonnet 5.5's docs say to re-run the effort sweep because the levels are recalibrated and a setting from Sonnet 5 will not carry over S3S8. Anthropic's advice for measuring on your own tasks has not changed since last week: run the same backlog task on each model, read turns, output tokens and cost from /usage, and repeat for three or four tasks before drawing a conclusion S9. I would add one column to that spreadsheet now: how many of those turns were served by a fallback model.

Sources

1. S1Anthropic, "Introducing Claude Sonnet 5.5," September 28, 2026, anthropic.com
2. S2Anthropic, "Introducing Claude Opus 5.5," September 22, 2026, anthropic.com
3. S3Claude Platform Docs, "What's new in Claude Sonnet 5.5," platform.claude.com
4. S4Claude Platform Docs, "Migrating to Claude Sonnet 5.5," platform.claude.com
5. S5Claude Platform Docs, "Claude Sonnet 5.5" (model overview, with the four-model comparison table), platform.claude.com
6. S6Claude Platform Docs, "What's new in Claude Opus 5.5," platform.claude.com
7. S7Anthropic, "System Card: Claude Sonnet 5.5," September 28, 2026, sections 3.3, 8.1 and 8.5, anthropic.com
8. S8Addy Osmani, "Building with Claude Sonnet 5.5," claude.dev, September 28, 2026, claude.dev
9. S9Addy Osmani, "What a task costs on Opus 5.5," claude.dev, September 25, 2026, claude.dev
10. S10Artificial Analysis, "Claude Sonnet 5.5 reaches #2 on the Artificial Analysis Intelligence Index," September 28, 2026, artificialanalysis.ai
11. S11Artificial Analysis, Claude Sonnet 5.5 model pages at low, medium, high and max effort (Intelligence Index v4.3.2, default fallback), accessed September 29, 2026, artificialanalysis.ai
12. S12Artificial Analysis, Claude Opus 5.5 release page (all five effort levels, Intelligence Index v4.3.2), accessed September 27, 2026, artificialanalysis.ai
13. S13Simon Willison, "Claude Sonnet 5.5," September 28, 2026, simonwillison.net
14. S14Hacker News, discussion thread on the Claude Sonnet 5.5 launch, September 28 to 29, 2026, news.ycombinator.com
15. S15Katie Parrott, "Vibe Check: Sonnet 5.5 Finds Its Place in Claude's Crowded Family," Every, September 28, 2026, every.to
16. S16Dan Shipper on X, launch-day notes on Sonnet 5.5 writing and revision, September 28, 2026, x.com
17. S17Steven J. Vaughan-Nichols, "You picked Claude Sonnet 5.5, but Anthropic may send your request to Sonnet 5 in higher-risk situations," The New Stack, September 28, 2026, thenewstack.io
18. S18GitHub Changelog, "Claude Sonnet 5.5 in GitHub Copilot," September 28, 2026, github.blog
19. S19CodeRabbit, "Sonnet 5.5 vs Opus 5.5 Code Review Benchmarks," September 2026, coderabbit.ai
20. S20VentureBeat, "Anthropic launches Claude Sonnet 5.5 with 30% cost reduction per-task due to faster speeds and fewer tool calls," September 28, 2026, venturebeat.com
21. S21CNBC, "Anthropic Sonnet 5.5 launch: Price, features and safety," September 28, 2026, cnbc.com
22. S22Tom's Guide, "Claude Sonnet 5.5 just launched, here's why it's about to become your daily driver," September 29, 2026, tomsguide.com
23. S23Atomic Agent, "Claude Sonnet 5.5 vs Opus 5.5: Benchmarks & Pricing," September 29, 2026, atomicagent.io
24. S24Kingy AI, "Claude Sonnet 5.5 vs Opus 5.5: Cost, Benchmarks & Tokens," September 29, 2026, kingy.ai
25. S25Myclaw, "Sonnet 5.5 vs Opus 5.5," September 29, 2026, the comparison whose thinking-block claim the platform docs contradict, myclaw.ai
26. S26Syed Moinuddin, "Not a Winner, a Routing Rule: What I Learned Researching Claude Opus 5.5 vs Fable 5.1," September 27, 2026, syedmoinuddin.com
27. S27AWS Machine Learning Blog, "Introducing Claude Sonnet 5.5 on AWS," September 28, 2026, aws.amazon.com

Written by

Syed Moinuddin

Full Stack Engineer.

Notes on AI tooling, agentic systems, and building things that survive contact with production.