Quick question about your last pull request: what did it cost?
Not in hours - in tokens. In money. If your team codes with AI agents, that PR had a bill. Somebody paid for the model calls that researched the bug, drafted the fix, wrote the tests, and generated the description. Do you know the number? Even roughly? Within an order of magnitude?
Almost nobody does. We track cloud spend to the cent, we argue about a $30 SaaS seat - and then we adopt tools that cost real, variable money per task and ship for months with zero idea what anything costs. That blind spot is about to become expensive, and closing it is surprisingly easy.
The invoice era has arrived
For a while, AI coding costs hid inside flat subscriptions. That era is ending. GitHub is moving Copilot to usage-based billing, metering actual token consumption at per-model rates - and the agentic tools most of us use daily already work this way. Realistic numbers in 2026: $200 to $2,000+ per engineer per month in usage-based costs for heavy agentic workflows, with individual agent tasks running anywhere from a few cents to a dollar and beyond.
The industry has noticed. The FinOps Foundation reports that 98% of organizations now actively manage AI spend - up from 31% just two years ago - and names AI cost management the number-one skill gap in the discipline. Meanwhile, analyses of AI ROI keep landing on the same caveat: the productivity claims only hold up when spend is attributed to the outcomes that produced it.
And that is exactly what almost no engineering team does. Spend is tracked - if at all - as one monthly blob on a dashboard nobody opens. Which features were expensive? Which workflows burn tokens without shipping anything? Nobody can say.
Why the pull request is the right unit
You could attribute AI costs per developer, per team, or per month. I attach them to the pull request - and I think that is the only level where the numbers become useful:
- A PR is an outcome. “We spent $1,400 on tokens this month” is trivia. “This refactoring PR cost $9, that feature cost $3, and the failed spike cost $40” is information you can act on.
- It builds trust upward. When management asks whether the AI budget is worth it, “here are the last 50 PRs with their costs next to the outcomes” ends the discussion. Gut feeling does not survive budget season; receipts do.
- It exposes waste where you can fix it. Cost per outcome makes patterns visible: the workflow that re-reads the entire codebase every session, the task type where the agent spins in circles, the model that is overkill for mechanical edits.
- It keeps everyone honest about the multiplier. I claim AI is a multiplier. A number on every PR is me putting evidence where my mouth is.
How mine works
My setup is deliberately boring - a small shell script and a hook, no platform, no vendor:
- During work, the AI tooling writes session transcripts locally (most agentic CLIs do, or expose usage per request).
- On PR creation, a script aggregates the session: input/output tokens per model, cached versus fresh, and multiplies by pinned per-model rates. The result is a small markdown table appended to the PR body.
- On session end, a hook appends one row per session and model to a cumulative CSV log - the durable record that outlives transcripts.
The PR table looks like this:
### AI usage (this session)
| Model | Input (cached) | Output | Est. cost |
| ------- | -------------- | ------ | --------- |
| model-a | 2.1M (87%) | 41k | $3.12 |
| model-b | 310k (12%) | 9k | $0.87 |
Session: content-pipeline-refactor · type: build · PRs opened: 1And because every session lands in the CSV, the retrospective questions become one awk away: cost per project this quarter, cost per month, research sessions versus build sessions, which initiatives ate the budget.
What the numbers changed
The surprises started in week one. A few things I only learned because the bill was attached to the outcome:
- Research is cheap; repetition is expensive. Long exploratory sessions cost less than expected thanks to caching - while repetitive mechanical loops (regenerate, fail, regenerate) quietly burned multiples of that.
- The expensive PRs were rarely the important ones. The correlation between cost and value is weaker than you would guess - which is precisely why you want to see it.
- Session hygiene matters. One sprawling everything-session is harder to attribute (and usually costlier) than focused sessions per task.
None of this was visible in the monthly blob. All of it is visible per PR.
The honesty rules
If you copy one thing, copy the caveats - they are what keep the numbers trustworthy instead of theatrical:
- Estimates, not invoices. Rates are pinned in the script and drift from the vendor’s pricing page. Label the numbers as estimates; update the table when pricing changes; report “n/a” for unknown models instead of silently charging zero.
- Session ≠ PR. A session can open three PRs, or none. My reports state the scope (“this session, up to PR creation”) and flag multi-PR sessions rather than pretending precision.
- Never in commit messages. Commits happen mid-work, so any number there is a partial count - and a squash merge collapses several into one misleading figure. The PR body is the correct place.
- Count the cache. Cached input tokens cost a fraction of fresh ones. A report that ignores caching overstates cost dramatically and teaches the wrong lessons.
Start smaller than you think
You do not need a FinOps platform to get 90% of the value. Version one is an afternoon:
- Find where your tooling exposes usage (transcript files, a usage API, response headers).
- Write the twenty-line script that sums tokens and multiplies by a pinned rate table.
- Append the output to your PR description - manually at first, via hook once it sticks.
- Add the one-row-per-session log when you start wanting trends.
The point is not accounting perfection. The point is that the person who wrote the code, the person who reviews it, and the person who pays for the tools all see the same number, in the same place, attached to the same outcome.
Receipts
Imagine an employee with a company credit card who never files an expense report. Not fraudulent - just opaque. Every month, finance sees one lump sum and has to take on faith that it was all worth it. Eventually, faith runs out - usually in the budget meeting where someone asks “what are we actually getting for this?” and nobody has an answer.
Now imagine the same card with a receipt stapled to every purchase: what it was for, what it produced. Same spending. Completely different conversation - because every euro has a story, and wasteful patterns show up in weeks instead of years.
AI tokens are the company card of engineering right now, and most teams are not filing expense reports. Staple the receipt to the pull request. It is the difference between “trust me, it’s worth it” and “see for yourself” - and between a budget that survives scrutiny and one that gets cut the first time money is tight.