Cómo elegir un gateway de AI Coding: OmniRoute, 9Router, OpenRouter y Ollama local

Guía práctica para elegir un gateway de AI Coding para Codex, Claude Code, Cursor y Agents locales: comparación de OmniRoute, 9Router, OpenRouter y Ollama por coste, estabilidad, privacidad e integración.

Después de usar herramientas de AI Coding durante un tiempo, los puntos de entrada de modelos se vuelven confusos. Codex puede usar el endpoint oficial. Claude Code puede pasar por Anthropic. Cursor tiene su propia configuración de modelos. Las herramientas locales pueden querer Ollama. Algunas tareas deberían usar modelos baratos. Otras necesitan modelos fuertes.

Entonces aparece una pregunta: ¿conviene añadir un gateway de AI Coding? El valor de un gateway no es tener “otra herramienta más”. Su valor real es gestionar entradas de modelos, coste, fallback, límites, auditoría y compatibilidad local.

OmniRoute se parece a un router multimodelo local o self-hosted. 9Router se enfoca más en cambiar Provider para herramientas como Claude Code y Codex. OpenRouter es una plataforma cloud de agregación de modelos. Ollama es una entrada de modelos locales, no un gateway cloud tradicional.

Resumen de Selección

Si quieres unificar varios proveedores cloud, mira primero OpenRouter u OmniRoute. Si principalmente cambias configuración local alrededor de Claude Code y Codex, mira primero 9Router. Si quieres bajo coste, privacidad local y experimentos offline, mira primero Ollama. Si quieres self-hosting, varios Provider, fallback automático y más control, mira primero OmniRoute.

Si todavía no tienes un flujo estable de AI Coding, no corras a añadir un gateway. Primero estabiliza un flujo de un solo modelo con Codex o Claude Code. Luego usa el gateway para resolver coste y cambios de proveedor.

Cuatro Opciones en una Tabla

Opción Posicionamiento Ideal para No ideal para
OmniRoute Gateway AI API self-hosted Personas con varias cuentas, modelos y necesidades de fallback Quienes no quieren mantener un servicio
9Router Configuración de rutas para herramientas de AI Coding Usuarios de Codex, Claude Code y cambio de Provider Quienes solo necesitan chat normal
OpenRouter Endpoint cloud de agregación de modelos Quienes quieren acceso rápido a muchos modelos Equipos con privacidad y cumplimiento estrictos
Ollama Runtime local de modelos Experimentos locales, privacidad, tareas baratas Trabajos que requieren el modelo más fuerte

Cuanto más simple sea la tarea, menos conviene añadir otra capa. Cuantas más fuentes de modelos tengas, más sentido tiene un gateway.

Primero Pregunta Por Qué lo Necesitas

Motivos comunes:

  • Los modelos son caros.
  • Un solo modelo tiene rate limits.
  • La configuración está dispersa entre herramientas.
  • Quieres cambiar modelos automáticamente por tarea.
  • Necesitas fallback local.
  • Necesitas registrar peticiones y costes.

Si ejecutas Agents muchas veces al día, el gateway empieza a tener valor.

Cuándo No Añadir un Gateway

  • Aún no sabes qué Agent usas principalmente.
  • No has medido coste de tokens.
  • No has encontrado rate limits.
  • No necesitas varios modelos.
  • No tienes tiempo para mantener un servicio local.
  • Tus tareas incluyen datos sensibles pero no tienes plan de auditoría.

Cuando una respuesta falle, no sabrás si el problema viene del modelo, el router, la Key o la herramienta cliente.

OmniRoute: Rutas Multimodelo y Self-Hosting

OmniRoute encaja con quien quiere poner varios Provider detrás de una sola entrada. Normalmente expone un endpoint compatible con OpenAI mediante un servicio local o remoto. El gateway elige modelos upstream, gestiona fallback, administra Keys y aplica estrategia.

Si ya viste la instalación, lee tutorial de OmniRoute. Para VPS, lee desplegar OmniRoute en VPS remoto.

OmniRoute Encaja Para

  • Dar una API unificada a varias herramientas de coding.
  • Combinar cuota gratis, modelos baratos y modelos fuertes.
  • Configurar fallback para peticiones fallidas.
  • Controlar Provider Keys localmente.
  • Crear una entrada interna de modelos para el equipo.
  • Medir uso real por modelo.

El Precio de OmniRoute

Es una capa de servicio. Un servicio necesita ejecución, actualizaciones, copias y monitorización. Si lo despliegas en un VPS remoto, también necesitas HTTPS, control de acceso, firewall y logs. Si todo el equipo lo usa, se vuelve una ruta crítica.

Por eso OmniRoute encaja mejor con necesidades continuas. No es ideal para probar un modelo de forma temporal.

9Router: Cambio de Configuración para Herramientas de Coding

9Router se parece más a una capa de rutas y configuración para herramientas de AI Coding. Su objetivo no es reemplazar todas las plataformas de modelos. Encaja mejor con el problema de “hoy uso Claude, mañana Codex y pasado mañana un endpoint local compatible con OpenAI”.

Si tu necesidad principal es cambiar entre Claude Code, Codex, MCP y endpoints locales compatibles con OpenAI, la intención de búsqueda de 9Router es clara. El sitio ya tiene dos tutoriales relacionados:

9Router Encaja Para

  • Gestionar el API Base URL de Claude Code.
  • Cambiar Codex o endpoints compatibles.
  • Gestionar configuración multi-Provider.
  • Reducir edición manual de archivos de configuración.
  • Depurar rutas de modelo que no se aplican.
  • Ser la capa de configuración de un entorno personal.

Límites de 9Router

No es un optimizador universal de coste. Tampoco garantiza calidad del modelo. Resuelve entrada y configuración.

Si el modelo upstream es lento, caro o inestable, 9Router puede ayudarte a cambiar, pero no hace más fuerte al modelo. Si necesitas fallback automático complejo, entrada compartida de equipo o auditoría centralizada, quizá necesites OmniRoute.

OpenRouter: Acceso Rápido a Muchos Modelos Cloud

La ventaja de OpenRouter es la velocidad. No mantienes tú mismo muchas cuentas de Provider. Una plataforma conecta con muchos modelos. Para desarrolladores, suele usarse como endpoint compatible con OpenAI. Muchos Agents, herramientas de chat, scripts y prototipos conectan rápido.

OpenRouter Encaja Para

  • Probar modelos diferentes rápidamente.
  • Crear prototipos.
  • Dar a pequeñas herramientas acceso a varios modelos cloud.
  • Evitar registrarse en muchas plataformas.
  • Gestionar algunas llamadas con una factura unificada.

Límites de OpenRouter

Es una capa cloud intermedia. El contenido de las peticiones pasa por una plataforma de terceros. La disponibilidad, rate limits, precio y ventana de contexto cambian por modelo.

Si tu código contiene lógica sensible, datos de clientes o contexto de repos privados, revisa privacidad y cumplimiento primero. Para experimentos personales es cómodo. Para producción empresarial, conviene más cautela.

Ollama: No Es Gateway, Pero Suele Ser Fallback Local

Ollama tiene otro papel. Principalmente ejecuta modelos en local. Puedes exponerlo como endpoint compatible y dejar que Codex, Claude Code u otras herramientas lo llamen. Pero no equivale a un gateway de modelos cloud. Se parece más a un servicio local de modelos.

Si quieres conectar un modelo local con Codex, lee usar una API de LLM local con Codex. Si Codex falla al conectar con Ollama, lee errores comunes de Codex con Ollama.

Ollama Encaja Para

  • Borradores privados.
  • Explicación de código de bajo riesgo.
  • Generación de scripts simples.
  • Experimentos de base de conocimiento local.
  • Demos offline.
  • Tareas batch de bajo coste.

Ollama No Encaja Para

  • Refactors difíciles entre muchos archivos.
  • Revisiones de seguridad complejas.
  • Decisiones de producción que requieren alta precisión.
  • Repos de negocio con contexto muy largo.
  • Tareas que necesitan el modelo más reciente.

Los modelos locales ganan en coste y privacidad. Sus límites son capacidad, VRAM y mantenimiento. Con GPUs de consumo, también considera cuantización, longitud de contexto y concurrencia.

Cómo Comparar Coste

El coste no es solo el precio unitario. El coste real de AI Coding tiene cinco partes:

  • Tokens de entrada.
  • Tokens de salida.
  • Reintentos fallidos.
  • Escaneo de contexto.
  • Tiempo humano de depuración.

Un modelo barato que falla muchas veces puede costar más. Un modelo fuerte que termina a la primera puede ser más barato.

Por eso optimizar coste con gateway no significa elegir siempre el precio mínimo. Lo razonable es dividir por tarea.

Tarea Estrategia recomendada
Editar README Modelo barato o local
Revisar errores de configuración Modelo medio
Bug entre archivos Modelo fuerte
Code review Modelo fuerte + grafo
Traducción batch Modelo barato y estable
Borrador privado Ollama local
Tarea Agent larga Modelo fuerte primero, fallback si falla

Cómo Comparar Estabilidad

La estabilidad depende de cuatro cosas:

  • Si el modelo upstream es estable.
  • Si el gateway es estable.
  • Si la configuración es trazable.
  • Si existe fallback cuando falla.

OpenRouter evita mantenimiento. Pero dependes de su disponibilidad. OmniRoute es controlable. Pero mantienes el servicio. 9Router está cerca de la configuración de herramientas de coding. Pero es más una capa personal o de pequeño equipo. Ollama es controlable en local. Pero la capacidad del modelo y el hardware son el techo.

Privacidad y Seguridad

Si el código es sensible, pregunta primero:

  • ¿Por dónde pasa la petición?
  • ¿Dónde se guardan los logs?
  • ¿Quién puede ver Provider Keys?

OpenRouter es cómodo, pero las peticiones pasan por una plataforma cloud de agregación. OmniRoute self-hosted es controlable, pero un mal despliegue también expone la entrada. 9Router debe proteger archivos locales de configuración. Ollama tiene la mejor privacidad local, pero no expongas el servicio a internet.

Lista Mínima de Seguridad

  • No escribas API Keys en el repo.
  • No expongas puertos del gateway a internet.
  • Gateways remotos deben usar autenticación y HTTPS.
  • Los logs no deben guardar Prompts completos.
  • Las Keys compartidas de equipo necesitan cuotas.
  • Servicios locales solo deben escuchar en 127.0.0.1.
  • No envíes contexto de producción a modelos desconocidos sin cuidado.
  • Mantén revisión humana para tareas importantes.

Cómo Conectar Codex y Claude Code

La mayoría de gateways ofrecen un endpoint compatible con OpenAI. Normalmente debes configurar:

base_url. model.

Algunas herramientas también requieren api_key. Conceptualmente:

1
client -> http://localhost:PORT/v1 -> gateway -> upstream model

O:

1
client -> cloud router endpoint -> selected model

No mezcles Provider Key, gateway Key y nombre de modelo. Muchos errores vienen de ahí.

Haz Primero una Prueba Mínima

No empieces con Codex. Primero prueba el gateway con una petición simple:

1
curl http://localhost:PORT/v1/models

Confirma que devuelve la lista de modelos y luego conecta el Agent. Así la depuración es más clara.

Ideas de Configuración por Herramienta

Codex

Codex funciona mejor con un workspace estable y permisos claros. Si lo conectas a un gateway, primero comprueba que el endpoint compatible con OpenAI funciona. Luego confirma nombre del modelo, base URL, API Key y límite de contexto.

No empieces con una cadena compleja de fallback. Primero haz que un modelo lea archivos, edite archivos, ejecute comandos, reporte diff y explique fallos de tests de forma estable. Después usa el gateway para optimizar coste.

Claude Code

Los usuarios de Claude Code suelen encontrar problemas de cambio de configuración. Si solo cambias Provider, 9Router encaja mejor. Si quieres conectar Claude Code a una entrada unificada de equipo, mira OmniRoute u OpenRouter. Si quieres usar modelos locales, acepta primero la diferencia de capacidad. Los modelos locales sirven para explicación, borradores y tareas de bajo riesgo. No son ideales para refactors complejos directos.

Cursor

La ventaja de Cursor está en la interacción dentro del IDE. Si solo escribes código en Cursor, quizá no necesitas un gateway separado. Si quieres que Cursor, Codex y Claude Code usen la misma entrada de modelos, el gateway tiene valor. Entonces la clave no es la configuración de Cursor, sino nombres de modelo y logs unificados.

Agents Propios

Los Agents propios son el mejor caso para gateways. Puedes controlar formato de petición, reintentos, logs y selección de modelo. Puedes dividir tareas en borradores, explicación de código, edición de un archivo, edición entre archivos, resumen de revisión, documentación y traducción batch. Cada tarea puede ir a un modelo distinto. Ahí es donde un gateway realmente ahorra coste.

Diez Preguntas Antes de Uso Largo

Antes de convertir un gateway en entrada permanente, responde:

  • ¿Quién mantiene la configuración?
  • ¿Quién puede ver API Keys?
  • ¿Quién puede cambiar rutas de modelos?
  • ¿Cuánto tiempo se conservan los logs?
  • ¿Se registran Prompts completos?
  • ¿Hay cuota por usuario?
  • ¿Hay cuota de equipo?
  • ¿Hay fallback?
  • ¿Se puede volver rápido a endpoints oficiales?
  • ¿Se pueden exportar datos de coste?

Si no hay respuestas, no pongas el gateway en una ruta crítica de equipo. El uso personal puede ser más ligero. El uso de equipo debe ser más estable.

Observabilidad del Gateway

No basta con ver si responde. Un gateway debería observar llamadas, coste y calidad.

Las métricas de llamada incluyen número de peticiones, tokens de entrada, tokens de salida, latencia media, latencia P95, tasa de fallos, reintentos, 429, 401 y distribución de modelos upstream. Las métricas de coste incluyen coste diario, coste por tarea, coste por modelo, coste de reintentos, coste de contexto largo, coste batch, electricidad de modelo local y depreciación de hardware. Las métricas de calidad incluyen tasa de éxito a la primera, retrabajo humano, tests aprobados, revisión de código aprobada, rondas de corrección y fallos por falta de capacidad del modelo.

Un usuario personal puede registrar una semana en una tabla. Un equipo puede añadir monitorización después.

Errores Comunes de Configuración

Usar la Upstream Key Como Gateway Key

Muchos gateways tienen Provider Key y clave de acceso de cliente. No son lo mismo. Provider Key accede al proveedor del modelo. La clave de cliente accede a tu gateway. Mezclarlas suele producir 401.

Escribir Mal el Nombre del Modelo

Los nombres de modelos pueden variar por plataforma. El mismo modelo puede tener alias distintos en routers distintos. Consulta /v1/models primero. Luego configura el Agent. No lo rellenes de memoria.

Exponer Puertos Locales a Internet

Ollama, OmniRoute o endpoints compatibles locales deberían ser solo locales por defecto. Si necesitas acceso remoto, añade autenticación, HTTPS y firewall. Si no, entregas tu entrada de modelos a cualquiera.

Mandar Todo al Modelo Más Barato

Los modelos baratos sirven para tareas simples. Las tareas complejas pueden fallar y reintentar hasta borrar el ahorro. Mejor enrutar por tipo de tarea, no por precio unitario mínimo.

Escenarios de Selección

Un desarrollador individual puede mantener endpoints oficiales de Codex y Claude Code, Ollama local como fallback y añadir 9Router si el cambio se vuelve frecuente. Un usuario intensivo de Agents puede usar OmniRoute u OpenRouter y luego 9Router para gestionar la configuración local. Un equipo pequeño debería tener entrada unificada, permisos individuales, logs desensibilizados, allowlist de modelos, límites de coste y revisión humana de PR. Un entorno de código privado encaja mejor con Ollama local, OmniRoute privado y reglas estrictas de salida. No envíes repos sensibles a capas públicas intermedias sin necesidad.

Ruta de Migración Recomendada

Paso uno: conserva endpoints oficiales. Paso dos: conecta Ollama para tareas de bajo riesgo. Paso tres: mide una semana de uso de modelos. Paso cuatro: si cambias Provider con frecuencia, añade 9Router. Paso cinco: si varias herramientas necesitan una entrada común, añade OmniRoute u OpenRouter. Paso seis: si lo comparte el equipo, añade autenticación, logs y límites de coste. Paso siete: deja tareas complejas en modelos fuertes. Paso ocho: envía tareas batch a modelos baratos o locales.

No montes todo un stack de gateway antes de encontrar el caso de uso.

Cuándo Mantenerlo Simple

Si usas un Agent solo unas veces por semana, mantén endpoints oficiales. Si usas un solo modelo, mantén el endpoint oficial. Si no tienes rate limits, mantén el endpoint oficial. Si no tienes presión de coste, mantén el endpoint oficial. Si no quieres mantener un servicio, usa endpoints oficiales u OpenRouter. Si solo quieres probar modelos locales, usa Ollama.

Menos herramientas significa depurar con más facilidad.

Ideas para Artículos Futuros

Este tema puede dividirse en páginas de búsqueda más estrechas:

  • Cómo configurar Codex con OpenRouter.
  • Errores comunes de Claude Code con 9Router.
  • Comparación de coste entre OmniRoute y OpenRouter.
  • Qué subtareas de Codex encajan con Ollama.
  • Cómo escribir reglas de routing para modelos de AI Coding.
  • Cómo limitar cuotas de AI API Key compartidas por equipo.
  • Cómo desensibilizar logs de un gateway local.
  • Si el fallback automático afecta la calidad del código.

Cierre: Mira la Tarea Antes que la Entrada

¿Quieres probar muchos modelos rápido? Elige OpenRouter. ¿Quieres gestionar configuración de herramientas de AI Coding? Elige 9Router. ¿Quieres entrada unificada self-hosted y fallback? Elige OmniRoute. ¿Quieres privacidad local y experimentos baratos? Elige Ollama.

La clave no es qué nombre está más caliente. La clave es si tus tareas necesitan varios modelos, fallback, auditoría y control de coste. Si la respuesta es no, no añadas gateway todavía. Si la respuesta es sí, empieza por la entrada mínima y no conectes todas las herramientas a la vez.