How Fast Is Claude Code? Tokens per Second, Measured on 20,000 Turns

Claude Code tells you a lot about tokens. /usage shows how much of the session and of the week you have used, the session monitor in AgentsRoom counts input, output, cache reads and cache writes turn by turn, and the status line can print the share of the context window in use. None of them prints the one number people keep searching for: how many tokens per second the model actually produces while you wait.

The number is not hidden, it is just never computed. Every message of every session lands in a JSONL transcript under ~/.claude/projects/, and each assistant message carries a timestamp and its token usage. So we computed it, on our own machine, over the last four weeks. This is the method, the script, and what came out.

Where the data comes from

Claude Code writes one file per session in ~/.claude/projects/<project slug>/<session id>.jsonl. One line per event. The lines that matter here are the assistant messages, and each one looks like this once you keep the useful fields:

{
  "type": "assistant",
  "uuid": "24d13076-…",
  "parentUuid": "d4447285-…",
  "requestId": "req_011CepWq…",
  "timestamp": "2026-09-07T18:00:08.412Z",
  "message": {
    "model": "claude-opus-5",
    "usage": {
      "input_tokens": 2,
      "cache_read_input_tokens": 0,
      "cache_creation_input_tokens": 51591,
      "output_tokens": 200,
      "output_tokens_details": { "thinking_tokens": 0 },
      "speed": "standard"
    }
  }
}

Four things make the measurement possible:

• timestamp is written when the content block is appended, so the last block of a turn is dated at the end of the stream.
• parentUuid points at the line that came just before, the user message or the tool result the model was answering. Its timestamp is the moment the request left.
• requestId groups the blocks of one API call. A turn that writes some text and then calls a tool produces two assistant lines with the same requestId and the same usage, so tokens must be counted once per request, not once per line.
• usage.output_tokens is the total output of the request, thinking included; output_tokens_details.thinking_tokens says how much of it was thinking.

Nothing in the file gives the time to first token. What you can measure is the whole turn: from the request leaving your machine to the last token arriving. That is also the only number you feel while you wait, so it is the one we kept.

The method

For each requestId: take the first and last assistant lines that carry it, read the usage from the first, find the parent of the first line, and divide the output tokens by the seconds between the parent's timestamp and the last line's timestamp. Then look at the distribution per model, never at a single average, because a 40-second turn and a 2-second turn are not the same object.

We dropped turns with no output tokens, turns with a non-positive duration (a resumed session can have a parent dated after its child) and turns longer than fifteen minutes, which are interrupted sessions rather than long answers. Nothing else was filtered.

The script is 40 lines of Python with no dependency. Run it from anywhere; it reads every project on the machine.

import json, glob, os, statistics as st
from datetime import datetime
from collections import defaultdict

def ts(s): return datetime.fromisoformat(s.replace("Z", "+00:00")).timestamp()

turns = []
for path in glob.glob(os.path.expanduser("~/.claude/projects/*/*.jsonl")):
    by_uuid, groups, order = {}, {}, []
    with open(path) as fh:
        for line in fh:
            try: o = json.loads(line)
            except ValueError: continue
            if "uuid" in o: by_uuid[o["uuid"]] = o
            msg = o.get("message") or {}
            if o.get("type") == "assistant" and msg.get("usage") and o.get("timestamp"):
                rid = o.get("requestId") or o["uuid"]
                if rid not in groups: groups[rid] = []; order.append(rid)
                groups[rid].append(o)
    for rid in order:
        first, last = groups[rid][0], groups[rid][-1]
        out = first["message"]["usage"].get("output_tokens", 0)
        parent = by_uuid.get(first.get("parentUuid"))
        if not parent or not parent.get("timestamp") or out <= 0: continue
        dur = ts(last["timestamp"]) - ts(parent["timestamp"])
        if 0 < dur <= 900:
            turns.append((first["message"].get("model"), out, dur))

by_model = defaultdict(list)
for model, out, dur in turns: by_model[model].append((out, dur))
for model, rows in sorted(by_model.items(), key=lambda kv: -len(kv[1])):
    rates = [o / d for o, d in rows]
    print(f"{model:18s} turns={len(rows):6d} median={st.median(rates):5.1f} tok/s "
          f"weighted={sum(o for o, _ in rows) / sum(d for _, d in rows):5.1f} tok/s")

The weighted column is total tokens divided by total seconds. It is what a long autonomous run experiences; the median is what a single interactive turn experiences.

The numbers

One Mac in France, 319 transcripts, 20,408 turns between August 27 and September 25, 2026, 12.0 million output tokens produced in 45 hours of generation. Standard speed on every turn (see fast mode below). Five models appear in the transcripts under the names Claude Code writes.

Two readings before anything else. First, Opus 5.5 is not a little faster than Opus 5, it is half as fast again on the median and 57% faster on the weighted figure, at a much higher share of long turns. Second, the spread within a model is wider than the gap between models: an Opus 5 turn at the 25th percentile streams at 51 tokens per second and one at the 75th at 72. The reason is the size of the turn, and it deserves its own section.

A short answer is always slower

Here is Opus 5 again, cut by the number of output tokens in the turn:

Same model, same month, same machine, and the rate doubles between a one-line answer and a long one. The model does not stream faster on long turns. Every turn pays a fixed cost before the first token shows up: the request goes out, the prompt is processed, the stream starts. On an 80-token turn that cost is a third of the elapsed time; on a 3,000-token turn it vanishes in the noise.

A least-squares fit of duration against output tokens separates the two. The slope gives the streaming speed, the intercept gives the fixed cost:

So when a tool-call heavy session feels slow, it is rarely the model's throughput. It is the number of turns. An agent that reads twelve files one by one pays twelve fixed costs; the same agent reading them in one batched call pays one. That is the same lesson as reducing token costs: fewer, larger turns, not a faster model.

The longest single turn of the corpus is 21,332 output tokens in 236 seconds on Opus 5, which is 90 tokens per second end to end: once the fixed cost is amortised, that is the ceiling we observed on that model at standard speed.

Thinking tokens are output tokens

output_tokens includes the thinking the model does before answering, and output_tokens_details.thinking_tokens tells you how much. In our corpus thinking is 30% of everything Opus 5 produced, 18% for Opus 5.5, 36% for Fable 5.1, and 54% for Sonnet 5, which we mostly ran at a higher effort level on review tasks.

That matters for reading a slow turn. A turn that thinks for eight seconds and prints two lines is not a slow model, it is a turn that produced 600 tokens you never saw. Turns with thinking are, per token, slightly faster than turns without: 67 against 57 tokens per second on Opus 5, because they are longer and amortise the fixed cost better. If a session feels sluggish and you do not need the reasoning, the effort level is the lever, not the model.

Cache reads change the bill, not the rate

Almost every turn in Claude Code hits the prompt cache: only 130 of the 16,680 Opus 5 turns had cache_read_input_tokens at zero, and those are the first turn of a session. On turns of 100 to 500 output tokens, the cached ones stream at a median 60.6 tokens per second and take 3.4 seconds; the uncached ones stream at 58.0 and take 3.7 seconds. The difference is real but small, and it sits in the fixed cost, not in the streaming speed. Caching is about the price of the context you carry, which is why the token counter in the AgentsRoom terminal shows cache reads and cache writes as separate figures.

Stable over the month

A cumulative number can hide a drift, so we also looked at the weekly median of Opus 5 on turns of 100 to 500 tokens, the most common kind: 63.6, 64.1, 60.9, 61.7, 56.9 tokens per second week after week, then 68.7 on the partial last week. Between 57 and 69, no trend. If your sessions feel slower one afternoon, it is worth running the script on that day alone before blaming the model.

What fast mode changes, and what we could not measure

Every usage block carries a speed field, and all 20,408 of ours say standard. Anthropic documents a fast mode for Claude Opus, toggled with /fast in the CLI or "fastMode": true in the user settings, that makes the model up to 2.5 times faster at a higher price per token: 8 dollars per million input tokens and 40 per million output tokens on Opus 5.5, 10 and 50 on Opus 5 and Opus 4.8. On Pro and Max plans it is billed to usage credits, outside the subscription windows; Sonnet and Haiku do not support it, and turning it on switches you to Opus. A lightning icon next to the prompt says it is on.

We have not paid for it, so we have no measured figure to put next to the documented 2.5 times. If you do run it, the same script tells you what you got: filter the turns on usage["speed"] == "fast" and compare the medians. Send us the numbers.

What this changes in how we run agents

Three things, none of them about picking a faster model.

The first is about expectations. If a night run of seven agents produces two million output tokens, that is eight hours of generation at 70 tokens per second, spread across agents that run in parallel. Knowing the rate is what lets you say whether a scheduled task can finish before the next one starts.

The second is about turns. The fixed second per turn is the same on a 30-token confirmation and on a 3,000-token diff. Agents that ask before every small step, or that read files one at a time, spend their time in that second. It is why we write "batch your independent reads" into the prompts of the agents that run unattended.

The third is about what the counter should show. The session monitor in AgentsRoom shows tokens and cache, and turns red when a session gets heavy; it does not show a rate, and after this measurement we are not sure it should. A rate is a property of the model and of the turn size, not of the session, and the number a developer needs is the one in the tables above. That is why this is an article and not a widget.

Frequently asked questions

How many tokens per second does Claude Code generate?

On our 20,408 turns recorded between August 27 and September 25, 2026: Opus 5 has a median of 63 output tokens per second (69 when you divide all tokens by all seconds), Opus 5.5 95 (109), Sonnet 5 77 (87), Fable 5.1 75 (80) and Opus 4.8 61 (64). Those figures count the whole turn, from the moment the request leaves your machine to the last streamed token, so they are what you actually wait for.

Does /usage or /cost show tokens per second?

No. /usage shows your plan quota, the 5-hour and weekly windows and the share of the context window in use; /cost is an alias of /usage. Neither prints a rate. The only place the speed exists is the session transcript under ~/.claude/projects/, where every assistant message carries a timestamp and its output token count. That is what the script in this article reads.

Why does a short answer feel slower than a long one?

Because every turn pays a fixed cost before the first token arrives: uploading the request, processing the prompt, starting the stream. In our data that overhead is about one second on Opus 5 and Opus 5.5 and half a second on Sonnet 5. On an 80-token answer, one second is a third of the turn, so the measured rate drops to 40 tokens per second; on a 3,000-token answer the same second disappears and the rate climbs to 80 or more. The streaming speed itself is constant.

Do thinking tokens count in the speed?

Yes. The usage block of each message reports output_tokens with an output_tokens_details.thinking_tokens breakdown, and the thinking tokens are part of output_tokens. In our corpus they are 30% of everything Opus 5 produced, 18% for Opus 5.5 and 54% for Sonnet 5, which mostly ran on a higher effort level. A turn that thinks for a long time is not slow, it is producing tokens you do not see.

Does prompt caching make Claude Code faster?

Not the output rate. On turns of 100 to 500 tokens, Opus 5 streams at a median 60.6 tokens per second when the request hits the prompt cache and 58.0 when it does not, and the whole turn takes 3.4 seconds against 3.7. Caching is about what you pay for the context, not about how fast the answer comes out.

What is Claude Code fast mode, and how much faster is it?

A configuration of Claude Opus that Anthropic documents as up to 2.5 times faster, at a higher price per token: 8 dollars per million input tokens and 40 per million output tokens on Opus 5.5, 10 and 50 on Opus 5 and Opus 4.8, billed to usage credits rather than to the subscription windows. You toggle it with /fast, and a small lightning icon appears next to the prompt. None of the 20,408 turns we measured ran in fast mode (every transcript says speed: standard), so we have no measured figure for it; the numbers in this article are standard speed.