OpenAI cost attribution
Updated 12 July 2026 · first published 5 May 2026
OpenAI cost attribution starts before the request is sent. The API response can tell you token usage, but it cannot know which product surface, team, customer, or business workflow caused the call unless your application attaches that context.
Attribution should join three sources: request metadata, usage records, and invoice data. Request metadata gives ownership. Usage records give token counts and model. Invoice data gives the authoritative financial total.
Tags to capture
- Feature or endpoint name.
- Team owner and environment.
- Tenant or customer where allowed.
- Workload class such as realtime, batch, eval, support, or agent step.
- Prompt version, route policy, and fallback status.
Common attribution gaps
Teams often miss retries and fallbacks. A user sees one answer, but the system may have paid for multiple upstream calls. Another common gap is batch work: evals and enrichment jobs should be tagged separately from user-facing traffic so they can move to lower-cost asynchronous lanes.
The best OpenAI attribution reports do not stop at “which model cost the most.” They show which product decision caused that model to be used, and which owner can change it.
Related
- LLM cost attribution - general attribution principles.
- Anthropic cost attribution - attribution for Anthropic models.
- What is LLM FinOps? - the complete operating discipline.
Where should the metadata be attached?
At the outermost boundary that still knows why the call is happening — usually the handler or job that received the user action, not the SDK wrapper. Attribution attached deep in a shared client is already too late: by then the request has lost the product context, and every caller looks the same. Pass an explicit context object down and let the client read from it, so a new call site cannot be added without an owner.
Practically, that means a request-scoped context carrying feature, team, environment, and tenant; a wrapper that refuses to send without one in non-production; and a parent request ID so retries, fallbacks, and multi-step agent calls collapse back to the single user action that caused them.
Why don't OpenAI's own reports answer this?
The usage dashboard aggregates by API key, model, and project. That is infrastructure attribution, not business attribution — it tells you which key spent the money, not which feature or customer. Splitting keys per team is the usual workaround and it breaks quickly: keys proliferate, shared services end up with their own key nobody owns, and you still cannot attribute a single agent run that touched three features.
How do you attribute agent and multi-step workloads?
Treat the whole run as the unit, not the individual call. An agent that plans, calls three tools, and retries once produces five billable requests for one user action, and per-call attribution makes each look cheap while the run is expensive. Emit a run ID on every step, roll cost up to the run, and report cost per completed run — that is the number that maps to what the feature actually costs.
Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit →
FAQ
When should OpenAI cost attribution data be captured?
OpenAI cost attribution should be captured before the request is sent. The API response can tell you token usage, but it cannot know which product surface, team, customer, or business workflow caused the call unless your application attaches that context.
What tags should be captured for OpenAI cost attribution?
Tags to capture include: feature or endpoint name, team owner and environment, tenant or customer where allowed, workload class such as realtime, batch, eval, support, or agent step, and prompt version, route policy, and fallback status.
What are common gaps in OpenAI attribution?
Teams often miss retries and fallbacks. A user sees one answer, but the system may have paid for multiple upstream calls. Another common gap is batch work: evals and enrichment jobs should be tagged separately from user-facing traffic so they can move to lower-cost asynchronous lanes.
What makes an OpenAI attribution report actionable?
The best OpenAI attribution reports do not stop at 'which model cost the most.' They show which product decision caused that model to be used, and which owner can change it.