I Put 8.8 Billion Tokens on My CV

Updated September 2026. This number has now been wrong twice, both times in the same direction — too low. First, /cost reports "all time" from the day the local stats cache started, not from your first token. Second, and worse: that cache is per machine, not per account. Details in the corrections below. Short version: every /cost screenshot you've seen, mine included, is a floor for one computer.

This morning I learned Claude Code has a /cost command. I ran it, stared at the screen for a second, and tweeted the screenshot: 8.8 billion tokens in 234 days.

Then I did something that felt slightly absurd and completely right: I put the number on my résumé.

How big is 8.8 billion, actually

Numbers with nine zeros stop meaning anything, so let me translate. 8.8 billion tokens is roughly six and a half billion words — more text than the entire English Wikipedia — flowing between me and my coding agents in 234 days. The odometer also said I was only actively driving on 56 of those days — which, as the corrections below explain, was wrong too: my prompt history records 174 active days in the same window. That puts the honest rate nearer 51 million tokens per active day of specs, diffs, test output, and code review.

The fine print is a story of its own. 8.4 of those billions are cache reads — agents re-reading their working context on every turn. That's not padding; that's exactly what several long-running sessions with big contexts cost, and the 19.8 million output tokens on the same line are the part I reviewed. There are 168 sessions in there, a 17-day streak, and one session that stayed open for 29 days straight.

No human types that. That's the point. The number isn't measuring my typing — it's measuring how much work I can keep in flight.

"Tokens are a cost, not an achievement"

I can hear the objection, because I made it to myself first: bragging about tokens consumed is like bragging about lines of code written. It's an input metric. Spent badly, 8.8 billion tokens is just an expensive way to heat a server room in Dublin.

That's true — on its own. Which is why the number sits on my CV next to what it produced: 15+ live products built and operated end to end, 2.38 million companies indexed by my job-board agents, 2,592 GitHub contributions in the last twelve months, and a whole Azure estate migrated to one VPS. Input without output is burn rate. Input with output is throughput, and throughput is exactly what hiring managers are trying to estimate when they ask "so, do you use AI tools?"

Everyone says yes to that question now. It's the "proficient in Microsoft Word" of 2026. A measured number is different: it's specific, it's falsifiable, and almost nobody has one, because almost nobody thought to look.

Spending tokens well is a skill

Here's the claim I actually want to defend: sustaining that volume productively is a skill, the way flight hours are a skill. Nobody hires a pilot because sitting in a cockpit is impressive; they hire the hours because you can't fake what they proxy for. Getting through billions of tokens without producing garbage means, concretely:

• Specs an agent can build from. Every feature I ship starts as a Markdown spec. Vague prompts burn tokens on wrong answers; a good spec converts them into working code on the first or second pass.
• Review that keeps up. Agents produce faster than most people can read. I review like a tech lead — every line, before it ships — and the day I can't keep up, the pipeline stalls no matter how many tokens I throw at it.
• Parallelism. One agent session is autocomplete. Three or four at once — one migrating a schema, one writing tests, one drafting a scraper — is a team, and coordinating a team is the actual job.
• Context engineering. When you also pay API invoices for your own products' users, you learn to care. The context-trimming layer I built for NestClaw cuts token spend roughly in half. High throughput and cost discipline aren't opposites; the second is what makes the first sustainable.

None of that shows up in "familiar with AI-assisted development." All of it shows up in the odometer.

What it looks like on the CV

The metrics strip on my résumé now reads:

20 yrs C#/.NET in production · 15+ live products · 35 production services on one VPS · 2,592 GitHub contributions in 12 months · 10.2B Claude Code tokens in 2026 so far

And the skills table says it plainly: Claude Code and parallel multi-agent workflows daily (10.2B tokens in 2026 so far across two machines, daily since March 2025).

Maybe in two years this will look as quaint as "types 80 WPM." Fine. Right now, in the middle of the transition, it answers the one question every engineering interview circles around — can this person actually work the new way, or do they just say they can? — with a number instead of an adjective.

Two corrections to the odometer

Correction one: "all time" isn't all time. /cost computes its numbers from ~/.claude/stats-cache.json, and that file reaches back only as far as the session transcripts still on disk. On my desktop the cache began on 5 January 2026, while claudeCodeFirstTokenDate in ~/.claude.json puts my first Claude Code token on 31 March 2025 — ten months the "all time" label quietly dropped. Summing modelUsage across every model in that cache gives 9.3B, for 2026 alone. The same file undercounts active days: it said 56, while my prompt history in ~/.claude/history.jsonl records 174 days with a prompt on them inside that very window — which is why the per-active-day rate in the original version of this post was about three times too high.

Correction two: the odometer is per machine. This one I found by accident, a month later. I opened Claude Code on my MacBook Air — the laptop I use maybe one day in ten, signed into the same account as the desktop above — and looked at the same screen:

907.2 million tokens, all time. Twenty-five sessions, eight active days out of 231, favorite model Opus 5. Same account, same subscription, same person, same week — and a number ten times smaller than the one on my CV.

Nothing syncs. stats-cache.json is computed from the transcripts on that computer's disk, so a second machine starts your odometer at zero and its window opens whenever that machine's oldest surviving session does: 18 January 2026 here, versus March 2025 on the desktop. Correction one then repeats itself locally — this laptop's own history.jsonl shows 41 days on which I typed a prompt, going back to 12 November 2025, against the cache's 8.

So the honest reading of any /cost total is this is what one computer still remembers. If you code from a desktop, a laptop and a cloud box, your account-wide number is the sum of caches you have to collect by hand; the CLI will never add them up for you.

Two details in that second screenshot generalize:

• Cache reads are 98% of the total. 889.5m of the 907.2m are cache reads; output is 2.3m, and typed input is 106.3k — about a novel's worth of me, against a library of agents re-reading their own context. The desktop's ratio was the same (8.4b of 8.8b). A token count mostly measures how much context your agents carry, not how much you write.
• A short window makes heavy use look like abandonment. "8 of 231 days" reads like a tool I gave up on. It's eight days of real work — one of them an 18-hour session — inside a window that started counting the first time this laptop happened to record a session.

So the CV figure moved again, for the second time in a fortnight: 9.3B was one machine's 2026 total, and adding this laptop's 907m makes it 10.2B across two machines — which is what the strip above now says, with "across two machines" written into the skills line, because a number you can't say the boundaries of isn't a measurement. It is still a floor. Whatever fell out of both caches before January 2026 is gone for good, and I'd rather publish the number I can reproduce from a file today than the bigger one I can only assert.

Check yours

Open Claude Code and run /cost. If you've been doing this daily for months, the number will surprise you — mine did, that morning, and I'd been watching the invoices. Then, before you trust the words "all time", do three things:

1. Check claudeCodeFirstTokenDate in ~/.claude.json. If it predates the window /cost is reporting, your real number is bigger than the one on screen.

2. Run it on every machine you code from. Each keeps its own ~/.claude/stats-cache.json and none of them know about the others. Your account-wide total is the sum, and you are the one who has to add it up.

3. Count your own active days. On macOS:

   grep -o '"timestamp":[0-9]*' ~/.claude/history.jsonl | cut -d: -f2 \
     | while read t; do date -r $((t/1000)) +%Y-%m-%d; done | sort -u | wc -l
   

   (On Linux, date -d @$((t/1000)) +%F.) Compare it with the "active days" the stats screen shows. Mine has been wrong on both machines, in the same direction.

And if the total is big: consider writing it down where hiring managers can see it — with the caveat, which is itself a hiring signal. Knowing what your own numbers don't measure is the job. The odometer only counts if you show it, and it only means anything if you can say what it left out.

What's your number? Tell me on X — I'm collecting them.