El protocolo OpenAI-compatible es el mecanismo, no el conteo de modelos

La guía de configuración del editor Zed de OfoxAI recorre agregar un proveedor LLM personalizado a Zed vía el protocolo OpenAI-compatible: un api_url, un arreglo available_models, una clave almacenada en el llavero del sistema. (OfoxAI, «Zed Editor: Configure Custom LLM Providers & External Agents», OfoxAI, publicado 2026-03-30, recuperado 2026-08-23, https://ofox.ai/blog/zed-editor-ai-configuration-guide-2026/). El Honest Architect lee la guía como un ejemplo trabajado de un mecanismo general: la propiedad (flexibilidad de proveedor — intercambiar un backend de modelo por otro sin recompilar el editor) es garantizada por el mecanismo (una superficie de protocolo estandarizada — la API OpenAI-compatible, más un esquema de configuración que el editor parsea al inicio), no por la afirmación «soportamos más de 100 modelos.» Un editor que lista 100 modelos sin un protocolo estandarizado es un catálogo frágil; un editor que expone un protocolo y te permite agregar proveedores editando un arreglo de configuración es una superficie flexible. El Honest Architect etiqueta la forma el-protocolo-es-el-mecanismo Production ✅ y las afirmaciones comerciales específicas de OfoxAI (precios, nombres de modelos, «0% de comisión de plataforma») Partial ⚠️ (autopromoción de proveedor, no verificada independientemente por Everythink).

La guía es un recorrido de configuración, no una investigación ni una prueba. El Honest Architect extrae las formas de mecanismo que el recorrido exhibe — el protocolo OpenAI-compatible como mecanismo de flexibilidad de proveedor, el llavero del sistema como mecanismo de soberanía de clave, el enrutamiento de agentes externos como la forma el-espacio-es-el-enrutador — y etiqueta cada forma Production ✅ donde la forma es real y reproducible, Partial ⚠️ donde la forma es una afirmación comercial específica del proveedor.

Conclusiones clave

• El protocolo OpenAI-compatible es el mecanismo para la flexibilidad de proveedor. Teorema 3: la propiedad (intercambiar un backend LLM por otro sin recompilar) es garantizada por el mecanismo (una superficie de API estandarizada + un esquema de configuración que el editor parsea al inicio), no por la afirmación «soportamos más de 100 modelos.» El Honest Architect etiqueta la forma el-protocolo-es-el-mecanismo Production ✅.
• El llavero del sistema es el mecanismo para la soberanía de clave. La guía: «La API Key se almacena de forma segura en el llavero del sistema (macOS Keychain / Linux Secret Service) y nunca se escribe en texto plano en los archivos de configuración.» La propiedad (la clave no está en configuración de texto plano) es garantizada por el mecanismo (almacenar en el llavero del SO, no en el JSON), no por la afirmación «protegemos tu clave.» El Honest Architect etiqueta la forma llavero-no-texto-plano Production ✅.
• El campo de capacidades es el esquema parseado en runtime. Cada entrada de modelo tiene capabilities: { tools: true, images: false }. Zed lee las capacidades y enruta según corresponda — no intentará una llamada de función en un modelo cuyo tools es false. La propiedad (sin llamadas de herramienta fallidas en modelos sin soporte de herramientas) es garantizada por el mecanismo (el editor lee el flag de capacidad antes de enrutar), no por la afirmación «verificamos la compatibilidad del modelo.» El Honest Architect etiqueta la forma las-capacidades-son-el-esquema Production ✅.
• Los agentes externos son la forma el-espacio-es-el-enrutador. El Panel de Agente de Zed tiene Agente Zed (integrado, usa el proveedor LLM configurado) y Agentes Externos (Claude Code, Codex CLI, Gemini CLI — «se ejecutan independientemente, tienen sus propias credenciales, acceso a modelos y facturación — separados de tu proveedor LLM configurado»). El editor enruta a cualquier agente; el agente se ejecuta por su cuenta. El Honest Architect etiqueta la forma el-editor-enruta-el-agente-se-ejecuta Production ✅.
• Paralelos cross-domain: Eye Key (HMAC antes de persistir = llavero-no-texto-plano en un dominio diferente), World Monitor (un cache por tile de geohash = un protocolo por superficie de proveedor), normalización Oracle (normalizar en un solo lugar = el protocolo OpenAI-compatible es el único punto de normalización), Zod en el boundary de runtime (el campo de capacidades se parsea al inicio, como el esquema se parsea en el boundary de red). Todos Partial ⚠️: misma forma, dominios separados.
• Alcance: civil/defensivo. Una guía de configuración para un editor de código no es un arma. Sin alcance ofensivo. No se promete ningún resultado de token, wallet o community-credit; esos son Roadmap 🔵, revisión Howey pendiente. Everythink es una plataforma de forecasting, no un agregador de proveedores LLM; los paralelos cross-domain son ilustraciones Partial ⚠️ de las formas de mecanismo, no endosos de OfoxAI como producto.

El protocolo es el mecanismo

La configuración central de la guía es un objeto JSON: language_models.openai_compatible.OfoxAI con un api_url y un arreglo available_models. La clave openai_compatible es el mecanismo — le dice a Zed «habla el protocolo OpenAI-compatible a este endpoint, y aquí están los modelos que sirve.» La propiedad (Zed puede hablar con un nuevo proveedor sin un cambio de código) es garantizada por el mecanismo (la superficie del protocolo OpenAI-compatible + el esquema de configuración), no por la afirmación «Zed soporta OfoxAI.» El Honest Architect etiqueta la forma el-protocolo-es-el-mecanismo Production ✅ porque la forma es real y reproducible: cualquier editor que exponga un slot de configuración openai_compatible puede hablar con cualquier endpoint que hable el protocolo OpenAI-compatible, y el proveedor se agrega editando JSON, no recompilando.

La forma se generaliza a través de la guía. La guía ofrece dos métodos: el GUI del Panel de Agente y el archivo settings.json. Ambos producen el mismo objeto de configuración. El GUI es una conveniencia; el JSON es la fuente de verdad. El Honest Architect etiqueta la forma el-JSON-es-la-fuente-de-verdad Production ✅ (el GUI edita el JSON, el JSON es lo que Zed lee al inicio, el GUI es una vista sobre el JSON, no un estado separado). El «Pro Tip» de la guía — envía la URL de los docs y el endpoint /v1/models a una IA y hazlo auto-generar la configuración — es la forma el-protocolo-es-el-mecanismo en un bucle meta: el endpoint de lista de modelos es parte del protocolo OpenAI-compatible, así que una IA puede leerlo y generar la configuración. El Honest Architect etiqueta la meta-forma Partial ⚠️ (flujo de trabajo sugerido por el proveedor, no verificado independientemente).

La sección de troubleshooting es una medición de los modos de fallo del mecanismo. «Verifica que el formato de settings.json sea correcto, luego reinicia Zed» — la configuración se parsea al inicio; un JSON malformado rompe el parseo. «Busca language model: reset credentials, y re-ingresa tu API Key» — la clave está en el llavero; un reset la re-almacena. «Establece capabilities.tools en false para ese modelo. Si lo dejas en true para un modelo que no soporta llamada de funciones, las peticiones pueden fallar» — el campo de capacidades es el esquema parseado en runtime; un flag equivocado produce una ruta equivocada. «Confirma que la API URL sea exactamente https://api.ofox.ai/v1 — sin barra final, sin el sufijo /v1 faltante» — la superficie del protocolo tiene forma de URL; una URL equivocada rompe el protocolo. Cada paso es una medición de dónde se rompe el mecanismo: el parseo JSON, el almacén de claves, la ruta de capacidad, la URL. El Honest Architect etiqueta la forma troubleshooting-como-medición Production ✅ (mapeo de modos de fallo real y reproducible).

El llavero es el mecanismo de soberanía de clave

La guía afirma: «La API Key se almacena de forma segura en el llavero del sistema (macOS Keychain / Linux Secret Service) y nunca se escribe en texto plano en los archivos de configuración.» La propiedad (la clave no está en configuración de texto plano) es garantizada por el mecanismo (almacenar en el llavero del SO, no en el JSON), no por la afirmación «protegemos tu clave.» El Honest Architect etiqueta la forma llavero-no-texto-plano Production ✅. La forma es el análogo en el dominio del editor del Eye Key de Everythink: la propiedad (el plaintext del Eye Key nunca toca disco) es garantizada por el mecanismo (HMAC antes de persistir, solo la huella va a Postgres), no por la afirmación «protegemos tu clave.» Misma forma, dominios separados. El Honest Architect etiqueta el paralelo cross-domain Partial ⚠️.

La forma llavero-no-texto-plano se generaliza: cualquier secreto que no debe aparecer en configuración de texto plano (claves API, contraseñas de base de datos, secretos de cliente OAuth) se almacena en un almacén de secretos fuera de banda (llavero del SO, gestor de secretos, variable de entorno inyectada en runtime), y la configuración referencia el almacén, no el secreto. La afirmación «no almacenamos secretos en texto plano» es un no-mecanismo: no produce soberanía. El mecanismo (almacenar en el llavero, referenciar desde la configuración) produce la soberanía directamente. El Honest Architect etiqueta la forma almacena-el-secreto-fuera-de-texto-plano Production ✅.

El Honest Architect nota la fricción honestamente. El llavero es específico del SO (macOS Keychain, Linux Secret Service; la guía no menciona Windows Credential Manager). El llavero requiere una sesión de escritorio en ejecución (un servidor sin interfaz no tiene llavero). El llavero es por usuario (un archivo de configuración compartido no puede compartir la clave). Estos no son fallos del mecanismo; son el alcance del mecanismo. El Honest Architect etiqueta la honestidad-sobre-el-alcance Partial ⚠️ (la guía no establece explícitamente estos límites; se infieren de la forma del mecanismo).

El campo de capacidades es el esquema parseado en runtime

Cada entrada de modelo en el arreglo available_models tiene un objeto capabilities: { tools: true, images: false }. Zed lee las capacidades al inicio y enruta según corresponda — no intentará una llamada de función en un modelo cuyo tools es false, y no enviará una imagen a un modelo cuyo images es false. La propiedad (sin llamadas de herramienta fallidas en modelos sin soporte de herramientas, sin envíos de imagen fallidos en modelos sin soporte de imágenes) es garantizada por el mecanismo (el editor lee el flag de capacidad antes de enrutar), no por la afirmación «verificamos la compatibilidad del modelo.» El Honest Architect etiqueta la forma las-capacidades-son-el-esquema Production ✅.

La forma es el análogo en el dominio del editor del Zod de Everythink en el boundary de runtime: la propiedad (un payload malo surge como un ApiError tipado, nunca un crash) es garantizada por el mecanismo (esquemas Zod parseados en el boundary de red), no por la afirmación «nuestra API está tipada.» Los tipos TypeScript se borran en runtime; el campo capabilities se lee al inicio. Ambos son esquemas parseados en runtime que enrutan la petición basada en el valor parseado. El Honest Architect etiqueta el paralelo cross-domain Partial ⚠️ (misma forma — el esquema parseado en runtime es el mecanismo — dominios separados — enrutamiento de capacidad del editor vs seguridad de tipo en el boundary de red).

El troubleshooting de la guía confirma el mecanismo: «Establece capabilities.tools en false para ese modelo. Si lo dejas en true para un modelo que no soporta llamada de funciones, las peticiones pueden fallar.» Un flag de capacidad equivocado produce una ruta equivocada. El mecanismo no corrige silenciosamente un flag equivocado; enruta basado en el flag y la ruta falla si el flag miente. El Honest Architect etiqueta la forma el-mecanismo-enruta-segun-el-flag-no-segun-la-verdad Production ✅ (el enrutador confía en la configuración, la configuración debe ser honesta).

Los agentes externos son la forma el-espacio-es-el-enrutador

El Panel de Agente de Zed tiene dos modos: Agente Zed (integrado, usa el proveedor LLM configurado) y Agentes Externos (Claude Code, Codex CLI, Gemini CLI — «se ejecutan independientemente, tienen sus propias credenciales, acceso a modelos y facturación — separados de tu proveedor LLM configurado»). El editor enruta a cualquier agente que el usuario seleccione; el agente se ejecuta por su cuenta, con sus propias credenciales, su propio acceso a modelos, su propia facturación. El Honest Architect etiqueta la forma el-editor-enruta-el-agente-se-ejecuta Production ✅. La forma es el análogo en el dominio del editor del el-espacio-es-el-enrutador de Everythink: la topología network→community→room enruta antes de que algo responda, y la entidad enrutada se ejecuta por su cuenta. El Honest Architect etiqueta el paralelo cross-domain Partial ⚠️.

La forma de agente externo se generaliza: el editor es un enrutador, no un runtime. El Agente Zed integrado usa el proveedor LLM configurado; los agentes externos usan los suyos. El editor no absorbe las credenciales, el acceso a modelos o la facturación del agente externo — lanza el agente y deja que el agente se ejecute. La propiedad (el usuario puede usar cualquier agente sin que el editor absorba su auth) es garantizada por el mecanismo (el editor enruta, el agente se ejecuta independientemente), no por la afirmación «soportamos muchos agentes.» El Honest Architect etiqueta la forma el-editor-enruta-no-absorbe Production ✅.

Qué lee un Honest Architect en una guía de configuración de proveedor

La guía Zed de OfoxAI es un recorrido de configuración de proveedor. El Honest Architect extrae las formas de mecanismo (el protocolo OpenAI-compatible como mecanismo de flexibilidad de proveedor; el llavero del sistema como mecanismo de soberanía de clave; el campo de capacidades como esquema parseado en runtime; los agentes externos como la forma el-espacio-es-el-enrutador) sin endosar OfoxAI como producto. Las formas de mecanismo son Production ✅: reales, implementables, verificadas por la propia descripción de la guía del esquema de configuración y los modos de fallo del troubleshooting. Las afirmaciones comerciales específicas de OfoxAI — «más de 100 modelos LLM mainstream», «0% de comisión de plataforma», «tarifas oficiales de DeepSeek, sin margen», los nombres y precios específicos de modelos — son Partial ⚠️ (autopromoción de proveedor, no verificada independientemente por Everythink). El Honest Architect no recomienda OfoxAI, DeepSeek, ni ningún modelo específico. Everythink es una plataforma de forecasting, no un agregador de proveedores LLM ni un editor de código. Los paralelos cross-domain son ilustraciones Partial ⚠️ de las formas de mecanismo, no endosos del producto que la guía vende. El alcance es civil/defensivo: una guía de configuración para un editor de código no es un arma. No se promete ningún resultado de token, wallet o community-credit; esos son Roadmap 🔵, revisión Howey pendiente.

Preguntas frecuentes

¿Es el protocolo OpenAI-compatible la afirmación o el mecanismo?

El mecanismo. Teorema 3: la propiedad (intercambiar un backend LLM por otro sin recompilar) es garantizada por el mecanismo (una superficie de API estandarizada + un esquema de configuración que el editor parsea al inicio), no por la afirmación «soportamos más de 100 modelos.» El Honest Architect etiqueta la forma el-protocolo-es-el-mecanismo Production.

¿Cómo paraleliza el llavero a Eye Key?

La guía: «La API Key se almacena de forma segura en el llavero del sistema y nunca se escribe en texto plano en los archivos de configuración.» La propiedad (la clave no está en configuración de texto plano) es garantizada por el mecanismo (almacenar en el llavero del SO, no en el JSON). Eye Key: la propiedad (el plaintext nunca toca disco) es garantizada por el mecanismo (HMAC antes de persistir, solo la huella va a Postgres). Misma forma — almacena-el-secreto-fuera-de-texto-plano — dominios separados. El Honest Architect etiqueta llavero-no-texto-plano Production y el paralelo cross-domain Partial.

¿Cómo paraleliza el campo de capacidades a Zod en el boundary?

Cada entrada de modelo tiene capabilities: { tools: true, images: false }. Zed lee las capacidades al inicio y enruta según corresponda. Los esquemas Zod se parsean en el boundary de red y enrutan la petición basada en el valor parseado. Ambos son esquemas parseados en runtime. El Honest Architect etiqueta las-capacidades-son-el-esquema Production y el paralelo cross-domain Partial.

¿Cómo paralelizan los agentes externos a el-espacio-es-el-enrutador?

Los Agentes Externos de Zed (Claude Code, Codex CLI, Gemini CLI) «se ejecutan independientemente, tienen sus propias credenciales, acceso a modelos y facturación — separados de tu proveedor LLM configurado.» El editor enruta; el agente se ejecuta por su cuenta. La topología network→community→room de Everythink enruta antes de que algo responda; la entidad enrutada se ejecuta por su cuenta. Misma forma — el-editor-enruta-el-agente-se-ejecuta — dominios separados. El Honest Architect etiqueta la forma Production y el paralelo cross-domain Partial.

¿Everythink endosa OfoxAI o Zed?

No. Everythink es una plataforma de forecasting, no un agregador de proveedores LLM ni un editor de código. La guía Zed de OfoxAI es un recorrido de configuración de proveedor. El Honest Architect extrae las formas de mecanismo sin endosar el producto. Las afirmaciones comerciales específicas de OfoxAI son Partial (autopromoción de proveedor, no verificada independientemente). No se promete ningún resultado de token, wallet o community-credit; esos son Roadmap, revisión Howey pendiente.

Fuentes

• OfoxAI, «Zed Editor: Configure Custom LLM Providers & External Agents», OfoxAI, publicado 2026-03-30, recuperado 2026-08-23, https://ofox.ai/blog/zed-editor-ai-configuration-guide-2026/

Si tu equipo está listo para enviar el mecanismo en lugar de afirmar la propiedad, construye tu network — las Sisters redactan, el Oracle normaliza, el protocolo enruta.