I Made Opus 5 My Only Model. I'm Never Going Back.
In this article
> **Bottom line:** After six weeks running Claude Opus 5 as the only model across my coding, writing, and ops work — dropping the Sonnet-for-cheap-tasks routing I'd used for two years — my token spend went up 23%, but my rework rate (tasks I had to redo because the first model got it wrong) dropped from roughly 1 in 4 to under 1 in 15.
The math isn't close: engineering time is the expensive resource, not tokens.
If you're still running a router that shuffles requests between cheap and expensive models based on "task complexity," you're optimizing for the wrong line item.
I deleted my model-routing config on a Tuesday. Not because it broke — because I finally did the math on what it was costing me in silent rework, and the number embarrassed me.
I'm serious. For two years I ran what I thought was a smart setup: Haiku for quick lookups, Sonnet for day-to-day coding, Opus reserved for "hard" problems I'd manually flag. It felt efficient.
It felt like good engineering discipline — use the right tool for the job, don't waste spend on a bigger model when a smaller one will do.
It was actually costing me hours every week that I never tracked, because the cost showed up as "huh, that's not quite right, let me try again" instead of a line item on an invoice.
The Setup: Why I Was Routing Models in the First Place
I run infrastructure for a mid-size SaaS company, and I use AI tooling constantly — Claude Code for the bulk of my day, plus scripted agents for log triage, incident postmortems, and IaC review.
Back in early 2025, when Sonnet 3.5 was the workhorse and Opus was slow and expensive by comparison, routing made sense. You didn't put a research-grade model on "rename this variable across 40 files."
That habit stuck even as the models changed underneath it.
By the time Opus 5 shipped, I was still running the same routing logic I'd built a year and a half earlier — a pile of heuristics deciding which requests were "worth" the bigger model.
Multi-file refactors and architecture decisions went to Opus. Everything else — quick edits, log parsing, routine PR reviews — got routed to Sonnet or Haiku to save cost.
The problem is that "everything else" turned out to be where most of my silent failures were hiding. Not catastrophic failures — subtle ones.
A Sonnet-generated Terraform diff that was 95% right but missed a lifecycle block.
A log-triage summary that flagged the wrong service as the root cause because it didn't hold enough context from three related incidents.
Small misses that cost me 20 minutes of "wait, that's not right" each time, dozens of times a week.
The Core Insight: Rework Is the Hidden Cost Nobody Tracks
I started logging something I'd never bothered to measure: how often I had to go back and redo a task because the model's first answer was wrong, incomplete, or missed context I'd assumed it would catch.
Not "the model said something dumb" — genuinely how often the deliverable needed a second real pass.
The two-week baseline
Over two weeks with my old routing setup, I tracked 140 discrete tasks — PR reviews, incident summaries, config generation, code migrations. **34 of them (24%) needed meaningful rework.** Not typos.
Actual re-runs where I had to re-prompt with more context, fix a logic error, or catch something the model missed that a more careful pass would've caught the first time.
Then I ran the same category of tasks — same 148-task shape, different two-week window — with Opus 5 as the only model, no routing, no "is this worth it" heuristic.
**Rework dropped to 9 out of 148 tasks — roughly 6%.**
Why the gap is bigger than a benchmark score
Here's the part that actually matters for infrastructure work specifically: our tasks are rarely self-contained.
A "simple" log-triage request usually depends on knowing what changed in the last deploy, what three other services look like, and what the on-call channel said an hour ago.
Smaller models handle isolated tasks fine. They degrade fast the moment a task needs to hold five loosely related facts in its head at once and reason across all of them without dropping one.
Opus 5's jump isn't really "it's smarter" in the abstract sense benchmarks measure.
It's that it holds context and doesn't quietly drop the thread halfway through a long agentic tool-use chain — which is exactly the shape of most real ops work. Terraform plans that touch six modules.
Incident postmortems that span three services and two on-call handoffs. A PR review that needs to reason about a caching layer three files away from the diff.
The token math, honestly
My monthly token spend went up 23% moving everything to Opus 5. That's real — I'm not going to pretend otherwise, and if you're running this at scale with a real budget line, model cost is not nothing.
But 34 reworked tasks at even a conservative 15 minutes each is **8.5 hours a month** of my time.
My time costs more per hour than the entire token bill difference, and that's before counting the cost of a bad Terraform apply reaching production instead of getting caught in review.
**The token line item is the visible cost. The rework line item is the real one, and it was 10x bigger.**
The Reality Check: Where This Falls Apart
I want to be straight about where "just use the big model for everything" stops being good advice, because it isn't universally true and I'd be overselling if I said otherwise.
**Pure volume batch jobs** are the obvious exception.
If you're classifying 50,000 support tickets or running a regex-adjacent extraction task across a huge dataset, Haiku 4.5 at a fraction of the cost is still the right call — the task doesn't need deep reasoning, it needs throughput, and paying Opus pricing for that is just waste.
**Latency-sensitive, user-facing paths** are another one.
If a model call sits in the critical path of a product feature and users are watching a spinner, Opus 5's extra reasoning time can be a real UX cost that a faster model avoids.
I still route our customer-facing chatbot through Sonnet 5 for that reason.
And I'll say the quiet part: some of my old routing setup was genuinely fine.
Simple, single-file edits with no cross-context dependency didn't get worse with Sonnet — they were fine before and they're fine now.
The 24% rework rate wasn't evenly distributed across all task types.
It was concentrated almost entirely in multi-context, agentic, "hold five things in your head" work — which, it turns out, is most of what infrastructure engineering actually is.
The Practical Takeaway: Stop Routing on Guesses
If you're maintaining a model router based on manually-guessed "task complexity," here's what I'd actually do instead of trusting your gut the way I did for two years:
- **Log rework, not just cost.** Track every time you re-prompt or manually fix a model's output. Two weeks of honest logging will tell you more than any benchmark comparison.
- **Route on context shape, not perceived difficulty.** The real signal isn't "is this task hard" — it's "does this task need the model to hold multiple related facts across files, services, or time." That's the category where cheaper models quietly degrade.
- **Keep small models for genuinely isolated, high-volume work.** Batch classification, simple formatting, single-file mechanical edits — Haiku 4.5 or equivalent is still the right tool there, no argument.
- **Re-run your own baseline whenever a new model ships.** The routing logic I built for Sonnet 3.5-era models was stale by the time Opus 5 existed.
Assumptions about "when the big model is worth it" have a shelf life measured in months, not years.
I'm not telling you every team should rip out their routing config tomorrow.
I'm telling you to actually measure the rework cost before you assume your routing is saving you money — because mine wasn't, and I'd been confidently telling people it was for two years.
Have you actually measured how often your "efficient" model choice sends you back for a second pass, or are you assuming the savings are real the same way I did?
I'd genuinely like to know what your numbers look like — drop them in the comments.
---
