¿Qué tan rápido es Claude Code? Tokens por segundo, medidos en 20.000 turnos

Claude Code nunca muestra su velocidad de salida, pero cada transcripción de sesión contiene lo necesario para calcularla. Pasamos un script de 40 líneas por 319 de nuestras sesiones, 20.408 turnos y 12 millones de tokens de salida: Opus 5 genera a una mediana de 63 tokens por segundo, Opus 5.5 a 95, Sonnet 5 a 77, y una respuesta corta siempre es más lenta que una larga. El método, el script, las cifras y lo que cambia el modo rápido.

Claude Code te dice muchas cosas sobre los tokens. /usage muestra cuánto has consumido de la sesión y de la semana, el monitor de sesión de AgentsRoom cuenta los tokens de entrada, de salida, las lecturas y las escrituras de caché turno por turno, y la línea de estado puede mostrar la parte de la ventana de contexto en uso. Ninguno muestra la cifra que la gente sigue buscando: cuántos tokens por segundo produce realmente el modelo mientras esperas.

La cifra no está oculta, simplemente nadie la calcula. Cada mensaje de cada sesión termina en una transcripción JSONL en ~/.claude/projects/, y cada mensaje del asistente lleva una marca de tiempo y su consumo de tokens. Así que la calculamos, en nuestra propia máquina, durante las últimas cuatro semanas. Este es el método, el script y lo que salió.

De dónde salen los datos

Claude Code escribe un archivo por sesión en ~/.claude/projects/<project slug>/<session id>.jsonl. Una línea por evento. Las líneas que importan aquí son los mensajes del asistente, y cada uno se ve así cuando te quedas solo con los campos útiles:

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

Cuatro cosas hacen posible la medición:

  • timestamp se escribe cuando se añade el bloque de contenido, así que el último bloque de un turno queda fechado al final del streaming.
  • parentUuid apunta a la línea justo anterior, el mensaje del usuario o el resultado de la herramienta al que respondía el modelo. Su marca de tiempo es el momento en que salió la solicitud.
  • requestId agrupa los bloques de una misma llamada a la API. Un turno que escribe algo de texto y luego llama a una herramienta produce dos líneas de asistente con el mismo requestId y el mismo usage, así que los tokens se cuentan una vez por solicitud, no una vez por línea.
  • usage.output_tokens es la salida total de la solicitud, razonamiento incluido; output_tokens_details.thinking_tokens dice cuánto de eso fue razonamiento.

Nada en el archivo da el tiempo hasta el primer token. Lo que sí puedes medir es el turno completo: desde que la solicitud sale de tu máquina hasta que llega el último token. También es la única cifra que sientes mientras esperas, así que es la que nos quedamos.

El método

Para cada requestId: toma la primera y la última línea de asistente que lo llevan, lee el usage de la primera, busca el padre de la primera línea y divide los tokens de salida entre los segundos que hay entre la marca de tiempo del padre y la de la última línea. Después mira la distribución por modelo, nunca un único promedio, porque un turno de 40 segundos y uno de 2 segundos no son el mismo objeto.

Descartamos los turnos sin tokens de salida, los turnos con una duración negativa o nula (una sesión reanudada puede tener un padre fechado después de su hijo) y los turnos de más de quince minutos, que son sesiones interrumpidas y no respuestas largas. No se filtró nada más.

El script son 40 líneas de Python sin dependencias. Ejecútalo desde cualquier sitio: lee todos los proyectos de la 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")

La columna weighted es el total de tokens dividido entre el total de segundos. Es lo que vive una ejecución autónoma larga; la mediana es lo que vive un solo turno interactivo.

Las cifras

Un Mac en Francia, 319 transcripciones, 20.408 turnos entre el 27 de agosto y el 25 de septiembre de 2026, 12,0 millones de tokens de salida producidos en 45 horas de generación. Velocidad estándar en todos los turnos (ver el modo rápido más abajo). Cinco modelos aparecen en las transcripciones, con los nombres que escribe Claude Code.

ModeloTurnosMediana tok/sPercentil 25 al 75tok/s ponderados
Opus 516.70862,751,5 a 71,869,8
Opus 5.51.10294,980,9 a 109,0109,3
Sonnet 542677,062,6 a 91,587,0
Fable 5.12.07075,166,1 a 82,980,0
Opus 4.810260,949,1 a 66,564,2

Dos lecturas antes que nada. Primero, Opus 5.5 no es un poco más rápido que Opus 5: es una vez y media más rápido en la mediana y un 57% más rápido en la cifra ponderada, con una proporción mucho mayor de turnos largos. Segundo, la dispersión dentro de un modelo es más amplia que la distancia entre modelos: un turno de Opus 5 en el percentil 25 genera a 51 tokens por segundo y uno en el percentil 75 a 72. La razón es el tamaño del turno, y merece su propia sección.

Una respuesta corta siempre es más lenta

Aquí está otra vez Opus 5, dividido según el número de tokens de salida del turno:

Tokens de salida en el turnoTurnosMediana tok/sDuración mediana
1 a 991.85442,11,9 s
100 a 49910.74360,63,4 s
500 a 1.9993.51272,811,1 s
2.000 y más59978,438,8 s

Mismo modelo, mismo mes, misma máquina, y el ritmo se duplica entre una respuesta de una línea y una larga. El modelo no genera más rápido en los turnos largos. Cada turno paga un costo fijo en tiempo antes de que aparezca el primer token: la solicitud sale, el prompt se procesa, el streaming arranca. En un turno de 80 tokens ese costo es un tercio del tiempo transcurrido; en un turno de 3.000 tokens se pierde en el ruido.

Un ajuste por mínimos cuadrados de la duración frente a los tokens de salida separa las dos cosas. La pendiente da la velocidad de streaming, la ordenada en el origen da el costo fijo:

ModeloCosto fijo por turnoVelocidad de streaming
Opus 51,03 s81,6 tok/s
Opus 5.51,10 s148,9 tok/s
Sonnet 50,45 s94,9 tok/s
Fable 5.10,99 s84,8 tok/s
Opus 4.81,40 s69,9 tok/s

Así que cuando una sesión cargada de llamadas a herramientas parece lenta, rara vez es el rendimiento del modelo. Es el número de turnos. Un agente que lee doce archivos uno por uno paga doce costos fijos; el mismo agente leyéndolos en una sola llamada agrupada paga uno. Es la misma lección que para reducir los costos de tokens: menos turnos y más grandes, no un modelo más rápido.

El turno individual más largo del corpus son 21.332 tokens de salida en 236 segundos en Opus 5, es decir, 90 tokens por segundo de principio a fin: una vez amortizado el costo fijo, es el techo que observamos en ese modelo a velocidad estándar.

Los tokens de razonamiento son tokens de salida

output_tokens incluye el razonamiento que hace el modelo antes de responder, y output_tokens_details.thinking_tokens te dice cuánto. En nuestro corpus el razonamiento es el 30% de todo lo que produjo Opus 5, el 18% en Opus 5.5, el 36% en Fable 5.1 y el 54% en Sonnet 5, que usamos sobre todo con un nivel de esfuerzo más alto en tareas de revisión.

Eso importa para interpretar un turno lento. Un turno que razona durante ocho segundos y muestra dos líneas no es un modelo lento: es un turno que produjo 600 tokens que nunca viste. Los turnos con razonamiento son, por token, algo más rápidos que los turnos sin él: 67 frente a 57 tokens por segundo en Opus 5, porque son más largos y amortizan mejor el costo fijo. Si una sesión se siente pesada y no necesitas el razonamiento, la palanca es el nivel de esfuerzo, no el modelo.

Las lecturas de caché cambian la factura, no el ritmo

Casi todos los turnos de Claude Code aciertan en la caché de prompt: solo 130 de los 16.680 turnos de Opus 5 tenían cache_read_input_tokens en cero, y son el primer turno de una sesión. En turnos de 100 a 500 tokens de salida, los que usan la caché generan a una mediana de 60,6 tokens por segundo y tardan 3,4 segundos; los que no la usan generan a 58,0 y tardan 3,7 segundos. La diferencia es real pero pequeña, y está en el costo fijo, no en la velocidad de streaming. La caché tiene que ver con el precio del contexto que arrastras, y por eso el contador de tokens del terminal de AgentsRoom muestra las lecturas y las escrituras de caché como dos cifras separadas.

Estable a lo largo del mes

Una cifra acumulada puede ocultar una deriva, así que también miramos la mediana semanal de Opus 5 en turnos de 100 a 500 tokens, los más frecuentes: 63,6, 64,1, 60,9, 61,7, 56,9 tokens por segundo semana tras semana, y luego 68,7 en la última semana, incompleta. Entre 57 y 69, sin tendencia. Si tus sesiones parecen más lentas alguna tarde, vale la pena ejecutar el script solo sobre ese día antes de culpar al modelo.

Lo que cambia el modo rápido, y lo que no pudimos medir

Cada bloque usage lleva un campo speed, y los 20.408 nuestros dicen standard. Anthropic documenta un modo rápido (fast mode) para Claude Opus, que se activa con /fast en la CLI o con "fastMode": true en los ajustes de usuario, y que hace el modelo hasta 2,5 veces más rápido a un precio por token más alto: 8 dólares por millón de tokens de entrada y 40 por millón de tokens de salida en Opus 5.5, 10 y 50 en Opus 5 y Opus 4.8. En los planes Pro y Max se factura a los créditos de uso, fuera de las ventanas de la suscripción; Sonnet y Haiku no lo admiten, y activarlo te cambia a Opus. Un icono de rayo junto al prompt indica que está activo.

No lo hemos pagado, así que no tenemos una cifra medida que poner al lado de las 2,5 veces documentadas. Si lo usas, el mismo script te dice lo que obtuviste: filtra los turnos con usage["speed"] == "fast" y compara las medianas. Envíanos las cifras.

Lo que esto cambia en cómo ejecutamos agentes

Tres cosas, y ninguna consiste en elegir un modelo más rápido.

La primera tiene que ver con las expectativas. Si una ejecución nocturna de siete agentes produce dos millones de tokens de salida, eso son ocho horas de generación a 70 tokens por segundo, repartidas entre agentes que trabajan en paralelo. Conocer el ritmo es lo que te permite saber si una tarea programada puede terminar antes de que empiece la siguiente.

La segunda tiene que ver con los turnos. El segundo fijo por turno es el mismo en una confirmación de 30 tokens que en un diff de 3.000 tokens. Los agentes que preguntan antes de cada pequeño paso, o que leen los archivos de uno en uno, pasan su tiempo en ese segundo. Por eso escribimos «agrupa tus lecturas independientes» en los prompts de los agentes que trabajan sin supervisión.

La tercera tiene que ver con lo que debería mostrar el contador. El monitor de sesión de AgentsRoom muestra los tokens y la caché, y se pone en rojo cuando una sesión se vuelve pesada; no muestra un ritmo, y después de esta medición no estamos seguros de que deba hacerlo. Un ritmo es una propiedad del modelo y del tamaño del turno, no de la sesión, y la cifra que necesita un desarrollador es la de las tablas de arriba. Por eso esto es un artículo y no un widget.

Preguntas frecuentes

¿Cuántos tokens por segundo genera Claude Code?

En nuestros 20.408 turnos registrados entre el 27 de agosto y el 25 de septiembre de 2026: Opus 5 tiene una mediana de 63 tokens de salida por segundo (69 si divides todos los tokens entre todos los segundos), Opus 5.5 95 (109), Sonnet 5 77 (87), Fable 5.1 75 (80) y Opus 4.8 61 (64). Esas cifras cuentan el turno completo, desde que la solicitud sale de tu máquina hasta el último token recibido, así que son lo que realmente esperas.

¿/usage o /cost muestran los tokens por segundo?

No. /usage muestra la cuota de tu plan, las ventanas de 5 horas y semanal y la parte de la ventana de contexto en uso; /cost es un alias de /usage. Ninguno de los dos muestra un ritmo. El único lugar donde existe la velocidad es la transcripción de sesión en ~/.claude/projects/, donde cada mensaje del asistente lleva una marca de tiempo y su número de tokens de salida. Eso es lo que lee el script de este artículo.

¿Por qué una respuesta corta parece más lenta que una larga?

Porque cada turno paga un costo fijo en tiempo antes de que llegue el primer token: el envío de la solicitud, el procesamiento del prompt, el inicio del streaming. En nuestros datos esa espera es de alrededor de un segundo en Opus 5 y Opus 5.5 y de medio segundo en Sonnet 5. En una respuesta de 80 tokens, un segundo es un tercio del turno, así que el ritmo medido cae a 40 tokens por segundo; en una respuesta de 3.000 tokens ese mismo segundo desaparece y el ritmo sube a 80 o más. La velocidad de streaming en sí es constante.

¿Los tokens de razonamiento cuentan en la velocidad?

Sí. El bloque usage de cada mensaje informa output_tokens con un desglose output_tokens_details.thinking_tokens, y los tokens de razonamiento forman parte de output_tokens. En nuestro corpus son el 30% de todo lo que produjo Opus 5, el 18% en Opus 5.5 y el 54% en Sonnet 5, que funcionó sobre todo con un nivel de esfuerzo más alto. Un turno que razona durante mucho tiempo no es lento: está produciendo tokens que no ves.

¿La caché de prompt hace más rápido a Claude Code?

No el ritmo de salida. En turnos de 100 a 500 tokens, Opus 5 genera a una mediana de 60,6 tokens por segundo cuando la solicitud acierta en la caché de prompt y a 58,0 cuando no, y el turno completo tarda 3,4 segundos frente a 3,7. La caché influye en lo que pagas por el contexto, no en la velocidad a la que sale la respuesta.

¿Qué es el modo rápido de Claude Code y cuánto más rápido es?

Una configuración de Claude Opus que Anthropic documenta como hasta 2,5 veces más rápida, a un precio por token más alto: 8 dólares por millón de tokens de entrada y 40 por millón de tokens de salida en Opus 5.5, 10 y 50 en Opus 5 y Opus 4.8, facturados a los créditos de uso y no a las ventanas de la suscripción. Se activa con /fast, y aparece un pequeño icono de rayo junto al prompt. Ninguno de los 20.408 turnos que medimos se ejecutó en modo rápido (todas las transcripciones dicen speed: standard), así que no tenemos una cifra medida para él; las cifras de este artículo son a velocidad estándar.

Descargar AgentsRoom

Ejecuta todos tus agentes de IA, en todos tus proyectos, desde una sola ventana.

GratisDescargar AgentsRoom

App complementaria: supervisa tus agentes en movimiento

Usa Claude, Codex, Antigravity CLI u otro proveedor de IA.

Instalar la extensión
Chrome Web Store

Envía bugs y peticiones directamente a tu backlog público.

Multi-proyectos
Multi-proveedor
Multi-agentes
Estado en vivo
Diff y commit
App móvil
Vista previa
Equipos de agentes
Pruebas en navegador
Dev guiada por backlog
Biblioteca de prompts
Biblioteca de skills
Ver todas las funcionalidades

Seguir leyendo