Model routing: cómo elegir el LLM correcto para cada tarea en los harness de IA

El artículo de Tiago Vilas Boas explica que el "model routing" no es una medida reactiva al fin de mes, sino una decisión que debe tomarse en el primer prompt. Cuando una empresa paga por un modelo de IA a través de suscripciones o facturas corporativas, la elección del modelo pasa de ser una preferencia a una línea de coste compartido. Si el harness (por ejemplo Cursor, Claude Code, Codex o Kiro) permite cambiar de modelo durante la ejecución, el gasto se dispara porque cada sub‑agente hereda o elige su propio modelo, creando una árbol de facturación difícil de controlar.

Principios del model routing

1. Conocer capacidades y limitaciones: cada LLM tiene un rango de tareas donde sobresale y otro donde falla. La telemetría del harness debe registrar qué modelo ejecutó qué tarea y con cuántos reintentos.
2. Evaluar coste‑beneficio: no se trata de usar el modelo más potente, sino el más barato que cumpla los requisitos de precisión y latencia. En la práctica, Vilas Boas emplea una política de tres niveles (FAST, BALANCED, FRONTIER) y un mix 80/15/5 que asigna la mayor parte de los trabajos al modelo más económico.
3. Orquestar antes de la ejecución: la regla es definir el plan de routing en el YAML del harness antes de que la tarea se spawn. Cambiar de modelo después de que los tokens ya se hayan consumido es equivalente a negociar la factura.

Ejemplo de política en YAML

routing:
  default: cursor-opus
  rules:
    - task: "test_generation"
      model: cursor-opus
    - task: "feature_impl"
      model: grok-balanced
    - task: "billing_fix"
      model: claude-frontier

Con esta configuración, la mayoría de los trabajos (pruebas unitarias, generación de código trivial) se asignan a Cursor Opus, que cuesta 0,50 $ por 1 M de tokens de entrada y 2,50 $ por salida. Sólo cuando la tarea requiere razonamiento complejo o tiene alto coste de error se eleva a Claude Frontier (4 $ entrada, 20 $ salida). La tabla de precios provista por la UI de Cursor se usa como referencia, pero la telemetría real del harness es la única fuente definitiva para validar el modelo elegido.

Impacto financiero

Si una empresa no controla el routing, una sola tarea de copia de botón ejecutada en un modelo frontier puede costar tanto como decenas de tareas simples en un modelo barato. Además, los sub‑agentes pueden multiplicar el consumo: cada hijo hereda el modelo padre o elige uno nuevo, generando una facturación en forma de árbol. La política descrita permite reducir el gasto a centavos por token en la mayoría de los casos, reservando los precios más altos para los casos críticos donde el error es mucho más costoso que el modelo.

En conclusión, el model routing es una práctica de ingeniería que combina conocimiento de los LLM, métricas de telemetría y políticas declarativas para optimizar tanto la calidad del output como el coste operativo. Queda abierto seguir ampliando la telemetría y automatizar la generación de reglas a partir de datos históricos, lo que podría cerrar el círculo entre selección de modelo y gestión financiera de IA.

Repositorio de ejemplo en GitHub