Skip to main content
AnthropicClaude CodeAI automation

Claude Code y el esquema proxy: dónde se rompe realmente

El debate sobre Claude Code revive un viejo sueño: usar una suscripción fija para la automatización con IA en lugar de la API por token. En la práctica, este método fallaría por las verificaciones del servidor, TLS, sistemas antiabuso conductual y las rápidas actualizaciones de Anthropic, haciéndolo poco fiable y arriesgado.

Contexto técnico

Analicé esta idea como ingeniero, no como un teórico de foros. La lógica es clara: contratar Claude Code por una suscripción de $20, $100 o $200, esnifar el tráfico, redirigirlo a través de un lm-proxy o un gateway propio y enviar las tareas a modelos especializados más baratos. Para la integración de IA, suena tentador, especialmente si una API por token consume decenas o cientos de dólares en una tarea voluminosa.

Pero aquí es donde todo se desmorona, y no solo a nivel de "bueno, una solicitud es solo un JSON". Claude Code se basa en solicitudes autorizadas a la infraestructura de Anthropic, donde no solo importa el payload, sino también los tokens, el esquema de respuesta, los tiempos, los límites y, a veces, la lógica del servidor para registrar el uso. Si se interpone un proxy entre el cliente y el backend, no basta con leer el tráfico, hay que reproducir de forma creíble todo el contrato.

Y en este punto, no contaría con una victoria fácil. HTTPS, posible certificate pinning, tokens de corta duración, verificación de endpoints, anomalías de comportamiento en la latencia y la forma de las respuestas, además de actualizaciones rápidas del cliente. Es un esquema frágil que se puede mantener justo hasta la próxima versión.

Un punto aparte que muchos confunden: el agente aquí no es magia ni "código aterrador en la máquina". Normalmente, es solo la orquestación de un modelo, herramientas, contexto y pasos de ejecución. Pero si un proveedor vende una suscripción para su propia UX y sus propios límites, y tú intentas convertirla en un transporte universal y barato para agentes de terceros, eso ya parece un caso de antiabuso, no una arquitectura de IA normal.

¿Qué significa esto para el negocio y la automatización?

En resumen: yo no apostaría por esto para producción. El riesgo de que el esquema funcione hoy y mañana te encuentres con una cuenta bloqueada, un pipeline roto y una migración de emergencia en medio de un sprint es demasiado alto.

Aquí solo ganan los experimentadores a los que no les importa perder una cuenta y pasar tiempo reparando constantemente sus apaños. Pierden los equipos que necesitan una implementación de IA predecible con un coste claro, SLAs y control de datos.

En estos casos, suelo simplificar la tarea: donde se necesita Claude, uso Claude; donde se puede desviar el tráfico a modelos más baratos, lo hago de forma honesta a través de un enrutador adecuado y mi propia lógica de selección de modelos. Estas son exactamente las soluciones que creamos para los clientes en Nahornyi AI Lab: sin esquemas grises, solo automatización de IA funcional que no se desmorona con una sola actualización. Si tus costos de inferencia se están acumulando o tu pila de agentes se ha vuelto demasiado cara, revisemos la arquitectura y encontremos dónde se puede ahorrar de verdad sin entrar en guerra con el proveedor.

Una parte relacionada de esta discusión es cómo aprovechar de manera ética y eficiente las capacidades de Claude mientras se gestionan los riesgos y costos operativos. Anteriormente cubrimos cómo los agentes paralelos de Claude Code pueden usarse para reducir los riesgos de CI/CD y optimizar gastos al detectar condiciones de carrera en PRs usando el modelo Sonnet.

Compartir este articulo