The cheapest models and the token-counter trap

New models advertise lower prices per million tokens. But if the same text starts occupying more tokens, the comparison also depends on a unit whose size has changed. The count increases even when we send the same content.

With Haiku 5.5, that increase is documented: roughly 30% more than Haiku 4.5 for the same text. Alongside it are pricing thresholds, categories excluded from the visible counter and allowance percentages that do not explain their relationship to that number.

That is the underlying problem. A low headline rate is not enough to understand a bill or usage allowance. If a provider advertises the discount per token, it should also show how much the count has grown for the same information.

Haiku: 25% in one test, 30% in the documentation

A tokenizer divides content into the units a model uses. Change it and the same sentence can occupy more tokens. The Haiku 5.5 migration guide puts the text increase at roughly 30%, depending on the content.

There is an independent observation too. On 7 October, Simon Willison published a test with one long prompt that produced approximately 1.25 times the Haiku 4.5 count: 25% more. It is one reported test, not an average across workloads.

Haiku 5.5 versus Haiku 4.5: approximately 25% more tokens in Willison’s prompt, 30% more for text in Anthropic’s guidance and 150% more in its image example. — Enlarge chart. The two text figures have different scopes. The 150% figure concerns a 2,000 × 1,500-pixel image processed at higher resolution, not text.

Anthropic’s image example uses about 2.5 times as many tokens as the previous model: 150% more, rather than 250% more. Haiku 5.5 preserves more resolution, so the detail being processed changes too.

For text, applying the 30% guidance as an approximation turns an old count of 100,000 into 130,000. A fixed allowance of 100,000 tokens would then hold 23.1% less text: 100/130 is approximately 0.769. This calculation holds the token allowance constant; it does not compare the models’ actual context-window sizes.

When the cost reaches 6.5 times the estimate

Haiku 5.5 advertises Standard input at $0.10 per million tokens up to 100,000 input tokens. Above that threshold, it charges $0.50 per million for the entire request. The increased count can push the same content into the higher rate. Haiku rates and threshold.

Consider a hypothetical input-only estimate, without caching, output or tools. Using Haiku 4.5’s count and Haiku 5.5’s short-prompt rate, a 50,000-token text would cost $0.005. Assuming 30% more tokens, it becomes 65,000 and costs $0.0065: 30% above the estimate.

For an 80,000-token text, the initial estimate is $0.008. The assumed increase takes it to 104,000, crossing the threshold. Input then costs $0.052: 6.5 times the estimate, or 550% more. The baseline is the old count multiplied by the new model’s short-prompt rate, not the previous model’s bill.

Hypothetical additional cost versus an estimate using old counts and Haiku 5.5’s short-prompt rate: 30% more for 50,000 to 65,000 input tokens and 550% more for 80,000 to 104,000. — Enlarge chart. Input calculations, not measured invoices. The 550% combines the assumed count increase with long-prompt pricing; it is not 550% more tokens.

The headline rate invites a simple multiplication. What it leaves out is that both the quantity counted and the applicable price can change. In the second example, underestimating the count also means budgeting with the wrong rate.

Luna has different conditions: above 272,000 input tokens, it doubles input rates and applies 1.5 times the output rate to the entire request. Understanding the counter therefore requires the effective rate as well as the price in the first pricing row.

Why the allowance percentage can advance faster than the counter

A percentage needs a denominator. In Claude Code, context occupancy compares input and cached tokens with the model’s context window. Five-hour and seven-day usage percentages are separate fields. A 30% increase in text tokens does not automatically mean 30% more subscription allowance consumed.

An Inventive HQ measurement from 2–4 October illustrates the difference. On a Pro account using several models, end-of-run counts accumulated approximately 30.3 million tokens, excluding cache reads. Including them brings the published categories to approximately 697.4 million: roughly 23 times the count. That activity consumed 33% of the weekly allowance.

Codex case consuming 33% of weekly allowance: approximately 30.3 million tokens in the counter versus 697.4 million including 667.1 million cache-read tokens. — Enlarge chart. Sum of rounded categories from a published case, predominantly GPT-6 Sol, not a Luna-only test. It includes repeated reads, not 697 million tokens of unique text.

Cache reads are cheaper. Processing 23 times the displayed count does not mean paying 23 times as much. The author estimated roughly $214 at API rates for that usage; it was not an additional subscription invoice. This did not establish a universal token-to-percentage conversion, and Luna’s specific weighting in the allowance remained unresolved.

With Luna, a million output tokens carries five times the weight

A token total does not explain credit consumption either. Codex pricing assigns Luna 2.5 credits per million Standard input tokens, 0.25 for cached input and 12.5 for output. The same number of tokens carries five times the weight when it is output rather than uncached input.

GPT-6 Luna at Codex Standard credit rates: a million input tokens consumes 2.5 credits; a million output tokens consumes 12.5, five times as much. — Enlarge chart. Official credit rates. This shows category weighting, not a tokenizer change or a formula for included plan usage percentages.

A counter that combines input and output in one number does not show that difference. If the allowance bar does not explain its weighting either, usage becomes harder to interpret. Users watch the percentage rise without a complete calculation they can check.

Which activity does the counter include?

A Luna test on Codex 0.155.1 verified independent counters per agent. The orchestrator’s API-equivalent cost was $2.67; including four subagents brought it to $5.62: 110.5% more estimated cost when the whole team was included. This is a scope difference, not tokenizer inflation or an actual invoice, and it depends on that version.

Output includes internal reasoning, even when the visible answer is short. Do not add it again. With Claude’s server-side compaction, currently in beta, top-level totals exclude the iteration that summarizes context. Sum usage.iterations to include all usage.

Haiku’s additional 30% for the same text is documented. The Codex cases show other accounting and weighting problems. Each deserves a full explanation of what is charged or deducted, keeping their different causes clear.

I would ask for comparable counts for the same content, every usage category made visible, and an explanation of how that usage moves the allowance. If a provider changes the unit or its weighting, that difference belongs beside the advertised price.

The trap lies in advertising the lower price per token without making it equally clear that the same work consumes more units or carries more weight than the counter suggests. The discount is easy to see. Checking the full cost takes more work from the user.

Sources checked on 10 October 2026. The cover photograph is an AI-generated conceptual image; it does not depict a real invoice.