No paran de llegar modelos de IA mejores y más baratos. El modelo que tenía sentido cuando publicaste una app puede que ya no sea la mejor opción unas semanas después. Pero si el ID de ese modelo está incrustado en una app iOS publicada o en un servidor desplegado, cada mejora se convierte en una nueva publicación. ¿Cómo puedes mantener la aplicación al día mientras los usuarios siguen con versiones antiguas? Haimaker te permite actualizar los modelos que usa tu aplicación sin volver a desplegarla. Envía haimaker/auto como ID de modelo y luego cambia el modelo por defecto o las reglas específicas de prompts en el panel.
Este problema se repite con cada lanzamiento de modelo. Los desarrolladores necesitan probar calidad, coste y capacidades frente a su carga de trabajo. Mantener la elección de modelo fuera del código desplegado les permite tomar decisiones a partir de esos resultados sin programar otra publicación de app o servidor.
Un ID de modelo fijo se queda obsoleto tras el lanzamiento
Un ID de modelo fijo hace que cada actualización de modelo dependa del proceso de publicación de la aplicación. Es asumible mientras construyes la primera versión. Después del lanzamiento, cada modelo prometedor o cambio de precio puede suponer editar código, ejecutar tests, desplegar servidores o enviar una actualización móvil. Los nuevos modelos pueden llegar entre publicaciones de la app.
En una app iOS, un ID de modelo incrustado en el cliente no puede actualizarse para los usuarios que no han instalado una actualización. Apple revisa las actualizaciones de apps antes de distribuirlas, y los usuarios pueden conservar versiones antiguas mucho después de que una nueva build esté disponible. Mover la llamada API a tu backend evita exponer una clave de proveedor en la app, pero un ID de modelo fijado en el código de ese backend sigue necesitando un cambio de configuración o un despliegue.
Un endpoint de gateway por sí solo no resuelve el problema. Si una petición especifica un modelo fijo, el cliente sigue ligado a esa elección. OpenRouter, por ejemplo, soporta modelos con nombre así como su propio enrutador openrouter/auto. Un auto-router puede mantener la elección del modelo subyacente fuera del código desplegado. Haimaker te permite ajustar la política de enrutamiento para tus propias clases de prompts después de que la aplicación se haya publicado.
¿Cómo puede una app desplegada mantenerse al día con los nuevos modelos?
Envía un ID de modelo estable desde la aplicación y mantén la política de selección en Haimaker. Un enrutador tiene un modelo por defecto para las peticiones que no coinciden con ninguna regla, y reglas que dirigen tipos específicos de prompts a otro destino. El enrutador está asignado a una clave API. Cuando cambias sus destinos, las peticiones posteriores pueden llegar a modelos diferentes aunque el cliente desplegado siga enviando haimaker/auto.
En un producto móvil, la app debe llamar a tu backend y el backend debe llamar a Haimaker. Así la clave API no queda expuesta en los dispositivos de los usuarios. Una aplicación de servidor puede usar el mismo patrón directamente: su código de petición permanece intacto mientras un operador ajusta el enrutador. La documentación de configuración muestra cómo crear un enrutador, elegir un modelo por defecto, asignar una clave API y probar peticiones.
import OpenAI from "openai";
// Run this on your backend; do not bundle the API key in a mobile app.
const client = new OpenAI({
baseURL: "https://api.haimaker.ai/v1",
apiKey: process.env.HAIMAKER_API_KEY,
});
const response = await client.chat.completions.create({
model: "haimaker/auto",
messages: [{ role: "user", content: prompt }],
});
El código anterior no necesita un nuevo nombre de modelo cuando cambia el valor por defecto. Haimaker almacena en caché las configuraciones del enrutador durante hasta 60 segundos, así que dale aproximadamente un minuto para que un cambio en el panel se propague a todas las peticiones posteriores.
Actualiza el modelo por defecto y luego enruta el trabajo más barato por separado
Cambiar el modelo por defecto actualiza la carga de trabajo general. Las reglas te permiten hacer cambios más concretos cuando un nuevo modelo es más barato o mejor para una tarea. Esa diferencia es clave: una app puede necesitar un modelo por defecto potente para la edición de textos largos mientras envía sugerencias cortas de título a un modelo de menor coste. Ambas decisiones pueden cambiar después del lanzamiento sin alterar el ID de modelo del cliente.
Imagina una app de escritura cuyo backend envía cada petición de IA a través del mismo enrutador. Un modelo recién publicado mejora sus ediciones de texto largo, así que el equipo lo prueba y cambia el modelo por defecto del enrutador. Más adelante, un modelo más barato gestiona las sugerencias de título lo bastante bien. El equipo añade una regla con ejemplos como “Sugiere cinco títulos cortos para esta nota” y “Dale a este borrador un encabezado conciso”, y la asigna al modelo más barato. Los usuarios con versiones antiguas de la app reciben ambos cambios a través del backend existente.
Para las reglas basadas en ejemplos, usa de 3 a 10 prompts representativos por tarea. Una coincidencia enruta la petición al destino de la regla; las peticiones sin coincidencia usan el modelo por defecto. Las comprobaciones de capacidad evitan que una regla envíe una petición de visión, uso de herramientas o salida estructurada a un modelo que no puede gestionarla. Los logs de enrutamiento muestran el modelo resuelto y la regla que lo seleccionó. Para conocer el funcionamiento de la coincidencia y el fallback, consulta nuestra guía de enrutamiento y la guía de enrutamiento por coste.
¿Qué cambia esto para un equipo después del lanzamiento?
El beneficio principal es que la selección de modelo puede adaptarse a la carga de trabajo en lugar de al calendario de publicaciones. Un equipo puede adoptar un nuevo modelo por defecto, mover una clase de prompts repetitiva a un modelo más barato o restaurar un destino anterior si los resultados empeoran. El código del servidor y los clientes móviles instalados siguen haciendo la misma petición API. El esfuerzo se centra en probar y revisar la decisión de enrutamiento.
| Cambio tras el lanzamiento | Con un modelo fijo en el código | Con haimaker/auto |
|---|---|---|
| Llega un modelo general mejor | Cambiar el ID de modelo y publicar código o configuración | Probarlo y luego cambiar el modelo por defecto del enrutador |
| Un modelo más barato encaja con una clase de prompts | Añadir lógica de enrutamiento en la aplicación y desplegarla | Añadir o editar una regla para esa clase de prompts |
| Un cambio de modelo empeora la calidad de salida | Revertir el cambio de código o configuración | Restaurar el destino anterior del enrutador |
| Los usuarios siguen con una build móvil antigua | El ID de modelo incrustado permanece desactualizado | El backend puede usar la política actual del enrutador |
Esto también ayuda cuando las publicaciones de servidor tienen trabajo pendiente no relacionado. Una decisión de modelo no tiene que esperar a esa ventana de despliegue. Las cargas de trabajo separadas pueden usar enrutadores separados asignándolos a claves API diferentes; Haimaker soporta un enrutador por clave.
Los cambios de enrutamiento siguen necesitando el mismo criterio que los cambios de código. El sandbox del panel muestra qué modelo seleccionaría un prompt, pero no demuestra que la respuesta sea buena. Ejecuta prompts representativos contra el modelo propuesto, inspecciona la salida real, vigila los logs del modelo resuelto y vuelve al destino anterior si la calidad baja. Haimaker cambia la selección de modelo; cambiar prompts, esquemas de herramientas o el comportamiento de la aplicación sigue requiriendo trabajo en la aplicación.
Mantén la elección de modelo preparada para la próxima publicación
Crea un enrutador, elige un modelo por defecto y asígnalo a la clave API que usa tu backend. Envía haimaker/auto en la petición y luego prueba unos cuantos prompts que representen la carga de trabajo. Cuando llegue un nuevo modelo, evalúalo con esos prompts antes de cambiar el modelo por defecto o una regla concreta. La documentación de Haimaker cubre la configuración del enrutador, el sandbox de pruebas y el historial de enrutamiento.
Los nuevos modelos pueden llegar antes de tu próxima publicación de app. Mantener la elección de modelo en Haimaker permite que la aplicación se mantenga al día mientras los desarrolladores dedican sus ciclos de publicación a cambios que requieren código nuevo.
Preguntas frecuentes
¿Cómo puedo cambiar el modelo de IA en una app móvil ya publicada?
Haz que la app llame a tu backend y que el backend envíe model: ‘haimaker/auto’ a Haimaker. Después puedes cambiar el modelo por defecto del enrutador o las reglas de prompts en el panel sin enviar una nueva build móvil. Los cambios en el enrutador pueden tardar hasta 60 segundos en surtir efecto.
¿Cambiar de modelo a través de Haimaker requiere un despliegue de servidor?
No. Si el servidor desplegado ya envía model: ‘haimaker/auto’ con una clave API asignada a un enrutador, puedes cambiar los modelos destino del enrutador en el panel. Los cambios en los prompts de la aplicación, los formatos de petición o el código siguen requiriendo el despliegue habitual.
¿Puedo mover solo los prompts sencillos a un modelo más barato?
Sí. Añade una regla con 3 a 10 prompts de ejemplo para una tarea sencilla y selecciona un modelo destino más económico. Haimaker verifica que el destino soporta la petición, mientras que los prompts que no coinciden con ninguna regla usan el modelo por defecto del enrutador.