An OpenAI API bill usually goes up for one of a few reasons: more requests, more tokens per request, a more expensive model or setting, or an API key being used by something nobody planned for. To find which, look at daily cost for the last six to eight weeks and note the first day it rose. Then group the cost from that day on by project, API key and model, and compare the request count and the cost per request before and after.
Check that usage actually went up
Start with the Usage page in the OpenAI platform rather than the card statement. New API accounts are prepaid, and auto-recharge, which is on by default, buys credits when the balance runs low. A larger charge can be a larger top-up, or two top-ups in one month, with no change in what you used.
Then compare like with like. The Usage page shows dates in UTC, so a month in your own time zone covers slightly different hours, and a 31-day month costs more than a 30-day one at the same daily rate. Leave out the last day or two, since recent days can still change. If you get an Enterprise invoice, it hasn't itemized API costs since April 1, 2026, so use the cost export on the Usage page instead.
Find the day the cost changed
Look at daily cost rather than the month-to-date total. A running total only rises, and it hides when the change happened. On a daily chart, the pattern points to the kind of cause.
| What the daily chart shows | Usual causes |
|---|---|
| A jump on one day that stays | Something shipped that day: a deploy, a new feature, a model switch, or a job that started looping |
| One or two expensive days, then back to normal | A backfill, a batch job, a load test, or retries during an incident |
| A gradual rise over several weeks | More users, or more use per user. Check cost per request as well |
Write down the first day of the change. Every later step asks what was different from that day on.
On our founder's team, before Braid existed, a bug kept calling an OpenAI endpoint for almost two weeks. Daily spend went from about $2 to more than $90, and the bug cost $1,051.96 before it was stopped. The jump was obvious on a daily chart. Working out which project, key and model it came from took real work.
Narrow it down by project, API key and model
Group the cost from the change onward, on the Usage page or with the Costs and Usage APIs. Our post on how to see OpenAI API costs by project, key and model shows where each view is.
Group by project
Look for the project whose cost moved on the day you noted. If everything runs in the Default project, this step won't tell you anything, and it's a good reason to give each use case its own project once you've found the cause.
Group by API key
Within that project, group by API key. OpenAI added API-key grouping to its usage and cost dashboards and APIs on August 4, 2026, so older forum answers saying it can't be done are out of date. Look for a key you don't recognize or that was created recently, a developer's personal key that a service is using, or a key that's spending when nobody is running anything with it. Treat that last case as a leak. Rotate the key first and investigate after.
Group by model and line item
Group usage by model and cost by line item. Line item names pair a model with a kind of charge, such as input or output tokens, so a model that first appears on the day of the change stands out. These are the common findings at this level:
| What you find | Why it costs more |
|---|---|
| A switch to a larger model | Higher prices per token. In November 2026 list prices, gpt-6.1-sol costs 20 times as much per token as gpt-6-luna |
| A reasoning model, or a higher effort setting | Reasoning tokens are billed as output. See OpenAI reasoning tokens: what they are and what they cost |
| Requests sent with Fast mode (formerly priority processing) | A premium on every token |
| Prompts over 272K tokens | A higher price per token for long prompts |
| Regional data processing | 10 percent extra on newer models |
| Built-in tools such as web search or file search | A charge per call, on top of the tokens |
Check whether requests or cost per request went up
Get the request count for the same project and model from num_model_requests in the Usage API, divide the day's cost by it, and compare the days before and after the change.
| What you see | Likely causes |
|---|---|
| More requests, same cost per request | More traffic, a new customer, a backfill, a retry loop or a script stuck in a loop |
| Same requests, higher cost per request | Longer prompts or outputs, a model or tier change, higher reasoning effort, or prompt caching that stopped working |
| Both up | A new feature or workflow, often an agent that makes several calls per task |
Prompt caching needs a check of its own. Cached input is billed at a tenth of the input price or less on GPT-5.6 and later, and a cache hit needs the start of the prompt to match exactly. A change that puts something variable at the top of the prompt, such as a timestamp or the user's name, turns cached input back into full-price input. Compare input_cached_tokens with input_tokens in the Usage API for the days before and after.
Match it to a change and contain it
With a project, key, model and date, check what your team changed that day: deploys, prompt edits, feature-flag rollouts, new scheduled jobs, and incidents with retries. Ask the project's owner whether the increase was expected. If nobody knows who owns the project, put that on the list of things to fix.
If the spend isn't expected, contain it while you investigate:
- Rotate or revoke the API key if it might be leaked or misused.
- Set a hard spend limit on the project, under Project settings, then Limits, then Spend. Once it's reached, requests fail with a 429 error and the code
project_spend_limit_exceeded. OpenAI says enforcement isn't instantaneous, so recorded spend can slightly exceed the limit. - Lower the project's rate limit for that model to slow a runaway job while you fix it.
Spend alerts help you catch the next one sooner, although they only notify and don't stop traffic. Our guide to OpenAI spend alerts and limits covers how alerts and hard limits work together.
Common questions
Why did my OpenAI bill go up when my usage didn't?
First check whether the charge was a credit top-up. With auto-recharge, a larger or extra top-up raises the card charge without any change in usage. If cost on the Usage page rose but request counts didn't, cost per request went up, so look for a model switch, more reasoning, Fast mode, longer prompts or prompt caching that stopped working.
How do I see which API key is costing the most?
On the Usage page, filter to the project and group cost by API key. Through the API, call GET /v1/organization/costs with group_by=api_key_id and an Admin key. Both have been available since August 2026.
How do I stop my OpenAI API bill from going over a set amount?
Set a hard monthly spend limit on the organization or on a project. Once it's reached, requests fail with a 429 error until the next monthly cycle or until you raise the limit. Enforcement isn't instantaneous, and spend alerts on their own don't stop any traffic.
Why doesn't my OpenAI usage match what I paid?
On a prepaid account, payments are credit purchases, and they don't line up with a month of usage. UTC dates, credits and recent days that are still changing add to the gap. Our post on why OpenAI usage doesn't match the invoice has a month-end routine for explaining it.
Where Braid fits
Braid is built around these questions. It reads cost and usage from your OpenAI organization with a read-only Admin key and maps each project and API key to an Implementation, a use case your company names, with an owner, a team and a monthly budget. Every Monday it emails a report of spend by Implementation and what changed. It also flags unusual spend in the app and by email, with the affected Implementation and source details when the data supports them.
It doesn't stop requests or change anything in your OpenAI account, so keep OpenAI's spend limits in place. The beta currently supports OpenAI API accounts. More provider connections are planned.