AI Cost Allocation: Turning OpenAI Projects and Anthropic Workspaces Into Team Budgets

Say the OpenAI invoice is $38,000 and the Anthropic invoice is $21,000. Finance can read both, and neither answers the question finance is actually asking: which team owns this spend? Support says their agent is cheap. Marketing says they barely use the API. Platform says the evaluation jobs run on a shared key. Everyone is probably right about their own corner, and nobody can say whose budget the $59,000 belongs to.

AI cost allocation is the work of answering that question every month without a spreadsheet. It is the same discipline FinOps teams already apply to cloud bills — every dollar gets an owner — applied to a bill that grows faster, changes shape with every model release, and arrives organized by technical boundaries rather than business ones. The argument of this post is simple: allocation creates ownership, and ownership is what makes an AI budget mean anything. A budget on the whole OpenAI organization tells you the company overspent. A budget on the support team's share tells someone what to do about it.

Why AI cost allocation is becoming a FinOps problem

For a while, LLM API spend was small enough to sit on one engineering card and be explained in a sentence. That stops being true once several teams ship features on top of the same providers: a support agent, a marketing content pipeline, an internal coding assistant, a batch classification job. Each has its own usage curve, its own model mix and its own owner, but they all draw on one OpenAI organization and one Anthropic organization, and they all land on one invoice per provider.

Token-based spend also behaves differently from most cloud spend. A deploy that doubles prompt length doubles input cost overnight. A switch to a reasoning model changes the output bill more than the traffic graph would suggest. A cache configuration change can move a workload's effective price in either direction. When that spend is unallocated, the variance is real but has no address — and spend without an address is the hardest kind to budget, forecast or cut.

Why an OpenAI or Anthropic bill doesn't tell you who owns the spend

Provider billing is organized around what the provider can measure: which project or workspace made the call, which model served it, and what kind of token was billed. Those are useful dimensions, but they are technical ones. "Output tokens on one model, in project proj_8Hq…" is a fact about the API, not about the business. Nothing on the invoice says that project belongs to Marketing, rolls up to the Go-to-Market group, and has a $4,000 monthly budget.

Cloud bills have the same gap, and cloud FinOps closes it with tags, accounts and allocation rules that map technical identifiers onto a cost-center tree. AI bills need the same mapping. The difference is which identifiers you get to map from — and with OpenAI and Anthropic, the list is short.

What OpenAI and Anthropic actually give you

Both providers expose cost and usage through admin APIs, and both expose the same four kinds of dimension — but not in the same place. The cost reports, which carry dollars, are grouped by project or workspace and billing line item; the usage reports carry token and request counts. Knowing which report a dimension comes from decides what your allocation can and cannot do.

OpenAI projects and Anthropic workspaces are the only dimensions the cost reports group spend by that you can also shape to match your organization. You create them, you name them, you decide which keys and which applications live in each. Models and token types are useful for explaining spend, but they describe what was consumed, not who consumed it.

API keys are the dimension people reach for first, and they are the one that cannot carry the answer. Both providers report tokens per API key, but cost — in dollars — is reported per project or workspace and per line item, not per key. You can see that one key used 40% of a workspace's output tokens; you cannot read a dollar figure for that key from the provider's cost report. Token types can have very different prices, especially cached versus uncached usage, so converting token counts into dollars yourself is still an estimate, not an allocation.

One more detail that matters later: usage in the Default project on OpenAI or the Default workspace on Anthropic arrives without a project or workspace ID. That spend is real and counted, but there is no identifier to tie it to a team.

Use projects and workspaces as ownership boundaries

Since the project or workspace is the only cost-report grouping you control, the most important AI cost allocation decision happens in the provider console, not in a FinOps tool: draw that boundary around ownership. If you want spend by team, create one OpenAI project and one Anthropic workspace per team, and give each team keys only from its own.

• ◦One project or workspace per owning team. marketing-ai belongs to Marketing; support-agent belongs to Customer Support. A boundary shared by two teams can only be allocated to one of them.
• ◦Split production from non-production where the budgets differ. support-agent-prod and support-agent-staging can map to the same team and still be watched separately.
• ◦Keep production out of the Default project and Default workspace. Spend there has no ID, so it cannot be routed to a specific team later.
• ◦If you need spend per customer or per product, make that the boundary deliberately: a project per customer, or a workspace per product line. It works cleanly only when the provider boundary and the business unit are the same thing.
• ◦Name boundaries for the answer you will be asked for, not for the repository that happens to call the API.

The provider-side mechanics — project limits, workspace spend caps, key management — are covered in our posts on tracking OpenAI API costs and Anthropic API cost tracking, linked at the end. The point here is the design rule: the boundary you draw in the provider console is the finest ownership grain your allocation will ever have.

Map AI spend into cost centers

With boundaries drawn around teams, allocation becomes a lookup. In CloudQuell, OpenAI spend arrives with its project_id and Anthropic spend with its workspace_id, and an allocation rule matches that ID and routes the spend to a cost center:

Tag rule   project_id   = proj_…   (OpenAI project marketing-ai)      →  Marketing
Tag rule   workspace_id = wrkspc_… (Anthropic workspace support-agent) →  Customer Support

Rules match the ID exactly, not the display name, so renaming a project does not break its allocation. Rules are evaluated in priority order and the first match wins, which keeps the result unambiguous: each dollar lands in exactly one cost center. The full setup, including where to find each ID and the rule types available, is in the step-by-step guide on our docs site, linked below.

Cost centers in CloudQuell form a hierarchy up to five levels deep. Customer Support and Success can sit under Customer Operations, Marketing and Sales under Go-to-Market, and each parent rolls up its children. A VP can see AI spend for their whole group and drill into the team that moved it, from the same rules.

This is where it is worth being precise about the approach, because the AI FinOps market allocates in several different ways: request-level instrumentation that enriches each LLM call with metadata, tagging and log enrichment, virtual dimensions built over billing data, and allocation from the provider's own billing dimensions. Request-level instrumentation can attribute cost to a feature, an end user or a customer inside a shared project, at the price of changing application code. Provider-billing allocation needs no application changes, but it stops at the provider's billing dimensions. CloudQuell allocates from provider billing data rather than instrumenting individual LLM requests, so the ownership boundary is an OpenAI project or Anthropic workspace.

What to do with unallocated AI spend

Spend that no rule matches does not disappear. It stays visible as Unallocated, next to the cost centers, so the allocated total always reconciles to the bill. That number is the health metric for your AI cost allocation, and it is worth reviewing on the same cadence as the budgets.

Unallocated AI spend usually comes from three places. A new project or workspace was created and nobody added a rule for it — fix it with a rule. Traffic still runs through the Default project or workspace — move it, because without an ID no team-specific rule can claim it; until then a broader rule, such as one that routes a whole provider integration or a specific model to a cost center, can give it a holding owner. Or a boundary is genuinely shared — a platform team's evaluation workspace used by three product teams. A rule sends a boundary's spend to one cost center; CloudQuell does not split one project or workspace across several. Shared boundaries either get a single accountable owner or get split at the provider into one per team.

The goal is not zero Unallocated on day one. It is a small, shrinking number that someone owns, rather than a large, silent one that turns every month-end review into an argument about whose spend it is.

Put a budget on each team's AI spend

Allocation is the prerequisite; budgeting is the payoff. Once Marketing's AI spend is a number, Marketing can have an AI budget, and the conversation changes from "the OpenAI bill went up" to "Marketing is at 92% of its AI budget with nine days left." That sentence names an owner, a limit and a deadline, which is everything an organization-wide spend cap cannot.

In CloudQuell, a budget can be scoped to a cost center — in which case it covers that cost center and everything beneath it — or directly to an OpenAI project or Anthropic workspace, a whole provider, a service or model, or a tag. Periods are monthly, quarterly or annual. A few patterns hold up well for AI spend:

• ◦Budget each team's cost center, not each provider. The team owns its AI spend whether it runs on OpenAI, Anthropic or both, and the budget should follow the owner.
• ◦Add a project- or workspace-level budget for the single workload most likely to run hot, such as a production agent, so it is watched on its own.
• ◦Use quarterly or annual budgets where AI spend is planned as an investment and the monthly line is expected to be uneven.
• ◦Keep provider-native spend or usage limits on as a backstop, where available. A team budget tells the owner early; a provider limit is the last line of defense.

Budgets are only as good as the allocation underneath them. A team budget that excludes half the team's spend because it sits in the Default workspace will report "on track" until the invoice says otherwise — which is why the unallocated number and the budgets belong in the same review.

Track actual vs forecast and catch unexpected increases

A budget that only compares month-to-date spend with the limit tells you about a problem after it has mostly happened. Each CloudQuell budget shows actual spend, a run-rate forecast for the period, and the percentage of budget used, with a status of On track, At risk or Over budget. Early in a period the forecast shows Warming up until there is enough data to project from — at least seven days and a tenth of the period — rather than extrapolating from one expensive Monday.

Threshold notifications go to Slack, Microsoft Teams or email, at the percentages you set — 80% and 100% by default. Once the forecast is reliable, a budget also warns when it is forecast to cross its highest threshold, which is the alert that gives a team time to act inside the period.

Budgets catch drift against a plan; anomaly detection catches change against history. CloudQuell watches OpenAI and Anthropic spend per model against a rolling baseline, and flags spend on a model with no history at all — the afternoon someone switches a workload to a pricier model. Our post on AI spend budget alerts covers why per-model baselines matter on a bill that can spike in hours.

One limit to plan around: none of this is real time. AI billing data syncs daily from the providers' cost and usage reports, and budget alerts are evaluated daily. That is fast enough to stop a bad week from becoming a bad quarter, but not fast enough to stop a runaway loop this afternoon. For that, the provider's own spend limits remain the right control.

Combine AI and cloud spend under the same cost center

A team's AI feature rarely runs on API calls alone. The support agent calls Claude, but it also runs on containers, a vector database, a queue and the logs behind them. If AI cost allocation lives in a separate tool from cloud allocation, the team gets two numbers and finance gets a reconciliation exercise.

In CloudQuell, the same cost-center hierarchy holds both. The Customer Support cost center can carry the support-agent workspace from Anthropic, a support-assistant project from OpenAI and the AWS, Azure or Google Cloud spend matched by tag or service rules, under one budget. That gives finance a much more complete answer to "what does the support agent cost to run?" — with shared infrastructure and anything still unallocated as the gaps to close.

Ask allocation and budget questions through MCP

The same data is available to AI assistants through CloudQuell's MCP server, which is useful precisely because allocation questions tend to come as follow-ups. In Claude, Cursor or another MCP client, an assistant can call get_allocation_breakdown for spend by cost center including Unallocated, get_budget_status for each budget's actual, forecast and status, and get_ai_spend for OpenAI and Anthropic spend grouped by project or workspace, model or token type. A question like "which team's AI budget is at risk this month, and which model is driving it?" becomes two or three tool calls instead of three dashboards. MCP access is on paid plans.

Where this approach stops: when you need request-level attribution

Allocation from provider billing is deliberately coarse. It answers "which team" well, as long as teams have their own projects and workspaces. It does not answer questions below that boundary:

• ◦Cost per feature when several features share one project or workspace.
• ◦Cost per end user, per prompt or per request.
• ◦Cost per customer, unless each customer has its own project or workspace.
• ◦Dollar cost per API key — the providers report tokens per key, not dollars.
• ◦Splitting one shared project or workspace proportionally across several teams.

If those questions drive real decisions — unit economics per customer, pricing a feature — you need request-level data: metadata attached to each call through a gateway, SDK or observability tool, and the cost computed from it. Our comparison of LLM cost management tools covers that category. The two approaches are complementary: request-level tooling explains cost inside a workload, and provider-billing allocation makes sure every dollar on the invoice has a team, a budget and a place in the same ledger as the cloud bill.

A practical checklist for AI cost allocation

• ◦Decide the ownership unit you will report on: team for most organizations; product or customer only if you will maintain a boundary per product or customer.
• ◦Create one OpenAI project and one Anthropic workspace per owner, split production from non-production where budgets differ, and move production traffic out of the Default project and workspace.
• ◦Build the cost-center tree once — teams under groups under departments — and use it for cloud and AI spend alike.
• ◦Add one rule per project or workspace, matching project_id or workspace_id, routed to the owning team.
• ◦Review Unallocated monthly; every new project or workspace needs a rule before it carries real spend.
• ◦Budget each team's cost center, with thresholds and a forecast alert sent to the team's own Slack or Teams channel.
• ◦Keep provider-native spend or usage limits on as a backstop where available, and per-model anomaly alerts in front of them.
• ◦Decide explicitly which questions need request-level data, and do not expect billing allocation to answer them.

What is AI cost allocation?

AI cost allocation is assigning LLM API spend — from OpenAI, Anthropic and other providers — to the teams, products or cost centers that own it, so it can be reported, budgeted and charged back like any other cost. In practice it means mapping the provider's billing boundaries, such as OpenAI projects and Anthropic workspaces, onto your organization's cost-center structure.

How do I track OpenAI spend by team?

Give each team its own OpenAI project and its own API keys from that project. OpenAI's cost reporting breaks spend out by project, so each project's spend becomes that team's spend. A FinOps tool can then map each project_id to a team cost center and put a budget on it.

How do I track Anthropic spend by team?

Use one Anthropic workspace per team. Anthropic's cost report breaks spend out by workspace, so each workspace_id can be mapped to the team that owns it. Avoid running team workloads in the Default workspace, which has no workspace ID to allocate from.

Can I see OpenAI or Anthropic cost per API key?

Not in dollars. Both providers report token usage per API key, but cost is reported by project or workspace and line item, not by key. You can see which key used the most tokens; for dollar attribution, use projects or workspaces as the boundary.

Can AI spend and cloud spend share a budget?

Yes, if both are allocated to the same cost center. In CloudQuell, one cost center can hold OpenAI projects, Anthropic workspaces and AWS, Azure or Google Cloud spend, and a budget on that cost center covers all of it — including its child cost centers.

Is AI spend allocation in CloudQuell real time?

No. OpenAI and Anthropic billing data syncs daily, and budget alerts are evaluated daily. Use provider-native spend or usage limits, where available, as the backstop against runaway usage, and team budgets and anomaly alerts for ownership and early warning.