¿Qué son los tokens en Claude y cómo funcionan? Contamos 3.800 millones

La palabra aparece por todas partes alrededor de Claude: en la lista de precios, en el mensaje de límite, en /usage, en cada artículo sobre cómo ahorrar. Casi nadie explica qué es un token, y la cifra que la gente mira rara vez es la que importa. Lo que Claude escribe de vuelta es una fracción de un punto porcentual de lo que cuenta una sesión de programación.

Así que contamos los nuestros. Treinta días de sesiones de Claude Code en un Mac, del 10 de septiembre al 9 de octubre de 2026: 388 sesiones, 19.668 solicitudes al modelo, 3.800 millones de tokens. Esto es lo que es un token, las cuatro formas en que Claude los cuenta y cómo se ven esas cifras en trabajo real.

Un token es un trozo de texto, y el tamaño del trozo cambia

Un modelo no lee letras ni palabras. Lee tokens: trozos de texto sacados de un vocabulario fijo, a veces una palabra corta entera, a menudo una parte de una palabra, a veces un solo carácter o un byte para algo que nunca ha visto. Todo se cuenta en esos trozos: lo que envías, lo que Claude escribe, lo que guarda de un turno a otro.

Cuánto texto cabe en un token depende del modelo y del idioma. El glosario de Anthropic da unos 3,5 caracteres en inglés por token en los modelos anteriores a Claude 4.7, e indica que Claude 4.7 y los posteriores usan un tokenizador nuevo que produce alrededor de un 30 % más de tokens para el mismo texto. El recuento exacto solo sale del endpoint de conteo de tokens, con el modelo que piensas usar.

Medimos la proporción en nuestro propio texto. Nuestros agentes responden en francés, así que tomamos las respuestas que eran solo texto, sin razonamiento, sin llamada a herramientas, sin bloque de código, de al menos 80 palabras: 296 respuestas repartidas entre Opus 5, Opus 5.5, Fable 5.1 y Sonnet 5.5. La mediana fue de 2,3 caracteres por token, unos 2,6 tokens por palabra. El código, el JSON y las escrituras no latinas dan otras proporciones. Lo importante no es la cifra exacta: un token es más pequeño que una palabra, y nunca los cuentas a mano.

Cada solicitud se cuenta en cuatro contadores

Claude Code escribe cada sesión en una transcripción JSONL dentro de ~/.claude/projects/. Cada respuesta del modelo lleva un bloque usage. Aquí tienes uno real de nuestras transcripciones, con los campos útiles:

"usage": {
  "input_tokens": 2,
  "cache_creation_input_tokens": 51836,
  "cache_read_input_tokens": 24882,
  "output_tokens": 315,
  "output_tokens_details": { "thinking_tokens": 54 },
  "cache_creation": {
    "ephemeral_1h_input_tokens": 51836,
    "ephemeral_5m_input_tokens": 0
  }
}

Cuatro contadores, y no cuestan lo mismo:

• input_tokens: la parte del prompt que ni se escribe en la caché ni se lee de ella, facturada al precio de entrada base. En Claude Code casi siempre son un puñado de tokens, porque casi todo pasa por la caché.
• cache_creation_input_tokens: la parte del prompt guardada en la caché para que la siguiente solicitud la reutilice. Una escritura de caché cuesta 1,25 veces el precio de entrada para una caché de 5 minutos y 2 veces para una caché de 1 hora. En nuestras transcripciones, el 97 % de las escrituras eran de la caché de 1 hora.
• cache_read_input_tokens: la parte del prompt que se vuelve a leer desde la caché. Una lectura de caché cuesta 0,1 veces el precio de entrada en la mayoría de los modelos, 0,05 veces en Opus 5.5 y Sonnet 5.5, y 0,025 veces en Fable 5.1 (página de prompt caching de Anthropic, consultada el 10 de octubre de 2026).
• output_tokens: lo que Claude escribe, razonamiento incluido. La salida cuesta 5 veces el precio de entrada en todos los modelos actuales: 20 dólares por millón en Opus 5.5, 25 en Opus 5, 50 en Fable 5.1, 10 en Sonnet 5.5.

Los tres primeros sumados dan el contexto que el modelo leyó para esa solicitud. El cuarto es la respuesta.

Cómo se ven 30 días de nuestras sesiones

Sobre las 19.668 solicitudes, contadas una vez por solicitud (una misma llamada a la API puede ocupar varias líneas de una transcripción):

La columna del coste valora cada solicitud con su propio modelo y su propia duración de caché. No pagamos esa cantidad: estas sesiones funcionaban con una suscripción. Es el peso de cada contador, la misma ponderación que usa AgentsRoom para repartir el porcentaje de un plan entre proyectos.

Tres lecturas.

Casi todos los tokens son la conversación releída. El 97,7 % de los tokens son lecturas de caché. El 99,2 % de las solicitudes lee algo de la caché. Cuando alguien dice que una sesión "consumió 50 millones de tokens", esto es lo que está mirando.

Lo que Claude escribe pesa poco en tokens y no tan poco en coste. El 0,34 % de los tokens, el 16,8 % de la factura, porque la salida es el token más caro que existe. El razonamiento fue el 29 % de esa salida.

Las escrituras de caché son la sorpresa cara. El 2 % de los tokens, el 37 % del coste. Esperábamos que vinieran de la caducidad de la caché, pero solo 16 solicitudes de 19.668 tuvieron que reescribir un contexto en frío, siete de ellas tras más de una hora de silencio. El 79 % de las escrituras es simplemente cada mensaje nuevo y cada resultado de herramienta guardado una vez, al doble del precio de entrada, antes de releerse en cada turno siguiente. El otro 20 % es la primera solicitud de cada sesión.

Por qué una sesión pesa más en cada turno

El modelo no guarda nada entre dos solicitudes. Claude Code vuelve a enviarlo todo cada vez: el prompt de sistema, las definiciones de herramientas, CLAUDE.md, cada mensaje, cada archivo que leyó, cada salida de comando. La caché hace que la parte repetida sea barata por token, no gratuita, y no más pequeña.

Contexto mediano leído por solicitud, según su posición en la sesión:

La solicitud mediana leyó 179.000 tokens de contexto para escribir 290 tokens de respuesta. Esa proporción resume toda la historia de los tokens en un agente de programación: la respuesta es corta, la lectura es larga, y la lectura crece con la sesión.

Nuestra primera solicitud es pesada, 52.000 tokens antes de que nadie escribiera nada, porque nuestros agentes arrancan con un brief de rol largo y cuatro servidores MCP cuyas definiciones de herramientas están en el prompt. Una sesión de Claude Code sin nada en una carpeta vacía arranca mucho más abajo. /context muestra lo que lleva la tuya antes del primer mensaje.

Lo que consume una sesión

Sobre las 380 sesiones con al menos tres solicitudes:

• 33 solicitudes de mediana, de 16 a 61 para la mitad central.
• 27.000 tokens de salida de mediana, de 12.000 a 48.000.
• 5,4 millones de tokens procesados de mediana, de 1,5 a 10,7 millones para la mitad central, de los cuales 5,1 millones eran lecturas de caché.
• 181.000 tokens escritos en la caché o enviados sin caché de mediana: la parte realmente nueva.
• 4,55 dólares a precios de lista de la API de mediana, de 1,81 a 9,25 para la mitad central.

Así que la respuesta honesta a "cuántos tokens consume una sesión de programación" es un rango de entre uno y diez millones, casi todo el mismo contexto leído otra vez. Una sesión que funciona toda la tarde en una sola tarea larga está en lo alto del rango; una sesión que corrige un bug y se detiene está abajo.

Lo que cuentan realmente la ventana de 5 horas y la semana

En un plan Pro o Max nunca ves un saldo de tokens. El centro de ayuda de Anthropic dice que ambos planes tienen un límite de sesión de cinco horas y un límite semanal, que estos límites se comparten entre Claude y Claude Code (IDE incluido), y que los planes Max tienen un límite semanal aparte para Fable. No publica ninguna cifra en tokens para ninguno de ellos. /usage muestra un porcentaje de cada ventana y la hora a la que se reinicia.

Lo que mueve ese porcentaje, según la propia lista de Anthropic: la longitud del mensaje, el tamaño de los adjuntos, la longitud de la conversación actual, el uso de herramientas, la elección del modelo, el nivel de esfuerzo y las tareas de varios pasos. Leída junto a las tablas de arriba, "la longitud de la conversación actual" es la que domina una sesión de programación: el contexto leído en cada solicitud pasa de 52.000 a 237.000 tokens en cincuenta solicitudes. El centro de ayuda también dice que el contenido en caché de los proyectos cuenta menos en tus límites cuando se reutiliza, que es la misma idea que el precio de una lectura de caché.

No sabemos cómo convierte Anthropic los tokens en un porcentaje de una ventana, y no vamos a inventar una conversión. Lo que sí dicen los datos es que una solicitud tardía en una sesión larga cuenta varias veces lo que cuenta una del principio, para la misma pregunta.

Lo que cambia el recuento, en la práctica

Cuatro palancas, en el orden en que pesan en nuestros datos:

• /clear entre tareas sin relación. Anthropic lo llama "la palanca más eficaz, tanto para la calidad como para el coste". Una tarea nueva en una sesión vieja paga el contexto de la tarea anterior en cada solicitud.
• /compact cuando continúas una sesión larga. Sustituye el historial por un resumen corto, así que las siguientes solicitudes leen menos.
• Vigila lo que entra en el contexto. Una lectura de archivo o una salida de comando de 20.000 tokens se escribe una vez al doble del precio de entrada, y luego se relee en cada solicitud siguiente hasta que termina la sesión. Leer las líneas que necesitas en lugar del archivo entero compensa dos veces.
• Modelo y esfuerzo. El razonamiento fue el 29 % de nuestra salida, y la salida es el token más caro. Un nivel de esfuerzo más bajo en el trabajo rutinario reduce la salida, y un modelo más barato reduce todos los precios a la vez.

Lo que no pesó en nuestros datos: dejar una sesión inactiva. Con la caché de 1 hora que usa Claude Code en nuestras transcripciones, una reescritura en frío ocurrió 16 veces en 30 días.

Para más formas de gastar menos, consulta cómo reducir tus costes de tokens en Claude Code.

Cuenta los tuyos

La tabla de arriba sale de un script sin dependencias. Lee todas las transcripciones de Claude Code de la máquina, cuenta cada solicitud una vez y muestra los cuatro contadores y las medianas por sesión. Añade un filtro sobre o["timestamp"] si quieres una ventana de tiempo.

import json, glob, os, statistics as st
from collections import defaultdict

FIELDS = ("input_tokens", "cache_creation_input_tokens",
          "cache_read_input_tokens", "output_tokens")
totals, sessions = defaultdict(int), []
for path in glob.glob(os.path.expanduser("~/.claude/projects/*/*.jsonl")):
    seen, session = set(), defaultdict(int)
    with open(path, errors="ignore") as fh:
        for line in fh:
            try: o = json.loads(line)
            except ValueError: continue
            msg = o.get("message") or {}
            usage = msg.get("usage") if isinstance(msg, dict) else None
            if o.get("type") != "assistant" or not usage: continue
            rid = o.get("requestId") or o.get("uuid")
            if rid in seen: continue   # one API call can span several lines
            seen.add(rid)
            session["requests"] += 1
            for f in FIELDS:
                n = usage.get(f) or 0
                totals[f] += n
                session[f] += n
    if session["requests"] >= 3: sessions.append(session)

grand = sum(totals[f] for f in FIELDS)
for f in FIELDS:
    print(f"{f:30s} {totals[f]:>15,} {100 * totals[f] / grand:6.2f}%")
for key in ("requests", "output_tokens", "cache_read_input_tokens"):
    print(f"median per session, {key}: {st.median(s[key] for s in sessions):,.0f}")

Compara tus porcentajes con los nuestros. La línea de lecturas de caché es la conversación releída, y la línea de escrituras de caché es lo que era nuevo: esas dos dicen más sobre tu factura que la línea de salida.

Dónde lo muestra AgentsRoom

El script te da un mes. Mientras trabajas, AgentsRoom muestra los mismos contadores por agente: un indicador de tokens en el compositor de cada sesión que se pone en rojo cuando una sesión se vuelve pesada, un monitor de sesión con la entrada, la salida, las escrituras de caché, las lecturas de caché y la tasa de aciertos de la caché, y una traza de sesión que reproduce la sesión turno a turno para mostrar qué lectura de archivo o qué resultado de herramienta llenó el contexto. El panel de uso reparte el porcentaje que indica tu plan entre tus proyectos y tus agentes, ponderando cada sesión por lo que costaría a precios de la API, la misma ponderación que la tabla de arriba.

Lo que nada de esto te da es un saldo de tokens, porque tu plan no lo tiene. Para esa pregunta, consulta cuántos tokens te quedan en Claude. Para la velocidad a la que llegan esos tokens de salida, consulta los tokens por segundo de Claude Code, medidos.

Preguntas frecuentes

¿Qué es un token en Claude?

La unidad en la que Claude lee y escribe texto: un trozo de palabra, a veces una palabra corta entera, a veces un solo carácter o un byte. Anthropic indica que el tamaño depende del modelo y del idioma: en los modelos anteriores a Claude 4.7 un token tenía unos 3,5 caracteres en inglés, y Claude 4.7 y los posteriores usan un tokenizador nuevo que produce alrededor de un 30 % más de tokens para el mismo texto. Todo lo que hace Claude se mide en tokens: lo que envías, lo que te responde y lo que guarda en su caché de un turno a otro.

¿Cuántos caracteres o palabras tiene un token de Claude?

Depende del idioma y del texto. Anthropic da unos 3,5 caracteres en inglés por token en los modelos anteriores a Claude 4.7, y alrededor de un 30 % más de tokens para el mismo texto en Claude 4.7 y posteriores. En 296 respuestas de solo texto que nuestros agentes escribieron en francés en septiembre y octubre de 2026, un token tenía 2,3 caracteres, es decir, unos 2,6 tokens por palabra. El código, el JSON y las escrituras no latinas dan otras proporciones. Para un recuento exacto, el endpoint de conteo de tokens de Anthropic recibe el texto y el modelo.

¿Por qué Claude Code consume tantos tokens?

Porque cada solicitud vuelve a enviar toda la conversación: el prompt de sistema, las definiciones de herramientas, CLAUDE.md, cada mensaje y cada resultado de herramienta hasta ese momento. En nuestras 19.668 solicitudes, la solicitud mediana llevaba 179.000 tokens de contexto para escribir 290 tokens de respuesta, y el contexto pasaba de 52.000 tokens en la primera solicitud de una sesión a 237.000 después de cincuenta solicitudes. La caché hace que esa relectura sea barata por token, pero se cuenta igualmente.

¿Cuántos tokens consume una sesión típica de Claude Code?

En nuestras 380 sesiones de tres solicitudes o más, registradas entre el 10 de septiembre y el 9 de octubre de 2026: una mediana de 33 solicitudes, 27.000 tokens de salida y 5,4 millones de tokens procesados en total, de los cuales 5,1 millones eran lecturas de caché. La mitad de las sesiones se situó entre 1,5 y 10,7 millones de tokens. A precios de lista de la API, esa sesión mediana habría costado unos 4,55 dólares; en un plan Pro o Max, el mismo trabajo se descuenta de las ventanas de 5 horas y semanal.

¿Cuentan los tokens de razonamiento?

Sí. Los tokens de razonamiento forman parte de output_tokens en cada bloque usage, con un campo thinking_tokens que indica qué parte de la salida fue razonamiento. Se facturan al precio de salida en la API, y Anthropic incluye el nivel de esfuerzo entre lo que hace que los límites de uso de un plan se agoten más rápido. En nuestro corpus, el razonamiento fue el 29 % de todo lo que escribieron los modelos.

¿Qué diferencia hay entre los tokens de escritura de caché y los de lectura de caché?

Una escritura de caché guarda una parte del prompt para que la siguiente solicitud la reutilice, y cuesta más que la entrada normal: 1,25 veces el precio de entrada para una caché de 5 minutos, 2 veces para una caché de 1 hora. Una lectura de caché reutiliza esa parte guardada y cuesta mucho menos: 0,1 veces el precio de entrada en la mayoría de los modelos, 0,05 veces en Opus 5.5 y Sonnet 5.5, 0,025 veces en Fable 5.1. En nuestras sesiones, las lecturas de caché fueron el 98 % de los tokens y el 46 % del coste a precios de lista; las escrituras de caché, el 2 % de los tokens y el 37 % del coste.