How to Track LLM API Costs Across Your Engineering 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

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.

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:

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 PMS tracks AI token usage and spend by developer, project, and team — including support for BYOK Anthropic deployments via the integrations layer.

---

FAQ: Tracking LLM API costs for engineering teams

How do I track Anthropic Claude API costs by developer?

Anthropic's Analytics API provides aggregate usage by model and time period, not per developer. To get per-developer attribution, you need a layer — typically a sync agent per seat — that captures session metadata (developer ID, project, model, token counts) and correlates it to the Anthropic invoice. CloudByte PMS does this automatically for Claude Code sessions.

What does the average developer spend on Claude Code API calls per month?

In our dataset, median spend per active developer runs $18–$45/month on Sonnet-class models and $80–$160/month for teams using Opus heavily. The top 20% of developers by token consumption typically account for 60–70% of total spend — identifying whether that spend correlates with proportionally higher output is the first question cost tracking should answer.

How do I attribute LLM API costs to specific projects or teams?

Capture the working directory or branch name from the developer's IDE at session start and record it alongside token counts. Without project-level tagging, provider invoices only show aggregate totals — you cannot split them by team or cost centre without external tooling.

How do I stop LLM API cost overruns before the invoice arrives?

Alert on week-over-week developer spend delta rather than monthly totals. Weekly alerts at 50% and 80% of weekly budget give you time to investigate and adjust. Monthly limits fire too late.

Can I track LLM costs across Claude, Copilot, and Cursor?

Yes, by normalising to a common unit — cost per commit or cost per active coding hour — rather than comparing raw spend. Each provider uses different billing units (tokens vs. seat fees vs. subscription tiers); normalisation lets you evaluate cost efficiency across your team regardless of which tool each developer uses.

What is BYOK and how does it affect LLM cost tracking?

BYOK (Bring Your Own Key) means using your organisation's Anthropic API key directly in Claude Code. All costs appear on your Anthropic invoice with no vendor markup, and you get direct Usage API access — but attribution is still aggregate. You need a per-developer session layer on top to split costs by engineer or project.