Llamar a Claude, GPT y Gemini a través de puntos finales compatibles con OpenAI

Tanto Anthropic como Google ahora ofrecen endpoints compatibles con OpenAI, por lo que dirigir el código existente del SDK de OpenAI hacia Claude o Gemini consiste únicamente en cambiar unas pocas líneas en lugar de reescribir toda la integración. La parte difícil no es la primera solicitud; sino saber qué funciones ignora silenciosamente cada capa de compatibilidad y cuál es el costo de mantener varias de ellas simultáneamente. A continuación encontrará la configuración exacta del cliente para cada proveedor, las deficiencias documentadas que son importantes para los agentes de producción y las compensaciones que implica agrupar a los tres en una única URL base y clave.

Qué promete realmente ser “compatible con OpenAI”

Una API compatible con OpenAI es cualquier punto de extremo que acepte el formato de solicitud que envía el SDK de OpenAI: un array messages, las mismas banderas de transmisión en tiempo real y el mismo esquema de llamada a herramientas. Dado que ese formato se convirtió en el estándar de facto hace años, la mayoría de los proveedores de modelos ahora exponen alguna versión de él, permitiendo así a los equipos probar un modelo diferente sin tener que reemplazar su código de cliente.

No obstante, ser compatible no implica ser idéntico. La estructura de la solicitud es similar, pero la semántica detrás de cada parámetro puede diferir, y las opciones no soportadas a menudo se aceptan e ignoran en lugar de rechazarse. Este segundo comportamiento es lo que hace que estos niveles de integración sean arriesgados: nada falla de manera evidente, por lo que la falta de una función se manifiesta como un resultado de calidad inferior en lugar de un error.

El nivel de compatibilidad de Anthropic

La documentación de compatibilidad del SDK OpenAI de Anthropic presenta esta capa como una forma de probar y comparar las capacidades de los modelos, y no como la opción recomendada para entornos de producción. También enumera limitaciones concretas:

• La bandera strict para la llamada a funciones se ignora, por lo que no se garantiza que el JSON de las llamadas a herramientas cumpla con el esquema proporcionado.
• El caché de prompts no está disponible a través de la capa de compatibilidad, aunque la API nativa de Anthropic lo soporta.
• Todos los mensajes del sistema y del desarrollador se fusionan en un único mensaje de sistema al inicio de la conversación, ya que Claude solo acepta un único prompt de sistema inicial.

Ninguno de estos problemas surgirá en un experimento rápido. Cada uno de ellos puede hacer fallar a un agente de producción que dependa de que los argumentos de la herramienta coincidan con un esquema, del caché para mantener bajo control la latencia y el costo, o de instrucciones del sistema inyectadas durante la conversación.

La capa de compatibilidad de Google

El lado de Google está más completo desde el primer uso. Según su documentación de Gemini sobre compatibilidad con OpenAI, las completaciones de chat estándar, la transmisión en tiempo real y la llamada a funciones funcionan todas. No obstante, Google deja claro que no toda opción específica de cada proveedor es transferible entre las dos APIs, y recomienda pasar a la API nativa de Gemini en cuanto se necesite una funcionalidad específica de esta.

El costo de ejecutarlos todos

Cada capa por separado constituye una solución temporal razonable para evaluar un modelo. Si se integran los tres proveedores en una sola aplicación, la carga adicional se multiplica: tres URLs base, tres claves API, tres paneles de facturación, tres conjuntos de límites de velocidad y tres listas diferentes de parámetros que se descartan silenciosamente, todo ello para mantener un código idéntico para cada proveedor.

Dirigir el SDK de OpenAI hacia Claude

Para pasar una integración con el SDK de OpenAI a Claude se necesitan tres cambios: la URL base, una clave API de Anthropic en lugar de una clave de OpenAI, y el nombre del modelo Claude. Esto lo convierte en la forma más rápida de evaluar a Claude antes de decidirse por el SDK nativo de Anthropic. Las importaciones permanecen igual:

import os
from openai import OpenAI

El cliente se construye con el endpoint de Anthropic y una clave leída del entorno, y la llamada en sí es una completación de chat estándar. Tenga en cuenta que el fragmento mostrado carece de un salto de línea entre el paréntesis cerrador del cliente y response =; divídalos en dos instrucciones al copiarlo:

client = OpenAI(
    api_key=os.environ.get("ANTHROPIC_API_KEY"),
    base_url="https://api.anthropic.com/v1/",
)response = client.chat.completions.create(
    model="claude-opus-5",
    messages=[{"role": "user", "content": "Explain how AI works"}],
)

Para una completación de chat básica, esa es toda la migración. Cualquier cosa que dependa de las limitaciones mencionadas anteriormente requiere más atención. Si su aplicación depende de esquemas estrictos de herramientas, del caché de prompts o de la salida completa del proceso de pensamiento, utilice la API nativa de Anthropic para obtener la función completa en lugar de su aproximación basada en OpenAI. Los nombres de los modelos, como el que se muestra, cambian con frecuencia, así que confirme el identificador actual en la lista de modelos del proveedor.

Dirigir el SDK de OpenAI hacia Gemini

La versión Gemini de este mismo intercambio está dirigida al endpoint de Google. Se necesita una clave API de Gemini, que se puede crear en Google AI Studio. De nuevo, solo se requiere la importación estándar de OpenAI:

from openai import OpenAI

El cliente utiliza la clave de Gemini y la URL base compatible con OpenAI de Google; el cuerpo de la solicitud no cambia. Aquí también aparece el mismo salto de línea faltante, y es mejor reemplazar el marcador de posición de la clave codificado de forma rígida por una variable de entorno, como en el ejemplo de Claude:

client = OpenAI(
    api_key="YOUR_GEMINI_API_KEY",
    base_url="https://generativelanguage.googleapis.com/v1beta/openai/",
)response = client.chat.completions.create(
    model="gemini-3.7-flash",
    messages=[{"role": "user", "content": "Explain how AI works"}],
)

Tanto la transmisión en flujo como la llamada a funciones funcionan a través de este endpoint. Los controles de razonamiento de Gemini se exponen mediante el parámetro reasoning_effort de OpenAI, pero la correspondencia no siempre es exacta y depende del modelo de Gemini que se utilice. Si desea contar con una nueva función exclusiva para Gemini tan pronto como esté disponible, el SDK nativo sigue siendo la opción más rápida.

¿Y qué pasa con GPT en sí?

La propia API de OpenAI no necesita una capa de compatibilidad, ya que define el formato que todos los demás imitan. Eso no resuelve el problema de múltiples proveedores, solo lo pospone. El código escrito según el formato de OpenAI facilita la adición posterior de las capas de Anthropic y Google, pero al final sigues teniendo claves separadas, límites de velocidad distintos y particularidades propias para cada proveedor.

Ruteo de todos los modelos a través de una única pasarela

Ninguna de las capas propias de los proveedores aborda el caso de múltiples proveedores, ya que cada una solo dirige las solicitudes a sus propios modelos. Una pasarela de LLMs llena esa brecha: un único punto de acceso compatible con OpenAI que reenvía las solicitudes a Claude, GPT o Gemini según el model que especifiques, de modo que tu código ya no necesita seguir qué particularidades pertenecen a cada proveedor.

La migración se parece exactamente a las dos anteriores. El ejemplo a continuación utiliza el endpoint de una pasarela comercial; el mismo patrón se aplica a cualquier pasarela compatible con OpenAI. La importación no ha cambiado:

from openai import OpenAI

El cliente ahora apunta a la URL base de la pasarela con una clave de pasarela, y el nombre del modelo selecciona al proveedor upstream. Como antes, agregue un salto de línea antes de response =:

client = OpenAI(
    api_key="YOUR_SAYGM_API_KEY",
    base_url="https://api.saygm.com/v1",
)response = client.chat.completions.create(
    model="claude-opus-5",
    messages=[{"role": "user", "content": "Explain how AI works"}],
)

Cambiar model por gpt-5.6-luna o gemini-3.7-flash es la única modificación necesaria para cambiar de proveedor; todo lo demás permanece igual. Considere estos nombres de modelo como ejemplos válidos en el momento de redactar este texto, y consulte el catálogo de modelos del gateway para obtener los identificadores actuales. La misma configuración funciona en las herramientas de desarrollo que ya leen ajustes compatibles con OpenAI, como Cursor, Cline, Claude Code y el Vercel AI SDK: una URL base y una clave permiten acceder a todos los modelos que ofrece el gateway, en lugar de solo a la gama de un proveedor específico. Cada herramienta tiene sus propios nombres de campo para la URL base y la clave, por lo que consulte la documentación de integración del gateway para conocer los ajustes exactos.

Qué no cambia un gateway

El enrutamiento a través de una pasarela no elimina las limitaciones relacionadas con el comportamiento de compatibilidad del proveedor subyacente. Enviar solicitudes a Claude en formato OpenAI a través de una pasarela tampoco permite el caché de prompts ni la aplicación estricta de esquemas; todas las limitaciones mencionadas anteriormente siguen siendo válidas.

Las pasarelas también forman parte de los límites de confianza, ya que cada prompt y respuesta pasa por ellas. Algunos proveedores promocionan medidas de confidencialidad, como el procesamiento de solicitudes dentro de entornos de ejecución confiables verificados por hardware, para que el operador de la pasarela no pueda leer el tráfico. Dichas garantías solo se aplican a la pasarela; el proveedor del modelo sigue recibiendo y procesando su solicitud según sus propios términos. Evalúe ambas capas por separado y verifique cualquier afirmación sobre verificaciones en la documentación técnica del proveedor, no en su material de marketing.

Preguntas comunes sobre migración

¿Sobreviven las características específicas de Claude o Gemini tras pasar por una capa compatible con OpenAI?

Solo las características que esa capa puede mapear. Ya sea que utilices el endpoint de compatibilidad del proveedor directamente o lo hagas a través de una pasarela, todo aquello que no se pueda traducir se pierde. En Claude eso incluye el caché de instrucciones, el procesamiento de PDF y toda la salida de razonamiento ampliado; en Gemini incluye los parámetros de razonamiento específicos del modelo. Si dependes de ellos, debes utilizar la API nativa para esos flujos de código.

¿Cuál es el costo de hacer el cambio?

Con una pasarela, generalmente se paga por token, de manera similar a cuando se llama directamente al proveedor, pero las tarifas varían según el modelo y el vendedor, y algunas pasarelas añaden un margen adicional. Verifica las tarifas actuales publicadas para el modelo específico antes de transferir el tráfico de producción.

¿Qué sucede cuando un proveedor tiene una interrupción?

Este es el argumento más sólido a favor de un único punto final. Una pasarela diseñada para el failover puede redirigir la solicitud a un modelo de respaldo sin necesidad de realizar cambios en el código de la aplicación, mientras que tres integraciones directas requieren cada una su propia lógica de intentos repetidos y respaldo. Tenga en cuenta que un modelo de respaldo es un modelo diferente: las instrucciones ajustadas para Claude pueden comportarse de forma distinta en Gemini, y la fiabilidad al llamar a herramientas varía. Pruebe sus instrucciones críticas con cada modelo de la cadena de respaldo antes de confiar en el failover automático.

Elegir una ruta de migración

• Evaluar un proveedor adicional: utilice el punto final compatible con OpenAI del propio proveedor. Eso es exactamente para lo que está diseñado, y la configuración consiste en un cambio de tres líneas.

Ejecutar dos o tres proveedores en producción: considere utilizar una pasarela, ya que elimina las claves duplicadas, los paneles de control y la gestión de límites de velocidad, además de centralizar el proceso de conmutación por fallas.

En función de las características específicas del proveedor: mantenga las llamadas al SDK nativo para esas rutas, independientemente de la opción que elija para todo lo demás.

Cualquiera que sea la ruta que elija, guarde la URL base, la clave y el nombre del modelo en la configuración en lugar de en el código, y agregue pruebas de integración para los comportamientos en los que depende su aplicación, como el cumplimiento del esquema de llamadas a las herramientas. De esta manera, la falta de un parámetro se detectará como una prueba fallida en lugar de convertirse en un incidente en producción.

Puntos clave

• Los puntos de extremo compatibles con OpenAI coinciden con la estructura de la solicitud, no con todos sus comportamientos; los parámetros no soportados a menudo se ignoran sin generar error alguno.
• La capa de Anthropic ignora los esquemas de herramientas strict, carece de caché para prompts y fusiona los mensajes del sistema; además, está documentada como un camino de pruebas.
• La capa de Gemini maneja bien las conversaciones, la transmisión en tiempo real y la llamada a funciones, pero las opciones específicas de cada proveedor aún requieren la API nativa.
• Un único gateway simplifica las claves, la facturación y el fallo automático entre proveedores, pero hereda todas las limitaciones de compatibilidad e introduce un nuevo actor en tu ámbito de confianza.