Opus 5 in production · 01: Claude Opus 5: what it costs, and the one default that breaks old code

$5 in, $25 out per million tokens, and thinking is now on by default, which is enough to truncate a request that worked fine last week. I pointed four Opus 5 agents at my own stack and the first thing they found was a contrast failure on my own primary button.

Late last night I did the thing I tell other people not to do. I opened a session on the new model, handed it four jobs at once, and let it run.

The four jobs weren’t toy jobs. I have a stack of skills that runs my design work and my video work, dozens of files, rules I wrote over months and never went back to read. So I pointed four parallel Opus 5 subagents at all of it and told them to rewrite the whole thing.

Most people meet a new model by asking it to one-shot a landing page, watching it cost more than the last one, and deciding it’s a tax. I did the opposite. I pointed it at files I actually own, where I’d know within thirty seconds if it was making things up.

It came back with a number I didn’t want.

The primary button on my own site, the one that says “Claim a founder slot”, is white text on #3AA5AA. Contrast ratio 2.94 to 1. WCAG AA asks for 4.5 on normal text and 3 on large text. It fails both. I checked it myself afterwards with a contrast tool, because I don’t take a model’s word for a number, and the number held.

I wrote that button. I have looked at it more times than any human being should look at a button.

Update, 2026-07-28. It is fixed in production now. I checked the live CSS before sending this: the failing teal is gone from the bundle. Everything below is still written as it stood the night of the run, because that is when I learned it. Episode 2 has the receipt for the fix.

So this is episode 1 of 3, and it’s the boring useful one: what Opus 5 is, what it costs, and what changed underneath it. The next two are the case studies, and they don’t mean anything if this part isn’t clear first.

Prices are per million tokens, input first, then output. It’s the only unit that matters and the one everyone skips.

Claude Haiku 4.5 (claude-haiku-4-5). $1 in, $5 out. Context window 200K, max output 64K. The small fast one.

Claude Sonnet 5 (claude-sonnet-5). $3 in, $15 out, currently running an intro rate of $2 and $10 through August 31, 2026. Context window 1M, max output 128K.

Claude Opus 5 (claude-opus-5). $5 in, $25 out. Same 1M window and same 128K ceiling as Sonnet. This is the one the series is about.

Claude Fable 5 (claude-fable-5). $10 in, $50 out, sitting above Opus 5 as Anthropic’s most capable widely released model.

So Opus 5 costs five times Haiku on input and half of Fable. That spread is the whole decision and almost nobody makes it on purpose. They pick a model from a dropdown in January and they’re still on it in July.

My session last night, the orchestrator plus the four subagents, moved 54,022,798 tokens including cache reads. That’s not a typo, and it’s why the caching change further down matters more than it sounds.

Opus 4.8 to Opus 5 isn’t a straight swap. Most of the changes are small enough to skim past in a changelog and big enough to break a script that worked fine on Friday.

Thinking is on by default. On Opus 4.8, leaving the thinking parameter out of your request meant no thinking. The same request on Opus 5 thinks. And max_tokens caps the thinking plus the response text together, out of one shared budget, so a call you tuned tightly last week can now run out of room mid-answer. If something of yours started returning half a sentence, start here.

Turning thinking off has a ceiling. Send thinking: {type: "disabled"} with effort set to xhigh or max and you get a 400 back. You can disable thinking up to high effort and no further. The two settings aren’t independent, which isn’t obvious until the error lands on you.

Effort runs a full ladder now. low, medium, high, xhigh, max. Default is high, so the default is already the careful, expensive end of the range.

The prompt cache minimum halved, 1024 tokens down to 512. Prompts that were too short to cache before now cache, and you change nothing to get it. Quietest item on the list, most likely to show up on your bill as a pleasant surprise.

Opus 5 has its own rate-limit bucket. It doesn’t draw on the combined Opus 4.x pool. Moving traffic over neither frees up your old headroom nor inherits it, so you’re planning against two separate ceilings instead of one bigger one.

A refusal arrives as a success. Safety classifiers can return stop_reason: "refusal" on a normal HTTP 200. Code that reads content[0] without checking stop_reason first doesn’t fail on the request. It fails three functions later, holding something nobody ever checked, and it picks the moment.

One more, sideways. There’s a fast mode, speed: "fast", at $10 in and $50 out. Claude API only, so not on Bedrock, Google Cloud, or Foundry. If you run through a cloud provider it just isn’t there for you.

Here’s what the run actually looked like, measured rather than remembered.

Four parallel Opus 5 subagents. 897,194 subagent tokens and 342 tool calls between them. Add the session orchestrating them and it comes to 54,022,798 tokens including cache reads.

Three findings survived my own verification.

The button. White on #3AA5AA at 2.94 to 1, failing both WCAG AA thresholds. The teal stays; the label moves to the per-theme --on-accent token, which measures 6.86 to 1 in dark and 5.61 in light. So the fix is a color value, and it’s a fix I could have made on any random Tuesday in the last two months if anyone had told me.

A skill nobody could search. One of my skills has a searchable database at the center of it. Eleven of its script paths were built on an environment variable that’s empty on my machine, so the whole database was unreachable. It had been unreachable the entire time I’d been using the skill. I never noticed, because a tool that quietly returns nothing looks exactly like a tool with nothing to say.

Eleven contradictions I wrote myself. Between skills, in my own rules. Four of them still said my video theme was dark, three days after I’d ruled it light. My own instructions arguing with my own decision, in writing, while I kept building on top of them.

That was the point where I sat back and went: wait, how much else in here is quietly wrong.

The model didn’t know my button was 2.94 to 1. There’s no version of “knowing” that covers a hex value on a site it has never seen.

It was pointed at real files, and it measured.

Ask a model “is my site accessible?” and you get a competent paragraph about accessibility that would fit any site on earth. Point the same model at the file containing #3AA5AA, give it a way to compute a ratio, and you get 2.94. Same model, same night. The difference is entirely in what you let it reach.

This is the part beginners get wrong and it’s expensive. The instinct is to treat these things as an oracle you consult. They’re closer to a very fast, very literal reader that will examine anything you put in front of it and will confidently invent the rest when you put nothing in front of it.

So the quality of what comes out is mostly a function of what you point it at. Not the prompt. The pointing.

And then you verify. I ran that contrast number myself before writing it down here, and I’d have thrown the finding out if it hadn’t held. A model that’s right eight times out of ten is genuinely useful, and it’s also exactly the shape of thing that will embarrass you in public the week you stop checking.

If you use Claude in the app or in Claude Code, the pricing above is background noise. What you’ll actually feel is that the model thinks before answering now, so it reads slower and more careful. That’s working as intended.

If you call the API, three things, in this order:

1. Go back through every max_tokens you tuned on Opus 4.8. Thinking shares that budget with the answer now.

2. Add a stop_reason check before anything reads content[0]. Costs you four lines.

3. Stop padding short prompts up to 1024 tokens for caching. The floor is 512.

If you’re choosing between models, here’s my split, which is a preference and not a benchmark: Haiku for high volume and simple sorting, Sonnet for most of the day, Opus 5 when the answer has to be right the first time, Fable when the problem is genuinely hard and I’ve already failed at it once.

Tonight I’m pointing Opus 5 at getwireai.com and rebuilding the design. Not a repaint. That button is one item on a list, and the list is the brief. That’s episode 2.

Episode 3 goes at the architecture of Wire AI itself, the Growth Engineer for Mobile Apps. That one is harder and I expect it to go worse, because a design finding has an obvious right answer and an architecture finding usually has three defensible ones and an argument about which.

I don’t know what either run will produce yet. That’s the reason they’re worth writing down. If a run comes back with nothing, I’ll publish that too, and then you’ll know I’m not selling you a model.

If you want the two case studies as they land, subscribe. And if there’s something specific you want me to point it at, reply to this email and tell me, I read those.

I’m Malik. Mobile engineer, 9 years, 7 of them in React Native. I build Wire AI, the Growth Engineer for Mobile Apps, and I write Code Meet AI, where I run the tools on my own work in public and publish the numbers either way.