How to track OpenAI API costs — 5 methods compared
Last verified
If you want the number right now: platform.openai.com/usage.
If you want to not be surprised by an invoice again, the question is different — it is not "where is the data" but "what makes me look at it". Here are the five options, honestly.
1. The usage dashboard
What it is: the built-in view at platform.openai.com/usage — daily cost chart, per-model breakdown, date filters.
Good: free, no setup, accurate, official.
Bad: OpenAI only. Requires you to remember. That second one is not a small caveat — it is the entire reason surprise bills exist. The data was always there.
Use it when: you want a definitive answer to a specific question right now.
2. The Costs API
What it is: GET /v1/organization/costs with an admin key — daily buckets, groupable by project.
Good: programmatic, scriptable, the same numbers you'll be billed. Feeds a Slack digest, a spreadsheet, or a CI check.
Bad: needs an admin key, which needs org ownership. Daily cadence, so no tight loop. You build and maintain whatever consumes it.
Use it when: you want a daily automated report and you're comfortable writing a script. Full details: the OpenAI Costs endpoint, explained.
3. CSV export
What it is: export usage from the dashboard and open it in a spreadsheet.
Good: zero code, finance-friendly, easy to share with someone who doesn't have console access.
Bad: manual, point-in-time, no alerting. It's a report, not a monitor.
Use it when: someone in finance needs the numbers, or you're reconciling an invoice.
4. A proxy or gateway
What it is: route requests through Helicone, Portkey, LiteLLM or similar. They observe each call, count tokens, and multiply by a price table.
Good: near-real-time, per-request granularity, and the only practical way to get per-feature and per-customer attribution. Adds caching and fallback routing as a bonus.
Bad: a third party is now in your request path — latency, an availability dependency, and visibility of prompts and responses. Requires code changes. Their numbers are computed, not billed, so they can drift from your invoice.
Use it when: you genuinely need per-request attribution. If you're asking "which endpoint costs the most", this is the honest answer and you should use it. Proxy vs billing API has the full tradeoff.
5. A tracker on your phone
What it is: an app that reads the billing API and shows you the number without you going to look. TKN is one; there are others on the App Store.
Good: multi-provider in one figure, and it removes the "remembering" problem, which is the actual failure mode. TKN adds spend rules and a kill switch that revokes at the provider.
Bad: daily cadence, because it reads billing APIs. Needs an admin key. No per-feature attribution.
Use it when: you want to know before the invoice, across several providers, without building anything.
Picking
| If you need | Use |
|---|---|
| The number, once, right now | The dashboard |
| A daily automated report | The Costs API |
| To hand numbers to finance | CSV export |
| Cost per feature or per customer | A proxy |
| To not be surprised, across providers | A phone tracker |
| To stop a leak from your phone | TKN specifically |
Most people need two: a hard spend limit as a backstop, and one daily number they see without seeking it out. Everything else is optimisation.
What none of these do
No billing-based method gives you real-time spend — billing APIs are daily by design. And no method stops anything on its own; a dashboard is not a control. That's what spend limits and revocation are for.