How much does Claude Code actually cost per day

A full day of Claude Code on API billing lands somewhere between $6 and $60 for one developer, and the spread is not about how much you type. Light use, meaning a handful of scoped edits and questions, sits near the bottom. A day of agentic work across a large repo, with long autonomous runs and lots of file reads, sits near the top. I have seen individual hours cross $15 when an agent got stuck re-reading the same directory tree.

The number that decides where you land is not lines of code written. It is how many input tokens get re-sent, at what price per million, and how many of them hit the prompt cache. Output is a rounding error by comparison. If you want one sentence to budget against: assume $20 to $30 per developer per day on Opus-tier API billing for real project work, and expect a subscription plan to be cheaper than that for most people.

The actual per-token prices

These are Anthropic first-party API rates per million tokens, as of August 2026. Amazon Bedrock and Vertex AI are partner-operated and priced separately.

• Claude Opus 5: $5 input, $25 output
• Claude Sonnet 5: $3 input, $15 output (introductory $2 / $10 through 2026-08-31)
• Claude Haiku 4.5: $1 input, $5 output
• Cache read: roughly 0.1x the base input price
• Cache write: 1.25x base input for the 5-minute TTL, 2x for the 1-hour TTL

Look at the cache rows again, because they are the whole story. A cached input token on Opus costs about 50 cents per million instead of $5. A ten-to-one difference on the single largest line item in your bill.

Why the bill is almost entirely input

The API is stateless. Every turn re-sends the entire conversation: system prompt, tool definitions, every file the agent read, every tool result, every previous message. A coding session that has been running for forty minutes might carry 120,000 tokens of context, and every single turn pays for all of it again.

Meanwhile the agent writes maybe 800 tokens of response. On Opus, 120,000 uncached input tokens cost 60 cents. The 800 output tokens cost two cents. That ratio is why people are surprised by their bill: they are budgeting for what the model wrote, and they are being charged for what it read.

Prompt caching is what makes any of this affordable, and Claude Code uses it. But caching is a prefix match, so it only holds while the front of the prompt stays byte-identical. Anything that shifts the prefix invalidates everything after it. Switching models mid-session invalidates the whole cache, because caches are model-scoped. Changing the tool set invalidates it, because tools render at position zero. A cache entry also expires after five minutes by default, so a coffee break costs you a full-price re-read on the next turn.

A worked day

Take a realistic session shape: 60 turns over a working day, averaging 90,000 tokens of context per turn, with an 85 percent cache hit rate, on Opus.

• Total input tokens re-sent across the day: 5.4 million
• Cached portion (85 percent): 4.59M at ~$0.50/M = $2.30
• Uncached portion: 810K at $5/M = $4.05
• Cache writes: roughly 500K at $6.25/M = $3.13
• Output: 60 turns x 900 tokens = 54K at $25/M = $1.35
• Day total: about $10.80

Now drop the cache hit rate to 40 percent, which is what happens when a session keeps getting interrupted, restarted, or is spread across three parallel worktrees that each rebuild their own context. The uncached input jumps to 3.24M tokens, which alone is $16.20, and the day lands near $25. Same work. Same code shipped. Two and a half times the bill, purely from cache behaviour.

That is the most useful thing I can tell you about budgeting for Claude Code: the variance between a cheap day and an expensive day is mostly cache hit rate and model tier, not effort.

Subscription plans versus API billing

Claude Code can run on a Claude subscription (Pro, Max 5x, Max 20x) instead of pay-as-you-go API credits. For a single developer doing consistent daily work, a subscription is usually cheaper than metered API billing, because the arithmetic above compounds fast. The subscription trade is throughput: you get usage windows rather than a hard dollar cap, so heavy days can hit a limit and pause you rather than quietly charging you $60.

The pattern I see most often is the opposite mistake to the one people expect. Not underpaying, but sitting on a tier well above what the usage actually justifies, because nobody went back and checked after the first heavy month. Whichever billing mode you are on, the fix is the same: measure your real token volume for two weeks before you decide anything.

How to measure your own number

Do not budget from someone else's blog post, including this one. Your repo size, your effort setting, and how often you restart sessions will move the number more than any general estimate. Options, roughly in order of effort:

• The /cost command inside Claude Code gives you the current session total. Fastest answer, no setup, but only covers the session you are in.
• Reading the local JSONL transcripts Claude Code writes to disk. Free, complete, and tedious. Tools like ccusage do this parsing for you.
• A proxy that records every request as it passes through. Catches every tool on the machine, not just Claude Code, and attributes cost to the process that made the call.

What Probe0 does about it

I built Probe0 because I got tired of finding out what a week cost after the week was over. It runs entirely on my machine, as a local proxy plus a certificate installed once, and every coding agent CLI on the box routes through it: Claude Code, Codex, Cursor. There is no Probe0 server, so nothing about my traffic leaves the laptop.

The part that answers this article's question is Recording: a full ledger of every request with model, token counts, real cost, latency, and which process made the call. That turns "what does Claude Code cost per day" from an estimate into a query. Because it knows actual usage, it can also tell you when you are paying for a plan tier above what you use.

The modules that move the number are separately switchable, and each reports what it saved: Exact Cache serves byte-identical repeats from local disk without touching the network, Semantic Cache matches near-identical prompts against a local vector index (with a strict similarity floor, and it refuses to match anything carrying tool calls, because a wrong hit corrupts a run), Request Coalescing collapses simultaneous identical calls into one upstream request, Model Tiering sends the cheap model first, and Local Routing hands work to a model already running in Ollama or LM Studio with weak answers auto-retried on the cloud. Spend Guard sets a hard cap per run or per day: it warns, then pauses.

Honest limits: macOS only, private beta, single-developer tool. It is not a team gateway, and provider coverage is what coding agents actually call rather than a hundred-provider catalogue. If you need multi-user deployment with shared budgets and audit trails, a hosted gateway is the right shape and Probe0 is not.

Two developers on the same team, same repo, same model, can differ by 3x on daily spend. The expensive one is almost never working harder. They are just rebuilding context more often.

If you take one action from this: check your cache hit rate before you change your plan. It is the cheapest lever available and most people have never looked at it.