¿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:
timestampse escribe cuando se añade el bloque de contenido, así que el último bloque de un turno queda fechado al final del streaming.parentUuidapunta 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.requestIdagrupa 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 mismorequestIdy el mismousage, así que los tokens se cuentan una vez por solicitud, no una vez por línea.usage.output_tokenses la salida total de la solicitud, razonamiento incluido;output_tokens_details.thinking_tokensdice 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.
| Modelo | Turnos | Mediana tok/s | Percentil 25 al 75 | tok/s ponderados |
|---|---|---|---|---|
| Opus 5 | 16.708 | 62,7 | 51,5 a 71,8 | 69,8 |
| Opus 5.5 | 1.102 | 94,9 | 80,9 a 109,0 | 109,3 |
| Sonnet 5 | 426 | 77,0 | 62,6 a 91,5 | 87,0 |
| Fable 5.1 | 2.070 | 75,1 | 66,1 a 82,9 | 80,0 |
| Opus 4.8 | 102 | 60,9 | 49,1 a 66,5 | 64,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 turno | Turnos | Mediana tok/s | Duración mediana |
|---|---|---|---|
| 1 a 99 | 1.854 | 42,1 | 1,9 s |
| 100 a 499 | 10.743 | 60,6 | 3,4 s |
| 500 a 1.999 | 3.512 | 72,8 | 11,1 s |
| 2.000 y más | 599 | 78,4 | 38,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:
| Modelo | Costo fijo por turno | Velocidad de streaming |
|---|---|---|
| Opus 5 | 1,03 s | 81,6 tok/s |
| Opus 5.5 | 1,10 s | 148,9 tok/s |
| Sonnet 5 | 0,45 s | 94,9 tok/s |
| Fable 5.1 | 0,99 s | 84,8 tok/s |
| Opus 4.8 | 1,40 s | 69,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.
App complementaria: supervisa tus agentes en movimiento
Usa Claude, Codex, Antigravity CLI u otro proveedor de IA.
Envía bugs y peticiones directamente a tu backlog público.
Seguir leyendo
¿El Remote Control de Claude Code consume más tokens? ¿Y Codex tiene uno?
Dos preguntas que la gente escribe en Google desde que Anthropic lanzó Remote Control: si pilotar una sesión de Claude Code desde el móvil cuesta más tokens, y si existe un equivalente para Codex. Respuestas cortas: no, un turno es un turno lo escriba donde lo escriba, y sí pero solo existe la mitad. Esto es lo que es realmente Remote Control, cómo medir usted mismo la cuestión de los tokens en cuatro comandos, qué hace hoy codex remote-control, y cómo un control remoto móvil que nunca habla con un proveedor cambia las cuentas.
Leer el artículoDiez agentes lanzaron el mismo typecheck a la vez. La solución fue una carpeta.
Diecisiete agentes de código en el mismo checkout, diez procesos tsc a la vez, load average 37 y 87 MB de RAM libre. Un typecheck de noventa segundos tardó 7 min 36. Aquí está la medición, por qué la máquina no calculaba, y el pequeño bloqueo compartido que lo resolvió. Copiable en cualquier repositorio.
Leer el artículoAntigravity Remote Control: lo que hace desde tu móvil y lo que no hace
Google lanzó Remote Control para Antigravity 2.0 y Antigravity CLI el 21 de agosto de 2026, y el volumen de búsquedas sobre ese nombre dice que la gente quiere saber qué es realmente. Esto es lo que hace, comprobado en la documentación el 22 de septiembre: el interruptor y los comandos agy remote-control, el panel web en el que inicias sesión con tu cuenta de Google, la instalación en la pantalla de inicio que te da las notificaciones push, varias máquinas en un solo selector y los tres límites que importan (solo Antigravity, un demonio por máquina, los ajustes se quedan en la CLI). Después, cómo el control remoto móvil de AgentsRoom cubre las otras 13 CLI y cómo encajan los dos.
Leer el artículo