You estimated the bill based on request count and rough token math. The actual number came in higher, and the OpenAI dashboard shows a total, not a story. Four things most commonly explain the gap — none of them are billing errors, they're just charges that don't show up in a simple "tokens in, tokens out" mental model.
1. Reasoning tokens bill at full output price, aren't visible in the response, and get no discount from caching or batching.
2. Cache writes have their own charge — if you write more than you read, caching can cost more than not caching at all.
3. Break the bill down by day and endpoint first; a spike concentrated in one place points to an incident, not organic growth.
Four Things That Explain a Surprise Bill
1. Reasoning tokens Often the biggest gap
On models that support extended reasoning, the model generates internal "thinking" steps before producing the visible response. These reasoning tokens are billed at the same rate as standard output tokens, but they're not part of what you see in the response text — a token count based on visible output alone will systematically undercount what you actually paid for. Reasoning tokens also don't benefit from prompt caching or the Batch API discount; the levers that reduce cost elsewhere in your stack simply don't apply to this category.
2. Cache write charges Can backfire if misused
Prompt caching has two prices: a write cost (when content is first cached) and a read cost (when a subsequent request reuses that cache, at a steep discount). If the cached content changes on nearly every request — a system prompt with dynamic content near the top, for instance — you're paying the write premium repeatedly without ever recouping it through cheap reads. Caching only pays off when the same content is actually being reused; caching content that's effectively unique every time adds cost rather than removing it.
3. Retry storms Shows up as a single-day spike
A downstream timeout, a malformed response triggering automatic retries, or a bug in error handling can multiply the effective request count for a narrow window without anyone noticing in real time — the symptom isn't a gradually rising bill, it's a sharp spike concentrated on one day or one endpoint, which is exactly what makes it identifiable if you know to look for that shape.
4. Model mismatch The slow, quiet driver
Unlike the first three, this one doesn't spike — it's a steady tax from running a more expensive model than a given task requires. It's the hardest of the four to spot from the bill alone, because it looks like normal usage rather than an anomaly; it only becomes visible once you break spend down by endpoint and compare task complexity against model choice.
Want your bill broken down by these categories automatically?
Preto shows cost by model, by feature, and by user — so "the bill went up" becomes "this endpoint's reasoning tokens went up."
See Your Real OpenAI Cost BreakdownPreto breaks down your OpenAI bill by model and feature and user. Free.
How to Actually Diagnose a Spike
Start with time and location, not category. Break the bill down by day first — is the increase spread evenly across the billing period, or concentrated on a handful of days? Then break it down by endpoint or feature. A spike that's narrow in both time and location (one bad day, one endpoint) points to an incident: a retry storm, a bad deploy, a misconfigured loop. A spike that's spread evenly across time and features usually means genuine usage growth or a broad pricing or usage-pattern shift, not a bug.
Only after narrowing by time and location does it make sense to dig into which of the four categories above is responsible — checking reasoning-token volume, cache write-to-read ratio, retry rates, and model-to-task mismatch on the specific narrow window or endpoint you've identified, rather than across the whole account at once.
Why This Isn't Visible in the Standard Dashboard
OpenAI's usage dashboard shows spend, mostly by model, over time. It doesn't natively break down reasoning tokens as a separate line from standard output, doesn't show cache write-versus-read ratio per prompt, and doesn't attribute cost to your own internal feature or endpoint concept — because it has no visibility into which part of your app made the call. That attribution has to happen at the point requests pass through your own infrastructure, which is the same reason per-user cost tracking requires tagging at the proxy layer rather than being reconstructable after the fact from the provider's own billing page.
Once that attribution exists, "the bill went up" stops being a mystery and becomes a specific, answerable question — which is the difference between guessing at the four categories above and actually confirming which one applies to your spike.
Frequently Asked Questions
Why is my OpenAI bill higher than my token math predicted?
Do reasoning tokens get any discount from caching or batching?
Why did my bill spike after I added prompt caching?
What's the fastest way to find an unexpected cost spike?
Turn "the bill went up" into a specific answer.
Preto breaks your OpenAI spend down by model, feature, and user — so the next surprise bill comes with an explanation attached.
See Your Real OpenAI Cost BreakdownFree forever up to 10K requests. No credit card required.
