Con solo 3 “hello” se alcanza el límite: ¿a dónde fue la cuota de tu Claude Code? Un bug de caché que se extendió durante 28 días y una respuesta oficial para que “uses con más cuidado”.

Título original: 3 saludos y te limitan el cupo; ¿a dónde fue tu saldo de Claude Code? Un bug de caché que se extendió durante 28 días, y una respuesta oficial que te pide “ahorrar para usar”

Autor original:律动BlockBeats

Fuente original:

Repost:火星财经

4-17%. Esta es la tasa de lectura del prompt cache de Claude Code en el último mes. El nivel normal es 97-99%.

Esto significa que, cuando recuperas una sesión anterior, Claude Code no reutiliza el contexto que ya había procesado, sino que vuelve a procesar todo desde cero cada vez, consumiendo un cupo de 10 a 20 veces en comparación con una situación normal. Crees que estás continuando una conversación, pero en realidad cada vez estás reiniciando una conversación nueva, completa y de tarifa completa.

Este dato proviene de pruebas en condiciones reales realizadas por el desarrollador independiente ArkNill mediante monitoreo de su agente. Configuró un proxy transparente, registró cada solicitud entre Claude Code y la API de Anthropic, y descubrió que al menos dos bugs de caché del lado del cliente impiden que el servidor de la API coincida con los prefijos de la conversación que ya estaban en caché, obligándolo a reconstruir tokens completos en cada ronda.

La imagen superior muestra una comparación de las tasas de lectura de caché en tres etapas. Entre v2.1.69 y v2.1.89 (es decir, el periodo en que existía el bug), en la versión standalone la tasa de lectura de caché era solo de 4-17%. Después de que v2.1.90 corrigiera uno de los bugs clave, la tasa de lectura de caché en el arranque en frío volvió a 47-99.7%. Y en v2.1.91, bajo funcionamiento estable, la tasa de lectura de caché se recuperó a 97-99%.

Vale la pena señalar un detalle en el gráfico: el rango de v2.1.90 es muy amplio (de 47% a 99.7%), porque cuando la sesión se recupera aún hace falta “calentar” la caché; las primeras rondas tienen una tasa de aciertos baja, pero en poco tiempo vuelve al nivel normal. Mientras que en la versión con bug, este calentamiento nunca ocurre: la tasa de lectura de caché se queda para siempre en los 14,500 tokens del prompt del sistema; todo el historial de la conversación se factura cada vez a tarifa completa.

28 días, 20 versiones

Este bug no fue de esos que se introducen en una actualización y se corrigen en la siguiente. Según el historial de publicaciones en el npm registry, la versión v2.1.69 que introdujo el bug se publicó el 4 de marzo; la v2.1.90 que corrigió el bug se publicó el 1 de abril. Pasaron 28 días en medio, cubriendo 20 versiones.

La línea de tiempo revela un detalle que vale la pena analizar. Después de que el bug se introdujera el 4 de marzo, los usuarios no se quejaron de inmediato a gran escala. Hasta el 23 de marzo, las quejas estallaron de manera concentrada; entre medio pasaron casi tres semanas. La razón es que, según el resumen del GitHub issue #41930, del 13 al 28 de marzo Anthropic lanzó una promoción de duplicación de cupos de 2x (duplicación en horarios off-peak), lo cual en la práctica ocultó el impacto del bug. Cuando terminó la promoción, el consumo del bug de caché volvió a la base de facturación normal, y los cupos de los usuarios “se evaporaron” de golpe.

La respuesta de Anthropic no llegó con rapidez. El 26 de marzo, es decir, tres días después de que estallaran las quejas, el ingeniero Thariq Shihipar anunció en su cuenta personal de X que el límite en horas punta (de lunes a viernes 5am-11am PT) se había ajustado a la baja. El 30 de marzo, Anthropic admitió en Reddit que “la velocidad con la que los usuarios alcanzaban el límite superó con creces lo esperado”, y dijo que se había incluido como la máxima prioridad del equipo. Hasta el 1 de abril, el miembro del equipo Lydia Hallie recién publicó las conclusiones formales de la investigación.

Durante todo el proceso, Anthropic no publicó ningún artículo de blog, no envió notificaciones por correo y no actualizó la página de estado. Todas las comunicaciones oficiales se realizaron únicamente mediante publicaciones en redes sociales personales del equipo de ingeniería y algunos comentarios en Reddit.

¿Pagaste cuánto y durante cuánto tiempo lo pudiste usar?

El GitHub issue #41930 reúne cientos de reportes de usuarios. El caso más extremo fue el de un usuario Max 20x (suscripción $200/mes): su ventana móvil de 5 horas se agotó por completo en 19 minutos. Los usuarios Max 5x ($100/mes) reportaron que la ventana de 5 horas se acabó en 90 minutos. Según lo reportado por The Letter Two, también hubo usuarios que afirmaron que una simple “hello” consumía el 13% del cupo de la sesión. Un usuario Pro ($20/mes) dijo en Discord que su cupo “se acaba el lunes y el sábado es cuando se reinicia”; en 30 días, solo 12 días pudo usarse con normalidad.

Según los benchmarks de ArkNill, en la versión con bug v2.1.89, el 100% del cupo del plan Max 20x se agotaba en aproximadamente 70 minutos. También calculó el costo del cupo para una sesión de contexto de 500K tokens con una sola operación --resume, que es de aproximadamente $0.15, porque el sistema vuelve a reproducir completamente todo el contexto.

“Lo estás usando de la manera incorrecta”

Las conclusiones de la investigación de Lydia Hallie confirmaron dos puntos: uno, que el límite en horas punta efectivamente se había ajustado a la baja; y dos, que el consumo de las sesiones con contexto de 1 millón de tokens aumentó. Dijo que el equipo corrigió algunos bugs, pero enfatizó que “ninguno de los bugs causó cargos de más”.

Luego dio cuatro recomendaciones para ahorrar: 1. Usar Sonnet 4.6 en lugar de Opus (Opus consume a una velocidad de aproximadamente el doble);

2. Cuando no se necesita razonamiento profundo, bajar la fuerza de razonamiento o apagar extended thinking;

3. No reanudar sesiones largas inactivas durante más de una hora; abrir una nueva;

4. Establecer la variable de entorno CLAUDE_CODE_AUTO_COMPACT_WINDOW=200000 para limitar el tamaño de la ventana de contexto.

No se mencionó ningún tipo de reinicio de límites ni compensación.

El presentador del podcast de IA Alex Volkov resumió esta respuesta como “Lo estás usando de la manera incorrecta” (You’re holding it wrong), señalando que Anthropic, por su propia cuenta, configuró el contexto de 1 millón de tokens como predeterminado, promocionó Opus como su modelo insignia y vendió extended thinking como un punto fuerte, pero ahora recomienda que los usuarios que pagan no usen esas funciones.

El argumento de “no cobró de más” también entra en tensión con el propio historial de actualizaciones de Claude Code. El día anterior a que Lydia publicara la respuesta, v2.1.90 corrigió un bug de regresión de caché confirmado desde v2.1.69: al restaurar una sesión con --resume, las solicitudes que deberían haber hecho match con el caché del prompt desencadenaban una falta completa del prompt cache, cobrándose a tarifa completa. La respuesta de Lydia no mencionó esa anomalía de facturación que ya estaba confirmada.

Como contraste, OpenAI también había presentado problemas similares de consumo anómalo de cupos con Codex. El enfoque de OpenAI fue reiniciar los cupos de los usuarios, emitir créditos y anunciar en marzo la eliminación del límite de uso de Codex. El enfoque de Anthropic fue recomendar que los usuarios degradaran el modelo, desactivaran funciones, limitaran el contexto y atribuir la responsabilidad a la forma en que los usuarios lo usan.

Anthropic vende una suscripción con “el modelo más fuerte + el contexto máximo + la mayor capacidad de razonamiento”, cobrando entre 20 y 200 dólares al mes. Un bug de caché que se extendió durante 28 días hace que el cupo de los usuarios que pagan se evapore a una velocidad de 10 a 20 veces, y la respuesta oficial es que te comportes y “uses con cuidado”.