Tu Herramienta de IA para Programar No Es Electricidad. Deja de Tratarla Como un Servicio Público.
Anthropic acaba de anunciar un ajuste en los límites de sesión de Claude Code durante las horas pico. No los límites semanales (esos siguen igual), solo la velocidad con la que quemas sesiones entre las 5am y 11am PT. Afecta al 7% de usuarios. El post de cancelación con más likes: "se acabó la confianza, nos timaron." Justo al lado, un tutorial para ejecutar Claude Code localmente. El mismo anuncio, dos reacciones opuestas. Unos cancelan. Otros construyen.
La indignación no demuestra que Anthropic la cagó con su comunicación (eso lo ve cualquiera). Demuestra que la mayoría de devs que usan Claude Code tienen cero resistencia en su flujo de trabajo. Un ajuste que afecta al 7% de usuarios durante horas pico, y es pánico total. Sin plan B. Sin multi-modelo. Sin programación. Trataron una herramienta que aún está escalando como si fuera un servicio estable. Exactamente el mismo error que cometió la industria cloud en 2011.
TLDR: El rate limiting no es un bug. Es una prueba de resistencia que la mayoría de flujos de trabajo suspenden. Multi-proveedor, programación fuera de pico, fallback por complejidad de tarea. Los devs que ya tenían eso ni se enteraron de la crisis. Construye el tuyo antes de la próxima.
La Ilusión de los $200: Por Qué Tu Cerebro Recategoriza una Herramienta como Infraestructura
A $20/mes, sabes que es una herramienta. La tratas como tal. Si se rompe, te encoges de hombros, cambias, sigues adelante.
A $200/mes, algo cambia. Tu cerebro silenciosamente la recategoriza como infraestructura. Misma categoría que tu proveedor de hosting. Misma categoría que la electricidad. Dejas de pensar qué pasa si se cae porque la infraestructura no se cae (excepto cuando sí se cae).
Claude Code en 2026 no es un servicio público. Económicamente es un servicio cloud en fase temprana con límites no publicados y un equipo que aún está descubriendo la planificación de capacidad en tiempo real. El hecho de que pagues un premium no cambia eso. Cambia tu percepción.
Ese cambio tiene precedente. Abril 2011, AWS se cae duro. Reddit, Foursquare, Quora, offline por horas. La reacción fue idéntica a lo que pasó ayer. Rabia. Anuncios masivos de migración hacia Rackspace. Desarrolladores jurando que nunca más dependerían de un solo proveedor (spoiler: la mayoría se quedó en AWS, y la mayoría se quemó otra vez un año después).
Entonces Netflix publicó Chaos Monkey en 2012. En lugar de abandonar AWS, construyeron una herramienta que mata servicios aleatoriamente en producción para forzar resistencia en la arquitectura. La revelación no fue "AWS no es confiable." La revelación fue "la confiabilidad es nuestro trabajo, no el suyo."
La industria cloud tardó unos tres años en internalizar eso. Y la razón por la que la mayoría de devs no entienden por qué sus sesiones de Claude Code explotan en primer lugar es la misma razón por la que no entienden esto: nunca han tenido que pensar en qué pasa del lado del proveedor.
$200/mes no convierte una herramienta en infraestructura. Convierte tu percepción.
Lo Que Los Posts Rabiosos Realmente Revelan Sobre Tu Flujo de Trabajo
Las respuestas furiosas no son una encuesta de sentimientos. Son una auditoría involuntaria de cómo la comunidad dev realmente trabaja con herramientas de coding AI. Y los resultados no son buenos.
La mayoría de los devs en pánico ejecutan todo a través de Anthropic. Sin modelo secundario, sin fallback local, nada. Cuando llega el throttling, el trabajo se detiene. No "se ralentiza." Se detiene. Como desenchufar la única máquina del taller.
Luego está el problema de selección de modelo. Opus para todo. ¿Code review? Opus. ¿Script bash rápido? Opus. ¿Generar un archivo de migración que cualquier modelo 7B podría manejar? Opus. Es como aparcar en paralelo un camión articulado cuando una bicicleta serviría. Y luego sorprenderse cuando se acaban los espacios de aparcamiento.
Y casi nadie piensa en el timing. Refactors grandes y trabajos en background durante horario comercial de EEUU, cuando el throttling está al máximo. No porque el trabajo necesite hacerse entonces. Porque nunca se les ocurrió que la programación importa para una API con restricciones de capacidad.
Todos entendemos que no despliegas a producción un viernes por la tarde antes de irte de buceo (ok, quizás hice eso una vez). Pero de alguna manera ejecutar tus cargas de trabajo AI más pesadas durante horas pico no se registra como la misma categoría de mala idea.
Del otro lado, los devs que apenas notaron el cambio comparten una cosa. Ya estaban tratando Claude Code como una herramienta que podía fallar. Algunos construyeron dashboards de monitoreo con fallbacks multi-modelo. Otros movieron cargas pesadas a horas fuera de pico hace meses. Algunos ejecutan modelos locales como red de seguridad para cuando la API se congestiona.
La crisis no creó su resistencia. La resistencia hizo la crisis invisible.
Esa es la misma lógica detrás de construir contratos de prompt en tu flujo de trabajo AI en lugar de esperar que cada sesión funcione. Construyes la estructura antes de necesitarla. No después.
Lo Que Realmente Hago (Y Por Qué No Cancelé)
Aclaración rápida antes de entrar en esto. Los devs resistentes no son moralmente superiores. Muchos desarrolladores solo no tienen el presupuesto o el ancho de banda para mantener un setup de fallback multi-modelo. Mi situación es específica, no universal. Pero ilustra la postura.
Mi agente de Telegram funciona con Kimi K2.5 como primario con MiniMax como fallback. Opus está reservado para las tareas que lo justifican: decisiones de arquitectura, revisión de seguridad, cualquier cosa que necesite profundidad de razonamiento seria. El resultado: el throttling de Claude nunca bloquea mi flujo de trabajo porque el 60% de mis tareas no pasan por Claude en primer lugar.
Refactors grandes y trabajos en background se ejecutan fuera de pico. No porque tenga alguna rutina de disciplina heroica. Porque es sentido común. No ejecutas tus migraciones de base de datos más pesadas al mediodía de un martes (a menos que disfrutes ese sabor específico de caos autoinfligido).
Y tengo un precedente directo para esta postura. En enero, Anthropic mató el acceso OAuth para toda mi configuración. El tipo de cosa que se siente como un puñetazo en el estómago un lunes por la mañana. Reconstruí todo por $15 en 48 horas en lugar de cancelar.
El patrón es siempre el mismo: el proveedor rompe algo, reconstruyes, sales más resistente. No menos.
¿Construí esta configuración multi-modelo porque tenía alguna visión arquitectónica grandiosa? No. La construí porque Anthropic me forzó la mano y tuve que sobrevivir. Resulta que quemarse es el mejor maestro de arquitectura.
Y para ser claro, los modelos no son intercambiables. Kimi no reemplaza a Opus en razonamiento complejo. Pero Kimi maneja el 60% de lo que solía lanzar a Opus sin pensar, y ese 60% es lo que marca la diferencia cuando llega el throttling.
El throttling no importó. No porque lo planificara. Porque ya me quemé una vez y accidentalmente terminé con la configuración correcta.
La Industria AI Aún No Ha Tenido Su Momento Chaos Monkey
Esto es lo que Chaos Monkey realmente hizo que importa. No probó si Netflix podía sobrevivir una caída de AWS. Cambió quién era responsable de la confiabilidad.
Antes de Chaos Monkey, el modelo mental era: "Le pago a AWS, AWS garantiza uptime, si AWS se cae ese es problema de AWS."
Después de Chaos Monkey, el modelo mental se convirtió en: "Mi arquitectura debe sobrevivir cualquier componente muriendo en cualquier momento, y si no puede, ese es mi problema."
Eso no es una actualización de herramientas. Esa es una inversión completa de propiedad.
La industria de herramientas de coding AI aún no ha hecho esa inversión. El modelo mental por defecto sigue siendo "Le pago a Anthropic $200/mes, Anthropic garantiza que mi flujo de trabajo funcione, si Claude hace throttling ese es problema de Anthropic." Las respuestas al post de Thariq lo prueban. La ira no es "necesito construir mejores fallbacks." La ira es "me debes servicio ininterrumpido."
Nadie te debe servicio ininterrumpido en una suscripción de consumidor sin SLA. Ni AWS en 2011 (al menos tenían SLAs, y aún así no fue suficiente). Definitivamente no una startup AI en 2026 que está escalando más rápido de lo que puede construir capacidad.
Los devs que cancelan hoy están resolviendo el problema equivocado. Están optimizando para "qué proveedor es más confiable" cuando la pregunta real es "¿sobrevive mi flujo de trabajo si cualquier proveedor falla?" Cambiar de Claude a Cursor o Codex no arregla eso. Solo mueve el punto único de falla a una dirección diferente.
En dos años, los flujos de trabajo AI de producción tendrán enrutamiento multi-proveedor, programación adaptativa, y selección de modelo basada en tarea integrados. No porque los proveedores se hayan vuelto confiables. Porque los desarrolladores habrán dejado de esperar que lo sean.
Los que esperen un proveedor perfecto seguirán escribiendo hilos furiosos en X. Los que construyan para la inestabilidad apenas notarán la próxima crisis (estarán en algún lugar cálido, debuggeando algo completamente diferente 🤷).
Los posts rabiosos no muestran que Anthropic la cagó con sus comunicaciones. Muestran que la mayoría de devs AI no tienen un plan B. Y ese no es problema de Anthropic.
Netflix no esperó a que AWS se volviera perfecto. Construyeron para la imperfección. Los devs que sobrevivirán la era del rate limiting son los que están construyendo lo mismo en su flujo de trabajo hoy.
La pregunta no es "¿vale Claude Code $200/mes?" La pregunta es "¿sobrevive tu flujo de trabajo si Claude deja de responder mañana por la mañana?" Si la respuesta es no, no tienes un problema de precios. Tienes una arquitectura con forma de punto único de falla.
PD: Me hicieron rate limiting tres veces mientras escribía este artículo. Tuve que ir a cuidar mi jardín mientras esperaba que volvieran las sesiones. /rage-garden
Fuentes y enlaces
- Hilo de anuncio de Thariq en X (26 de marzo, 2026)
- Netflix Chaos Monkey (Netflix Tech Blog, 2012)
(*) La portada es generada por AI. Los dos personajes sobrevivieron al rate limiting sin drama. Resistencia arquitectónica, probablemente.