Sonnet 5 Pricing: Rebuild Your Agent Math

By Lazar Milicevic · Published July 1, 2026 · 9 min read

Your agent stack was priced around Sonnet 4 or Opus for the hard steps and a cheaper model for the easy ones. That routing math just changed. If you're running production agents on Anthropic — or you shelved a project because Opus-tier costs made the unit economics ugly — Sonnet 5 forces a fresh look at what you route where, and whether the whole "cheap model for planning, expensive model for reasoning" pattern still holds.

This post is for the solo builder or small ops team running real agent workloads. I'll cover what actually changed, how to re-cost your pipeline without rewriting it, where Sonnet 5 breaks existing routing logic, and the failure modes I've already seen in the first pass of migrations.

What Anthropic actually shipped

Anthropic released Claude Sonnet 5, positioned as near-flagship agentic performance at mid-tier pricing. The pitch is straightforward: enterprise developers get Opus-adjacent capability on tool use, long-horizon tasks, and code without paying flagship rates per million tokens. The launch lands while Anthropic moves toward an IPO, and pricing pressure from OpenAI, Google, and open-weight competitors makes "cheaper capable model" the obvious next lever.

For SMB builders, three things matter more than the launch narrative:

1. The gap between mid-tier and flagship narrowed on agentic benchmarks. Anthropic's own reporting emphasizes tool-calling, multi-step reasoning, and coding tasks — the exact workloads that were forcing us to use Opus.
2. Sonnet-tier pricing means it fits in existing per-request budgets. Most of the router logic I wrote in 2025 assumed Sonnet was "good enough for 80% of steps." Now it's plausibly good enough for 95%.
3. Prompt caching and batch pricing still apply. The published per-token rate isn't the number you should be optimizing against — effective cost after caching is.

I'm deliberately not quoting per-million-token prices here. Check the current Anthropic pricing page before you build a spreadsheet. Pricing has moved twice in twelve months across the industry, and any number I write today will be wrong by the time this post is a quarter old.

Why this breaks your existing routing logic

Most production agent stacks I audit look something like this:

def route(step):
    if step.type == "classification":
        return "haiku"
    if step.type in ("planning", "tool_call"):
        return "sonnet-4"
    if step.type in ("code_generation", "long_reasoning"):
        return "opus-4"

That pattern made sense when Opus was meaningfully better on hard reasoning and Sonnet meaningfully cheaper. Sonnet 5 collapses the middle tier upward. In practice, three routing rules I've relied on for a year are now suspect:

• "Escalate to Opus on retries." If Sonnet 5 hits the same task quality on the first try, the retry logic just doubles cost for no accuracy gain.
• "Opus for the final synthesis step." Multi-agent systems often reserved Opus for the last consolidation call. Test whether Sonnet 5 produces the same synthesis. In several pipelines I've re-run, it does.
• "Sonnet for planning, Opus for execution." This inversion (cheap plan, expensive act) may flip entirely — plan on Sonnet 5, and only escalate execution when a specific tool call fails validation.

The concrete action: before you touch code, dump one week of production traces, tag which model handled which step, and replay the top 20 most expensive traces against Sonnet 5. If quality holds, you have a rewrite target.

A practical re-costing workflow

Don't guess at savings. Measure them. Here's the workflow I run for clients when a new model tier drops:

Step 1 — Export a representative sample. Pull 200–500 real traces from the last 14 days. Not synthetic tests, not the eval suite. Actual user requests.

Step 2 — Replay against the new model. Keep everything else identical: same prompts, same tools, same temperature. Only swap the model ID.

import anthropic

client = anthropic.Anthropic()

def replay(trace, new_model):
    return client.messages.create(
        model=new_model,
        max_tokens=trace.max_tokens,
        system=trace.system,
        tools=trace.tools,
        messages=trace.messages,
    )

results = []
for trace in production_traces:
    baseline = trace.completion  # what Opus/Sonnet-4 returned
    candidate = replay(trace, "claude-sonnet-5")
    results.append({
        "trace_id": trace.id,
        "baseline_tokens": trace.usage,
        "candidate_tokens": candidate.usage,
        "baseline_output": baseline,
        "candidate_output": candidate.content,
    })

Step 3 — Score with a judge model. Use a separate model (or Opus itself) to compare baseline vs candidate on a rubric specific to your task: correctness, tool-call validity, format adherence. Do not eyeball 500 outputs.

Step 4 — Compute cost and quality deltas. You want two numbers per trace type: percent cost reduction and percent quality retention. A 40% cost cut with 98% quality retention is a clear migrate. A 60% cost cut with 82% retention is a hybrid case — route the easy variants of that task type to Sonnet 5, keep the hard ones on Opus.

Step 5 — Ship the router change behind a flag. Roll to 10% of traffic, watch a week of metrics that matter for your product (task completion rate, human intervention rate, refund/complaint rate), then expand.

The whole exercise is two to four days of work for a solo builder. It pays for itself the first month if you run any meaningful volume.

Where Sonnet 5 will and won't save you money

Not every workload benefits equally. From migrations I've watched and run:

The pattern: agentic workloads that were forced onto Opus for reliability, not raw intelligence, are the biggest winners. Anywhere Haiku was already sufficient, nothing changes. Anywhere Opus was picked for a specific hard-reasoning gap (deep refactors, novel math, complex legal reasoning), verify before you migrate — the gap narrowed, but it hasn't fully closed.

The IPO context nobody should ignore

Anthropic isn't dropping mid-tier pricing out of generosity. A pre-IPO lab needs revenue growth curves that justify private valuations, and the fastest way to grow API revenue is to expand the addressable workload — meaning: make it economically viable to run agents on tasks that were previously too expensive.

For builders, this cuts two ways.

The good part: you get to run workloads that didn't pencil out before. Automated customer support that reads full ticket history plus knowledge base. Sales agents that qualify leads with real research. Internal ops bots that actually chain five tool calls without you flinching at the bill. These stop being pilot projects and become production line items.

The part to plan for: pricing this aggressive during a run-up to a public listing can move again after. Not necessarily upward — competition from Google, OpenAI, and open-weight models pushes the other way — but the specific structure of discounts, batch rates, and caching bonuses is not a permanent contract. Build your agent architecture so the model ID is a config value, not a hardcoded assumption. If you're spending real money on a single provider, keep at least a shadow evaluation running against one competitor so you can switch in a week, not a quarter.

I've written before about how Make.com's pricing collapses at 10K ops — the same discipline applies to model providers. Every abstraction layer between your business logic and the vendor's SKU is insurance.

Failure modes I'm already seeing

First-pass migrations tend to fail the same three ways. Watch for them.

Silent quality regressions. Sonnet 5 will produce plausible output on 100% of your traces. Some fraction of that plausible output will be subtly worse — a missed edge case in a tool call, a slightly weaker chain of reasoning, an occasional formatting drift. Without an automated judge or a downstream metric that catches quality, you won't notice until users do. Do not migrate without a scoring harness in place.

Token count creep. Newer models sometimes generate more verbose reasoning or more elaborate tool arguments. Your per-token price dropped, but total tokens per task went up. Track cost per completed task, not cost per million tokens.

Cache invalidation on migration. If you were relying heavily on prompt caching with Sonnet 4, switching to Sonnet 5 invalidates those caches. Your first week of Sonnet 5 will look more expensive than steady-state. Warm the caches before you compare.

Here's a minimal cost-per-task logger I add to any client project on migration day:

import time, json

def log_run(task_type, model, usage, wall_ms, success):
    cost = (
        usage.input_tokens * PRICE[model]["in"]
        + usage.output_tokens * PRICE[model]["out"]
        + usage.cache_read_input_tokens * PRICE[model]["cache_read"]
    )
    with open("runs.jsonl", "a") as f:
        f.write(json.dumps({
            "ts": time.time(),
            "task_type": task_type,
            "model": model,
            "cost_usd": cost,
            "wall_ms": wall_ms,
            "success": success,
        }) + "\n")

Cost per successful task, split by model and task type, is the only number that matters at the end of the migration. Everything else is vanity.

A concrete migration checklist

For a solo builder or small team running production agents today, here's the sequence I'd run this month:

week_1:
  - export production traces (7-14 days, min 200 samples)
  - build or reuse LLM judge harness for your task types
  - baseline current cost per successful task, by task type
week_2:
  - replay top-cost task types on Sonnet 5
  - score quality retention with judge
  - identify migrate / hybrid / hold buckets
week_3:
  - implement router change behind feature flag
  - roll to 10% traffic
  - monitor: task success rate, human intervention rate, cost per task
week_4:
  - expand to 50%, then 100% if metrics hold
  - document routing decisions and thresholds
  - schedule a re-evaluation for the next model release

If you're on a heavier stack, the same sequence applies — just budget more time for eval harness work. The single biggest mistake teams make is skipping the eval step and migrating on vibes. Vibes are how you end up with 20% higher user complaints and no idea why.

For deeper background on picking the right orchestration layer under this router, my write-up on Make.com vs n8n for AI agents walks through the trade-offs that survive any model change.

How BizFlowAI approaches this

This is the kind of work we already do for clients: taking an existing agent stack — whether it's a Make.com scenario, an n8n workflow, or bespoke Python — and re-costing it against the current model landscape. When a new tier lands, we run the replay-and-score workflow above, ship the router change behind a flag, and hand back a spreadsheet showing cost per completed task before and after. No mystery, no "trust us."

If Sonnet 5's pricing changed your agent roadmap — or unblocked something you had shelved as too expensive — book a discovery call and we'll recost the roadmap together. Bring one workflow, real trace data if you have it, and we'll walk out with a concrete before/after estimate.

What to do this week

If you take one thing from this post: don't rewrite anything yet. Measure first. Pull traces, build the judge, replay against Sonnet 5, score quality retention, then decide. The whole exercise is small enough for a solo builder to run in a week, and the routing changes it surfaces usually pay for a quarter of runway.

The launch itself is less interesting than what it signals: mid-tier model pricing will keep compressing the case for flagship-only architectures. Build your stack so the model ID is a swap, not a rewrite, and the next launch — from Anthropic or a competitor — becomes an opportunity instead of a fire drill.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Book a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.