Claude Haiku 5.5 charges 5x token rates when prompts cross 100K tokens

A fivefold cliff at 100,000 tokens

Claude Haiku 5.5 is priced in two tiers, and the boundary between them is sharp. According to a dev.to post by Gabriel Anhaia, Anthropic's pricing page lists the model at $0.10 per million input tokens and $0.50 per million output tokens for prompts up to 100,000 tokens, and at $0.50 and $2.50 above that line, with the higher rate applying to output as well as input.

The arithmetic in the post makes the cliff concrete. A request with 99,000 prompt tokens and 1,000 output tokens costs about $0.0104 at list prices. The same request with 101,000 prompt tokens costs about $0.0530: roughly 2% more prompt, 5.1 times the cost. Scaled to an illustrative 100,000 requests per day before caching or batch discounts, that is the gap between about $1,040 and $5,300.

The post's cautionary scenario involves a team that moved a retrieval endpoint to Haiku 5.5 after its October 7 launch, attracted by a base rate one tenth of Haiku 4.5's. Traffic could then drift over the line when someone raises retrieval topK from 12 to 20 in a one-line pull request, or when source documents get longer. Because the model has a 1M-token context window, every request still succeeds. Nothing throws an error; the first visible symptom is the invoice.

Prompt caching does not help

Two terms in Anthropic's long-context pricing, as quoted in the post, close the obvious workaround. A request's prompt length counts all of its input tokens, including cache reads and cache writes, and a request over the threshold pays the higher prices even for the portion that is a cache hit. A 90,000-token cached system prefix combined with 15,000 fresh tokens is therefore a 105,000-token prompt, and the cache read rate itself rises from $0.01 to $0.05 per million tokens. Caching cannot pull a request under the line; only a shorter prompt can.

The threshold is evaluated per request, and a prompt of exactly 100,000 tokens stays in the base tier.

Counting before each request

The post's remedy is a small TypeScript guard that estimates prompt size before sending and trims the lowest-ranked retrieved chunks until the request fits. It leans on the token-counting endpoint exposed by Anthropic's TypeScript SDK as client.messages.countTokens, which takes the same model, system, messages and tools as the Messages API and returns an input_tokens figure. The count is free, has its own rate limit (5,000 requests per minute on the Start tier) and does not draw on message-creation capacity. Because Anthropic describes the result as an estimate that may differ slightly from actual usage, the guard targets a 97,000-token budget rather than the full 100,000.

Existing token counts may also be stale. Haiku 5.5 uses a newer tokenizer that produces roughly 30% more tokens for the same text than Haiku 4.5, the post notes, so measurements taken against the older model now understate prompt size. For prompts that are clearly small, a rough ratio of about 2.5M Unicode characters per million tokens can be used to skip the extra API round trip, though that figure is an average rather than a bound.

Trimming and verifying

When a prompt is over budget, the guard binary-searches the ranked chunk list for the longest prefix that fits, since the token count only grows as chunks are added. That costs about log2(n) counting calls instead of one per dropped chunk. The guard also logs which tier the API actually billed, backed by a Vitest test that fails CI when the worst-case prompt crosses the threshold.

That logging step matters because of a usage-reporting trap the post highlights: the API's input_tokens field only covers tokens after the last cache breakpoint. The billed total is cache_read_input_tokens plus cache_creation_input_tokens plus input_tokens, so a dashboard charting input_tokens alone could show 15,000 for a request billed at the long tier.

Why it matters

Tiered long-context pricing turns prompt size from a technical constraint into a direct cost lever, and this threshold sits far inside the model's usable context window. Crossings are silent: requests succeed, responses look normal, and only the spend changes. The post is a useful template for anyone running RAG or agent workloads on metered APIs — measure prompts per request, remember that cached tokens count toward the limit, read the correct usage fields, and put the worst-case prompt under test.