Your OpenAI Bill Doubled. Here's How to Find the Feature That Caused It.

By the solo builder of LLMtrack. OpenAI dashboard features and rates were checked on 20 October 2026 against OpenAI's own docs and changelog. How I check the numbers.

The invoice is one number. When it doubles, the question is which part of the product did it, and the honest answer is that OpenAI's dashboards get you most of the way there now, provided you set things up so they can.

This is part of our guide to LLM and AI cost optimization.

Step 1: find the day it changed

Open the Costs view in OpenAI's usage dashboard and look at daily spend for the last 30 days. You're looking for a step: a day where spend jumped and stayed up, or a single day that spiked and fell back.

The two shapes mean different things. A step that stays up is usually a code or config change that shipped that day: a new model, a new prompt, a new feature. A one-day spike that falls back is usually a loop, a batch job or one customer doing something unusual.

Write the date down. Everything after this is about matching it to something that happened.

Step 2: group by model

Group the same range by model. If a model that wasn't there before shows up on the day of the step, you've probably found it.

A detail worth knowing: the gpt-5.6 alias routes requests to gpt-5.6-sol, the most expensive model in that family. Code that asks for gpt-5.6 thinking it gets a default mid-tier model pays Sol rates.

A worked example of how much a model switch moves the bill. A summarizer handling 100,000 requests a month at 1,200 input and 300 output tokens costs $27 a month on GPT-6 Luna ($0.10 input, $0.50 output per million). Move it to GPT-6.1 Sol ($2 and $10) and the same traffic costs $540. Twenty times more for one line changed in a config file.

Step 3: group by API key

Since 4 August 2026 the Usage and Costs dashboards can filter and group by API key, and the Usage API and Costs API support the same dimension if you'd rather pull it into a spreadsheet.

If each service or environment has its own key, this is the step that names the culprit. If everything shares one key, it tells you nothing, and that's a very common setup.

Step 4: check the seven usual causes

Once you know the day, the model and the key, one of these is almost always the reason.

1. A model switch

Someone changed the default model, or an alias started pointing somewhere new. Step 2 shows it as a new model appearing on the day of the step. Compare per-request cost before and after with the OpenAI API cost per request tables.

2. Higher reasoning effort

Reasoning tokens bill at the output rate and never show in the reply. If output tokens per request jumped while request count stayed flat, look for a reasoning effort setting that went from low to high, or a model that reasons by default. More in reasoning tokens, the invisible line item.

3. Conversation history growing

Every chat turn re-sends the whole conversation. If input tokens per request climb steadily over days rather than in one step, long conversations are the likely cause. See how conversation history inflates chat costs.

4. Retries

Request count goes up without more users. Since 2 September OpenAI returns a 429 with the slow_down code when traffic rises too fast and a 503 with server_is_overloaded when a model is overloaded, both sometimes with a Retry-After header. A retry loop that ignores the header and hammers the API multiplies requests at exactly the wrong moment. See how retry logic inflates an LLM bill.

5. A prompt cache that stopped hitting

Cached input costs 5% to 10% of the input rate on the GPT-6 models. If someone edits the start of a long system prompt, every request after that pays full price for it. OpenAI's Prompt Caching dashboard, added on 20 August, shows cache hit rate over time, and Prompt Cache Diagnostics in the Responses API tells you why a request missed. A drop in hit rate on the day of the step is a strong lead. See prompt caching, the discount most apps leave off.

6. Fast mode or long prompts

Two price changes that need no new model at all. Fast mode costs twice the Standard rate. Prompts past 272K input tokens switch to the long-context rate, which on GPT-6.1 Sol doubles input from $2 to $4 per million. A document feature that slowly grows past that line doubles its unit cost on its own.

7. One heavy customer

A single customer running an automation can outspend everyone else. OpenAI's dashboards can't show this unless each customer has their own key or project, which most products don't do. This is the cause that's hardest to see and the one that hurts margin the most. See the unit economics of AI features.

Put a ceiling on it while you look

Since 22 July 2026 you can set a hard monthly spend limit on an organization or a project. When tracked spend reaches it, affected requests return a 429. Pair it with spend alerts so you hear about it before traffic stops. A hard limit protects the budget, but it also stops the product, so set it per project rather than only on the whole organization. More in LLM cost alerts and budget limits.

What OpenAI's dashboards can't tell you

They group by what OpenAI knows: day, model, project, API key, service tier. They don't know which product feature a request came from or which of your customers it was for.

You can fake it with one key per feature, or one project per customer. In practice that falls apart quickly. Keys multiply, new features ship on an existing key, and nobody keeps it up for long. It also only covers OpenAI. If you call Anthropic or Google too, you're stitching dashboards together.

The permanent fix: label each request

Put a feature name and a customer ID on every request, the moment it completes. Then the next spike shows up as "summarizer, customer acme-corp, since Tuesday" instead of a total.

You can build this yourself: log usage to your own database with a feature column, and keep a price table current. For one model and one feature that's probably enough. If you'd rather not maintain the price table, LLMtrack does AI cost tracking per feature, model and customer from one call after each response:

import { LLMtrack, fromOpenAIUsage } from 'llmtrack'

const llmtrack = new LLMtrack({
  apiKey: process.env.LLMTRACK_API_KEY,
  onError: (e) => console.warn(e.code, e.message),
})

const res = await openai.chat.completions.create({ model: 'gpt-6-luna', messages })

llmtrack.track({
  provider: 'openai',
  model: res.model,
  feature: 'summarizer',
  customerId: 'acme-corp',
  ...fromOpenAIUsage(res.usage),
})

The call runs after the response, never throws and never blocks the user's request. Give each call site its own feature name. If everything is called chat, the breakdown is one bar. Prefer raw HTTP? See the API reference.

FAQ

Find the expensive feature from your next request. The free plan includes every feature: start free.

Sources

• OpenAI API changelog: API key grouping (4 August 2026), hard spend limits (22 July 2026), Prompt Caching dashboard (20 August 2026), error codes (2 September 2026), the gpt-5.6 alias (9 July 2026)
• OpenAI spend limits guide
• OpenAI API pricing, checked 20 October 2026

Related guides

• OpenAI API cost per request, per user and per month
• Real-time vs delayed LLM monitoring
• LLM cost alerts and budget limits: a setup guide

Last updated 20 October 2026. OpenAI's dashboard features and rates were checked that day and change often.