Enrutamiento multimodelo para agentes de programacion

Qué hace el enrutamiento multimodelo a un agente de programación

El enrutamiento multimodelo envía cada petición al modelo más económico capaz de procesarla. En el tráfico de chat funciona bien. En un agente de programación suele costar más de lo que ahorra, porque la factura de un agente está dominada por un prefijo de prompt que se almacena en caché por modelo, y cambiar de modelo invalida esa caché.

La regla que defiende esta publicación es: enrutar entre proveedores para garantizar la disponibilidad, enrutar entre niveles por coste solo en los límites de las tareas y fijar un modelo por sesión para cualquier actividad del agente. Todo lo que sigue es el razonamiento.

Cuatro términos, definidos una vez. Un router elige un modelo por petición. Un gateway es el proxy a través del cual pasa la petición, que puede o no realizar también el enrutamiento. Un prompt cache es el proveedor que almacena el prefijo procesado de su prompt, de modo que una petición posterior que repita ese prefijo se factura a una fracción del precio de entrada. Un KV cache (caché de clave-valor) es la misma idea dentro de un servidor que usted mismo ejecuta.

Por qué el tráfico de chat se enruta correctamente y el de los agentes no

Una petición de chat es un turno único. Llega, se clasifica, pasa a un modelo y devuelve una respuesta. No hay persistencia entre una petición y la siguiente. Un router puede enviar esta pregunta a un modelo pequeño y la siguiente a uno grande, sin que ninguna petición tenga constancia de la otra. Esta es la carga de trabajo que miden casi todos los benchmarks de enrutamiento, y los routers de calidad son realmente eficaces en ello.

Un turno de agente no es una única petición. Una instrucción como "corrige el test fallido" se convierte en entre veinte y sesenta llamadas a la API. Cada llamada reenvía la conversación completa: el system prompt, todas las definiciones de herramientas, cada archivo que el agente ha leído y cada salida de comando que ha visto. El contexto solo aumenta. Para la llamada número treinta, el prefijo repetido puede sumar decenas de miles de tokens, mientras que el contenido genuinamente nuevo en cada llamada es de apenas unos cientos.

Esa estructura cambia el significado de la palabra "costoso". En el chat, el coste es aproximadamente el precio del modelo multiplicado por la petición. En un bucle de agente, el coste es el prefijo, que se factura de nuevo en cada llamada individual. El resto de esta publicación se deriva de este único hecho.

La caché de prompts es por modelo y el agente reside dentro de ella

Anthropic valora una lectura de caché en 0.1 veces el precio base de entrada, y una escritura de caché de cinco minutos en 1.25 veces. Estos son los precios de lista publicados, a fecha de agosto de 2026.

[
  {
    "label": "Opus 5",
    "uncached_input_usd": "5.00",
    "cache_read_usd": "0.50"
  },
  {
    "label": "Sonnet 5",
    "uncached_input_usd": "2.00",
    "cache_read_usd": "0.20"
  },
  {
    "label": "Haiku 4.5",
    "uncached_input_usd": "1.00",
    "cache_read_usd": "0.10"
  }
]

Compare la segunda serie con la primera, a través de las filas en lugar de las columnas. Una lectura de caché en Opus 5 cuesta 0.50 dólares por millón de tokens. La entrada sin caché en Haiku 4.5, el modelo más barato de la lista, cuesta 1.00 dólares. Por lo tanto, volver a leer un prefijo activo en el modelo más caro cuesta menos por token de entrada que leer ese mismo prefijo en frío en el modelo más barato.

Esa comparación única invalida la mayoría de los planes de enrutamiento. Un enrutador que mueve trabajo a un nivel inferior compara precios de lista. Pero un agente en mitad de una sesión no paga el precio de lista del modelo que ya está utilizando. Paga el precio de lectura de caché, que ya se sitúa por debajo de la tarifa sin caché del modelo económico.

Las cachés se indexan mediante un hash del prefijo del prompt y son específicas para cada modelo. Una solicitud a un modelo diferente genera un hash contra un almacén que nunca lo ha visto, por lo que no encuentra nada y paga el precio completo. La caché también es una jerarquía: primero las herramientas, luego el sistema y, finalmente, los mensajes. Un cambio en cualquier nivel invalida ese nivel y todo lo que le sigue, lo que significa que editar una definición de herramienta descarta la caché del prompt del sistema que se encuentra detrás. Los agentes que registran herramientas durante la ejecución se ven afectados por esto sin necesidad de interactuar con un enrutador.

El coste real de un cambio a mitad de sesión

Tomemos una sesión con un prefijo estable de 40,000 tokens, un tamaño habitual una vez que un agente ha leído un puñado de archivos. A continuación se muestra el coste del prefijo de un solo turno, calculado a partir de los precios de lista anteriores.

[
  {
    "label": "Opus 5, cache warm",
    "prefix_cost_usd": "0.020"
  },
  {
    "label": "Sonnet 5, turn after switch",
    "prefix_cost_usd": "0.100"
  },
  {
    "label": "Opus 5, cache re-warmed",
    "prefix_cost_usd": "0.250"
  }
]

Permanecer en Opus 5 con una caché activa cuesta 0.020 dólares por el prefijo de ese turno. El primer turno tras redirigir a Sonnet 5 cuesta 0.100 dólares, porque Sonnet no tiene ninguna entrada para este prefijo y debe escribir una. Volver a Opus 5 cuesta 0.250 dólares, porque la entrada original expiró mientras la sesión estaba fuera.

Por tanto, el viaje de ida y vuelta paga dos escrituras en caché para evitar dos lecturas en caché. A cambio, el cambio permitió obtener un turno de salida al precio de salida de Sonnet en lugar del de Opus. El bloque de detalles analiza el viaje completo: el ahorro se mide en fracciones de centavo, mientras que la penalización de la caché se mide en decenas de centavos. La penalización es mayor en más de un orden de magnitud y crece con la longitud del prefijo, mientras que el ahorro no lo hace.

Opus 5, warm read     40,000 x $0.50 / 1e6  = $0.020
Sonnet 5, cache write 40,000 x $2.50 / 1e6  = $0.100   (1.25 x $2 base)
Opus 5, cache write   40,000 x $6.25 / 1e6  = $0.250   (1.25 x $5 base)

800 x ($25 - $10) / 1e6 = $0.012

Los formatos de llamada a herramientas no son iguales entre proveedores

Un agente es un bucle de llamadas a herramientas, por lo que el formato de la llamada es crítico, a diferencia de lo que ocurre en un chat convencional. La Messages API de Anthropic devuelve un bloque de contenido tool_use y espera un bloque tool_result como respuesta. Las API compatibles con OpenAI devuelven una matriz tool_calls en la que function.arguments es una cadena codificada en JSON en lugar de un objeto anidado. Una pasarela traduce entre ambos formatos y, para llamadas ordinarias, la traducción es limpia.

Los problemas aparecen en los casos límite. Las llamadas a herramientas en paralelo, donde un modelo emite varias llamadas en una sola respuesta, se representan de forma distinta y no cuentan con soporte idéntico en todas partes. La aplicación estricta de esquemas es una funcionalidad específica de cada proveedor, por lo que un modelo que garantiza argumentos válidos según el esquema en un endpoint, solo tiende a generar argumentos válidos en otro. El agente percibe la diferencia como un resultado de herramienta que contiene un error de análisis, el cual intenta reparar gastando otro turno. Esos turnos de reparación se facturan al precio completo del prefijo, por lo que una discrepancia de formato se refleja tanto en la factura como en el registro de la sesión.

Los endpoints autohospedados requieren una configuración explícita. El servidor compatible con OpenAI de vLLM requiere --enable-auto-tool-choice junto con un --tool-call-parser adaptado a la familia del modelo (hermes, mistral, llama3_json y otros), además de una plantilla de chat que gestione los mensajes con rol de herramienta. La documentación de vLLM es directa sobre los límites de esta vía: con tool_choice="auto" y sin una restricción estricta de esquema, vLLM extrae las llamadas a herramientas a partir de texto sin formato, por lo que los argumentos pueden estar mal formados ocasionalmente o violar el esquema de parámetros de la función. Elegir el analizador incorrecto para su modelo es un error de configuración que se manifiesta como un agente incapaz de llamar a herramientas, algo que conviene saber antes de dirigir tráfico hacia él. La diferencia entre Ollama y vLLM para servir modelos usted mismo es relevante aquí, ya que ambos exponen la llamada a herramientas bajo condiciones distintas.

El cambio de comportamiento en tareas intermedias mediante fallback sin errores

El enrutamiento de fallback es la funcionalidad que más probabilidades tiene de activarse por accidente. Se configura una puerta de enlace para reintentar con otro modelo cuando el primero devuelve un límite de tasa o un error 5xx, y luego se coloca al modelo fallido en un periodo de enfriamiento durante algunos segundos. En el tráfico de chat, esto es correcto. Sin embargo, dentro de una tarea larga de un agente, significa que la segunda mitad de la tarea se ejecutó en un modelo que usted no eligió.

Nada informa de esto. La tarea no falla, el agente no advierte y el estado de salida es de éxito. Lo que se obtiene es una tarea donde el plan fue redactado por un modelo y las ediciones fueron realizadas por otro, con un tono y un conjunto de hábitos que cambian a mitad del proceso. La única señal fiable es el campo model en el registro de peticiones de la puerta de enlace o en los metadatos de respuesta; por lo tanto, si utiliza fallbacks, registre ese campo por petición y léalo cuando un resultado le sorprenda. Depurar un comportamiento sin saber qué modelo lo produjo consume más tiempo del que el fallback ahorró.

La misma trampa afecta a la compresión de contexto. Muchos agentes resumen un historial largo llamando a un modelo pequeño. Si esa llamada utiliza un modelo diferente o un prompt del sistema distinto, escribe su propia entrada en la caché y no actualiza la de la sesión principal, por lo que el siguiente turno completo paga el coste de un prefijo en frío. La compresión ahorró tokens pero perdió la caché.

La sobrecarga de enrutamiento es real, pero la latencia no es el problema principal

Los routers añaden trabajo por cada petición, y conviene ser precisos sobre cuánto. DigitalOcean informa que su modelo Arch-Router resuelve la intención de enrutamiento en unos 51 milisegundos, con una precisión de enrutamiento del 93.17% según su propia evaluación. Estas son sus cifras, basadas en sus mediciones y sus pruebas de rendimiento, no en las nuestras ni en un resultado universal. Si se toman al pie de la letra, la conclusión es tranquilizadora: 51 milisegundos a lo largo de cuarenta llamadas de agente suponen unos dos segundos añadidos a una tarea que se ejecuta durante varios minutos.

Dos segundos no es lo que hace que el enrutamiento sea costoso en este caso. La sobrecarga que sí perjudica es la de un router que clasifica mediante una llamada completa al modelo, ya que eso supone una segunda inferencia en cada petición, facturada y encolada como cualquier otra. Debajo de ambos se encuentra la aritmética de caché mencionada anteriormente, que no es una sobrecarga en absoluto. Es el coste de aquello que el enrutamiento debía optimizar.

En un servidor que usted mismo gestiona, se aplica la misma regla con menos margen de maniobra. El equivalente local de la caché de prompts es el almacenamiento en caché de prefijos en la KV cache, que reside en la memoria de la GPU. Alojar dos modelos en una misma GPU divide esa memoria entre ellos, por lo que cada uno mantiene una KV cache más pequeña y expulsa los prefijos antes. Por tanto, enrutar entre dos modelos locales puede reducir la tasa de aciertos de caché para ambos simultáneamente. Si está dimensionando el hardware para esto, la memoria y CPU que un agente de programación realmente necesita en un VPS es un punto de partida más útil que un router.

La regla de decisión

• Enrute entre proveedores para garantizar la disponibilidad. Cuando la alternativa es una petición fallida, cualquier coste es el coste correcto. Asigne el respaldo a un modelo con el mismo formato de llamada a herramientas para que el bucle del agente siga funcionando, y registre qué modelo atendió cada llamada.
• Enrute entre niveles de servicio por coste solo en los límites de las tareas. Elegir Haiku para renombrar y Opus para una refactorización es una buena decisión tomada una vez, antes de que comience la sesión. Es una mala decisión si se toma en el turno treinta de esa sesión.
• Asigne un único modelo por sesión para cualquier tarea de agentes. El valor de una sesión reside en su caché activa. Trate el cambio de modelo como trataría el vaciado de esa caché, porque eso es exactamente lo que provoca.
• Enrute subagentes libremente. Un subagente que comienza con un contexto nuevo y pequeño no tiene una caché activa que perder, por lo que puede ejecutarse en cualquier modelo que se adapte a su trabajo. Este es el único lugar dentro de un agente donde el enrutamiento es prácticamente gratuito.

Para construir esto, la pasarela realiza el trabajo: alias de modelos y listas de respaldo explícitas. Una configuración mínima de proxy LiteLLM tiene este aspecto.

model_list:
  - model_name: agent-primary
    litellm_params:
      model: anthropic/claude-opus-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: agent-standby
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  fallbacks: [{"agent-primary": ["agent-standby"]}]
  num_retries: 2
  cooldown_time: 30

Apunte el agente a agent-primary y permanecerá en un modelo hasta que este no esté disponible. Ambas entradas residen en el mismo proveedor, por lo que el formato de llamada a herramientas no cambia cuando se activa el respaldo. Usted sigue aceptando un cambio de nivel en ese momento, lo cual es un intercambio que solo vale la pena hacer porque la alternativa es una petición fallida. Eso es enrutamiento por disponibilidad sin enrutamiento por costes asociados, que es la combinación que la mayoría de los agentes de programación desean. La implementación completa, incluyendo claves y presupuestos, se trata en ejecutar una pasarela LiteLLM autohospedada en su propio VPS, y esta publicación deliberadamente no lo repite.

Cuando un modelo bien elegido supera a cualquier router

El enrutamiento es una solución a la varianza en la dificultad de las peticiones. Un agente de programación tiene menos varianza de la que parece, porque la parte costosa de cada llamada es el mismo prefijo, independientemente de lo que solicite la llamada. Una vez que el prefijo domina, la diferencia entre su nivel económico y su nivel costoso se reduce hacia la diferencia en sus precios de salida, y la salida representa una pequeña parte de los tokens de un agente.

Por lo tanto, la opción predeterminada honesta es un solo modelo, elegido una vez, con el almacenamiento en caché activado y un TTL (tiempo de vida) lo suficientemente largo como para cubrir las pausas cuando deja de escribir para leer un diff. Anthropic ofrece una escritura en caché de una hora a 2 veces la entrada base, lo cual se amortiza después de dos lecturas, y eso suele ser una palanca mejor que cualquier router. Elija el nivel deliberadamente usando una comparación directa de Opus, Sonnet y Haiku, y si la factura sigue siendo el problema, redúzcala con presupuestos y contextos más pequeños como en controlar los costes de agentes de IA en un VPS en lugar de cambiar de modelo a mitad de la sesión.

Enrute cuando las peticiones sean independientes y breves, o cuando los subagentes comiencen con contextos nuevos. Fije el modelo cuando tenga una sesión larga realizando una sola tarea. La mayor parte del trabajo de un agente de programación es del segundo tipo, razón por la cual el router que ahorra dinero en su producto de chat le costará dinero silenciosamente aquí. Si aún no se ha decidido por el agente en sí, la comparación de Claude Code frente a Cursor, Codex y Copilot cubre cómo cada uno gestiona la selección de modelos, y algunos de ellos toman esta decisión por usted.

FAQ

¿Cambiar de modelo a mitad de sesión realmente pierde la caché de prompts?

Sí. Las cachés de prompts se indexan mediante un hash del prefijo del prompt y se almacenan por modelo; por tanto, una petición enviada a un modelo distinto busca en un almacén que nunca ha visto ese prefijo. No encuentra nada y paga el precio completo de entrada sin caché, además de pagar una escritura en caché si esta está habilitada. Volver al modelo anterior tampoco recupera la entrada original, ya que el tiempo de vida predeterminado de cinco minutos suele haber expirado para entonces. Compruebe los campos cache_read_input_tokens y cache_creation_input_tokens en el objeto de uso de la respuesta: un turno que lee cero tokens en caché durante una sesión larga es el síntoma.

¿Es el enrutamiento a un modelo más barato alguna vez más económico para un agente?

Solo cuando no hay una caché activa que perder. Una lectura de caché en Anthropic cuesta 0.1 veces la entrada base, lo que sitúa una lectura activa en Opus 5 por debajo de la tasa de entrada sin caché en Haiku 4.5. Una vez que una sesión tiene un prefijo grande en caché, el modelo actual ya es la opción barata en cuanto a entrada. El enrutamiento compensa cuando el contexto es nuevo y pequeño: al inicio de una tarea o en un subagente que solo transporta el contexto que necesita.

¿Por qué mi agente se comportó de forma distinta a mitad de una tarea?

Compruebe si se activó una alternativa (fallback) en el gateway. Un límite de tasa o un error 5xx en el modelo principal hace que el gateway reintente la operación en el modelo de reserva y ponga al principal en periodo de enfriamiento durante unos segundos, por lo que el resto de la tarea se ejecuta en otro lugar. Esto no produce errores ni advertencias, y la tarea sigue reportando éxito. El campo model en el registro de peticiones del gateway o en los metadatos de respuesta es el único registro fiable, así que regístrelo por petición si utiliza alternativas.

¿Funcionan las llamadas a herramientas igual en todos los proveedores?

No exactamente. La API Messages de Anthropic utiliza bloques de contenido tool_use y tool_result, mientras que las APIs compatibles con OpenAI utilizan un array tool_calls cuyo function.arguments es una cadena codificada en JSON. Un gateway traduce bien los casos comunes, pero las llamadas a herramientas en paralelo y la aplicación estricta de esquemas difieren según el proveedor. En vLLM autohospedado debe configurar --enable-auto-tool-choice y un --tool-call-parser que coincida con su familia de modelos; la documentación de vLLM señala que, sin una restricción de esquema estricta, el servidor extrae las llamadas a herramientas a partir de texto sin formato, por lo que los argumentos pueden estar mal formados ocasionalmente.

¿Cuánto tiempo debo establecer el TTL de caché para una sesión de programación?

Utilice el tiempo de vida predeterminado de cinco minutos para trabajo continuo, y la opción de una hora cuando un humano lea diferencias (diffs) entre turnos. Anthropic valora la escritura de cinco minutos en 1.25 veces la entrada base y la escritura de una hora en 2 veces, frente a una lectura de 0.1 veces. La escritura de cinco minutos se amortiza con una sola lectura, y la de una hora con dos; por tanto, en cualquier sesión en la que espere volver y continuar, el tiempo de vida más largo suele costar menos que pagar por un prefijo frío.