-
Chris Alarcon - 14 Aug, 2026
My Real Claude Code Usage, Measured
Quick answer: I pay $200 a month for Claude Max 20x, I use Claude Code most days, and I almost never hit a usage limit. Across nine weeks of my own logs, limit and overload events account for about 0.05% of 220,861 log lines. The reason is not restraint. It is that 97.4% of my tokens are prompt cache reads, not new work. Heavy usage looks enormous and is mostly cheap context re-reads. That single fact is missing from every "am I using too much" thread I have read, so I mined my own logs and published the numbers. One thing up front: these are one operator's numbers on the top consumer tier, with specific habits. They are not a benchmark and they are not what your usage will look like. How I measured this, and what I cannot prove Credibility here comes from the caveats, so they go first rather than in a footnote. Raw verified window: June 11 to August 14, 2026. I streamed all 1,587 session log files and deduped token counts by request ID so retries and repeated writes do not double count. Lifetime figures: these come from Claude Code's own stats cache covering December 31, 2025 to August 11, 2026. I label them "as reported by the app" everywhere they appear, because the raw logs from before July were rotated out and I cannot independently verify them. That distinction matters. The headline number people would want me to lead with, 64.4 billion lifetime tokens, is the weakest number I have. The nine-week verified figure is the one I would defend. One more honesty note, because it is funny and it tells you something about log data: my longest recorded "session" runs about nine days. That is not a nine-day session. That is a terminal window I left open. If a stat below has no caveat attached, it came from the verified window. The numbers Verified, nine weeks (June 11 to August 14, 2026):Measure ValueTotal tokens 11.29BPrompt cache reads 97.4% of tokensGenuinely new output 29.8M tokens (0.26%)Biggest single day 1.29B tokens (August 7, a Friday)Limit / overload events 119 hits across 220,861 log lines (**0.05%**)Median session length 3.2 minutesSessions under 1 minute ~30%90th percentile session 94 minutesMedian messages per session 53As reported by the app (Dec 31, 2025 to Aug 11, 2026): 2,742 sessions across 159 active days, roughly 17 sessions per working day, 64.4B tokens. Model mix by request, nine weeks:Model Share of requestsOpus 60%Fable 27.8%Opus 4.8 9.9%Sonnet 2.2%Haiku 0.04%Time of day: activity peaks at 8 AM and again from 3 to 4 PM ET. Dead between 4 and 6 AM. The 97.4% is the whole story If you take one thing from this page, take this. Cache reads are not new work. When an agent works in a repo, it re-reads the same files, the same instructions, and the same conversation over and over. Anthropic caches that, and a cache read costs a fraction of fresh input. The API price sheet makes the ratio concrete: Opus 5 input runs $5 per million tokens while a cache read runs $0.50. Ten to one.Anthropic's published API rates, captured August 14, 2026. The read row is why 11.29 billion tokens is a much smaller number than it looks. So "64 billion tokens" is not 64 billion tokens of thinking. It is a small amount of new reasoning wrapped in an enormous amount of cheap re-reading. This is why an extreme user rarely hits the wall. It is also why the token numbers people post in Reddit threads are almost meaningless without the cache split, and nobody ever posts the cache split. Median session: 3.2 minutes The other surprise in my own data was the shape of the sessions. I expected marathons. I got quick draws. Half my sessions are under 3.2 minutes and about 30% are under a single minute. The long tail is real, with a 90th percentile of 94 minutes, but the everyday pattern is: open it, ask for the thing, close it. That maps to how I actually work, and it is worth saying because "power user" imagery usually shows someone locked in for six hours. Mine looks more like a couple of dozen short visits a day, going by the app-reported session count against active days. The day the limit taught me routing Here is the anecdote that changed my habits, and it is not flattering. I was using the top model to QA a skill. Not to build anything. Just to check my work. I burned more than 20% of my usage in one day. By day two or three I was at roughly 50%. By day four I was at 70 to 80%. And I started getting stingy. Damn, I thought, I should not be using the top model for that. The limit never actually blocked me. It taught me routing. That is the reframe I would hand to anyone panicking about caps: the limit is not a punishment, it is a pricing signal. It tells you when you are spending a premium model on a commodity job. I want to be honest about the current state of this too, because my own data could be read as bragging. I hit the weekly wall this week. On the 20x tier. That was me riding long sessions up to the maximum context window until they auto-compacted, which is exactly the habit I am about to tell you to fix. The wall is real even at $200 if your habits slip. Habit 1: a context meter and a fresh-session handoff This is the one where most of my spending was hiding. I run a context meter in my status line. It shows green, yellow, red. Around 500k it visually grabs my attention. At that point a hook fires and auto-writes a NEXT-STEPS markdown file at the repo root. I close the window, open a fresh session, say "read the next-steps file," and carry on with zero context but the same knowledge. Two reasons this matters, and the second one surprised me:At 800k context you burn tokens dramatically faster, because every single message re-reads all of it. Ironically, the quality deteriorates. A model swimming in 800k of accumulated history is not sharper than one handed a clean brief.Before I built this, I rode sessions until they auto-compacted. That is where the 20%-plus days came from. Habit 2: subagents, and the payload rule The main agent stays the brain. Grunt work goes somewhere else. Research, file sweeps, mechanical checks: I spawn those to subagents. Each one gets its own context window, so five or ten of them can run a large parallel sweep without touching my main session's budget at all. The catch is real and most people hit it: give them a good payload. Clear instructions and the right tool access up front. Send a subagent off with a vague one-liner and it will do basic research and hand you garbage back. The parallelism is free. The quality is not. Habit 3: model and effort routing Sonnet 5 is the floor for grunt work. Haiku only for genuinely mechanical jobs like renaming files. Opus at medium effort handles routine, deterministic work. A LinkedIn post I build the same way every time does not need more than that. Opus at high effort is for research and for leveling up skills. Opus hard is amazing, and honestly I underrated it for weeks by leaving it on medium. The top model comes out only when the problem is genuinely hard. The part people miss: the effort dial is part of the budget, not just the model name. Moving from medium to high changes both cost and quality, and switching that dial deliberately did more for my output than any model upgrade did. What a heavy day actually looks like The biggest day in the verified window was August 7, at 1.29 billion tokens. It was a Friday, and that is not a coincidence. Friday is content day:Shorts scripts, including scraping competitor comments and X for topics Blog work driven off Search Console opportunities, both new posts and enriching existing ones The newsletterThe rest of the week is lighter: analytics reviews asking where we fell short, and tinkering to level up skills. That tinkering compounds in a way that is easy to miss. My shorts skill started as "generate scripts." Then it found topics. Then it wrote in my voice. Now it edits the videos. I record 14 shorts in about 45 to 60 minutes, spend roughly 15 minutes editing, and then a polish skill runs for two to three hours autonomously. Longform editing went from about two hours to 10 or 15 minutes through the same iteration loop. The current hook-animation work I would grade a C, and I expect to get it to an A the same way. That is what the token count is actually buying. Not chat. Compounding tooling. What I would tell you to do with this Do not use my numbers to justify the $200 plan. Read them the other way. A heavy daily user on the top tier sits at roughly 0.05% limit friction, which means I have headroom I am not using, and I still got walled once by bad habits. Habits move this number more than tiers do. Do not read a big token count as a big workload. Ask for the cache split. Without it the number means nothing. Fix context before you fix your plan. The fresh-session handoff was worth more to me than a tier upgrade would have been. If you are choosing between the two Max steps, the measured version of that decision is Claude Max 5x vs 20x. If you are earlier in the ladder, Claude Pro vs Claude Max and Claude usage limits explained cover the mechanics I am measuring against here. One last thing, and it is the reason I published my own logs instead of another opinion piece. The only difference between AI slop and us is we actually have our experience. That is Chris Alarcon's rule, and it is why this page has numbers in it. Published and last reviewed August 14, 2026. Verified figures come from 1,587 local Claude Code session logs streamed and deduped by request ID over June 11 to August 14, 2026. Lifetime figures are from Claude Code's own stats cache and are labeled as reported by the app throughout. Plan mechanics and API rates checked against claude.com/pricing that day. These are one account's numbers on Max 20x, not a benchmark.This post is part of Claude at Work, the hub with every plan decision, task comparison, and setup guide for using Claude at your job without code.