How to track AI coding spend across your engineering org (2026)

Two years ago an AI coding assistant was a $20 seat. Today a single developer running agents can spend more on tokens in a week than their laptop cost. This is a practical guide to seeing that spend before the invoice does: where the numbers live, the four ways to collect them, and what to attribute them to.

By the CodeCost team · 9 min read

Why this became a problem in 2026

Three things changed at once.

The tools became agents. Claude Code, Codex CLI, Gemini CLI and their desktop and IDE cousins no longer answer one prompt with one completion. A single task fans out into subagents, re-reads files, calls tools, retries. The token count of one sitting is no longer bounded by how fast a person can type.

Usage moved from seats to consumption. Anthropic’s own published figure for Claude Code is roughly $150 to $250 per developer per month on average, with the heavy tail far above that. The tail is the problem: an average tells the CFO nothing about the three people running overnight refactors.

Budgets got missed in public. In May, Forbes reported that Uber had burned through its full-year 2026 AI coding budget in four months. CloudZero’s survey of finance leaders the same spring found that 80% of companies miss their AI spend forecasts by 25% or more. Both Anthropic and OpenAI shipped admin spend controls in June and July, which tells you how many customers asked.

None of this means the spend is wrong. Most of it is the best money an engineering org spends. It means the spend is now large enough to need the same treatment as cloud: attribution, a forecast, and an alert that fires while there is still time to act.

The three questions you are trying to answer

Every tracking setup, however elaborate, exists to answer three questions. Judge any tool against them.

1. Who spent what? Not a total — a breakdown you can act on. By team, so a manager sees their own share. By developer, so the tail is visible. By repository, so you can see that the cost lives in one legacy service and not in “engineering”. By model, so you can tell effort settings and model choice apart from volume.
2. Will we blow the budget? A forecast for the month, from the first days of the month, and a threshold alert that goes to the person who can do something about it — before the overrun, not in the invoice.
3. Why did it spike? When Tuesday cost three times Monday, the reason is usually one of: a model switch, a cache that stopped hitting, a subagent fan-out, or one very long session. You need to get from the spike to that session in a couple of clicks.

Where the numbers actually live

Before choosing a tool, it helps to know where the data is. There are five places, and they disagree with each other.

1. The vendor’s own dashboard

Anthropic gives Team and Enterprise admins a Claude Code analytics dashboard (adoption, accepted lines, a contributor leaderboard, and a spend report export per user and model), and API customers a Console view with daily spend and per-user spend this month. OpenAI’s Global Admin Console shows ChatGPT and Codex credit usage by user, product and model with per-group limits. GitHub has Copilot metrics. Each one is authoritative for its own vendor — and blind to every other one. If your developers use two tools, you have two dashboards and no total. We compare the Anthropic dashboard with CodeCost in detail in CodeCost vs Claude Code Analytics.

2. The invoice

The truth, thirty days late, with no attribution below the organisation. It tells you what last month cost, so it is the number you reconcile against — but it cannot change what this month costs, because by the time it arrives the spending is done.

3. The developer’s machine

Every coding tool writes a session log locally — Claude Code’s JSONL transcripts, Codex’s session files, Gemini CLI’s, and so on. Those files carry, per turn, the model, the input and output tokens, cache reads and writes, timestamps, and the working directory. This is the one place where all tools are recorded side by side. The free single-developer CLIs (ccusage and its family) read these files on demand and print one machine’s totals. CodeCost starts from the same files and builds the org’s cost system on top of them: continuous capture on every Mac, identity and teams, cost by team, developer, repository and model, a month forecast with alerts, role-scoped views, and a privacy boundary that ships only metadata fields; see CodeCost vs ccusage.

4. A gateway on the request path

If every API call goes through a proxy you run (LiteLLM, Portkey, Helicone), the proxy sees every token. This is the standard answer for the LLM calls your product makes. For coding agents it has three problems: every developer has to configure every tool to route through it, subscription-plan usage (a Claude Max seat, a ChatGPT plan) never touches it at all, and the proxy sees prompts and code. More on that in CodeCost vs LLM gateways and observability platforms.

5. OpenTelemetry from the tool itself

Claude Code can export metrics and events over OTLP if you set the right environment variables on each machine and run a collector and a Grafana. It is a good option for a platform team that already has that stack and only needs Claude. It is not org-wide across tools, and it is not zero-config.

Four approaches, compared

What to attribute spend to

“Cost by developer” is what most people ask for first and it is the least useful dimension on its own. A leaderboard of expensive people invites the wrong conversation. Attribute to all four, and lead with the first two:

• Team. The unit that has a budget and a manager. Each manager should see their team’s share and nobody else’s.
• Repository. The unit that explains cost. When 78% of a team’s spend lands in platform/auth-service, the follow-up is about that codebase — its size, its test suite, the refactor it is going through — not about a person.
• Model and effort. The same task at a higher effort setting or on a larger model is the most common cause of a step change that nobody noticed.
• Developer. For the developer themself, first. A budget readout in the menu bar changes behaviour more reliably than a report to their manager.

And one more that people forget: tool. A developer who moves between Claude Code and Codex in the same afternoon is one person with one total. If your setup shows them as two, it is not tracking spend, it is tracking vendors.

Forecast from pace, not from last month

Cloud forecasting leans on seasonality. AI coding spend has almost none yet — it has adoption curves and a heavy tail. The forecast that works is simple and it works from the first days of the month: spend so far, divided by the fraction of the working days elapsed, projected forward, and re-drawn every day. On the 8th of the month it will already tell you whether you are on pace for 90% or 130% of the budget.

Then put an alert on it. Not on the total — on the pace. “On pace for 108%” on the 18th is a message a manager can act on. “You have spent 100%” on the 29th is not.

Why bills spike, and how to read one

When you have the breakdown, spikes turn out to have a small number of causes. In rough order of how often we see them:

• Cache reads stopped. Prompt caching can make the same session five to ten times cheaper. A tool update, a changed system prompt or a long gap between turns can quietly turn it off. Watch the ratio of cache-read tokens to input tokens; when it drops, cost climbs with nothing else changing.
• Subagent fan-out. One task that spawns eight subagents costs like eight tasks. This is often the right trade, but it should be a visible one.
• Model mix. A team that switches its default from a mid-size model to the largest one will double its bill and never mention it, because nothing about their day changed.
• One long session. Context windows are large now. A session that keeps a full window in play for six hours is a real, singular event — and the right response is usually a conversation, not a policy.

The requirement this puts on tooling: from the day’s number you need to get to the session that did it, and from the session to its model, its cache ratio and its subagent count. A total that cannot be drilled into is a number, not an answer.

Decide what you are willing to collect

The most informative signal about why a session was expensive is the prompt. It is also the one thing you must not ship to a third party: it contains your code, your keys, sometimes your customers’ data. Any tracking setup for coding tools should be judged on what it refuses to collect.

The practical standard is a published whitelist: an exact list of the fields that leave the machine, and nothing else. Tokens, model, timestamps, latency, cost, a session id, a repository name — yes. Prompts, responses, API keys, file paths, the developer’s email — no. CodeCost’s list is 36 fields and is printed in full on the landing page and in the privacy policy; whatever you choose, ask for the equivalent.

The second standard is fail open. Anything that sits between the developer and the model can break the developer. A tracking tool that stops your coding tools when it goes down will be uninstalled by the third engineer who hits it, and you will have no data at all.

A checklist

• Every tool your developers use appears in one view, and one person is one total.
• Spend by team, developer, repository, model and tool — with the manager seeing only their team.
• A month forecast from pace, updated daily, with an alert on the pace.
• From any day’s number to the session that caused it, with model, cache ratio and subagent count.
• A published list of exactly what leaves the machine. No prompts, no code, no keys.
• Nothing on the request path. If the tracker fails, the tools keep working.
• Rollout in minutes — an installer or an MDM package — not an environment variable in every shell on every laptop.

Where CodeCost fits

CodeCost is the local-agent approach in the table above. A signed macOS app reads the session files that Claude Code, Claude Desktop, Codex, VS Code, Gemini CLI, OpenCode and Antigravity already write, keeps prompts and code on the machine, and sends 36 metadata fields to a console that shows spend by team, developer, repository and model, with a pace forecast from day one and alerts before the overrun. The CTO sees the org, a manager sees their team, a developer sees themself and a budget in the menu bar. It is not a proxy; if it stops, nothing else does.

It is free during the beta.