Send the cheap work to Haiku before you burn Sonnet tokens
Claude Haiku 5.5 shipped October 7, 2026 aimed at high-volume classification, routing, summaries, and subagent work at a much lower list price than Haiku 4.5. Before you point every call at your biggest model, split the jobs that only need a fast, bounded answer.
If your bill is mostly Sonnet tokens spent on small jobs, Anthropic's October 7, 2026 Haiku 5.5 launch gives you a cheaper lane: list the calls that are short, repetitive, and low-consequence; route those to Haiku 5.5 with an explicit escalation path to Sonnet or Opus; recount tokens on the new tokenizer; and measure cost per successful task, including retries. Keep the 100K-token price tier visible so long prompts do not silently jump tiers.
Start with the call list, not the model card
Open last month's LLM usage export—or the proxy logs if that is what you have. Sort by call volume. You are looking for the boring majority: classify this ticket, extract these three fields, summarize this short thread, pick the next tool name, compact the context before the big step.
Those calls do not need your most expensive model every time. Claude Haiku 5.5, announced by Anthropic on October 7, 2026, is explicitly aimed at high-volume, cost-sensitive work such as summaries, classification, routing, compaction, and subagent tasks, with list prices much lower than Haiku 4.5 for prompts under 100K tokens. This note is operating guidance from those public docs—not a claim we load-tested Haiku 5.5 on your traffic.
The expensive model should meet the hard step, not every step.
Teams that start from the model card tend to "try Haiku on everything" for a week and then declare it uneven. Starting from the call list keeps the experiment honest: you already know which jobs are repetitive. Haiku 5.5's published strengths map to those jobs; your logs tell you which rows qualify.
How the work moves
Cost-routing walk for one workflow
- Inventory
Rank call shapes by volume from last month's logs.
- Bound
Write success criteria and escalate conditions.
- Route
Send eligible calls to Haiku 5.5; others stay on the large model.
- Measure
Track cost per success, escalate rate, and tier crossings.
- Rollback
Keep a one-switch return to the previous model.
Draw the cheap / escalate line
For each high-volume job, write two columns: what "good enough" means, and what must escalate. Good enough might be "intent is one of these eight labels" or "return JSON with these keys." Escalate when confidence is low, the input is hostile or ambiguous, money moves, or a customer-facing promise is at stake.
Wire the escalate path to Sonnet 5.5 or Opus 5.5 (or whatever your frontier tier is)—not to a silent retry on the same small model. Name the owner of the routing table the same way you name owners for feature flags.
If you already use agents, treat Haiku as a subagent for bounded chores while a larger model plans. Anthropic's own launch copy describes that shape; your job is to make the boundary explicit in code and in the runbook.
Write escalate conditions as code comments and as a short runbook paragraph. When an on-call engineer sees a spike in escalations at 11 p.m., they should know whether to widen Haiku, tighten validation, or pause the feature. Mystery spikes are how cost-routing projects get reverted wholesale.
The expensive model should meet the hard step, not every step.
Price tiers and the tokenizer trap
As published October 7, 2026 on Anthropic's Haiku pages: for prompts up to 100K tokens, Haiku 5.5 list pricing is $0.10 per million input tokens and $0.50 per million output tokens; above 100K tokens, $0.50 input and $2.50 output. Cache read/write rates differ by tier. Anthropic also notes Haiku 5.5 uses a newer tokenizer that counts roughly more tokens for the same text than Haiku 4.5—so do not multiply old token counts by a fixed factor. Recount representative prompts.
Anthropic's "around 75% less on average" versus Haiku 4.5 is their blended claim. Your mix may differ. Compare cost per successfully completed task, including retries, fallbacks, and human review—not cost per raw token alone.
If you use prompt caching or the Batch API, keep those line items separate in the spreadsheet too. Blending cache hits into a single "average cost per call" will hide regressions when cache hit rate drops after a prompt change.
Decision guide
When Haiku is enough vs when to escalate
| Consideration | Stay on Haiku 5.5 | Escalate to a larger model |
|---|---|---|
| Task shape | Classify, extract, short summarize, route. | Open-ended planning, hard coding, ambiguous judgment. |
| Consequence | Easy to undo; low customer harm. | Money, legal, safety, or hard-to-reverse sends. |
| Input | Short, clean, in-distribution. | Hostile, huge, or novel. |
| Check | Schema or allow-list validates the answer. | No reliable automatic check. |
| Owner signal | Escalate rate stays low in the first week. | Humans keep fixing the same miss. |
Walk one workflow end to end
Pick a single production path—support triage, document field extraction, or a coding subagent that only retrieves a fact. Implement:
- Router or hard-coded rule sends eligible calls to
claude-haiku-5-5. - Validation checks schema or allow-list; failures escalate.
- Dashboards show volume, escalate rate, and cost per success for seven days.
- A rollback switch returns that path to the previous model in one config change.
Read the escalate samples yourself on day two and day seven. If humans keep correcting the same class of miss, either tighten the job or stop calling it "cheap work."
Build the routing into the web application the same way you would build any other dependency: timeouts, budgets, and an owner—not a prompt left in a wiki.
Pair the workflow walk with product language. Support agents should know when an automatic triage label came from the small model and when a human should distrust it. Silent routing that nobody can see becomes silent failure.
Mistakes to avoid in week one
Do not route refunds, legal commitments, or production deploys to the small model "to save money." Do not hide the 100K tier boundary in a single blended budget line. Do not skip the recounted tokenizer check and then blame the model for a cost surprise. Do not forget that faster models still need containment—see agent containment if tools are attached.
Also skip vanity A/B tests that only measure vibe. Measure task success against fixtures you already trust.
Do not negotiate your cloud commitment based on a single week of Haiku traffic. Seasonality and prompt changes move spend more than model list prices sometimes do. Revisit the routing table on a monthly cadence for the first quarter.
How this shows up in a web app architecture.
In practice the router often lives next to your existing LLM gateway: a policy table keyed by job name, model id, max tokens, and escalate model. The application code should not hard-code model fashion; it should ask the gateway for "triage.v2" and let config decide Haiku versus Sonnet this week. Feature flags help, but a dated config file with an owner is enough to start.
Emit structured logs: job, model, tokens in/out, tier (under/over 100K), escalate reason, validation pass/fail. Those logs feed the monthly routing review. Without them you are back to vibes and vendor averages.
When tools are attached to the small model, apply the same allow-lists you would for any agent. A cheap model with a wide write tool is not a bargain.
Keep a short rejection log for prompts that look like they belong on Haiku but fail validation often. Patterns in that log tell you whether the job definition is wrong or the model tier is wrong. Either fix is cheaper than permanently escalating everything "to be safe," which quietly restores the old bill.
Put this into practice
This week: export your top twenty LLM call shapes by volume. Mark five as Haiku candidates with escalate rules. Ship one. Review escalate samples with the person who owns the customer outcome.
If you want help designing the router and the budgets inside a production app—talk to us.
Related work: Spin:Market.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.