Cada semana me quedaba sin créditos de Claude Code para el jueves. Esto reveló la auditoría.

Era jueves por la tarde. Aviso de cuota: Límite semanal alcanzado. Dos días antes. Otra vez.

(Mi cuota se reinicia los sábados a la 1am, por eso el muro me cae miércoles o jueves — cinco o seis días dentro de un ciclo de siete. Claude Max amarra tu semana a la fecha en que te suscribiste, así que tu reset puede caer cualquier día. La forma es la misma: te quedas sin créditos N días antes, todas las semanas.)

Ya conozco el patrón. Si algo falla a la misma hora cada semana, el problema no es el límite. Es el enfoque.

En vez de intentar esquivar la cuota, corrí cost-per-day.sh sobre el JSONL de Claude Code y me puse a ver qué estaba pasando en realidad.

Así se veía "quedarse sin cuota" cada semana: tres días de sprint todavía pendientes, banner arriba, trabajo en pausa. La línea turquesa es la misma carga con las cuatro palancas activas. Semana completa, con margen.

Resumen rápido

Es una historia de Max 200. La factura de $200 al mes no cambia. Lo que cambia es cuánto trabajo entra en la misma ventana semanal.

Una nota rápida sobre la matemática: cada cifra de $/día más abajo es una estimación equivalente a la API, calculada desde los conteos de tokens JSONL a las tarifas publicadas de Anthropic. En un plan Max con tarifa plana esos dólares no existen en ninguna factura — son el proxy más limpio que tengo para medir consumo de cuota. La fórmula completa está en el bloque de metodología, en "La auditoría".

Cuatro cambios dieron una mejora de 3× en capacidad de cuota:

Y los resultados:

Un solo cambio se llevó el 94% del trabajo. Los otros tres se repartieron el 6% restante — y casi ni los publico.

Esto es el equivalente individual / plan Max de lo que los equipos ya venían resolviendo a escala de API, con scripts de medición que puedes correr sobre tu propio JSONL. El repo está en clarivant/claude-credits-multiplier. Todo lo que sigue es reproducible.

La auditoría

Claude Code escribe un archivo JSONL por proyecto en ~/.claude/projects/<hash>/*.jsonl. Una entrada por cada turno de asistente con el modelo, los conteos de tokens (entrada / creación de caché / lectura de caché / salida) y el timestamp. Armé un script, cost-per-day.sh, que recorre ese log y muestra el gasto por día y por tier de modelo. Está en el repo junto con todo lo demás de este post.

Metodología en un bloque: los números vienen de transcripciones JSONL del 25 de abril al 18 de mayo: 24 días, 82,973 turnos. El $/turno se calcula como (entrada × $/MTok_entrada + salida × $/MTok_salida) / turnos a las tarifas publicadas por Anthropic en abril 2026 ($25/MTok de salida en Opus, $15/MTok de salida en Sonnet). Etiqueto los números como Hard cuando vienen medidos directamente y como Estimated cuando salen de una fórmula declarada. Las etiquetas aparecen en cada cifra donde la distinción importa.

Una muestra de la salida:

$ ./cost-per-day.sh
2026-04-28  $1267  Opus:99% Sonnet:1%   turns:4892
2026-05-02  $203   Opus:14% Sonnet:86%  turns:3201  ← opusplan activado
2026-05-09  $102   Opus:11% Sonnet:88%  turns:2987
2026-05-14  $78    Opus:12% Sonnet:87%  turns:2654

Lo que apareció al correrlo:

• 99% de los turnos en Opus 4.x. Todos, sin importar qué tarea era.
• Costo promedio por turno: $0.2568 a precios equivalentes a la API.
• Opus sale 1.67× más caro que Sonnet en la tarifa de salida ($25/MTok Opus vs $15/MTok Sonnet 4.6, según las tarifas publicadas por Anthropic en abril 2026 — misma tarifa en Opus 4.6 y 4.7). Cada turno estaba pagando ese premium.
• Trayectoria semanal: cuota agotada para el jueves o viernes.

Antes de seguir, cómo funciona realmente la cuota. Esto importa para entender el problema. Claude Max 200 tiene un pool total de créditos semanales que se comparte entre todos los modelos. Sonnet además tiene su propio cap, separado del total. Si solo usas Sonnet, te chocas con su cap sin tocar el pool general — los créditos de Opus y Haiku quedan intactos. Si solo usas Opus, drenas el pool total por completo y el cap de Sonnet ni se mueve. Yo estaba haciendo lo segundo. El 99% de Opus no era nada más caro por turno; estaba quemando el único recurso que define si chocas con el muro el jueves. (Anthropic documenta la estructura de dos capas oficialmente. Capa diferente, mismo muro.)

Dos escenarios, mismos créditos iniciales. A la izquierda: Opus drena el pool compartido y los créditos de Sonnet quedan intactos. A la derecha: con Sonnet manejando el 84% de los turnos, los dos pools terminan el domingo con margen. La diferencia entre los dos niveles del lado derecho es el multiplicador de 3× hecho visual.

Lo obvio, dicho sin adornos: cada tarea, por más mecánica que fuera, se enrutaba al modelo más caro por default. Correr un comando en bash: Opus. Escribir un mensaje de commit: Opus. Revisar un diff de tres líneas: Opus. (Sí, todas.)

Y se iba acumulando. Un plugin que uso despachaba 3 subagentes por tarea (un implementador y dos revisores), y todos heredaban Opus de la sesión padre. Cada turno de planificación lanzaba un mini-clúster de Opus que yo no podía ni ver.

No había telemetría para ver nada de esto hasta que la escribí yo. Esa es la moraleja real. Antes de poder arreglar el consumo de cuota, tienes que poder verlo.

Lo tenía en el orden equivocado

Tenía semanas gastándome el crédito dos, tres, cuatro días antes de cuando debería terminarse, y me estaba frustrando. Implementé los modelos locales primero, con la esperanza de que todo se bajara, y no. Solamente veía que estaba ahorrando un par de dólares a la semana.

Después empecé a armar el stack completo, donde incluí opusplan, Context Mode, SocratiCode y el proxy de LiteLLM. Las llamadas por turno seguían ahorrando casi la misma cantidad de dólares. Significativo en porcentaje, pequeño en valor absoluto: menos del 1.3% en cada llamada. Viendo solo ese número, casi ni publico esto.

Pero después de empezar a analizar bien y darme cuenta de que mis créditos estaban durando más tiempo, que ya estaba llegando al final de la semana sin chocar con el muro, fue cuando me cayó el veinte. No eran solamente los tokens que ya no se enviaban porque se procesaban de manera local. Eran los tokens que estaban siendo ahorrados en cada llamada, en cada turno, y que exponencialmente iban ahorrando y ahorrando y ahorrando sobre el resto de la sesión.

Por eso este post va en orden de impacto: opusplan primero, Context Mode segundo, SocratiCode tercero, LLM local cuarto. No es el orden en que los descubrí. El orden de descubrimiento fue exactamente al revés.

Palanca 1: opusplan — una variable de entorno, ~94% de la ganancia

Gasto diario equivalente a API, calculado desde los conteos de tokens del JSONL a tarifas de Opus/Sonnet de abril 2026. La línea base W0 (magenta) promedió $858/día. El tramo W2 (sombreado turquesa), con las cuatro palancas activas, promedió $283. El bar de $1,267 del 28 de abril se convirtió en los $78 del 14 de mayo. 16× más barato día a día.

El binario claude soporta un modo de ruteo llamado opusplan. Se activa como variable de entorno de shell:

export ANTHROPIC_MODEL=opusplan

Cuando está activo, Opus solo corre en modo Plan (Shift+Tab). Todo lo demás (turnos de ejecución, uso de herramientas, despachos de subagentes) se va a Sonnet.

Antes de confiar en eso, verifiqué que estuviera realmente cableado:

$ strings $(which claude) | grep opusplan
opusplan   # aparece 5× en el binario

La flag está documentada oficialmente, pero no aparece en el selector estándar de /model, así que la mayoría de los devs con los que he hablado la describen como "oculta". El grep de arriba es una verificación reproducible que puedes correr en tu propia instalación. Se ha mantenido estable a lo largo de varios releases de Claude Code hasta mayo 2026.

Puse la variable el 2 de mayo. Ese día Opus pasó de 99% a 14.2% de los turnos. El lunes siguiente fue la primera semana de sprint completa sin chocar con el muro de cuota.

De dónde sale el 94%. opusplan es dueño de cada decisión de ruteo fuera de modo Plan, el 99% de todos los turnos. Las otras tres palancas se componen encima vía el multiplicador de relecturas de caché, y sus ahorros aparecen como estiramiento de cuota más que en dólares por turno, lo cual es más difícil de atribuir limpiamente. El 94% es la porción de la reducción de $/turno atribuible al ruteo de modelo solo. El 6% restante son Context Mode, SocratiCode y delegación a LLM local actuando juntas. (No vas a encontrar esa descomposición derivada línea por línea — los dólares no suman linealmente porque las palancas interactúan a través de las relecturas de caché. El número refleja el dominio del ruteo sobre la palanca de costo en dólares, no un split limpio 94/6 del multiplicador.)

La distinción entre 2.4× y 3.0×. Objeción razonable: ¿no será que hice menos trabajo en W2? El número por turno responde solo. W0 = $0.215/turno, W2 = $0.090/turno. 2.4× más barato por unidad de trabajo, independiente del volumen. El 3.0× del $/día incluye una caída ligera de volumen (3,164 turnos/día vs 3,996 en W0). Las dos cifras se sostienen.

El share de turnos no es el share de tokens. Después de activar opusplan, en todos los turnos siguientes, Opus se estabilizó en 15.8%. Ese único día del 2 de mayo fue 14.2%; lo que importa para el multiplicador es el promedio acumulado. Ese 15.8% de turnos se traduce a 30.5% de tokens de salida: las respuestas en modo Plan son más largas (1,838 tokens contra 790 de Sonnet). El ahorro viene de que Sonnet a $15/MTok atiende el 84% de los turnos que no necesitan juicio arquitectónico. No de que Opus haga menos trabajo.

Herencia entre subagentes. La pregunta obvia: si modo Plan dispara en Opus y despacha subagentes, ¿esos subagentes heredan Opus? No. ANTHROPIC_MODEL=opusplan es una variable de entorno de shell. Los subprocesos que lanza Agent heredan el entorno completo del padre. Cada despacho sigue el mismo ruteo. Audité el JSONL específicamente para esto: cero turnos de Opus marcados como subagente (isSidechain=True) en 9,298 llamadas a Opus posteriores al 2 de mayo. El 15.8% es honesto a través del orquestador y de todos los subagentes por igual.

Tu número va a ser distinto. El promedio de 15.8% mezcla proyectos con cargas muy diferentes:

Si tu trabajo es principalmente planeación arquitectónica, espera entre 25 y 40%. Si es principalmente implementación: entre 5 y 15%.

Palanca 2: Context Mode y el multiplicador de relecturas de caché

Esta palanca se nota menos, pero se compone más fuerte.

Cada turno de una sesión de Claude Code relee la caché de la sesión. El cache hit rate corrió al 96.1% a lo largo de 82,973 turnos en 24 días. Un token que entra al contexto temprano se relee en prácticamente cada turno siguiente hasta que cierras la sesión.

La cuenta es molesta pero importa: un token que entra al contexto en el turno 50 de una sesión de 500 turnos se relee unas 450 veces. Si lo dejas afuera, evitaste 450 relecturas. No una. El valor esperado, promediando dónde entraría el token a lo largo de la sesión, es ~M/2 lecturas evitadas por cada token que desvías.

Context Mode MCP (mantenido por mksglu, se instala con npx context-mode) toma la salida de las herramientas y la encapsula en un índice FTS5 local en tu máquina. Fetches web, lecturas de archivos grandes, output de comandos. Todo va al sandbox. Solo lo que buscas explícitamente con ctx_search entra al contexto de Claude. El mantenedor reporta ~98% de reducción de contexto en sesiones típicas; mis propios números de 15 días están abajo.

La configuración es un bloque en .mcp.json:

{
  "mcpServers": {
    "context-mode": {
      "command": "npx",
      "args": ["-y", "context-mode"]
    }
  }
}

Y se refuerza con hooks: cualquier Read de más de 200 líneas sin parámetro limit queda bloqueado en duro → reroute a ctx_execute_file. Cualquier fetch web → ctx_fetch_and_index. Sin los hooks, Context Mode existe pero se aplica de forma desigual.

Resultados de 15 días (3 may → 18 may):

Los números Estimated usan tokens_fuera × (turnos_sesión / 2). Mantengo las etiquetas Hard/Estimated en todo el post. La distinción importa.

Los días pico (el 9 de mayo con 2.1M tokens encapsulados, el 11 con 2.2M) fueron sesiones de sprint multi-archivo donde el output de las herramientas habría saturado la ventana de contexto. Ahí es donde Context Mode aparece más claramente en los datos.

Una advertencia sobre calidad: no hay A/B test controlado. La hipótesis es que encapsular el output de herramientas y recuperar fragmentos relevantes no degrada la calidad de las respuestas. En la práctica eso se sostuvo en todas las sesiones: el código compiló, las búsquedas devolvieron resultados útiles, las tareas se completaron bien. Pero es verificación anecdótica, no un benchmark. Un caso de falla sería difícil de distinguir de un error normal.

Palanca 3: SocratiCode — búsqueda semántica en codebases

El otro lugar donde el contexto de Claude se inunda es cuando haces grep en un codebase y terminas leyendo los 20 mejores matches.

SocratiCode es un servidor MCP local (basado en Docker, totalmente offline) que indexa el proyecto con embeddings locales (nomic-embed-text en GPU 1 → Qdrant) y devuelve fragmentos rankeados con búsqueda híbrida semántica + BM25. Cada llamada a codebase_search devuelve ~5 fragmentos rankeados (unas 500 líneas en total) en lugar de que grep/Read vuelque archivos enteros al contexto de Claude.

Los ahorros se componen por el mismo mecanismo de relectura de caché que la Palanca 2. Un fragmento que nunca entra al contexto en el turno N no se relee en cada turno siguiente por el resto de la sesión. Mismo mecanismo, ruta distinta.

Números operativos (2 may → 18 may, 17 días post-fix):

Por qué aquí no hay un número Hard de ahorros en tokens. A diferencia de ctx_stats en Context Mode, SocratiCode no expone un hook de métricas por llamada. Cada búsqueda reemplaza una cantidad incierta de secuencias grep+Read que habrían inundado el contexto. El conteo de 711 llamadas es la medida más limpia de qué tanto lo uso. Los tokens mantenidos fuera del contexto se estiman aguas abajo desde la matemática del multiplicador de relecturas — mismo mecanismo que la Palanca 2, solo que no medido por llamada.

Por qué el salto pre-fix → post-fix fue de 7.8×. El cableado estaba roto en dos formas al mismo tiempo. El bug de embeddings base64 (cubierto en "Lo que no funcionó") hacía que el índice fuera prácticamente inservible. Y CLAUDE.md tenía el nombre de herramienta MCP equivocado (socraticode_* en vez de mcp__socraticode__*), así que Claude Code no podía alcanzar la herramienta de forma confiable. Los dos quedaron arreglados el 2 de mayo, junto con socraticode-nudge.sh, un hook PreToolUse que se dispara con grep / rg / find y redirige a búsqueda semántica. Después de que los tres aterrizaron, el uso saltó de 4–7 llamadas/día en sprints pesados a 41.8/día.

Para strings exactos (nombres de marca, clases CSS, constantes), grep sigue siendo la herramienta correcta. SocratiCode es para "dónde se define X / quién llama a Y / dónde se lee la config Z."

Palanca 4: Delegación a LLMs locales

Corro dos RTX 3090 con un proxy LiteLLM al frente (Qwen3.6-27B en GPU 0, Qwen3-14B en GPU 1, embeddings en GPU 0 junto al modelo grande). El hardware importa menos que el protocolo: code_task_files le pasa al modelo local una ruta de archivo en vez del contenido. El modelo lee desde disco, escribe la salida a disco, y Claude recibe la ruta del resultado. El contenido del archivo nunca entra al contexto de Claude.

97% menos tokens de Claude por llamada. Es una proporción por llamada. La delegación local fue la fracción más chica del multiplicador semanal en números absolutos.

Para no engañar a nadie: esto requiere un ejecutor que no sea Claude. 890 llamadas, 91% de offload entre el 1 y el 18 de mayo. Cero errores en la reconciliación más reciente de 389 llamadas vía proxy LiteLLM. Sin hardware local, delegarías a otra API. El ahorro se mueve a otra factura. El patrón sirve igual; lo que cambia es la economía según cuál sea tu ejecutor.

Lo que no funcionó

Tres cosas que intenté y terminé revirtiendo o arreglando. (Esta es la sección que me deja en paz para publicar los números de arriba.)

nomic-embed vía LiteLLM. Intenté enrutar las llamadas de embedding por el proxy de LiteLLM para tener telemetría unificada. La equivalencia coseno falló. En silencio. Causa raíz: nomic-embed-text necesita que se inyecten los prefijos search_query: / search_document: en la entrada, y el adaptador LiteLLM → Ollama los descarta sin avisar. Los resultados se veían razonables. No eran equivalentes. Me quedé con Ollama directo (puerto 11434). Lección: prueba la similitud coseno antes de confiar en cualquier adaptador de embeddings.

El bug base64 de dimensiones (y un parche vendorizado). Lección al frente: cuando una herramienta devuelve embeddings con la forma equivocada, el bug casi siempre está más arriba en la cadena de SDK + adaptador. No en la herramienta que tienes en la mano. Esto no fue una falla de SocratiCode (el mismo bug ya había caído en otros tres proyectos: langchain-ai/langchainjs#8221, mem0ai/mem0#4057, getzep/graphiti#868). Sigo corriendo SocratiCode en producción. El parche es de una línea. Lo que pasó: SocratiCode empezó a devolver embeddings de 192 dimensiones contra una colección de Qdrant de 768. Búsquedas tirando 400, fallos en upsert, confusión total hasta que verifiqué las dimensiones reales de los embeddings. La cadena de causa raíz: el SDK de OpenAI Node 6.34.0 manda encoding_format: "base64" por default (desde openai-node #1310). El adaptador Ollama de LiteLLM 1.83.13 ignora esa flag y devuelve arrays de floats crudos. El SDK los decodifica mal como un Float32Array exactamente 4× más corto (768 → 192 dim). Fix: vendoricé SocratiCode 1.6.1 con un parche de una línea forzando encoding_format: "float".

El mito del "40% más lento a 280W". Mis docs iniciales decían que limitar las GPUs a 280W hacía el stack 40% más lento que stock. El benchmark mostró 9%. Esta carga está limitada por ancho de banda de memoria. Subir el power añade FLOPS, pero el cuello de botella es el bandwidth de VRAM. El 40% venía de posts de foros sobre una carga completamente diferente. Lección: no importes benchmarks sin chequear primero si la carga coincide con la tuya.

De qué se trata esto, y de qué no

En Max tarifa plana: nada de esto baja la factura. Los $200/mes no cambian. El valor está enteramente en capacidad de cuota. Más semanas de sprint antes del límite, menos pausas a media tarde del jueves.

Un matiz que vale la pena marcar: después de opusplan, la mayoría de los turnos van a Sonnet. Si tu mezcla de trabajo es muy pesada en ejecución, podrías pegarle al cap por modelo de Sonnet antes de agotar el pool total. Un muro de jueves diferente. La telemetría te dice cuál estás acercándote. El arreglo es el mismo: mide primero.

En facturación API por uso: los ahorros son reducciones directas en dólares. opusplan mueve la mayor parte del trabajo de Opus ($25/MTok salida) a Sonnet ($15/MTok). Alrededor de 40 a 60% de reducción en la factura de API, dependiendo de tu mezcla actual de modelos. Context Mode aporta más arriba. El multiplicador de 3× es matemática de Max tarifa plana. Tu equivalente en API por uso va a ser un número distinto, pero la dirección es la misma.

En cualquier caso, lo que hace todo esto medible es la telemetría. Sin saber qué dice tu propio JSONL, estás optimizando por intuición.

Preguntas frecuentes

¿Necesito GPUs locales para sacar la mayor parte del beneficio?

No. Las dos palancas más grandes (opusplan y Context Mode) son completamente agnósticas al hardware. SocratiCode y la delegación a LLM local necesitan un ejecutor que no sea Claude — el GPU local funciona, pero una API remota de embeddings o un LLM remoto también. El 94% de la ganancia viene de opusplan solo, una variable de entorno, sin infraestructura. Empieza por ahí.

¿Por dónde es más simple empezar?

export ANTHROPIC_MODEL=opusplan en tu perfil de shell. Una línea, nada más. Para confirmar que prendió: busca "model": "claude-sonnet" en tu JSONL en la siguiente sesión, o corre opusplan-validation.sh del repo claude-credits-multiplier. Mide una semana de baseline, activa la variable, mide la semana siguiente. La inflexión se ve clarísima en los datos.

¿Anthropic puede cambiar o quitar opusplan sin aviso?

La flag está documentada oficialmente, pero no aparece en el selector estándar de /model. Por eso casi todo el mundo la describe como "oculta". Se ha mantenido estable a lo largo de varios releases de Claude Code hasta mayo 2026. Para confirmar que está cableada en tu instalación:

strings $(which claude) | grep opusplan

Si desaparece después de un update, la quitaron. Que esté documentada oficialmente me da más confianza que si solo viviera en el binario. Pero yo no trataría a ninguna flag específica de ruteo de modelo como una garantía permanente.

Cierre

Lo que más me sorprendió: el 94% de la mejora de cuota vino de una variable de entorno de shell que cambió qué modelo maneja qué tipo de turno. El rig de GPU es infraestructura genuinamente útil, y aportó la fracción más chica de la mejora semanal. (Me molestó un poco, la verdad.)

La infraestructura que terminó importando fue la medición. Sin cost-per-day.sh mostrándome lo que el JSONL realmente decía, nada de esto habría sido visible hasta quedarme sin cuota el jueves otra vez.

Los scripts de telemetría están en claude-credits-multiplier: cost-per-day.sh para gasto por día y por modelo, opusplan-validation.sh para confirmar que tu binario soporta la flag de ruteo, ctx-stats-parser.sh para resumir los ahorros de Context Mode. Córrelos sobre tu propio JSONL. Tu baseline va a ser distinto, tus brechas van a ser distintas, tus palancas van a ser distintas.

La forma de este trabajo (medir el costo real de algo opaco, encontrar la palanca que se lleva el 94% del trabajo, publicar el script para que la ganancia sea verificable) es la misma que uso en costo de pipelines de datos, en confianza sobre analytics, y en infraestructura de IA en Clarivant. Superficie distinta, misma disciplina de ingeniería. Si quieres entender a dónde se va realmente tu cuota (o por qué la factura del warehouse de analytics no para de subir), hablemos.