Cuánto gasta tu Claude Code: statusline, VS Code y OpenTelemetry

Hace unos meses, controlar el gasto de Claude Code significaba dos proyectos separados: montar ccusage en el statusline del terminal, o buscar una extensión de VS Code que pintara el coste en la barra de estado porque Anthropic no publicaba nada propio para eso. Esa separación ya no describe la herramienta actual. El propio JSON que alimenta el statusline trae hoy coste y límites de cuota sin depender de terceros, y la extensión oficial de VS Code abrió su propio panel de cuenta y uso. Lo que sigue sin resolver de serie es la parte que le importa a un equipo: histórico, atribución por persona y alertas, y ahí es donde entra OpenTelemetry.

Este artículo recorre el control de gasto en Claude Code de dentro hacia fuera: primero lo que ya viene incluido, después el statusline en terminal, luego el mismo dato dentro del editor y por último la telemetría pensada para varias personas gastando a la vez.

Lo que Claude Code te dice sin instalar nada

El comando /usage muestra el coste de la sesión actual, el desglose de qué skills, subagentes, plugins y servidores MCP están consumiendo tu cuota -el coste por servidor MCP da para un análisis propio, que no repito aquí: qué servidores MCP sobreviven a la prueba de tokens-, y -en planes de suscripción- las barras de uso de las ventanas de 5 horas y semanal con su hora de reset, todo sin instalar nada adicional.

Ese bloque de sesión (Total cost, tokens por modelo, líneas de código) se calcula localmente a precio de lista y se reinicia con cada /clear; para la cifra que de verdad te van a cobrar, la referencia es la página de uso de la Claude Console, no /usage. En planes Pro, Max, Team o Enterprise, el mismo comando además marca qué comportamiento está detrás del gasto -contexto largo, fallos de caché, sesiones con muchos subagentes en paralelo- cuando ese comportamiento explica el 10% o más del consumo reciente.

Parte del ahorro ya es automático: Claude Code cachea el prompt de sistema y el CLAUDE.md entre turnos, y compacta la conversación cuando se acerca al límite de contexto sin que tengas que pedirlo. Un acierto de caché cuesta el 10% del precio de entrada base, un multiplicador documentado que por sí solo explica buena parte de por qué el mismo volumen de trabajo puede costar la mitad o más según si el CLAUDE.md y el contexto se mantienen estables durante la sesión, no según qué modelo aparezca en el encabezado. (La Batch API, con 50% de descuento en entrada y salida, es una modalidad distinta de la API de Anthropic pensada para trabajo asíncrono por lotes; una sesión interactiva de Claude Code no pasa por ahí, así que no forma parte de este ahorro.) Incluso en segundo plano hay consumo: resumir conversaciones para claude --resume o comprobar el estado con comandos como /usage gasta típicamente menos de $0,04 por sesión, según la documentación oficial de gestión de costes, que sitúa el gasto medio en despliegues de empresa en unos $13 por desarrollador activo al día y entre $150 y $250 al mes, con el 90% de usuarios por debajo de $30 al día.

Cuándo te basta esta capa: si trabajas en solitario y solo quieres una foto puntual del gasto de la sesión o de la semana, /usage ya la da sin instalar nada. El límite es que solo la ves cuando la pides.

Statusline: el número sin ir a buscarlo, en la terminal

El statusline de Claude Code es una barra personalizable en la parte inferior del terminal que ejecuta el comando shell que configures en statusLine dentro de settings.json en cada refresco de interfaz, y que recibe por stdin un JSON de sesión con modelo, coste, ventana de contexto y límites de cuota, sin gastar tokens por consultarlo.

Esto es lo que cambió desde que montar ccusage era la única forma de ver coste en tiempo real: hoy el propio JSON incluye un bloque cost.total_cost_usd, un bloque context_window con used_percentage, y -si usas un plan Claude.ai- un bloque rate_limits con five_hour y seven_day, cada uno con su used_percentage y su hora de reset. Un script mínimo con jq, sin dependencias externas, ya puede mostrar esto:

{
  "statusLine": {
    "type": "command",
    "command": "bash ~/.claude/statusline.sh",
    "timeout": 3000
  }
}

#!/bin/bash
input=$(cat)

MODEL=$(echo "$input" | jq -r '.model.display_name')
COST=$(echo "$input" | jq -r '.cost.total_cost_usd // 0')
CTX=$(echo "$input" | jq -r '.context_window.used_percentage // 0')
FIVE_H=$(echo "$input" | jq -r '.rate_limits.five_hour.used_percentage // empty')

LINE="[$MODEL] \$$(printf '%.2f' "$COST") | ctx: ${CTX}%"
[ -n "$FIVE_H" ] && LINE="$LINE | 5h: $(printf '%.0f' "$FIVE_H")%"
echo "$LINE"

Esto cubre coste y cuota de un vistazo sin instalar nada, tal como documenta la referencia oficial del statusline. Lo que ese JSON no da es burn rate (tokens por minuto), histórico por día o por proyecto, ni una vista agregada si combinas Claude Code con otros CLIs agénticos. Para eso sigue siendo la herramienta más madura ccusage: lee los mismos archivos de sesión en ~/.claude/projects/, calcula burn rate y desgloses por día, semana, mes o sesión, e incluye un subcomando statusline pensado específicamente para este uso. Sigue activo -versión 20.0.19 a fecha de este artículo, con más de 14.000 estrellas en GitHub- y su alcance creció: además de Claude Code ahora también lee sesiones de Codex CLI, OpenCode, Amp y varios agentes más, útil si alternas herramientas.

{
  "statusLine": {
    "type": "command",
    "command": "ccusage statusline --visual-burn-rate emoji",
    "timeout": 5000
  }
}

Con esa línea en settings.json no hace falta nada más: ccusage statusline ya lee ~/.claude/projects/ por su cuenta en cada refresco, sin hooks ni caché intermedia que mantener. Como con cualquier binario que se ejecuta en cada refresco, instala ccusage en global (npm install -g ccusage) en vez de con npx: la descarga de la primera ejecución puede agotar un timeout corto y dejar el statusline en blanco. Si necesitas el detalle de una sesión concreta fuera del statusline, el subcomando es ccusage session --json (en singular, no sessions), documentado en su README.

Cuándo te basta esta capa: si vives en terminal con un único agente y solo necesitas coste y cuota en tiempo real, el JSON nativo ya lo resuelve. Si necesitas burn rate, tendencias o mezclas herramientas, ccusage sigue mereciendo la pena.

El mismo control dentro de VS Code

La extensión oficial de VS Code (anthropic.claude-code) dejó de ser solo el panel de chat: desde la versión 2.1.174, ejecutar /usage desde el menú de comandos abre un diálogo de cuenta y uso con las mismas barras de plan, el mismo desglose por skill, subagente, plugin y servidor MCP, y el mismo alternador entre día y semana que ves en el comando de terminal, según confirma la documentación oficial de la extensión. Ya no es del todo cierto que Anthropic no ofrezca nada propio dentro del editor: lo que sigue faltando es un número siempre visible en la barra de estado sin tener que abrir el diálogo.

Ese hueco lo sigue llenando la comunidad. Estas tres extensiones están publicadas y activas hoy en el Marketplace, verificadas por su ID exacto porque varias comparten nombre parecido:

Las tres declaran leer los mismos JSONL locales que ya escribe Claude Code; el límite de cuota real (rate limit) no vive en esos ficheros, así que la que lo muestra en su barra -man-vu- necesita alguna llamada mínima a tu cuenta para leerlo. Si programas mucho y quieres el número siempre a la vista sin abrir un diálogo, esta capa gana a la oficial; si te basta comprobarlo una vez por sesión, el diálogo de /usage ya viene incluido de serie.

Cuándo te basta esta capa: trabajas en VS Code y quieres el dato de un vistazo constante en la barra de estado, no solo cuando lo pides.

Cuando el problema es de equipo: OpenTelemetry

Ninguna de las capas anteriores agrega datos de varias personas ni guarda histórico más allá de tu máquina. Para eso, el camino oficial es exportar telemetría por OpenTelemetry (OTel), en beta pero funcional, activable solo con variables de entorno y sin SDK ni wrapper:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317

Con esto activo, Claude Code emite métricas con nombre y atributos estables: claude_code.token.usage desglosada por tipo (entrada, salida, lectura y escritura de caché) y claude_code.cost.usage en dólares, ambas segmentables por modelo, usuario, sesión, skill, plugin o subagente, según la documentación oficial de monitorización. Los intervalos de export por defecto son 60 segundos para métricas y 5 para logs (ajustables con OTEL_METRIC_EXPORT_INTERVAL y OTEL_LOGS_EXPORT_INTERVAL): son la cadencia periódica de envío, no una latencia máxima garantizada, se intenta exportar con esa cadencia, pero la entrega puede tardar más por transporte, colas o reintentos. El contenido sensible -prompts, parámetros de comandos, cuerpos de API- va redactado por defecto; hay que activarlo explícitamente con variables como OTEL_LOG_USER_PROMPTS.

Para no montar el backend desde cero, existe un dashboard publicado en Grafana Labs (ID 25255) que consume estas métricas vía PromQL y ya trae coste, tokens, sesiones, líneas de código, commits y pull requests por usuario. Si tu organización está en un plan Team o Enterprise, hay una alternativa sin montar nada: el informe de gasto de la analítica de organización ya agrega coste estimado por persona y por modelo con exportación a CSV, sobre una cuota compartida con Claude chat y Cowork que se reinicia en ventanas de 5 horas y semanales.

Cuándo te basta esta capa: cuando el problema deja de ser "cuánto gasto yo" y pasa a ser "cuánto gasta el equipo y quién dispara los picos".

Qué capa activar según tu caso

Las cuatro capas no son excluyentes -lo habitual es combinar dos-, pero si solo vas a activar una hoy, esta tabla resume por dónde empezar:

Empieza siempre por la capa más barata para tu caso: casi nadie necesita las cuatro a la vez, y montar OpenTelemetry para controlar el gasto de una sola persona es más infraestructura de la que el problema pide.