Claude Code Usage: 463 Sessions, 45B Tokens, Counted
66 days of my Claude Code usage, counted: cache writes were 2.1% of 45B tokens and 42% of the list-price dollars. Sessions, prompts, subagents and limits.
In 66 days of my Claude Code logs, cache writes were 2.1% of the tokens and about two fifths of the list-price dollars. My median prompt was 10 words, because the real instructions live in files the agent rereads on every turn, and that rereading is where the tokens go.
The window is 6 August to 10 October 2026. The same script counted 463 interactive sessions and 335 wall-clock hours, a median prompt of 10 words, about 2.7 sessions busy for every hour at the keyboard, and 1 in 5 subagent calls spent on code review.
How I counted
The earliest surviving transcript is from 6 August 2026. Claude Code deletes transcripts after cleanupPeriodDays, 30 days by default (Claude Code docs), and until early October one of my four accounts kept 60 days and the other three 30. So August and early September cover only that one account, and the session counts grow partly because the coverage does: 80 sessions in August, 279 in September, 770 in the first ten days of October (all sessions). The prompt history keeps longer, and I counted prompts from 12 July, so prompt numbers cover 91 days, of which I typed on 76. Each number below says which window and which sessions it counts.
I wrote my own script instead of running /insights, for three reasons. /insights analyzes up to 200 new sessions per run (Claude Code docs, fetched 12 Oct 2026), and I had 1,129. Its reports are deleted on the same 30-day schedule as the transcripts. And I needed headless runs separated from the sessions I drove myself.
The script follows three rules:
- Interactive where it describes me. My logs also hold over 600 headless runs (scripted
claude -pcalls). The "interactive" rows count only sessions I opened in a terminal, plus the subagents they started. Rows marked "all sessions" include the headless runs. - Deduplicated. Transcripts repeat events, so tokens count once per API request, messages once per message ID and tool calls once per call ID.
- Aggregate only. Most of my working directories are client work. Nothing here names a client or a project.
For scale, Stack Overflow's 2026 Developer Survey (6 October 2026) found that 31% of developers who use AI daily use it four or more hours a day, and that its "agents of choice" were Claude Code (66%) and GitHub Copilot (59%). My numbers are one heavy user inside that group.
The script and its raw output stay on my machine. In early October I set cleanupPeriodDays to 365 on three of my four Claude Code accounts, so the next count can cover a full quarter.
The headline numbers
| Metric | Count | Scope |
|---|---|---|
| Sessions | 463 | interactive, 66 days |
| Active days | 53 of 66 | interactive |
| Wall-clock active hours | 335 | interactive |
| Session-hours, overlaps counted | 890 | interactive |
| Subagent sessions | 3,599 | started by interactive sessions |
| Tool calls | 172,480 | all sessions |
git commit | 4,920 | all sessions |
gh pr create | 928 | all sessions |
git worktree add | 454 | all sessions |
| Test runs | 6,981 | all sessions |
| Typecheck runs | 2,835 | all sessions |
| Prompts I typed | 10,511 | 91-day prompt window, 76 active days |
| Usage-limit episodes | 37 | 66 days |
"Active" means less than 15 minutes between events, so a session left open over lunch doesn't count as working.
What does Claude Code usage cost?
Token counts across all sessions, deduplicated per request:
- Cache reads: 43.97 billion
- Cache writes: 950 million
- Output: 83 million
- Fresh input: 627 thousand
That is about 45 billion tokens, 97.7% of them cache reads. Long sessions reread the same rules, code and conversation on every turn, and the prompt cache serves almost all of it.
Priced at Opus 5.5 list rates, the 66 days come to roughly $18,000 by my arithmetic, assuming every cache write used the 1-hour cache, which is the cache lifetime on a subscription (Claude Code docs). Cache writes were 2.1% of the tokens and 42% of the dollars, because a 1-hour cache write costs 40 times a read. A write happens whenever context isn't already cached: a new session, a first message after the cache expired, a compaction. So the read share tells you the cache is working. The write count tells you what it costs.
Two levers follow. Keep what loads on every turn small, since cache reads are still about half the dollars. And avoid needless rebuilds: since v2.1.251, /usage shows a Prompt cache (main) line with the misses, and since v2.1.260 their likely cause (Claude Code docs, fetched 12 Oct 2026). My cost case study tracks the result per merged PR.
Those dollars aren't my invoice: the sessions ran on Claude subscriptions with a flat fee. They measure compute used at list price. On API billing the cache settings can differ, so treat the figure as a scale, not a forecast. Stack Overflow's 2026 survey also found that 38% of organizations set limits on AI usage and 28% review spending data.
On models: 90% of assistant messages came from the Opus models, 7% from Sonnet and the rest from smaller or newer models. I use the cheaper tiers for read-only exploration and keep the strongest one for writing and review.
How long are prompts to Claude Code?
I typed 10,511 prompts. The median was 10 words and the mean 21. 1,620 were slash commands, and I interrupted a running agent 288 times.
Before counting, I would have said I write long, careful prompts. The long text actually sits in briefs, rules files and skills, written once and loaded every time. The prompt itself is usually "continue", a slash command or a one-line correction. Pasted text appears in my history as a short placeholder, so long pastes are undercounted, and the median holds anyway because pastes are a small share of 10,511.
What I take from it: put the effort into files the agent rereads, and keep the prompt for steering.
How many Claude Code sessions run at once?
Summed session by session, my interactive sessions were active for 890 hours. On the wall clock, with overlapping sessions merged, I worked 335. That is about 2.7 sessions running for every hour I was at the keyboard.
My busiest 10-minute window had 18 interactive sessions active at once. A median active day was about 6 hours on the clock, with 7 or 8 new sessions started. Each parallel session needs its own checkout, which is where the 454 git worktree add calls come from. How I run them is in the parallel post.
The ratio measures concurrency: how much work the agents produce while I'm there. How fast that work ships depends on review, which 2–3x on my backlog measures with GitHub timestamps.
1 in 5 subagent calls went to a code reviewer
My sessions spawned 1,119 subagents through the Agent tool:
- General-purpose: 615
- Read-only search (Explore): 132
- Code reviewers: 252, across three roles (correctness, security, completeness)
- Copy and design checkers: 86
- Other named roles: 20
- No type given: 14
So 22.5% of spawned subagents were code reviewers, and 30% counting the copy and design checkers. That's the practice I'd defend hardest, though this part is my judgment, not a count: the agent that wrote the code is a poor judge of it, and a fresh agent with a narrow brief catches some of what the author missed. Whether the reviewers catch real bugs is a separate question, answered with outcomes in the subagents post.
The 3,599 subagent sessions in the table come from transcript files, a different source from these 1,119 Agent calls, so the two numbers don't match.
1.4 test runs per commit
Across all sessions, agents ran git commit 4,920 times and test suites 6,981 times, about 1.4 test runs per commit, plus 2,835 typecheck runs. gh pr create ran 928 times, an upper bound on PRs opened, since some calls were retries. The commit-every-step rule behind those numbers is in my rules file.
37 usage-limit episodes
The script found 37 distinct episodes where a session hit a usage limit, counted once per day and reset message. With up to 18 sessions running, in my experience that's the real ceiling on parallel agents, more than my attention. My fix is a lean orchestrating session that leaves the token spend to the executors; the parallel post has the setup.
What the numbers don't show
4,920 commits say nothing about whether the code was good. What makes the volume safe is what a script can't count well: the review each PR gets before it merges, and what I look for in it. What these tokens cost per merged PR is in the cost case study.
If you're rolling Claude Code out to a team and want the setup that produced these numbers (rules, review subagents, gates and the usage counting), that's the Agent Fleet Setup on my services page.
Questions
How long are prompts to Claude Code in practice?
Short, in my logs: across 10,511 prompts the median was 10 words and the mean 21. The long instructions sat in briefs, rules files and skills that the agent loads on every session, so the typed prompt was usually a correction, a slash command or 'continue'.
How much does Claude Code cost for a heavy user?
At Opus 5.5 list rates, my 66 days of usage (6 Aug to 10 Oct 2026, about 45 billion tokens) came to roughly $18,000 of compute, assuming 1-hour cache writes. It ran on flat-fee subscriptions, so that's compute used, not my invoice. Cache reads were about half the dollars, cache writes 42% and output 9%.
What share of Claude Code tokens are cache reads?
In my logs, 97.7% of about 45 billion tokens over 66 days were prompt-cache reads, because every turn rereads the rules, the code and the conversation. Priced at Opus 5.5 list rates, those reads were about half the dollars, and cache writes, only 2.1% of the tokens, were another 42%. A high hit rate says the cache works; the cost sits in context size and cache rebuilds.
Agent Fleet Setup · from €4,000
Want this setup in your repo?
I install the agent harness I run in your repo: project rules, the worktree and dispatch workflow, and review gates your team keeps.
or book a free 30-minute scoping call →