Qual a velocidade do Claude Code? Tokens por segundo, medidos em 20.000 turnos

O Claude Code conta muita coisa sobre tokens. O /usage mostra quanto você já usou da sessão e da semana, o monitor de sessão do AgentsRoom conta entrada, saída, leituras e gravações de cache turno a turno, e a linha de status pode mostrar a parte da janela de contexto em uso. Nenhum deles mostra o número que as pessoas continuam procurando: quantos tokens por segundo o modelo realmente produz enquanto você espera.

O número não está escondido, só nunca é calculado. Cada mensagem de cada sessão vai parar numa transcrição JSONL em ~/.claude/projects/, e cada mensagem do assistente traz um timestamp e o seu consumo de tokens. Então nós calculamos, na nossa própria máquina, nas últimas quatro semanas. Este é o método, o script e o que saiu disso.

Tokens por segundo do Opus 5.5: atualização de 19 de outubro de 2026

Refizemos a medição nas últimas quatro semanas completas: de 21 de setembro a 18 de outubro de 2026 (UTC). Incluímos o diretório de transcrições padrão e os perfis adicionais do Claude usados pelo AgentsRoom, e depois contamos cada requisição uma única vez entre todos os arquivos.

O tempo fixo é o intercepto de um ajuste por mínimos quadrados dos segundos decorridos em função dos tokens de saída. É uma estimativa da sobrecarga de tempo por turno, não um preço nem uma medição direta do tempo até o primeiro token. O raciocínio está incluído nos dois ritmos.

Esta atualização também corrige a cronometragem. O pai direto pode ser um anexo técnico, incluindo deferred_tools_record, gravado quando a resposta já está chegando. Em uma requisição, o método antigo dividia 562 tokens por 0,046 segundo, o que dava mais de 12.000 tok/s. Seguir a cadeia de pais até a mensagem do usuário ou o resultado da ferramenta que disparou o turno recupera cerca de sete segundos de tempo decorrido. Com essa correção e a deduplicação das requisições, nenhuma requisição do Opus 5.5 neste período passa de 400 tok/s; não filtramos os ritmos altos.

As tabelas de setembro mais abaixo continuam sendo a medição original. A mediana de 94,9 tok/s e o ritmo ponderado de 109,3 tok/s delas usam a cronometragem antiga e uma amostra diferente, então a diferença não prova que o Opus 5.5 ficou mais lento. Esses números descrevem as nossas cargas de trabalho, a nossa rede e os timestamps das transcrições, não um benchmark do modelo isolado.

De onde vêm os dados

O Claude Code grava um arquivo por sessão em ~/.claude/projects/<project slug>/<session id>.jsonl. Uma linha por evento. As linhas que importam aqui são as mensagens do assistente, e cada uma fica assim quando você mantém só os campos úteis:

{
  "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"
    }
  }
}

Quatro coisas tornam a medição possível:

• timestamp é gravado quando o bloco de conteúdo é adicionado, então o último bloco de um turno fica datado no fim do streaming.
• parentUuid aponta para o evento anterior, que pode ser um anexo técnico gravado durante a resposta. Siga a cadeia passando pelos eventos attachment, system e progress até a mensagem do usuário ou o resultado da ferramenta que disparou o turno; o timestamp desse evento serve como aproximação do início do turno.
• requestId agrupa os blocos de uma mesma chamada de API. Um turno que escreve algum texto e depois chama uma ferramenta produz duas linhas de assistente com o mesmo requestId e o mesmo usage, então os tokens devem ser contados uma vez por requisição, não uma vez por linha.
• usage.output_tokens é a saída total da requisição, raciocínio incluído; output_tokens_details.thinking_tokens diz quanto disso foi raciocínio.

Nada no arquivo informa o tempo até o primeiro token. O que dá para medir é o turno inteiro: da requisição saindo da sua máquina até a chegada do último token. É também o único número que você sente enquanto espera, então foi o que mantivemos.

O método

Para cada requestId: pegue a primeira e a última linha de assistente que o contêm, leia o usage da primeira, siga a cadeia de pais dela até a mensagem do usuário ou o resultado da ferramenta que disparou o turno, e divida os tokens de saída pelos segundos decorridos até a última linha de assistente. Conte cada requisição uma única vez entre os arquivos e apresente cada modelo e cada configuração de velocidade separadamente. Esses timestamps incluem a sobrecarga local: eles não isolam o tempo de geração da API.

Descartamos os turnos sem tokens de saída, sem mensagem de disparo encontrada, com duração negativa ou zero, ou com duração acima de quinze minutos. O script abaixo usa o período da atualização datada, com início incluído e fim excluído, em UTC. Altere START e END para medir outro período.

O script atualizado requer Python 3.10 ou mais recente e nenhuma dependência extra. Rode de qualquer lugar: ele lê os projetos padrão e os perfis locais adicionais do Claude sem enviar o conteúdo deles.

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}%")

A coluna weighted é o total de tokens dividido pelo total de segundos. É o que uma execução autônoma longa vive; a mediana é o que um único turno interativo vive.

Os números

Um Mac na França, 319 transcrições, 20.408 turnos entre 27 de agosto e 25 de setembro de 2026, 12,0 milhões de tokens de saída produzidos em 45 horas de geração. Velocidade padrão em todos os turnos (veja o modo rápido mais abaixo). Cinco modelos aparecem nas transcrições, com os nomes que o Claude Code grava.

Duas leituras antes de qualquer outra coisa. Primeiro, o Opus 5.5 não é um pouco mais rápido que o Opus 5: é uma vez e meia mais rápido na mediana e 57% mais rápido no número ponderado, com uma parcela bem maior de turnos longos. Segundo, a dispersão dentro de um modelo é maior que a diferença entre modelos: um turno do Opus 5 no percentil 25 gera a 51 tokens por segundo e um no percentil 75 a 72. O motivo é o tamanho do turno, e ele merece uma seção própria.

Uma resposta curta é sempre mais lenta

Aqui está o Opus 5 de novo, dividido pelo número de tokens de saída do turno:

Mesmo modelo, mesmo mês, mesma máquina, e o ritmo dobra entre uma resposta de uma linha e uma longa. O modelo não gera mais rápido nos turnos longos. Cada turno paga um custo fixo de tempo antes de o primeiro token aparecer: a requisição sai, o prompt é processado, o streaming começa. Num turno de 80 tokens esse custo é um terço do tempo decorrido; num turno de 3.000 tokens ele some no ruído.

Um ajuste por mínimos quadrados da duração em função dos tokens de saída separa as duas coisas. A inclinação dá a velocidade de streaming, o intercepto dá o custo fixo:

Então, quando uma sessão cheia de chamadas de ferramentas parece lenta, raramente é a capacidade de geração do modelo. É o número de turnos. Um agente que lê doze arquivos um por um paga doze custos fixos; o mesmo agente lendo todos numa única chamada agrupada paga um. É a mesma lição de reduzir os custos de tokens: menos turnos e maiores, não um modelo mais rápido.

O turno isolado mais longo do corpus tem 21.332 tokens de saída em 236 segundos no Opus 5, ou seja, 90 tokens por segundo de ponta a ponta: com o custo fixo amortizado, é o teto que observamos nesse modelo na velocidade padrão.

Tokens de raciocínio são tokens de saída

output_tokens inclui o raciocínio que o modelo faz antes de responder, e output_tokens_details.thinking_tokens diz quanto. No nosso corpus o raciocínio é 30% de tudo o que o Opus 5 produziu, 18% no Opus 5.5, 36% no Fable 5.1 e 54% no Sonnet 5, que usamos quase sempre com um nível de esforço mais alto em tarefas de revisão.

Isso importa para interpretar um turno lento. Um turno que raciocina por oito segundos e imprime duas linhas não é um modelo lento: é um turno que produziu 600 tokens que você nunca viu. Os turnos com raciocínio são, por token, um pouco mais rápidos que os turnos sem: 67 contra 57 tokens por segundo no Opus 5, porque são mais longos e amortizam melhor o custo fixo. Se uma sessão parece arrastada e você não precisa do raciocínio, a alavanca é o nível de esforço, não o modelo.

Leituras de cache mudam a conta, não o ritmo

Quase todo turno no Claude Code encontra o cache de prompt: só 130 dos 16.680 turnos do Opus 5 tinham cache_read_input_tokens em zero, e esses são o primeiro turno de uma sessão. Em turnos de 100 a 500 tokens de saída, os que usam o cache geram a uma mediana de 60,6 tokens por segundo e levam 3,4 segundos; os que não usam geram a 58,0 e levam 3,7 segundos. A diferença é real mas pequena, e está no custo fixo, não na velocidade de streaming. O cache tem a ver com o preço do contexto que você carrega, e é por isso que o contador de tokens no terminal do AgentsRoom mostra as leituras e as gravações de cache como dois números separados.

Estável ao longo do mês

Um número acumulado pode esconder uma deriva, então também olhamos a mediana semanal do Opus 5 nos turnos de 100 a 500 tokens, os mais comuns: 63,6, 64,1, 60,9, 61,7, 56,9 tokens por segundo semana após semana, e depois 68,7 na última semana, incompleta. Entre 57 e 69, sem tendência. Se suas sessões parecerem mais lentas numa tarde, vale a pena rodar o script só naquele dia antes de culpar o modelo.

O que muda com o modo rápido, e o que não conseguimos medir

Todo bloco usage traz um campo speed, e todos os nossos 20.408 dizem standard. A Anthropic documenta um modo rápido (fast mode) para o Claude Opus, ativado com /fast na CLI ou com "fastMode": true nas configurações do usuário, que deixa o modelo até 2,5 vezes mais rápido a um preço por token mais alto: 8 dólares por milhão de tokens de entrada e 40 por milhão de tokens de saída no Opus 5.5, 10 e 50 no Opus 5 e no Opus 4.8. Nos planos Pro e Max ele é cobrado dos créditos de uso, fora das janelas da assinatura; o Sonnet e o Haiku não suportam o modo, e ativá-lo muda você para o Opus. Um ícone de relâmpago ao lado do prompt indica que ele está ativo.

Nós não pagamos por ele, então não temos um número medido para colocar ao lado das 2,5 vezes documentadas. Se você usar, o mesmo script diz o que você obteve: filtre os turnos por usage["speed"] == "fast" e compare as medianas. Mande os números para a gente.

O que isso muda no jeito como rodamos agentes

Três coisas, e nenhuma delas é escolher um modelo mais rápido.

A primeira tem a ver com expectativas. Se uma execução noturna de sete agentes produz dois milhões de tokens de saída, isso dá oito horas de geração a 70 tokens por segundo, divididas entre agentes que rodam em paralelo. Saber o ritmo é o que permite dizer se uma tarefa agendada consegue terminar antes de a próxima começar.

A segunda tem a ver com os turnos. O segundo fixo por turno é o mesmo numa confirmação de 30 tokens e num diff de 3.000 tokens. Agentes que perguntam antes de cada pequeno passo, ou que leem os arquivos um de cada vez, passam o tempo nesse segundo. É por isso que escrevemos “agrupe suas leituras independentes” nos prompts dos agentes que rodam sem supervisão.

A terceira tem a ver com o que o contador deveria mostrar. O monitor de sessão do AgentsRoom mostra os tokens e o cache, e fica vermelho quando uma sessão fica pesada; ele não mostra um ritmo, e depois desta medição não temos certeza de que deveria. Um ritmo é uma propriedade do modelo e do tamanho do turno, não da sessão, e o número de que um desenvolvedor precisa é o das tabelas acima. É por isso que isto é um artigo e não um widget.

Perguntas frequentes

Quantos tokens por segundo o Claude Opus 5.5 gera?

Na nossa medição atualizada em 19 de outubro de 2026, o Claude Opus 5.5 atingiu uma mediana de 89,4 tokens de saída por segundo em 30.119 requisições únicas de 21 de setembro a 18 de outubro, todas na velocidade padrão. O total de tokens de saída dividido pelo total de segundos decorridos dá 97,5 tok/s. O raciocínio responde por 42,1% dos tokens de saída. São medições de ponta a ponta feitas nas transcrições das nossas próprias sessões, não um benchmark universal de velocidade de streaming.

Quantos tokens por segundo o Claude Code gera?

Nos nossos 20.408 turnos registrados entre 27 de agosto e 25 de setembro de 2026: o Opus 5 tem uma mediana de 63 tokens de saída por segundo (69 quando você divide todos os tokens por todos os segundos), o Opus 5.5 95 (109), o Sonnet 5 77 (87), o Fable 5.1 75 (80) e o Opus 4.8 61 (64). Esses números contam o turno inteiro, do momento em que a requisição sai da sua máquina até o último token recebido, então são o que você realmente espera.

O /usage ou o /cost mostram tokens por segundo?

Não. O /usage mostra a cota do seu plano, as janelas de 5 horas e semanal e a parte da janela de contexto em uso; o /cost é um alias do /usage. Nenhum dos dois mostra um ritmo. O único lugar onde a velocidade existe é a transcrição da sessão em ~/.claude/projects/, onde cada mensagem do assistente traz um timestamp e sua contagem de tokens de saída. É isso que o script deste artigo lê.

Por que uma resposta curta parece mais lenta que uma longa?

Porque cada turno paga um custo fixo de tempo antes de o primeiro token chegar: o envio da requisição, o processamento do prompt, o início do streaming. Nos nossos dados essa espera é de cerca de um segundo no Opus 5 e no Opus 5.5 e de meio segundo no Sonnet 5. Numa resposta de 80 tokens, um segundo é um terço do turno, então o ritmo medido cai para 40 tokens por segundo; numa resposta de 3.000 tokens o mesmo segundo desaparece e o ritmo sobe para 80 ou mais. A velocidade de streaming em si é constante.

Os tokens de raciocínio contam na velocidade?

Sim. O bloco usage de cada mensagem informa output_tokens com um detalhamento output_tokens_details.thinking_tokens, e os tokens de raciocínio fazem parte de output_tokens. No nosso corpus eles são 30% de tudo o que o Opus 5 produziu, 18% no Opus 5.5 e 54% no Sonnet 5, que rodou quase sempre com um nível de esforço mais alto. Um turno que raciocina por muito tempo não é lento: ele está produzindo tokens que você não vê.

O cache de prompt deixa o Claude Code mais rápido?

Não o ritmo de saída. Em turnos de 100 a 500 tokens, o Opus 5 gera a uma mediana de 60,6 tokens por segundo quando a requisição encontra o cache de prompt e a 58,0 quando não encontra, e o turno inteiro leva 3,4 segundos contra 3,7. O cache influencia o que você paga pelo contexto, não a velocidade com que a resposta sai.

O que é o modo rápido do Claude Code, e quanto mais rápido ele é?

Uma configuração do Claude Opus que a Anthropic documenta como até 2,5 vezes mais rápida, a um preço por token mais alto: 8 dólares por milhão de tokens de entrada e 40 por milhão de tokens de saída no Opus 5.5, 10 e 50 no Opus 5 e no Opus 4.8, cobrados dos créditos de uso e não das janelas da assinatura. Você ativa com /fast, e um pequeno ícone de relâmpago aparece ao lado do prompt. Nenhum dos 20.408 turnos que medimos rodou no modo rápido (todas as transcrições dizem speed: standard), então não temos um número medido para ele; os números deste artigo são na velocidade padrão.