OpenAI API costs too high? Audit your bill before changing models
If your OpenAI API bill is higher than expected, first trace the increase to a specific workload. Compare the same reporting period and account scope, identify the largest billed categories, then connect them to the requests your application makes. A model change is easier to judge once you know what caused the spend.
The useful question is: what did it cost to complete the task the user actually needed? A growing bill may reflect more completed work, more work per task, or activity you did not intend to run. Those require different responses.
1. Establish the amount you are investigating
Write down the start and end of the period, its time zone, the organisation, the projects included and the service that billed you. Keep the invoice or billing statement alongside the cost report. Separate usage charges from credits and other adjustments shown on your own statement before comparing totals.
OpenAI exposes separate usage and costs reporting. Its Costs endpoint provides monetary amounts and supports breakdowns including project and line item. Use those cost records to investigate spend, and usage records to investigate the activity behind it. OpenAI usage and costs reference.
Do not force a token estimate to equal an invoice. First check that both cover the same scope, dates and categories. If a difference remains, record the unexplained amount and the evidence needed to resolve it. A reconciliation with a visible gap is more useful than a tidy total built on assumptions.
2. Follow the spend into one workflow
Choose the largest unexplained category or the clearest increase. Ask which project, model and application workflow contributed to it, using the breakdowns available in your reports and logs.
For that workflow, record completed user tasks as well as API requests. Link a task identifier to its request records, model, timing and reported usage. Keep credentials and unnecessary personal content out of the worksheet; request metadata is usually a better starting point than copying full prompts.
Inspect a small sample of task histories. Look for repeated submissions, extra model steps, retries, or a background job running more often than intended. Treat each as a hypothesis until the records support it. A failed request or a timeout alone does not establish whether it incurred a charge: retain the response information and compare it with reported usage.
A hypothetical example
Suppose a workflow completes 1,000 tasks. In one period, each task makes two model calls. In the next, each makes five, while the model, token quantities per call and applicable rates stay unchanged.
That is 2,000 calls versus 5,000: 2.5 times as many calls for the same number of completed tasks. Under those assumptions, the model-call cost also rises by that factor. This is arithmetic, not a measured client result. Real requests vary, so use your own recorded quantities before drawing the same conclusion.
3. Check what each request consumes
Review the categories that apply to your workload:
- Input and caching: inspect the input quantities and any reported cached portion. Do not assume repeated text received a particular rate.
- Generated output: compare output usage with what the task needs, rather than estimating it from the length of the displayed answer.
- Tools and storage: check the billed items beyond model tokens. OpenAI's pricing documentation includes separate charging units for services such as web search, file search and containers. Match each item to its current rules. OpenAI API pricing.
For reasoning models, reasoning tokens are billed as output even though they are not visible in the answer. The Responses API's max_output_tokens covers generated tokens, including reasoning; reaching that limit can leave a response incomplete. Check the usage details and completion status together before tightening it. OpenAI reasoning documentation.
Keep a copy of the applicable model and service pricing references with your audit date. This worksheet deliberately supplies no model rate table: the aim is to explain your actual workload before comparing alternatives.
4. Complete an audit worksheet
Copy this table for each workflow you investigate. Fill it with observations first; keep proposed explanations separate. “Unknown” is a valid entry when telemetry is missing.
| Audit field | Your record |
|---|---|
| Period and scope | Start/end, time zone, organisation, project and service |
| Billed category | Cost-report line item, amount and currency |
| Completed work | Task definition and number completed |
| Observed driver | Request count, usage category or storage quantity |
| Evidence | Report/export date and safe log reference |
| Hypothesis | What may explain the increase? |
| Bounded change | One proposed change and the test scope |
| Acceptance checks | Required quality, completion rate and latency |
| Measured result | Before/after cost per completed task and checks |
| Remaining gap | Unexplained amount or missing evidence |
For example, “the same document appears twice in the input” is an observation if the request records show it. “Removing the duplicate will preserve answer quality” is a hypothesis to test. Keeping those statements separate prevents a plausible cost fix from becoming an unexamined product change.
5. Test one change against the task outcome
Choose a change that addresses the measured cause. If duplicate context is present, test removing it. If the workflow makes unnecessary calls, test a simpler sequence. If output is longer than required, test a tighter response requirement. Consider another model only with a representative set of tasks and explicit acceptance criteria.
Use comparable workloads before and after the change. Record cost per completed task alongside the quality, completion and latency checks you defined. Include unsuccessful attempts in the workflow's total cost; excluding them could make an unreliable version look efficient.
Avoid changing the model, prompt and workflow simultaneously if you need to understand which change helped. Keep the previous version available so a cheaper but less useful result is easy to reject.
6. Verify what your spending control actually does
An alert and an enforced limit have different effects. OpenAI documents spend alerts that notify while traffic continues, and optional hard limits for organisations or projects that make affected requests return 429 after tracked spend reaches the limit. Enforcement is not instantaneous, so recorded spend can slightly exceed it. OpenAI spend limits.
Check which control is enabled for your scope. Before enforcing a limit, decide what users should see if their task cannot proceed, and who responds to an alert. A spending control helps contain exposure; the audit explains what should change.
Start with one workflow and one completed worksheet. Once its costs are understood, the AI API pricing comparison provides broader context for comparing providers; check current official rates before making a decision.