Claude Haiku 5.5 costs five times more per token once a prompt passes 100,000 tokens.
Our price table held one pair of rates per model, and the price page listed Haiku 5.5 on two rows. The rows read “Claude Haiku 5.5 (for prompts up to 100,000 tokens)” and “(for prompts over 100,000 tokens)”. Every other model in the table had a single pair of numbers, one rate for input and one for output.
What the two rows say
A request’s prompt is its input tokens, cache reads and cache writes added together. At 100,000 tokens or fewer, Haiku 5.5 is priced at 0.10 for input and 0.50 for output. Over 100,000, it is priced at 0.50 for input and 2.50 for output. The rates are per million tokens, and the price a request pays depends on the length of its prompt.
Teaching the table about tiers
First, the table. ModelPrice got optional long-prompt fields: a threshold in tokens, plus a long rate for input, output and each cache tier. Every flat-priced model leaves them empty. The long tier’s cache rates are derived from its own input rate with the same multipliers as the short tier, 0.1x, 1.25x and 2x, so nobody types that arithmetic by hand. A new for_prompt() method returns the flat price that applies to one request.
Second, the script that checks our table against the live price page. It had flagged the two tier rows as new models. We taught it to read the tier out of the name cell and check both tiers against the page.
Third, the places that add up what we spend: the usage rollup, the credits code and the review budget. Each now calls for_prompt(). The credits code parses a transcript request by request, so it keeps a separate set of token totals for the requests whose prompt went over 100,000. Those are priced at the long rate and everything else at the short rate.
Each of the three places got a test, one below 100,000 and one above.
The edge of the line
A prompt of exactly 100,000 tokens still gets the short rate. for_prompt() returns the short price for a prompt “at or under the threshold”, and the credits code counts a request as long only when its prompt is greater than 100,000, so a request at exactly 100,000 tokens bills at 0.10 and 0.50.
AI Skills
Use this lesson with the AI assistant you already use
A price page listed Claude Haiku 5.5 on two rows, one rate pair for prompts up to 100,000 tokens and a higher pair for prompts over 100,000. The price table held only one pair of rates per model, so every place that totaled spend had to change.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
The prompt works in any AI assistant as it is. We are also building a /dxdev skill for visual reports and saved memory.
It is not released yet: see what you can use today.
dxdev LESSON · paste into your AI coding agent
LESSON: Model Prices Can Depend On Request Size So Price Every Request By Its Own Prompt Length
SOURCE: dxdev.com/blog/same-model-price-jumps-past-100k
WHAT HAPPENED: The table's ModelPrice type got optional long-prompt fields: a token threshold and long rates for input, output and each cache tier. A for_prompt() method returns the flat price that applies to a single request. The script that checks the table against the live price page had flagged the two tier rows as new models, so it was taught to read the tier from the name cell and check both tiers. The usage rollup, the credits code and the review budget now all call for_prompt(). The credits code parses transcripts request by request, so it keeps separate token totals for requests whose prompt went over 100,000. Each of the three places got one test below the threshold and one above. The boundary was also pinned down: a prompt of exactly 100,000 tokens bills at the short rate.
THE RULE: When a vendor prices one model differently by request size, resolve the price per request from that request's own prompt length instead of per model, and route every spend calculation through that single lookup. State which side of the threshold the exact boundary value falls on and make every caller agree.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Every code path that totals spend gets its rate from one per-request lookup such as for_prompt(), not from a per-model flat rate.
2. Each cost calculation has tests on both sides of the tier threshold, and the exact boundary value has a test that matches the documented rule.
3. The script that validates your price table against the vendor's page can parse tier labels in model names, and it does not report the tier rows as new models.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
