Anthropic Surprise-Launches Sonnet 5.5: Impressive, But You Probably Shouldn't Use It Directly

Anthropic has been moving at a relentless pace. From Fable 5.1 — dubbed "the best coding model ever" by Theo — to Opus 5.5 taking over nearly everyone's workflow, to this unannounced drop of Sonnet 5.5: the company is applying precise, sustained pressure on OpenAI through sheer product velocity.

What makes Sonnet 5.5 particularly interesting is that Theo (t3.gg) — one of the most respected AI benchmarkers around — describes it as a model "full of contradictions": excellent in its own right, yet he explicitly recommends most people "don't use it directly." The reasoning behind that advice reveals a lot about the real competitive landscape of AI coding models today.

Sonnet's Comeback: From "Garbage Tier" to a Genuine Surprise

Sonnet 5 was one of Theo's least favorite model releases — he described it outright as "garbage tier." Because of that, he'd planned to skip Sonnet 5.5 entirely and not even make a video about it, given how thoroughly Opus 5.5 had already won him over.

But he admits he was wrong. Sonnet 5.5 scored a record-breaking 70.6% on Terminal Bench 4 — a sevenfold leap from Sonnet 5's 10.3%. The number is so high that Theo himself started questioning the validity of Terminal Bench as a benchmark. It's also the first Sonnet model to complete Pokémon Red from screenshots alone.

Theo's take is vivid: "These models now feel like a slightly dumber but much faster version of Fable." He suspects Anthropic (jokingly called "InfraOpix" in the video) recently had an internal breakthrough in reinforcement learning — previously, smaller models outside the very top tier always felt like "robots mechanically executing tasks," while Sonnet now has the quality of actually understanding what it's doing. Anthropic has also been actively removing the infamous "Claude-isms" from outputs, making Sonnet 5.5's responses cleaner and more collaborative.

The Pricing Trap: Cache Read Costs Are the Hidden Catch

Anthropic officially claims Sonnet 5.5 is "30% faster and 30% cheaper than its predecessor," with pricing at $2 per million input tokens and $10 per million output tokens. But Theo doesn't hold back in pointing out that this framing "deliberately buries the important detail" — specifically around cache read token pricing.

The crux: in modern agentic coding workflows, cache reads and writes are where the majority of your costs actually live. Fable 5.1 cut cache read costs by 90%, Opus cut them by roughly 60% — but Sonnet 5.5's cache read price remains unchanged at $0.20 per million tokens.

Theo runs the numbers to make the point concrete: as you move down the model tier, cache reads represent an ever-larger share of total cost. On Fable that share is under 5%; on Opus it's around 20%; on Sonnet 5.5 it balloons to over 50%. The result: for the same real-world workload, Sonnet 5.5 ends up costing "about the same as Opus, or even more." By Artificial Analysis's intelligence index, Sonnet 5.5's cost on real tasks is roughly on par with the higher-tier Fable 5.1.

---

Prompt Caching is the foundational concept you need to understand this cost analysis. When a large language model processes a request, it must recompute attention over every input token from scratch — an expensive and time-consuming operation. Prompt caching allows the model to store intermediate computation results for repeated context — system prompts, codebase content, conversation history — so subsequent requests can reuse them, skipping the redundant computation. In agentic coding workflows, each invocation carries large amounts of identical context (like full codebase snippets), meaning cache read volume and token count often vastly exceed fresh input. This makes the cache read price the dominant variable in your actual bill, far more than the headline input/output rates. The stark differences in how Anthropic prices cache reads across models is precisely what allows Sonnet 5.5 to end up more expensive in practice despite appearing similarly priced on paper.

---

Never Touch Max Mode

Theo dedicates a significant portion of the video to "blasting" the Max reasoning mode — and it's one of the core technical reasons behind his "don't use it" recommendation.

He explains that reasoning tiers (low/medium/high/x-high) are fundamentally budget ceilings — they set the maximum amount of thinking the model is allowed to do. Max mode breaks this logic entirely: instead of raising the ceiling, it raises the floor, forcing the model to consume a minimum number of thinking tokens regardless of task complexity.

The results are extreme. Theo's testing shows token usage grows only about 5% going from low to x-high — but jumping from x-high to Max causes a 1,500% increase, or 15x. Worse still, forcing the model to over-think actually hurts performance: the model starts second-guessing itself and getting simple questions wrong.

Benchmark data backs this up. Running Sonnet 5.5 at Max tier on a benchmark cost $7.60 — more than double the competing Astra — while the same task on high cost $1.08, and medium just $0.59. Theo's advice is blunt: "Pretend Max mode doesn't exist and your life will be much easier." He also cautions that Anthropic models perform poorly at low (the no-thinking option has even been removed), so the guidance is: "skip low, skip Max — medium is generally fine."

---

Anthropic's Extended Thinking feature allows the model to generate a hidden chain-of-thought before producing its final answer — these internal reasoning steps consume what are called thinking tokens. The reasoning tiers (low/medium/high/x-high) set budget ceilings on this token count, letting the model draw on reasoning as needed without over-spending on simple problems. Max mode inverts this logic entirely: it becomes a floor instead of a ceiling, mandating large thinking token consumption regardless of task difficulty. The result is a model that repeatedly second-guesses and re-verifies tasks it could have answered directly — costs skyrocket while accuracy can actually drop. This "forced overthinking" maps closely to the cognitive science concept of analysis paralysis, and it's the fundamental reason Theo recommends ignoring Max mode completely.

---

The Real Value: It's a Tool for Other Models to Call

So why does Theo actually like this model? His answer is counterintuitive: "I don't think you or I should be directly selecting this model."

Sonnet 5.5's true purpose is to serve as a sub-agent that Opus or Fable can invoke when breaking down complex tasks. It shouldn't be called directly by the user — it should be a node in an orchestration pipeline.

Theo validated this with a codebase deep-audit benchmark. He had various models perform a deep analysis of a massive "orchestrator V2" PR in the T3 codebase (hundreds of thousands of lines of code), generating a strategy for how to break it down and ship it. This isn't traditional coding — it's analytical work that requires traversing enormous amounts of code, making architectural judgments, and explaining findings clearly.

The results surprised him: Sonnet 5.5 performed slightly better than Opus at half the cost, and crucially finished in about 5 minutes — roughly half the time Opus took, and a third of the time Astra (the best-quality analysis) needed. "The cost-per-point is absurdly low — the best value I've seen in this benchmark."

He also shared a compelling real-world example: while rewriting a TypeScript compiler in Rust, he asked the model to clean up legacy "slop" code. In a thread full of numeric discussion, when asked about progress mid-thread, Sonnet didn't force-guess his intent — it made a reasonable inference from the thread context. The task ultimately deleted roughly 1.6 million lines of code. Intent and context comprehension, clearly working.

---

Multi-Agent Orchestration is the dominant architecture paradigm for complex AI tasks today. In this model, an Orchestrator handles goal understanding, task decomposition, and sub-task assignment, while multiple Sub-agents handle specific operations — code search, file read/write, API calls, etc. The advantage is clear: the orchestrator can use the strongest, most expensive model to guarantee planning quality, while sub-agents can be chosen for best cost-efficiency on their specific sub-tasks. Sonnet 5.5's combination of speed, low cost, and near-Opus accuracy on codebase analysis makes it an ideal investigative sub-agent — one that can traverse large codebases, aggregate information, and return findings to an upstream Opus or Fable for final decision-making. This is precisely why Theo argues "you shouldn't use it directly": its maximum value is unlocked inside an orchestration system, not as a user-facing conversational interface.

---

Frontend Design Remains a Weak Spot — But the Fish Game Demo Impresses

On the Witch.ai design showcase platform, Sonnet 5.5's frontend output is underwhelming — cards described as "ugly," animations as "terrible," background lines hurting readability. Theo sees it as "clearly worse than Opus, and far worse than Fable." He still considers Fable 5.1 the gold standard for design, with Opus winning on steerability and instruction-following.

But on the "fish slop" game generation demo, Sonnet 5.5 delivered what Theo called "one of the best results I've seen": cute 3D fish, coral, seaweed, even the best-looking alien of the bunch — the whole game running at a silky 120 FPS on his laptop.

Speed and token efficiency, however, are another sore point. Sonnet 5.5 set yet another record in Cursor Bench — this time for token consumption, at 270,000 tokens per task. That's nearly double Gemini 3.8 Flash and more than 5x GPT-6 Sol. Despite the higher generation speed (~150 TPS vs Opus's ~100 TPS), the token bloat means the fish slop task actually took longer than Opus: 43 minutes for Sonnet vs. 36 for Opus.

OpenAI's Position: Falling Behind Across the Board

Theo repeatedly notes this model "is basically aimed directly at OpenAI," and particularly at GPT-6 Sol. His assessment of Sol is cold — "DOA (dead on arrival)," barely worth discussing in the video.

His summary is sharp: OpenAI is losing on every axis it used to own. "They don't have the smartest model, the most efficient model, the cheapest model, or the best model for orchestrating other models." From a subscription value standpoint, a $200 Codex subscription produces far less actual coding output than his $200 Claude subscription (which he estimates gets him roughly $2,300 worth of usage per week).

The conclusion: you don't need to personally reach for Sonnet 5.5, but it's an excellent piece of the new model family. If you configure things correctly so that Opus calls Sonnet at the right moments — deep codebase dives, hypothesis validation, investigative groundwork — Opus as a whole will feel faster and cost less. And that is precisely what Sonnet 5.5 is here to do.