Le agregué más de 100 modelos de IA a mi app usando OpenRouter y Antigravity

Modal 'Configuración de IA' mostrando campo de API Key enmascarado y lista de modelos de imágenes

Muchas aplicaciones con inteligencia artificial terminan atadas a un solo modelo. Cuando aparece algo mejor, más barato o más rápido, cambiar implica tocar backend, probar todo de nuevo y asumir riesgos. Aquí explico un patrón práctico para liberar tu app: permitir que cada usuario use su propia API key y elija entre cientos de modelos dinámicamente. La integración central será OpenRouter y el entorno de desarrollo será Antigravity. Te muestro la arquitectura, la UX clave, cómo cachear el catálogo de modelos, ejemplos de prompts y código de referencia para que lo adaptes a tu proyecto.

Tabla de contenidos

🔧 El problema: apps atadas a un único modelo

Muchas apps empiezan con un proveedor y un modelo: «usamos GPT-X o DALL·E para todo». Eso funciona al principio, pero se vuelve un problema cuando:

  • Surge un modelo mejor: migrar implica cambios backend, despliegue y nuevos tests.
  • Necesitas ajustar costos: modelos rápidos pueden ser caros, modelos económicos pueden servir para tareas menos críticas.
  • Regulaciones o privacidad: algunos usuarios prefieren usar su propia API key (Bring Your Own Key) por control y facturación.

La solución consiste en separar el cliente de la decisión del modelo: que la app soporte múltiples modelos y permita al usuario elegir qué modelo usar para cada tipo de tarea (texto, imágenes, asistentes, etc.). Esto reduce fricción y da flexibilidad sin reescribir la arquitectura.

🧭 Arquitectura propuesta: BYOK + catálogo dinámico

La arquitectura que recomiendo consta de tres piezas principales:

  1. Bring Your Own Key (BYOK): el usuario pega su API key desde OpenRouter (u otro proveedor compatible) en la app. Esa key se usa desde el cliente para llamar directamente a OpenRouter, o se transmite de forma segura al backend según diseño.
  2. Catálogo dinámico de modelos: la app obtiene la lista de modelos disponibles a través de la API de OpenRouter y la muestra al usuario (nombre, costo, context window, arquitectura, tipo imagen/texto, etiqueta si es gratis, etc.).
  3. Preferencias por tarea: el usuario puede asignar un modelo por defecto para texto y otro para imágenes (o más granular: prompts específicos, asistentes, etc.). Esas preferencias se persisten en localStorage o en el backend del usuario.

Beneficios:

  • Permite comparar calidad vs costo sin desplegar cambios críticos.
  • Reduce la superficie de mantenimiento: una sola integración (OpenRouter) te da acceso a cientos de modelos.
  • Los usuarios mantienen control de su facturación si usan BYOK.

🔎 ¿Por qué OpenRouter?

OpenRouter actúa como una capa unificadora: expone múltiples modelos (alrededor de 300 en el momento del proyecto) desde distintos proveedores con una API consistente. Ventajas principales:

  • Catálogo enorme: modelos de texto e imágenes, gratuitos y de pago.
  • Metadatos útiles: precio por millón de tokens, context window, arquitectura y tags para filtrar.
  • Sencillez de integración: con una sola API puedes listar modelos y ejecutar inferencias.

Gracias a su catálogo, los usuarios pueden elegir desde modelos económicos (ej: Minimax) hasta modelos de alta calidad y costo (ej: SOPUS 4.6).

⚙️ Implementación práctica: pasos clave

1) Permitir que el usuario pegue su API key (BYOK)

Diseño mínimo: un formulario simple de configuración que almacena la API key en localStorage del navegador. Consideraciones:

  • No almacenes claves en texto plano en tu backend sin consentimiento claro.
  • Explica al usuario que la key la controla él y que su facturación quedará en su cuenta de OpenRouter.
  • Añade validaciones y feedback visual (error si la key no es válida).

2) Obtener el catálogo de modelos y cachearlo

Hacer requests a la API de OpenRouter para listar modelos cada vez que un usuario abra la configuración es ineficiente y genera latencia. En su lugar:

  • Solicita el catálogo una vez y almacénalo en localStorage con un timestamp.
  • Refresca el catálogo cada 24 horas como valor por defecto; permite refresco manual.
  • Presenta el modelo con nombre, precio por millón de tokens y context window. Destaca visualmente los modelos gratuitos.
Buscador de modelos con término 'mini' y Minimax M2.5 resaltado mostrando precio y tamaño de contexto

Ejemplo de comportamiento: si el usuario no ha puesto su API key, el catálogo no se consulta. Al ingresar la key, la app hace la primera solicitud y guarda resultados para 24 horas.

3) Filtrar por tipo: imagen vs texto

OpenRouter devuelve metadatos que permiten identificar la arquitectura del modelo (por ejemplo «image» o «text»). Aprovecha esto para filtrar automáticamente y presentar dos listas separadas: modelos aptos para texto y modelos aptos para imágenes.

4) Selector de modelos en la UI

La UI debe permitir:

  • Elegir un modelo por defecto para texto y otro para imágenes.
  • Ver precio por millón de tokens y context window para comparar capacidad y costo.
  • Ver etiqueta «gratis» u «oferta» en modelos sin costo.
  • Probar una generación rápida desde la pantalla de configuración.
Selector de modelos mostrando MiniMax M2.5 seleccionado con precio y context window

5) Persistencia de la elección

Para empezar rápido, guarda la API key y las preferencias del modelo en localStorage. A medida que tu app crezca, ofrece opción de persistir estas preferencias en el backend del usuario (con encriptación o servicios de secreto) para recuperación en otros dispositivos.

💻 Código de referencia: listar modelos y cachearlos

Este es un ejemplo simple de cómo listar modelos usando fetch y cachear en localStorage. Asume que la API de OpenRouter expone un endpoint como /models y que la key del usuario se usa en Authorization.

const OPENROUTER_MODELS_CACHE_KEY = 'openrouter_models';
const OPENROUTER_MODELS_TS_KEY = 'openrouter_models_ts';
const CACHE_TTL_MS = 24 * 60 * 60 * 1000; // 24 horas

async function fetchModels(apiKey) {
  const cached = localStorage.getItem(OPENROUTER_MODELS_CACHE_KEY);
  const cachedTs = localStorage.getItem(OPENROUTER_MODELS_TS_KEY);

  if (cached && cachedTs && (Date.now() - Number(cachedTs) < CACHE_TTL_MS)) {
    return JSON.parse(cached);
  }

  const res = await fetch('https://api.openrouter.ai/v1/models', {
    headers: {
      Authorization: `Bearer ${apiKey}`,
      'Content-Type': 'application/json'
    }
  });

  if (!res.ok) {
    throw new Error('Error al obtener modelos');
  }

  const data = await res.json();

  // Guardar cacheada
  localStorage.setItem(OPENROUTER_MODELS_CACHE_KEY, JSON.stringify(data));
  localStorage.setItem(OPENROUTER_MODELS_TS_KEY, String(Date.now()));

  return data;
}

Con este patrón tienes control sobre llamadas repetitivas y mantienes experiencia rápida. Si quieres, puedes ajustar el TTL a 1 hora o exponer un botón de «Actualizar catálogo» en la UI.

🖼️ Enrutamiento entre modelos de imagen y texto (ejemplo de petición)

Cuando un usuario genera texto o imágenes, tu lógica debe:

  1. Recuperar la API key que el usuario configuró.
  2. Determinar el modelo seleccionado para la tarea (texto o imagen).
  3. Construir la petición adecuada según el tipo de modelo y hacer la llamada a OpenRouter.
// Ejemplo simplificado de solicitud de texto
async function generateText(apiKey, modelId, prompt, maxTokens = 200) {
  const payload = {
    model: modelId,
    prompt,
    max_tokens: maxTokens
  };

  const res = await fetch('https://api.openrouter.ai/v1/completions', {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${apiKey}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify(payload)
  });

  const data = await res.json();
  return data;
}

// Ejemplo simplificado de solicitud de imagen
async function generateImage(apiKey, modelId, prompt, width, height) {
  const payload = {
    model: modelId,
    prompt,
    width,
    height
  };

  const res = await fetch('https://api.openrouter.ai/v1/images/generate', {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${apiKey}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify(payload)
  });

  const data = await res.json();
  return data;
}

Ajusta los endpoints y estructuras de payload según la documentación de OpenRouter. La idea principal es que el mismo flujo se adapta a cualquier modelo que el usuario haya escogido.

🎛️ UX y detalles prácticos que marcan la diferencia

Algunas decisiones de diseño y UX evitarán confusiones y problemas:

  • Mostrar precio y contexto: en el selector, además del nombre del modelo, muestra precio por millón de tokens y context window. Esto ayuda a comparar costo y capacidad.
  • Destacar modelos gratuitos: marca visualmente los modelos con costo cero. En mi implementación los resalté para que el usuario sepa opciones sin costo.
  • Permitir pruebas rápidas: un botón de «probar modelo» para hacer una generación pequeña ayuda a validar calidad sin generar grandes costos.
  • Indicador de estado de la API key: si la key es inválida, el catálogo no carga; ofrece un mensaje claro y enlaces para crear una key en OpenRouter.
  • Aspect ratio para imágenes: cuando generes imágenes, pasa un parámetro de aspect ratio (cuadrado, vertical, horizontal) según la vista. Así evitas resultados inesperados.
Modal de vista previa con imagen generada por IA y menú contextual sobre fondo difuminado del tablero

También tuve que ajustar estilos: asegúrate de que los mensajes se vean tanto en modo claro como oscuro. Un pequeño detalle como colores incorrectos en el banner de la API key arruina la experiencia.

✅ Ejemplo de flujo de usuario: configuración y generación

Un flujo típico que implementé y que recomiendo:

  1. Usuario abre Configuración y pega su API key de OpenRouter.
  2. La app valida la key y obtiene el catálogo de modelos (cacheado 24 horas).
  3. Usuario selecciona un modelo de texto (ej: Minimax M 2.5) y un modelo de imágenes (ej: Nano Banana 2).
  4. Las preferencias se guardan en localStorage.
  5. En la UI principal, al generar texto, la app usa la key y el modelo seleccionado para pedir la inferencia a OpenRouter.
  6. Para imágenes, la app envía prompt + aspect ratio al modelo elegido y recibe la imagen generada.
Editor de código con funciones de generación y un panel de UI de ajustes (Antigravity) mostrando la integración con OpenRouter

Con esto el usuario controla costo y calidad sin que el desarrollador tenga que tocar el backend cada vez que quiera cambiar de modelo.

💡 Consejos sobre selección de modelos y prompts

No todos los modelos son iguales. Aquí algunas recomendaciones prácticas:

  • Para prototipos y ahorro: usa modelos gratuitos o económicos para tareas no críticas (generación inicial, borradores, pruebas).
  • Para generación final o de alta calidad: elige modelos premium y permite que el usuario decida si quiere gastar más.
  • Proveer presets: ofrece presets (ej: «rápido y barato», «balance», «alta calidad») que seleccionen modelos y parámetros automáticos para usuarios que no quieran elegir manualmente.
  • Prompting consistente: para imágenes pasa parámetros como aspect ratio y estilo. Para texto, define temperature, max tokens y si necesitas instrucciones de sistema (system prompt) para consistencia.

🔐 Seguridad y privacidad con BYOK

BYOK tiene ventajas para el usuario, pero implica responsabilidades:

  • No transmitas la API key insegura: si decides enviar la key al backend, encripta y almacena según buenas prácticas. Preferible mantenerla en cliente y que las peticiones vayan desde el cliente a OpenRouter cuando el modelo lo permita.
  • Explica facturación: aclara que la facturación corre por cuenta del usuario si usa su key.
  • Rate limits: informa sobre posibles límites de la API y maneja errores de forma amigable (retry, backoff, mensajes claros).
  • Eliminar key: permite al usuario borrar su key fácilmente y revocar accesos.

📈 Estrategias de costo y control

Algunas ideas para evitar facturas sorpresivas:

  • Límite por sesión: permitir al usuario definir un límite de gasto por día o por mes e informar cuando se acerca.
  • Presets de tokens: para generación de texto ofrece opciones de longitud y muestra una estimación del costo basada en tokens.
  • Notificaciones: alerta cuando un modelo seleccionado cambia su precio (si tu app detecta cambios en el catálogo).

🧪 Pruebas y verificación

Antes de lanzar multi-modelo en producción, realizar pruebas de:

  • Compatibilidad: validar que cada modelo en la lista acepta los parámetros que tu UI envía.
  • Errores: manejar gracefully modelos que fallen o devuelvan estructura distinta.
  • Performance: medir latencia por modelo y mostrar al usuario si la respuesta será lenta.

🚀 Casos reales y aprendizajes

Implementando esto en mi clon de Tinder aprendí varias cosas:

  • Minimax funciona muy bien para prompts de texto económicos. Suele ser suficiente para descripciones y copy rápido.
  • Nano Banana 2 ofrece resultados visuales conceptuales excelentes para mockups y pruebas iniciales; pasarle aspect ratio mejora mucho la composición final.
  • Mostrar el costo y marcar modelos gratis acelera la adopción. Muchos usuarios probaron primero opciones gratuitas antes de usar modelos de pago.
  • La cache de 24 horas para los modelos fue suficiente y evitó requests repetitivos. Permití refresh manual por si el usuario quería ver nuevos modelos al instante.
Selector de modelos con 'MiniMax M2.5' seleccionado y detalles de coste/context window visibles

⚙️ Extensiones y mejoras futuras

Una vez en funcionamiento, puedes agregar:

  • Integración con backend para compartir configuraciones: almacenar preferencias del usuario en su cuenta para sincronizar entre dispositivos.
  • Presets colaborativos: crear presets de modelo+prompt recomendados por la comunidad.
  • Métricas de uso y optimización: mostrar al usuario cuánto ha gastado por modelo y sugerir alternativas más económicas.
  • Fallback automático: si un modelo falla, redirigir la petición a un modelo alternativo predefinido.

📚 Recursos y enlaces útiles

Enlaces mencionados y recursos para seguir implementando:

  • Comunidad Skool: https://www.skool.com/vibe-coding-crea-apps-con-ia-5930
  • PrimeraApp.com — herramienta exclusiva de la comunidad: PrimeraApp.com
  • Playlist sobre crear apps web con IA: https://www.youtube.com/playlist?list=PLBTuX25MUpdo9YuMzu-o9c80p1q40EBfI
  • OpenRouter: revisa su documentación para endpoints exactos y estructura de modelos.

🧾 Checklist rápido antes de lanzar

Antes de poner multi-modelo en producción, revisa:

  1. Validación y manejo de la API key del usuario.
  2. Cache del catálogo con TTL y botón de refresh manual.
  3. Filtrado claro de modelos por tipo (texto/imágenes).
  4. Método para probar modelos sin incurrir en grandes costos.
  5. Visualización del precio, context window y etiquetas (gratis, recomendado).
  6. Manejo de errores y fallback por modelo.
  7. Política de privacidad y explicación sobre facturación BYOK.

📌 Conclusión

Hacer que una app soporte más de 100 modelos no es solo una cuestión técnica; es una decisión de producto que potencia flexibilidad y control para los usuarios. Usando OpenRouter como capa unificadora y adoptando BYOK puedes ofrecer libertad al usuario, optimizar costos y reducir la fragilidad del producto frente a cambios en el ecosistema de modelos.

Implementa el catálogo dinámico, cachea la información, permite seleccionar modelos por tarea y añade herramientas para comparar costo y calidad. Con esto tu app estará preparada para adaptarse rápidamente a nuevas opciones de modelos sin dolor.

🔗 Enlaces destacados

– Comunidad Skool (recursos y prompts): https://www.skool.com/vibe-coding-crea-apps-con-ia-5930
– Herramienta exclusiva de la comunidad: PrimeraApp.com
– Playlist sobre crear apps web con IA: https://www.youtube.com/playlist?list=PLBTuX25MUpdo9YuMzu-o9c80p1q40EBfI

🎯 ¿Listo para implementarlo?

Si ya tienes una app con IA, empezar con BYOK y catálogo dinámico es un cambio incremental con alto impacto. Si estás construyendo desde cero, diseñar la capa de selección de modelos desde el principio te ahorrará muchos dolores más adelante. Adapta el código de ejemplo a tu stack, prueba modelos gratuitos primero y luego ofrece recomendaciones de pago para tareas críticas.

¡Éxito construyendo una app más flexible, económica y preparada para el futuro de los modelos de IA!

Entradas relacionadas