• Shared API keys break cost ownership at every hop unless you propagate a stable ownership contract with the request.
• The minimum useful contract is trace_id, owner_team, workflow_id, feature, and a non-PII user or tenant handle.
• Request metadata at the gateway is necessary, but it is not enough unless the same fields survive router, queue, and worker hops.
• Good attribution lets you answer chargeback questions per request, not just per provider account or per project.
• A quick audit usually finds the same failure mode: usage logs exist, but ownership fields are missing or inconsistent when the provider bill arrives.

If your FinOps team is managing AI API spend in the $5k to $50k per month range, the hard part in 2026 is no longer getting the bill. The hard part is explaining who owns each slice of it when one user action fans out through a gateway, a router, an agent loop, a queue, and three different model providers.

According to the FinOps Foundation State of FinOps 2026, 98% of respondents now manage AI spend. That makes attribution a day-two operating problem, not an advanced edge case. Once multiple teams share the same API gateway or model account, project-level dashboards stop being enough for chargeback, anomaly review, and unit economics.

This guide covers the patterns that actually hold up under review: request-level tagging, trace-level ownership fields, gateway metadata, and a simple audit method you can run against your current stack.

Why shared API keys lose attribution at every hop

A shared API key is convenient for platform engineering and terrible for cost ownership. The provider sees one caller, but your finance process needs to know which internal team, workflow, feature, or customer generated the spend.

Attribution typically disappears in four places:

1. The application sends only the prompt and model, with no ownership fields.
2. The gateway adds metadata, but the router or agent runtime does not carry it forward.
3. Async hops rewrite the payload and drop the original request context.
4. Billing data lands in one system while trace data lands in another, with no stable join key.

The result is familiar: the monthly review shows a spike in Anthropic or Bedrock spend, the platform team knows it came through the shared gateway, but nobody can prove whether the cost belongs to support automation, internal copilots, or a customer-facing workflow.

That is why raw provider dashboards are necessary but insufficient. OpenAI's Usage API gives organization-level usage and cost views by project and API key. Anthropic's Admin API can group usage by dimensions such as API key, workspace, and model. Those are useful controls, but they still do not solve per-request ownership when many teams share the same path to the model.

The ownership contract you need on every request

The cleanest fix is to treat cost attribution as a data contract, not as a reporting afterthought. Every LLM request should carry the same small ownership envelope from the first user action to the final provider call.

At minimum, carry these fields:

• trace_id: the end-to-end join key across gateway, router, workers, and provider logs
• owner_team: the team that owns the spend
• workflow_id: the workflow, feature, or product path that triggered the call
• feature: the finer-grained capability, such as ticket-triage or draft-reply
• tenant_id or customer_id_hash: customer ownership, hashed or non-PII
• user_id_hash: user-level analysis without exposing personal data
• provider, model, and service_tier: required for accurate cost calculation
• cache_hit or cache_policy: essential when some calls are discounted or bypassed

If you already use OpenTelemetry, this fits naturally. The OpenTelemetry docs describe baggage as contextual key-value data that propagates across service boundaries, and they explicitly warn not to put credentials or other sensitive data in it. That makes baggage a good transport for ownership metadata, provided you keep the keys boring, stable, and safe.

A practical rule is this: if a field is needed during chargeback review, it must exist before the first gateway hop. If it only appears later in a worker log, assume it will be missing in production when you need it most.

Which attribution pattern actually works

Not all attribution strategies are equal. Some look neat in architecture diagrams and fail the first time a request fans out across providers.

The last row is what holds up in practice. It is the only pattern that lets you answer questions like, “Why did Support Automation own 62% of yesterday’s GPT spend even though the API key belongs to Platform?”

What complete vs broken attribution looks like in a real trace

Here is a broken trace. The gateway logs a request, but ownership disappears before the actual model calls:

{
  "trace_id": "tr_9f4c",
  "gateway": {"team": "support-platform", "feature": "ticket-triage"},
  "router": {"provider": "bedrock", "model": "anthropic.claude-sonnet"},
  "worker": {"prompt_tokens": 18400, "completion_tokens": 2100},
  "billing_join": null
}

You can see token usage, but not who should pay for it. If that request spawned a retry or a fallback call, the finance team is left reconstructing ownership from application logs and Slack memory.

Now compare that with a complete trace:

{
  "trace_id": "tr_9f4c",
  "owner_team": "support",
  "workflow_id": "ticket-triage-v4",
  "feature": "auto-classify",
  "tenant_id_hash": "t_71b2",
  "user_id_hash": "u_19ac",
  "provider_calls": [
    {
      "provider": "bedrock",
      "model": "anthropic.claude-sonnet",
      "request_id": "br_441",
      "input_tokens": 18400,
      "output_tokens": 2100,
      "service_tier": "standard",
      "estimated_cost_usd": 0.091
    },
    {
      "provider": "openai",
      "model": "gpt-4.1-mini",
      "request_id": "oa_882",
      "input_tokens": 3200,
      "output_tokens": 480,
      "service_tier": "standard",
      "estimated_cost_usd": 0.002
    }
  ],
  "total_estimated_cost_usd": 0.093
}

That second trace is chargeback-ready. It supports team allocation, customer drill-down, retry analysis, and provider comparison without manual reconstruction.

The important point is not the exact field names. The important point is that the same ownership fields survive every hop and can be joined to either provider usage logs or your internal cost model.

Gateway metadata matters, but it is not the whole answer

Gateways are the right place to enforce tagging because they see every request before routing. Add ownership fields there even if upstream teams forget. But do not stop there.

AWS Bedrock's per-request metadata tagging documentation makes the limitation explicit: request metadata is recorded in invocation logs, but it does not appear in AWS Cost Explorer or the Cost and Usage Report as a native cost allocation tag. AWS recommends joining invocation logs with CUR on requestId, or computing costs directly from logged token counts and pricing.

That pattern generalizes across providers. Gateway metadata gives you the attribution payload. A stable trace or request ID gives you the join key. Your cost pipeline still has to connect the dots.

In practice, that means your gateway should do three things:

1. Reject or quarantine calls missing required ownership fields.
2. Stamp a stable trace_id and forward it downstream unchanged.
3. Emit a normalized event after every provider response with tokens, model, tier, latency, and ownership fields.

If your gateway does only logging and not enforcement, the coverage rate will drift. One new worker, one retry path, or one streaming endpoint will quietly become “unallocated spend.” In a $22,000 monthly AI bill, even 11% unattributed usage means $2,420 that nobody wants to own.

How to calculate LLM spend by team when one request fans out

Per-request attribution gets harder when an agent or workflow makes multiple model calls. The fix is simple: treat the user-visible request as a parent span and every provider invocation as a child cost event.

For example, a single customer action might do all of this:

• classify the task with a cheap model
• retrieve context with embeddings or search
• call a larger reasoning model for the final answer
• retry once if a tool invocation fails

If you only attribute the final call, you understate the feature cost. If you attribute only the gateway request, you miss which provider or retry path caused the spike.

A better pattern is:

• parent request owns the business context
• child calls own the metering details
• total request cost is the sum of all child calls
• chargeback rolls up by owner_team, workflow_id, feature, and tenant_id_hash

This also helps with anomaly review. If Team A's spend jumps 37% week over week, you can separate “more traffic” from “same traffic, more retries” or “same traffic, model mix changed.”

How to audit your current attribution setup

A fast audit does not start with the invoice. It starts with ten recent traces.

Pick ten real AI requests across two or three workflows and verify these questions:

1. Can you trace each request from user action to every provider call?
2. Does each hop preserve the same trace_id?
3. Do owner_team, workflow_id, and feature exist on every provider event?
4. Can you identify tenant or customer ownership without exposing PII?
5. Can you reconstruct total request cost from token and pricing data?
6. Can you explain retries, fallbacks, and cache effects?
7. What percentage of AI spend is currently unattributed?

If you cannot answer at least six of those seven, your reporting is not ready for chargeback.

A practical target is to get unattributed spend below 2% and keep a visible weekly coverage report. Anything higher usually means a specific broken hop, not a mysterious finance problem.

If you want a quick first pass, run your current traces through the free AI cost auditor. It is useful for spotting where ownership fields disappear between gateway and downstream calls. If your team wants shared reviews and team-level workflows later, join the waitlist for the upcoming team features.

FAQ

How do I attribute AI costs to specific teams when tenant_id is missing?

Start with owner_team, workflow_id, and feature. Those three fields are usually enough for internal chargeback even when customer identity is absent. Then add a hashed tenant or customer handle as soon as possible. Do not block attribution work waiting for perfect tenant metadata.

What should I check first when an attribution audit fails?

Check whether the same trace_id survives gateway, queue, worker, and provider response events. In most systems, the first failure is not pricing logic. It is context propagation breaking at an async boundary or retry path.

How does this work across OpenAI, Anthropic, and Bedrock at the same time?

Use one internal schema for ownership and one normalized cost event format. Provider-specific fields can vary, but your internal event should always carry the same trace, team, workflow, feature, token, tier, and cost fields. Normalize first, analyze second.

What is the difference between request-level and session-level attribution?

Session-level attribution rolls many actions into one bucket, which is useful for product analytics but weak for chargeback disputes. Request-level attribution ties cost to a single user-visible action and is much better for retries, fallbacks, and per-feature optimization.

Do I need one API key per team to make this work?

No. Separate keys can help with coarse controls, but they are not required for accurate attribution. A stable ownership contract plus end-to-end tracing is more important than key sprawl.

Summary

AI API cost attribution breaks when ownership is treated as optional metadata instead of a required contract. Shared keys, gateways, routers, and agent hops are all manageable if the same trace and ownership fields survive every step. The teams that get chargeback right in 2026 are not the ones with the prettiest provider dashboard. They are the ones that can explain any expensive request, end to end, with evidence.

If you want to test your current setup, start with ten traces, measure unattributed spend, and run the gaps through the free auditor. If you need collaborative review flows after that, join the waitlist for the team features.