> ## Documentation Index
> Fetch the complete documentation index at: https://docs.costory.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Track and Allocate LLM Costs Per Team Across Providers

> How to get team-labeled LLM cost data from Anthropic, OpenAI, Azure OpenAI, AWS Bedrock, GCP Vertex, and Mistral, then unify it in Costory into one cross-provider AI cost dashboard for chargeback and adoption tracking.

Seeing your total AI bill is the easy part. The hard part is answering "which team, product, or feature drove this spend?" across providers that each expose cost attribution differently, and most of them expose it poorly. Anthropic keys, OpenAI projects, Azure deployments, Bedrock IAM identities, Vertex labels, and Mistral workspaces are six different mechanisms with six different levels of effort.

This guide covers the part that actually matters: how to get **team-labeled cost data out of each LLM provider**, and how to unify it in Costory into one cross-provider view you can use for chargeback, budgets, and adoption tracking. The end state is a single dashboard that splits your AI spend by team and by model across every provider you connect.

## How each provider lets you attribute LLM cost

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](https://docs.anthropic.com/en/api/admin-api/usage-cost/get-cost-report). Using one API key per app, team, or environment puts the split in the billing data with no code.

**In Costory:** the [Anthropic connector](/setup/billing/anthropic) 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](/setup/billing/aws) (billed as `Claude ... (Amazon Bedrock Edition)`).

### OpenAI

**Available:** OpenAI ties usage to **projects**, readable through the [Usage and Cost API](https://developers.openai.com/cookbook/examples/completions_usage_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](/setup/billing/azure) 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)](https://learn.microsoft.com/en-us/azure/foundry/concepts/manage-costs) 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](/setup/billing/azure) ingests Azure Cost Management data, including Azure OpenAI (billed under Cognitive Services). Costory detects the deployment and user-defined tags as [dimensions](/features/tagging/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](https://aws.amazon.com/blogs/aws-cloud-financial-management/track-amazon-bedrock-costs-by-caller-identity-with-iam-based-cost-allocation/), 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](/setup/billing/aws) 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](https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/capabilities/add-labels-to-api-calls#google-models), 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](/setup/billing/gcp) 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](https://docs.mistral.ai/admin/user-management-finops/billing) 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](/setup/billing/aws) and [Azure](/setup/billing/azure) connectors (publisher Mistral AI). Mistral's direct platform is not a native connector today.

## Unify and allocate 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](/setup/billing) for **Anthropic, AWS, Azure, and GCP** and normalizes them into one schema. You then build a single [virtual dimension](/features/tagging/dimensions) (call it `team` or `product`) with one rule per source that maps its native key to the right owner:

| 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.

<Note>
  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](mailto:contact@costory.io) about your setup.
</Note>

## 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](/features/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](/features/dashboards) 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 you get once it is allocated

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

<CardGroup cols={3}>
  <Card title="Measure adoption" icon="chart-line" href="/features/unit-economics">
    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.
  </Card>

  <Card title="Budget per team" icon="money-check-dollar" href="/use-cases/automate_budget">
    Set an AI budget on the team dimension and track burn against it.
  </Card>

  <Card title="Alert on spend" icon="bell" href="/features/alerts">
    Fire a Slack or email alert when a team's daily AI cost crosses a threshold, before month-end.
  </Card>
</CardGroup>

## Next steps

* Connect each provider from [Billing Data](/setup/billing).
* Build your cross-provider `team` [virtual dimension](/features/tagging/dimensions).
* Use the [Costory MCP](/features/mcp) to build and investigate your AI cost in natural language.