🔀 Enrutado de modelos por coste
Idea: no ejecutar todas las tareas con el modelo más caro. Antes de cada tarea, una decisión barata elige modelo (o agente) y solo entonces se paga el modelo grande. El cuello de botella no es generar texto, es decidir, y decidir no requiere un LLM caro.
El patrón
- Llega una tarea (correo, lead, job programado, petición del usuario).
- Un modelo de decisión barato y rápido responde a una pregunta tipada: categoría (
choice), prioridad (score) o sí/no (null). - Según la respuesta, el sistema enruta a un modelo light o strong, a un agente concreto, o a ningún sitio (silencio).
Reglas de diseño que aparecen en la fuente
- Fail-safe hacia la calidad: si el router duda, se elige el modelo fuerte o se pregunta al humano. Un ahorro nunca debe degradar una tarea difícil.
- Silencio por defecto: si la decisión es “no hay nada relevante”, no se notifica ni se gasta en generar un mensaje vacío.
- Mismo agente, misma memoria, distinto modelo: el enrutado solo cambia el motor, no el contexto.
- Latencia despreciable: si la decisión tarda milisegundos, el enrutado no se percibe (el autor no nota diferencia frente a llamar al agente directamente).
Dónde encaja en este wiki
- Complementa token-optimization: aquello reduce tokens dentro de una llamada; esto reduce el precio por token eligiendo motor.
- El plugin token-optimizer mide gasto; el enrutado lo recorta en origen.
- Candidato natural para un cron de Hermes: consultas baratas que deciden si merece la pena despertar al modelo grande.
Límites
- Solo aplica a tareas clasificables; el trabajo creativo o de razonamiento largo sigue necesitando el modelo fuerte.
- Depende de que el modelo de decisión sea fiable y esté realmente disponible por API (ver jev).