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.

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 a linha logo anterior, a mensagem do usuário ou o resultado da ferramenta que o modelo estava respondendo. O timestamp dela é o momento em que a requisição saiu.
• 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, encontre o pai da primeira linha e divida os tokens de saída pelos segundos entre o timestamp do pai e o da última linha. Depois olhe a distribuição por modelo, nunca uma média única, porque um turno de 40 segundos e um turno de 2 segundos não são a mesma coisa.

Descartamos os turnos sem tokens de saída, os turnos com duração negativa ou zero (uma sessão retomada pode ter um pai datado depois do filho) e os turnos com mais de quinze minutos, que são sessões interrompidas e não respostas longas. Nada mais foi filtrado.

O script tem 40 linhas de Python sem nenhuma dependência. Rode de qualquer lugar: ele lê todos os projetos da máquina.

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

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 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.