¿Es viable construir en producción solo con IA gratis? Lo que aprendimos probando OmniRoute con un equipo real de agentes
Es viable, pero no como sustituto total de un presupuesto de inferencia: funciona como una capa de coste casi cero para roles de bajo riesgo, combinada con un colchón de pago mínimo como última red de seguridad, monitorización activa y expectativas realistas sobre fiabilidad.
Casi cualquier equipo técnico se ha hecho la misma pregunta al mirar la factura de inferencia: ¿podemos evitarla, al menos durante un tiempo, usando proveedores de IA gratuitos? Hay decenas de artículos que responden que sí, con una lista de “13 APIs de IA gratis” y una tabla de límites sacada de la documentación de cada proveedor. Ninguno de esos artículos ha puesto esa lista a trabajar de verdad.
Nosotros sí. Durante el 24 y 25 de julio de 2026 pusimos un gateway de modelos de IA (OmniRoute) delante de un equipo real de agentes en producción y le pedimos que funcionara exclusivamente con proveedores gratuitos: OpenRouter, NVIDIA NIM, Google AI Studio (Gemini) y OpenCode Go, con pruebas descartadas de Groq, Mistral y Cerebras. No fue una llamada de prueba aislada ni un benchmark de fin de semana. Fue tráfico real, con logs, fechas y cifras concretas. Esto es lo que encontramos, incluyendo lo que falló.
El experimento: qué se puso a prueba y por qué
El sistema que sirvió de banco de pruebas es un equipo real de agentes de IA —roles de dirección de producto, arquitectura, ingeniería, QA, release y un analista de dominio— orquestados con un framework de gestión de agentes, trabajando sobre tareas reales de un producto de software en construcción. Por petición explícita del cliente, no revelamos el proyecto, el producto ni el sector: lo que importa aquí es la capa de infraestructura de IA, no el negocio que corría encima.
Esa distinción es relevante porque cambia por completo lo que se está probando. Un chat de prueba manual hace una llamada, espera una respuesta y ya está. Un equipo de agentes concurrentes genera picos de tráfico impredecibles, repite llamadas con los mismos parámetros muchas veces por minuto y no tiene a nadie mirando cada respuesta en tiempo real. Si un proveedor gratuito falla de una forma que solo aparece bajo esas condiciones, ninguna prueba manual lo va a descubrir antes de que sea un problema en producción.
Qué es un gateway de modelos de IA (y por qué no basta con una API key)
Un gateway o router de modelos de IA es una capa que se sitúa entre tu aplicación y los proveedores reales de inferencia. En lugar de que cada parte de tu sistema llame directamente a la API de OpenRouter, de NVIDIA o de Google, todas las llamadas pasan por el gateway, que decide a qué proveedor enviar cada petición y qué hacer si ese proveedor falla.
En este experimento usamos OmniRoute, una herramienta local (CLI más un servidor en 127.0.0.1) que expone un endpoint compatible con la API de OpenAI y de Anthropic hacia el resto del sistema, y por detrás enruta cada petición hacia proveedores reales según reglas configurables que la herramienta llama “combos”. Lo mencionamos porque es la pieza real que usamos, no porque exista ningún acuerdo comercial con ella: el artículo trata igual sus aciertos que sus propios errores de traducción entre APIs, que detallamos más abajo.
Sin un gateway, cada vez que un proveedor gratuito cae o cambia su cuota, alguien tiene que entrar a mano en cada agente y cambiar credenciales o configuración. Con un gateway, es una única actualización de combo la que redirige a todo el sistema. Eso resuelve un problema operativo real, pero no resuelve el problema de fondo: la fiabilidad de los proveedores gratuitos en sí. Un gateway no elimina ese riesgo, lo hace gestionable.
Un detalle que conviene conocer: los combos de OmniRoute usan una estrategia de prioridad (intentar el proveedor 1, si falla pasar al 2, y así sucesivamente) que no es 100% determinista. Verificamos con omniroute simulate --combo <nombre> --explain que, incluso con todos los proveedores sanos, hay aproximadamente un 85% de probabilidad de que la petición vaya al proveedor primario — un factor a tener en cuenta antes de diseñar alertas basadas en “qué proveedor debería estar respondiendo ahora mismo”.
Este mismo problema —conectar un sistema de IA con piezas externas de forma controlada— tiene un pariente conceptual en qué es un MCP: ambos son capas de infraestructura que median entre una IA y el mundo real, aunque resuelven necesidades distintas.
Los proveedores probados, uno por uno, con datos reales
Esta es la parte central del experimento. Cada fila de la tabla es una llamada real de producción, no una prueba de la documentación oficial.
| Proveedor | Resultado | Evidencia real |
|---|---|---|
| OpenRouter (modelos `:free`) | Funciona, pero con cuota diaria dura | 1.509 llamadas afectadas en un solo día por agotamiento de la cuota diaria de modelos gratuitos (`free-models-per-day-high-balance`), sin posibilidad de reintento hasta el reset |
| NVIDIA NIM | Funciona en formato OpenAI; incompatible en formato Anthropic | `400 Unsupported parameter: prompt_cache_key` de forma consistente al enrutar peticiones `/v1/messages` — un bug de traducción del gateway, no del proveedor en sí |
| Google AI Studio (Gemini) | Funciona solo con la generación de modelo vigente | Los modelos "legacy" (`gemini-2.5-flash`, `gemini-2.0-flash`) devuelven `404: no longer available to new users` en cuentas nuevas; hace falta usar la generación actual |
| OpenCode Go (pool `-free` compartido) | Prácticamente inutilizable bajo carga real | 4.083 llamadas en un día, 4.078 en `429` — un 99,9% de fallo, 0 éxitos confirmados |
| OpenCode Go (pool de suscripción de pago) | Funciona de forma consistente | 15+ llamadas reales consecutivas en `200 OK` (~1,3–1,5 s) mientras los proveedores gratuitos estaban en `429` a la vez |
| Groq (`llama-3.3-70b-versatile`, `llama-3.1-8b-instant`) | Falso positivo: funciona en prueba manual, falla siempre en tráfico real | Prueba manual en `200 OK`; tráfico real de agentes devolvía `400: property 'prompt_cache_key' is unsupported` el 100% de las veces |
| Mistral (`mistral-small-latest`, `codestral-latest`) | Mismo patrón de falso positivo que Groq | Prueba manual en `200 OK` (~420–440 ms); tráfico real devolvía `400: reasoning_effort is not enabled/not supported for this model` el 100% de las veces |
| Cerebras | Descartado en la primera llamada real | La cuenta pasó a `credits_exhausted` (404 sin credenciales activas) en los tres modelos disponibles, sin haber hecho ninguna llamada facturable previa |
Estas cifras corresponden a un día concreto de tráfico (24–25 de julio de 2026) y a la política de free tier vigente en esa fecha. Los límites gratuitos de estos proveedores cambian con frecuencia —lo confirma la propia documentación de OpenRouter sobre rate limits—, así que conviene reverificarlos antes de tomar una decisión de arquitectura, no asumir que seguirán igual.
Ningún proveedor de esta tabla es “malo” en general. Groq y Mistral no fallaron por ser proveedores poco fiables; fallaron por una incompatibilidad puntual de parámetros con este gateway concreto, algo que cualquier integración nueva puede tener. El punto no es señalar a un proveedor, es mostrar que ninguno se puede dar por bueno sin probarlo con el tráfico real que de verdad vas a enviarle.
El falso positivo que casi pasa desapercibido
Este es, para nosotros, el hallazgo más importante del experimento, y no es el que esperábamos encontrar.
Con Groq y Mistral activos como dos de los cuatro proveedores del fallback, cada turno del sistema agotaba automáticamente esos dos proveedores rotos antes de llegar al único que a veces respondía. ¿Por qué no se detectó de inmediato? Porque una prueba manual simple (omniroute chat, una pregunta suelta) devolvía 200 OK sin problema en ambos proveedores. La razón es que esa prueba manual no incluía los mismos parámetros que el tráfico real del sistema de agentes: en concreto, prompt_cache_key y reasoning_effort. Groq y Mistral rechazaban esos parámetros con un 400, pero solo cuando estaban presentes — y una prueba manual sencilla nunca los mandaba.
El resultado en producción fue peor que un fallo visible. La latencia acumulada de esos dos intentos fallidos antes de llegar al tercer proveedor hacía que el cliente cerrara la conexión por timeout. El sistema “completaba” ejecuciones sin haber hecho ningún trabajo real, sin ningún error visible a simple vista. Solo se detectó cruzando los logs de llamadas reales del gateway —no una prueba manual— contra el comportamiento observado en el producto.
La lección no es “no confíes en Groq ni en Mistral”. Es que verificar un proveedor con una llamada de prueba simple da falsos positivos si esa llamada no reproduce los mismos parámetros que el tráfico real. Si tu prueba de validación no manda lo mismo que manda tu sistema en producción, no está validando nada.
Cuando todos los proveedores gratis caen a la vez
El segundo hallazgo importante es de naturaleza distinta: no es un bug de compatibilidad, es un riesgo de concentración.
En un momento del experimento, los tres proveedores del fallback principal —OpenRouter, NVIDIA y OpenCode Go— cayeron simultáneamente: coincidieron la cuota diaria agotada, la saturación del servicio y el pool -free compartido sin capacidad disponible, todo a la vez. El proceso que debía reintentar automáticamente quedó “en ejecución” de cara al exterior, pero con el proceso real que hacía el trabajo ya muerto por detrás.
Nadie lo detectó durante aproximadamente dos horas. El sistema no estaba caído de forma visible; simplemente no avanzaba. No hubo una alerta automática que lo señalara — se detectó por auditoría manual, revisando por qué no había progreso reciente.
Este es el riesgo más caro de operar solo con proveedores gratuitos: el problema real no es que un proveedor gratuito falle, es que falle en silencio y nadie se entere durante horas. Un fallo visible se soluciona rápido. Un fallo silencioso se descubre tarde, y para entonces ya ha costado tiempo, trabajo perdido o ambas cosas.
La configuración que sí funcionó
Después de este proceso llegamos a una configuración estable, que es la respuesta práctica a “entonces, ¿cómo se hace bien?”:
- Repartir el primer intento entre dos proveedores gratuitos distintos según el rol del agente, para no concentrar todo el tráfico en uno solo.
- Añadir un tercer proveedor gratuito de refuerzo.
- Como último recurso obligatorio, un proveedor de pago con coste marginal casi nulo — en este caso, el pool de una suscripción ya contratada, no el pool gratuito compartido del mismo proveedor.
Esta combinación resolvió el problema real observado en el experimento: los proveedores gratuitos solos, sin ningún colchón de pago, podían dejar el sistema completamente parado cuando coincidían varios picos de cuota a la vez — exactamente lo que pasó en el incidente de las dos horas. El propio blog oficial de OpenRouter sobre APIs de IA gratuitas recomienda esta misma idea como buena práctica: combinar fallback entre proveedores con un colchón de crédito de pago, porque los tiers gratuitos no vienen con SLA. Nuestro experimento no descubre esa recomendación; la confirma con un incidente real y cuantificado.
Es la misma lógica que aplicamos al hablar de aprovechar varios proyectos gratuitos de Supabase: los tiers gratuitos son una herramienta legítima y utilizable, siempre que se usen con criterio sobre sus límites reales, no como si no existieran.
Checklist: ¿tu caso puede vivir solo de IA gratis?
Antes de replicar esta configuración, conviene evaluar con honestidad estos puntos:
| Pregunta | Si la respuesta es “sí” | Si la respuesta es “no” |
|---|---|---|
| ¿Puedes tolerar que una tarea falle o se retrase varias veces al día sin que sea crítico? | Un esquema solo-gratis puede tener sentido para esa tarea | Necesitas al menos un colchón de pago como última red |
| ¿Tu tráfico es de un solo agente/llamada aislada, o de varios agentes concurrentes? | Un proveedor único gratuito puede aguantar | La concurrencia agota cuotas mucho más rápido; necesitas fallback real |
| ¿Validaste cada proveedor con los mismos parámetros exactos que usa tu tráfico real (cache, reasoning, etc.)? | Puedes confiar razonablemente en esa validación | Tu prueba puede estar dando un falso positivo, como en Groq/Mistral |
| ¿Tienes monitorización activa que detecte "no hay progreso" y no solo "hay un error 500"? | Reduces el riesgo de un fallo silencioso | Un fallo como el de las dos horas puede pasar sin que nadie se entere |
| ¿Puedes asumir un pequeño coste mensual como colchón de última instancia? | Tu configuración puede quedar cerca de la nuestra | El escenario "todo cae a la vez" te deja sin salida |
Si la mayoría de tus respuestas apuntan a la columna de riesgo, probablemente tu caso necesita algo más que una lista de APIs gratis: necesita una decisión de arquitectura.
Conclusión: la respuesta honesta
¿Es viable construir en producción solo con IA gratis? Con la evidencia de este experimento, la respuesta no es un sí ni un no categórico: es viable como capa de coste casi cero para roles de bajo riesgo, nunca como sustituto total de un presupuesto de inferencia. Los proveedores gratuitos que probamos son reales y utilizables, pero se comportan como infraestructura con fallos esperables —cuotas, 429, incompatibilidades de parámetros—, no como una API estable. La diferencia entre “funciona en mi prueba” y “funciona en producción” es la carga real y la concurrencia, y solo se descubre probando con ellas.
Si estás evaluando si tu producto o tu equipo de agentes puede operar sin presupuesto de inferencia, o si ya combinas varios proveedores gratuitos y quieres saber dónde va a fallar eso bajo carga real, hablemos de tu caso. Y si todavía no sabes si conviene construir con IA gratuita o reservar presupuesto real, podemos ayudarte a decidirlo antes de comprometer arquitectura.