LLM Cost Allocation: Track AI Spend by Team, Feature, and Customer

Watch how to allocate LLM costs across teams and features

You have one bill from your LLM provider. Your teams are on one shared API key. Nobody knows who spent what. This is the LLM cost allocation problem, and every team hits it the moment they start paying for AI. A single Anthropic or OpenAI bill reaches your CFO with no answer to the question: did search spend more than recommendations? Did the mobile team or backend team drive this spike? Without attribution at the time of consumption, chargeback becomes guesswork, and cost control becomes impossible. Each LLM provider exposes attribution differently, and most offer only the bare minimum. Anthropic keys, OpenAI projects, Azure deployments, Bedrock IAM identities, Vertex labels, and Mistral workspaces are six different signals with six different levels of effort to wire up. This guide shows how to get per-team cost data out of each LLM provider, unify it in Costory, and build the allocation rules needed for showback, chargeback, and unit economics (cost per token, cost per customer, cost per feature). The end state is a single dashboard that splits your AI spend by team, product, and model across every provider you connect, so every team sees their own cost contribution and the platform owns a complete view of AI economics.

How each provider handles LLM cost allocation

There is no shared standard. Before plumbing anything, it helps to see the mechanism and the easiest practical split per provider.

Provider	Native attribution mechanism	Easiest practical split
Anthropic (Claude)	One API key per app or team, plus the Cost API	API key per team
OpenAI	Projects, plus the Usage and Cost API (`group_by` project_id, model)	One project (and key) per team
Azure OpenAI / Foundry	Resource, deployment, and user-defined tags; `project` tag (preview)	One deployment or tag per use case
AWS Bedrock	Caller identity (IAM role or user) in the Cost and Usage Report	One IAM role per team
GCP Vertex AI	Per-call metadata labels, or project-level labels	One GCP project per team
Mistral	Per-workspace billing, API keys scoped to a workspace	One workspace per team

Two patterns repeat across the table. Per-call labels (Vertex, partly Azure) give the finest granularity but are the most work to wire into every call site. Isolating usage into a separate account, project, key, or workspace per team is coarser but far easier to set up and maintain, and it is what most teams actually ship.

What each provider exposes, and what Costory uses

Attribution starts at the provider. Each one exposes a different signal that ties spend to a team, key, project, or use case, with different granularity and effort. Below is the signal available from each provider and the field Costory ingests to build your per-team split. A developer could wire any of this up internally; what Costory adds is knowing the right field for each provider and keeping the mapping current as keys, projects, and deployments change.

Anthropic (Claude)

Available: Anthropic ties usage to the API key and actor (user email or key name), exposed through the Cost and Usage API. Using one API key per app, team, or environment puts the split in the billing data with no code. In Costory: the Anthropic connector ingests the key or actor as Sub account id and Resource name, and the model as Service name, so you group spend by team and by model directly. If you call Claude through Amazon Bedrock instead of the Anthropic API, that spend lands via the AWS connector (billed as Claude ... (Amazon Bedrock Edition)).

OpenAI

Available: OpenAI ties usage to projects, readable through the Usage and Cost API with group_by on project_id, line_item, and model. One project (and project key) per team gives isolation and per-project budget caps. For finer per-feature attribution, OpenAI’s guidance is to log application metadata (feature, route, customer) alongside response.usage at call time, since the export carries no per-call labels. In Costory: GPT models are most often consumed through Azure OpenAI, where the spend already lands via the Azure connector as Azure OpenAI (Cognitive Services) charges, split by deployment and region. OpenAI’s direct platform is not a native connector today, so for direct API usage, attribute it with projects and the Usage and Cost API.

Azure OpenAI / Foundry

Available: Azure has the richest native model. Costs carry resource, deployment, and user-defined tags, you can group cost by model deployment, and Microsoft added project-level chargeback (preview) that auto-tags every Foundry project. Naming a deployment per use case (one for support, one for document processing) makes deployment-level cost equal to cost per feature. In Costory: the Azure connector ingests Azure Cost Management data, including Azure OpenAI (billed under Cognitive Services). Costory detects the deployment and user-defined tags as dimensions for the team or use-case split.

AWS Bedrock

Available: Bedrock has no per-call labels. Instead, AWS records the caller identity (IAM role or user) on every Bedrock line in the Cost and Usage Report. Per the AWS guide, you tag your IAM principals, activate those cost allocation tags, and enable caller-identity allocation in a CUR 2.0 export, which adds a line_item_iam_principal column. It breaks when calls route through a shared gateway role, and AWS sub-accounts per team are a heavier alternative than a GCP project. In Costory: the AWS connector ingests the CUR including line_item_iam_principal and your cost allocation tags, so once the export option is on, the per-team split flows in automatically.

GCP Vertex AI

Available: Vertex recently added custom metadata labels on each API call, the most granular option, though wiring a label into every call through the Python SDK is work to roll out and keep consistent. The simpler path, used by a Costory customer, is one GCP project per team. In Costory: the GCP connector ingests the project and all resource labels from the billing export, so either approach maps onto a team dimension.

Mistral

Available: Mistral bills per workspace and scopes API keys to a workspace, with per-workspace usage and spending caps in the admin panel. The natural unit is one workspace per team or environment. In Costory: Mistral is most often run through AWS Bedrock or Azure, and that spend reaches Costory via the AWS and Azure connectors (publisher Mistral AI). Mistral’s direct platform is not a native connector today.

Implementation examples per provider

Anthropic: API key per team

Create separate API keys in the Anthropic console, one per team. Name them for clarity (the name shows in billing):

# In Anthropic console, create keys named by team
- search-team-key
- recommendations-team-key
- backend-team-key

# Then use the right key in your application
export ANTHROPIC_API_KEY=search-team-key

Each key’s usage appears separately in the Cost and Usage API, and Costory ingests the key name as Resource name.

Azure OpenAI: Deployment names and resource tags

Create separate deployments per team or feature. The deployment name itself is part of the URL and automatically appears in billing. Follow Azure’s cost management guidance to tag and allocate: Create deployments in Azure:

# Azure Portal → Azure OpenAI → Deployments
# Name them by team or feature
- search-gpt4
- recommendations-gpt35
- backend-gpt4

Tag the resource in Azure:

az cognitiveservices account update \
  --resource-group my-rg \
  --name my-openai \
  --tags team=search environment=production feature=ai-search

API call (the deployment name routes the cost):

curl https://my-openai.openai.azure.com/openai/deployments/search-gpt4/chat/completions \
  -H "api-key: $AZURE_OPENAI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [{"role": "user", "content": "What is AI?"}],
    "model": "gpt-4-turbo"
  }'

The deployment name (search-gpt4) automatically tags the cost in Azure billing. Resource-level tags (team, environment) appear in Cost Management. Costory ingests the deployment name and tags as dimensions for team-level allocation.

AWS Bedrock: Separate IAM roles per team

Create one IAM role per team. Each application assumes its team’s role to call Bedrock. AWS records which role made the call: Create separate roles:

# Each role allows bedrock:InvokeModel
# Role 1: SearchTeamBedrockRole (for search application)
# Role 2: RecommendationsTeamBedrockRole (for recommendations)

Tag each role to identify the owner:

aws iam tag-role \
  --role-name SearchTeamBedrockRole \
  --tags Key=team,Value=search Key=environment,Value=production

aws iam tag-role \
  --role-name RecommendationsTeamBedrockRole \
  --tags Key=team,Value=recommendations Key=environment,Value=production

In your application, assume the right role and call Bedrock:

import boto3

# Search service assumes SearchTeamBedrockRole
sts = boto3.client('sts')
credentials = sts.assume_role(
    RoleArn='arn:aws:iam::ACCOUNT:role/SearchTeamBedrockRole',
    RoleSessionName='search-session'
)

# Use temporary credentials to call Bedrock
bedrock = boto3.client(
    'bedrock-runtime',
    aws_access_key_id=credentials['Credentials']['AccessKeyId'],
    aws_secret_access_key=credentials['Credentials']['SecretAccessKey'],
    aws_session_token=credentials['Credentials']['SessionToken']
)

response = bedrock.invoke_model(
    modelId='anthropic.claude-opus-v1',
    body=json.dumps({"prompt": "..."})
)

Enable caller-identity allocation in your CUR 2.0 export. AWS then records the IAM role ARN (line_item_iam_principal) for every Bedrock call. Costory ingests the ARN and its tags to allocate costs by team.

GCP Vertex AI: Per-call metadata labels

Pass labels on every API call. This is the most granular approach:

import vertexai
from vertexai.generative_models import GenerativeModel

vertexai.init(project="my-project", location="us-central1")
model = GenerativeModel("gemini-2.0-flash")

response = model.generate_content(
    "What is AI?",
    # Labels passed per-call
    labels={
        "team": "search",
        "feature": "ai-search",
        "customer": "acme",
        "environment": "production"
    }
)

Or use the REST API:

curl https://us-central1-aiplatform.googleapis.com/v1/projects/my-project/locations/us-central1/endpoints/gemini:streamGenerateContent \
  -H "Authorization: Bearer $GCLOUD_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": {...},
    "labels": {
      "team": "search",
      "feature": "ai-search",
      "customer": "acme"
    }
  }'

These labels appear in Vertex billing exports and Costory ingests them as dimensions. Alternatively, use one GCP project per team (simpler but coarser).

Mistral: Workspace per team

Create a workspace in Mistral for each team. Each workspace has its own billing and API keys:

# Organization → Workspaces → Create workspace
# Name: "search-team", "recommendations-team"
# Each workspace gets unique API keys scoped to it

export MISTRAL_API_KEY=search_team_key  # Only works in search-team workspace

Workspace-level billing appears in the Mistral admin console. Costory ingests the workspace ID to split costs.

Track and allocate LLM costs across providers in Costory

Each provider hands you a different key: an API key, a project, a deployment, an IAM principal, a label, or a workspace. On their own they live in separate billing consoles. You can stitch them together yourself by exporting each provider’s cost data, normalizing it, and maintaining the mapping in your own warehouse, but that is a pipeline to build and own. It is easier and more reliable to do it in Costory. Costory has native billing connectors for Anthropic, AWS, Azure, and GCP and normalizes them into one schema. From there, you build a single virtual dimension (call it team, product, or customer) with one rule per source that maps its native key to the right owner. This unified view becomes your source of truth for chargeback and cost per token attribution.

Source (Costory connector)	Native key Costory ingests	Allocate by
Anthropic	Sub account id (API key / actor)	rule per key
Azure OpenAI (Azure connector)	deployment or user-defined tag	rule per deployment or tag
AWS Bedrock (AWS connector)	IAM principal or cost allocation tag	rule per role
GCP Vertex (GCP connector)	project or label	rule per project

The result is one team axis spanning every connected source. Spend re-allocates automatically as new keys, projects, or deployments appear, with no manual updates, and the same dimension feeds chargeback, budgets, and reports.

In practice, most teams consume these models through the clouds: GPT through Azure OpenAI, Claude and Mistral through Bedrock or Azure. That spend already flows into Costory through the AWS, Azure, and GCP connectors, with the cloud’s own attribution (deployment, IAM principal, project, label). The direct OpenAI and Mistral platforms are not native connectors yet; track those with the provider methods above, or contact us about your setup.

Build the cross-provider dashboard with the MCP

Once the data is unified, you do not have to assemble the dashboard by hand. Connect the Costory MCP to Claude, Cursor, or any MCP client and ask for it in plain language:

“Build a dashboard of our LLM cost across all connected AI sources (Anthropic, Azure OpenAI, Bedrock, Vertex). Total cost over time by provider, a breakdown by model, and a split by team using our team dimension.”

The assistant works out the scope across providers, builds the widgets, and saves the dashboard for you to review and adjust. You can keep asking for the cuts you need (“split the Bedrock cost by IAM principal”, “compare this month to last by team”) and it runs them without you rebuilding queries.

What LLM cost management looks like once spend is allocated

With one cross-provider, team-level view in place, the AI bill becomes something you can manage and report on:

Measure adoption

Track which teams and products use AI most, and how fast usage is growing. Rising spend is usually adoption, and now you can show it per team.

Budget per team

Set an AI budget on the team dimension and track burn against it.

Alert on spend

Fire a Slack or email alert when a team’s daily AI cost crosses a threshold, before month-end.

FAQ

How do you allocate OpenAI or Anthropic costs across teams?

Each LLM provider offers a native mechanism: OpenAI uses projects and the Usage and Cost API. Anthropic uses API keys and the Cost and Usage API. The simplest approach is one API key (Anthropic) or project (OpenAI) per team. This isolation puts the split directly in the billing data. For finer attribution (cost per feature or per customer), use Costory’s virtual dimensions to map provider keys and projects to logical owners, then apply cost-allocation rules.

What is LLM cost allocation and why does it matter?

LLM cost allocation is the process of assigning shared AI spend to the teams, products, or customers that generated it. Your LLM provider sends one bill, but multiple teams consume from one API key or account. Without allocation, each team sees only the total company spend, not their contribution. Allocation enables chargeback (billing teams for their usage), budget enforcement (per-team cost caps), and accurate unit economics (cost per token, cost per customer). Costory automates this by ingesting each provider’s billing data and applying your allocation rules across all sources at once.

How do you track LLM costs by team?

Track LLM costs by team by isolating each team’s usage into its own provider signal, then reading it back from billing: one Anthropic API key, one OpenAI project, one Azure deployment, one Bedrock IAM role, or one Vertex label per team. Each provider stamps the team onto its own billing lines, so the split lands in the data with no per-call code. Costory ingests all of these into a single team dimension, so you track spend by team across every connected provider in one view instead of stitching consoles together.

What is the difference between showback and chargeback?

Showback is visibility: teams see their own costs in a dashboard or report, but no bill is exchanged. Chargeback is billing: each team receives an internal invoice for their share of the AI bill based on allocation rules. Showback is a prerequisite for chargeback and helps teams make cost-conscious decisions even without internal billing. Both require cost allocation; chargeback is a stronger accountability mechanism.

How do you calculate cost per token for each team?

Cost per token combines billing data (total cost per provider and model) with usage data (token counts). Most LLM providers expose token counts in their billing API or usage dashboard. Divide your team’s total cost by their total tokens consumed to get cost per token. This metric shows which teams are getting the most efficiency from their AI spending and helps identify runaway prompts or inefficient model usage. Track this in Costory by building a formula that divides your cost query by a usage metric from your provider’s telemetry.

What happens with shared API key allocation when one team spikes?

If all teams share one API key, you cannot see which team drove a spike at the provider level. You must rely on per-call instrumentation: logging which team made each request in your application, then correlating that log with usage. Costory’s support this by ingesting both provider billing (the total cost) and your application logs (which team made the call), then allocating the cost forward. The alternative is to isolate each team into a separate API key or project at the provider level, which eliminates ambiguity but requires more infrastructure.

Can you split per-customer AI cost?

Yes. Per-customer attribution follows the same pattern as per-team. If you have one API key shared across customers, instrument your API calls to log customer ID, then ingest those logs into Costory as a usage metric or custom dimension. Map that customer data to your billing costs. Costory then allocates the AI bill by customer, enabling per-customer unit economics (cost per customer request, cost per customer feature). This is especially important for platforms or SaaS products where AI is part of the offering you charge for.

Next steps

Connect each provider from Billing Data.
Build your cross-provider allocation virtual dimension.
Use the Costory MCP to build and investigate your AI cost in natural language.

Explore

Annotate

Analyze

Share

LLM Cost Allocation: Track AI Spend by Team, Feature, and Customer

How each provider handles LLM cost allocation

What each provider exposes, and what Costory uses

Anthropic (Claude)

OpenAI

Azure OpenAI / Foundry

AWS Bedrock

GCP Vertex AI

Mistral

Implementation examples per provider

Anthropic: API key per team

Azure OpenAI: Deployment names and resource tags

AWS Bedrock: Separate IAM roles per team

GCP Vertex AI: Per-call metadata labels

Mistral: Workspace per team

Track and allocate LLM costs across providers in Costory

Build the cross-provider dashboard with the MCP

What LLM cost management looks like once spend is allocated

Measure adoption

Budget per team

Alert on spend

FAQ

Next steps

​How each provider handles LLM cost allocation

​What each provider exposes, and what Costory uses

​Anthropic (Claude)

​OpenAI

​Azure OpenAI / Foundry

​AWS Bedrock

​GCP Vertex AI

​Mistral

​Implementation examples per provider

​Anthropic: API key per team

​Azure OpenAI: Deployment names and resource tags

​AWS Bedrock: Separate IAM roles per team

​GCP Vertex AI: Per-call metadata labels

​Mistral: Workspace per team

​Track and allocate LLM costs across providers in Costory

​Build the cross-provider dashboard with the MCP

​What LLM cost management looks like once spend is allocated

Measure adoption

Budget per team

Alert on spend

​FAQ

​Next steps

How each provider handles LLM cost allocation

What each provider exposes, and what Costory uses

Anthropic (Claude)

OpenAI

Azure OpenAI / Foundry

AWS Bedrock

GCP Vertex AI

Mistral

Implementation examples per provider

Anthropic: API key per team

Azure OpenAI: Deployment names and resource tags

AWS Bedrock: Separate IAM roles per team

GCP Vertex AI: Per-call metadata labels

Mistral: Workspace per team

Track and allocate LLM costs across providers in Costory

Build the cross-provider dashboard with the MCP

What LLM cost management looks like once spend is allocated

FAQ

Next steps