Haiku 5.5 Pricing: What Happens Above 100K Tokens?

Haiku 5.5 switches price tiers when a single request’s total input exceeds 100,000 tokens. Exactly 100,000 remains in the lower tier. Above the threshold, the relevant higher-tier rates apply to the entire current request, including output—not just to the input tokens beyond 100K.

Cached reads and cache writes count toward that input threshold. They still receive their own cache rates; counting toward the threshold does not turn them into ordinary uncached input. Earlier requests are not retroactively repriced.

This guide checks Anthropic’s pricing documentation and prompt-caching rules as of October 15, 2026. All examples are local arithmetic using published first-party USD rates, not measured API usage or Ofox quotes. Haiku 5.5 was announced October 7.

The two rate cards

Prices below are USD per one million tokens, for standard first-party global inference.

Batch processing halves the applicable token costs and can combine with caching pricing. It is an asynchronous processing mode, not a label you can apply to any synchronous request. Managed Agents does not offer Batch mode. The examples exclude the separate first-party inference_geo: "us" multiplier; the documentation specifies a 1.1 multiplier for that option, including cache and output rates.

One additional input token can change the whole rate card

Assume ordinary input only and exactly 1,000 output tokens:

These are synthetic boundary cases. They do not mean that adding one character always adds one token, or that your tokenizer will produce these exact lengths. The point is the billing discontinuity: do not calculate the first 100K at the lower rate and only the excess at the higher rate.

Output affects the cost but does not decide which input tier applies. A request with 99,000 input and 2,000 output tokens still uses the lower input-length tier. Whether that request fits other model limits is a separate validation question.

Count cache tokens once

Use disjoint usage categories:

prompt_total = ordinary_input + cache_write_5m + cache_write_1h + cache_read
cost = (ordinary_input × input_rate
      + cache_write_5m × write_5m_rate
      + cache_write_1h × write_1h_rate
      + cache_read × read_rate
      + output × output_rate) / 1,000,000

Select the rate card from prompt_total before multiplying the categories. If the API reports both an aggregate cache-creation field and five-minute/one-hour detail fields, use the detailed split once. Do not add the aggregate again. A cache read is part of the model’s prompt even when that content was written in an earlier request.

The usage fields map as follows: input_tokens is ordinary input, cache_read_input_tokens is cache read, and cache_creation.ephemeral_5m_input_tokens / cache_creation.ephemeral_1h_input_tokens are the two write categories. Use cache_creation_input_tokens to reconcile the write total, not as another category to add.

For example, 90,000 cache-read tokens plus 10,001 ordinary input tokens gives 100,001 input tokens, so the higher tier applies. With 1,000 output tokens:

(90,000 × 0.05 + 10,001 × 0.50 + 1,000 × 2.50) / 1,000,000
= $0.0120005

For the same category counts in an applicable Batch request, the estimate is $0.00600025. This is conditional arithmetic, not a promise that a real Batch job will hit a cache. A miss changes the usage categories and therefore the bill.

Use the downloadable calculator

Download the Python calculator and boundary examples CSV. The calculator uses Python’s decimal arithmetic and standard library only. It makes no network calls, reads no credentials, and sends no API requests.

python3 haiku_cost.py --input 100001 --output 1000
python3 haiku_cost.py --input 10001 --cache-read 90000 --output 1000
python3 haiku_cost.py --input 10001 --cache-read 90000 --output 1000 --batch
python3 haiku_cost.py --self-test

The first result should show the higher tier, 100,001 total prompt tokens, and USD 0.0525005. The second should produce 0.0120005, and the third 0.00600025. Negative counts are rejected. Cache writes can be entered separately with --cache-write-5m and --cache-write-1h. Use the matching actual usage fields rather than a character-count estimate.

The self-test checks threshold selection, cache inclusion, output exclusion from the threshold, cache rates, Batch arithmetic, and invalid inputs. It verifies our implementation of the published formula; it does not verify Anthropic’s production meter or your invoice. The calculator fixes rates to October 15 and needs updating if the rate card changes.

Stay below the threshold without breaking the task

Start by measuring the prompt you actually send: system instructions, tool definitions, conversation history, retrieved material, and other included inputs. Do not count only the user’s visible message. Leave room for variable retrieval or conversation growth instead of targeting exactly 100,000 in every request.

Three options have different acceptance tests:

Splitting is not automatically cheaper. It may repeat system prompts, generate several outputs, require a final synthesis, or cause retries. Compare the sum of every request, including failed attempts and aggregation, against the unsplit baseline. Test quality on cases that require information from multiple chunks—not only easy isolated records.

For a long-running conversation, calculate each request separately. A later turn crossing 100K can cost more, but it does not change the rate already applied to earlier turns. Persistent cache use can reduce cost while the prompt still crosses the threshold.

Reconcile the estimate with real usage

For each authorized production request, retain its timestamp, model, billing provider, input/cache/output counts, processing mode, and the applicable rate snapshot. Keep prompts and secrets out of a public cost worksheet. Separate five-minute and one-hour writes; confirm whether Batch and any geographic option actually applied.

If the invoice differs, first check omitted cache writes, duplicate counting, output usage, provider-specific prices, retries, and the rate date. Do not compensate by arbitrarily reducing the token count. A third-party gateway can have a different rate card; this first-party calculator is not evidence of an Ofox charge.

Our Haiku 5.5 versus 4.5 task comparison addresses output behavior in classification, extraction, and summaries. It does not establish the cost of these synthetic boundary cases. Different tokenizers also mean that equal text does not guarantee equal token counts across models.

Finally, Claude Max and Team API credits can fund eligible first-party usage, but do not change this formula. Complete the task by reproducing the examples, mapping your own usage into disjoint categories, and checking both cost and output quality before changing context strategy.