Launching today
CodeBurn
See where your AI coding spend actually goes
106 followers
See where your AI coding spend actually goes
106 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.
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.
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?