Aditya Vikram Singh

Posted on Aug 12

Your AI Coding Bill Tells You the Cost. Not What the Work Produced.

#ai #programming #productivity #opensource

AI coding tools are becoming a meaningful line item for developers and engineering teams.

But most provider dashboards answer only one question:

How much did you consume?

They rarely tell you:

Which project consumed it?
Which model was responsible?
Was the agent coding, debugging, planning, or merely talking?
How often did it retry the same edit?
Did the work result in a commit or pull request?
Was an expensive model doing work a cheaper model could have handled?

That information often already exists. It is sitting in the session files that coding agents write to your machine.

We built CodeBurn to read those files and turn them into something useful.

The missing layer in AI coding observability

A total token count is not enough to make a good engineering decision.

Suppose two coding sessions each cost $10.

The first session:

implemented a feature;
edited the correct files;
succeeded on its first attempts;
produced code that landed in the repository.

The second:

repeatedly reread the same files;
retried several edits;
spent most of its time in conversation;
ended without producing a commit.

The invoice sees $20.

An engineering team sees two radically different outcomes.

The more useful unit is not simply cost per token. It is something closer to:

Cost per successful unit of work.

Getting there starts with better attribution.

The data is already on your machine

Claude Code, Codex, Cursor, Gemini, Copilot and many other coding tools preserve local session data.

Depending on the tool, that data can include:

token usage;
model information;
timestamps;
tool calls;
project paths;
files read or edited;
shell commands;
conversation history.

CodeBurn currently supports 40 coding tools and agents. It normalizes their different storage formats into one local view of usage.

There is no proxy in front of the model and no wrapper around your workflow. CodeBurn reads the records the tools have already written.

That distinction matters.

Your coding transcripts may contain source code, file paths, architecture decisions, debugging output and other sensitive project context. You should not have to upload all of that to another service merely to understand your own usage.

CodeBurn therefore runs locally:

no account;
no API keys;
no transcript uploads;
no cloud dependency.

From token totals to work patterns

Once usage is connected to projects, models and tool activity, more useful questions become possible.

Where is the money going?

CodeBurn breaks usage down by:

coding tool;
model;
project;
task category;
session;
time period.

Run:

npx codeburn

That opens the interactive terminal dashboard using the session data already on your machine.

For a copyable report:

codeburn overview

You can also narrow the analysis:

codeburn overview --provider claude
codeburn overview --from 2026-08-01 --to 2026-08-12

Is the model working efficiently?

Token consumption alone cannot tell you whether a model struggled.

CodeBurn measures patterns such as:

one-shot edit rate;
retry rate;
self-correction;
cost per call;
cost per edit;
output tokens per call;
delegation and planning behavior;
cache use.

Run:

codeburn compare

This compares two models using your own work rather than a generic benchmark.

A model that looks stronger on a public benchmark may still be less economical for your projects. It may require more retries, generate more output or perform differently across debugging, feature work and refactoring.

Your workload is the benchmark that ultimately matters.

Where is the avoidable waste?

CodeBurn can inspect sessions and local configuration for recurring waste patterns:

codeburn optimize

Examples include:

files repeatedly loaded into context across sessions;
editing before enough relevant code has been read;
unused MCP servers adding tool-schema overhead;
unused agents or skills loaded into sessions;
oversized instruction files;
context-heavy sessions with little useful output;
expensive sessions that repeatedly retry without observable delivery.

For supported fixes, CodeBurn can prepare or apply a change and keep a local journal so it can be undone:

codeburn optimize --apply
codeburn act list
codeburn act undo --last

After enough post-change data exists, it compares estimated savings with observed results.

The objective is to measure whether an optimization helped, not merely claim that it should.

Did the work ship?

The hardest question is whether the AI spend produced useful work.

CodeBurn begins to approach this by correlating session windows with Git activity:

codeburn yield

The result categorizes spend as:

productive;
reverted;
abandoned;
ambiguous.

This attribution is deliberately described as heuristic. A commit near a session does not mathematically prove that the session caused it. Parallel sessions make attribution harder.

But even an inspectable heuristic is more useful than treating every consumed token as equally valuable.

Why this matters beyond individual developers

For an individual developer, the immediate benefit is visibility:

Which tool costs the most?
Which model works best for my tasks?
Where am I wasting context?
Which sessions produced useful work?

For a team, the question becomes larger:

What useful engineering output are we receiving from our AI spend?

That requires more than aggregating invoices. It requires connecting cost to projects, workflows and outcomes while respecting the sensitivity of developer data.

We think local-first observability is a useful starting point for that problem.