TKN.

What Claude Code actually costs (and how to see it)

Last verified

Claude Code records everything it spends, locally, in a format you can read. Every assistant turn is appended to a JSONL file under ~/.claude/projects/ with the full usage block — input, output, cache writes and cache reads. No API key needed to read it, because it is already on your disk.

The fastest way to see the number:

npx @tknapp/cli agents --days 30

That reads the logs, prices them against published rates, and prints spend by day. It makes no network call.

Where the data lives

~/.claude/projects/<encoded-project-path>/<session-id>.jsonl

Each line is a JSON record. The ones that cost money have "type": "assistant" and a message.usage object:

{
  "type": "assistant",
  "requestId": "req_...",
  "timestamp": "2026-08-04T21:37:09.000Z",
  "cwd": "/home/you/project",
  "sessionId": "b7b07e33-...",
  "gitBranch": "main",
  "isSidechain": false,
  "message": {
    "id": "msg_...",
    "model": "claude-opus-5",
    "usage": {
      "input_tokens": 2,
      "output_tokens": 251,
      "cache_read_input_tokens": 0,
      "cache_creation_input_tokens": 36009,
      "cache_creation": {
        "ephemeral_5m_input_tokens": 0,
        "ephemeral_1h_input_tokens": 36009
      }
    }
  }
}

If CLAUDE_CONFIG_DIR is set, the directory moves with it.

The five numbers, and why they are priced differently

This is where a naive calculation goes wrong. There is not one input rate — there are four, and they differ by up to 20×.

FieldWhat it isRate, relative to base input
input_tokensFresh, uncached input1×
cache_creation → ephemeral_5m_input_tokensWritten to the 5-minute cache1.25×
cache_creation → ephemeral_1h_input_tokensWritten to the 1-hour cache2×
cache_read_input_tokensServed from cache0.1×
output_tokensGeneratedOutput rate (≈5× base input)

Two things follow.

Cache reads dominate the token count and not the cost. In a real long session, cache reads routinely account for 95%+ of all input tokens — but at 0.1× they contribute a fraction of what their volume suggests. Sum the token counts and you'll wildly over-estimate; ignore them and you'll under-estimate.

Cache writes are the expensive input. The 1-hour cache costs 2× base input. It pays for itself after two reads — which in a working session it comfortably does — but a session that writes a large cache and then ends immediately has paid a premium for nothing.

Doing the arithmetic

For Claude Opus 5 (verified 2026-08-05: $5 input, $25 output, $6.25 5m-write, $10 1h-write, $0.50 cache-read, all per million tokens):

RATES = {"input": 5.0, "output": 25.0, "w5": 6.25, "w1": 10.0, "read": 0.50}

def cost(u):
    cc = u.get("cache_creation") or {}
    w5, w1 = cc.get("ephemeral_5m_input_tokens"), cc.get("ephemeral_1h_input_tokens")
    split = w5 is not None or w1 is not None
    vals = {
        "input":  u.get("input_tokens", 0),
        "output": u.get("output_tokens", 0),
        "w5":     (w5 or 0) if split else u.get("cache_creation_input_tokens", 0),
        "w1":     (w1 or 0) if split else 0,
        "read":   u.get("cache_read_input_tokens", 0),
    }
    return sum(v / 1e6 * RATES[k] for k, v in vals.items())
Deduplicate on requestId

Resuming a session or retrying a request re-appends the same assistant record. Counting it twice inflates your total, and it is the single most common way a homemade calculator ends up wrong. Key on requestId + message.id and skip repeats.

A worked example

From a real 178-request Claude Code session on Claude Opus 5:

TokensCost
Input (fresh)331$0.00
Output308,900$7.72
Cache writes (1h)1,130,223$11.30
Cache reads57,690,000$28.85
Total59.1M$47.88

Read that table twice. Cache reads are 98% of the tokens and 60% of the cost. Output is 0.5% of the tokens and 16% of the cost. Fresh input is a rounding error.

That shape is typical, and it explains almost everything about why Claude Code feels expensive — you are not paying for what you typed, you are paying to re-read the conversation on every turn.

What /cost does and doesn't show

/cost reports the current session, and only for API-billed users. On a Pro or Max plan it does not show a dollar figure, because there isn't one — usage draws against plan quota instead.

It also doesn't give you history, per-project totals, or a trend. That's what the log files are for.

Subscription plan vs API billing

Worth being clear, because it decides whether any of this applies to you:

  • Pro / Max plan — usage draws against a plan quota. No per-token charge. Token counts in the logs are real, but converting them to dollars tells you what the same work _would_ have cost on the API, not what you were charged.
  • API billing — metered per token. The log figures are your actual spend.

If you're on a plan and want to know whether the API would be cheaper, the log-derived figure is exactly the comparison you need — subscription plan vs pay-per-token.

Other tools

ccusage is the widely-used reference implementation and is excellent — see ccusage alternatives for an honest comparison. cccost and token-meter cover similar ground.

tokn agents is TKN's version. It differs in one way that may or may not matter to you: the same tool also reads your metered API spend across OpenAI, Anthropic, xAI and Gemini, so agent cost and API cost land in one place. If you only want Claude Code numbers, ccusage is a fine answer and we'd say so.

Sources

Related