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

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

Tokens por segundo de Opus 5.5: actualización del 19 de octubre de 2026

Repetimos la medición sobre las últimas cuatro semanas completas: del 21 de septiembre al 18 de octubre de 2026 (UTC). Incluimos el directorio de transcripciones por defecto y los perfiles de Claude adicionales que usa AgentsRoom, y después contamos cada solicitud una sola vez entre todos los archivos.

El tiempo fijo es la ordenada en el origen de un ajuste por mínimos cuadrados de los segundos transcurridos frente a los tokens de salida. Es una estimación de la sobrecarga de tiempo por turno, no un precio ni una medición directa del tiempo hasta el primer token. El razonamiento está incluido en ambos ritmos.

Esta actualización también corrige el cronometraje. El padre directo puede ser un adjunto técnico, incluido deferred_tools_record, escrito cuando la respuesta ya está llegando. En una solicitud, el método anterior dividía 562 tokens entre 0,046 segundos, lo que daba más de 12.000 tok/s. Seguir la cadena de padres hasta el mensaje del usuario o el resultado de la herramienta que desencadenó el turno recupera unos siete segundos de tiempo transcurrido. Con esa corrección y la deduplicación de solicitudes, ninguna solicitud de Opus 5.5 en este periodo supera los 400 tok/s; no filtramos los ritmos altos.

Las tablas de septiembre de más abajo siguen siendo la medición original. Su mediana de 94,9 tok/s y su ritmo ponderado de 109,3 tok/s usan el cronometraje anterior y una muestra distinta, así que la diferencia no demuestra que Opus 5.5 se haya vuelto más lento. Estas cifras describen nuestras cargas de trabajo, nuestra red y las marcas de tiempo de las transcripciones, no un benchmark del modelo aislado.

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 al evento anterior, que puede ser un adjunto técnico escrito durante la respuesta. Sigue la cadena más allá de los eventos attachment, system y progress hasta el mensaje del usuario o el resultado de la herramienta que desencadenó el turno; su marca de tiempo sirve como aproximación del inicio del turno.
• 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, sigue su cadena de padres hasta el mensaje del usuario o el resultado de la herramienta que desencadenó el turno, y divide los tokens de salida entre los segundos transcurridos hasta la última línea de asistente. Cuenta cada solicitud una sola vez entre archivos e informa de cada modelo y cada configuración de velocidad por separado. Estas marcas de tiempo incluyen la sobrecarga local: no aíslan el tiempo de generación de la API.

Descartamos los turnos sin tokens de salida, sin mensaje desencadenante encontrado, con una duración negativa o nula o con una duración de más de quince minutos. El script de abajo usa el periodo de la actualización fechada, con el inicio incluido y el fin excluido, en UTC. Cambia START y END para medir otro periodo.

El script actualizado requiere Python 3.10 o posterior y ninguna dependencia adicional. Ejecútalo desde cualquier sitio: lee los proyectos por defecto y los perfiles locales de Claude adicionales sin subir su contenido.

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

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.

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:

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:

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

En nuestra medición actualizada el 19 de octubre de 2026, Claude Opus 5.5 alcanzó una mediana de 89,4 tokens de salida por segundo en 30.119 solicitudes únicas del 21 de septiembre al 18 de octubre, todas a velocidad estándar. El total de tokens de salida dividido entre el total de segundos transcurridos da 97,5 tok/s. El razonamiento representa el 42,1% de los tokens de salida. Son mediciones de extremo a extremo sobre las transcripciones de nuestras propias sesiones, no un benchmark universal de velocidad de streaming.

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