Claude Haiku 5.5 shipped on October 7, 2026 with a headline price of $0.10 per million input tokens and $0.50 per million output tokens, a tenth of the per-token price of Claude Haiku 4.5. The headline has a condition. Those prices apply to requests whose prompt is up to 100,000 tokens. A request with a longer prompt is billed at $0.50 and $2.50, and the higher prices cover the whole request, not only the tokens past the line.
So a 100,000-token prompt costs one cent of input and a 100,001-token prompt costs five. Three things about the model push existing workloads toward that line: a tokenizer that counts the same text as roughly 30% more tokens, thinking blocks that now stay in the conversation, and a context window five times the old one, which makes long prompts easy to send.
This article covers how the threshold is counted, why prompts that were comfortable on Haiku 4.5 can land on the wrong side of it, and the code that keeps requests under it: a cost function, a pre-flight check, a retrieval packer and a context-editing setup for agent loops. The numbers come from Anthropic's documentation as read on October 12, 2026, and the code uses the official anthropic Python SDK.
The short answer
- Haiku 5.5 has two price lists. Prompts up to 100,000 tokens pay $0.10 input and $0.50 output per million tokens. Prompts over 100,000 pay $0.50 and $2.50. Every line item in the second list is exactly 5× the first.
- The second list applies to the entire request, including its output tokens and its cache reads.
- Prompt length is
input_tokens + cache_creation_input_tokens + cache_read_input_tokens. A cache hit does not keep a request under the line.
- The same text is about 30% more tokens than on Haiku 4.5, so a prompt that measured around 77,000 tokens there is close to the threshold here.
- Token counting is free. Count before you send, and keep a margin.
- In agent loops, set tool-result clearing to trigger below 100,000. Its default trigger is exactly 100,000.
How Claude Haiku 5.5 pricing works
These are the prices on the pricing page, per million tokens:
| Prompt up to 100,000 tokens | Prompt over 100,000 tokens | Claude Haiku 4.5 (any length) |
|---|
| Input | $0.10 | $0.50 | $1 |
| 5-minute cache write | $0.125 | $0.625 | $1.25 |
| 1-hour cache write | $0.20 | $1 | $2 |
| Cache read | $0.01 | $0.05 | $0.10 |
| Output | $0.50 | $2.50 | $5 |
| Batch API, input / output | $0.05 / $0.25 | $0.25 / $1.25 | $0.50 / $2.50 |
And this is the rule, quoted from the same page:
A request's prompt length counts all of its input tokens, including cache reads and cache writes. Each request is priced on its own: a request over the threshold pays the higher prices even when part of its prompt is a cache hit, and earlier requests keep the prices they were billed at.
Anthropic's cost guide puts it in one clause: a request over the threshold "pays the higher prices for all of its tokens".
Three consequences follow.
It is a step, not a marginal rate. A tax bracket charges the higher rate only on the amount above the bracket. This charges it on everything. Trimming a 120,000-token prompt to 100,000 removes 17% of the tokens and 83% of the input cost: $0.060 becomes $0.010.
Output is priced by the prompt's tier. Output tokens don't count toward the 100,000, but a long prompt makes every output token cost 5×, and thinking is billed as output.
Nothing is retroactive. A conversation that grows past the line pays more from that request on. The turns before it keep their price.
Haiku 5.5 is the only model in the current lineup priced this way. The other models with a 1M-token context window bill long prompts at their standard rate.
Here is the rule as code. Prices are strings turned into Decimal, and since $X per million tokens is X micro-dollars per token, the arithmetic stays exact:
from decimal import Decimal
THRESHOLD = 100_000 # prompt tokens; "up to 100,000" is still the lower tier
# USD per million tokens, from platform.claude.com/docs/en/about-claude/pricing
# (checked 2026-10-12). This is configuration: reload it when prices change.
# Standard API with global routing: the Batch API halves these, and
# inference_geo "us" multiplies them by 1.1.
HAIKU_5_5 = {
"short": {"input": "0.10", "write_5m": "0.125", "write_1h": "0.20", "read": "0.01", "output": "0.50"},
"long": {"input": "0.50", "write_5m": "0.625", "write_1h": "1.00", "read": "0.05", "output": "2.50"},
}
def prompt_tokens(usage: dict) -> int:
"""Prompt length as the pricing rule defines it: every input token, cached or not."""
return (
usage.get("input_tokens", 0)
+ usage.get("cache_creation_input_tokens", 0)
+ usage.get("cache_read_input_tokens", 0)
)
def price_haiku_5_5(usage: dict) -> tuple[str, Decimal]:
"""Return (tier, cost in USD) for one request, priced on its own."""
tier = "long" if prompt_tokens(usage) > THRESHOLD else "short"
p = {k: Decimal(v) for k, v in HAIKU_5_5[tier].items()}
write_1h = usage.get("cache_creation_1h_input_tokens", 0)
write_5m = usage.get("cache_creation_input_tokens", 0) - write_1h
micro_usd = (
usage.get("input_tokens", 0) * p["input"]
+ write_5m * p["write_5m"]
+ write_1h * p["write_1h"]
+ usage.get("cache_read_input_tokens", 0) * p["read"]
+ usage.get("output_tokens", 0) * p["output"]
)
return tier, micro_usd / Decimal(1_000_000)
for n in (100_000, 100_001):
print(n, *price_haiku_5_5({"input_tokens": n, "output_tokens": 1_000}))
# 100000 short 0.0105
# 100001 long 0.0525005
One token moved the request from about one cent to about five.
What counts toward the 100,000-token threshold
Everything in the prompt counts: the system prompt, tool definitions, every message, images and PDFs, tool results, and the thinking blocks of earlier assistant turns.
The response's usage object splits the prompt into three fields, and the prompt caching docs give the total as cache_read_input_tokens + cache_creation_input_tokens + input_tokens. Don't check input_tokens alone. It holds only the tokens after the last cache breakpoint, and in a well-cached application it is a small number that says nothing about the tier.
Caching is where the rule surprises people. Take a request that reads 98,000 tokens from the cache, adds 2,000 new ones and returns 500:
print(*price_haiku_5_5({"cache_read_input_tokens": 98_000, "input_tokens": 2_000, "output_tokens": 500}))
# short 0.00143
print(*price_haiku_5_5({"cache_read_input_tokens": 98_000, "input_tokens": 2_001, "output_tokens": 500}))
# long 0.0071505
Prompt caching lowers what each token costs on either side of the line. It does not move the line.
Output tokens of the current request don't count. They become input on the next turn, which is how a conversation crosses the threshold a few turns after you looked.
Why prompts that fit on Claude Haiku 4.5 land over the line
The migration guide lists three changes that raise the token count of the same request.
The tokenizer. Haiku 5.5 uses the tokenizer introduced with Claude Opus 4.7, and "the same input text produces approximately 30% more tokens on Claude Haiku 5.5 than on Claude Haiku 4.5. The exact increase depends on the content." Divide 100,000 by 1.3 and you get about 77,000: a prompt of that size by Haiku 4.5's count is near the threshold on Haiku 5.5. Treat that as a reason to recount, not as a conversion factor.
Thinking blocks stay in context. "Thinking blocks from earlier assistant turns stay in context and count as input tokens, where Claude Haiku 4.5 kept only the latest turn's." Adaptive thinking is on by default, so a multi-turn conversation grows faster than the tokenizer alone explains.
Large images cost more. Haiku 5.5 uses the high-resolution image tier. Per the guide, an image of 2,000 by 1,500 pixels costs about 2.5 times as many visual tokens as on Haiku 4.5.
None of this makes the migration a bad deal. Assuming the 30% figure, the same text costs about 87% less to send than on Haiku 4.5 when the request stays under the threshold (1.3 × $0.10 against $1) and about 35% less when it doesn't (1.3 × $0.50 against $1). The threshold decides which of those two savings you get. The output side needs measuring rather than arithmetic, because thinking is now on by default, where Haiku 4.5 ran without it unless you enabled it, and thinking is billed as output.
Measuring is one function. The token counting endpoint counts under the tokenizer of the model you pass, so count each request twice:
import anthropic
client = anthropic.Anthropic()
def recount(request: dict) -> dict:
"""Count one request (system / tools / messages) under both tokenizers."""
old = client.messages.count_tokens(model="claude-haiku-4-5", **request).input_tokens
new = client.messages.count_tokens(model="claude-haiku-5-5", **request).input_tokens
return {"haiku_4_5": old, "haiku_5_5": new, "ratio": round(new / old, 3), "over": new > 100_000}
Run it over a sample of real production requests, the largest ones first, and look at two things: the ratio for your content, and how many requests come back with over set.
Count before you send
Token counting is free and has its own rate limit, separate from the Messages API: 5,000 to 20,000 requests per minute depending on usage tier. Two details from its documentation shape the guard.
The count "is an estimate. In some cases, the actual number of input tokens used when creating a message might differ by a small amount." A request counted at 99,990 could land on either side, so keep a margin.
The endpoint rejects requests that include server tools such as web search or code execution, the MCP connector, and images or documents passed by URL or file ID. Images and PDFs can be counted when you send them as base64. For requests with server tools or MCP servers, the only number you get is usage on the response, after the fact.
MODEL = "claude-haiku-5-5"
SAFETY_MARGIN = 2_000 # the count is an estimate; leave room for drift
def count(request: dict) -> int:
"""request holds system / tools / messages exactly as you would send them."""
return client.messages.count_tokens(model=MODEL, **request).input_tokens
def tier_before_sending(request: dict) -> str:
n = count(request)
if n <= THRESHOLD - SAFETY_MARGIN:
return "short"
if n <= THRESHOLD:
return "borderline" # could be billed either way: shrink it or accept the risk
return "long"
A request that comes back long has three honest options: send less context, split the work, or send it as it is because the task needs it. The next two sections cover the first two. The third has its own section further down, on when the long-prompt price is the right price.
Retrieval and document jobs: pack to a budget, split instead of stuffing
With a 1M-token window it is tempting to pass every retrieved chunk. On Haiku 5.5 the budget that matters is 100,000, so pack to it. Store each chunk's token count at indexing time, measured with the model you will call, and add chunks in rank order until the next one doesn't fit:
SYSTEM = "Answer from the documents. Say so when they don't contain the answer."
def build_request(question: str, chunks: list[str]) -> dict:
docs = "\n\n".join(f"<document>\n{c}\n</document>" for c in chunks)
return {"system": SYSTEM, "messages": [{"role": "user", "content": f"{docs}\n\n{question}"}]}
def pack(question: str, ranked: list[tuple[str, int]], budget: int = THRESHOLD - SAFETY_MARGIN) -> dict:
"""ranked: (chunk_text, token_count) pairs, best first."""
used = count(build_request(question, []))
chosen: list[str] = []
for text, tokens in ranked:
if used + tokens > budget:
break
chosen.append(text)
used += tokens
request = build_request(question, chosen)
while chosen and count(request) > budget: # per-chunk counts don't add up exactly
chosen.pop()
request = build_request(question, chosen)
return request
The stored counts make the loop cheap, and the final count() catches the difference between a sum of parts and the assembled prompt.
For a single large document, compare stuffing with splitting. A 250,000-token document with a 2,000-token answer costs $0.130 as one request. Split into three parts of about 84,000 tokens, each returning 1,000 tokens, it costs $0.0267, and a final request that merges the three partial answers (about 4,000 tokens in with its instructions, 2,000 out) adds $0.0014. That is about 78% less for the same input.
Splitting only works when the task decomposes: extraction, classification, per-section summaries. A question that needs two distant parts of the document in view at once loses accuracy when you split it, and no price difference fixes a wrong answer.
The Batch API halves both price lists and keeps the threshold: $0.05 and $0.25 per million tokens under it, $0.25 and $1.25 over it.
Agent loops: the cliff arrives mid-run
An agent re-sends its growing history on every step. With prompt caching that is cheap, until the history passes 100,000 tokens. From that step on, every request pays the second price list, cache reads included, and it keeps paying until the context shrinks.
The size of the effect depends on the run length, so here is a model you can change. It assumes 8,000 tokens of system prompt, tools and task, and a step that appends a 3,000-token tool result and a 500-token assistant turn (its output, thinking included), with the history cached incrementally. With a trigger, tool results older than the last four are cleared once the prompt passes it. Two simplifications: a cleared result counts as zero tokens, although the API leaves placeholder text in its place, and the clearing request is charged as a full cache rewrite, the worst case:
def simulate(steps: int, fixed: int = 8_000, tool_result: int = 3_000, out: int = 500,
trigger: int = 0, keep: int = 4) -> dict:
results: list[int] = [] # live tool-result sizes, oldest first
turns = 0 # assistant turns in history, `out` tokens each
cached = 0 # tokens already in the cache
total = Decimal(0)
long_steps = 0
for _ in range(steps):
prompt = fixed + sum(results) + turns * out
cleared = False
if trigger and prompt > trigger and len(results) > keep:
results = [0] * (len(results) - keep) + results[-keep:]
prompt = fixed + sum(results) + turns * out
cleared = True
read = 0 if cleared else cached
tier, cost = price_haiku_5_5({
"cache_read_input_tokens": read,
"cache_creation_input_tokens": prompt - read,
"output_tokens": out,
})
total += cost
long_steps += tier == "long"
cached = prompt
results.append(tool_result)
turns += 1
return {"steps": steps, "steps_over_100k": long_steps, "usd": round(total, 4)}
| Steps in the run | No context management | Clearing at 75,000 tokens |
|---|
| 25 | $0.0293, no step over the line | $0.0300 |
| 40 | $0.1553, 13 steps over | $0.0516 |
| 60 | $0.4018, 33 steps over | $0.0862 |
The unmanaged run crosses the line at step 28, and from there the gap widens: 3× at 40 steps, 4.7× at 60. At 50,000 sixty-step runs a month, that is about $20,100 against $4,300. This is arithmetic on published prices with invented workload numbers, not a benchmark, so put your own step sizes in.
A run that never reaches the line gains nothing from clearing and pays for the cache rewrite: about 2% more in this model. Real runs can do worse. The cost guide quoted earlier reports a short agent run on which context editing cost 74% more and a long one on which it changed nothing. Removing tokens is rarely a saving in itself. In this model about 94% of the gain comes from keeping every step on the first price list, and the rest from smaller cache reads.
The mechanism behind the right-hand column is context editing, a beta feature that clears old tool results on the server before the prompt reaches the model:
response = client.beta.messages.create(
model="claude-haiku-5-5",
max_tokens=8_000,
system=AGENT_SYSTEM,
tools=TOOLS,
messages=messages, # your full, unmodified history
betas=["context-management-2025-06-27"],
context_management={
"edits": [
{
"type": "clear_tool_uses_20250919",
"trigger": {"type": "input_tokens", "value": 75_000},
"keep": {"type": "tool_uses", "value": 4},
"clear_at_least": {"type": "input_tokens", "value": 20_000},
}
]
},
)
Four details matter here.
Set the trigger yourself. The default trigger is 100,000 input tokens, which is exactly Haiku 5.5's price line. I haven't found a statement in the documentation on whether the tier is decided by the prompt's size before or after clearing, so don't let the bill depend on it. Pick a lower value, with enough headroom that what clearing leaves behind still fits: the system prompt, the kept tool results and the assistant turns. To preview the result, pass the same betas and context_management to client.beta.messages.count_tokens(): it returns the count after clearing as input_tokens and the count before as context_management.original_input_tokens.
Clearing breaks the prompt cache. Per the documentation, tool result clearing invalidates cached prompt prefixes when content is cleared, and clear_at_least exists so that each invalidation removes enough tokens to be worth it. If the API can't clear that much, the strategy is not applied, so watch context_management.applied_edits on the response for runs where nothing gets cleared.
Old thinking blocks can be cleared too. The clear_thinking_20251015 strategy keeps only the last N turns' thinking when you set keep to {"type": "thinking_turns", "value": N}. On Haiku 5.5 its default is to keep all of them. When you combine it with tool-result clearing it must come first in edits, and clearing thinking also invalidates the cache from that point.
Don't trim history on the client. On Haiku 5.5, a request that sends a thinking block back after a change to system, tools or earlier messages returns a 400 error, unless you opt into having the invalidated blocks dropped. Accounts created before August 31, 2026 get the error only when they set thinking.block_binding.prefix_mismatch_behavior. The classic sliding window that drops the oldest messages is exactly that kind of change. Server-side context management "never invalidates thinking blocks", which is the reason to prefer it. When clearing tool results isn't enough, compaction, also in beta, replaces older turns with a summary written on the server.
Clearing changes what the model can see. An agent that needs a file it read thirty steps ago has to read it again. Run your evals with clearing on before you rely on the savings.
Watch the line in production
The response tells you which price list a request was billed on, as long as you add the three input fields together. Log the prompt length, the tier and the cost on every call:
def usage_dict(u) -> dict:
"""Flatten the SDK's usage object into the dict price_haiku_5_5() expects."""
return {
"input_tokens": u.input_tokens,
"cache_creation_input_tokens": u.cache_creation_input_tokens or 0,
"cache_creation_1h_input_tokens": u.cache_creation.ephemeral_1h_input_tokens if u.cache_creation else 0,
"cache_read_input_tokens": u.cache_read_input_tokens or 0,
"output_tokens": u.output_tokens,
}
usage = usage_dict(response.usage)
tier, cost = price_haiku_5_5(usage)
print(prompt_tokens(usage), tier, cost) # send these to your metrics instead
Two numbers are worth an alert. The share of requests billed as long should match what you decided on purpose. The share of requests between 90,000 and 100,000 tokens tells you what will cross after the next prompt edit, the next tool you add, or the next slightly longer document.
When the long-prompt price is the right price
Staying under the line is an optimization, not a rule. Above it, Haiku 5.5 costs $0.50 and $2.50 per million tokens. That is half the per-token price of Haiku 4.5 and a quarter of Claude Sonnet 5.5 at $2 and $10.
Pay it when the task needs the whole context in one view, when a split would cost accuracy, or when the request runs a few times a day and four cents is not worth an engineer's afternoon. The cliff matters at volume, in the classification, extraction, routing and subagent traffic the model is built for, where a 5× difference on every request is the whole bill.
Other migration changes that move the bill
The threshold is one of several changes in the migration guide that affect cost.
- Thinking is on by default and counts toward
max_tokens. A small max_tokens carried over from Haiku 4.5 can stop a response after a thinking block and before any text.
- The effort parameter is the control for how much the model thinks. The default is
medium. The docs describe low as the cheapest and fastest level, meant for simple, high-volume requests. Set it with output_config={"effort": "low"}.
- Changing the top-level effort value between requests invalidates the prompt cache for that conversation's messages.
thinking with budget_tokens and assistant prefill return a 400 error. So does nearly every temperature, top_p or top_k value, so omit all three.- The minimum cacheable prompt is 512 tokens, down from 4,096 on Haiku 4.5, so prompts in between now cache when they set
cache_control.
FAQ
Is the higher price charged only on the tokens above 100,000?
No. A request whose prompt is over 100,000 tokens pays the higher prices on all of its tokens: input, cache writes, cache reads and output.
Do cached tokens count toward the 100,000-token threshold?
Yes. The prompt length counts all input tokens, including cache reads and cache writes. A request over the threshold pays the higher prices even when part of its prompt is a cache hit.
Do output tokens count toward the threshold?
No. Only the prompt is measured. Output is priced by the tier the prompt lands in, and it becomes input on the next turn.
Does the Batch API avoid the higher tier?
No. Batch requests get 50% off in both tiers, and the same 100,000-token threshold applies to each request.
Does Claude Haiku 4.5 have the same threshold?
No. Haiku 4.5 is billed at $1 and $5 per million tokens at any prompt length, with a 200,000-token context window. It is now listed among the legacy models. The deprecations page shows it as active, with a tentative retirement date of "Not sooner than October 15, 2026" and no deprecation notice so far.
How do I know which tier a request was billed at?
Add input_tokens, cache_creation_input_tokens and cache_read_input_tokens from the response's usage. Over 100,000 means the higher prices.
A migration checklist
- Recount a sample of real requests with
model="claude-haiku-5-5". Don't reuse counts measured on Haiku 4.5.
- Price requests by tier, from all three input fields in
usage.
- Count before sending, with a margin, wherever a prompt can approach 100,000 tokens.
- Pack retrieval to a budget. Split document jobs that decompose.
- In agent loops, turn on tool-result clearing with an explicit trigger below 100,000 and a
clear_at_least value, and keep the history append-only on the client.
- Alert on the share of requests in the long tier and on the share between 90,000 and 100,000 tokens.
- Send a long prompt when the task needs one, and know what it costs when you do.
The $0.10 headline is real, and it belongs to requests whose prompts stay at or under 100,000 tokens. The line is not visible from inside a single request. It shows up when you add up usage across a day of traffic, so do that before the invoice does it for you.
I'm Dragoș. I build LLM systems and teach production LLM integration at Cursuri-AI.ro.
