Launched this week
CodeBurn
See where your AI coding spend actually goes
123 followers
See where your AI coding spend actually goes
123 followers
CodeBurn is a free, open-source tracker for AI coding costs. It reads the session files your tools already write - Claude Code, Cursor, Codex, Copilot, 40 in all, and shows every token and dollar by the task, model, project, and pull request that used it. The Optimize tab finds waste like cache bloat or retry tax, applies the fix, and tracks what it actually saved. Everything runs on your machine: no account, no uploads. MIT-licensed and genuinely free, used by 150k+ developers across the world.
@iamtoruk this is actually so necessary
CodeBurn
@iamtoruk @lizzy_leonard Glad you find it useful. Try the desktop app as well, it'll show you ways to reduce your spend as well.
CodeBurn
@iamtoruk @tehreem_fatima5 You've touched on a pain we ourselves faced. Set a few agents in loops, and you'll come back to your quota exhausted with no idea what pulled how much. Codeburn shows you that split at a granular level. What session, what activity, what model, so you can track it seamlessly.
the attribution thread in here is the most honest writeup of this problem I've seen, the "unattributed rather than smearing it somewhere plausible" choice especially. curious how this handles fan-out though. I run a lot of orchestration now where one task spins up 5-10 subagents in parallel, each burns its own tokens on its own slice, and only one final step merges their output into a PR. none of those side agents individually "did" the PR, the value only exists at the synthesis step. does codeburn have any concept of a parent task grouping child sessions, or does that show up as several expensive unattributed sessions and one cheap one that happens to touch the PR?
@galdayan really good question, and its the exact case the attribution was built for, so let me be straight about where it works and where it doesnt.
Yes, there is a parent-child concept. when your orchestrator spawns subagents through Claude Code's Task tool, CodeBurn captures each spawn and ties it back to the PR the parent was working on when it fanned out. The side agents' spend folds into that PR, and the parent can be the anchor even if it barely spent anything itself. So your cheap synthesis session isnt "the one that touched the PR" while the real cost floats away unattributed. The PR row shows the parent plus all the folded workers, with a count of how many agent runs rolled in.
Two honest limits though:
it keys on native Task-tool spawning. If your fan-out is a custom harness or separate processes or cross-provider workers, that parent-child link isnt in any single tool's logs, so those fall back to weaker time/directory correlation or land in unattributed.
And it attributes to the PR that was active when the child was spawned. If the workers all run before the PR even exists and it only appears at the merge step, CodeBurn wont retroactively credit that PR with them. It leaves them unattributed rather than pretending the synthesis step "did" work that happened before it. Thats the same principle you noticed.
So the clean case (Task subagents on a branch you cut up front) folds properly. The messy case (the value only becomes a PR after the workers finish, or a mixed orchestrator) is exactly the frontier we are still working on, because that grouping only exists in your orchestrator's head, not in the logs. Genuinely the most interesting problem in this whole thing.
@iamtoruk that's a really honest answer, most tools would've just claimed to solve the messy case too. one thought on it though: since you already have the unattributed pool sitting there, could you run a reconciliation pass after the fact, once a PR does show up, walk backward through unattributed sessions in the same repo/timeframe and offer a "these probably belong to this PR, confirm?" match instead of leaving them orphaned forever? wouldn't need to be automatic or confident, just a suggestion queue. feels like the fuzzy grouping that only exists in the orchestrator's head could partially be reconstructed after the fact even if it can't be captured live
@galdayan nice idea, and it fits better than you would expect: attributions already carry a provenance tag for how they were derived, so a confirmed match slots in as another source rather than a special case.
one correction though, the unattributed pool is aggregated to a number, not kept as sessions, so there is nothing to walk back through yet. Its have to be rebuilt from the session cache.
and the real constraint is retention. Claude deletes transcripts after about 30 days, so walking backward silently stops working past that window. Better to snapshot the candidates eagerly while sources exist, then reconcile against that later.
The part I would be careful about: this relaxes a bound that exists for a reason. Unbounded directory correlation once put 129 of 131 sessions on one PR here. A human gate is safer, but if the queue is usually right, people start clicking yes on reflex, so it has to stay small and show its evidence.
Filed an issue (https://github.com/getagentseal/codeburn/issues/990). Thanks for thinking it through.
@iamtoruk that 129-of-131 story is the kind of thing that should be on the landing page honestly, it's a better trust signal than any marketing copy. makes sense on the snapshot-eagerly point too, that's basically the same lesson as the parent-child fan-out case - capture the structure while it's cheap to capture, because reconstructing it later is either expensive or a guess. filed issue read, thanks for actually running with it instead of just nodding along.
CodeBurn
I came to CodeBurn from a somewhat unusual direction.
I spent years in strategy and venture investing looking at companies deploying AI, and later moved into an operating role partly because I wanted to understand the problem from inside an enterprise.
Then I started building with coding agents all day myself, and one thing became very obvious: provider dashboards are good at telling us what we consumed. They are much worse at telling us what the consumption actually accomplished.
Resham had already been attacking that problem with CodeBurn. What immediately interested me was how much ground-truth information was sitting locally in agent sessions and git history.
Which project used the money?
What was the agent actually doing?
How many times did it retry?
What did it reread?
Did any of that work become a commit or PR?
That is the layer we're building out.
The longer-term question we're particularly interested in is cost per useful unit of AI work, rather than cost per token.
For this launch, I’d especially love feedback from people who use multiple coding agents heavily:
What do you still feel blind to? What metric would actually make you change how you use your agents?
I’ll be around here all day. Looking forward to your inputs.
@adityavsingh Honest answer: I can see what a session cost. I have no way to see what it bought.
Most of my spend is not in the PR. It's the hour before it, where the agent reads the wrong files, I stop it, rewrite the prompt, start over. On a dashboard that's retry tax. But a good chunk of it is me working out what I actually want, and then the PR takes ten minutes. So cost per merged PR would make the messy session look awful and the clean one look great, when the messy one is what paid for it.
The metric I'd act on is one where the throwaway sessions get attributed to whatever they eventually produced. Right now I look at the weekly total and shrug.
Separate question: if one session touches three repos, where does the cost land?
@adityavsingh @dimhold the messy hour before the PR: mostly covered, with limits. Attribution is not "sessions that mention the PR". session that never references the PR but ran in the same checkout during the same working stretch gets folded into that PR (we bound it to a window of several hours around the PR-linked work, because unbounded folding turned whole repos into black holes and we learned that on our own data). Throwaway runs also fold in a second way: if you stop an agent and relaunch the same prompt in another tool, the relaunch is correlated back to the same PR. So the messy session that paid for the clean ten-minute PR lands on that PR, not on "retry tax".
the honest limit: this is a same-working-stretch claim. The thinking you spread across three evenings before you ever opened the repo does not fold in, and I do not currently have a way to attribute it that would not be guessing. When we cannot attribute, we show it as unattributed rather than smearing it somewhere plausible.
three repos in one session: cost lands per turn, not per session. PR references attach to individual turns, so the turns you spent in repo A are attributed to repo A's PR, and the same for B and C. A session is not an attribution unit, it is a container. turns with no evidence stay unattributed, again rather than being guessed onto whichever repo the session started in.
@adityavsingh @iamtoruk Thanks, that answers it. Per turn instead of per session is the right call, and so is leaving the rest unattributed. I'd rather see a gap than a number that got put somewhere plausible, because the plausible one is the one I'd act on. The three-evenings case I don't think is recoverable at all, it never touched a log.
CodeBurn
@dimhold That wrong file reading and rework you mentioned, that's something we're actively working to curb. Could you share more about that? What seems to worsen it, is it more with some specific models, or on types of tasks?
@adityavsingh The worst case for me is when the agent decides the answer doesn't exist. I asked one to change how our churn denominator works. It found the calculation quickly. Then about thirty files trying to work out whether that denominator is right. It told me the repo can't answer that, because the source of truth is a spreadsheet it can't read.
The spreadsheet is a zip and the formula is sitting in the XML inside it. The agent never tried. And the formula matched what the code already does, so the right answer was to change nothing.
On models I was going to say the cheap ones give up sooner, but my own run doesn't support it. Thirty files is not giving up. It searched plenty and still called the thing impossible. Nothing made it try the next move, which was to unzip the file and look. So I'd look at the type of task first, the ones where the answer lives outside the code.
Which is the same shape as the messy hour I described earlier. That was reading and no commit too, and it paid for the ten-minute PR after it. This one was reading and no commit and a wrong answer. From the outside they look identical. What separates them is how it ended.
So the measurement has to be about the ending. The one I'd watch is how often a session ends by declaring something impossible. Next to it, how often a confident answer turns out wrong, or pushing the first one alone just teaches it to stop saying no.
The first is already in the sessions you read, with one catch. Agents rarely write "impossible". They write "you may want to confirm this" and hand the task in as done. Whether it asked you anything before giving up is in the same place and costs nothing. I wouldn't try to score how many of the blockers were right, though. Checking one means going and finding the answer myself, and by then I have it and don't need the number.