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.

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.

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.

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.

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 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.

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.”