DEV Community: Toruk Makto

Your AI Coding Agent Already Leaves an Audit Trail. I Built a Desktop App to Read It

Toruk Makto — Tue, 21 Jul 2026 19:30:35 +0000

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:

https://github.com/getagentseal/codeburn

Your agent burned millions of thinking tokens you never saw.

Toruk Makto — Fri, 03 Jul 2026 11:05:43 +0000

Codeburn context opens the black box. Every block in the window, counted: reasoning, injected meta, compactions, the real context from API usage.

try npx codeburn context

You pay for Claude, Codex, and Cursor every month.

Toruk Makto — Sat, 27 Jun 2026 11:18:16 +0000

The bill gives you one number. It never tells you that half of it went to conversation instead of code.

CodeBurn does. Every token and dollar, by task, model, and project. 30 AI tools, one screen, all local.

npx codeburn

I turned 14 business books into Claude Code skills that auto-trigger based on your question

Toruk Makto — Wed, 29 Apr 2026 02:08:28 +0000

why this exists

been using claude for almost all my business planning - pricing, customer interviews, marketing strategy, sales calls. the problem is claude knows these books from training data but only surface level. ask it about The Mom Test and it'll say "ask open-ended questions." ask it to actually score your customer conversation and it makes up random criteria every time.

wanted something structured. actual decision trees, scoring rubrics, templates that work the same way every time. started with The Mom Test after someone recommended it to me. turned it into a skill. then couldn't stop. 14 books later here we are.

what's actually inside each skill

every skill follows the same structure:

a decision tree at the top that tells you whether this is even the right framework for your problem. half the time founders think they have a messaging problem when it's actually distribution or pricing. the skill catches that before you waste time.

scored checklists you can use in real situations. the mom test skill scores your customer conversations on 10 specific criteria. spin selling has a call planning worksheet. $100M offers has an offer scoring rubric.

honest limitations. every skill tells you what the book got wrong, what's outdated, and when to stop using it. the lean startup skill flags that innovation accounting barely works outside software. crossing the chasm warns you the bowling alley model is mostly theoretical.

conflict resolution between books. storybrand says position yourself as the guide. obviously awesome is more product-centric. the skills map exactly where two frameworks disagree and how to resolve it depending on your situation.

who this actually helps

you're about to do customer interviews → mom test skill gives you exact questions to ask and a scoring rubric to evaluate answers

you're pricing a new product → monetizing innovation walks you through willingness-to-pay research before you build

you're writing your landing page → storybrand gives you a fill-in brandscript template so you stop talking about yourself and start talking about the customer's problem

your marketing isn't converting → the skill figures out whether it's messaging (storybrand), positioning (obviously awesome), channels (traction), or your offer itself ($100M offers)

you're preparing for a B2B sales call → spin selling gives you a call planner with situation, problem, implication, and need-payoff questions mapped out

how to use

clone the repo and symlink into claude code - skills auto-trigger based on your question. or just paste any SKILL.md into chatgpt/gemini/cursor as context. works the same way.

https://github.com/getagentseal/founder-playbook

free and open source. genuinely curious what books you'd want added next.

Reading your AI coding logs: cache hits, retry loops, and other signals

Toruk Makto — Thu, 16 Apr 2026 09:58:49 +0000

Last week I checked my AI coding spend and it was higher than my AWS bill. I'm paying for Claude Code, Codex, Cursor, the occasional Opus burst, and I had no visibility into where any of it went. Just a number going up.

Turns out every AI coding tool already writes session data to disk. Claude Code drops JSONL into ~/.claude/projects/. Codex writes to ~/.codex/sessions/YYYY/MM/DD/. Cursor uses a SQLite database. OpenCode uses SQLite. Pi uses JSONL. All of it is sitting there waiting to be read.

I started reading mine and the patterns are obvious once you look.

What the data shows

This is one week of my actual AI coding usage:

A few things jumped out immediately.

Cache hit rate matters more than I thought. Claude prices cache reads at 1/10th the cost of fresh input. Opus came in at 98.8% cache hits, which sounds great until I noticed Sonnet 4.6 was at 77.1%. That gap is real money. If your system prompt or the first few files in context are unstable, you're paying full price for the same tokens every turn.

Tool counts tell you the agent's mood. 2,126 Bash calls, 990 Reads, 742 Edits in a week. The Read:Edit ratio is roughly 1.3, which is fine. If Read had been 4x higher, I'd know the agent was spelunking instead of executing.

One-shot rate is brutal honesty. Coding shows 88% one shot. The other 12% needed retries (Edit → Bash → Edit). That's where time and tokens leak silently.

Model mix reveals overspending. Opus 4.6 cost $1219 this week. Sonnet 4.6 cost $38. Some of those Opus turns were small Q&A that Sonnet would have handled fine. I haven't run the experiment of routing them yet, but the gap suggests there's real money on the table.

Patterns worth watching for

Signal	What it usually means
Cache hit < 80%	System prompt or context unstable, caching not configured
Lots of Read calls per session	Agent re-reading files, missing context
Low one-shot rate (Coding < 30%)	Retry loops, agent struggling with edits
Opus dominating cost on small turns	Overpowered for the task
`dispatch_agent` heavy	Sub-agent fan-out, expected or excessive
No MCP usage	Either you don't use MCP, or your config is broken
Bash dominated by `git status`, `ls`	Agent exploring instead of executing
Conversation category dominant	Agent talking instead of doing

These aren't verdicts, just starting points. A 60% cache hit on a one-off experiment is fine. A persistent 60% across weeks is a config issue.

How I'm reading this data

There's a tool called codeburn that reads all the session formats and renders this dashboard in your terminal. It supports Claude Code, Codex, Cursor, OpenCode, and Pi. No proxy, no API keys just reads the local files.

npx codeburn report --period week

Repo: https://github.com/AgentSeal/codeburn

Open source, MIT.

Why this matters

We obsess over model choice and pricing tier. We argue about Opus vs Sonnet vs GLM. The discussion online is almost entirely about which model to use, never about what your agent is actually doing once it's running.

The session files have the answer. Every retry, every redundant Read, every cache miss, every misrouted model,it's all there. Looking at it once a week takes ten minuts and tells you more about your spend than any pricing comparison.

Try reading your own sessions for a week. Even if you don't use any tool, just cat a few JSONL files and look at the usage blocks. You'll spot at least one pattern you didn't expect.

Where do your AI coding tokens actually go?

Toruk Makto — Thu, 16 Apr 2026 09:49:05 +0000