IBM Research: el routing de modelos no es clasificación, es optimización de todo el sistema
IBM Research mostró el 15 de julio de 2026 por qué elegir un modelo barato para cada tarea no garantiza ahorro. En 417 tareas de AppWorld, el costo real cambió con caché, pasos de razonamiento, latencia, cumplimiento y condiciones del servicio.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
El routing de modelos suele venderse con una regla sencilla: manda lo fácil a un modelo barato y reserva el modelo grande para lo difícil. IBM Research acaba de explicar por qué esa receta se rompe en cuanto el agente usa herramientas, repite contexto o trabaja bajo restricciones empresariales.
En su artículo del 15 de julio de 2026, el equipo describe el routing como un problema de optimización de sistemas, no de clasificación. La diferencia importa: no basta con predecir la dificultad del prompt. Hay que optimizar costo, calidad, latencia, caché, confiabilidad y políticas al mismo tiempo.
El precio de la ficha no es el costo de la tarea
IBM comparó el mismo agente CodeAct en 417 tareas de AppWorld. Claude Sonnet 4.6 acumuló 79 dólares, o 0,19 dólares por tarea; GPT-4.1 llegó a 155 dólares, o 0,37 dólares por tarea. El resultado parece contraintuitivo porque el precio nominal de GPT-4.1 era menor y Sonnet necesitaba más pasos de razonamiento.
La explicación fue la caché. Un agente reutiliza grandes fragmentos de contexto entre llamadas. Si un proveedor cobra menos por lecturas desde caché, el costo efectivo puede cambiar el orden que sugería la tabla de precios. Un router que solo mira el precio por millón de tokens está optimizando una variable incompleta.
La primera métrica útil, entonces, no es precio_modelo. Es el costo por tarea terminada, separado en tokens nuevos, tokens cacheados, llamadas de herramientas, reintentos y pasos que terminaron en error.
La dificultad se revela durante la ejecución
“Resume este contrato” puede parecer una tarea pequeña y activar recuperación, controles de cumplimiento, varias herramientas y rondas de revisión. Un prompt técnico puede resolverse con un modelo especializado de menor costo. Además, una petición cambia de naturaleza cuando el agente observa el primer resultado.
Por eso el routing por turno puede ser mejor que el routing único por solicitud, pero también más caro y más lento. Elegir el modelo en cada paso abre flexibilidad para escalar cuando aparecen señales de complejidad; al mismo tiempo, añade decisiones, llamadas y puntos de fallo.
| Señal | Pregunta operativa | Riesgo si se ignora |
|---|---|---|
| Caché | ¿Cuánto contexto se reutiliza? | El modelo “caro” puede salir más barato. |
| Trayectoria | ¿Cuántos pasos y reintentos necesita? | El precio nominal oculta el trabajo real. |
| Latencia | ¿Está caliente el endpoint y cuánto tarda el router? | Un modelo rápido puede entregar una experiencia lenta. |
| Gobierno | ¿Qué modelos están permitidos por datos o región? | La ruta óptima puede ser inaceptable. |
IBM propone una frontera, no un ganador único
El enfoque del artículo genera configuraciones que dibujan una frontera entre costo y exactitud. Una configuración orientada a latencia alcanzó 84% de exactitud, 93 dólares y 83 segundos, con una reducción de 21% en costo y 9% en latencia frente a ejecutar todo con Opus, a cambio de una caída de 4% en exactitud. La cifra es de ese experimento; no debe convertirse en una promesa universal.
La idea general sí es reusable: ofrecer varios puntos de operación y elegir según el producto. Un flujo de soporte puede priorizar costo y tiempo. Un agente que modifica datos puede pagar más por confiabilidad. Una organización regulada puede descartar una ruta aunque sea barata por residencia o privacidad.
Cómo probarlo sin construir un monstruo
Empieza con un conjunto de 50 a 100 tareas reales, no con prompts inventados. Ejecuta el mismo harness con dos o tres modelos y registra costo efectivo, tiempo total, pasos, errores, uso de caché y necesidad de intervención. Compara también reintentos y respuestas incompletas: un fallo caro debe pesar más que una victoria barata.
No rutees hasta tener una política de salida. Si el agente excede pasos, pierde una herramienta crítica o devuelve una evidencia insuficiente, debe escalar, detenerse o pedir revisión. Y vuelve a medir cuando cambien precios, caché, modelos o infraestructura.
La demanda se infiere por la publicación reciente, el interés de builders en routing y la búsqueda de consultas como model routing agents, cost per agent task y LLM router cache. Agente IA puede competir en español porque traduce el anuncio a una práctica concreta: calcula el costo de completar trabajo, no el costo de producir tokens. Para ordenar el resto del arnés, puedes revisar el curso gratis y contrastar este enfoque con las métricas de agentes por repositorio.