Attribution is just connecting spend to the people and the work that created it. For coding agents, that means taking a pile of token consumption spread across several vendors and answering one precise question: who ran this, on what, and to what end. Get it right and every other decision about coding agent cost opens up. Get it wrong and you're left with one big number nobody owns.
Here's how I'd actually do it.
Why is attribution the hard part?
Because coding agent spend is born detached from everything you'd normally use to attribute it. Cloud cost has resources and tags. A coding agent has a developer at a keyboard, a vendor invoice in the vendor's own units, and not much in between. There's no instance to label, no account boundary that maps to a team, no tag you set when something gets provisioned. The spend shows up as usage, and usage doesn't come pre-sorted by team, project, or outcome.
That's why attribution, not visibility, is where most efforts stall. Seeing the total is the easy part. Splitting it into shares the right people recognize as theirs is the actual work.
The levels of attribution
Attribution isn't one thing. It's a ladder, and most teams climb it a rung at a time.
- Organization. The total across every tool, in consistent units. This is the floor. It tells you the size of the problem and nothing about its shape.
- Team. Spend mapped to the groups that can act on it. This is the first rung that changes behavior, because a number a team recognizes as its own is a number a team will manage.
- Project. Spend mapped to the work, not just the group. Now you can compare the cost of initiatives, not just cost centers, and finance starts to see a budget with structure.
- Outcome. The hard rung. Spend set against what the work produced, the features shipped, the issues resolved, the value delivered. This is what turns "this team spends a lot" into "this team spends a lot and it's worth it," or the reverse.
Each rung depends on the one under it. You can't attribute to projects if you can't attribute to teams, and you can't talk about outcomes until the spend beneath them is already mapped.
What data you need
Three things, in order of difficulty.
First, identity. A reliable link between usage and the person or service account that generated it, across every tool. Vendors expose this differently, which is the first place a single-tool approach breaks.
Second, a mapping from identity to team and project. This is org data, who's on which team, which teams own which projects, kept current enough to trust. Stale mappings are the most common reason people stop believing the numbers.
Third, for the top rung, a link to the work, so cost can be set against output. This is the newest and least standardized of the three, and it's where dedicated tooling earns its keep.
The ways it usually goes wrong
Attribution tends to fail in a few predictable ways. Knowing them is half the battle.
- Tool-by-tool silos. Attributing inside each vendor's console separately and never reconciling. You end up with five partial pictures and no whole.
- Stale mappings. Identity-to-team data that drifts out of date, so the numbers are technically attributed but no longer correct. People stop trusting them, and trust is the whole point.
- Stopping at the org total. Treating the consolidated number as the finish line. The total tells you the size. Only the breakdown tells you what to do.
- Attribution that slows developers down. Schemes that make engineers tag every session or pick a project before every prompt. They fall apart almost immediately, because they tax the work just to measure it. Good attribution is inferred from data you already have, not collected by hand.
Why attribution is the bridge
This is the part I want to land. Visibility tells you the number. Optimization changes it. Attribution is the bridge between them, because you can't optimize a number you can't assign. "Spend is high" isn't something anyone can act on. "This team is running a frontier model for routine work" is, and the only thing that turns the first sentence into the second is attribution. That's why it's worth getting right even though it's the hard part. Every saving downstream rides on it.
How we approach it
TokenShift attributes coding agent spend across Claude Code, Codex, Cursor, Copilot, and Devin Desktop to teams and projects, in consistent units, and ties it back toward the work it produced, without asking developers to tag anything by hand. The attribution is inferred from the data, kept current, and read the same way by engineering and finance. From there the saving is a decision, not a guess.
FAQ
What's the difference between showback and chargeback for coding agents? Showback shows each team its own attributed spend without moving money. Chargeback actually allocates the cost to the team's budget. Showback is usually the first step, since it changes behavior through visibility, and chargeback follows once the attribution is trusted. Both depend on the same underlying mapping.
How do I attribute coding agent costs without slowing developers down? Infer attribution from data you already have, identity, team membership, project ownership, instead of asking engineers to tag sessions or pick projects by hand. Hand-collected attribution decays fast because it taxes the work. Inferred attribution scales because it doesn't.
Can I attribute coding agent spend to outcomes, not just teams? It's the hardest rung and the most valuable. It means linking spend to the work it produced, which is newer and less standardized than identity or team mapping, and it's where dedicated tooling helps most. Most teams reach team and project attribution first and build toward outcomes from there.