API Usage Response Parser
Paste a response body, get the usage fields pulled out and costed at your own rates.
Read a JSON body · recognised as OpenAI-style (prompt_tokens / completion_tokens). 13,210 billable tokens at the rates above.
- Uncached input
- 2,240 × $3 → $0.0067
- Cached input read
- 10,240 × $0.3 → $0.0031
- Cache written
- 0 × $3.75 → $0
- Output
- 730 × $15 → $0.01
- Billable tokens
- 13,210
- Total the response reported
- 13,210
- Cost per response
- $0.02
- At 1,000 responses/month
- $20.74 per month
- prompt_tokens
- 12,480
- completion_tokens
- 730
- prompt_tokens_details.cached_tokens
- 10,240
- completion_tokens_details.reasoning_tokens
- 512
- total_tokens
- 13,210
usage rather than counting your text. What is assumed is the inclusion convention, and it differs by shape: prompt_tokens is treated as INCLUDING cached_tokens, so the uncached input line is prompt_tokens − cached_tokens. reasoning_tokens is treated as already inside completion_tokens and is not billed twice. No cache-write line exists in this shape. Rates are yours and are applied flat: no minimum billing, no rounding to a billing increment, no discount tier, no per-request fee. If your invoice disagrees with this by a few percent, the difference is almost always one of those, or a cached-token line counted on the wrong side.The only token count that is not an estimate
Every other tool in this family approximates. This one does not: it reads the counts the provider itself returned, which are the numbers the invoice is built from. If a client-side count and this disagree, this is right — and the gap is worth understanding, because it is made of things you cannot see from your side: chat-template wrapping, role markers, the provider’s own serialisation of your tool schemas, and on some models a system preamble you did not write.
The part that costs people real money is the inclusion convention. In the OpenAI-style shape, prompt_tokens is the whole input and cached_tokens is a subset of it, so billing the two separately double-counts the cached portion. In the Anthropic-style shape, input_tokens excludes both cache lines, so ignoring them undercounts. Same idea, opposite arithmetic, and a cost model built for one provider silently produces the wrong number for the other. The tool prints which convention it applied so you can check it against your own invoice rather than trusting it.
Two other traps this makes visible. Reasoning tokens are billed at the output rate on the providers that report them, and they can dwarf the answer you actually received — a 700-token reply that carried 512 tokens of hidden thinking costs almost twice what the visible text suggests. And on a streamed response the usage object rides the final chunk, so a client that stops reading at the last content event never sees it at all, which is the usual reason a per-request cost log has gaps in exactly the places the requests were most expensive.