Claude Haiku 5.5 in Production: 1M Context, a 100K Pricing Cliff, and a Tokenizer That Bites Back

I moved a chunk of my high-volume extraction and triage traffic onto Claude Haiku 5.5 around launch (October 7, 2026) and it is exactly what the tier promises: 1M tokens of context, 128K of standard output, adaptive reasoning, and base rates of $0.10/Mtok input and $0.50/Mtok output for prompts up to 100K tokens.

The model ID is claude-haiku-5-5 on the Claude API, anthropic.claude-haiku-5-5 on Bedrock. It also ships on Google Cloud and Microsoft Azure.

The headline numbers are not where the surprises live. Three things will actually change your bill and your latency profile: the 100K pricing cliff is per-request and there are no exemptions, the new tokenizer counts roughly 30% more tokens for identical text, and every glossy benchmark score was measured at max effort while the product default is medium.

What's actually new versus Haiku 4.5

Effort is now a dial

Haiku 5.5 is the first Haiku with configurable effort levels, so you can trade reasoning depth against latency and token spend inside the same model. Default is medium. For "is this email a refund request, yes/no" I run low. For ambiguous field extraction or tool-planning steps where a wrong answer costs a retry, I bump it up. Adaptive thinking means the model also decides when to reason, which introduces variance in both generated tokens and p95 latency — so tune thresholds on real distributions, not on an average.

The tokenizer quietly eats ~30% of the headline savings

Anthropic's docs are explicit: the same input text counts as approximately 30% more tokens than it does on Haiku 4.5. The rate cut is real — 90% off Standard input/output under 100K — but Anthropic only claims ~75% lower average running cost once request-length mix and per-task token usage are accounted for. That gap is the tokenizer plus workload shape. If your cost model still assumes Haiku 4.5 token counts, your projection is wrong in the optimistic direction.

Long context, with the usual discipline

1M tokens of window is genuinely useful for long documents and fat conversation histories, but the cliff below is why I still use retrieval, truncation, and caching instead of just dumping everything in. A big window is a capability, not a pricing strategy.

The 100K cliff is per request, not per excess token

Prompt length selects the pricing band for the whole request. Cross 100K and the entire call is billed at the higher band — you don't get 100K at the cheap rate plus the overflow at the expensive one.

Rate category	Prompt ≤ 100K	Prompt > 100K
Input	$0.10	$0.50
Output	$0.50	$2.50
5-minute cache write	$0.125	$0.625
1-hour cache write	$0.20	$1.00
Cache read	$0.01	$0.05
Batch input (50% off)	$0.05	$0.25
Batch output (50% off)	$0.25	$1.25

Rates above are official Standard/cache/Batch USD per million tokens, checked October 8, 2026. Cached workflows are where people get this wrong most often: count the whole request, including history and tool definitions, for the selected model, then reconcile input, cache-write, cache-read, and output against the band the request landed in. Pull a few representative cached requests off your invoice before you set a budget.

Here's the arithmetic on a scenario I actually ran, 100,000 requests/month at 2,000 input and 500 output tokens each (200M input, 50M output, all under the cliff, no caching or retries):

REQ, IN_TOK, OUT_TOK = 100_000, 2_000, 500
official = {                       # (input $/Mtok, output $/Mtok)
    "haiku-4.5":  (1.00,  5.00),
    "haiku-5.5":  (0.10,  0.50),
    "sonnet-5.5": (2.00, 10.00),
}
for name, (rin, rout) in official.items():
    total = REQ * (IN_TOK * rin + OUT_TOK * rout) / 1e6
    print(f"{name:11} ${total:,.0f}/month")

rin, rout = (r * 0.8 for r in official["haiku-5.5"])   # gateway Standard = official x 0.8
print(f"{'haiku-5.5*':11} ${REQ * (IN_TOK * rin + OUT_TOK * rout) / 1e6:,.0f}/month")

Output: $450, $45, $900, and $36 for the discounted route. That last row is where a unified multi-model endpoint earns its keep — the same key and request shape also reaches Sonnet 5.5 and Opus 5.5, so routing by complexity doesn't mean a second SDK. CometAPI lists claude-haiku-5-5 at $0.08 input / $0.40 output per Mtok under 100K (and $0.40 / $2.00 over), i.e. 20% off the corresponding official Standard bands. I wouldn't assume that discount stacks on top of Batch or cache pricing without checking the live page.

And note the framing: $450 → $45 is a 90% rate reduction on a fixed-token illustration. It is not a promise that your equivalent workload costs 90% less. Recount your own inputs before you promise anyone a number.

Benchmarks: read the config, not the score

Benchmark	Haiku 4.5	Haiku 5.5	Sonnet 5.5
GDPval-AA v2.1 (Elo)	735	1,620	1,840
AA-Briefcase v1.1 (Elo)	614	1,578	1,824
OSWorld 2.1, offline subset, partial credit	15.7%	72.4%	83.9%
Humanity's Last Exam, no tools	10.2%	45.9%	56.9%
Humanity's Last Exam, with tools	18.7%	57.4%	64.5%
Terminal-Bench 4.0	0.0%	39.2%	70.6%
Chartography, no tools	6.4%	46.4%	61.6%

These are vendor-reported (GDPval-AA and AA-Briefcase come from independently run Artificial Analysis evals). The evaluation config matters more than the digits:

• Scores use adaptive thinking at max effort, default sampling, five trials unless stated. Product default is medium. A headline score is not a default-setting guarantee for your app.
• OSWorld 2.1 is 82 offline tasks, no internet, 1080p, 500-action cap. The 72.4% is partial credit; strict pass rate is 37.1%.
• Terminal-Bench 4.0 runs Claude Code in --bare mode with safeguards on. Haiku 5.5 gets max effort, no fallback, no internet egress, 10 trials per task. Sonnet 5.5 gets five trials and a fallback for some flagged requests. Haiku 4.5 uses a fixed 63,999-token thinking budget.

That last bullet is why 39.2% vs 70.6% isn't a clean comparison. Reproduce effort, tools, scaffold, and budget before comparing against your own harness.

My read: the OSWorld jump is the real story — Haiku 5.5 became dramatically more usable for structured GUI work. But Sonnet 5.5's Terminal-Bench lead confirms the larger-model advantage in agentic coding hasn't moved. Pick by failure cost, not by leaderboard rank.

Choosing between the three tiers

Dimension	Haiku 4.5	Haiku 5.5	Sonnet 5.5
Context	200K	1M	1M
Max standard output	64K	128K	128K
Standard input / MTok	$1	$0.10 ≤100K; $0.50 over	$2
Standard output / MTok	$5	$0.50 ≤100K; $2.50 over	$10
Reasoning	Extended thinking, fixed budget	Adaptive, medium default	Adaptive, high default
Relative latency	Fast	Fastest at standard speed	Fast
Coding depth	Bounded tasks	Stronger subagents	More complex coding
Typical use	Legacy small-model deployments	High-volume workflows	Complex production workflows

All three take text + image input and emit text (that's not image generation). "Fastest" refers to standard-speed modes — Opus Fast Mode is explicitly excluded from that claim. Anthropic's product tiers don't establish parameter counts or architecture details, so don't infer them.

Workload routing I'd actually ship:

Workload	Default	Why
Email classification	Haiku 5.5	Short, repeated, verifiable
Document field extraction	Haiku 5.5	Cheap structured processing
Support triage	Haiku 5.5	Fast first response + escalation
Coding subagents	Haiku 5.5	Low-cost file search, contained edits
Complex debugging	Sonnet 5.5	Meaningfully better on coding evals
High-stakes multi-step reasoning	Opus 5.5	Upper tier
Mixed traffic	Haiku + Sonnet	Route by complexity and confidence

Sonnet wins when stronger judgment avoids repeated failed calls, tool retries, or human corrections. On a labeled sample of your own traffic, measure accepted-task rate, correction cost, and latency; route anything that fails explicit validation or exceeds tested task scope to a stronger model; then re-tune after any prompt, tool, or effort change.

Migration notes that will actually bite you

temperature        -> omit; if sent, must be exactly 1
top_p              -> omit; if sent, must be exactly 0.99
top_k              -> omit; any value returns HTTP 400
temperature+top_p  -> both present returns HTTP 400
assistant prefill  -> banned

Then:

• Update the model ID and re-validate every endpoint-specific field.
• Recount tokens with the new tokenizer — including stable prefixes and tool definitions, not just user text.
• Re-test adaptive-thinking behavior and how you parse response blocks.
• Cap external-tool permissions, keep audit logs, and require review before consequential actions.
• Watch stop_reason and usage. If Haiku 4.5 completed a response and Haiku 5.5 truncates it, the tokenizer is counting more for the same text and adaptive thinking can eat output budget. Don't copy legacy max_tokens; retune on real tasks.
• Report p50/p95 latency, accepted-task rate, and total billable tokens — not token price.
• Stage the rollout with a rollback path for anything business-critical.

One subtle one: stored thinking blocks are only valid in the account that produced them, or an account linked to it. An unrelated account sending one has it discarded before the model sees it — the request can still succeed, just without that reasoning. If you continue a tool workflow, keep the conversation blocks and stay on the originating or linked account. A gateway or account switch needs explicit testing; matching a model name doesn't guarantee the blocks survive.

Where it isn't the right tool

Haiku 5.5 is not a universal substitute. Long-horizon reasoning and complex coding are still real differentiators for Sonnet and Opus, and the 1M window costs you real money past 100K, so use it selectively. Adaptive reasoning adds variance you have to measure rather than assume.

For high-volume work with measurable acceptance criteria, this is a straightforward upgrade: cheaper entry pricing, bigger window, adaptive reasoning, and much better published agentic/computer-use evals. For ambiguous decision-making or hard debugging, paying Sonnet or Opus rates often costs less in total because you stop paying for retries and human corrections. Benchmark the whole workflow, not the token.

---

Originally published at cometapi.com