AI cost allocation assigns the cost of model usage to the feature, environment, team or customer that caused it: through the dimensions the provider records (project, workspace, API key, deployment, inference profile, IAM principal, label) and, below those, through the application's own record of each request. The general method of direct cost, split shared cost and a visible remainder is covered in cost per customer, feature and environment. What is specific to AI is that the finest dimension available depends on where the model is bought, and on a choice made before the first request: which key, project or profile it runs under.
How it works
Which exports the providers deliver, and at what granularity, is covered in usage and cost exports of the AI providers; this section covers the dimensions an allocation can hang on.
OpenAI
An organisation is divided into projects, and the costs endpoint groups daily cost by project, user, line item, API key and API source. OpenAI suggests separate projects for staging and production, each with its own rate and spend limits. A request can carry up to 16 key-value pairs as metadata, retrievable on the stored object; the costs endpoint does not group by them. The safety_identifier field serves abuse detection, not cost reporting.
Anthropic
An organisation is divided into workspaces, up to 100 by default. An API key can be scoped to one workspace, and usage and cost reports carry the workspace ID. The default workspace and keys spanning all workspaces appear there without one. For Claude Code, Anthropic creates a workspace of its own with one key per person. metadata.user_id takes an opaque identifier for abuse detection.
AWS
Amazon Bedrock offers two routes. An application inference profile with tags makes on-demand calls through that profile reportable as cost allocation tags. The second route is allocation by IAM principal: with the caller identity option in a CUR 2.0 standard export, line_item_iam_principal holds the calling user or role for each Bedrock call, and tags on those principals appear with the prefix iamPrincipal/. Either way the tag key has to be activated in the Billing console: up to 24 hours before it shows up there, and up to 24 more to activate. A principal's tags appear only after it has made at least one call, and the export grows by a row per calling identity and model.
Azure
In Microsoft Foundry, Azure OpenAI and Microsoft's own models appear as meters under their Foundry resource, partner models under the resource group. Cost analysis can be filtered by deployment tags and user-defined tags. In preview, Foundry tags each project's usage with a project tag automatically, so a shared resource can be split by project; this covers models sold by Azure, not yet models through Azure Marketplace.
Google Cloud
On the Gemini API, keys belong to Google Cloud projects, and cost appears per project in Cloud Billing. Gemini Enterprise Agent Platform also accepts labels on each call and forwards them to Cloud Billing: up to 64 per call for Google models, 32 for supported partner models. Each label key may have at most 1,000 distinct values over the life of the billing account, beyond which it can be dropped without notice. For partner models (currently Anthropic and Mistral AI), Google forwards labels to Cloud Billing only on pay-as-you-go calls; on Provisioned Throughput they are dropped without an error.
| Bought | Finest unit the provider records | Reaches cost data through | Limit |
|---|---|---|---|
| OpenAI, direct | project, API key, user | costs endpoint, daily | no grouping by metadata |
| Anthropic, direct | workspace, API key | cost report by workspace, daily | default workspace without ID |
| Amazon Bedrock | inference profile, IAM principal | CUR 2.0 with activated tags | only calls through the profile or with the option on |
| Microsoft Foundry | resource, deployment tag, project | Azure cost data | project tag not for Marketplace models |
| Agent Platform | project, label per call | Cloud Billing | 1,000 values per key; partner models not on Provisioned Throughput |
Per customer
None of these providers knows the application's customers. Every response does return its tokens by type (at OpenAI input, cached and cache-written input, output and the reasoning within it; at Anthropic input, cache writes, cache reads and output) and a request ID. If the application logs customer, feature, model, tokens by type and request ID for each request, cost per customer follows from tokens times the price list rate for each type. The sum across customers is reconciled against the daily cost of the project, workspace or profile, and whatever is missing stays visible as unallocated cost.
Shared AI cost
A gateway, a cache, a vector store, an evaluation pipeline or reserved capacity serve several features. They are split by an allocation rule, such as tokens or requests per feature from the same period; shared cost and how to split it covers the keys.
What it means for your cost
The allocation unit that needs no code is a project, workspace, inference profile or deployment of its own per feature and environment. A request is booked where it ran; whoever makes that choice while building the feature has allocation from day one. Why cost allocation comes before any optimisation is covered in why cost allocation comes before optimisation.
Cost per customer from application logs is a reconstruction, not an invoice. It matches the bill only if the logs apply the rates the provider applied: batch, cache and a data residency uplift change the rate per token, and at Anthropic they multiply. Reconciling against daily cost shows the size of the gap, and a gap that grows month by month points to a rate the logs do not know about.
Allocation is what makes the next steps possible. A feature's cost per outcome needs that feature's cost as its numerator, and a limit per feature needs the feature to have a scope of its own that a limit can attach to. The articles on cloud cost per customer for SaaS and multi-tenant SaaS cost allocation show the method for a SaaS product as a whole.
Where it goes wrong
- One key for everything. Every feature sits in one row. The cause: the provider records project and key, not the feature; details in AI provider billing.
- Tags set but not activated. The inference profile or role carries a tag that the cost report does not show. The cause: the tag key was not activated as a cost allocation tag in the Billing console, or the principal has not yet made a call.
- Calls that bypass the profile. Part of the Bedrock cost has no tag. The cause: a service calls the model directly instead of through the application inference profile.
- Customer IDs without tokens. The log counts requests per customer, but the cost does not add up. The cause: requests cost very different amounts depending on context and output; without tokens by type the price list cannot be applied.
- Retries and failures left out. Customers add up to less than the invoice. The cause: only the final, successful response is logged. Microsoft notes that the HTTP status alone does not decide whether a request is billed.
- A label per customer. Beyond a certain number of customers the label is missing from cost data. The cause: Google may drop a label key with more than 1,000 values; labels suit features and environments, not customers.
Sources
Read on 2026-10-16. OpenAI production best practices, costs endpoint and Responses API: create a response; Anthropic Workspaces, pricing, Messages API and errors and request IDs; AWS inference profiles, IAM principal cost allocation and activating cost allocation tags; Microsoft plan and manage costs for Microsoft Foundry; Google Gemini API billing and custom metadata labels in Gemini Enterprise Agent Platform.