How to track LLM API costs across your team

Your Anthropic invoice arrives and the number is higher than last month. You know your team grew by two developers. You do not know which projects drove the increase, whether the extra spend correlates with more output, or which developer is running five-figure context windows on every prompt.

This is the default state for most engineering teams on Claude Code. The API gives you aggregate token counts. It does not give you attribution.

Why is LLM API cost tracking hard?

The core problem is that LLM API billing is aggregate by default — providers invoice at the account level, not at the developer or project level.

Anthropic shows you total input tokens, total output tokens, and total cost, broken down by model and by time period. It does not tell you which developer generated those tokens, on which codebase, for which feature or bug fix.

For a team of five, this is manageable — you can roughly reconstruct who did what. For a team of twenty-five, it is opaque. The developer who ran a 200k-token context window on a large refactor looks identical in the invoice to the developer who used 200k tokens across 400 normal-sized sessions.

What LLM cost data you get from providers by default

Provider	Billing unit	Per-developer data	Per-project data	Exportable log
Anthropic (Claude Code)	Tokens (input/output) per model	❌ Aggregate only	❌ None	⚠️ Usage API, not real-time
GitHub Copilot	Per seat/month	✅ Seat count	❌ None	❌ No cost log
OpenAI	Tokens per model	❌ Aggregate only	❌ None	⚠️ Usage API
Cursor (subscription)	Per seat/month	✅ Seat count	❌ None	❌ No cost log
Cursor (BYOK)	Tokens via your key	❌ Aggregate only	❌ None	⚠️ Via provider API

The pattern is consistent: subscription-based tools give you seat counts; API-key-based tools give you aggregate token totals. Neither gives you the attribution layer you need for cost management.

How do you attribute LLM API costs to individual developers?

Attribution requires capturing metadata at the session level — before the API call is made — and correlating it back to the provider invoice.

The attribution layer sits between the developer's IDE and the LLM provider. It records:

• Developer identity (user ID or email)
• Project context (working directory, repository, branch)
• Model selected (e.g. claude-sonnet-4-6, claude-opus-4-8)
• Token counts for the session (input, output, cache read, cache write)
• Timestamp and session duration

That record is written to a central log. At billing time, the log is aggregated to match the provider invoice total — and you can slice it any way: by developer, by project, by team, by week.

Why IDE-level capture is more reliable than API proxying

There are two approaches to capturing session metadata:

API proxy: Route all LLM traffic through a proxy that logs every request and response. Accurate and complete, but adds latency, requires all developers to point their tools at the proxy, and creates a single point of failure.

IDE sync agent: A lightweight agent installed per developer seat that reads session context locally and reports metadata without intercepting the API call. No latency impact, no traffic rerouting, but depends on the agent being installed and running.

For most engineering teams, the sync agent approach works better in practice. Developers are sensitive to latency in their coding tools; a proxy that adds even 50ms per request will generate complaints. The trade-off is installation compliance — you need the agent on every developer machine to get complete attribution.

Context caching and cost attribution: Anthropic's prompt caching reduces cost for repeated context — but cached token reads are priced differently from new token writes. If your attribution layer does not distinguish cache hits from cache writes, you will over-attribute cost to developers who re-use context efficiently and under-attribute it to those who repeatedly re-send the same large context. CloudByte AI logs all four token types (input, output, cache_creation_input, cache_read_input) per session.

How do you track LLM costs across multiple AI tools?

Normalise to a common cost unit — cost per active coding hour or cost per merged commit — and track that metric per developer, not raw token counts.

The challenge with multi-tool tracking is that costs are in different units:

• Claude Code: dollars per 1M tokens (varies by model)
• GitHub Copilot: flat per-seat monthly fee regardless of usage
• Cursor: per-seat fee plus BYOK API costs if enabled
• Custom LLM deployments: compute cost in dollars per hour

A developer using Claude Code heavily and a developer using Copilot cannot be compared on raw spend without normalisation. But if you measure cost per commit merged or cost per PR review, both can be evaluated against the same business outcome.

Practical normalisation approach

1. Capture all AI tool spend — API token costs (from provider billing), seat costs (from subscription invoices), any infra costs for self-hosted models.
2. Map to a common time unit — weekly or monthly per developer.
3. Join to output metrics — commits merged, PRs reviewed, features delivered (from git + project tracking).
4. Calculate cost efficiency — total AI spend per developer / output units per developer.

Teams that do this consistently find that cost efficiency varies 3–5x across developers at the same AI tool tier. The highest-spend developers are not always the highest-output ones — and the lowest-spend developers are not always underusing the tool. Some developers extract more value per dollar simply by structuring prompts better or using context caching effectively.

What should you alert on for LLM API cost anomalies?

Alert on week-over-week spend delta per developer, not just total monthly budget.

Monthly budget alerts are too slow. A developer who hits 10x their normal weekly spend on day 3 of the month will have run up significant cost before any monthly alert fires. Weekly alerts catch the spike while there is still budget to redirect.

Recommended alert thresholds:

Alert	Trigger	Why
Developer spike	Developer's weekly spend > 2× their 4-week average	Catches runaway context windows or accidental loops
Project surge	Project's weekly spend > 3× prior week	Signals a large refactor, migration, or uncontrolled batch job
Model tier shift	Developer starts using Opus when they normally use Sonnet	Unintentional model upgrade — often a config change
Zero activity	Developer had spend last week, zero this week	Tool not working, developer stopped using AI, or key revoked
Budget pacing	Team spend at >80% of weekly budget by Wednesday	Will likely overshoot weekly target

The zero-activity alert is underrated. Most cost dashboards focus on high spend. Low spend is equally informative: if a developer who normally uses Claude Code actively shows zero API calls for a week, that is a signal worth investigating — the tool may be broken for them, they may have switched to a different tool, or they may be stuck on work where AI is not helping.

How does BYOK change LLM cost tracking?

BYOK (Bring Your Own Key) gives you direct API cost data but removes the per-developer attribution that a managed subscription would handle.

With a managed AI tool subscription, the vendor handles billing and often surfaces per-seat usage data. With BYOK, your Anthropic key is used directly — all costs appear in your Anthropic invoice, and you are responsible for attribution.

BYOK advantages for cost tracking:

• Direct access to Anthropic's Usage API for real-time token data
• No markup from the AI tool vendor on token costs
• Can set per-key or per-project API keys to create natural cost buckets

BYOK challenges for cost tracking:

• Anthropic's Usage API is aggregate — still no per-developer breakdown without additional tooling
• Developers can pass their own keys, bypassing your organisation key entirely
• Multiple API keys across projects and teams make reconciliation harder

The cleanest BYOK cost tracking setup: one organisation key per team (not per developer), with a sync agent layer that attributes sessions to developers and writes records to a central cost log. This gives you both: Anthropic's accurate token data and the attribution layer that makes it actionable.

See how CloudByte AI tracks AI token usage and spend by developer, project, and team — including support for BYOK Anthropic deployments via the integrations layer.