How to Track LLM Usage and Spend by Team

A shared OpenAI or Anthropic organization key produces one invoice line per month, which means any company running several teams against that key cannot separate LLM usage and spend by team. Bifrost, the open-source AI gateway built in Go by Maxim AI, resolves this at the infrastructure layer: every request authenticates through a virtual key that carries team identity, and every response is priced and recorded before it returns to the caller. This post covers the full path, from labeling requests through to enforcing per-team budgets that block overspend instead of reporting it after the invoice arrives.

Why LLM Spend Is Hard to Attribute by Team

Attributing LLM usage and spend by team is difficult because providers bill at the credential boundary rather than the organizational boundary. An API key is the only dimension the invoice knows about, so any team structure that does not map one-to-one onto keys is invisible to billing. Attribution has to be added upstream of the provider, at the point where requests are issued.

The specific obstacles teams run into:

• Credential-level billing: provider dashboards report totals per key or per project, not per team, feature, or customer.
• Key splitting trade-offs: issuing one provider key per team buys attribution but fragments failover, load balancing, and shared rate limit headroom across keys.
• Inconsistent application tagging: when each service adds its own metadata, coverage depends on every team remembering to instrument, and gaps appear silently.
• Multi-provider pricing: a team running OpenAI, Anthropic, and Bedrock needs three pricing schemas normalized into one currency figure before any rollup is meaningful.
• Hidden cost multipliers: retries, cached tokens, batch discounts, and reasoning tokens all change the real cost of a request in ways a raw token count does not capture.

The pressure to solve this is now widespread. The FinOps Foundation's State of FinOps 2026 report found that 98% of respondents manage AI spend, up from 31% two years earlier. Centralizing attribution at the gateway is one of the practical answers, and the governance capabilities available at that layer are what make per-team reporting possible without touching application code.

Three Approaches to LLM Cost Attribution

Teams generally choose between provider key splitting, application-level tagging, and gateway-level attribution. The three differ in how much application code they require, how complete their coverage is, and whether they can enforce limits rather than only report on them.

Gateway-level attribution is the only option of the three that both covers all traffic and blocks a request before the spend happens. Because the Bifrost AI gateway works as a drop-in replacement for existing SDKs, adopting it means changing a base URL rather than rewriting call sites, which is what makes complete coverage realistic. For teams comparing options at this layer, the LLM Gateway Buyer's Guide breaks down the capability matrix in more detail.

How Bifrost Tracks LLM Usage and Spend by Team

Virtual keys are the primary governance entity in the open-source Bifrost gateway. Applications authenticate with a virtual key instead of a raw provider key, and that key carries the access permissions, budget, and rate limits for whoever holds it. Requests can present the key through the x-bf-vk header or through the standard Authorization, x-api-key, x-goog-api-key, and api-key headers, so existing SDK code continues to work unchanged.

Each virtual key attaches to exactly one team or one customer, and those attachments are mutually exclusive. That constraint is what makes team rollups unambiguous: a request's spend belongs to one team, never two.

The budget hierarchy runs four levels deep, with an independent budget at each level:

• Customer: the top-level entity, typically a business unit or an external tenant
• Team: one-to-many under a customer, holding the team's own budget
• Virtual key: one-to-many under a team, with its own budget and rate limits
• Provider config: one-to-many under a virtual key, with per-provider budgets and rate limits

Cost is computed by Bifrost rather than estimated. Pricing is applied using real-time model pricing data, actual input and output token counts from the provider response, the request type (chat, text, embedding, speech, or transcription), cache status for reduced-cost cached responses, and batch operation discounts. The result is a per-request dollar figure recorded alongside the rest of the request metadata for that call.

Labeling Requests for Per-Team Reporting

Team attribution in reporting comes from custom dimensions attached at request time. Bifrost, the AI gateway, accepts x-bf-dim-* headers and turns each one into a label on the metrics it emits, so a team name travels with the request from the caller to the dashboard.

Configure the label set once, then send values per request:

curl -X POST <http://localhost:8080/v1/chat/completions> \
  -H "Content-Type: application/json" \
  -H "x-bf-dim-team: engineering" \
  -H "x-bf-dim-environment: production" \
  -H "x-bf-dim-project: support-agent" \
  -d '{
    "model": "gpt-4o-mini",
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

The label names are declared in configuration as prometheus_labels, for example ["team", "environment", "organization", "project"]. From there, telemetry exposes the counters that matter for cost reporting, each carrying the provider and model base labels plus the custom dimensions:

• bifrost_cost_total: total cost in USD for upstream provider requests
• bifrost_input_tokens_total and bifrost_output_tokens_total: token volume sent and received
• bifrost_upstream_requests_total: request counts, with success and error variants
• bifrost_cache_hits_total: direct and semantic cache hits, broken out by cache type

A single Prometheus query over bifrost_cost_total grouped by the team label produces monthly LLM usage and spend per team without any additional pipeline. Metrics are available by scraping the /metrics endpoint or pushing to a Push Gateway for multi-node deployments, and telemetry collection runs asynchronously so it adds no latency to request processing. The same x-bf-dim-* values also propagate into internal logs and OpenTelemetry span attributes, which keeps team attribution consistent with the OpenTelemetry GenAI semantic conventions already used elsewhere in the stack.

Enforcing Team Budgets, Not Just Reporting Them

Reporting explains overspend after it happens; budgets prevent it. On the Bifrost platform, every applicable budget in the hierarchy is checked independently before a request proceeds, and a failure at any single level blocks it.

The checking sequence for a team-attached virtual key runs provider config budget, then virtual key budget, then team budget, then customer budget. When the request succeeds, its cost is deducted from every applicable level, so a team budget and the customer budget above it both reflect the same spend.

Practical details worth configuring deliberately:

• Reset durations: budgets and limits accept 1m, 5m, 1h, 1d, 1w, 1M, and 1Y, with day, week, month, and year windows typical for cost control.
• Calendar alignment: setting calendar_aligned resets a budget at the start of each calendar period in UTC instead of on a rolling window, which lines team budgets up with finance reporting periods.
• Rate limits: request and token limits apply at the virtual key and provider config levels, running in parallel so a team can be capped on call volume and token throughput independently.
• Routing interaction: a provider that exceeds its budget or rate limits is excluded from routing, so other providers under the same virtual key stay available instead of the request failing outright.

This combination is what separates cost governance from cost reporting, and the Bifrost governance resources cover how access control, budgets, and limits compose into a single policy per consumer.

Scaling Team Attribution Across a Large Organization

Manual virtual key issuance stops scaling once the number of teams passes a few dozen. The Bifrost gateway addresses this in the enterprise tier with access profiles: reusable policy templates that describe what a user, team, or business unit is permitted to do, and that materialize into virtual keys automatically.

Access profiles carry the provider list, model whitelist, budgets, rate limits, and MCP tool access defined once on the template. Assigning a profile creates a per-user copy with isolated budget and rate limit counters, and marking a profile as a role's default provisions new users in that role automatically. Auto-issued keys are write-protected, so a user cannot weaken their own policy by editing the key, and every template change is recorded with a full snapshot history.

Two further capabilities matter for organizations reporting spend across business units. Customer-scoped requests let a team attached to multiple customers attribute a single request to one specific customer using a scope header, rather than charging every customer the team belongs to. And per-request metadata (timestamps, provider, model, latency, token counts, cost, and status) is retained in the logs store, with large payloads optionally offloaded to S3 or GCS so long retention stays affordable. Regulated teams running this in isolated environments can review the deployment and compliance options on the Bifrost Enterprise page.

Start Tracking LLM Spend by Team with Bifrost

Tracking LLM usage and spend by team comes down to three decisions: authenticate every application through a virtual key rather than a raw provider key, attach team dimensions to each request so reporting can group by them, and set budgets at the team level so overspend is blocked at request time. The Bifrost gateway layer provides all three without application rewrites, since adopting it changes a base URL rather than call sites.

To see how per-team budgets, cost labels, and access profiles would map onto your organization, book a demo with the Bifrost team.