One of the major challenges in the transition to agentic coding is being able to tell if the usage of these techniques is ROI positive. And in an environment where each new model release comes with higher token costs, and an industry claiming we are heading towards a compute crunch, having a clear insight into the costs of agentic coding is necessary. Uber famously spent their annual AI budget in months and had to set limits.
The problem is that no-one currently provides a turnkey solution that lets you say “Here is the feature, and here is what agents cost us to build it”. But most of the pieces to do that are already in place, and depending on how your developers work, there might be a path to building (or getting agents to build) that reporting.
We’re not going to show you how to build such a system, but we are going to give you a quick overview of what’s available and links to more detailed information and guides that you, or your agents, can use.
And we’re going to start with the problem.
The problem of AI attribution
There are two reasons you can’t currently answer “what did that feature cost?”.
Subscriptions are opaque already, but once you’re past a few seats, you pay per token. Anthropic’s Enterprise plan meters every token on top of the seat fee, and OpenAI and GitHub have moved the same way. GitHub shifted every Copilot plan onto usage-based billing in June 2026. The flat subscription is on its way out.
The second is that the providers don’t tell you the cost. When a tool calls a model, the response reports the number of tokens used, not a dollar figure. You have to multiply those token counts by the current price list yourself. The exception is OpenRouter, which sits in front of the models and returns the actual cost on each call, but their services charges a fee of around 5% of your token spend.
So your monthly total is easy to find, but the cost of a single feature or bug fix is not. No mainstream tool joins spend to a unit of work today.
Without a per-unit cost you can’t work out your ROI, you can’t price a feature or settle a build-versus-buy question on real numbers.
What you need is two things for each piece of work: what it cost, and what it was for. You capture both when the agent runs, then join them afterwards. How far you can take that depends on where your developers work.
Cost attribution depends on where your developers work
Whether the money leaves through a terminal, an IDE, or your own code decides how precise your answer can be.
Terminal agents
If your developers use a terminal-based agent like Claude Code, OpenAI Codex, Amp, pi, etc, you have the most room to move. These tools let you set the endpoint they call, so you can send every request through a gateway that sits between the agent and the model and prices each call and records whatever label you attach. LiteLLM, Helicone and Cloudflare AI Gateway all do this, and the first two you can host yourself.
LiteLLM is the closest thing to an off-the-shelf answer. You point the agent at it and pass a customer id or a tag on each request, and it prices the call and files it under that tag. There is a walkthrough for doing exactly this with Claude Code.
Helicone works the same way, and lets you segment cost by custom properties you set on each request, so your branch or ticket becomes a filter in its dashboard.
Cloudflare AI Gateway is the managed option if you would rather not run anything. It logs the cost of every request and lets you filter on it, though you get less control over the labels than with the other two.
If your team uses Claude Code, you don’t need a gateway at all. It can export its usage over OpenTelemetry, an open standard for emitting metrics that dashboards can read, and it will attach whatever labels you give it to each cost figure. That is the simplest way to get a labelled, priced record without adding a service to the path, and if you want a running start there is an open-source setup, claude-code-otel, that wires the export into ready-made dashboards.
IDEs: Copilot, Cursor, VS Code
Inside an IDE, how much you get back depends on the editor and, more than anything, on whose models you are paying for.
GitHub Copilot has two modes here. Run it on GitHub’s own models and you get spend per user, per day and nothing finer, with the pull requests its agent opens folded into that daily figure. But Copilot also lets you bring your own provider key or a custom endpoint, and once you do, the spend leaves GitHub’s meter and lands on your provider account, or on a gateway you point it at. That puts you back in the terminal case, with a priced, labelled record per call.
Cursor keeps you on its own billing for agent work, so you are limited to what its APIs expose. Its Admin API reports cost per request, and its AI Code Tracking maps AI-written lines to the commit they landed in. The two sit apart, though. Nothing shared joins a dollar amount to a given commit or pull request, so a per-feature figure still has to be stitched together by hand.
VS Code gives you the most direct way to do the Copilot trick above. It has a setting to point it at your own model endpoint, which you can aim at one of the gateways from the terminal section.
Your own harness
If your team has built its own harness around the models, this is straightforward. You own the call, so you record the cost and the label together. It is one reason teams that care about attribution keep a thin harness of their own.
Labelling the work
A number on its own isn’t much use until you attach a label to it: a branch, a ticket, a pull request, a developer, whichever unit your team works in. If you ship a feature per branch, use the branch. If you run everything through Jira, use the ticket. Match it to how your team already divides the work.
Both of the mechanisms above take a label. A gateway reads it from a header on the request, and Claude Code’s telemetry takes it as an attribute you set before the run. So the practical trick is a one-line wrapper around the command your developers already use to start the agent. It reads the current git branch and sets that header or attribute for them. Nobody has to remember to tag anything, and the branch ends up on every cost record, ready to join to a pull request and a ticket later.
It doesn’t change how your developers work, which is the point.
How far do you need to go
There are three levels, and the right one depends on what your team will actually keep running.
The cheapest is an estimate. You divide your total AI spend by the number of pull requests you merged and call it a rough cost per PR. That is what DX’s AI cost report gives you: a useful trend line, and an average that tells you nothing about any particular feature.
Building it yourself is the only route to a real per-feature number. You carry the label with the spend using the pieces above, then join branch to pull request in your own database. It is a couple of hundred lines of work, and no-one sells it as a product yet.
Buying help gets you part of the way. Engineering-intelligence vendors like Faros will pull your AI spend together and attribute it by team, tool and type of work, which is enough for budgeting and for seeing where the money goes. What they won’t hand you is a dollar figure against a single feature or pull request.
No tool will point at a feature and tell you what it cost. What you can do is decide how close you need to get, and pick the level of effort that matches.
Is AI cost attribution worth doing?
Before your team builds anything, you need task yourself three questions.
What would you do differently if you knew the cost of a feature? If the answer is nothing, leave it, keep an eye on the monthly total and keep doing what you’re doing.
Where do your developers work? That decides what your options for AI cost tracking and your accuracy before you start.
And how accurate does that number actually need to be? For a rough sense of it, count your merged pull requests and divide your AI spend by them. Stick the numbers in a spreadsheet and after a few months you will be able spot the trend, but not learn anything about a particular feature. For a cost you can put against an actual feature, you are into the small build of your own from the last section. Do whichever is worth your while.
The cost attribution gap is real, but we expect it to be temporary. Vendors will close it in time. Until they do, the teams that get useful numbers are the ones that put basic tracking in place: tagging the work, logging the spend, and integrating the numbers into reporting and decision making.
