DEV Community: Nikhil Kumar

My side project cost $1,278 in tokens. I built a tool to find out where it went.

Nikhil Kumar — Sun, 27 Sep 2026 16:57:54 +0000

Quick question. Your last vibe coded project. How long did it take you, and what did it cost?

Not "about a week". Not "I'm on the Max plan so, nothing?". The actual answer. Which feature ate the most time. Which bug cost you forty bucks of tokens going in circles. Which afternoon you'd rather forget.

I didn't know either, and it bugged me. So I built a tool that works it out, and it turns out the answer was sitting on my disk the whole time.

The project I built it on came out like this: 542 prompts, 32 sittings, 36 hours at the keyboard, and $1,278 at API rates. Yes, that last one is real.

Your agent has been keeping a diary

Claude Code, Codex and Pi all write a transcript of every session to your machine. Every prompt, every file the agent touched, every command it ran, every token it burned. It's all in there, going back as far as your agent keeps it.

Nobody reads these files, because they're unreadable. One session can run for a week and wander through a dozen unrelated things. It's a wall of JSON.

bough reads them for you and draws the shape of what you actually built.

You install it, type bough, pick a project, and it opens in your browser. That's the whole setup. No account, no API key, and nothing leaves your machine. It doesn't even need the internet.

brew install nickelsec/tap/bough

(Linux, Windows and go install are on bough.run, it's one command each.)

The map of your project

The first thing you see is a line running left to right. That's time.

Each big square on the line is a sitting. A stretch where you sat down and worked, until you stopped for the night or went and did something else. Under each one it tells you the day, what time you started, and how long you were actually at the keyboard. "Fri 25 Sep, 5:21 PM · 7 min."

The smaller squares hanging off it are tasks. This is the part I'm proudest of. Your agent thinks in sessions, and a session is useless as a unit of work because one of them can cover a week of unrelated stuff. bough works out where one piece of work ends and the next one starts. It looks at how long you paused, whether the agent had to compact its memory, and whether you changed subject and files at the same time. So instead of "session 7f3a9", you get "that time I rebuilt the export path" as its own thing.

Every little circle is a single prompt you typed.

Hover anything and the path back to its sitting lights up, with a note saying what it was. Click it and the full record opens on the side, scrolled to that exact prompt, in your own words, untrimmed. Every typo intact. Humbling, honestly.

What each piece of work cost

Behind every task there's a faint circle. Its size is how much that task was charged.

Hover it and you get the breakdown in tokens and in dollars. Open the usage table from the rail and there's every sitting and every task in one place, with the same columns the agents themselves report.

Here's what surprised me most. Most of the money isn't the model writing code. It's the model re-reading the conversation. Every single reply, it reads everything so far again. On my projects that came out between 176 and 732 times more context read than output written. A long rambling chat can cost more than a hard piece of engineering, just because it's long.

Once you see that, you'll probably start clearing context a lot more often.

A few honest things about the dollar figure:

It's what the work would have cost at published API rates. If you're on a flat subscription, you didn't pay this. Flip it around though and it's what your subscription saved you, which is a fun number to know.
If you run a local model through Pi, with Ollama or llama.cpp, that work is $0, and it says "(local)" next to it so you know why.
If a model has no published price, it says NA. It won't make up a number. A wrong number is worse than no number.

One task from early on reads 14 prompts, 5 failures, an hour and 29 minutes, and $34.77. Seeing it laid out like that, with every failed attempt in order, is a different experience from remembering it.

Your commits are on the map

A task with a small mark on it is one that ended in a commit. The note gives you the hash and the message.

bough also reads your project's git history, read-only, to check them. So a commit shows up with its real subject line and how many lines it added. Everything else in the drawing is worked out from your history. The commits are the part you can go and check yourself.

"You kept coming back to this file"

This one is sneaky useful. For every sitting, bough notices which file you kept returning to, and how much of it actually changed each time.

"kept coming back to index.html (4 times, 92 lines)"

Coming back nine times to fix a typo is a very different afternoon from coming back nine times to rewrite the whole thing. Now you can tell which it was.

It also draws dotted lines between sittings that went back to the same files. So when you pick something up again three days later, you can see the thread. On a big project there are a lot of these, so there's a switch to hide them when they get in the way.

Filters, because you will have a lot of history

The rail on the right is where it gets fun. Nothing disappears when you filter. Everything that doesn't match just fades, so you still see the whole shape around what you're looking for.

Search your own prompts. Type a few words you remember writing and it rings every prompt that has all of them. Perfect for "that time I asked it to fix the timezone thing" when you have no idea which week it was.

Filter by file. Type hero.css and every task that touched it lights up. Great for "when did this file start going wrong".

Filter by date. Pick a range, see only that.

Filter by cost. One slider. Drag it and everything under the threshold fades. "Show me every task that cost more than $25" is one drag. You can switch it to any token count instead of dollars too.

What to show. A few switches:

Only substantial sittings, which fades anything under five prompts so the quick "fix this typo" visits get out of the way.
Show where it was hard, which colours the work where you rewrote the same file over and over and the prompts came thick and fast. I'll be honest, this one is a guess, and the app labels it as one. It's off until you ask for it.
Show links between sittings, the dotted lines from before.

It works in the terminal too

Don't want a browser? Add --text and you get the same thing as an indented list:

Fri 25 Sep     make it even worst
17:21          1 task, 4 prompts, 7 minutes
               kept coming back to index.html (4 times, 92 lines)

  make it even worst
    4 prompts, 12 changes, 3 failures, 7 minutes, 11k written, 24x context, $0.26

(Yes, that prompt says "make it even worst". I was testing on a deliberately terrible portfolio site. Don't judge.)

--json gives you the whole structure if you want to build something on top of it.

Why not just use /stats or ccusage?

You should! They're good at a different question. Claude Code's /stats and tools like ccusage tell you how much you've used and spent. They stop at a session, and a session is an opaque id that can cover weeks of unrelated work.

bough answers what did I build, and what did each piece of it cost. Knowing what one feature or one stubborn bug cost you is where the numbers actually start meaning something.

The boring but important bits

It only reads. It never writes to your agent's history or your repo.
It never touches the network. Your prompts, your code and your costs stay on your machine.
It's one Go binary, free, and MIT licensed.
It reads Claude Code, OpenAI Codex CLI and Pi, and finds all three automatically. If you use more than one on the same project, they show up in the same list.

Go look at your own receipt

brew install nickelsec/tap/bough
bough

Then pick the project you're proudest of, or the one that nearly broke you. I promise at least one number in there will surprise you.

It's still early, and the task boundaries are tuned on my own history, so if yours land somewhere weird I'd genuinely love to hear about it. Issues, ideas and "this number looks wrong" are all welcome on GitHub.

And if you find out what your worst afternoon cost, tell me in the comments. I showed you mine.

I parsed 76,801 lines of my own Claude Code history. Three things nearly broke my parser.

Nikhil Kumar — Sun, 06 Sep 2026 16:42:15 +0000

Claude Code writes every session to ~/.claude/projects as JSONL. I wanted to know what I'd actually built over three weeks on one repo, so I started reading those files.

The format is undocumented. Here is what I measured across 28 transcripts, 275 MB and 76,801 lines, and the three things that gave me wrong numbers before I noticed.

1. The files replay, and counting lines overcounts by 3x

Claude Code appends to a transcript when you resume or rewind a session, and it rewrites records it has already written. The same uuid shows up more than once.

My largest session:


lines	36,676
distinct records	10,964
uuids appearing more than once	7,919

So counting lines, which is the obvious first thing anyone does, overstates that
session by more than three times. Worse, the overstatement is uneven, so there
is no constant you can divide by to fix it.

Deduplicate on uuid, keeping the last copy. Later copies carry fields the
earlier ones did not.

2. One field is sometimes an object and sometimes a string

toolUseResult is an object 17,319 times and a bare string 490 times.

// This is wrong, and it fails quietly
type Record struct {
    ToolUseResult *ToolUseResult `json:"toolUseResult"`
}

If you type it as an object only, every string-valued line fails to decode. And
if your reader skips a record on a decode error, which is a reasonable default,
you lose it silently. In my own test fixture that dropped 85 of 340 records. I
found it a week later, by accident, because a count didn't match.

The fix is a custom unmarshaller that accepts either shape:

func (t *ToolUseResult) UnmarshalJSON(b []byte) error {
    if len(b) == 0 || b[0] != '{' {
        return nil
    }
    type plain ToolUseResult
    return json.Unmarshal(b, (*plain)(t))
}

message.content has the same problem: a list of blocks 52,641 times, a bare
string 400 times.

3. Quiet commits arrive with no hash

When the agent commits, the result carries the commit:

"toolUseResult": {
  "gitOperation": {
    "commit": { "sha": "d0a65cc", "kind": "committed", "branch": "main" }
  }
}

Except Claude Code fills that in by reading what git printed. Silence git and
the field never appears:

commit command	calls	carried a hash
without `-q`	57	53 (93%)
with `-q`	88	0

Relying on that field alone found 4 of one repository's 31 commits.

The dependable signal is the shell command itself: a git commit that returned
without an error. Which leads to the trap I enjoyed least.

The bonus trap: commits that never happened

If you detect commits by matching git commit in shell commands, a command that
writes a file containing those words looks identical to one that runs them:

cat > release.sh <<'SH'
git commit -m "release $VERSION"
SH

Seven of one project's apparent commits were heredocs like this. The fix is to
check whether a heredoc opens before the match. A real commit taking its message
on a heredoc opens it after.

Why any of this mattered to me

I was building a thing that draws your Claude Code history as a diagram: squares for days, smaller squares for tasks, a circle for every prompt, with commits marked on the work that produced them. Every number above is one I got wrong first and had to go back and fix.

It's a Go binary, runs locally, reads files already on your disk and sends
nothing anywhere. github.com/nickelsec/bough

The full format notes, including record types and the fields that carry less
than you'd hope, are at bough.run/docs/format.

If you're parsing these files yourself, the replay is the one that will get you.
It's silent, it's uneven, and every number downstream of it is wrong.