Anthropic released Claude Haiku 5.5 on October 7. It's a small, cheap model with a 1M-token context window, aimed at classification, extraction, routing and subagent work. That's the exact slot where most teams run their highest-volume calls.

The headline is the price tier. The detail that will actually bite you is smaller: the model ships with a newer tokenizer, and it counts tokens differently from older models. Same text in, different number out.

Why a tokenizer change hurts quietly

Nothing crashes. Your prompts still run. But a lot of production code treats token counts as if they were a law of physics.

Think about where a number like that gets baked in:

A max_tokens cap you tuned on the old model, now cutting responses off mid-sentence or leaving room you're paying for
A chunking step that splits documents at 3,000 tokens because that fit your old context math
A cost dashboard that estimates spend from character counts times a ratio someone measured last spring
Rate limit logic and per-user quotas that assume one count per request
Alerting thresholds on "unusually long prompt" that now fire constantly, or never

Each of those was correct for one tokenizer. Swap the model and they're all approximately right, which is the worst kind of wrong. Nobody opens a ticket for approximately right.

Cheap subagent models make it worse

A small model is exactly what you put in a loop. A router that classifies every incoming request. An extractor that runs on every document. A subagent that gets spawned dozens of times per task. Volume is the whole point.

So a 10 or 15 percent drift in how a prompt is counted isn't a rounding error. It's multiplied by your highest call volume. And because the model is cheap, nobody is watching that line item closely. That's how a cheap tier ends up costing more than you planned.

What we'd do about it

First, stop counting tokens yourself. Use the provider's token counting endpoint or the usage block in the response, and log the real numbers per call. Estimates from a different model are guesses.

Second, put token limits in config, not code. If swapping a model means grepping for magic numbers, you'll miss one. Make budgets a per-model setting next to the model name.

Third, run a replay before you switch. Take a day of real traffic, send it through the new model, and compare input tokens, output tokens, truncation rate and cost per completed task. You want to see the diff before your customers do.

Fourth, treat a model upgrade like a dependency bump. It has a changelog, it has side effects, and it gets a test run. The tokenizer note is sitting right there in the release notes. Someone has to read it.

The bigger point

Teams spend a lot of energy on which model is smartest and not much on what a model swap changes underneath. Tokenizer, context behavior, default parameters, output length habits. Any of them can move your cost and your reliability without touching your code.

The 1M context window is real, but it doesn't mean you should fill it. Long context still costs, and a tokenizer that counts more aggressively just makes a stuffed prompt more expensive.

Small models are great. Use them for routing and extraction and subagents. Just don't assume the numbers you measured on the last one still hold.

We're here to help founders and teams design and build digital products that are built to scale with you, not slow you down. If you're looking to build something, get in contact with us today!