AI Costs 75% Less? What Claude Haiku 5.5 Should—and Shouldn't—Run

Anthropic says Claude Haiku 5.5 costs about 75% less to run than Haiku 4.5 on average. That is a striking headline, but it does not mean every Claude workload suddenly costs one quarter as much. The saving depends on prompt length, output length, effort settings, caching, and whether the task is narrow enough for a small model.

The useful story is not “cheap AI replaces expensive AI.” It is that production agents can now route a much larger share of routine work to a fast, inexpensive model—if the system knows when to escalate.

What actually became cheaper

For prompts up to 100,000 tokens, Anthropic lists Haiku 5.5 at $0.10 per million input tokens and $0.50 per million output tokens. Prompts above that threshold cost more. Cache reads and writes are also priced separately, so the final bill depends heavily on how an application reuses context.

That pricing structure matters more than the headline percentage. Input tokens are cheap relative to output tokens, which means the shape of a workload changes the economics. A pipeline that ingests long documents and emits short structured answers sits at the favorable end of the curve. A pipeline that asks for long prose, extended reasoning traces, or verbose tool-call transcripts sits at the expensive end, because output is five times the input rate even before any long-context surcharge applies. Two teams can both “use Haiku 5.5” and see wildly different bills depending on which of those shapes their traffic resembles.

Caching deserves separate attention because it can dominate real production costs in either direction. Applications that repeatedly send the same system prompt, policy document, or tool schema can amortize that context across many calls; applications that rebuild context from scratch on every request pay full freight each time. The 75% figure is an average across Anthropic’s own assumptions, and averages hide exactly this kind of variance. Before trusting it, a team should model its own prompt-to-output ratio, its cache hit rate, and how often it crosses the 100,000-token boundary where pricing steps up.

Anthropic positions the model for summarization, classification, database lookups, browser operation, live support, context compaction, and tightly scoped subagent tasks. Those are high-volume jobs where latency and cost often matter more than frontier reasoning.

The company also introduced adjustable effort for a Haiku-class model. Lower effort can reduce cost and latency; higher effort can spend more reasoning on difficult requests. That flexibility is valuable, but it makes the “75% less” figure a starting point rather than a universal guarantee.

Effort settings are the mechanism behind much of the flexibility, and they are also the mechanism behind much of the uncertainty. A system that dials effort down to save money is making a quality trade on every request, and the right setting is rarely uniform across a task class. Classification may tolerate the lowest effort; extraction from messy documents may not. The practical implication is that effort should be a per-task configuration, tuned against measured accuracy, rather than a global default chosen once and forgotten.

The benchmark claim needs context

Anthropic reports that Haiku 5.5 scored 72.4% on the offline subset of OSWorld 2.1, compared with 15.7% for Haiku 4.5 and 48.9% for GPT-6 Luna. It also reports large improvements on coding and knowledge-work evaluations.

The jump from 15.7% to 72.4% is the kind of number that invites over-reading. It says the new model is dramatically better at the specific browser-and-desktop tasks in that offline subset, and that it now clears a competitor that previously sat between the two Haiku generations. It does not say the model is right three times out of four on your workflows, because the benchmark’s tasks, interfaces, and failure modes are not yours.

These are vendor-run evaluations. They are useful evidence, but they are not a substitute for testing the exact prompts, tools, permissions, and failure costs in a real application. A browser agent that succeeds on a benchmark can still click the wrong customer record, misread a changed interface, or confidently summarize stale data.

The more important limitation appears in Anthropic’s own positioning: Sonnet and Opus remain better choices for complex agentic coding and open-ended work. Haiku is designed to be a workhorse, not the final judge for every task.

That self-imposed ceiling is worth taking seriously precisely because it comes from the vendor. Companies have an obvious incentive to claim a small model can do everything; Anthropic is instead drawing a line between narrow, high-volume work and open-ended reasoning. Buyers should treat that line as a design constraint, not a marketing hedge.

Where Haiku 5.5 makes sense

The strongest deployment pattern is a small-model-first router:

1. Haiku handles classification, retrieval, extraction, formatting, and routine tool calls.
2. The system checks confidence, policy risk, and task complexity.
3. Ambiguous or high-impact cases escalate to a larger model or a human.
4. Logs compare cost, latency, and correction rates by task class.

This can reduce spending without blindly trading away quality. Customer-support triage, bug labeling, structured data extraction, document compaction, and repetitive browser steps are good candidates. Legal conclusions, security-sensitive actions, financial decisions, and unfamiliar multi-step debugging should have a higher escalation threshold.

The router itself is the hard part, and it is where most of the engineering effort will land. Confidence signals from a small model are not automatically trustworthy—a model can be confidently wrong—so the escalation check usually needs external evidence: schema validation on extracted fields, policy rules that flag risky actions, disagreement between two cheap passes, or a retrieval step that confirms the source actually contains the claimed fact. None of that is free, and its cost belongs in the same ledger as the token bill.

There is also a counter-argument worth weighing. Routing adds latency and complexity, and a mis-tuned threshold can quietly degrade quality while the invoice looks great. Some teams will find that a single mid-tier model, used consistently, is simpler to operate and cheaper in total once orchestration, monitoring, and incident response are counted. The small-model-first pattern wins when volume is high, tasks are genuinely repetitive, and the escalation path is well instrumented—not merely because the per-token price is low.

The metric that matters is corrected cost

Token price alone can be misleading. A cheap model that requires repeated retries or human repair may cost more than a larger model that finishes correctly once.

Teams should track cost per accepted result, not only cost per call. That means measuring:

• first-pass success rate;
• retry and escalation rate;
• human correction time;
• latency at the 95th percentile;
• incidents caused by incorrect tool use;
• savings after cache and long-context charges.

If Haiku completes 80% of routine tasks correctly and escalates the rest, the economics can be excellent. If it silently produces plausible but wrong outputs, the low token price becomes irrelevant.

The word “silently” carries most of the weight here. Escalation failures are visible and measurable; silent errors are not, and they tend to surface later as customer complaints, reconciled spreadsheets, or audit findings. That is why the logging requirement in the router pattern is not optional bookkeeping. Comparing cost, latency, and correction rates by task class is how a team discovers that a task it assumed was routine is actually producing a slow drip of repairs—and how it catches that before the savings claim hardens into policy.

For the reader weighing a migration, the practical sequence is unglamorous: pick a narrow task class, run it against the exact prompts and tools in production, measure accepted results rather than calls, and only then decide whether the 75% headline survives contact with your own traffic. The number is real as an average. Whether it is real for you is an empirical question, and the tools to answer it are the same ones that make the routing architecture safe in the first place.

Verdict

Claude Haiku 5.5 makes multi-agent systems cheaper because it gives developers a credible default worker for narrow, frequent tasks. It should not become the universal brain of the system.

The winning architecture is not “replace every model with Haiku.” It is “send each task to the cheapest model that can complete it reliably, then prove that routing decision with production data.”