And OpenAI does input_tokens 180° differently

Yesterday I wrote about Anthropic, where input_tokens excludes cache reads and cache writes. You'll be surprised to find out that OpenAI does almost the exact opposite, which creates a different cost intel trap.

On OpenAI, input_tokens already includes the cached tokens. Now that sounds easier until you price the whole column at the normal input rate. Let's look closer:

OpenAI’s own example shows input_tokens of 2,600 tokens.

Inside that total, 2,000 are cached reads, 400 are cache writes, and only 200 are ordinary input. The 2,600 is the total, not another bucket you add the cache fields to.

So if you take input_tokens and multiply the whole thing by the standard input price, you can materially overstate your cost.

Take GPT-5.6 Sol. Current pricing is $5 per million ordinary input tokens and $0.50 per million cached input tokens.

Now imagine one request reports 1,000,000 input tokens, with 995,000 of those reported as cached reads and 5,000 as ordinary input......

Price input_tokens as one normal bucket and you get $5.00. Then: price what actually happened and you get about $0.5225: $0.4975 for the cached input and $0.025 for the ordinary input.

Across 100 identical calls, the naive calculation says $500. The correctly separated input cost is $52.25.

Same input_tokens column. Nearly a 10x difference.

This is a hall of mirrors, mirror image of the Anthropic problem. With Anthropic, ignoring the cache fields can make the request look much cheaper than it really was. With OpenAI, treating the whole input_tokens field as uncached can make it look much more expensive.

And for good measure, OpenAI has added another wrinkle on GPT-5.6 and later: Cache writes are reported separately inside input_tokens_details and billed at a different rate, while cache reads are cheaper than ordinary input.

So the safe rule is not “multiply input_tokens by the input price.” The rule is: understand what your provider means by input_tokens, separate the billing buckets, and price each one correctly.

This becomes important when you compare customers, features or providers. If one side is undercounted and the other is overpriced, your margin comparison can be wrong before you even start analysing it.

To be honest....this can be as clear as mud most of the time and we all have better things to spend time on as founders.

That’s why Culpa does all of this for you. It reads the provider’s token fields, prices the relevant buckets separately, then attaches the result to the conversation, feature, customer and workflow.

If you’re calculating OpenAI cost yourself, check one request tonight.

After the headache, tell us how much of your input_tokens total was actually cached?