Why your provider dashboard cannot track AI token spend by project
If you have ever opened the Anthropic Console at the end of the month, seen one large number, and had no idea which of your four repos caused it, you have already found the problem. Billing is organised around the thing the provider charges: an account, an API key, a workspace. Your projects are organised around repos. Nothing in the request tells the provider which repo you had open.
Quick Answer
To track AI token spend by project, you need per-session records that carry three things at once: which model ran, the token counts split by pricing tier (fresh input, cached reads, cache writes, output), and the repo or project the session was actually working in. Provider dashboards give you the first two at organisation level and never the third, which is why most developers end up dividing one monthly bill across projects by feel. The reliable options are one API key per project, an LLM gateway that tags every request, or a tracker daemon that reads agent sessions and attributes them to the repo they ran in. Below: a comparison of five methods and where each breaks, plus real numbers from my own 13,674 dollar month showing how far a gut-feel split can miss.
It gets worse with coding agents specifically. Claude Code on a Max plan, Cursor on a Pro seat, and Codex on a subscription all bill flat, so the console shows no per-session dollar figure at all. The usage is real and the cost is real, but the dollar attribution has to be reconstructed locally from the session's own token counts and current model prices. This is usually the point where people give up and allocate by headcount or by vibes.
There is a third wrinkle that catches almost everyone. Token counts are not one number. A cached read costs roughly a tenth of a fresh input token, and a cache write costs more than one. Over the 30 days I measured, about 96 percent of my token volume was cache reads, and output tokens were under half a percent of the volume while carrying a large share of the bill. Any allocation that divides a bill by raw token count is therefore wrong before it starts.
Five ways to get per-project token cost, compared
Most people pick a method based on what they can set up in an hour, then discover the gap three months later when a client asks what their project cost. Here is what each approach actually gives you and the specific place it fails.
| Method | What you get | Where it breaks |
|---|---|---|
| Provider console (Anthropic, OpenAI usage pages) | Accurate dollars per organisation and per API key, daily grain, zero setup | No project dimension at all. Agents on subscription plans show no dollar cost. Retention on usage exports is limited |
| One API key per project | Clean per-project dollars with no parsing, works with any provider | Breaks the moment an agent runs on a subscription rather than a key. Key sprawl, forgotten switches, and shared keys quietly poison the split |
| Agent session logs on disk (Claude Code JSONL, Codex, Cursor) | Per-session token counts, already on your machine, free | No prices attached. Model IDs change under you. No repo dimension unless you parse each session's working directory yourself, and you own that parser forever |
| LLM gateway or OTel proxy (LiteLLM, OpenLLMetry) | Per-request tokens and cost with whatever tags you attach, including project | Only sees traffic you routed through it. Coding agents on vendor subscriptions bypass it entirely, so your production LLM calls are covered and your Claude Code sessions are not |
| Tracker daemon that attributes sessions to repos (DevClocked) | Per-project, per-model cost tied to the sessions and commits that produced it | Needs the daemon installed. Aimed at developer agent sessions, not your backend's production inference traffic |
The split that matters in this table is between methods that see the *request* and methods that see the *session*. A gateway sees requests and knows nothing about your repo unless you tell it. A session-based tracker sees the working directory and the git repo, so the project dimension comes for free and the cost has to be computed from model prices. Neither covers both sides, which is why teams running production inference plus agentic coding usually end up with a gateway for the former and a session tracker for the latter.
What a real month looked like
Full disclosure: I build DevClocked, so I have this data on myself. These are my actual numbers for 21 July to 19 August 2026, across all coding agents, pulled from my own per-project cost report.
Total spend was 13,674 dollars across 9.9 billion tokens. Two projects dominated, anonymised here as Project A and Project B:
| Project | Cost | Tokens | Agent work blocks | Cost per block |
|---|---|---|---|---|
| Project A | $5,450 | 3.49B | 272 | $20.04 |
| Project B | $3,088 | 2.08B | 307 | $10.06 |
| Everything else | $5,137 | 4.34B | ~342 | varies |
Look at the middle two columns before the money. Project B ran *more* agent work blocks than Project A, 307 against 272, and cost 2,362 dollars less. Per block it was half the price. The reason is model mix: Project A leaned on the expensive frontier model for architecture and migrations, while Project B did far more of its volume on a cheaper model and spent 269 dollars on GPT-5.6 where Project A spent 3 dollars 82. Session count is a terrible cost proxy, and this is why.
Now the allocation error. Project A was 35.2 percent of my token volume and 39.9 percent of my cost. If I had done the obvious thing and split the bill by token share, about 640 dollars would have landed on the wrong project in a single month. On a client bill that is not a rounding error, and it compounds every month you keep doing it.
One more detail worth copying. About 13.9 million tokens came from models with no price entry (an auto-review model and one unidentified session), and my report flags them as unpriced rather than counting them as zero. A tool that silently prices unknown models at nothing will report a total that looks clean and is quietly low. In practice, an honest unpriced flag is more useful than a tidy number, because it tells you exactly which gap to close.
How to set this up
Most developers want this working before the next invoice, not as a quarter-long project. Here is the order that gets the most accuracy per hour spent.
- Decide what question you are answering. Budget control ("am I about to blow 500 dollars this week") needs alerting and daily grain. Client billing needs per-project accuracy and an audit trail. Model selection ("is the expensive model earning its keep on this repo") needs per-model breakdown inside each project. These want different setups, and picking one keeps you from building all three badly.
- Split by API key wherever you control the key. This is the cheapest real win. If a project has its own backend inference, give it its own key today. It costs nothing and it makes that slice of spend exact at the provider level. It will not help with your coding agents, which is the next step.
- Capture agent sessions with the repo attached. Claude Code, Codex, and Cursor each write session data locally with token counts in it. The piece that turns those into per-project cost is the working directory, resolved to a git repo and then to a project. You can parse this yourself, and some people do. A tracker daemon that already normalises repo names, handles worktrees, and maps repo aliases to one project saves you from maintaining that mapping by hand as repos get renamed and moved.
- Price by tier, not by token count. Multiply each tier by its own rate: fresh input, cached read, cache write, output. Given cache reads were 96 percent of my volume, this single step is the difference between a plausible number and a wrong one.
- Set it against what shipped. Cost alone is half a calculation. Once spend is attributed per project, put it next to the hours and the shipped output for that same project, which is the whole subject of measuring the ROI of AI coding assistants. A project burning 5,000 dollars a month is fine if it shipped the release, and alarming if it produced three reverted branches.
You will often see step 5 skipped, and that is the step that turns a cost report into a decision.
Where DevClocked fits
If you run one project and one API key, skip all of this. Your provider console already tells you what you spent, and the answer to "which project" is the only project you have. Equally, if the spend you care about is production inference from your backend rather than your own coding sessions, a gateway like LiteLLM with project tags is the right tool and a developer tracker is not. I would rather say that plainly than pretend one tool covers every LLM bill you have.
Where DevClocked earns its place is developer agent spend across several repos. The daemon reads token usage and model costs out of Claude Code, Codex CLI, and Cursor sessions and attributes them to the project the session was working in, so per-project and per-model cost is a first-class report rather than something you reconstruct in a spreadsheet. It sits alongside the session tracking, work blocks, AI-versus-human attribution, and the Leverage Score, which means the cost line for a project sits next to the hours and the output for that same project. Git alone cannot tell you any of this. Your commit history knows a diff landed, not that the diff cost 40 dollars in cache writes on a frontier model.
A single monthly invoice split by memory is a claim about where your money went. A per-session record carrying model, tier, price, and repo is proof of where it went, and the two disagree by hundreds of dollars a month in my own data. That gap is the entire reason to instrument this rather than estimate it.
If cost control is genuinely all you need, a dedicated agent-spend tool does that job well and is a smaller commitment. Tokscale is built for exactly that, and our head-to-head on DevClocked and Tokscale is honest about where each one stops. Editor-time trackers are the other half of the confusion: DevClocked compared with WakaTime covers why hours-in-editor data has no cost dimension at all.
Common mistakes
The first is allocating a shared bill by token share. My own month shows a 640 dollar error from doing exactly that, because different projects run different model mixes at different prices per token.
The second is treating a session count or an hour count as a cost proxy. Project B ran more agent blocks than Project A for less than half the price per block. Time and money diverge as soon as your model choice varies by task, and it always does.
The third is counting unknown models as zero. Every provider ships new model IDs faster than pricing tables get updated, so there is a permanent tail of usage your table does not recognise. Flag it, do not absorb it.
The fourth is stopping at cost. Token spend is an input. Without the output side, you have a denominator and nothing above the line, which is the same trap covered in how to track Claude Code usage.
