I use more than one AI coding tool.
A task might begin in Claude Code, move through Codex, involve a few delegated agents, and finish with a manual cleanup in the editor.
At the end, every tool can tell me that tokens were used.
None of them could answer the questions I actually had:
- Which project consumed them?
- Which sessions became expensive?
- Did the expensive model produce better results?
- How much work went into a particular pull request?
- How much was spent retrying or reworking the same files?
- Are my subscription plans keeping up with my real usage?
- What happened in delegated subagent sessions?
The data needed to answer many of these questions already existed on my machine. It was just scattered across JSONL files, SQLite databases, editor storage, agent transcripts, and provider-specific caches.
That became CodeBurn.
CodeBurn is an open-source, local-first tool that reads this existing session data and turns it into a desktop application, terminal dashboard, local web dashboard, CLI, and MCP server.
This post focuses on the desktop app and what the different screens are actually useful for.
The overview is meant to answer “what happened?” before making you dig through individual sessions.
Start with the shape of your usage
A monthly API bill is one number. It tells you almost nothing about how it happened.
The Overview screen breaks activity down by day and shows:
- Total estimated spend
- Number of sessions and calls
- Model usage
- Daily changes
- Expensive sessions
- Potential waste
- Recent workflow activity
The expensive-session list is often more useful than the total.
A normal day can contain ten small sessions and one agent run that quietly consumed most of the budget. Seeing that session immediately gives you somewhere concrete to investigate.
This is also where differences between tools become visible. You may discover that one provider handles quick fixes cheaply while another dominates longer planning or refactoring sessions.
A session list is more useful when it has context
The Sessions screen is a searchable history of actual agent work.
Instead of presenting raw transcript identifiers, CodeBurn tries to retain useful context such as:
- Session title
- Project
- Provider
- Models used
- Start and end time
- Number of turns and calls
- Estimated cost
This helps when a number on the Overview page looks suspicious.
If Tuesday was unusually expensive, you can move from the daily total to the sessions responsible for it. From there, you can distinguish a genuinely large implementation from a short task that got stuck repeating itself.
The goal is not to judge a session because it was expensive. Some difficult tasks should be expensive. The useful part is being able to connect the cost to the work.
Attribute agent work to pull requests
The feature I wanted most was pull-request attribution.
The Pull Requests screen groups work around the PR where it happened.
For each pull request, it can show:
- Attributed spend
- Models used
- Linked sessions
- API calls
- Active dates
- Work-category breakdown
- Delegated subagent runs
This becomes interesting when agents delegate work.
A parent session might use one model for orchestration while several subagents use other models for investigation, testing, or implementation. Looking only at the parent makes the PR appear cheaper than it actually was and hides the models that performed most of the work.
CodeBurn folds linked subagent activity into the parent turn that launched it. Nested agent runs are included as well, while safeguards prevent the same work from being counted twice.
Attribution happens at turn level. If one long session works on multiple PRs, each turn is associated with the PR it was working on rather than charging the entire session to every PR.
It also correlates cross-provider work where enough local Git and session context exists. That matters when one tool starts the work and another tool continues it in the same repository.
The result is a much more useful question than “What did AI cost this month?”
It becomes:
What did AI-assisted work on this change actually involve?
Spend is not only about models
The Spend view provides several different lenses:
- Projects
- Activity categories
- Tools
- MCP servers
- Subagents
- Model-to-project flow
These breakdowns expose patterns that a model-only report misses.
For example, a project may be expensive because it genuinely contains most of your work. But it might also be expensive because the agent repeatedly searches the repository, runs a failing command, or revisits the same files.
Tool and MCP breakdowns can also reveal how an agent is approaching the task. Two sessions with similar token totals can represent very different workflows: one may spend most of its time editing and testing, while another spends it searching and rereading context.
Measure retries instead of guessing about quality
Cost alone does not tell us whether a model was effective.
CodeBurn classifies work into categories such as coding, debugging, testing, planning, documentation, review, and research. For edit-oriented work, it also tracks file-aware retry cycles.
A retry is not simply “the agent used the Edit tool twice.”
It is closer to this pattern:
- Edit a file
- Run a command
- Return to the same file
- Edit it again
Editing several different files during an implementation is normal. Repeatedly returning to the same file after validation failures is a stronger signal that the first attempt did not work.
From that, CodeBurn can calculate a one-shot rate: how often an edit succeeded without needing another correction cycle.
It is not a perfect software-quality metric. It is a workflow signal.
But it makes model comparisons more meaningful than comparing token prices alone.
Compare models using the work they performed
The Models and Compare screens answer questions such as:
- Which models are used most often?
- Which tasks are they being used for?
- What is their average cost per session?
- How often do their edits succeed without retries?
- Is a cheaper model actually cheaper after correction cycles?
- Is an expensive model being used for work a smaller model handles well?
This is where I often find the most practical changes.
The conclusion is rarely “always use the cheapest model” or “always use the strongest model.”
It is usually something narrower:
- This model is fine for documentation but struggles with debugging.
- This expensive model is being used for simple edits.
- This cheaper model needs enough retries that the saving disappears.
- Planning is cheap, but implementation is creating most of the cost.
That is information you can use when choosing models or configuring routing rules.
Find work that did not survive
The Optimize screen looks for signs of avoidable work, including reworked files and reverted or abandoned changes.
This is deliberately presented as evidence rather than a magical optimization score.
A reverted edit is not automatically waste. Developers explore ideas, test alternatives, and deliberately throw work away. But repeated patterns can still be useful:
- The same file is rewritten several times
- A costly session ends with most changes reverted
- A model repeatedly fails a particular task category
- A large amount of spend never reaches the final result
The screen gives you places to investigate. You decide whether the work was necessary.
Track subscription pacing
Many developers no longer pay only per API token. We also use Claude, ChatGPT, Cursor, and other subscription plans.
The Plans screen lets you configure provider-specific monthly plans and compare usage against their cost.
This does not pretend to know hidden provider limits. Vendors generally do not publish exact token allowances for consumer subscriptions.
Instead, it helps answer a simpler question:
Based on how I am using these tools, is this subscription still making sense for me?
The app does not require a separate CLI installation
The packaged desktop app includes its own CodeBurn CLI.
The Electron process uses that bundled CLI to parse and aggregate local data. There is no daemon to configure and no local HTTP server required for the desktop interface.
The application is available for:
- macOS on Apple Silicon
- macOS on Intel
- Windows
- Linux as AppImage or Debian package
Downloads are available from the desktop release:
https://github.com/getagentseal/codeburn/releases/tag/desktop-v0.9.19
The source is here:
https://github.com/getagentseal/codeburn
What “local-first” means here
CodeBurn reads session data directly from the files and databases created by supported tools.
Depending on the provider, that may include:
- JSON or JSONL transcripts
- SQLite databases
- Editor workspace storage
- Token-count events
- Tool-call records
- Git branches and working directories
It does not require you to route AI calls through a proxy or wrapper. It also does not need your provider API keys just to analyze existing local sessions.
Pricing data is taken from LiteLLM and cached locally. When a provider exposes exact token counts, CodeBurn uses them. When it does not, the result may be estimated.
That distinction matters.
The limitations are real
This kind of tool is only as accurate as the underlying data.
Different providers expose different levels of detail:
- Some store exact input, output, and cache token counts
- Some store only cumulative counters
- Some require token estimation from message content
- Some expose file operations but not precise model usage
- Some do not retain enough Git context for PR attribution
- Local models and proxies may require custom pricing rules
CodeBurn tries to make these cases explicit instead of presenting every number as equally precise.
Supporting many tools also means parsers can break when providers change their storage formats. That is one reason the project is open source: every provider integration can be inspected, tested, corrected, or extended.
Why I’m sharing it here
I think AI coding observability is still an unsolved developer-tooling problem.
We have increasingly capable agents, but very little shared understanding of how to evaluate their work beyond “the code eventually passed.”
Token totals are only one part of the picture. Sessions, retries, tools, projects, PRs, abandoned work, and model choices provide much more useful context.
CodeBurn is our attempt to make that context visible using data developers already have.
If you try it, I would be interested in hearing:
- Which coding agents do you use together?
- What would make PR attribution more useful?
- Which workflow signals do you trust?
- Where do the current numbers feel misleading?
- Which provider should be supported or improved next?
The project is open source:
Top comments (0)