Name the tokens the response billed

The model was supposed to answer, and someone is going to ask what it cost. Do not send the sentence, and do not start another request you will have to explain, until you can name the token counts on that response, show whether the uncached input is the whole input, and show a different request whose counts are not the same split. If the log does not store the usage object, write that, and do not guess the bill from the length of the paragraph. Do not ask the model how many tokens it used. You will get a fluent estimate of a response you still have not opened.

This is the usage object on one successful response. It is not the identifier of the model that ran. Name the model the request hit is that string, and whether the string you sent was the string that came back. A model id is not a count. It is not why the tokens stopped. Name the stop the response carried is stop_reason. A completed turn can be expensive, and a turn cut off at the budget can be cheap. The reason is not the bill. It is not the tool. Name the tool the model called is the tool, the arguments, and whether it ran. A tool's name is not input_tokens. It is not the clock. Time the answer the customer waited is the duration. A fast call can bill more than a slow one. The design question of which decisions set the multiplier, before a single response is opened, is what makes an AI feature expensive to run. That page is the ordering. This page is the fields on one call. Do not store the essay's multipliers as if they were this response.

None of what follows is a rate for this product, and none of it is a price you should quote a customer from a table. The fields below are one vendor's current description of a usage object, and the prices beside them are that vendor's current list. The latencies below that are a 2024 research prototype on open models. An open model on a lab GPU is not a Claude call. A dollar on a pricing table is not the invoice for Tuesday. Do not ask the model to reconcile them.

Anthropic's Messages API bills and rate-limits by the counts in usage, because tokens are the cost to the system. The reference says the API transforms the request into a format for the model, and the model's output then goes through a parsing stage before it becomes the response. As a result, the counts will not match one-to-one with the visible content of the request or the response. The example they give is output_tokens non-zero even when the response text is an empty string. An empty string is not 0 output tokens. Total input, on that same reference, is the sum of input_tokens, cache_creation_input_tokens, and cache_read_input_tokens. input_tokens alone is not the total. A log that stores one of the three and drops the other two has not stored the bill (Anthropic, Messages).

The same page's sample object is an illustration, and its fields do not collapse into each other. cache_creation_input_tokens prints 2051. cache_read_input_tokens also prints 2051. input_tokens prints 2095. output_tokens prints 503. 2051 is not 2095. 503 is not 2051. Adding the three input fields is a total the sample does not print, so do not write 6,197 into a ticket and cite the sample. Inside cache_creation, ephemeral_5m_input_tokens prints 0 and ephemeral_1h_input_tokens prints 0. 0 plus 0 is not 2051. The parent and the two children, in that example, are not the same fact. Do not repair the example by deciding which field is wrong. output_tokens_details.thinking_tokens prints 0. The reference says thinking_tokens is always less than or equal to output_tokens, and that output_tokens minus thinking_tokens approximates the non-reasoning output. 503 minus 0 is 503 in this sample. That identity is the sample. It is not a rule that thinking is always zero. output_tokens remains the inclusive total used for billing. The approximation is not a second bill.

Two more fields in that sample are not tokens. server_tool_use prints web_fetch_requests 2 and web_search_requests 0. 2 is a count of fetches. It is not 2 tokens, and it is not 503. service_tier prints standard, and speed also prints standard. The same word is two fields. A batch tier is not a fast speed, and a standard tier is not a standard speed, even when both strings match. inference_geo prints global in the sample. A geographic hint on the response is not a token count, and it is not the region you promised a customer their rows sit in. stop_reason in the sample is end_turn. That value is the other article. It does not say what the call cost. A count-tokens request, POST /v1/messages/count_tokens, is a different call. It estimates an input before you send it. It is not the usage object on the response you already got. Do not paste a pre-flight count into the bill.

What the cache fields mean, when caching is on, is a second page, and it disagrees with a casual reading of the name input_tokens. The caching guide says input_tokens is only the tokens after the last cache breakpoint, not all the input you sent. cache_read_input_tokens is the prefix already cached. cache_creation_input_tokens is the prefix being written now. The guide's example is 100,000 read, 0 created, 50 after the breakpoint, and a total of 100,050. 100,050 is their sum for that example. It is not 2051, and 50 is not 2095. 100,000 in that example is cached content in one request. It is not the 100,000-token price threshold on a Haiku row further down the same page. A read is not a write. 0 created, next to 100,000 read, is a hit. 0 and 0, for both cache fields, is the guide's signal that the prompt was not cached. Both zero is not a successful read. The guide says a prompt shorter than the model's minimum is processed without caching and no error is returned. A missing error is not a cached prompt (Anthropic, Prompt caching).

The minimum is not one number. On the Claude API and the listed platforms, the guide prints 512 tokens for one group of models, including Haiku 5.5, and 4,096 for Haiku 4.5. The same family name, a different floor. 512 is not 4,096. Opus 4.6 and Opus 4.5 print 4,096. Opus 4.8 prints 1,024. 1,024 is not 4,096. Mythos Preview and Opus 4.7 print 2,048. Haiku 3.5 prints 2,048 as well, and it is not the same model as Opus 4.7. A range someone remembers as 512 to 4,096 is a span across rows. It is not the floor of the model that answered. The ordering constraint, tools then system then messages, and the instruction to put the breakpoint on the last block whose prefix stays identical, already live on the cost page. This page does not re-derive them. A timestamp early in the prompt is still a miss. The miss shows up as a write, or as two zeros, not as a sentence.

The price multiples are printed twice, and the exceptions are the point. Five-minute cache writes are 1.25 times base input. One-hour writes are 2 times. Cache reads are 0.1 times, except where a footnote says otherwise. 1.25 is not 2. 0.1 is not 1.25. A later sentence says writes cost 25% more than base, which is the 1.25, and reads cost 10% of base, which is the 0.1, or 2.5% on Claude Fable 5.1 and Claude Mythos 5.1, or 5% on Claude Opus 5.5 and Claude Sonnet 5.5. 10 is not 2.5 is not 5. 25% more is not 2 times. Footnote 1 prices Fable 5.1 and Mythos 5.1 hits at 0.025 times base. Footnote 2 prices Opus 5.5 and Sonnet 5.5 hits at 0.05 times. 0.025 is not 0.05 is not 0.1. The Opus 5.5 row prints base input $4 per million, a five-minute write $5, a one-hour write $8, a hit $0.20, and output $20. $0.20 is the 0.05 footnote applied to $4. It is not the $5 write. Haiku 5.5 at or under 100,000 prompt tokens prints base $0.10, and over 100,000 prints base $0.50. $0.10 is not $0.50. That 100,000 is the price tier. It is still not the guide's 100,000 cached tokens. Breakpoints themselves add no cost. The guide allows 4 breakpoint slots. A fifth explicit breakpoint, or a top-level cache control whose lifetime disagrees with the last block, returns a 400. A 400 is not a usage field. There is no count to name, because the request did not succeed. The streaming page on the stop-reason article already separates a 400 from a stop reason. Do not record one as the other.

The lifetime is a clock, and it is not the price. The default is 5 minutes, measured from the start of the request that writes or reads the entry, not from the end of the response. If a response takes 4 minutes to stream, a follow-up that wants the same prefix has about 1 minute left. 4 is not 5. About 1 is not 5. A one-hour lifetime is a different product, at the 2 times write price. Using a cached prefix refreshes it at no additional cost. A refresh is not a write. 4 breakpoints are not the 20-block lookback. The guide's turn-3 sketch has 35 blocks, checks 20 positions, and misses an entry sitting at block 15. 35 is not 20. 15 is not 16. A conversation that grows by 20 or more blocks past the last write misses. That 20 is blocks, not dollars, and not the 512-token floor.

A research system that reuses attention states is not this API, and its own sentences do not all use the same range. In Gim, Guojun Chen, Seung-seob Lee, Nikhil Sarda, Anurag Khandelwal, and Lin Zhong, at Yale, with Sarda at Google, presented Prompt Cache at MLSys 2024. The abstract says time-to-first-token drops from 1.5 times to 10 times for GPU inference with prompt modules in GPU memory, and from 20 times to 70 times for CPU inference, without any significant accuracy loss. The body, on the same GPU machines, says 1.5 times to 3 times when the modules are loaded from CPU memory, and 5 times to 10 times when they sit in GPU memory. 1.5 to 10 in the abstract is not 5 to 10 in the body. 20 to 70 is CPU inference, a different machine from either GPU range. 3 times is not 70 times. None of these is a price multiple. 0.1 times money is not 10 times faster (Gim et al., Prompt Cache).

The machines and the scores are a third cut, still not a bill. GPU benchmarks used an RTX 4090, an A40, and an A100. The A40 and the A100 are virtual nodes, each with a 16-core processor and 224 GB of RAM. The CPU pair is an Intel i9-13900K with 128 GB of DDR5 at 5600, and a Ryzen 9 7950X with 128 GB of DDR4 at 3600. 128 is not 224. 5600 is not 3600. DDR5 is not DDR4. 16 cores is not 128 GB. They used models that fit in 40 GB. LongBench, as they use it, is 21 datasets across 6 categories, context from 4K to 10K, averaging about 5K tokens. The figures show 8 datasets. 8 is not 21. 4K is not 10K. 5K is not 512, and it is not 4,096. Table 1 prints two scores per model. On NarrativeQA, Llama 2 7B prints 19.93 and 19.38. On 2Wiki, 16.63 and 13.95. 19.93 is not 19.38. 16.63 is not 13.95. The paper does not print the subtraction. Do not invent a delta and cite the cell. They mark outliers where one score exceeds the other by more than 2.5. More than 2.5 points is not 2.5 times, and it is not the memory table's 2.5 MB per token for Llama 70B. That memory table is megabytes per cached token: BERT 0.03, Falcon 1B 0.18, Llama 7B 0.50, Llama 13B 0.78, MPT 30B 1.31, Falcon 40B 1.87, Llama 70B 2.5, Falcon 180B 4.53. 0.50 is not 0.03. 4.53 is not 40 GB. Falcon 180B is in the memory table. The accuracy runs are the models that fit. A 7B score is not a 180B score. Decoding is greedy, the highest-probability token. It is not the temperature on some other paper. These models do not return input_tokens. A 5 times faster prefill is not a cache_read_input_tokens field.

Do the three proofs on one real response, in the log that actually stored usage. First, the fields. Copy input_tokens, output_tokens, and, when they are present, cache_creation_input_tokens, cache_read_input_tokens, and the two ephemeral children. If the log kept the text and dropped usage, write that the object was not stored. Do not estimate tokens by dividing characters by four. Second, the split. If the cache fields are absent, say so, and do not treat input_tokens as a total you have proved. If both cache fields are zero, the guide's reading is that this request was not served from cache. If a read is non-zero and a write is zero, you have a hit, not a write. If the children do not add to the parent, write both numbers. Do not pick one. Third, the other request. A different call, the same day, has a different split, or you write that every stored response has the same counts. One object is a fact. It is not a unit price. If the only number you have is the monthly invoice, you do not have this proof.

Three moves feel like the proof and are a second problem. Asking the model how many tokens it spent. Multiplying a character count by a rule of thumb and putting the product in the bill. Treating the count-tokens endpoint as the usage on a response you already sent, or treating a 400 as a zero-token success. A user text that replaced the instruction is when the user rewrote the rule. The usage object does not say the instruction lost. It says what the call consumed. Two answers to one question are when one question gets two answers. A second sentence is not a second price unless you stored both usage objects.

The shape of a product that can refuse to quote a cost it did not store, without refusing every answer, is narrower than a pricing table. The support agent we shipped for a DTC brand answers order status, returns, and product questions from order data, policies, and the catalog, and it can look up an order, start a return, or change an address behind a permission check, with escalation to a person. It is not a token ledger. Nothing in that description is a headcount, a duration, or a result figure. The shape is the split: a lookup you are willing to send is a lookup whose usage you stored, and a lookup whose usage you dropped is not a cost you can defend. A design that stores the prose and drops the object cannot make that split.

There is a version of this response where hiring the path is the wrong purchase. Nothing is in production. No model is being called, so there is no object to read. The user sent two questions and got two answers. That is the pair the other article already covers, and it is not a missing bill. A customer has already seen another customer's data. A token count does not close a leak. The wrong value was already a write. The object tells you what the call consumed. It does not undo the row. Or no metric was ever named, so there is nothing a later eval can fail. The questions for that gap are not this page.

When the response is real and the object is not in the log, the missing object is specific. The input fields, the output field, the split between a read and a write, and one other call whose counts you can also name. An AI pilot failed to reach production engagement is for the system that is already in front of customers and cannot yet show those: audit in the first one to two weeks, finished in 8–12 weeks, scoped after the audit, unpaid if the agreed metric does not move, rollout behind a human-review gate. The triple you wrote tonight is the kind of case the harness has to include, or the next release will be just as fluent and just as unpriced. The harness is AI evaluation and observability. An AI integration sprint is the shape where the acceptance sentence can require the object on every stored response. If you do not yet know whether the pilot can be saved, a two-week AI readiness assessment hands you the findings either way. Those are the terms on the site. They are not a promise that every short answer was cheap, and they are not a rate. $0.20 is one row's cache hit. 19.93 is one cell on a lab benchmark. Neither is your log.

A factor an account enrolled, and a migration a deploy applied, are different objects: show the factor they enrolled and name the migration the deploy applied. Do not record either on this page. An authenticator is not a token count. A schema version is not a bill.

Before you tell anyone what the call cost, do the three proofs and write the fields. Name the token counts, or write that usage was not stored. Show a cache read is not the uncached input, and not a cache write. Show another request that billed a different split. Do not ask the model for the count, and do not divide the paragraph by four. The prose is what they would have read. The object is the page you can defend.