La capa de enrutamiento es el mecanismo, no la elección de proveedor

Una lectura del Honest Architect de LLM API Gateway Guide: Choose the Right One (2025), publicado el 20 de marzo de 2026 por Ofox en ofox.ai.

La afirmación de superficie del artículo es una guía de compra: elige uno de seis LLM API gateways (OpenRouter, LiteLLM, Portkey, Ofox, Helicone, Kong AI Gateway) según el tamaño de tu equipo y tus prioridades. El Honest Architect la lee por el mecanismo bajo la comparación y encuentra seis. El que lleva la carga es la capa de enrutamiento misma: un gateway se sienta entre tu aplicación y los proveedores de LLM, dándote una interfaz unificada, failover automático y control centralizado de costos. Theorem 3 en el HAI Engine de Everythink afirma la misma forma: una propiedad está garantizada exactamente cuando su mecanismo está implementado y midiendo. Aquí la propiedad es «tu aplicación sigue funcionando cuando un proveedor cae»; el mecanismo es «la capa de enrutamiento hace failover a otro proveedor antes de que la aplicación vea el error».

Una nota de alcance antes de los mecanismos: la fuente es una guía comercial de infraestructura de IA de un vendor de gateways, y naturalmente favorece el patrón de gateway. Las seis formas de mecanismo de abajo son ✅ — extraíbles de la propia evidencia del artículo. Las paralelas transversales a Everythink son ⚠️ — estructurales, no una afirmación de que nuestra plataforma de previsión civil y defensiva corre sobre un gateway LLM multi-proveedor. La configuración de proveedores LLM de Everythink es solo OpenAI-compatible (un protocolo como puerto, cualquier proveedor compatible como adaptador) — misma forma arquitectónica, alcance más estrecho.

Un gateway LLM multi-proveedor comercial como producto de Everythink es 🔵 Roadmap — pre-ingresos, no parte de la plataforma civil y defensiva actual.

Mecanismo 1 — La API unificada es el mecanismo de estabilidad-de-puerto

El artículo afirma que un gateway te da «One interface format for all providers — call GPT, Claude, and Gemini with the same code». El Honest Architect lo lee como una afirmación de estabilidad de puerto: tu aplicación sobrevive un cambio de proveedor está garantizado por la interfaz unificada estando implementada, no por tu aplicación conociendo el SDK de cada proveedor. El mecanismo que produce «cambiar de modelo es un cambio de configuración, no un cambio de código» es «el gateway expone una interfaz y traduce detrás». La API unificada es el mecanismo; el SDK nativo del proveedor no lo es. ✅ Producción — el artículo nombra el mecanismo (API unificada, una interfaz para todos los proveedores) y la propiedad (cambio de modelo es un cambio de una línea).

El artículo es honesto sobre lo que cuesta la interfaz unificada: «It's not an abstraction that hides model differences (you still choose which model to call)». El puerto es estable; la elección detrás sigue siendo tuya.

La paralela transversal a los puertos hexagonales basados en traits de Everythink es solo estructural. Los repositorios del AppState de Everythink son Arc<dyn Trait> para que los tests intercambien mocks — la aplicación depende del trait, no del adaptador Pg* concreto. El «tu código depende de la una interfaz del gateway, no de tres SDKs de proveedor» del artículo y el «tu use-case depende del trait del puerto, no del adaptador concreto» de Everythink comparten la misma forma: un puerto estable es el mecanismo de intercambiabilidad. ⚠️ Parcial — dominios diferentes, misma forma: un puerto estable es el mecanismo de intercambiabilidad.

Mecanismo 2 — El failover automático es el mecanismo de disponibilidad

El artículo afirma que «If Provider A is down, transparently retry with Provider B» y «If GPT-5.2 is unavailable or rate-limited, the gateway automatically routes to Claude — your app never sees an error». El Honest Architect lo lee como una afirmación de disponibilidad: el uptime está garantizado por el failover estando implementado y enrutando, no por un solo proveedor siendo confiable. El mecanismo que produce «tu aplicación nunca ve el error» es «el gateway reintenta con el Proveedor B antes de surfacer el fallo». El failover automático es el mecanismo; un solo proveedor confiable no lo es. ✅ Producción — el artículo nombra el mecanismo (failover automático, reintento transparente) y la propiedad (la aplicación nunca ve el error del proveedor).

El artículo es honesto de que esto no es hipotético: «In 2025 alone, every major LLM provider experienced at least one significant service disruption». El failover existe porque la garantía de un solo proveedor no existe.

La paralela transversal al ensemble del Oracle de Everythink es solo estructural. El Oracle fusiona salidas de múltiples Sisters tipadas (analyst, contrarian, disruptor, historian, institutionalist) en un ensemble normalizado — si el draft de una Sister es débil o falta, el ensemble se sostiene sobre las demás. El «Proveedor A cae → Proveedor B toma el relevo» del artículo y el «una Sister débil → el ensemble sigue fusionando» del Oracle comparten la misma forma: el failover multi-fuente es el mecanismo de disponibilidad. ⚠️ Parcial — el Oracle sirve previsión civil y defensiva, el gateway LLM sirve infraestructura de IA comercial. Dominios diferentes, misma forma: el failover multi-fuente es el mecanismo de disponibilidad.

Mecanismo 3 — La gestión de claves es el mecanismo de soberanía-de-credencial

El artículo afirma que «One gateway key in your code; provider keys stay in the gateway config». El Honest Architect lo lee como una afirmación de soberanía de credencial: la credencial del proveedor nunca llega a la aplicación está garantizado por la gestión de claves estando centralizada, no por la aplicación siendo cuidadosa. El mecanismo que produce «el código de la aplicación持有 una clave de gateway, no tres claves de proveedor» es «las claves de proveedor viven en la config del gateway, y la aplicación nunca las ve». La gestión de claves es el mecanismo; la higiene de claves a nivel de aplicación no lo es. ✅ Producción — el artículo nombra el mecanismo (una clave de gateway en el código, claves de proveedor en la config del gateway) y la propiedad (las credenciales de proveedor nunca llegan a la aplicación).

El artículo es honesto sobre por qué importa: sin esto, «each team member has their own API keys» y hay «no unified dashboard showing total spend across providers». La proliferación de credenciales es el síntoma; el mecanismo de gestión de claves faltante es la causa.

La paralela transversal a la soberanía del Eye Key de Everythink es solo estructural. El Eye Key es la credencial propia del usuario — el texto plano nunca toca el disco; solo el HMAC y la huella van a Postgres, y la clave del usuario es la frontera de límite de tasa. El «las claves de proveedor se quedan en la config del gateway, la aplicación持有 una clave de gateway» del artículo y el «el texto plano se muestra una vez en memoria, la plataforma almacena solo el HMAC» del Eye Key comparten la misma forma: la separación de credenciales es el mecanismo de soberanía. ⚠️ Parcial — Eye Key rige la soberanía de API para previsión civil y defensiva, la gestión de claves del gateway rige infraestructura de IA comercial. Dominios diferentes, misma forma: la separación de credenciales es el mecanismo de soberanía.

Mecanismo 4 — El seguimiento de costos es el mecanismo de observabilidad-de-gasto

El artículo afirma que «Without centralized cost tracking, you can't answer basic questions: Which model costs the most per task? Would switching providers save money? Are there runaway processes burning tokens?» y describe el agujero negro de costos: «You discover at month-end that someone left a batch job running against GPT-5 all weekend. Your API bill is 4x what you budgeted». El Honest Architect lo lee como una afirmación de observabilidad de gasto: el gasto está controlado está garantizado por el seguimiento de costos estando implementado y visible, no por el equipo siendo disciplinado. El mecanismo que produce «atrapas el batch job desbocado antes de fin de mes» es «el dashboard centralizado muestra el gasto total entre proveedores en tiempo real». El seguimiento de costos es el mecanismo; la disciplina del equipo no lo es. ✅ Producción — el artículo nombra el mecanismo (dashboard centralizado de costos, gasto por-modelo por-tarea) y la propiedad (el gasto desbocado se atrapa).

El artículo es honesto de que la configuración más barata en papel (llamadas directas, $0 de costo de gateway) esconde el costo real: «factor in engineering time — maintaining three SDKs, building custom fallback logic, debugging three different error formats, and reconciling three separate invoices — and the total cost of ownership shifts heavily toward using a gateway». La medición que importa es el costo total de propiedad, no el costo de API por línea.

La paralela transversal al ensemble con entropía estampada de Everythink es solo estructural. El Oracle normaliza probabilidades en exactamente un lugar y estampa entropía en nats en cada merge — la entropía es la señal de calibración que viene gratis de la normalización, no una afirmación separada de confianza. El «el dashboard centralizado muestra el gasto entre proveedores, no facturas por-proveedor» del artículo y el «la entropía se estampa en cada merge, no se afirma separadamente» del Oracle comparten la misma forma: una medición que viene gratis del mecanismo central es la señal de estado honesto. ⚠️ Parcial — dominios diferentes, misma forma: una medición subproducto gratis es la señal de estado honesto.

Mecanismo 5 — El enrutamiento de modelos es el mecanismo de decisión-en-la-frontera

El artículo afirma que un gateway provee «Route requests to different models based on cost, latency, or capability» y la config de failover toma un parámetro routing ("routing": "cost"). El Honest Architect lo lee como una afirmación de decisión en la frontera: el modelo correcto se elige por petición está garantizado por la regla de enrutamiento estando implementada en el gateway, no por la aplicación hardcodeando el modelo. El mecanismo que produce «la petición va al proveedor adecuado más barato» es «la regla de enrutamiento evalúa costo, latencia o capacidad en el gateway antes de despachar». El enrutamiento de modelos es el mecanismo; el string de modelo hardcodeado en la aplicación no lo es. ✅ Producción — el artículo nombra el mecanismo (regla de enrutamiento por costo/latencia/capacidad, parámetro routing) y la propiedad (selección de modelo por-petición).

El artículo es honesto de que el enrutamiento es una política, no magia: el framework de decisión pide a los equipos que puntúen los gateways por modelo de precios, cobertura de modelos, compatibilidad de SDK, fiabilidad, opción de self-host y experiencia de desarrollador. La regla de enrutamiento codifica la política; la política no es implícita.

La paralela transversal a la topología «the space is the router» de Everythink es solo estructural. La topología network → community → room de Everythink enruta una petición antes de que nada responda — el espacio es el router, y el enrutamiento pasa aguas arriba del compute. El «el gateway enruta antes de que el proveedor responda» del artículo y el «la topología enruta antes de que el agente responda» de Everythink comparten la misma forma: enrutamiento antes de respuesta es el mecanismo de decisión-en-la-frontera. ⚠️ Parcial — «the space is the router» rige la topología de previsión civil y defensiva, el enrutamiento del gateway rige infraestructura de IA comercial. Dominios diferentes, misma forma: enrutamiento antes de respuesta es el mecanismo de decisión-en-la-frontera.

Mecanismo 6 — La traducción de formato es el mecanismo de análisis-de-frontera

El artículo afirma que algunos gateways soportan SDKs nativos sin traducción (Ofox: «three protocols natively — OpenAI, Anthropic, and Gemini SDKs all work without translation») mientras otros traducen (LiteLLM: «Anthropic SDK ✅ (translation)»). El Honest Architect lo lee como una afirmación de análisis de frontera: la aplicación habla el formato del SDK elegido está garantizado por el gateway traduciendo en la frontera, no por la aplicación conformando al formato de cada proveedor. El mecanismo que produce «tu código del SDK de Anthropic funciona a través del gateway» es «el gateway parsea la petición en formato Anthropic y la traduce al formato nativo del proveedor». La traducción de formato es el mecanismo; la conformidad de formato del lado de la aplicación no lo es. ✅ Producción — el artículo nombra el mecanismo (soporte de SDK nativo sin traducción, o traducción en el gateway) y la propiedad (el código del SDK de la aplicación funciona sin modificar).

El artículo es honesto sobre el trade-off: el soporte nativo significa «you can use each provider's SDK with its full feature set, all through a single API key», mientras que la traducción significa que obtienes la interfaz unificada pero puedes perder características específicas del proveedor. La frontera parsea; lo que la frontera preserva es una decisión de diseño.

La paralela transversal a la frontera Zod-en-runtime de Everythink es solo estructural. Los wire types de Everythink se definen una vez en Zod en @everythink/types, y las respuestas se parsean en la frontera de red; un payload malo sale como un ApiError tipado, nunca un crash. El «el gateway parsea el formato de la petición en la frontera, la aplicación no infiere» del artículo y el «el parser valida el payload en la frontera, la aplicación no infiere» de Everythink comparten la misma forma: parsing explícito en la frontera es el mecanismo de interpretación correcta. ⚠️ Parcial — dominios diferentes, misma forma: parsing explícito en la frontera es el mecanismo de interpretación correcta.

Qué implica esto para alcance y límites

El artículo de Ofox es una guía comercial de infraestructura de IA de un vendor de gateways. Las seis formas de mecanismo son reales y extraíbles de la propia evidencia del artículo. Las paralelas transversales a la plataforma de previsión civil y defensiva de Everythink son estructurales — comparten formas de mecanismo, no mercados. El Honest Architect las marca ⚠️.

La propia configuración de proveedores LLM de Everythink es solo OpenAI-compatible (async-openai): un protocolo como puerto, cualquier proveedor compatible (OpenAI, vLLM, OpenRouter, Together) como adaptador. Este es el mismo patrón de puerto hexagonal aplicado a un alcance más estrecho — un protocolo, no tres. Sin dependencia directa del SDK de Anthropic. La forma arquitectónica se sostiene; el alcance de implementación es más estrecho. Esto es ⚠️ Parcial, no una afirmación de que Everythink corre la comparación de seis gateways.

Lo que el artículo no afirma merece también una marca. No afirma que un gateway elimine las caídas de proveedor — afirma que el failover las esconde de la aplicación. No afirma que la API unificada elimine las diferencias de modelo — afirma que el gateway traduce formato, mientras tú todavía eliges el modelo. No afirma que el seguimiento de costos reduzca el gasto — afirma que el seguimiento hace el gasto visible. Estos límites de alcance son la honestidad del artículo, y este billete los preserva.

Puntos clave

• Tu aplicación sobrevive un cambio de proveedor está garantizado por la interfaz unificada estando implementada, no por tu aplicación conociendo el SDK de cada proveedor. La API unificada es el mecanismo. ✅ Producción.
• El uptime está garantizado por el failover estando implementado y enrutando, no por un solo proveedor siendo confiable. El failover automático es el mecanismo. ✅ Producción.
• La credencial del proveedor nunca llega a la aplicación está garantizado por la gestión de claves estando centralizada, no por la aplicación siendo cuidadosa. La gestión de claves es el mecanismo. ✅ Producción.
• El gasto está controlado está garantizado por el seguimiento de costos estando implementado y visible, no por el equipo siendo disciplinado. El seguimiento de costos es el mecanismo. ✅ Producción.
• El modelo correcto se elige por petición está garantizado por la regla de enrutamiento estando implementada en el gateway, no por la aplicación hardcodeando el modelo. El enrutamiento de modelos es el mecanismo. ✅ Producción.
• La aplicación habla el formato del SDK elegido está garantizado por el gateway traduciendo en la frontera, no por la aplicación conformando al formato de cada proveedor. La traducción de formato es el mecanismo. ✅ Producción.
• Las paralelas transversales a los puertos hexagonales basados en traits (puerto estable es intercambiabilidad), ensemble del Oracle (failover multi-fuente es disponibilidad), soberanía del Eye Key (separación de credenciales es soberanía), ensemble con entropía estampada (medición subproducto gratis es señal de estado honesto), «the space is the router» (enrutamiento antes de respuesta es decisión-en-la-frontera) y frontera Zod-en-runtime (parsing explícito en frontera es interpretación correcta) son solo estructurales — mercados diferentes, mismas formas de mecanismo. ⚠️ Parcial.
• La propia configuración LLM de Everythink es solo OpenAI-compatible (un protocolo como puerto, cualquier proveedor compatible como adaptador) — mismo patrón de puerto hexagonal a alcance más estrecho; no una afirmación de correr la comparación de seis gateways. ⚠️ Parcial.

Sources

• LLM API Gateway Guide: Choose the Right One (2025), Ofox, publicado el 20 de marzo de 2026. https://ofox.ai/blog/why-llm-api-gateway-how-to-choose-2026/ (recuperado el 2026-08-23).
• Arquitectura de la plataforma Everythink: HAI Engine en producción desde 2016; Theorem 3 (una propiedad está garantizada exactamente cuando su mecanismo está implementado y midiendo); topología «the space is the router» (red → comunidad → sala); World Monitor (geo-señales enrutadas por prefijo de geohash, pasarela multi-fuente con auto-desactivación por fuente, los clientes leen el caché no los upstreams); normalización del ensemble del Oracle con entropía en nats estampada en cada merge; Sisters tipadas (analyst, contrarian, disruptor, historian, institutionalist) cargadas en runtime desde archivos TOML; ports hexagonales basados en traits con adaptadores intercambiables (Arc<dyn Trait> en el AppState); wire types de Zod definidos una vez en @everythink/types, parseados en la frontera de red, payload malo → ApiError tipado; soberanía del Eye Key (HMAC y huella registrados, el texto plano nunca toca el disco, la clave del usuario es la frontera de límite de tasa); proveedores LLM solo OpenAI-compatible vía async-openai (un protocolo como puerto, cualquier proveedor compatible como adaptador, sin dependencia directa del SDK de Anthropic).