Anthropic Sonnet 5.5 Deep Dive: Don't Rush to Use It Directly — It's Better as a Tool

Anthropic's release cadence has been nothing short of relentless lately. From Fable 5.1, dubbed "the best coding model ever loved," to Opus 5.5 taking over countless workflows, and now Sonnet 5.5 arriving out of nowhere — this model looks like it was precision-engineered to take aim at OpenAI. But after hands-on testing, well-known developer and tech blogger Theo (t3.gg) landed on a counterintuitive conclusion: Sonnet 5.5 is a genuinely impressive model, but most people shouldn't reach for it directly.

What Actually Makes Sonnet 5.5 Stand Out

On paper, Sonnet 5.5 is a clear upgrade over Sonnet 5: 30% faster, with costs reduced by up to 30% in most scenarios. But Theo is quick to point out that comparing against Sonnet 5 is hardly a fair fight — in his words, Sonnet 5 was "one of the worst model releases," making it a pretty low bar.

What's genuinely worth paying attention to is the benchmark leap. Sonnet 5.5 hit a record-high 70.6% on Terminal Bench 4, compared to just 10.3% for its predecessor — a sevenfold improvement. That means it's finally "actually usable" for coding tasks. It also became the first Sonnet model to complete Pokémon Red purely by reading and acting on screenshots, showing real strength in long-horizon tasks and visual understanding.

Theo's read on this is insightful: previously, any non-flagship Anthropic model lacked a certain "feel" — they operated more like robots constrained to a specific scope. Now these mid-tier models "feel like slightly dumber, way faster versions of Fable." He half-jokingly quipped: "It feels like they saw everyone distilling Anthropic's models, got jealous, decided to do it themselves — and discovered they're actually pretty good at it."

The Pricing Trap: "Cheap" Is an Illusion

This is the most valuable analysis in the entire review. Sonnet 5.5 is priced identically to Sonnet 5: $2 per million input tokens, $10 per million output tokens, and $0.20 per million cache reads. On the surface, that looks like half the cost of Opus (which runs $4 input / $20 output).

But Theo zeroes in on a critical issue — cache read costs have barely budged. In day-to-day agentic coding work, cache reads and writes typically make up the bulk of actual costs. Fable 5.1 slashed cache read costs by 90%, Opus cut them by roughly 60%, but Sonnet 5.5 received none of that discount.

The result is a counterintuitive phenomenon: in real-world usage, cache reads account for a growing share of total costs as you move down the model tier — under 5% with Fable, approaching 20% with Opus, and topping 50% with Sonnet 5.5. Because every other number is low, that one line item sticks out like a sore thumb.

Theo verified this on the Artificial Analysis intelligence index: running the same real-world coding tasks, Sonnet 5.5 ends up costing roughly the same as the significantly pricier Fable 5.1. His conclusion: "Sonnet consistently costs no less than Opus for equivalent real work — and may actually cost more."

---

A Note on Cache Read Pricing

In LLM API billing, "cache reads" refer to a mechanism where repeated context — system prompts, long documents, conversation history — is temporarily stored in a fast cache. Subsequent calls only incur a much lower "cache read" fee rather than reprocessing all tokens from scratch. For agents continuously working on the same codebase, each call carries a large amount of repeated context (source files, project documentation, etc.), meaning cache reads can account for 70–90% of total token consumption — making them the dominant cost driver, not the input/output unit prices vendors typically highlight in their marketing. Fable 5.1's dramatic reduction in cache read pricing is the core reason it leads on cost efficiency for agentic use cases. Sonnet 5.5's failure to follow suit means its headline pricing advantage largely evaporates in practice.

---

Whatever You Do, Avoid Max Mode

Theo dedicates significant attention to explaining his distaste for Max reasoning mode. The core logic: reasoning levels are fundamentally "budgets," not "grades." Setting low, medium, high, or x-high simply caps how many reasoning tokens the model can use — it doesn't force it to use them all.

The problem with Max is different. Max doesn't raise the ceiling — it raises the floor. It effectively tells the model, "don't consider the task done unless you've hit a minimum amount of reasoning." Theo's testing shows that going from low to x-high increases token usage by only 5–8%, but jumping from x-high to Max causes a 1,500% spike — a full 15x increase.

Worse, excessive reasoning often actively hurts performance — the model starts second-guessing itself and overturning correct answers. One piece of evidence: on the Frontier Code benchmark, x-high actually outscores Max, pushing Max below GPT-6 Sol. His advice is blunt: "Pretend Max mode doesn't exist and your life will be much easier." He also doesn't recommend using low on any Anthropic model — because "these models are terrible without reasoning."

---

Background: The "Thinking Token" Mechanism in Reasoning Models

Major LLM vendors — Anthropic, OpenAI, Google — have broadly introduced "extended thinking" capabilities in their flagship models: before producing a final answer, the model generates an internal reasoning chain that isn't visible to users. These are commonly called "thinking tokens" or "reasoning tokens." This mechanism significantly improves accuracy on complex logic and coding tasks, but substantially increases latency and cost. Anthropic's Sonnet 5.5 uses a tiered budget design (low/medium/high/x-high/Max), intended to let developers tune reasoning depth and cost to task complexity. However, Max operates on fundamentally different logic from the other tiers: the others set an upper limit on reasoning tokens (the model can use fewer if appropriate), while Max enforces a minimum floor, forcing extensive reasoning regardless of task difficulty. This produces the counterintuitive result of degraded performance — consistent with academic research on "overthinking" harming model outputs.

---

The Truth About Speed and Token Efficiency

Anthropic heavily markets Sonnet 5.5's speed, but Theo thinks this is oversold. It is faster — he measured roughly 150 TPS on average through his subscription, versus around 100 TPS for Opus. But it's extremely token-inefficient.

On Cursor Bench, Sonnet 5.5 set another record — this time an unwanted one: 271,920 tokens consumed per task, surpassing Opus's 218k and Gemini 3.8 Flash's 162k, and more than five times GPT-6 Sol and 6 Aster.

The speed advantage gets wiped out by token volume. In the "Fish Slop" game-generation demo test, Sonnet took 43 minutes versus Opus's 36; the gap in raw token generation time was even wider — 39 minutes versus 27. In other words, the faster model was actually slower end-to-end because it had to generate so many more tokens.

Frontend Design: A Clear Weakness

Using Witch.ai, a design showcase tool built by Dara, Theo tested Sonnet 5.5's frontend capabilities — and wasn't impressed. Generated card designs were "ugly," animations were "bad," background lines hurt readability, and scroll behavior had bugs.

By comparison, it's slightly worse than Opus and noticeably worse than Fable. Theo maintains that Fable 5.1 remains the best overall design model, especially for polished frontend work like marketing pages; Opus is more controllable when following design instructions. As for Sonnet 5.5 — "it's still miles ahead of anything from OpenAI or xAI, but it's not the model I'd reach for when doing frontend work," especially given it costs about the same for equivalent tasks.

Its Real Value: A Tool for Other Models

So after all those criticisms — why does Theo still praise this model? The answer: Sonnet 5.5 isn't meant to be called directly by end users. It's meant to be called as a sub-agent by Opus or Fable during orchestration.

Theo validated this with a benchmark he originally designed to evaluate Grok: he had various models perform a deep audit of a massive orchestrator V2 PR in the T3 codebase — hundreds of thousands of lines — breaking it down into an incrementally mergeable strategy. This is an analysis- and architecture-decision-oriented task, not traditional code writing.

The results surprised him: Sonnet's cost was about half of Opus's (as expected), but it scored slightly higher than Opus, producing the best "score per dollar" of any model he's tested on this benchmark. More importantly, Sonnet completed the task in roughly 5 minutes; Opus took nearly twice as long, and Astra (the top scorer) took nearly three times as long.

This has a clear implication: when Opus or Fable picks up a large task and needs to analyze a codebase first, it can call Sonnet to quickly handle that reconnaissance work — and be happy with the result. Theo's theory is that if Opus is properly configured to call Sonnet as a sub-agent at the right moments, Opus "will feel much faster and cost slightly less."

---

Multi-Agent Orchestration Architecture: A Brief Explainer

Multi-agent orchestration represents a major paradigm shift in AI application development: a primary "orchestrator" agent (typically the most capable flagship model) handles high-level task understanding, strategy, and result synthesis, while dynamically dispatching multiple "sub-agents" to handle specific subtasks — code search, file I/O, web scraping, and so on. The core benefit is capability layering: the orchestrator only steps in when high-level reasoning is needed, while repetitive or exploratory preliminary work is handled by faster, cheaper sub-models — reducing both cost and total time. Anthropic's Claude Code natively supports this kind of orchestration, allowing developers to specify which model handles which task type in configuration files. Sonnet 5.5's speed on information-dense preprocessing tasks like codebase auditing makes it a natural fit for the sub-agent role in this architecture.

---

Subscription Value and Why OpenAI Is Losing

Theo also shared real usage data from his subscription: on the $200 Claude Code plan, he runs roughly $2,300 worth of API-equivalent usage per week — nearly $10,000 a month. That's a lot of model capacity.

On the Fish Slop game demo, Sonnet 5.5 used more than 3.5x the input tokens of Opus, but ended up at a similar total cost. And the output quality? "One of the best I've seen" — 3D fish, coral, seaweed, and aliens with recognizable, detailed designs, running at a smooth 120 FPS on his laptop. At API prices that's just $16; through the subscription it's "dirt cheap."

Theo closes by turning on OpenAI: "They lost on every dimension they used to own. Not the smartest model. Not the most efficient. Not the cheapest. Not the best at calling other models." He's direct: the $200 Codex plan delivered far less actual coded output than the same-priced Claude subscription.

Conclusion

Sonnet 5.5 is a fascinating paradox. On benchmarks and sticker price alone, it doesn't dazzle — its frontend is weak, it burns through tokens, and the cost math doesn't favor direct use. But as an orchestration tool within the Opus and Fable ecosystem, it delivers remarkable speed and value on reconnaissance-style tasks like deep codebase auditing and hypothesis validation. As Theo puts it: he wouldn't reach for this model himself very often, but he wants his Opus to — because that's where the real value is hiding.