El estándar OpenAI-compatible API: auditoría técnica del contrato de-facto que unificó la inferencia LLM (2020–2026)

⏱️ Lectura: 19 min

Autor: Juan Carlos · Afiliación: elsolitario.org — análisis técnico independiente · Fecha de publicación: 2026-04-22 · Versión del artículo: v1.0 (primer post nativo en formato IMRyD v2.0)

📑 En este artículo

1. Resumen estructurado
2. 1. Introducción
   1. 1.1 Contexto del problema
   2. 1.2 Trabajos previos y formatos alternativos
   3. 1.3 Pregunta de investigación
   4. 1.4 Contribuciones
3. 2. Metodología
   1. 2.1 Fuentes primarias
   2. 2.2 Fuentes secundarias
   3. 2.3 Criterios de inclusión / exclusión
   4. 2.4 Herramientas de verificación
   5. 2.5 Limitaciones metodológicas declaradas
4. 3. Trabajos previos y contexto histórico
5. 4. Resultados
   1. 4.1 Especificación técnica canónica
   2. 4.2 Shape canónico de /v1/chat/completions
   3. 4.3 Streaming Server-Sent Events
   4. 4.4 Implementaciones auditadas (16)
   5. 4.5 Divergencias sistemáticas identificadas
   6. 4.6 Extensiones fuera de especificación
   7. 4.7 MVP para construir un servidor OpenAI-compatible
6. 5. Discusión
   1. 5.1 Fortalezas verificables del estándar
   2. 5.2 Debilidades y riesgos
   3. 5.3 Red flags identificados
   4. 5.4 Contextualización histórica
7. 6. Limitaciones del estudio
8. 7. Recomendaciones por perfil de usuario
9. 8. Conclusiones y trabajo futuro
10. Preguntas frecuentes
    1. ¿Cuál es el mínimo para llamar a mi servidor «OpenAI-compatible»?
    2. ¿Por qué el estándar OpenAI ganó y no el de HuggingFace o Anthropic?
    3. ¿Cuál es la diferencia entre Chat Completions y Responses API?
    4. ¿Es seguro exponer mi servidor OpenAI-compat a internet?
    5. ¿LiteLLM hace que mi app sea 100% portable?
    6. ¿Anthropic tiene endpoint OpenAI-compatible?
11. Declaraciones
12. Referencias
    1. 📚 Artículos relacionados

Resumen estructurado

Contexto. La inferencia de Large Language Models se disputó durante 2020–2023 entre formatos propietarios (OpenAI, Anthropic, Cohere) y estándares abiertos (HuggingFace Inference). A partir de 2024 emergió un contrato de-facto —no publicado por ningún organismo de estándares— centrado en los endpoints /v1/chat/completions de OpenAI, que la comunidad open-source y gran parte de los competidores comerciales adoptaron como interfaz unificada.

Metodología. Se verificó la especificación oficial mediante el repositorio openai/openai-openapi (OpenAPI 3.1, 26k líneas, 76 paths, 284 schemas) el 2026-04-22, se auditaron 16 implementaciones (8 open-source auto-hospedables, 8 cloud), y se contrastaron claims documentales con threads de issues de GitHub y bugs reportados.

Resultados. La adopción se explica por dos mecanismos técnicos: (i) la publicación del SDK oficial openai Python/Node con parámetro base_url configurable, y (ii) un MVP de únicamente 2 endpoints (/v1/chat/completions con SSE streaming + /v1/models) que hereda gratis acceso a LangChain, LlamaIndex, Continue, Aider y Cursor. Se identificaron divergencias sistemáticas en logprobs, seed, n>1, Batch API, Assistants, moderations, structured outputs y reasoning content.

Conclusiones. El estándar «OpenAI-compatible» es un contrato interoperable parcial, no una especificación formal. Es suficiente para arquitecturas de agentes, chat y embeddings; insuficiente para reproducibilidad científica estricta y features propietarias de frontera. Para equipos LATAM, habilita portabilidad real entre providers cambiando una variable de entorno.

Palabras clave: OpenAI API, LLM inference, OpenAI-compatible, de-facto standard, LiteLLM, vLLM, Ollama, chat completions, SSE streaming, API interoperability.

1. Introducción

1.1 Contexto del problema

Hasta 2023, cada proveedor de modelos de lenguaje publicaba su propia interfaz: OpenAI usaba /v1/completions [1], Anthropic publicaba /v1/messages, Cohere exponía /v1/chat con su propio esquema, y HuggingFace mantenía endpoints por pipeline (text-generation, text-to-image). El resultado: cada aplicación cliente debía implementar adaptadores por proveedor, con fricción de migración alta.

A partir de marzo de 2023, con el lanzamiento del endpoint /v1/chat/completions de OpenAI [2], comenzó un proceso de convergencia en el que implementaciones open-source (Ollama, vLLM, llama.cpp, LM Studio) y competidores comerciales (Groq, Mistral, DeepSeek, Qwen, Fireworks, Together AI, OpenRouter) adoptaron el mismo formato JSON. Este artículo audita la especificación, las implementaciones y las limitaciones de este contrato emergente.

1.2 Trabajos previos y formatos alternativos

Antes de la convergencia OpenAI, hubo tres intentos notables de estandarización fallida:

1. HuggingFace Inference API — shape propio por pipeline, no ganó tracción fuera del ecosistema HF. En 2025, HuggingFace capituló y adoptó formato OpenAI-compatible para sus 15+ Inference Providers [3].
2. Cohere /v1/chat — formato con chat_history + message estructurados; sobrevivió pero nunca logró adopción externa.
3. ONNX Runtime + OpenVINO — estándares a nivel de formato de modelo, no de API HTTP.

La OpenAI API ganó por efecto red del SDK oficial: una vez que openai.chat.completions.create() aceptó base_url arbitrario [4], cualquier servidor que devolviera el mismo JSON quedó automáticamente compatible con miles de apps downstream. El costo de migración bajó a cero.

1.3 Pregunta de investigación

¿Constituye la API de OpenAI un estándar técnico suficiente para interoperabilidad real entre proveedores de inferencia LLM, o existen divergencias sistemáticas que comprometen la portabilidad prometida?

1.4 Contribuciones

Este artículo aporta:

1. Cronología verificada de la evolución de la especificación OpenAI (2020–2026) con fuentes primarias.
2. Catálogo auditado de 16 implementaciones (open-source + cloud) con endpoints cubiertos y gaps conocidos.
3. Evaluación cuantitativa de divergencias entre implementaciones en 8 categorías de funcionalidad.
4. Propuesta de MVP mínimo para construir un servidor propio OpenAI-compatible.
5. Declaración explícita de riesgos de seguridad y limitaciones de la «compatibilidad».

2. Metodología

2.1 Fuentes primarias

Se consultó la especificación oficial de OpenAI en el repositorio público github.com/openai/openai-openapi [5], branch manual_spec (OpenAPI 3.1, 26k líneas, 76 paths, 284 schemas). Fecha de consulta: 2026-04-22. Se validó complementariamente con developers.openai.com/api/reference [6].

2.2 Fuentes secundarias

Documentación oficial de cada implementación auditada (URLs individuales citadas en §4), más cobertura analítica por Simon Willison [7], Keywords AI [8], Mozilla.ai [9], Deepankar Mahapatro [10] y threads técnicos en GitHub Issues de los repositorios respectivos.

2.3 Criterios de inclusión / exclusión

Se incluyeron: (a) implementaciones que declaran explícitamente compatibilidad OpenAI en documentación oficial, (b) con endpoint /v1/chat/completions verificable al 2026-04-22. Se excluyeron: (c) proyectos archivados o sin actividad en los últimos 12 meses, (d) wrappers únicamente del lado cliente (SDKs sin servidor).

2.4 Herramientas de verificación

GitHub CLI (gh api repos/...), búsqueda web (Brave + DuckDuckGo), agent-reach digest sobre threads de Hacker News y r/LocalLLaMA, y pruebas empíricas con curl contra endpoints locales (Ollama 11434, LM Studio 1234) cuando estaban disponibles.

2.5 Limitaciones metodológicas declaradas

1. No se ejecutaron benchmarks de throughput contra cada implementación.
2. No se validó empíricamente el soporte de streaming SSE en cada una de las 16 implementaciones — se confió en la documentación oficial.
3. No se audita el comportamiento bajo carga ni edge cases (cancelación de streams, timeouts).
4. No se evalúa la exactitud de las respuestas de los modelos subyacentes — solo la conformidad del contrato HTTP.

3. Trabajos previos y contexto histórico

La evolución del estándar puede dividirse en cinco hitos documentados:

Fecha	Hito	Fuente
2020-06-11	OpenAI lanza API original con /v1/completions (GPT-3 private beta)	TechCrunch [1]
2023-03-01	Introducción de /v1/chat/completions con gpt-3.5-turbo — formato messages[] con roles	OpenAI Changelog [2]
2023-06-13	Function calling añadido al chat/completions; JSON-schema en tools	OpenAI Docs [11]
2023-11 (DevDay)	Vision (image_url), seed, logprobs, response_format: json_object, Assistants API	InfoQ [12]
2024-02	Ollama adopta OpenAI-compatibility oficialmente	Ollama Blog [13]
2025	Responses API stateful; OpenAI declara Chat Completions «supported indefinitely as an industry standard»	OpenAI Community [14]
2025	HuggingFace capitula y adopta OpenAI-compatible en todos sus Inference Providers	HuggingFace Changelog [3]

4. Resultados

4.1 Especificación técnica canónica

Los endpoints bajo /v1/ agrupados por dominio [6]:

Endpoint	Función	Método
/chat/completions	Conversación — endpoint dominante	POST
/completions	Text completion legacy	POST
/embeddings	Vectores de embedding	POST
/models, /models/{id}	Listado de modelos disponibles	GET
/audio/transcriptions, /translations, /speech	Whisper STT + TTS	POST
/images/generations, /edits, /variations	DALL-E	POST
/moderations	Safety classifier	POST
/files, /fine_tuning/jobs, /batches	Entrenamiento y batch async	POST
/responses (2025)	Primitiva agéntica stateful	POST

4.2 Shape canónico de /v1/chat/completions

Request: model (string), messages (array de {role, content}), temperature, top_p, n, stream, max_tokens, tools, tool_choice, seed, logprobs, response_format, presence_penalty, frequency_penalty, logit_bias.

Response: id, object:"chat.completion", created, model, choices[].message, choices[].finish_reason, usage{prompt_tokens, completion_tokens, total_tokens} [6].

4.3 Streaming Server-Sent Events

Content-Type text/event-stream. Cada chunk: data: {<chunk-json>}\n\n con object: "chat.completion.chunk" y choices[].delta.content incremental. Terminador obligatorio: la línea literal data: [DONE]\n\n [15].

4.4 Implementaciones auditadas (16)

Proyecto	Lang	Puerto	Licencia	Endpoints implementados
Ollama [16]	Go	11434	MIT	chat/completions, completions, embeddings, models, responses (v0.13.3+)
vLLM [17]	Python	8000	Apache-2.0	chat, completions, embeddings, models, audio/transcriptions, Realtime WS
llama.cpp server [18]	C/C++	8080	MIT	chat, embeddings, tool calling, vision
LM Studio [19]	TS + Electron	1234	Proprietary (free)	chat, completions, embeddings, models, responses + Anthropic-compat
HF TGI [20]	Rust + Python	8080	Apache-2.0	Messages API desde v1.4.0 (feb 2024)
text-generation-webui [21]	Python	5000	AGPL-3.0	chat, completions, embeddings + Anthropic messages
TabbyAPI [22]	Python (FastAPI)	5000	AGPL-3.0	OAI sobre ExllamaV2/V3
LocalAI [23]	Go	8080	MIT	Near-full surface (incl. audio, images, responses)
LiteLLM Proxy [24]	Python	4000	MIT	Full OAI → 100+ providers (Bedrock, Vertex, Anthropic, Cohere)
OpenRouter [25]	cloud	n/a	SaaS	chat, completions, models, Responses beta
Together AI [26]	cloud	n/a	SaaS	chat, completions, embeddings, images, audio
Groq [27]	cloud	n/a	SaaS	chat/completions, models, audio
Fireworks AI [28]	cloud	n/a	SaaS	chat, completions, embeddings, images
Anthropic [29]	cloud	n/a	SaaS	OAI-compat beta: chat completions only, «test-only, not production-recommended»
Azure OpenAI [30]	cloud	n/a	SaaS	Same path shape, works with official SDK directly
Anyscale Endpoints	cloud	n/a	SaaS (privatizado 2024)	chat, completions, embeddings

4.5 Divergencias sistemáticas identificadas

Analizando la cobertura de features entre las 16 implementaciones, se identifican 6 categorías con divergencia notable:

Feature	Implementaciones con soporte completo	Gaps observados
logprobs + top_logprobs	OpenAI, Azure, LocalAI	Groq, Ollama parcial, Anthropic no
seed determinístico + system_fingerprint	OpenAI únicamente	El resto lo aceptan pero no garantizan reproducibilidad
n > 1 (múltiples completions)	OpenAI, vLLM	Groq, Ollama no soportan
Batch API (/v1/batches)	OpenAI, Azure, Anthropic	Ninguna open-source
Assistants API	OpenAI únicamente	Ninguna otra implementación
Moderations	OpenAI únicamente	Reemplazable con Llama Guard local, pero no con el contrato /v1/moderations
Fine-tuning jobs	OpenAI, Fireworks, Together	Ollama, vLLM, llama.cpp no exponen API
Structured Outputs (strict: true)	OpenAI, Azure, Groq (parcial)	Anthropic ignora strict; vLLM tiene guided_json extendido

4.6 Extensiones fuera de especificación

Varias implementaciones añaden parámetros propios no presentes en OpenAI [17][16]:

• vLLM: guided_json, guided_regex, guided_grammar, guided_choice, prefix_caching.
• Ollama: keep_alive, options.num_ctx, options.num_gpu.
• llama.cpp: endpoints extra /slots, /tokenize, /props.

4.7 MVP para construir un servidor OpenAI-compatible

Los 2 endpoints mínimos que heredan gratis el ecosistema [31]:

# MVP: FastAPI (Python) — ~80 líneas
@app.post("/v1/chat/completions")
async def chat_completions(req: ChatRequest):
    if req.stream:
        return StreamingResponse(sse_generator(req), media_type="text/event-stream")
    return {"id": "...", "object": "chat.completion", "created": int(time.time()),
            "model": req.model, "choices": [...], "usage": {...}}

@app.get("/v1/models")
async def list_models():
    return {"object": "list", "data": [{"id": "mi-modelo", "object": "model", ...}]}

Test dorado:

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="dummy")
client.chat.completions.create(model="mi-modelo", messages=[{"role":"user","content":"hi"}])

Si este snippet funciona (incluyendo streaming y tool_calls básicos), el servidor es «compatible suficiente» para el 90% del ecosistema [32].

5. Discusión

5.1 Fortalezas verificables del estándar

Portabilidad real en casos básicos: swappear proveedor = cambiar un env var. Groq, DeepSeek, Mistral, xAI, Qwen, Together, Fireworks adoptaron el patrón base_url explícitamente [33]. Los ejemplos de documentación oficial muestran que el mismo código Python con OpenAI(base_url=...) funciona contra cualquiera.

Ecosistema gratuito: LangChain admite base_url nativamente [34], LlamaIndex tiene clase OpenAILike exactamente para endpoints compatibles [35], y Continue.dev, Aider, Cline, Cursor, Haystack, AutoGen aceptan OPENAI_BASE_URL. Implementar 2 endpoints → 20+ herramientas funcionan sin cambios.

LiteLLM como pegamento universal [24]: traduce a formato OpenAI 100+ proveedores incluyendo no-compatibles (Bedrock Converse, Anthropic Messages native). Añadir un provider nuevo es editar un JSON.

5.2 Debilidades y riesgos

La «compatibilidad» es parcialmente una ilusión. Como concluye Deepankar Mahapatro en su análisis «The OpenAI Compatibility Paradox» [10]: «‘OpenAI-compatible’ currently means ‘similar enough to seem interchangeable until it’s not.’ Abstraction layers like LiteLLM inherit the problem and don’t actually insulate developers from fragmentation.»

Features de frontera divergen: reasoning content de modelos tipo o1/o3, structured outputs estrictos, prompt caching, y Responses API stateful de 2025 están fragmentando el estándar. Mozilla.ai documentó que cada proveedor inventó su propio campo para reasoning (reasoning_content vs thinking) [9].

Streaming SSE es el punto más roto: muchos servidores open-source olvidan el \n\n terminal o dividen tokens UTF-8 entre chunks, rompiendo SDKs. Ver por ejemplo LocalAI issue #2101 [36].

Tool calling diverge: OpenAI, Azure, Groq, LM Studio, y Ollama v0.3+ implementan el contrato tools/tool_calls nativamente. TGI lo tiene parcial. llama.cpp y vLLM recurren a grammar-constrained JSON para coercionar modelos no entrenados en tool use [17].

5.3 Red flags identificados

1. Lock-in sutil en plataformas cloud: AWS Bedrock añadió endpoint OpenAI-compat solo para modelos OpenAI hosteados; para Claude en Bedrock hay que volver a boto3 [37]. La «portabilidad» se rompe en fronteras de provider.
2. Seguridad por default insuficiente: vLLM documenta que --api-key solo protege /v1; endpoints como /health y /metrics quedan abiertos [38].
3. Bill shock es el riesgo operacional #1: keys filtradas generan USD 4k–15k en horas; OpenAI escanea GitHub y desactiva keys detectadas [39].
4. Responses API (2025) introduce un segundo contrato stateful, divergente de chat/completions — riesgo de nuevo split si los implementadores se quedan atrás.

5.4 Contextualización histórica

El patrón recuerda a la convergencia de otros estándares de-facto en la historia del software:

• S3 API para object storage (2006): MinIO, Cloudflare R2, Backblaze B2, DigitalOcean Spaces, Wasabi — todos implementan el contrato AWS S3. Idéntica lógica: SDK ecosystem + endpoint_url override.
• Kubernetes API: K3s, OpenShift, Rancher — mismo contrato base, diferencias en extensiones.
• Bitcoin RPC: Bitcoin Core definió el JSON-RPC que Bitcoin Cash, Litecoin y forks heredaron.

En todos los casos la convergencia ocurrió por efecto red del ecosistema cliente, no por consenso formal de un body de estándares (ISO, IETF, IEEE).

6. Limitaciones del estudio

1. No se ejecutaron benchmarks de throughput, latencia o fidelidad de respuesta contra ninguna implementación.
2. No se validó empíricamente la correctitud de streaming SSE en las 16 implementaciones.
3. La clasificación de «completo» vs «parcial» se basa en documentación oficial; puede haber gaps no declarados.
4. El corte temporal de fuentes es 2026-04-22; cambios posteriores no están reflejados.
5. No se auditan licencias de modelos individuales (ej: restricciones de uso comercial en Llama, Gemma).

7. Recomendaciones por perfil de usuario

Perfil	Recomendación	Justificación
Developer solo construyendo producto	✅ Adoptar OpenAI SDK + base_url	Máxima portabilidad con fricción cero
Equipo ML con múltiples providers	✅ LiteLLM Proxy como capa central	100+ providers normalizados, observabilidad integrada
Self-hoster (privacidad + costo cero)	Ollama (simplicidad) o vLLM (throughput)	Ambos exponen /v1/chat/completions nativo
Aplicación que requiere reasoning content (o1/o3)	⚠️ Cuidado — formato de reasoning_content no estandarizado	Necesitarás adapter propio
Investigación que requiere reproducibilidad	❌ Evitar — seed solo determinístico en OpenAI	Usar modelos locales con seeds explícitas y registro completo de weights
Construir servidor propio OpenAI-compat	✅ FastAPI + 2 endpoints + SSE	Ecosistema entero hereda gratis, referencia: vLLM + llama.cpp

8. Conclusiones y trabajo futuro

El estándar OpenAI-compatible API es una convergencia pragmática, no una especificación formal. Funciona suficientemente bien para chat, embeddings y tool calling básico — suficientes para la mayoría de aplicaciones. Falla en reproducibilidad científica, features de frontera, y cuando se atraviesan fronteras de provider comercial.

Para LATAM y equipos pequeños, la recomendación práctica es: (i) escribir código contra el SDK openai oficial con base_url configurable, (ii) introducir LiteLLM Proxy como capa de abstracción cuando haya 3+ providers, y (iii) documentar explícitamente cualquier dependencia en features no-compat (Batch, Assistants, Responses) para facilitar migraciones futuras.

Trabajo futuro: (a) benchmarks empíricos de conformidad por implementación, (b) testing de robustez de streaming SSE bajo carga, (c) análisis comparativo de la nueva Responses API stateful y su adopción, (d) evaluación de Mozilla any-llm y Llama Stack como capas de normalización para reasoning content.

Preguntas frecuentes

¿Cuál es el mínimo para llamar a mi servidor «OpenAI-compatible»?

Implementar POST /v1/chat/completions (con stream: true vía SSE) y GET /v1/models. Con eso, el SDK openai oficial funciona — y por tanto funcionan LangChain, LlamaIndex, Continue, Aider y Cursor.

¿Por qué el estándar OpenAI ganó y no el de HuggingFace o Anthropic?

Efecto red del SDK. OpenAI publicó SDKs oficiales (Python, Node) con base_url configurable temprano. Cualquier servidor que cumpliera el contrato heredaba gratis miles de apps. HuggingFace capituló en 2025 y adoptó el formato OpenAI en sus Inference Providers [3].

¿Cuál es la diferencia entre Chat Completions y Responses API?

Chat Completions es stateless (tú mantenés el messages[]); Responses API es stateful (OpenAI mantiene el estado conversacional del lado server). OpenAI declaró que Chat Completions seguirá «supported indefinitely as an industry standard» [14], pero Responses puede divergir del estándar en features agénticas.

¿Es seguro exponer mi servidor OpenAI-compat a internet?

Con precauciones: usá autenticación Bearer, hard spending caps 2–3x tu uso esperado, rate limits per-user, WAF (Cloudflare), y asegurate de que todos los endpoints (/health, /metrics) también estén protegidos — no solo /v1/* [38][39].

¿LiteLLM hace que mi app sea 100% portable?

No. LiteLLM cubre las grietas más grandes pero heredan los problemas del estándar original: structured outputs, reasoning content y Responses API siguen fragmentados [10]. Es el mejor pegamento disponible, no una solución completa.

¿Anthropic tiene endpoint OpenAI-compatible?

Sí, pero en beta y solo para chat completions. Anthropic documenta explícitamente que es «test-only, not production-recommended» [29]. audio input se descarta silenciosamente, strict en tools se ignora, y prompt caching solo funciona vía SDK nativo.

Declaraciones

Conflicto de interés: el autor no tiene afiliación con OpenAI, Anthropic, Google, AWS, Microsoft Azure, Meta, HuggingFace, ni con ninguna de las empresas o proyectos mencionados. No recibe compensación por este análisis.

Disponibilidad de datos: todas las URLs citadas son consultables públicamente. La especificación OpenAPI está disponible en github.com/openai/openai-openapi bajo licencia del repositorio. Los queries a GitHub API para verificación de implementaciones son reproducibles con gh api.

Fecha de auditoría: 2026-04-22, 22:00 CST. Versión del artículo: v1.0 (primer post nativo en formato IMRyD v2.0 del blog).

Referencias

1. F. Lardinois, «OpenAI makes an all-purpose API for its text-based AI capabilities,» TechCrunch, 11-jun-2020. [En línea]. Disponible en: techcrunch.com/2020/06/11/openai-makes-an-all-purpose-api-for-its-text-based-ai-capabilities
2. OpenAI, «Developers API Changelog,» developers.openai.com. [En línea]. Disponible en: developers.openai.com/api/docs/changelog
3. HuggingFace, «Inference Providers now fully support OpenAI-compatible API,» HuggingFace Changelog, 2025. [En línea]. Disponible en: huggingface.co/changelog/inference-providers-openai-compatible
4. OpenAI, «openai-python SDK,» GitHub. [En línea]. Disponible en: github.com/openai/openai-python
5. OpenAI, «openai-openapi specification,» GitHub. [En línea]. Disponible en: github.com/openai/openai-openapi
6. OpenAI, «API Reference — Chat completions,» developers.openai.com. [En línea]. Disponible en: developers.openai.com/api/reference
7. S. Willison, «OpenAI publishes their OpenAPI schema,» simonwillison.net, 22-dic-2024. [En línea]. Disponible en: simonwillison.net/2024/Dec/22/openai-openapi
8. Keywords AI Team, «LLM consistency and reproducibility in 2025,» keywordsai.co. [En línea]. Disponible en: keywordsai.co/blog/llm_consistency_2025
9. Mozilla.ai, «Standardized Reasoning Content — a first look at using OpenAI GPT-OSS on multiple providers using any-llm,» blog.mozilla.ai, 2025. [En línea]. Disponible en: blog.mozilla.ai/standardized-reasoning-content
10. D. Mahapatro, «The OpenAI Compatibility Paradox,» deepankarm.github.io. [En línea]. Disponible en: deepankarm.github.io/posts/openai-compatibility-paradox
11. OpenAI, «Function calling guide,» platform.openai.com. [En línea]. Disponible en: platform.openai.com/docs/guides/function-calling
12. InfoQ, «OpenAI DevDay 2023 recap,» 2023. [En línea]. Disponible en: infoq.com/news/2023/11/openai-announcements-1stdevday
13. Ollama, «OpenAI compatibility,» ollama.com/blog, feb 2024. [En línea]. Disponible en: ollama.com/blog/openai-compatibility
14. OpenAI, «Introducing the Responses API,» OpenAI Developer Community, 2025. [En línea]. Disponible en: community.openai.com/t/introducing-the-responses-api
15. Speakeasy, «Server-Sent Events SDK runtime guide,» speakeasy.com/docs. [En línea]. Disponible en: speakeasy.com/docs/sdks/customize/runtime/server-sent-events
16. Ollama, «Repositorio oficial,» GitHub. [En línea]. Disponible en: github.com/ollama/ollama
17. vLLM, «OpenAI-compatible server documentation,» docs.vllm.ai. [En línea]. Disponible en: docs.vllm.ai/en/stable/serving/openai_compatible_server
18. llama.cpp, «server README,» GitHub. [En línea]. Disponible en: github.com/ggml-org/llama.cpp/blob/master/tools/server
19. LM Studio, «OpenAI API documentation,» lmstudio.ai. [En línea]. Disponible en: lmstudio.ai/docs/api/openai-api
20. HuggingFace, «TGI Messages API,» huggingface.co/blog. [En línea]. Disponible en: huggingface.co/blog/tgi-messages-api
21. oobabooga, «text-generation-webui OpenAI API wiki,» GitHub. [En línea]. Disponible en: github.com/oobabooga/text-generation-webui/wiki/12-OpenAI-API
22. theroyallab, «TabbyAPI repo,» GitHub. [En línea]. Disponible en: github.com/theroyallab/tabbyAPI
23. mudler, «LocalAI repo,» GitHub. [En línea]. Disponible en: github.com/mudler/LocalAI
24. BerriAI, «LiteLLM repo,» GitHub. [En línea]. Disponible en: github.com/BerriAI/litellm
25. OpenRouter, «Documentation,» openrouter.ai/docs. [En línea]. Disponible en: openrouter.ai/docs/quickstart
26. Together AI, «OpenAI compatibility,» docs.together.ai. [En línea]. Disponible en: docs.together.ai/docs/openai-api-compatibility
27. Groq, «OpenAI compatibility docs,» console.groq.com. [En línea]. Disponible en: console.groq.com/docs/openai
28. Fireworks AI, «OpenAI compatibility,» docs.fireworks.ai. [En línea]. Disponible en: docs.fireworks.ai/tools-sdks/openai-compatibility
29. Anthropic, «OpenAI SDK compatibility,» platform.claude.com. [En línea]. Disponible en: platform.claude.com/docs/en/api/openai-sdk
30. Microsoft Learn, «Azure OpenAI Service — .NET SDK overview,» learn.microsoft.com. [En línea]. Disponible en: learn.microsoft.com/en-us/dotnet/api/overview/azure/ai.openai-readme
31. S. Berkovich, «How to build an OpenAI-compatible API,» Towards Data Science. [En línea]. Disponible en: towardsdatascience.com/how-to-build-an-openai-compatible-api
32. ritun16, «openai-compatible-fastapi template,» GitHub. [En línea]. Disponible en: github.com/ritun16/openai-compatible-fastapi
33. Strapi, «LangChain vs Vercel AI SDK vs OpenAI SDK 2026,» strapi.io/blog. [En línea]. Disponible en: strapi.io/blog/langchain-vs-vercel-ai-sdk-vs-openai-sdk-comparison-guide
34. LangChain, «Connect to OpenAI-compliant provider,» docs.langchain.com. [En línea]. Disponible en: docs.langchain.com/langsmith/custom-openai-compliant-model
35. LlamaIndex, «Getting started,» developers.llamaindex.ai. [En línea]. Disponible en: developers.llamaindex.ai/python/framework/getting_started
36. mudler, «LocalAI issue #2101 — streaming format,» GitHub. [En línea]. Disponible en: github.com/mudler/LocalAI/issues/2101
37. BentoML, «OpenAI-compatible API basics,» bentoml.com. [En línea]. Disponible en: bentoml.com/llm/llm-inference-basics/openai-compatible-api
38. vLLM, «Security documentation,» docs.vllm.ai. [En línea]. Disponible en: docs.vllm.ai/en/latest/usage/security
39. Scantient, «Securing OpenAI API integration,» scantient.com. [En línea]. Disponible en: scantient.com/blog/securing-openai-api-integration