Claude Opus 5.5 vs Sonnet 5.5: Which Model to Route To?

Anthropic shipped two models six days apart: Claude Opus 5.5 on September 22 and Claude Sonnet 5.5 on September 28. If you build on the Claude API, the question is no longer which model is smarter. It is which one each request should go to, because on some of Anthropic’s own benchmarks the cheaper model is ahead.

The Numbers Side by Side

Both models share a lot: a 1M token context window, 128K max output, adaptive thinking and a June 2026 knowledge cutoff. The differences that matter for an application are these:

Price — Opus 5.5 is $4 input / $20 output per million tokens. Sonnet 5.5 is $2 / $10, unchanged from Sonnet 5.
Cache reads — $0.20 per million tokens on both. That detail matters more than it looks.
Latency — Anthropic’s docs label Opus 5.5 as moderate and Sonnet 5.5 as fast. Each is described as over 30% faster than the model it replaces.
Thinking — On Opus 5.5 thinking is always on. On Sonnet 5.5 it is adaptive.
Default effort — medium on Opus 5.5, high on Sonnet 5.5. Yes, the more expensive model defaults lower.

Where the Benchmarks Actually Separate Them

Anthropic published both models in one table on the Sonnet 5.5 launch page, which makes a direct comparison possible. These are vendor-reported numbers, so treat them as a starting point for your own evals, not a verdict:

Terminal-Bench 4.0 (agentic coding) — Sonnet 5.5 70.6%, Opus 5.5 66.4% (Opus measured at xhigh effort)
CursorBench 4.0 — Sonnet 5.5 55.5%, Opus 5.5 57.8%
FrontierCode 1.1 — Sonnet 5.5 46.2%, Opus 5.5 54.4%
OSWorld 2.1 (computer use) — Sonnet 5.5 80.1%, Opus 5.5 81.8%
GDPval-AA v2.1 (knowledge work) — Sonnet 5.5 1844, Opus 5.5 1846
Humanity’s Last Exam (with tools) — Sonnet 5.5 64.5%, Opus 5.5 67.7%

On most rows the gap is two or three points. The clear outlier is FrontierCode, where Opus leads by eight. That lines up with how Anthropic positions the pair: Sonnet 5.5 for well-scoped everyday tasks, bug fixes and polished documents; Opus 5.5 for complex, open-ended work that needs sustained judgment.

Network of connected nodes representing requests routed between models

Most of the savings come from routing each request to the right model, not from picking one model for everything

The Cost Math

Per token, Opus 5.5 is exactly twice the price of Sonnet 5.5 on both input and output. A request with 50K input tokens and 5K output tokens costs about $0.30 on Opus 5.5 and $0.15 on Sonnet 5.5.

Two things bend that ratio. First, cache reads cost the same $0.20 per million on both models, so an agent loop that re-reads a large cached context pays a smaller premium for Opus than the list price suggests. Second, the price that matters is cost per completed task. A cheaper model that needs a second attempt, or more turns to finish, is not cheaper. Both models also get 50% off through the Batch API for work that can wait.

API Differences That Will Bite You

If you are moving existing code over, Opus 5.5 is the stricter of the two. Per Anthropic’s migration guide:

Thinking cannot be disabled — thinking: {type: "disabled"} and manual budget_tokens return a 400. Lower the effort level instead.
No forced tool calls — tool_choice of any or tool returns a 400. Use auto with strict tool use or structured outputs.
Thinking blocks stay with the model — Opus 5.5 thinking blocks are only read by Fable 5.1 and Mythos 5.1. Switch a conversation from Opus 5.5 to Sonnet 5.5 halfway through and those turns run without the earlier reasoning.

That last point shapes how you route: pick the model per conversation or per task, not per message. Here is the small router I would start with in a Node.js service:

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

// Set effort explicitly: the API defaults differ
// (Opus 5.5 runs at medium, Sonnet 5.5 at high).
const ROUTES = {
  deep: { model: "claude-opus-5-5", effort: "high" },
  fast: { model: "claude-sonnet-5-5", effort: "medium" },
} as const;

export async function run(prompt: string, openEnded: boolean): Promise<string> {
  const route = openEnded ? ROUTES.deep : ROUTES.fast;

  const response = await client.messages.create({
    model: route.model,
    max_tokens: 16000,
    output_config: { effort: route.effort },
    messages: [{ role: "user", content: prompt }],
  });

  if (response.stop_reason === "refusal") {
    throw new Error("Request declined by safety classifiers");
  }

  return response.content
    .flatMap((block) => (block.type === "text" ? [block.text] : []))
    .join("");
}

Leave out the thinking field so the request is valid on both models, and always check stop_reason before reading the content.

Default to Sonnet 5.5 and make Opus 5.5 something a task has to earn. The benchmarks say the cheaper model is within a few points on most work, and your evals, not the launch charts, should decide where that gap matters.

How I Would Route Between Them

Sonnet 5.5 — Well-scoped coding tasks, bug fixes, UI and document generation, and high-volume or latency-sensitive endpoints
Opus 5.5 — Open-ended agent runs, large migrations, reviewing big changes, and multi-step work where one wrong turn is expensive
Measure before you commit — Run 20 to 50 real tasks from your product through both models, and compare pass rate and total cost per finished task

The 5.5 generation made the choice more interesting. Sonnet is no longer a noticeably weaker model you accept to save money. For a lot of day-to-day engineering work it is simply the better default.