El contexto técnico
No me llamó la atención un gran anuncio, sino el problema real y concreto de un desarrollador: una persona con una cuota de 5 horas recién renovada de Claude Code Max 5x ejecutó un simple comando para hacer commit de sus cambios de la tarde y perdió inmediatamente cerca del 6% de su límite. Y no se trata de un escenario exótico, sino de una tarea rutinaria que llena cualquier día de trabajo.
Investigué un poco los hechos. Anthropic todavía no ha publicado límites numéricos claros y precisos para Claude Code Max 5x. En la comunicación pública se menciona una lógica de «aproximadamente 5 veces más que el plan Pro», y según informes de testers, ronda los 225 mensajes por ventana de 5 horas, pero más como una guía que como una garantía estricta.
Y aquí es donde empieza lo más desagradable. Cuando el límite no se calcula como «tienes X solicitudes por minuto», sino a través de una ventana flotante de 5 horas, y además con una lógica interna propia para tokens y acciones de agente, la previsibilidad se desvanece. Para un chat, es tolerable. Para el desarrollo en producción, ya no.
Con las operaciones de git, la situación es especialmente estresante. Un commit, una revisión, edición de archivos, análisis del contexto del repositorio, el intento de formular un mensaje de commit y, a veces, reintentos ocultos o recálculos de contexto... de repente, un comando se convierte en una costosa sesión de agente. Según los comentarios de los usuarios, estas tareas pueden consumir no un 1-2%, sino mucho más, especialmente en horas pico.
En marzo, Anthropic ya reconoció que algunos usuarios estaban alcanzando los límites más rápido de lo esperado. Hubo flexibilizaciones temporales de las cuotas, que luego terminaron. Paralelamente, surgieron quejas sobre errores en la caché de prompts, picos extraños de consumo y la sensación de que la herramienta parece tener vida propia en lugar de seguir reglas claras.
¿Qué rompe esto en la automatización real?
En historias como esta, no me interesa la queja en sí, sino lo que revela sobre la arquitectura. Si un solo commit puede consumir el 6% de la ventana, significa que Claude Code, por ahora, no es adecuado como una capa fiable para ciclos de desarrollo largos: crear una rama, hacer un montón de cambios, commits, refactorización, pruebas y comandos de seguimiento. La cadena de acciones se topa con el rate limiting demasiado rápido.
Para un desarrollador individual, es una molestia. Para un equipo, ya es un riesgo en el proceso. No se puede planificar adecuadamente la automatización con IA si el coste de las operaciones típicas fluctúa enormemente dependiendo de la hora, la longitud del contexto o las heurísticas internas del modelo.
Aquí, por ahora, ganan aquellos con escenarios cortos y puntuales: hacer una pregunta sobre un archivo, generar rápidamente una función, explicar un error localmente. Pierden los usuarios avanzados, los pipelines de agentes y los equipos que quieren hacer de la automatización con IA una parte de su desarrollo diario, y no un juguete para «ayudar un par de veces al día».
Precisamente por eso, cada vez más veo estas herramientas no como un «reemplazo del IDE», sino como un recurso computacional inestable. Si un recurso es inestable, no puede colocarse en el centro de una arquitectura de IA. Necesita una capa de soporte: modelos de fallback, políticas de límites, throttling, división de tareas y, a veces, incluso cambiar a una API con una economía más transparente.
En Nahornyi AI Lab nos encontramos con esto regularmente en proyectos donde se implementa inteligencia artificial en el desarrollo y en los procesos de ingeniería internos. Sobre el papel, todo es perfecto: el agente hace commits, corrige errores, escribe pruebas. En la práctica, sin control del contexto, los presupuestos y los puntos de fallo, el sistema empieza a quemar dinero o simplemente paraliza al equipo a mitad del día.
De ahí el interés en alternativas como Codex o los modelos API de OpenAI con límites más comprensibles. No porque «un modelo sea más inteligente que otro», sino porque la previsibilidad suele ser más importante que el puro «efecto wow». Las empresas no necesitan el agente más artístico, sino uno que se pueda integrar en el proceso sin tener que adivinar si sobrevivirá a tres comandos más antes del almuerzo.
Este análisis lo he hecho yo, Vadim Nahornyi de Nahornyi AI Lab. Construyo soluciones de IA para empresas, diseño la arquitectura de soluciones de IA y analizo noticias como esta desde la perspectiva de la explotación, no del marketing. Si quieres discutir tu caso, donde necesitas una integración de IA sin sorpresas de límites y presupuesto, escríbeme y juntos diseñaremos un plan funcional.