Agregadores de LLM: cómo elegir modelos gratuitos que de verdad funcionen y no falsear el resultado

Si en un proyecto surge la necesidad de elegir un LLM, la mayoría de las veces se toma el camino más obvio: una larga lista de modelos, eliges uno, envías la solicitud. Funciona a corta distancia. A larga distancia empieza a romperse.

Dónde Se Rompe el Enfoque Simple

Los problemas no aparecen en la interfaz, sino en el comportamiento de los proveedores y de los propios modelos:

• Modelos free inestables — listados como gratuitos, pero responden de manera inestable, desaparecen durante el downtime del proveedor
• Los modelos desaparecen — ayer estaban disponibles, hoy el proveedor los eliminó o los cerró a nuevos usuarios
• Degradación de calidad — formalmente vivos, pero solo sirven para demo o tareas simples
• Desajuste entre frontend y backend — la lista en la interfaz está desactualizada por uno o dos días, mientras que el backend conoce una realidad diferente
• Errores y redireccionamientos — solicitaste un modelo, recibiste un error, o la respuesta vino de un modelo completamente diferente

El principal problema: la interfaz no sabe qué modelo respondió realmente. El usuario seleccionó Claude 3.5, pero la respuesta vino de Gemini — y no lo sabrá. Esto crea confusión: si la calidad de la respuesta no coincide con el modelo seleccionado, el usuario pierde la confianza.

Un Loop Rígido de Ingeniería en Lugar de un Catálogo

La solución no se construye a través de una lista infinita, sino a través del control en el backend:

Paso 1: limpieza de la lista. El backend recibe una lista cruda de modelos del proveedor, la filtra — mantiene solo opciones free adecuadas, elimina las inestables, quita duplicados. Puedes agregar health checks — consulta periódicamente cada modelo y verifica si está vivo.

Paso 2: un modelo por marca. Aunque OpenAI tenga 5 modelos free en la lista, el frontend recibe uno, el más estable. Esto simplifica la elección para el usuario y reduce la probabilidad de obtener un modelo deficiente.

Paso 3: fallback entre marcas. Durante una solicitud real — si el primer modelo devuelve un error, automáticamente intenta el segundo, luego el tercero. El usuario no sabrá del fallo, para él solo será un poco más lento.

Paso 4: honestidad en la respuesta. Devuelve no solo el texto generado, sino también `actual_model` — qué modelo lo generó realmente. Ahora la interfaz puede decir honestamente al usuario: "La respuesta es de GPT 4o mini, porque el modelo principal estaba en downtime."

"El problema no es cómo mostrar bonito una lista de modelos.

El problema es cómo construir un sistema que elija modelos free vivos y no mienta sobre el resultado" — esa es la esencia de la tarea.

Esto transforma un catálogo inestable en un loop predecible. El proveedor eliminó un modelo — el backend lo notará en la siguiente verificación y actualizará la lista en el frontend. El modelo se cayó — entra en juego el fallback, el usuario recibe una respuesta de otro proveedor.

Qué Significa Esto

Elegir un LLM deja de ser una tarea de UI y se convierte en una tarea de ingeniería — con limpieza de datos, health checks, lógica de fallback y seguimiento honesto. Para el producto, significa confiabilidad y menos preguntas de soporte. Para el usuario — la elección funciona, las respuestas llegan, la interfaz no miente.