La mañana del 19 de febrero empezó con normalidad para la mayoría de los desarrolladores que construían sobre Claude. Para la hora del almuerzo, ya no.
Anthropic actualizó sus términos de servicio para prohibir explícitamente el uso de tokens OAuth basados en suscripción en aplicaciones de terceros. Los suscriptores de Claude Pro y Max que habían estado enrutando sus credenciales de suscripción a través de herramientas como OpenCode, Cline y decenas de proyectos más pequeños se despertaron con un único mensaje de error: acceso denegado. Sin período de gracia. Sin ruta de migración. Solo un cambio de política y un flujo de trabajo roto.
La comunidad de desarrolladores reaccionó de forma predecible. Los issues de GitHub se desbordaron. Los servidores de Discord se encendieron. Publicaciones en Substack con títulos como "El fin del hack de suscripción de Claude" empezaron a circular en cuestión de horas. Para los proyectos que habían construido todo su modelo de autenticación aprovechándose de las suscripciones de Claude, esto no era un inconveniente menor — era una amenaza existencial.
Los usuarios de NanoClaw, mientras tanto, no notaron que nada hubiera cambiado. No porque tuvieran suerte, sino porque NanoClaw nunca fue diseñado para usar OAuth.
Qué pasó realmente
Para entender por qué esto importaba, hay que entender el hack que Anthropic eliminó. Las suscripciones de Claude Pro y Max incluyen acceso a Claude Code, la herramienta CLI oficial de Anthropic. Claude Code se autentica vía OAuth — inicias sesión una vez, obtienes un token, y la CLI usa ese token para las llamadas a la API. El token está vinculado a tu suscripción, no a una clave API con medición.
Los desarrolladores se dieron cuenta rápidamente de que este token OAuth podía extraerse y usarse en otras herramientas. En lugar de pagar por token a través de la API de Anthropic, podías pagar una tarifa plana de $20/mes por Claude Pro y enrutar solicitudes ilimitadas a través del token de suscripción. Proyectos como OpenCode construyeron toda su propuesta de valor en torno a esto: "Usa Claude sin costes de API."
La economía era convincente. Un usuario intensivo de la API de Claude podía gastar $200-500/mes en tokens. El mismo uso a través del hack de suscripción costaba $20. Para equipos ejecutando enjambres de agentes o automatización continua, el ahorro era enorme.
Anthropic toleró esto durante meses. Luego, el 9 de enero de 2026, desplegaron protecciones del lado del servidor que bloquearon el funcionamiento de los tokens de suscripción fuera de los clientes oficiales. El 19 de febrero, lo convirtieron en política oficial. The Register lo reportó como Anthropic "reforzando su modelo de ingresos." La comunidad de desarrolladores lo llamó una traición. Ambas descripciones eran precisas.
Por qué NanoClaw nunca estuvo en riesgo
El modelo de autenticación de NanoClaw es deliberadamente simple: configuras ANTHROPIC_API_KEY en tu archivo .env, y esa clave se pasa a los contenedores de agentes en tiempo de ejecución vía stdin. Eso es todo. Sin flujo OAuth, sin extracción de tokens, sin aprovecharse de suscripciones.
Esto no fue un descuido ni una limitación — fue una decisión de diseño consciente basada en una filosofía específica: no construyas sobre el arbitraje de precios de otro.
El hack de OAuth siempre fue una violación de política esperando ser aplicada. Los términos de servicio de Anthropic nunca permitieron explícitamente usar tokens de suscripción en herramientas de terceros. El hecho de que funcionara era una brecha en la aplicación, no una funcionalidad. Construir un producto sobre esa brecha significaba construir sobre arena.
Hay una razón arquitectónica más profunda también. Los tokens OAuth son basados en sesión y revocables. Expiran, pueden ser invalidados del lado del servidor y requieren flujos de renovación periódicos. Una clave API, en cambio, es un simple token portador que funciona hasta que lo rotas. Para un agente siempre activo que se ejecuta en contenedores aislados, el modelo de autenticación más simple es también el más fiable.
Cuando NanoClaw lanza un contenedor de agente, lee la clave API del .env en tiempo de ejecución y la pasa al proceso del contenedor vía stdin en formato JSON. La clave nunca toca process.env dentro del contenedor, nunca se escribe en disco y nunca aparece en los logs. Esto no es solo más simple que OAuth — es más seguro. Un contenedor comprometido no puede extraer un token de sesión y usarlo para suplantar al usuario en otro lugar, porque no existe ningún token de sesión.
Las consecuencias para los proyectos dependientes de OAuth
Los proyectos que construyeron sobre el hack de OAuth están ahora en distintas fases de crisis. Algunos han migrado a autenticación por clave API — adoptando esencialmente el modelo que NanoClaw ha usado desde el primer día, pero con el dolor añadido de migrar usuarios existentes. Otros están explorando soluciones alternativas que probablemente serán bloqueadas en la próxima ronda de aplicación.
OpenCode lanzó un modo "Antigravity" que intenta usar rutas de autenticación alternativas. La respuesta de la comunidad ha sido mixta — algunos lo ven como ingeniería ingeniosa, otros lo ven como doblar la apuesta en una estrategia que ya falló una vez.
Las consecuencias más interesantes son filosóficas. El hack de OAuth creó una expectativa entre los desarrolladores de que el acceso a Claude debería ser de tarifa plana e ilimitado. Ahora que el hack está muerto, los desarrolladores se enfrentan a la economía real de ejecutar agentes de IA: los costes por token son reales, escalan con el uso, y no hay atajos.
Esto es realmente saludable para el ecosistema. Cuando el coste de las llamadas a la API está oculto detrás de un hack de suscripción, los desarrolladores no optimizan la eficiencia. Ejecutan prompts verbosos, se saltan el caché y dejan que los agentes iteren sin conciencia de costes. Cuando cada token tiene un precio, empiezas a pensar en ingeniería de prompts, gestión de la ventana de contexto y si ese agente realmente necesita ejecutarse cada 60 segundos.
Qué significa esto de cara al futuro
El cambio de política de Anthropic es parte de una tendencia más amplia. Los proveedores de IA están endureciendo los controles de acceso mientras definen modelos de negocio sostenibles. OpenAI lleva meses restringiendo el acceso a su API. La API de Gemini de Google tiene límites de uso que se vuelven más estrictos con cada actualización. La era del acceso ilimitado a la IA mediante hacks creativos de autenticación está llegando a su fin.
Para los desarrolladores que construyen agentes de IA, la lección es directa: autentícate a través de canales oficiales y documentados. Usa claves API. Paga por lo que usas. Construye tu modelo de costes sobre los precios reales de la API, no sobre oportunidades de arbitraje que pueden desaparecer de la noche a la mañana.
El enfoque de NanoClaw — una única ANTHROPIC_API_KEY en .env, pasada de forma segura a los contenedores en tiempo de ejecución — no es emocionante. No es un hack, no es ingenioso, y no te ahorra dinero mediante enrutamiento creativo de tokens. Pero funcionó ayer, funciona hoy y funcionará mañana, porque está construido sobre el modelo de autenticación que Anthropic realmente soporta y documenta.
A veces la decisión arquitectónica aburrida es la que mejor envejece. El 19 de febrero, lo aburrido ganó.