¿Una API compatible con OpenAI está hecha por OpenAI?

No. El término describe el formato de petición y respuesta. Muchos proveedores independientes lo siguen y cada uno ejecuta sus propios modelos.

¿Puedo usar el SDK de Python o Node.js de OpenAI con ello?

Sí. Establece la URL base y la clave de API en el constructor del cliente, y usa el ID de modelo que te dé el proveedor. Para este servicio es uncensored.

¿Funcionarán todas las funciones de OpenAI en una API compatible?

No necesariamente. Los proveedores eligen qué funcionalidades implementar. Aquí obtienes completaciones de chat, streaming, llamadas a herramientas y modo JSON, pero no imágenes, audio ni embeddings.

¿Significa compatibilidad las mismas respuestas que otro modelo?

No. Las respuestas dependen del modelo y de las reglas del proveedor. Prueba con tus propios prompts en lugar de asumir un comportamiento similar.

¿Qué significa compatible con OpenAI para una API?

La respuesta corta

Cuando un proveedor dice que su API es openai-compatible, significa que acepta las mismas peticiones HTTP que envían las bibliotecas cliente de OpenAI y devuelve respuestas con la misma estructura. Mantienes tu código, cambias la URL base y la clave, y la llamada va a un servidor diferente.

Esa es toda la promesa. Es una declaración sobre la interfaz, como decir que dos cargadores usan el mismo enchufe. No te dice qué hay en el otro extremo del cable. El modelo, sus reglas de seguridad, su precio y sus límites los decide el proveedor y varían mucho.

Lo que realmente cubre la etiqueta

En la práctica, la compatibilidad con OpenAI es una lista corta de cosas concretas. Si un proveedor las soporta todas, la mayoría del código cliente se ejecuta sin cambios.

Rutas. Las peticiones de chat van a POST /v1/chat/completions y la lista de modelos proviene de GET /v1/models.
Autenticación. La clave se envía en el encabezado Authorization: Bearer.
Cuerpo de la petición. Una cadena model, un array messages de objetos con role y content, y campos de muestreo opcionales como temperature, top_p, stop y seed.
Cuerpo de la respuesta. Un array choices con el mensaje del asistente, un finish_reason y un objeto usage con conteos de tokens.
Streaming. Con stream: true el servidor envía Server-Sent Events, cada uno con un pequeño delta JSON, terminando con un marcador final.
Funcionalidades opcionales. Llamadas a funciones, modo JSON y campos similares, donde el proveedor elige soportarlos.

Como se escribieron tantas herramientas contra este formato, se convirtió en un objetivo común. Editores, frameworks de agentes, interfaces de roleplay y scripts simples permiten ingresar una URL base personalizada, y eso es todo lo que necesitan.

Por qué un formato se convirtió en el objetivo común

El formato de completación de chat se extendió porque era simple y llegó temprano. Un autor de herramientas que lo soporte una vez puede llegar a muchos backends, y un autor de backend que lo soporte una vez puede llegar a muchas herramientas. Es un buen trato para ambos lados, así que el formato se consolidó, incluso entre servicios que no tienen nada que ver con la empresa que lo diseñó.

Para ti como desarrollador esto tiene un significado práctico. Tu código no necesita una integración diferente para cada proveedor. Puedes mover un prototipo entre endpoints en una tarde, comparar dos modelos con los mismos prompts o mantener un segundo proveedor como respaldo cuando el primero es lento. El costo de cambiar de opinión es bajo y eso facilita probar un nuevo servicio sin comprometerte con él.

El lado opuesto es que la superficie compartida oculta diferencias reales. Como cambiar es tan fácil, es tentador asumir que todo detrás de la URL es equivalente. No lo es, y las secciones siguientes muestran dónde suelen aparecer las brechas.

Lo que no te dice

Aquí es donde la gente se sorprende. La etiqueta omite todo lo que determina si la API es útil para tu trabajo.

El modelo detrás de ello

Un endpoint compatible puede servir cualquier modelo. Algunos sirven modelos de pesos abiertos, otros enrutan a varios proveedores, otros envuelven un modelo propietario. La compatibilidad no significa que el servicio lo ejecute OpenAI, ni que el modelo se comporte como uno de ellos. El nombre del modelo que pasas en model es solo una cadena que define el proveedor.

Comportamiento de rechazo

Las reglas de contenido pertenecen al modelo y al proveedor, no al protocolo. Dos APIs compatibles pueden responder al mismo prompt de formas opuestas. Si tu caso de uso es ficción, roleplay u otro contenido adulto lícito, verifica qué dice el proveedor sobre los rechazos antes de conectar nada.

Profundidad de funciones

Algunos proveedores implementan solo chat. Otros añaden herramientas, modo JSON, probabilidades log o endpoints extra. Un cliente que envíe un campo que el servidor ignora no siempre fallará con error, por lo que es posible una discrepancia silenciosa.

Límites, precios y errores

Los límites de peticiones, la ventana de contexto, el tamaño máximo del cuerpo y el precio por token son decisiones del proveedor. Los cuerpos de error también difieren en detalles aunque los códigos de estado HTTP coincidan, así que la lógica de reintento debe basarse en códigos de estado y encabezados en lugar de texto de mensaje.

Una prueba rápida de compatibilidad

Puedes verificar un proveedor en unos minutos con tres peticiones. Reemplaza la clave con la tuya. Este ejemplo usa la URL base de este sitio.

curl https://api.kimicode.top/v1/models \
  -H "Authorization: Bearer YOUR_API_KEY"

curl https://api.kimicode.top/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "uncensored",
    "messages": [{"role": "user", "content": "Reply with the word ready."}]
  }'

La primera llamada confirma la clave y lista IDs de modelo. La segunda verifica la estructura de chat. Luego prueba las partes de las que depende tu aplicación: añade "stream": true y observa los fragmentos incrementales, pasa un array tools si usas function calling, y establece response_format a {"type":"json_object"} si necesitas salida parseable.

También dispara un error a propósito, como una clave incorrecta. Quieres ver un estado HTTP limpio y un cuerpo de error JSON que tu cliente pueda manejar.

La misma llamada en Node

El SDK de JavaScript toma los mismos dos valores. Aquí tienes una llamada en streaming, que es la forma que usan la mayoría de las interfaces de chat.

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.kimicode.top/v1",
  apiKey: process.env.API_KEY,
});

const stream = await client.chat.completions.create({
  model: "uncensored",
  stream: true,
  messages: [{ role: "user", content: "Name three uses of SSE." }],
});

for await (const chunk of stream) {
  process.stdout.write(chunk.choices[0]?.delta?.content ?? "");
}

Si esto imprime texto palabra por palabra, la ruta de streaming funciona de extremo a extremo. El mismo bucle funciona contra cualquier proveedor compatible, que es el punto entero del formato.

Cómo se ve el cambio en el código

Con el SDK oficial de Python, el cambio son dos argumentos del constructor. El resto de tu programa permanece como estaba.

from openai import OpenAI

client = OpenAI(
    base_url="https://api.kimicode.top/v1",
    api_key="YOUR_API_KEY",
)

resp = client.chat.completions.create(
    model="uncensored",
    messages=[{"role": "user", "content": "Summarize SSE in one sentence."}],
)
print(resp.choices[0].message.content)

El SDK de Node es la misma idea con las opciones baseURL y apiKey. Muchas herramientas leen OPENAI_BASE_URL y OPENAI_API_KEY del entorno, así que a veces puedes cambiar sin tocar código en absoluto.

Recuerda cambiar también la cadena del modelo. Una petición que nombre un modelo que el nuevo servidor no alojará fallará, y ese es el primer error más común.

Dónde encaja la API de este sitio

Este servicio es una API alojada, solo de texto, que sigue el formato de OpenAI. Ejecuta un modelo de pesos abiertos, operado por un proveedor independiente y ajustado para responder sin rechazos de contenido para uso adulto lícito. No es la API oficial de ningún proveedor de modelos y no enruta entre proveedores. El ID del modelo es uncensored.

Admite streaming por SSE con el uso reportado al final, llamadas a funciones, modo JSON, y pasa temperatura, top_p, stop, seed y las penalizaciones. La ventana de contexto es de 100,000 tokens para el prompt y la finalización juntos. No genera imágenes ni audio, y no ofrece incrustaciones ni ajuste fino. Una regla es fija: no contenido sexual que involucre a menores de edad.

La facturación es prepago y medida: $0,15 por 1M tokens de entrada y $0,50 por 1M tokens de salida, sin suscripción. Puedes ver los números en la página de precios, y la documentación explica una primera petición. Si quieres probarlo sin pagar, las cuentas nuevas pueden reclamar un crédito de prueba de $0,50 con un clic en la página de clave de API.

Errores comunes de compatibilidad

URL base incorrecta. La URL debe terminar en /v1. Los clientes añaden /chat/completions por su cuenta, por lo que añadirlo a la base produce un error 404.
Parámetros no admitidos. Si una biblioteca envía un campo que el servidor no reconoce, comprueba si se rechaza o se descarta silenciosamente y luego elimínalo.
Streaming y concurrencia. Una petición con streaming ocupa una ranura de concurrencia hasta que finaliza. Si tu aplicación abre muchos streams, puedes alcanzar un 429 con el código concurrency aunque tu conteo por minuto sea bajo.
Reintento en 429. Trata el 429 como una señal para esperar. Cuando esté presente el encabezado Retry-After, respétalo.
Conteo de tokens. No asumas que el tokenizador de otro proveedor coincide. Lee el objeto usage en la respuesta para obtener los números por los que se te cobra.

Ninguno de estos errores es difícil de corregir una vez que sabes dónde buscar, y la mayoría se reducen a leer cuidadosamente el primer mensaje de error.