To track OpenAI API spend by product feature, add a stable feature ID to your application’s request and usage records, then reconcile those records against OpenAI’s Usage and Costs reports. OpenAI’s built-in reports can group supported usage by dimensions such as project, API key, and model, but they do not provide a universal product-feature tag. Feature-level attribution is therefore your accounting layer; OpenAI’s Costs data is the better reference for financial reconciliation.
What OpenAI’s reports can—and cannot—attribute
OpenAI’s reporting dimensions offer useful context, but they are not interchangeable with the features in your application. Supported Usage endpoints can group activity by dimensions such as project, user, API key, model, batch, and service tier. The Costs endpoint supports project and line-item groupings. Neither gives you a universal field for labels such as “document summary” or “support search.” See the Usage API reference for the currently supported dimensions.
Use Usage data to diagnose activity and Costs data to reconcile spend. OpenAI notes that the two can differ slightly because usage and spend may be recorded differently, and recommends Costs for financial purposes. For that reason, treat provider cost as the organization or project-level financial record; do not describe an internally distributed feature share as a provider-measured charge.
Build a feature-level ledger
Choose stable feature IDs
Use identifiers that will remain meaningful if a screen or marketing name changes—for example, chat_reply, document_summary, or support_search. Define how your system will classify shared orchestration, background jobs, retries, and requests that support more than one feature. Keep the feature ID in your own telemetry alongside a request or correlation ID.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Record each request and its returned usage
For each API call, store a UTC timestamp, feature ID, endpoint, requested and returned model identifiers, status, project and API-key identity when available, and a provider request or response correlation ID when available. Capture the endpoint’s returned usage object; visible text length is not a reliable substitute for metered usage.
Keep usage categories separate when the endpoint provides them: input, output, cached input, reasoning, and modality-specific usage such as audio or image. Field names vary by API: the Usage Dashboard guidance distinguishes Chat Completions fields such as prompt_tokens and completion_tokens from Responses fields such as input_tokens and output_tokens. Only record detail the selected endpoint actually returns.
Handle streamed Chat Completions carefully
For streamed Chat Completions, set stream_options: {"include_usage": true} to request a final usage chunk containing usage for the full request. OpenAI cautions that an interrupted stream may not deliver that chunk. Mark the usage as missing or pending recovery—not zero. This instruction applies to Chat Completions; consult the current reference for streaming behavior on other endpoints.
Rank #2
Choose project and key boundaries deliberately
Use separate OpenAI projects when they help enforce access boundaries, spend controls, or useful project-level reporting. OpenAI says projects organize access and activity can be broken down by project; projects also support spend limits. See Managing projects in the API platform.
Do not create a project per feature by default. If several features share a project, keep their feature IDs in application telemetry. API-key grouping can add operational context where supported, but a key shared by multiple features does not establish each feature’s exact spend.
Join application events to provider usage
For synchronous requests, join your application record to the most specific provider usage record available, using a request identifier where possible. Keep model, project, API key, endpoint, and time as validation dimensions. If the provider data is aggregate-only, compare your feature events within the same UTC window and provider scope; an aggregate project or key total cannot prove an exact feature cost when multiple features share that scope.
A practical ledger can include the following fields. Leave unavailable fields absent or marked unavailable according to your data model; do not invent values to make records appear complete.
event_time_utc,feature_id,request_id, and endpoint- Model, project ID, API-key ID, batch ID, and service tier when available
- Input, cached-input, output, and reasoning usage when returned, plus non-token usage fields
- Status and allocation or reconciliation state
Keep an “unallocated/shared” category for usage that cannot be confidently assigned, including missing stream usage, uncorrelated retries, shared orchestration, and organization-level charges. If you allocate these internally, document the rule and label the result as an allocation.
Recommended Free Tools
Reconcile feature activity to financial costs
Use the Usage API to investigate activity and the Costs endpoint or the Usage Dashboard’s Costs tab to reconcile spend. The Costs endpoint currently documents daily buckets and grouping by project and line item, while applicable Usage endpoints can offer minute-, hour-, or day-level buckets. Align your joins to UTC: OpenAI’s dashboard reports dates in UTC. See the Usage API reference for current bucket and grouping details.
Start reconciliation at the provider’s available scope—organization, project, UTC day, and line item—before distributing any shared amount among features. Keep provider-measured cost distinct from your feature allocations, and document the allocation method for shared or organization-level spend.
Export monthly costs from the dashboard
For monthly cost detail, OpenAI’s export guide describes downloading Cost data as CSV and grouping by line item. Select all projects or the project you need, use daily intervals, and choose the full reporting month or month-to-date. The guide says this export flow replaces invoice detail for Enterprise customers starting with invoices issued April 1, 2026. See OpenAI’s monthly billing details guide for the current workflow applicable to your organization.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Account for reporting boundaries and exceptions
- Multiple organizations: The Usage Dashboard does not combine separate organizations; sub-organizations are reported separately. Use a custom report through the Usage API if you need a combined view. OpenAI’s usage review guide describes dashboard reporting boundaries.
- Scale Tier bundles: OpenAI attributes Scale Tier bundle costs to the organization rather than individual projects. A project’s usage can therefore appear without corresponding incremental project spend if it is covered by an allocation. Report bundle costs separately or state an explicit internal allocation rule.
- Batch history: The Batch reference says usage fields are populated only for batches created after September 7, 2025. Older batch records may not contain those fields. Batch API reference.
- Playground activity: Playground calls count toward API usage under the same usage rules and pricing as application calls. Include them in the intended scope, or filter them where available dimensions permit.
- Missing usage: An absent usage record is not proof of zero usage, particularly when a streamed response was interrupted before its usage chunk arrived.
Compare feature economics, not just token prices
For a useful comparison, measure reconciled dollars per successful feature outcome alongside usage mix and operating conditions. Compare equivalent tasks, then include model, service tier, batch versus synchronous path, retries and failures, missing-usage rate, and quality or completion rate. A lower price per million tokens does not necessarily mean a lower total task cost: tokenization and generated output or reasoning can vary. OpenAI’s token guidance explains these differences and the usage categories to consider: What are tokens and how to count them.
Keep the denominator meaningful. Cost per successful summary or completed support search is more useful than cost per request if failures or retries differ between implementations. Report shared-cost allocations separately from directly reconciled provider costs so readers can see what was measured and what was distributed internally.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
