Uso de Claude Code por sesión: cómo ver qué sesión se está comiendo tu plan

Si tienes varias sesiones de Claude Code en paralelo, el límite semanal baja más rápido de lo que esperas. Quieres saber qué sesión se lo está comiendo, pero abrir /usage no te lo dice.

La respuesta corta: a septiembre de 2026 no existe ninguna pantalla oficial que muestre qué parte del consumo se llevó cada sesión. /usage te da los números de la sesión actual y, además, el consumo de todo tu plan repartido en porcentajes por Skill, subagente, plugin y servidor MCP. Si lo quieres por sesión, tienes que sumar tú los registros de conversación que se guardan en tu propia máquina.

Eso sí, si cuentas esos registros sin más, te equivocas. Al medir los registros de los últimos 7 días en mi máquina, sumar las líneas tal cual dio un total 2.06 veces mayor que el valor correcto. Peor aún: incluso entre las 12 sesiones que más consumieron, el tamaño de ese error iba de 1.30× a 3.02×, así que el orden cambiaba. Este artículo repasa lo que sí muestran las pantallas oficiales, la forma correcta de contar, un script de recuento de unas 50 líneas y lo que medí.

1. Qué muestran las pantallas oficiales y qué no

Estos son los principales sitios oficiales que informan del consumo (a septiembre de 2026). Ninguno muestra la parte que se llevó cada sesión. Lo más parecido es el desglose del plan en /usage, pero su eje es a qué función se fue el consumo, no qué sesión lo gastó.

Fuente: documentación de Claude Code, «Manage costs effectively» (/usage, /insights, paneles de organización), documentación de Claude Code, «Desktop» (anillo de uso), Centro de ayuda de Claude, «Usage limit best practices» (la página de uso de Settings), documentación de Claude Code, «Monitoring» (OpenTelemetry)

Sobre el desglose del plan en /usage, la documentación dice otra cosa importante: «Las cifras son aproximadas y se calculan a partir del historial de sesiones local de esta máquina, así que no incluyen el uso desde otros dispositivos ni desde claude.ai.» Es decir, hasta el desglose oficial sale, en última instancia, de tus registros locales. Si lees tú esos mismos registros, puedes sumarlos por el eje que las pantallas oficiales dejan fuera: la sesión. Si ya has llegado al límite y quieres comprobar cuánto te queda, consulta Claude Code «usage limit reached»: causas y soluciones.

2. La respuesta está en tus registros de conversación locales

Claude Code guarda el registro completo de cada conversación en JSONL (un objeto JSON por línea), con un archivo por sesión. La documentación indica dónde están.

Fuente: documentación de Claude Code, «Explore the .claude directory»

En mi máquina, el nombre de la carpeta <proyecto> era la ruta absoluta de la carpeta de trabajo con sus símbolos sustituidos por - (D:\work\site-a pasa a ser D--work-site-a). Las sesiones ejecutadas desde la pestaña Code de la app de escritorio se escribían en el mismo sitio, con "entrypoint":"claude-desktop" registrado en cada línea.

Lo que sumas es el usage que acompaña a las líneas que registran las respuestas de Claude ("type":"assistant"). Aquí tienes una línea real, reducida a los campos que usa el recuento (con los ID ocultos).

{"type":"assistant","requestId":"req_…","timestamp":"2026-07-25T00:16:37.822Z",
 "message":{"id":"msg_…","model":"claude-opus-5",
  "content":[{"type":"text","text":"…"}],
  "usage":{"input_tokens":2,"output_tokens":255,
           "cache_read_input_tokens":33775,"cache_creation_input_tokens":17265,
           "cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":17265}}}}

Los cuatro números de usage (entrada, salida, lectura de caché y escritura de caché) son campos oficiales de las respuestas de la API de Claude. El formato del propio archivo de registro, es decir, qué se escribe en cada línea, no está documentado oficialmente. El método de recuento de este artículo lo comprobé con mis propios registros de la v2.1.197 a la v2.1.260, y puede dejar de funcionar en versiones futuras.

La documentación deja clara otra precaución: «Las transcripciones y el historial no están cifrados en reposo. Los permisos de archivos del sistema operativo son la única protección.» Si una herramienta lee un archivo .env, su contenido acaba también en el registro. Compartir resultados ya sumados con otras personas no es problema, pero ten cuidado al entregar los registros en sí o al dejar que los lea una herramienta que no conoces bien.

3. Súmalo sin más y sale casi el doble: cuatro trampas

Busca las líneas con usage y súmalas todas. Es el enfoque más obvio, pero en mis registros el total salió aproximadamente el doble del valor correcto. Hay cuatro motivos.

Trampa 1: una respuesta se escribe en varias líneas

Una respuesta de Claude (una petición a la API) no equivale necesariamente a una línea del registro. En mi máquina, cada bloque de contenido, como el razonamiento, el texto o una llamada a herramienta, se escribía en su propia línea (más del 99.9% de las líneas contenían exactamente un bloque), y todas esas líneas llevaban usage. Lo que identifica una respuesta es el par formado por message.id y requestId.

De las 142,345 respuestas escritas en dos o más líneas, el 76% tenía exactamente el mismo usage en todas sus líneas. En el 24% restante, el valor de tokens de salida cambiaba de una línea a otra. Así que, para cada respuesta, quédate solo con la línea que tenga más tokens de salida. Aparte, 1,903 respuestas aparecían también en otro archivo (el 0.95% de todos los tokens). No he averiguado por qué, pero agrupar todo por la misma clave evita que también estas se cuenten dos veces.

Trampa 2: los registros de los subagentes están en archivos aparte

Si lees solo los archivos .jsonl principales, los subagentes desaparecen por completo. En mis registros, esta es la parte de los totales correctos que venía de subagentes.

• Entrada (sin caché): 42.9%
• Salida: 23.2%
• Escritura de caché: 10.8%
• Lectura de caché: 6.9%

Por sesión, la dispersión es aún mayor: en los últimos 7 días, ponderado por precio, iba desde sesiones con un 0% hasta una sesión con un 54%. Cuanto más trabajo reparte una sesión entre subagentes, más pequeña parece si cuentas solo el archivo principal.

Trampa 3: los dos errores se compensan en parte, pero de forma distinta en cada sesión

Si sumas tal cual las líneas de los archivos principales, la trampa 1 infla el recuento y la trampa 2 lo encoge. En los últimos 7 días el total dio 2.06 veces el valor correcto. Si todas las sesiones se desviaran en el mismo factor, los porcentajes seguirían siendo correctos. En la práctica, no fue así.

Fuente: mediciones propias (los últimos 7 días a 15 de septiembre de 2026. Para facilitar la comparación, solo esta tabla usa recuentos de tokens sin ponderar, también en la parte de subagentes. Las letras de las sesiones coinciden con la figura del principio)

Los puestos 2 y 3 se intercambiaron, igual que el 4 y el 5, y G, que en realidad era 9.º, subió al 6.º. Que D salga pequeña por apoyarse en subagentes es exactamente la trampa 2, pero E, con la misma parte de subagentes que D (39%), fue en sentido contrario, con 2.60×. También influye en cuántas líneas se divide cada respuesta (cuánto razonamiento y cuántas llamadas a herramientas contiene), así que el factor no se puede predecir de antemano. «Divide entre dos y listo» no funciona.

Trampa 4: el 97% de los tokens son lecturas de caché

Incluso contando bien, comparar recuentos de tokens en bruto lleva a juzgar mal lo pesada que es cada sesión. Esta es la composición de los últimos 7 días.

Los precios unitarios, sin embargo, no se parecen en nada. En la página oficial de precios de Anthropic, las lecturas de caché cuestan 0.1 veces el precio base de entrada (0.025 veces en Claude Fable 5.1 y Claude Mythos 5.1), las escrituras de caché de 5 minutos cuestan 1.25 veces y las de 1 hora, 2 veces, y la salida cuesta 5 veces el precio de entrada en todos los modelos actuales. La sesión C, que tenía el 12.7% de los tokens, se quedó en el 10.4% al ponderar por estos precios.

El propio tamaño de las cifras también dice algo. De las 12 sesiones que más consumieron, las 10 que no son D ni E leían de media entre unos 410,000 y 480,000 tokens de contexto por respuesta (D y E, que se apoyan en subagentes, rondaban los 240,000 y los 310,000). «Claude Code envía la conversación entera en cada petición», así que cuanto más tiempo sigue abierta una sesión, más pesa cada petición. ¿Qué se está comiendo el contexto de Claude Code? explica a fondo cómo funciona.

4. El script de recuento

Este script de recuento tiene en cuenta las cuatro trampas. Funciona solo con la biblioteca estándar de Python 3 (lo probé con la 3.11). Se limita a leer los registros: no modifica ni envía nada. Si has movido tu directorio de configuración con la variable de entorno CLAUDE_CONFIG_DIR, lee desde ahí.

import json, os, sys
from collections import defaultdict
from datetime import datetime, timedelta, timezone
from pathlib import Path

DAYS = float(sys.argv[1]) if len(sys.argv) > 1 else 7
ROOT = Path(os.environ.get("CLAUDE_CONFIG_DIR") or Path.home() / ".claude") / "projects"
SINCE = datetime.now(timezone.utc) - timedelta(days=DAYS)
# USD per 1M input tokens (output = 5x). First match wins.
PRICES = [("sonnet-5", 2), ("sonnet", 3), ("haiku", 1), ("opus-4-1", 15),
          ("opus-4-2025", 15), ("opus", 5), ("fable", 10), ("mythos", 10)]

best = {}  # one API response = one (message.id, requestId)
for path in ROOT.rglob("*.jsonl"):  # also reads <session>/subagents/*.jsonl
    project = path.relative_to(ROOT).parts[0]
    with path.open(encoding="utf-8", errors="replace") as f:
        for line in f:
            if '"usage"' not in line:
                continue
            try:
                row = json.loads(line)
            except ValueError:
                continue
            msg = row.get("message") or {}
            usage = msg.get("usage")
            ts = row.get("timestamp")
            if row.get("type") != "assistant" or not usage or not ts:
                continue
            if datetime.fromisoformat(ts.replace("Z", "+00:00")) < SINCE:
                continue
            key = (msg.get("id"), row.get("requestId"))
            old = best.get(key)
            if old is None or usage.get("output_tokens", 0) >= old[2].get("output_tokens", 0):
                best[key] = (project, msg.get("model") or "", usage)

totals = defaultdict(lambda: [0, 0.0])  # [tokens, weight]
for project, model, u in best.values():
    p = next((v for name, v in PRICES if name in model), 5)
    read_rate = 0.025 if "5-1" in model and ("fable" in model or "mythos" in model) else 0.1
    inp, out = u.get("input_tokens", 0), u.get("output_tokens", 0)
    read, write = u.get("cache_read_input_tokens", 0), u.get("cache_creation_input_tokens", 0)
    write_1h = (u.get("cache_creation") or {}).get("ephemeral_1h_input_tokens", 0)
    totals[project][0] += inp + out + read + write
    totals[project][1] += p * (inp + out * 5 + read * read_rate
                               + (write - write_1h) * 1.25 + write_1h * 2)

all_tokens = sum(t for t, _ in totals.values()) or 1
all_weight = sum(w for _, w in totals.values()) or 1
print(f"last {DAYS:g} days: {len(best):,} responses")
print(f"{'weight':>7} {'tokens':>7}  project")
for project, (t, w) in sorted(totals.items(), key=lambda kv: -kv[1][1]):
    print(f"{w / all_weight:7.1%} {t / all_tokens:7.1%}  {project}")

Guárdalo con un nombre como usage_by_session.py y pásale el número de días como argumento. Si lo omites, obtienes los últimos 7 días.

python usage_by_session.py        # últimos 7 días
python usage_by_session.py 1      # últimas 24 horas
python usage_by_session.py 30     # últimos 30 días

La salida tiene este aspecto (con los nombres de carpeta ocultos). weight es la parte ponderada por precio y tokens, la parte según el recuento de tokens en bruto.

last 7 days: 19,991 responses
 weight  tokens  project
  32.3%   31.7%  D--work-project-a
  11.1%   11.4%  D--work-project-b
  10.4%   12.7%  D--work-project-c
   7.7%    8.6%  D--work-project-d
   6.4%    5.4%  D--work-project-e

5. Medido: una de 29 sesiones gastó casi un tercio

En los últimos 7 días hubo 29 sesiones activas en mi máquina. Como muestra la figura del principio, el consumo estaba concentrado en solo unas pocas.

Al poner los números uno al lado del otro salieron a la luz tres cosas.

Primero, las sesiones de arriba pesan en cada petición. Las 3 primeras leían de media entre unos 410,000 y 480,000 tokens por respuesta. No es solo que hicieran más peticiones: siguieron abiertas todo el día mientras su contexto no paraba de crecer. La documentación también señala que, en una sesión que lleva mucho tiempo abierta, hasta una pregunta de una línea genera consumo por la conversación entera.

Segundo, las sesiones que se apoyan en subagentes parecen pequeñas vistas desde la conversación principal. En D y E, los subagentes supusieron el 44% y el 54% del consumo ponderado por precio, respectivamente. Si miras la conversación principal en la barra lateral, esa parte no la ves nunca.

Tercero, más de la mitad de las sesiones apenas consumieron nada. El límite no baja más rápido porque tengas muchas sesiones abiertas; lo que lo agota son unas pocas sesiones pesadas. Si vas a actuar, basta con empezar por esas pocas. Qué recortar primero lo explica Consejos para ahorrar tokens en Claude Code y qué pasa al alcanzar el límite.

6. Cómo leer los números y hasta dónde llegan

7. Para seguirlo de aquí en adelante, OpenTelemetry

La ventaja de sumar los registros es que puedes ver los últimos 30 días al instante. Si lo que quieres es seguir vigilándolo a partir de ahora, encaja mejor OpenTelemetry, la función oficial de monitorización.

Una vez activado, Claude Code exporta una métrica de tokens, claude_code.token.usage (con los tipos input, output, cacheRead y cacheCreation), y una métrica de coste, claude_code.cost.usage. Ambas llevan session.id por defecto (OTEL_METRICS_INCLUDE_SESSION_ID, true por defecto). Como no lee los archivos de registro, las líneas duplicadas de la trampa 1 no entran en juego, y el consumo de los subagentes se registra por separado en query_source (main, subagent, auxiliary).

Para probarlo primero en local, arranca Claude Code con el exportador configurado para imprimir en la terminal, como muestra la documentación.

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=console
export OTEL_METRIC_EXPORT_INTERVAL=1000
claude

Para sumarlo de forma continua, pon OTEL_METRICS_EXPORTER=otlp y envía los datos a un destino que gestiones tú (un backend de monitorización que acepte OTLP). Tienes que montar ese destino, y no queda registrado nada de antes de activarlo: esas son las diferencias con sumar los registros.

Fuente: documentación de Claude Code, «Monitoring» (nombres de las métricas, atributos, variables de entorno)

FAQ

Q1. ¿No basta con el desglose del plan de /usage?
Mide por otro eje. El desglose del plan muestra, en porcentajes, a qué Skills, subagentes, plugins y servidores MCP se fue el consumo, y no muestra qué sesión lo gastó. Para averiguar qué agota tu límite desde el lado de las funciones, usa /usage; desde el lado de las sesiones, usa el recuento de este artículo.

Q2. ¿Puedo usar una herramienta de recuento ya hecha?
Sí. La herramienta no oficial ccusage, por ejemplo, puede generar informes por sesión a partir de los mismos registros. Antes de usar una, comprueba dos cosas. Primero, si todo el procesamiento se queda en tu máquina: los registros contienen resultados de herramientas sin cifrar. Segundo, cómo cuenta: para asegurarte de que trata las líneas duplicadas y los subagentes igual, compara una vez su salida con la del script de este artículo.

Q3. Quiero incluir el consumo de otras máquinas y de claude.ai.
Los registros solo se guardan en cada máquina, así que haces el recuento en cada una y sumas los resultados. Los chats de claude.ai no aparecen en los registros de Claude Code. Para saber cuánto te queda del plan en total, lo fiable es mirar las barras de progreso de Settings > Usage en claude.ai.

Q4. Quiero conservar los registros para poder sumar también el consumo antiguo.
En las sesiones usadas en la terminal, sube cleanupPeriodDays en settings.json y se conservarán más tiempo. Las sesiones que iniciaste o continuaste por última vez en la app de escritorio (o en Cowork) ya se conservan sin importar su antigüedad desde la v2.1.248 (para ponerles un límite, usa desktopSessionCleanupPeriodDays). Ten en cuenta, eso sí, que la documentación menciona bajar estos valores como forma de reducir la exposición de tus registros. Cuanto más tiempo los conserves, más tiempo permanecen registros sin cifrar en tu máquina, así que tenlo presente.

Fuentes

• Claude Code Docs — Manage costs effectively (el bloque Session y el desglose del uso del plan de /usage, la nota de que las cifras se calculan con el historial de esta máquina, /insights, los paneles de organización, por qué el consumo crece en sesiones largas)
• Claude Code Docs — Explore the .claude directory (dónde se guardan los registros, subagents/, los 30 días por defecto de cleanupPeriodDays y el trato de las sesiones de la app de escritorio, la falta de cifrado)
• Claude Code Docs — Desktop (el anillo de uso)
• Claude Help Center — Usage limit best practices (qué muestra Settings > Usage)
• Claude Code Docs — Monitoring (nombres de las métricas de OpenTelemetry, session.id, variables de entorno)
• Claude Platform Docs — Pricing (precios por modelo, multiplicadores de la caché)

Artículos relacionados

• ¿Qué se está comiendo el contexto de Claude Code? — por qué pesa tanto cada respuesta
• Claude Code «usage limit reached»: causas y soluciones — cuando llegas al límite
• Consejos para ahorrar tokens en Claude Code y qué pasa al alcanzar el límite — qué recortar primero
• El límite semanal de Claude Code y sus reinicios anticipados — cómo funciona el límite semanal