Problema en el plan Claude Code Pro Max 5x: la cuota se agota en 1.5 horas incluso con un uso moderado

• En el plan Pro Max 5x (contexto de 1M), incluso con un nivel moderado de preguntas y respuestas y trabajo de desarrollo, se produce un exceso del límite de tokens en apenas 1.5 horas
• Se señala como causa un error por el cual los tokens cache_read se calculan con la tarifa completa (1.0x), lo que elimina el efecto del caché y provoca un consumo acelerado
• Las invocaciones automáticas de sesiones en segundo plano, la compresión automática (auto-compact) y las entradas de contexto grandes aumentan conjuntamente la velocidad de consumo
• La comunidad analiza como causas principales el acortamiento del TTL del caché (de 1 hora a 5 minutos) y el fenómeno de invalidación de caché (cache busting)
• Anthropic está trabajando en reducir el contexto predeterminado (a 400k), mejoras de UX y optimización de invocaciones inactivas, mientras recopila comentarios de usuarios

---

Problema de agotamiento acelerado de cuota en el plan Pro Max 5x

• Se reportó que en el plan Pro Max 5x (claude-opus-4-6, contexto de 1M) la cuota se agota en apenas 1.5 horas, incluso con preguntas y respuestas de nivel intermedio y desarrollo ligero
  • En una sesión previa de 5 horas de desarrollo intensivo, el consumo fue normal, pero después del reinicio comenzó el consumo acelerado
  • El problema ocurrió en Claude Code CLI sobre WSL2, en una sola sesión (con 2 compresiones automáticas)
• Se apunta como causa principal a un error por el cual los tokens cache_read se calculan con la tarifa completa (1.0x)
  • En condiciones normales, cache_read debería calcularse con una proporción de 1/10; de lo contrario, el efecto del caché desaparece
  • El uso de tokens se analizó a través del objeto usage en los registros de sesión (~/.claude/projects/.../*.jsonl)
• Las invocaciones automáticas de sesiones en segundo plano, el alto costo del procesamiento de compresión automática (auto-compact) y las entradas grandes derivadas de la ventana de contexto de 1M se combinan para acelerar el consumo
• Según el análisis de la comunidad, algunos usuarios señalan como causas principales el acortamiento del TTL del caché (de 1 hora a 5 minutos) y el fenómeno de invalidación de caché (cache busting)
• El equipo de Anthropic está trabajando en reducir el contexto predeterminado (a 400k), mejoras de UX y optimización de invocaciones inactivas, y solicita más datos mediante comentarios de usuarios

Consumo de tokens medido

• Ventana 1 (15:00–20:00, 5 horas, desarrollo intensivo)

  • 2,715 llamadas a la API, Cache read 1,044M, Cache create 16.8M, salida de 1.15M tokens
  • Entrada efectiva (aplicando la proporción de 1/10): 121.8M tokens
  • Se realizaron implementación de servidor Express + app iOS, pipeline de graphify y coordinación multiagente basada en SPEC

• Ventana 2 (20:00–21:30, 1.5 horas, uso moderado)

  • Sesión principal (vibehq): API 222 veces, Cache read 23.2M, Cache create 1.4M, salida 91k
  • Sesiones en segundo plano (incluyendo token-analysis y career-ops): 691 llamadas en total, Cache read 103.9M, salida 387k
  • Total de 13.1M tokens efectivos (aplicando la proporción de 1/10) → en condiciones normales, no habría exceso de cuota
  • En la práctica fueron 105.7M tokens (si se calculan a 1.0x) → equivalente a 70.5M por hora, en línea con el agotamiento de la cuota

Resumen de los principales problemas

• 1. Error en el cálculo del límite de cobro para tokens Cache read

  • Lo esperado: cache_read se calcula con una proporción de 1/10
  • Lo real: se calcula con la tarifa completa, lo que anula el efecto del caché
  • En un entorno de contexto de 1M, se envían entre 100k y 960k tokens por llamada, por lo que más de 200 llamadas pueden agotar la cuota en minutos

• 2. Consumo de cuota compartida por sesiones en segundo plano

  • Las sesiones inactivas (como token-analysis y career-ops) también siguen consumiendo la cuota compartida mediante llamadas automáticas de compresión y posprocesamiento

• 3. Llamadas de alto costo de la compresión automática (auto-compact)

  • Antes de comprimir, se envía todo el contexto (~966k tokens) como cache_creation, lo que hace que la llamada más cara ocurra automáticamente

• 4. Efectos secundarios de la ventana de contexto de 1M

  • Un contexto grande dispara la cantidad de tokens por llamada y acelera la velocidad de consumo de cuota

Pasos para reproducirlo

1. Ejecutar Claude Code con el modelo Opus en el plan Pro Max 5x
2. Incluir unos 30 archivos de reglas en ~/.claude/rules/ (sobrecarga de 19k tokens)
3. Realizar tareas centradas en herramientas como lectura de archivos, build y pruebas
4. Verificar el aumento del contexto con el comando /context
5. Confirmar la caída abrupta de la cuota tras 200–300 llamadas
6. Mantener 2–3 sesiones activas en otra terminal
7. Confirmar que la cuota vuelve a agotarse en poco tiempo incluso después del reinicio

Comparación entre el comportamiento esperado y el real

• Esperado:

  • cache_read debe calcularse con una proporción de 1/10
  • Las sesiones inactivas deben tener un consumo mínimo
  • La compresión automática no debe provocar un consumo excesivo
  • Con uso moderado, debería poder durar entre 2 y 3 horas

• Real:

  • Se agota en 1.5 horas
  • Las sesiones en segundo plano representan el 78% del consumo
  • Se enviaron 105.7M tokens en total, lo que sugiere que cache_read se calculó con la tarifa completa

Propuestas de mejora

1. Aclarar el método de cálculo de cache_read — especificar en la documentación la proporción real usada para el límite de cobro
2. Límite basado en tokens efectivos — corregir el cálculo para que cache_read use la proporción de 1/10
3. Detección de sesiones inactivas — impedir llamadas automáticas de sesiones inactivas o mostrar advertencias
4. Visualización en tiempo real del consumo de tokens — mostrar el uso de cache_read, cache_create, entrada y salida por separado
5. Predicción de costo basada en contexto — mostrar el costo estimado en tokens antes de ejecutar la tarea

Análisis y discusión de la comunidad

• cnighswonger

  • Recolectó durante 24 horas datos de 1,500 llamadas usando el interceptor claude-code-cache-fix
  • Tras comprobar tres hipótesis (cache_read 0.0x, 0.1x y 1.0x), solo el modelo 0.0x mostró resultados consistentes en una ventana de 5 horas (CV 34.4%)
  • Conclusión: cache_read prácticamente no afecta la cuota en la práctica, y el caché funciona con normalidad
  • Aun así, se necesita validación adicional con datos de una sola cuenta

• henu-wang

  • Tras una regresión en la que el TTL del caché se redujo de 1 hora a 5 minutos, cada pausa de sesión provoca cache_create, generando un costo 12.5 veces mayor
  • Cuanto más largo es el contexto, más aumenta el costo de forma no lineal
  • Como solución temporal, propone mantener sesiones cortas, usar activamente el comando /compact y precargar el contexto clave en CLAUDE.md

• bcherny (equipo de Anthropic)

  • Reconoció que con una ventana de contexto de 1M, los fallos de caché del prompt tienen un costo alto
  • Están probando mejoras de UX (guiar a usar /clear al reanudar sesiones largas) y una reducción del contexto predeterminado a 400k
  • Confirmaron casos en los que tareas inactivas consumen demasiados tokens al usar múltiples agentes y plugins, y están trabajando en mejoras de limpieza automática y programación

• wadabum

  • Señaló un bug en el que el caché no acierta en absoluto en sesiones nuevas (#47098, #47107)
  • El prompt del sistema basado en git status y los bloques de CLAUDE.md cambian en cada sesión, provocando invalidación de caché (cache busting)
  • cnighswonger respondió que el interceptor sí realiza cierta estabilización del orden, pero que el problema de git-status requiere una corrección aparte

Resumen de propuestas de la comunidad

• RockyMM: cuando una sesión alcance el límite, inducir una reanudación tras un resumen automático y acortar el TTL a 10 minutos
• mikebutash: reportó que en el plan Pro solo eran posibles 2 prompts por cada 5 horas, y confirmó una mejora de 3–4 veces al volver a la versión v2.1.81 e instalar cache-fix
• wutlu: mitigar el problema reiniciando la sesión por cada tarea
• dprkh: ayudar a identificar la causa compartiendo habilidades del modo debug (Skill.md)

Conclusión

• El agotamiento acelerado de la cuota en el plan Pro Max 5x se atribuye a un efecto combinado del comportamiento del caché, la regresión del TTL, la expansión del contexto y las llamadas en segundo plano
• La comunidad plantea que la causa principal no sería un error en el cálculo de cache_read, sino la invalidación del caché y la reducción del TTL
• El equipo de Anthropic está trabajando en reducir el contexto predeterminado, mejorar la UX del caché y optimizar las invocaciones inactivas, y solicita más datos mediante comentarios de usuarios (/feedback)

[kimjoin2]

En términos de calidad, no tiene reemplazo.
Ojalá se pudiera usar más con un parche simple.

[GN⁺]

Opiniones de Hacker News

• Soy Boris del equipo de Claude Code. Tras investigar los problemas reportados recientemente, encontramos dos causas principales

  1. Cuando se usa una ventana de contexto de 1M tokens, un fallo del caché de prompts sale caro. Actualmente el TTL del caché es de 1 hora, así que si te ausentas más de una hora, la sesión expira y hay que volver a cargar todo el caché. Ya desplegamos mejoras de UX para esto y estamos evaluando una opción para bajar el valor predeterminado a 400k. Si quieres probarlo ahora mismo, puedes usar el comando CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claude
  2. Si se ejecutan demasiados plugins o agentes al mismo tiempo, se desperdician tokens. Para resolverlo, estamos trabajando en mejoras de UX y en la limpieza y programación automáticas de tareas no esenciales
     Si estás teniendo este problema, enviar comentarios con el comando /feedback ayuda con la depuración
  • Boris, las experiencias de los usuarios que están apareciendo en la comunidad no son simples excepciones. Como dijo Jeff Bezos, hay momentos en que las anécdotas dicen la verdad, no los datos. Deberían revisar seriamente si sus métricas no están mal
  • Me preguntaba por qué este problema apareció de repente, y al investigar vi que la causa fue que el TTL del caché de prompts se redujo de 1 hora a 5 minutos. Incluso si inicias una sesión nueva, al final igual tienes que reconstruirlo todo, así que es ineficiente. Tener una estructura donde debes vigilar el vencimiento del caché va en contra de la filosofía de CC
  • En mi caso, la regresión más grave fue que el prompt del sistema intentaba escanear malware en los archivos cada vez. Eso consumía tokens rápidamente, y seguía apareciendo la respuesta “not a malware”. Ese diseño fue una mala decisión. Al final abandoné el proyecto y me cambié a Qwen, que ha salido bastante bien
  • La notificación de /clear no es una solución. Si vacías el caché, al final igual hay que reconstruirlo, así que el costo es el mismo. Guiar a los usuarios por UX hacia contextos más pequeños degrada la calidad del servicio. Si el problema es el costo, deberían corregir el precio o la arquitectura
  • OpenAI reiniciaba los límites de uso cuando había problemas, pero Anthropic no está tomando ese tipo de medidas. Esto da la impresión de que es algo intencional

• Últimamente Claude estaba notablemente más lento e ineficiente. Aunque le indicara archivos concretos, se quedaba atrapado más de 5 minutos en bucles de exploración y llegaba muy rápido al límite de sesión. Usándolo solo tres veces al día desaparecía el 25% del límite semanal. Por eso me cambié al plan de Codex de $100, y es mucho mejor en precisión y generosidad. Eso sí, me molesta el tono de Codex, así que agregué instrucciones aparte en Agents.md. Antes Claude Code tenía mejor sensibilidad de UI, pero para depuración de backend y resolución de problemas complejos Codex va por delante. Ahora mismo recomiendo comparar Codex con el plan de $20 de Cursor

  • A mí me pasó algo parecido. Hace unos días Claude parecía quedarse pensando como si se hubiera detenido, y al día siguiente volvió a funcionar normal
  • Estoy usando el plan Codex Business (30 euros) y últimamente siento que la cuota ha bajado. Aun así, sigue ofreciendo condiciones mucho mejores que Claude Code
  • Ahora mismo estoy comparando cómo funciona el confidence score en los modelos Opus, Haiku y Sonnet. Opus es el más eficiente en tareas de dificultad media
  • He usado CC, Gemini-cli y Codex, y CC sigue siendo el mejor. Me da curiosidad si una combinación con Cursor o Aider será mejor
  • La programación con IA desperdicia mucho contexto, así que limitar el alcance con un sandbox personalizado mejora la eficiencia

• Revisando los issues, entendí por qué Anthropic cierra tan rápido los tickets. La mayoría parece ruido generado por IA. Mi solución fue la siguiente

  1. Activar max thinking en todas las sesiones para reducir la exploración de rutas innecesarias
  2. Mantener la sesión siempre activa. Si el caché expira en 5 minutos, hay que reconstruir los tokens
  3. Ejecutar compact en cuanto se superen los 200k tokens
     Lo que más me molesta es que Anthropic haya impuesto a la fuerza el modelo de 1M
  • Yo también me reí al ver el issue. Probablemente fue el resultado de pedirle a Claude Code que “investigara por qué se agotaron los tokens”
  • Unos dicen que hay que activar thinking y otros que hay que desactivarlo. Es irónico que ambos digan que ahorra tokens
  • El núcleo del problema es un bug donde el caché se invalida aleatoriamente. Parece que el cliente API termina antes de tiempo el caché del suscriptor. Además, también subieron en secreto el costo de los tokens de entrada
  • Yo también lo confirmé. max effort ayuda. Es importante mantener el contexto por debajo del 25%. Me pregunto si hay alguna forma de verificar el estado de expiración del caché
  • Puedes desactivar el modelo de 1M con los comandos /model opus o /model sonnet

• Ya da la impresión de que se acerca el fin de la era de los subsidios. En la comunidad de Google Gemini también están explotando las quejas por la reciente reducción de cuota (enlace al issue). Al final yo también me cambié a la combinación de Kiro IDE y Codex CLI, y estoy satisfecho

  • Era algo previsible. Durante la época de tokens gratis, una estrategia inteligente era construir por adelantado las bibliotecas necesarias
  • Anthropic ahora parece estar girando hacia clientes empresariales, y OpenAI va por un camino similar. En Reddit y Discord hay movimiento buscando modelos abiertos o alternativas chinas, pero todavía no hay un sustituto completo
  • antigravity consume rápido la cuota Pro, pero el modo flash es mucho más generoso. Trabajando en un proyecto STM32 obtuve una productividad 3 veces mayor
  • Al final, quizá el destino de esta tendencia sea una era en la que las salidas lleven publicidad
  • Me recuerda a los viajes de Uber que costaban $3

• Me inquieta que el issue que señalaba la causa raíz del problema haya sido cerrado como “Not planned”

  • La respuesta suena poco natural, como escrita por IA. La lógica de que “un TTL de 1 hora es más caro” también suena rara. Cuesta entender que no ofrezcan un toggle por motivos de costo
  • Tampoco hace falta asustarse tanto. Si la calidad baja, simplemente dejas de usarlo
  • Creo que Anthropic vende tokens como un casino y no le importa si el usuario pierde dinero. Si no te gusta ese modelo, creo que es mejor usar un LLM local

• Al hacer rollback a la versión 2.1.34, se resolvieron la mayoría de los problemas de cuota y de caché.
  Agregué "effortLevel": "high", "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": 1, etc., a ~/.claude/settings.json, y eliminé las demás versiones.
  Adaptive thinking sigue estando incompleto, pero si mejora en el futuro podría ayudar. Aun así, estoy pensando en cambiarme a Codex

  • Yo también configuré cosas como CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000, DISABLE_AUTOUPDATER=1, etc., en ~/.bashrc

• También hubo problemas parecidos en modelos inferiores. Creo que un trato justo empieza con mediciones transparentes. Voy a cancelar la suscripción de este mes

  • Hubo casos en que la sesión se iniciaba mientras la computadora estaba en modo de suspensión y se consumían tokens. Incluso una pregunta simple como “¿qué hora es?” gastaba el 10%

• Este año probé hacer la declaración de impuestos con agentes de IA. Usé Opus 4.6, Codex 5.4 y Antigravity 3.1, cada uno con un plan de $20.
  Codex lo resolvió perfectamente en 12 minutos, Antigravity omitió una página pero se corrigió rápido. Claude Code se detuvo por límite de uso excedido, y aun tras reintentar seguía teniendo errores. Estuvo por debajo de lo esperado

  • Yo hice un experimento parecido, pero en mi caso Claude fue tan preciso como un contador. Es interesante que incluso en la misma tarea el resultado cambie según la sesión. La atención al cliente en la era del software no determinista es realmente una experiencia extraña

• Desde el aviso de actualización publicado en Reddit, Claude cambió hasta el punto de que ya no se puede usar para programación cotidiana. Los créditos de la cuenta Pro se agotaban en una hora, así que volví a Gemini o ChatGPT

• Al final, parece que la estructura de cobro por tokens de Anthropic está diseñada de forma desfavorable para los usuarios comunes. Cuando realmente lo usas, se nota enseguida cuánto dinero querían sacar