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.

Opus 5.5 tokens per second: October 19, 2026 update

We reran the measurement on the last four complete weeks: September 21 through October 18, 2026 (UTC). We included the default transcript directory and the additional Claude profiles used by AgentsRoom, then counted each request only once across files.

The fixed time is the intercept of a least-squares fit of elapsed seconds against output tokens. It is an estimate of per-turn overhead, not a price or a direct measurement of time to first token. Thinking is included in both rates.

This update also corrects the timer. A direct parent can be a technical attachment, including deferred_tools_record, written while the answer is already arriving. In one request, the old method divided 562 tokens by 0.046 seconds, yielding over 12,000 tok/s. Following the parent chain back to the triggering user message or tool result restores roughly seven seconds of elapsed time. With that correction and request deduplication, no Opus 5.5 request in this window exceeds 400 tok/s; we did not filter out high rates.

The September tables below remain the original measurement. Their 94.9 tok/s median and 109.3 tok/s weighted rate use the old timer and a different sample, so the difference is not evidence that Opus 5.5 became slower. These figures describe our workloads, network and transcript timestamps, not an isolated model benchmark.

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 to the preceding event, which can be a technical attachment written during the response. Follow the chain past attachment, system and progress events to the triggering user message or tool result; its timestamp is a proxy for the start of the turn.
• 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, follow its parent chain to the triggering user message or tool result, and divide output tokens by elapsed seconds up to the last assistant line. Count a request once across files, and report each model and speed setting separately. These timestamps include local overhead; they do not isolate API generation time.

We drop turns with no output tokens, missing triggers, non-positive durations or durations above fifteen minutes. The script below uses the dated update window, with an inclusive start and exclusive end in UTC. Change START and END to measure another period.

The updated script requires Python 3.10 or later and no extra dependencies. Run it from anywhere; it reads the default projects and the additional local Claude profiles without uploading their contents.

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

START, END = "2026-09-21", "2026-10-19"  # UTC, end exclusive
PATTERNS = ("~/.claude/projects/*/*.jsonl",
            "~/.agentsroom/claude-profiles/*/projects/*/*.jsonl")

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

def read_session(path):
    by_uuid, groups = {}, defaultdict(list)
    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"):
                groups[o.get("requestId") or o["uuid"]].append(o)
    return by_uuid, groups

def trigger(first, by_uuid):
    parent, visited = by_uuid.get(first.get("parentUuid")), set()
    while parent and parent.get("type") in ("attachment", "system", "progress"):
        uid = parent.get("uuid")
        if uid in visited: return None
        visited.add(uid)
        parent = by_uuid.get(parent.get("parentUuid"))
    return parent if parent and parent.get("type") == "user" else None

by_model, seen = defaultdict(list), set()
for pattern in PATTERNS:
    for path in glob.glob(os.path.expanduser(pattern)):
        by_uuid, groups = read_session(path)
        for rid, blocks in groups.items():
            first, last = blocks[0], blocks[-1]
            if rid in seen or not START <= first["timestamp"] < END: continue
            usage = first["message"]["usage"]
            out, parent = usage.get("output_tokens", 0), trigger(first, by_uuid)
            if not parent or not parent.get("timestamp") or out <= 0: continue
            dur = ts(last["timestamp"]) - ts(parent["timestamp"])
            if not 0 < dur <= 900: continue
            seen.add(rid)
            thinking = (usage.get("output_tokens_details") or {}).get("thinking_tokens", 0)
            key = first["message"].get("model"), usage.get("speed", "unknown")
            by_model[key].append((out, dur, thinking))

for (model, speed), rows in sorted(by_model.items(), key=lambda kv: -len(kv[1])):
    outputs, durations, thinking = zip(*rows)
    median = st.median(o / d for o, d, _ in rows)
    weighted = sum(outputs) / sum(durations)
    overhead = st.linear_regression(outputs, durations).intercept if len(set(outputs)) > 1 else float("nan")
    print(f"{model} {speed}: turns={len(rows)} median={median:.1f} "
          f"weighted={weighted:.1f} tok/s overhead={overhead:.2f}s "
          f"thinking={100 * sum(thinking) / sum(outputs):.1f}%")

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 Opus 5.5 generate?

In our measurement updated on October 19, 2026, Claude Opus 5.5 delivered a median 89.4 output tokens per second across 30,119 unique requests from September 21 to October 18, all at standard speed. Total output tokens divided by total elapsed seconds gives 97.5 tok/s. Thinking accounts for 42.1% of output tokens. These are end-to-end transcript measurements from our own sessions, not a universal streaming-speed benchmark.

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.