LLM Cost Attribution for Teams: Who's Spending What?
Most engineering organizations start with a single OpenAI API key shared across the whole company. It works fine at first. Then three teams are using it. Then five. Then someone notices the monthly bill jumped from $800 to $4,200 in 60 days and nobody knows why.
This is the LLM cost attribution problem: when multiple teams, projects, or features share API access, spend becomes invisible at the organizational level. You know the total but not the breakdown. You can't charge back to cost centers, you can't set per-team budgets, and you can't identify which team or feature drove the spike.
Here's how to fix it.
Why This Is Harder Than It Sounds
With traditional cloud services (AWS, GCP, Azure), cost attribution is solved at the infrastructure layer. Separate AWS accounts per team, or resource tags that flow through to billing reports.
LLM APIs don't work that way. You get one invoice from OpenAI or Anthropic, covering all usage on your account. The providers offer limited native attribution:
- OpenAI: No native per-team attribution. Usage dashboard shows totals only. You can use multiple API keys, but they all bill to the same account with the same view.
- Anthropic: Similar situation. Workspaces (under the API) let you create separate keys, but billing is still rolled up.
- Google AI Studio / Vertex: Google Cloud's resource hierarchy gives you project-level billing separation, but it requires more setup.
So attribution has to be implemented at the application layer.
Strategy 1: One API Key Per Team
The simplest approach: each team or project gets its own provider API key. Your backend routes requests through the appropriate key based on which team or feature is making the call.
| API Key | Owner | Month-to-date cost |
|---|---|---|
sk-prod-search-...abc |
Search team | $1,240 |
sk-prod-chat-...def |
Chat feature | $2,100 |
sk-prod-reports-...ghi |
Analytics team | $380 |
sk-staging-...jkl |
Shared staging | $95 |
Pros: Zero code changes at the call site. You can revoke a team's key without affecting others. Some providers show per-key breakdowns in their dashboards.
Cons: Requires managing secrets per team. OpenAI's usage dashboard doesn't show per-key breakdowns natively — you still can't see exactly which key spent what without a third-party tool.
Strategy 2: Metadata Tagging at the Call Site
Most LLM APIs support sending metadata alongside your request. This metadata doesn't affect the model's behavior — it's purely for attribution. Your monitoring layer captures it and uses it for cost grouping.
For OpenAI, use the metadata field (or user for simpler tagging):
const response = await openai.chat.completions.create({
model: "gpt-4o",
messages: [...],
user: "team:search|feature:autocomplete|env:prod"
});
For Anthropic, use the metadata object:
const response = await anthropic.messages.create({
model: "claude-sonnet-4-5",
messages: [...],
metadata: {
user_id: "team:analytics",
// custom fields are passed through
}
});
The metadata gets logged by your monitoring layer alongside the token counts, and you can slice costs by any dimension: team, feature, user segment, environment, model, etc.
Strategy 3: A Centralized LLM Gateway
For larger organizations, the most scalable approach is routing all LLM traffic through a central internal service. This gateway:
- Accepts requests from all internal teams
- Requires callers to identify themselves (team ID, service name)
- Appends attribution metadata before forwarding to the provider
- Logs token usage and cost per caller
- Enforces per-team rate limits and budget caps
# Internal gateway request (simplified)
POST https://llm-gateway.internal/v1/chat
{
"team": "search",
"feature": "autocomplete",
"provider": "openai",
"model": "gpt-4o-mini",
"messages": [...]
}
The gateway translates this into the correct provider API call, handles auth, logs the usage, and returns the response. Callers never touch provider API keys directly.
This approach also makes it easy to implement model routing — the gateway can automatically downgrade to a cheaper model when the team's quality threshold allows it, or when a budget limit is being approached.
What to Track Per Team
Once you have attribution data flowing, these are the metrics that matter:
| Metric | Why it matters |
|---|---|
| Total cost (this period) | Budget tracking and chargeback |
| Cost per request | Efficiency benchmark; spikes indicate regression |
| Input vs output token split | High output % = optimization opportunity |
| Model distribution | Are teams using expensive models where cheaper ones would work? |
| Daily cost trend | Early warning for unexpected spikes before month-end |
| Cost per user / per feature | Unit economics for pricing decisions |
Setting Per-Team Budgets and Alerts
Attribution without budgets is just reporting. The actionable part is setting limits:
- Soft limits — send a Slack alert when a team hits 80% of their monthly budget. No hard cutoff, just visibility.
- Hard limits — the gateway rejects requests when a team exceeds their daily or monthly cap. Use sparingly (it can break production features), but it's the only way to guarantee overage prevention.
- Rate limits per team — requests/minute caps prevent one team's batch job from saturating the shared account and triggering provider-side rate limiting for everyone else.
The Chargeback Question
If your organization does internal cost chargebacks, LLM costs are now attributable to specific teams and cost centers. This creates the right incentives:
- Teams that build efficient features (lower cost per request) benefit from lower chargebacks
- Teams know their AI spend is visible, which encourages more intentional model selection and prompt engineering
- Budget planning becomes data-driven instead of "we spent $X last quarter, let's add 20%"
One common pushback: "Won't this discourage teams from using AI if they're being charged for it?" Maybe — but that's not necessarily bad. If a team can't justify the cost of their AI feature in terms of value delivered, that's information the organization needs. The goal is appropriate usage, not maximum usage.
Implementing This With LLMeter
The attribution strategies above require either infrastructure changes (new API keys, a gateway service) or instrumentation at every call site. Both take engineering time.
LLMeter handles the monitoring layer without a proxy. You connect your existing provider API keys to LLMeter, and it tracks usage and cost per key. For per-team attribution specifically:
- Create one LLMeter project per team (Search, Chat, Analytics, etc.)
- Connect the API key used by each team to its respective project
- Each project gets its own cost dashboard, usage trends, and budget alerts
- The org-level dashboard shows the roll-up across all teams
There's no code to add, no proxy to route through, and no SDK to install. The cost data flows directly from the providers into LLMeter via their usage APIs.
A Real-World Cost Breakdown Example
Here's what per-team attribution typically reveals in a 20-person engineering org:
| Team | Monthly LLM Cost | % of Total | Cost per Request | Primary Driver |
|---|---|---|---|---|
| Chat / Copilot | $3,200 | 52% | $0.042 | High output tokens per session |
| Search / RAG | $1,400 | 23% | $0.008 | High volume, short outputs |
| Automation / Agents | $900 | 15% | $0.18 | Multi-step chains, long context |
| Data Enrichment | $520 | 8% | $0.003 | Batch jobs, cheap model |
| Staging / Dev | $140 | 2% | variable | Testing |
Without attribution, you'd see "$6,160/month" and have no idea where to optimize. With attribution, you immediately see that the Automation team has a cost-per-request of $0.18 — 22x higher than the Search team. That's where you look first.
Getting Started: The Minimum Viable Attribution Setup
- Audit your current API keys. How many keys do you have? Who owns each one? Are any shared across teams?
- Create per-team keys. One key per team or per major feature. Takes 10 minutes in the provider dashboard.
- Connect to a monitoring tool. Either build your own logging, or use LLMeter (free tier covers up to 3 providers).
- Set up one alert. Pick a monthly budget number per team. Set an alert at 80% of that number. You'll catch spikes before they become surprises.
- Review weekly. Cost data is only useful if someone looks at it. Add a 10-minute LLM cost review to your weekly engineering sync for the first few months.
The cost of not doing this is a recurring one: every month you operate without attribution is a month of optimization opportunities you can't see. Start simple, stay consistent, and the data will tell you where to act.