Cambia de proveedor LLM en 3 minutos
Guía de migración con red de seguridad

La mayoría de equipos que quieren cambiar de proveedor LLM nunca lo hacen. No porque el switch sea difícil, sino porque cambiar con seguridad, sin romper la prod, sin perder semanas reescribiendo, sin atarte a un vendor que aún no has validado, parece difícil.

No hace falta. Aquí tienes el camino de migración mínimo viable de OpenAI a Claude (o entre dos proveedores compatibles con OpenAI), con una red de seguridad que te deja hacer rollback en segundos.

El cambio de dos líneas

Si tu código usa el SDK de OpenAI hoy, y la mayoría del código Python y JavaScript lo hace, el switch mínimo posible es:

# Antes
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

# Después
client = OpenAI(
    api_key=os.environ["HIWAY_API_KEY"],
    base_url="https://app.hiway2llm.com/v1",
)

Dos líneas. Tus llamadas client.chat.completions.create(...) no cambian. Tu código de streaming no cambia. Tu código de tool use no cambia.

El proxy habla la API de OpenAI del lado de entrada y traduce hacia el proveedor que has configurado del lado de salida. Anthropic, Google, Mistral, xAI. Eliges el proveedor en un dashboard, no en el código.

Funciona porque la industria ha convergido en "OpenAI-compatible" como lingua franca. La mayoría de proxies, gateways y routers modernos implementan la API chat completions de OpenAI, incluso cuando llaman a Claude o Gemini detrás.

La red de seguridad

Aquí va la parte que la mayoría de guías de migración se saltan: no estás obligado a comprometerte con un proveedor inmediatamente. El buen camino de migración es:

Fase 1, hacer correr los dos en shadow. Tu tráfico primario sigue golpeando OpenAI. Un porcentaje pequeño (digamos un 5 %) se duplica hacia Claude vía el proxy. Logueas la latency, el coste y la salida de cada uno. Al cabo de una semana, tienes datos reales sobre calidad, latency y delta de coste para tu workload concreto.

Fase 2, promote. Una vez que los datos shadow están limpios, cambias el tráfico primario. El proxy sigue ahí. Mantienes OpenAI como fallback, si Claude falla o si la latency hace spike, el proxy bascula automáticamente.

Fase 3, retira el fallback. Meses después, cuando tienes confianza, dropeas el fallback. O no. Mantener la redundancia de proveedor no cuesta nada y te salva el día que un proveedor tenga un outage.

La mayoría de equipos intentan hacer las tres fases de golpe, en un fin de semana, y acaban haciendo rollback cuando llega el primer incidente.

Implementación

Paso 1: Saca una API key en tu proveedor objetivo

Crea una cuenta en Anthropic, OpenAI, Google, el que quieras. Saca una API key. Mete fondos en la cuenta. Lleva 3 minutos con una tarjeta.

Crítico: la key vive en tu cuenta, no en la cuenta revendedora de un middleware. Eso es lo que significa BYOK. Si el middleware cae, tu key sigue funcionando en directo.

Paso 2: Cablea el proxy

Te lo puedes saltar si quieres ir directo al proveedor. Pero si quieres el routing, los controles de presupuesto y la red de seguridad, apuntas a un proxy:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["HIWAY_API_KEY"],
    base_url="https://app.hiway2llm.com/v1",
)

response = client.chat.completions.create(
    model="claude-sonnet-4-6",  # o "auto" para smart routing
    messages=[
        {"role": "user", "content": "¿Cuánto es 2+2?"},
    ],
)

El parámetro model ahora acepta cualquier nombre de modelo de proveedor. Ponlo a "auto" y el router elige por request.

Paso 3: Activa el shadow mode

En el dashboard del proxy, configura el shadow routing: el 5 % de las requests va hacia Claude en paralelo a OpenAI. La respuesta primaria se devuelve al usuario; la respuesta shadow se loguea.

Al cabo de 1 000 requests shadow, tienes un dataset decente. Compara:

• Coste por request (Anthropic suele ser más barato en el tier Sonnet)
• Latency (el TTFT de Anthropic suele ser mejor; el throughput de OpenAI suele ser más alto)
• Calidad de salida (mira 20-30 pares a ojo tú mismo; no confíes en un juez LLM aquí)

Paso 4: Flipa el primario

Una vez contento con los resultados shadow, flipa el routing: Claude es ahora primario, OpenAI es el fallback. Es un cambio de dashboard, no un deploy.

Vigila tu tasa de error 24-48 h. Si es estable, has terminado.

Paso 5: Decide qué hacer con el fallback

Mantener OpenAI como fallback no cuesta nada mientras no haya incidente. Cuando Anthropic tuvo su outage de enero, nuestro tráfico basculó hacia OpenAI durante 90 minutos sin impacto visible para el usuario. Solo ese día pagó el haber mantenido el fallback cableado durante el año.

Si vas con un presupuesto ajustado y confías en tu primario, puedes dropear el fallback. Pero para servicios en prod, yo lo mantendría.

Las cosas que diferirán

Algunos comportamientos que no son perfectamente idénticos entre proveedores, incluso a través de un proxy compatible con OpenAI:

System prompts. Anthropic trata el system prompt aparte. OpenAI lo mergea con los mensajes user. La mayoría de proxies normalizan eso, pero si tienes system prompts muy largos, testea con cuidado.

Strictness JSON del tool use. Claude es más estricto con los tool schemas mal formados. Si tus tool definitions tienen typing flojo, OpenAI lo va a tolerar; Claude va a fallar. Arregla los tool schemas, no le eches la culpa al proxy.

Deltas de streaming. La shape de los chunks de streaming es ligeramente distinta. Si tu frontend parsea los deltas crudos en vez del campo content normalizado, puedes ver artefactos. Usa la capa de abstracción del SDK.

Rate limits. La estructura de tiers de Anthropic es distinta a la de OpenAI. Puede que tengas que pedir aumentos de tier por separado en cada uno.

Ninguno de estos puntos es bloqueante. Es la fricción habitual de cambiar cualquier componente de infra.

Lo que no necesitas cambiar

• Tus prompts. Muévelos tal cual primero, tunealos después si hace falta.
• Tu lógica de retry. Los retries del SDK de OpenAI funcionan sin cambios a través del proxy.
• Tu código de streaming. Los chunks tienen la misma pinta para tu código.
• Tu código de tool use. Mismo schema, mismo handling de respuesta.
• Tu caching. Si cacheabas en cliente, sigue.

El switch es principalmente un cambio de configuración. El código se queda.

Por qué moverse

Las razones habituales: coste más bajo, mejor fit, redundancia de proveedor. La razón infravalorada: la opcionalidad. Una vez que puedes cambiar de proveedor con un cambio de config, negocias distinto. Nunca estás lock-in. Cuando Anthropic saca un modelo mejor, lo pruebas inmediatamente. Cuando OpenAI baja precios, evalúas. Cuando Mistral abre un modelo nuevo, lo shadow-testeas en una tarde.

Esa opcionalidad vale más que los ahorros de coste para la mayoría de equipos en prod.

Para leer también: BYOK, descodificado, por qué traer tus propias keys es la base de todo este enfoque.