- Published on
What a Task Costs on Opus 5.5 — And Why Every Team Running AI Agents Should Care
- Authors

- Name
- Vuk Dukic
Founder, AI/ML Engineer

Anthropic just published something rare in AI marketing: a pricing post that reads like an engineering memo instead of a sales pitch. It's called "What a task costs on Opus 5.5," and if you're running Claude in production — whether through Claude Code, an agent pipeline, or a CRM co-pilot like the one we build at Anablock — it's worth actually reading, not skimming.
I want to break down what it says, why it matters more than the headline discount number, and what it should change about how you build with these models.
The Headline Number Isn't the Story
Every outlet covering this launch led with the same figure. Opus 5.5 was released on Tuesday, setting a new state-of-the-art in coding and knowledge work performance, and is significantly cheaper than its predecessor. Specifically, output tokens are charged at $20 per million tokens for Opus 5.5, compared to $25 for the previous model. Input pricing dropped too — the new model costs $4 per million input tokens and $20 per million output tokens, 20% less than Opus 5, with cache reads dropping to $0.20 per million from $0.50 and cache writes falling to $5 from $6.25.
That's a clean 20% price cut across the board. Nice, but not the interesting part.
The interesting part is that Anthropic's own blog post argues the 20% list-price cut understates the real savings. Anthropic puts overall savings closer to 40% because Opus 5.5 uses fewer tokens to complete a task and generates output more than 30% faster. In other words: the price per token went down, and the number of tokens needed to finish the same job also went down. Those two effects compound. That's the whole point of the blog post — it's not selling you a token price, it's teaching you how to actually estimate what a real task costs, because the sticker price on its own tells you almost nothing.
Why "Cost Per Token" Is the Wrong Mental Model
Here's the core insight from the post, and it's one most teams building on top of LLMs get wrong: token price and task price are not the same thing, and the gap between them is where all your money actually goes.
Anthropic breaks down a "typical task" and shows the math. The 60K output tokens of a typical task cost $1.20, the same as reading 6M tokens from cache — and output includes thinking, so you pay for all of it, even when Claude Code only shows you a summary. That last part is the sleeper detail. If your agent is running at high reasoning effort, you're billed for every token of that internal reasoning even though your UI only surfaces the final three-sentence answer. Teams budgeting off the visible output are going to be surprised by the invoice.
Then there's the multi-turn problem, which is the one that actually kills budgets in agentic workflows. The same task run across 25 turns processes about 1.75M tokens and costs about $1.02 in input, because a turn costs more than the tokens it adds — it resends everything before it. So the cheapest turn is the one you don't need. That's not a pricing quirk, it's just how conversational context works: every turn re-sends the full history. An agent that needs 25 back-and-forths to finish a task isn't just slower than one that needs 5 — it's paying for the same context over and over again.
The practical fix Anthropic recommends is one we already push hard internally at Anablock: give the model a way to check its own work — a test to run, a build, or a script that calls the endpoint — because a model that can check its own work finds its mistakes earlier, and a model that gathers what it needs in one pass and batches its tool calls pays the resend fee fewer times too. This is the same principle behind how we design Ana's tool-calling inside the CRM: batch independent lookups, don't make the agent guess-and-check across five sequential turns when it could gather everything it needs once and act.
Caching Is the Single Biggest Lever — By Far
If there's one number from this post I'd put on a whiteboard, it's this one. The same 2.8M input tokens cost $11.20 if none come from cache, but at a 90% hit rate they cost $1.62, and at 96% about $0.99 — no other setting moves input cost this much.
Read that again. Going from a cold cache to a 96% hit rate turns an $11.20 bill into a $0.99 bill. That's an 11x cost swing from a setting most teams never think about, let alone tune. And it doesn't require heroics — a steady session keeps a high hit rate on its own. The lesson: if your agent architecture is randomly reordering system prompts, injecting timestamps into cached blocks, or restructuring context between calls, you're silently torching your cache hit rate and paying for it on every single turn.
This is also where the Opus 5.5 pricing changes get compounding. Input and output tokens are 20% cheaper than on Opus 5, cache reads are 60% cheaper, and the input price falls with the read rate falling too — from a tenth of the input price to a twentieth. Anthropic is explicitly rewarding well-architected, cache-friendly agents more than it's rewarding raw usage. If your system is built to preserve cache continuity, Opus 5.5 gets dramatically cheaper. If it isn't, you're leaving most of the savings on the table.
Effort Is a Cost Dial, Not Just a Quality Dial
The other lever the post highlights is "effort" — how much the model thinks before answering. On Opus 5.5, an output token costs 100 times a cache read, which is why effort — which mostly changes how much the model thinks — moves the bill so much; a model with cheaper cache reads mostly helps long sessions, while one with cheaper output mostly helps tasks that need a lot of reasoning.
Translation for anyone running production agents: don't run every task at maximum reasoning effort by default. A lead-scoring pass, a routine follow-up email, a CRM field cleanup — these don't need the same thinking budget as a multi-file refactor or a complex deal-strategy analysis. Effort should be a per-task setting, not a global default, because it's now one of the most direct cost dials Anthropic gives you.
How This Stacks Up Against the Field
Anthropic isn't operating in a vacuum here, and it's worth being honest about where Opus 5.5 sits against the alternatives, because "Others" — meaning GPT-5.5 and the rest of the frontier field — are the actual decision most engineering leads are making right now.
On raw benchmark performance, independent trackers currently show Claude Opus 5 leads on 38 of 44 shared benchmarks versus GPT-5.5's 6 wins, though pricing snapshots from before the 5.5 cut showed Claude Opus 5 at $5.00 per million input tokens and $25.00 per million output tokens versus GPT-5.5's $5.00/$30.00 — Opus was already cheaper on output before this latest price drop widened the gap further. On agentic coding specifically, Anthropic's own benchmark citation is direct about the delta: on CursorBench, which evaluates coding agents on ambiguous, multi-file tasks taken from real Cursor sessions, Opus 5.5 at default effort scores 52.5%, beating GPT-5.6 Sol's top score of 41.7% by 11 points for about a third of the cost per task.
Third-party coverage backs the "does more with less" framing rather than just repeating the marketing line. One outlet summarized independent testing by noting Opus 5.5 used among the fewest tokens and steps measured across GitHub Copilot CLI and VS Code, solving more terminal tasks than Opus 5 in less than half the steps. Fewer steps means fewer resent-context turns, which loops straight back to the "cheapest turn is the one you don't need" principle from the pricing post itself. The efficiency story and the cost story are the same story.
It's also worth noting the safety framing Anthropic attached to this release, because it's a genuine change in posture, not boilerplate: Opus 5.5 is much less likely than recent models to take hard-to-reverse actions or act outside the boundaries it's been given, and it's more resistant than Opus 5 to prompt injection, with alignment testing broadened to cover longer tasks and impossible tasks. For anyone deploying agents with real write access — CRM updates, email sends, financial actions — that's not a footnote. It's the difference between an agent you can trust to run overnight unattended and one you have to babysit.
What This Means If You're Building Agents
Bringing this back to something actionable, here's what I'd take from Anthropic's own breakdown if you're running Claude in any agentic system:
- Measure task cost, not token cost. A cheap-looking per-token price can still produce an expensive task if your agent needs 25 turns to finish.
- Design for cache continuity. Stable system prompts, consistent tool ordering, and avoiding unnecessary context churn between calls can be an order-of-magnitude cost difference — not a rounding error.
- Give agents self-verification tools. Tests, build scripts, endpoint calls — anything that lets the model catch its own mistakes cuts the turn count, and turn count is where the real cost hides.
- Tune effort per task, not globally. Not every task needs maximum reasoning. Treat effort as a cost lever the same way you'd treat model selection.
- Batch tool calls. Gathering everything needed in one pass instead of guessing-and-checking across turns pays the "resend tax" fewer times.
This is exactly the philosophy we've built into Ana, Anablock's AI co-pilot inside our CRM. Independent tool calls get batched in a single pass. Context is kept stable across a session instead of being reshuffled turn to turn. Reasoning effort scales with the actual complexity of the task — a quick contact lookup doesn't burn the same budget as a multi-step outreach sequence. The pricing mechanics Anthropic just made public are the same ones we've been optimizing against quietly for a while, because they were true well before this blog post spelled them out — they're just harder to see until someone shows you the receipts.
If you're evaluating whether your team's AI spend is actually buying you leverage or just quietly padding a bill nobody's looking at closely, it will be well worth your time to schedule a meeting to learn more about how we architect for this inside Anablock CRM. Reach out here: https://anablock.com/contact-us
— Vuk Dukic, Founder, Anablock