Claude Code Costs and Token Usage

TL;DR

Claude Code meters usage whether you feel it or not: subscription plans have rolling usage windows and weekly caps, and API billing is per token. Usage monitors tell you how fast you are burning, and the good ones are worth installing, but no monitor reduces the burn. The structural fix is routing the work that does not need a frontier model to models you run yourself. With an Anthropic-compatible local router, that is one environment variable.

How Claude Code usage actually works

There are two billing models, and they fail differently.

• Subscription plans meter by rolling usage windows plus weekly caps. A heavy agentic session can exhaust a window mid-afternoon, and then you wait for the reset. Anthropic does not publish the exact token math behind the windows, which is exactly why burn-rate prediction tools exist.
• API billing is per token, by model. Nothing stops mid-task, but the invoice scales with the two things agentic coding produces most: long contexts and many turns.

Claude Code ships some visibility of its own:

The monitors people install, and the gap they fill

Native tooling answers "what did this session cost". The questions people actually have are "will I hit my limit before it resets" and "what did this month look like". Every Claude Code session writes a transcript under ~/.claude as plain JSONL, so a small ecosystem grew up parsing those files:

• ccusage: daily, monthly, and per-project rollups from your local transcripts. Its signature trick is pricing subscription usage at API rates, which answers whether the plan pays for itself.
• Claude Code Usage Monitor: a live terminal dashboard that watches burn rate and predicts when the current window runs out, which is the actual anxiety.
• Dashboards like claude-usage and codeburn, for people who want the same data on a web page, or across multiple coding agents.

Install one. The visibility is free and the transcripts are already on your disk. Just be clear about what you bought: a monitor is a smoke alarm, not a sprinkler.

What actually burns the tokens

Agentic sessions are expensive for structural reasons, not because you are doing anything wrong:

• Context is resent every turn. The conversation, the system prompt, and every tool definition ride along on each request. Prompt caching cuts the reprocessing cost, but the session still grows.
• Tool results accumulate. File reads, test output, and build logs land in context and get carried forward long after they stopped being useful.
• Background calls add up. Summaries, titles, and subagent chores are cheap individually and constant in aggregate.
• Retries multiply all of the above. A flaky loop that needs three attempts sends the whole context three times.

That leaves two levers: send fewer tokens per request, or send some requests somewhere that does not meter. The first is tuning and it helps at the margins. The second is the structural fix.

Route the routine work to your own Macs

Claude Code lets you change its API endpoint. Point it at a local router and the session runs on models you host, where a token costs nothing:

export ANTHROPIC_BASE_URL=http://localhost:11435
export ANTHROPIC_AUTH_TOKEN=dummy   # any non-empty value
claude

That endpoint is Ollama Herd: full tool use, streaming, and the standard agentic loop against Ollama and MLX models spread across every Mac you own. Claude Code's own model IDs resolve automatically to the best local model your fleet has loaded, so there is no mapping to maintain.

The honest tradeoff: a 30B local coding model is not a frontier model, and this page is not going to pretend otherwise. The split that works in practice is to keep a paid session for architecture, gnarly debugging, and anything you would escalate to a senior engineer, and hand the grind to the fleet: boilerplate, tests, refactors, doc passes, first drafts. The grind is where most of the token volume lives, which is why offloading it moves the bill. Local burn costs electricity and nothing else, and the break-even math tilts further toward local the more agents you run in parallel.

Long local sessions stay viable because the router does its own three-layer context management, clearing stale tool results and compacting history before your local model's context window becomes the limit. The same guide covers the token-saving knobs, like dropping tool definitions your session never uses. And if you are choosing hardware or models for the local side, start with what actually runs well on Apple Silicon.

Questions people actually ask

How do I check my Claude Code token usage?

Inside Claude Code: /cost for the current session, /usage for your plan window. For history, ccusage reads the transcripts already on your disk and rolls them up by day, month, and project.

Why do I hit Claude Code usage limits so quickly?

Because agentic loops resend a growing context every turn and carry tool output forward. It is structural. A monitor makes the burn visible; only sending less, or sending it somewhere unmetered, makes it smaller.

Can I run Claude Code without paying per token?

Yes: change ANTHROPIC_BASE_URL to a local router and the session runs on your own machines. Most people run a local session alongside their paid one rather than instead of it, and split the work by difficulty.

Do local models make Claude Code worse?

For the hardest work, yes, and you should keep using the frontier model there. For routine work, current local coding models hold up well, and routine work is most of the volume. The Claude Code guide documents exactly what works and what breaks.