Claude Haiku 5.5 at the 100K-Token Boundary: When the Lowest Token Price Loses
One extra input token can change the price of an entire Haiku request. The more useful question is what happens after that request: does its answer pass, require another attempt, or send the workflow to a larger model?
Claude Haiku 5.5, released October 7, has a one-million-token context window and a separate pricing boundary at 100,000 prompt tokens. A large window is capacity, not a promise of the lowest cost for every workload. Anthropic model overview.
Scope and evidence — October 12, 2026. This is a pricing analysis with reproducible arithmetic, not a report of completed API trials. Prices come from Anthropic's documentation. Token volumes, retry counts, and acceptance outcomes in the worked examples are explicit assumptions. No benchmark establishes an accuracy drop at 100K or a universal 64K optimum.
The cliff is in the rate card, not the context window
For the standard Claude API, Haiku's input rate changes from $0.10 to $0.50 per million tokens above 100,000 prompt tokens; output changes from $0.50 to $2.50. Exactly 100,000 stays in the lower band. Cache reads and writes also move to higher rates. Official Haiku pricing.
The band applies to the request, not just the tokens beyond the boundary. Cached input still contributes to prompt length; each request is priced separately. Earlier calls are not retroactively repriced. Anthropic's long-context billing rules.
The calculation is small enough to audit: 100,000 × $0.10 / 1,000,000 + 4,000 × $0.50 / 1,000,000 = $0.012. Replace the input count with 100,001 and the two rates with $0.50 and $2.50 to obtain $0.0600005. Across 1,000 such independent calls, the corresponding totals are $12 and $60.0005.
This is not evidence that quality suddenly deteriorates at the boundary. It is evidence that an extra document, a tool schema, or retained history can change the budget before the model generates anything.
Reference: all five standard token rates
USD per one million tokens; checked October 12, 2026 against the model overview.
| Category | Prompt ≤100K | Prompt >100K |
|---|---|---|
| Input | $0.10 | $0.50 |
| Output | $0.50 | $2.50 |
| Cache read | $0.01 | $0.05 |
| 5-minute cache write | $0.125 | $0.625 |
| 1-hour cache write | $0.20 | $1.00 |
These are standard API rates, not a partner-platform quote. Regional multipliers, Batch pricing, tool charges, and negotiated terms require their own ledger.
An 80K prompt can become a 104K prompt without adding text
Anthropic says identical text produces approximately 30% more tokens with Haiku 5.5's newer tokenizer than with Haiku 4.5's; the change varies by content. Reusing the older model's count can therefore select the wrong band. Migration guide: recount tokens.
Anthropic's Token Counting API accepts a structured request, including system prompts and tools. Its result is an estimate and can differ slightly from actual message usage. Token-counting documentation. My deployment recommendation is to leave a tested safety margin near 100K, log the actual usage, and re-evaluate the band after any history or retrieval change. The margin is an application policy, not an Anthropic-specified sweet spot.
When does the cheap model actually lose?
Crossing 100K does not by itself make Haiku more expensive than Sonnet. Sonnet 5.5's standard input/output rates are $2/$10 per million tokens; its full 1M context window uses those standard rates. Anthropic pricing. Holding uncached token volumes equal, Haiku's higher band is still one-quarter of those rates.
Now define a deliberately simple workload: 120,000 input tokens and 4,000 billed output tokens per call, no cache, no tools, and no regional multiplier. A Haiku attempt is $0.07; a Sonnet attempt is $0.28. If one Sonnet call passes, four same-sized Haiku calls tie its API spend. A fifth makes the Haiku path cost $0.35—25% more.
That condition matters. Three retries are not a universal tipping point; different output lengths or cache hits change it. A Sonnet failure changes the comparison too. In a measured evaluation, count every billed attempt, accept at most one completed result per original task, and preserve tasks that never pass.
Total API spend across all attempts ÷ accepted tasksInclude paid failures, cache charges, and fallback calls. Report latency and human review separately unless you explicitly monetize them.
For independent one-shot calls with a constant cost c and a measured acceptance fraction p, this ratio becomes c / p. It is not a reliable shortcut for correlated retries on the same hard task. Use the observed workflow ledger for that case.
Reproduce the arithmetic without calling an API
This worksheet is static and deterministic. It estimates spend; it cannot generate acceptance rates or benchmark results.
| Assumed path | Calculation (USD) | Spend |
|---|---|---|
| Haiku, one call | 0.12 × 0.50 + 0.004 × 2.50 | $0.07 |
| Sonnet, one call | 0.12 × 2 + 0.004 × 10 | $0.28 |
| Haiku, five calls | 5 × 0.07 | $0.35 |
Volumes are millions of tokens. All five Haiku calls are assumed to have identical input and billed output; real retries can differ. For cached workloads, price uncached input, cache reads, and each cache-write duration separately. Include initialization and fallback cache writes over the same evaluation interval.
Effort and cache behavior belong in the same budget
Haiku offers low, medium, high, xhigh, and max; medium is the default. Anthropic advises comparing Sonnet when evaluating xhigh or max because deeper thinking and longer replies increase cost. Haiku prompting guidance.
Thinking is billed as output. usage.output_tokens is the inclusive billing total; the thinking detail is a breakdown, not an extra quantity to add again. Effort is soft guidance, while max_tokens caps a single call's total output. Neither setting alone caps an entire agent loop. Changing top-level effort can also invalidate prompt caching. Thinking, caching, and cost control.
My practical recommendation is to test a small set of model-and-effort configurations on the same task sample, keep each configuration stable during its run, and compare complete workflows. A lower output cap that repeatedly truncates valid answers is not a saving. A higher effort setting that prevents expensive retries can be.
A router should spend against an acceptance contract
Consider invoice extraction. The contract might require valid JSON, required fields, currency consistency, and a total that matches the source. A syntactically valid response can still fail those checks. Define them before comparing models; otherwise, the cheapest-looking path can simply be the path with the loosest definition of success.
A router also needs to distinguish rejection from a policy refusal. Haiku can return stop_reason: "refusal" in a normal HTTP 200 response and has no server-side fallback or fallback credit. A client-side fallback may require a new cache write. Refusal and fallback rules. Record the category and use a permitted recovery path; do not treat a safety refusal as an instruction to retry indefinitely.
Before migration, replace the legacy manual thinking budget with adaptive thinking and effort; omit sampling parameters; parse content by type; and check the exact platform's feature support. The current migration guide says Haiku 5.5 structured outputs are unavailable on Amazon Bedrock, so that path needs application-side format validation. Haiku migration checklist.
What I would measure before changing the default
- Freeze a representative task sample. Include short prompts, prompts near the price boundary, and real difficult cases. Keep the source material and acceptance rules identical across configurations.
- Capture a per-attempt ledger. Record actual input and cache categories, inclusive output, model, effort, stop reason, latency, and the rate date. Do not discard paid failures or cache initialization.
- Compare whole paths. Evaluate Haiku alone, bounded Haiku recovery, and the qualified direct alternative. Report accepted tasks out of the original sample alongside spend.
- Check whether the result generalizes. A win on extraction does not establish a win on coding. Re-test after changing the corpus, prompt construction, model, or retry policy.
The conclusion is conditional but actionable: Haiku is a strong candidate for bounded, high-volume work; it loses on cost when the measured extra work erases its per-call advantage. The 100K line makes that advantage smaller, not automatically worthless. Choose the least expensive workflow that meets the same quality and latency requirements, rather than assigning every task to the model with the smallest rate-card number.
FAQ
Does passing 100K prove that Haiku becomes less accurate?
No. The documented threshold is a billing rule. An accuracy or retrieval claim needs a controlled evaluation with actual prompts and an independent acceptance test. The calculations here make no such claim.
Can caching keep a long request in the lower band?
No. Cached tokens contribute to prompt length. Caching may reduce spend, but a prompt above 100K uses the higher-band rates for that request. Official billing explanation.
Is the five-attempt example a measured Sonnet victory?
No. Both the token volumes and the accepted outcomes are assumed. It shows an auditable break-even, not a model ranking. Real API usage, cache behavior, retry output, and measured acceptance can move that break-even in either direction.
Official Sources
Documentation and rates checked October 12, 2026. Calculated examples use the standard Claude API rates and exclude taxes, credits, tools, and regional surcharges.
