How do you attribute AI API costs by feature and team?
You tag every call at the request layer, before it reaches the provider, with the feature and team it belongs to — because the provider's invoice never captures that context on its own. This matters because “AI spend went up” is not an actionable finding. “The new support-bot feature drove the increase” is.
The core problem is structural, not a matter of finding the right dashboard: one provider API key routinely serves many features and teams, and the resulting invoice is one number with no breakdown underneath it.
The problem
A single OpenAI or Anthropic API key is easy to provision once and reuse everywhere — which is exactly why it ends up authenticating calls from the support chatbot, the internal search feature, an experimental agent workflow, and a batch summarization job, all in the same billing period. The invoice at the end of the month reports a model name and a token count. It says nothing about which of those four features generated the spend, and nothing about which team owns the cost.
That gap compounds every month it goes unaddressed. By the time someone tries to explain a spend increase to finance, the honest answer is often “we don't know which feature drove it” — not because nobody cares, but because nothing in the request path ever recorded the context needed to answer the question.
Why the common approaches fall short
Per-API-key tagging
Issue a separate provider API key per feature or team, and let the key itself be the attribution boundary. This works cleanly as long as every key maps to exactly one feature — but it breaks the moment a key gets shared across two product surfaces to save on setup time, or a single backend service (an agent orchestrator, a shared inference gateway) fans out to multiple features using the same credential. At that point the key stops being a reliable attribution unit, and untangling it after the fact means reading application logs, not billing data.
Manual spreadsheet reconciliation
Export the provider invoice, cross-reference it against deploy logs or engineering's best recollection of which team shipped what that month, and build an allocation spreadsheet by hand. This is a legitimate stopgap for a team's first month of AI spend, when volume is low enough to reconstruct by memory. It does not scale past that: the reconciliation is stale the moment it's finished, requires someone to redo it every billing cycle, and depends on institutional memory that degrades as teams and features change.
Billing-layer tagging
Look for a tagging feature on the provider's billing dashboard, the way you'd tag a cloud resource in AWS or GCP. Providers don't expose that granularity for API usage — the invoice reports model and token count, not which feature or team the call served. There is no billing-layer setting that recovers information the provider never captured in the first place, because the provider has no visibility into your application's internal routing at all.
How Cognocient solves this
Cognocient sits in the request path as a proxy — your application calls Cognocient instead of the provider directly, a one-line base-URL change — and reads attribution straight off each request's HTTP headers before forwarding it on. Add X-Cost-Feature, X-Cost-Department, and X-Cost-Session to a call, and that call is attributed the moment it happens — not reconstructed later from an invoice that never had the context to begin with.
X-Cost-Feature and X-Cost-Department answer which product surface and which team a call belongs to. X-Cost-Session groups related calls — the calls making up one support ticket, one PR, one agent task — so cost rolls up per workstream, not just per feature. Because the tagging happens on the call itself rather than on the shared key that authenticates it, one key can safely serve any number of features without losing attribution — the header, not the key, is what Cognocient reads. See the full attribution headers reference for the complete header list, including GL-account and user-level tags for chargeback reporting, and the AI spend attribution glossary entry for the underlying concept.
What this looks like in practice
Consider a hypothetical team running three AI features off one provider key: a support chatbot, an internal document search tool, and a newer agentic workflow still in beta. Every call already goes through Cognocient's proxy. Adding attribution means adding two headers to each feature's existing API call — X-Cost-Feature: support-bot, X-Cost-Feature: doc-search, X-Cost-Feature: agent-beta — with no other code change required.
From that point forward, the same invoice total splits into three visible lines instead of one opaque number. If the agent-beta feature's share climbs sharply week over week, that shows up as a per-feature trend immediately — not as a mystery someone has to reconstruct from deploy logs three weeks after the invoice arrives. This is illustrative of how the mechanism behaves, not a specific customer's reported result.
The pattern generalizes past three features and one team. Every call tagged this way rolls up into per-feature, per-department, and per-session cost breakdowns automatically, which is the foundation the rest of AI FinOps builds on — you can't enforce a per-feature budget or measure cost per outcome without attribution existing first. See the full guide to what a mature AI FinOps practice looks like for how attribution fits alongside enforcement and outcome-tracking.