How much is your team spending on AI coding tools?

The three numbers, and why they disagree

Almost every argument about AI tool spend is two people quoting different numbers at each other. Finance has invoices. Engineering has telemetry. Neither is wrong and they will never match, because they measure different things.

The third row is the one worth understanding, because it is both the most useful and the most easily oversold. It is an API-equivalent estimate that each tool calculates for itself. It is not your bill. It cannot be reconciled to your bill, it will not agree with your bill, and a vendor who implies otherwise is hoping you do not check.

What it is good for is proportion. Which team, which repository, which model, which week. Invoices cannot answer any of those, and no amount of accounting will make them.

What each tool actually reports

Coverage is uneven, and the unevenness matters more than the averages.

• Claude Code reports claude_code.cost.usage, a counter in USD that Anthropic documents as the cost of the Claude Code session. That is a real per-session number you can group by user, and it is a tool-side calculation rather than a billed amount.
• Cursor's Admin API has /teams/spend, which returns per-user spend for the billing cycle. That is actual money. It is the best Cursor cost source that exists, and endpoint telemetry cannot match it, because Cursor's hook payloads carry no cost figure at all.
• Codex CLI usage rolls up into aggregated Codex usage and activity metrics for a ChatGPT workspace, for the sessions that authenticated into that workspace and no others.

Say the uncomfortable half out loud: an endpoint agent that reports a dollar figure for Cursor is either calling Cursor's Admin API behind the scenes or inventing the number. Synopt does neither, so every Cursor event it stores contributes $0. Get Cursor spend from Cursor.

How do you calculate cost per developer?

The numerator is the easy part. The argument is always the denominator, and picking it is a decision about what question you are answering.

Compute at least the first two and put them next to each other. Where they diverge is your adoption story, told in the only units a CFO reads without being asked twice.

Where the money usually is

Four places, roughly in order of how much they pay back for the effort of finding them.

• Seats nobody used. Subscription seats with zero events in the window. This needs no cleverness, only a seat list joined to an activity list, and it is reliably the highest-yield number in the category.
• Model mix. The same task on a frontier model and on a cheaper one differ by an order of magnitude. Grouping tool-reported cost by model tells you whether anyone is choosing, or whether everyone is on whatever the default is.
• Concentration. A handful of people usually account for most of the spend. That is often correct and worth knowing anyway, because it turns a budget conversation into a specific one.
• Repository. Cost grouped by repo tells you which codebase is expensive to work in, which is a code-health signal wearing a finance costume.

What Synopt shows for this

A cost view with estimated total cost, total tokens, estimated cost per active user and active users, sliced by team, model, tool and day. Plus a Monthly AI Spend & ROI report built for finance, which adds estimated total spend, subscription seats at monthly list rate, estimated metered spend, idle seats, estimated cost per active user, and tokens per dollar.

Idle seats is the one to look at first. It is defined as subscription seats with zero events in the window, and it is the only number on that page that turns directly into a cancelled invoice line.

Printed on the report itself, not buried in a footnote: cost figures are estimated API-equivalent rates reported by each tool, not billed amounts.

Can you calculate ROI from this?

No, and it is worth being blunt about it. Nothing here measures output quality, delivery speed or business value. Tokens per dollar is an activity-per-dollar proxy and it is labelled as one. There is no code-output metric and no outcome metric in this data, so any ROI figure derived from it is an assumption with a decimal point stuck on the end.

What you can defend in a budget meeting: total spend, the trend, who is using it, which seats are idle, and the cost of the work per team. That is a stronger position than a fabricated multiplier, and it survives being questioned.