How to check Claude Code usage

There is no single place that holds all of it, which is why this question keeps getting asked. What exists is a short ladder: one command that answers it for right now, a directory of files that answers it for the past, and a tool on top of those files if you want the past arranged by day. Work down the ladder and stop at the rung that answers your question — most people never need the bottom one.

Step 1: ask Claude Code, in the session

Type /usage at the prompt. Anthropic's command reference describes what comes back as session cost, plan usage limits and activity stats, and lists /cost and /stats as aliases that open the same screen — worth knowing, because plenty of older write-ups still present them as three separate features. (code.claude.com/docs/en/commands, read 2026-09-19.) On a Pro, Max, Team or Enterprise plan the screen also breaks down what has been driving your limits recently, and d and w toggle that breakdown between the last 24 hours and the last 7 days.

Two things the cost documentation is explicit about, and that change how much weight to put on the answer: the figures are approximate, and they come from the session history stored on the machine you are sitting at. A second laptop, a work desktop, or anything done on claude.ai is not in them. (code.claude.com/docs/en/costs, read 2026-09-19.)

Step 2: get a written report out of it

If you want something to read rather than a screen to squint at, the same documentation describes /insights: it analyses recent sessions on that machine and writes an HTML report to ~/.claude/usage-data/report.html, keeping a timestamped copy of each run. Note what it is and is not — the documentation calls it a report on how you work rather than how many tokens you have used, covering what you work on, friction points such as misunderstood requests or buggy code, and suggestions for using Claude Code more effectively. It also costs tokens to produce, since the analysis runs through your own account.

For a number that is in front of you permanently instead of on demand, Claude Code passes its status line script a rate_limits object with your five-hour and seven-day percentages, for subscription accounts, after the first API response of a session. Writing that script is a small job, and ccclub ships one if you would rather not.

Step 3: know where the raw data is

Everything past this point reads the same source: the JSONL transcripts Claude Code writes under ~/.claude/projects/, one directory per project and one file per session. Every assistant response in those files carries the model it used and its token counts. You can grep them yourself; it is not pleasant, but it means no tool below needs any access you have not already granted it, and it means you can verify any claim any of them makes.

If you have set CLAUDE_CONFIG_DIR, or your install uses ~/.config/claude/projects, that is where to look instead. Tools that read these files check both locations.

Step 4: turn the files into a dated history

The transcripts have no notion of "last week". Something has to sum them. For your own numbers only, ccusage is the established choice and uploads nothing. For a history that also compares against other people, this is ccclub, and setup is one command:

npx ccclub init

That asks for a display name, creates a group with a six-letter invite code, detects which agents you have logs for, and installs the automatic sync. No account, no email, no configuration file to edit. Once it has run:

ccclub                 # today
ccclub -d 1            # yesterday
ccclub -d 7            # last 7 days
ccclub -d 30           # last 30 days
ccclub -d all          # everything synced
ccclub --json          # the same data as JSON, for scripts and agents

The same periods are on the web page every group gets at ccclub.dev/g/CODE. For the shape of your year rather than a table, ccclub activity draws a heatmap of the last 53 weeks straight from local logs, with no network call at all.

Step 5: check what leaves the machine, before it does

Anything that compares you with other people has to send something. Run ccclub show-data and it prints the last five 30-minute blocks in full, field by field: token counts, the estimated cost, model names, call and turn counts, under a heading saying that is exactly what gets uploaded. Those five are a sample, not the payload — what follows them is a set of all-time totals. But the sample is the point: every other block carries the same fields, and nothing else is uploaded either. No prompts, no code, no file paths, no project names. Reading that output takes a minute and is a better basis for trusting the tool than any sentence on this page.

Step 6: read the number you got

Three things trip people up at the end of this, and all three are about interpretation rather than measurement.

• The big total is mostly cache. Cache reads and writes are counted alongside input and output, and on long sessions they dominate everything else. ccclub --no-cache drops to input plus output; the two numbers will not be close, and neither is wrong. Why that gap exists is covered in what a usage number counts.
• The dollar figure is not a bill. On a subscription nothing is charged per token, so every tool showing dollars is pricing your tokens at public API list rates. It is a useful unit for comparison and a bad one for accounting — see how the estimate is built.
• One machine is one machine. Both the built-in screen and any local tool see the logs in front of them. If you use Claude Code on two computers, you have two partial answers, and only syncing them somewhere gives you one.

And the ceiling question is a different question. If what you actually want to know is how much of your allowance is left rather than how much you have used, that lives in the rate-limit windows, not in any of the totals above.

Last updated 2026-09-29. Corrections welcome on GitHub.