Cloudflare lanza Auto Router: elige el modelo por el empleado y ahorra hasta un 30%

Cloudflare ha lanzado en beta pública Auto Router, una función de AI Gateway que elige por sí sola el modelo para cada solicitud. En el cliente o en el agente basta con indicar cloudflare/auto. A partir de ahí, la pasarela decide si la tarea requiere un modelo de gama alta o si basta con uno más barato. En su trabajo con la herramienta agéntica interna OpenCode, la compañía obtuvo un ahorro de hasta el 30% respecto a usar solo modelos de gama alta. En su propio benchmark de tareas de oficina, el router costó $2,10 frente a $5,91 de Claude Opus 5.5, pero también perdió frente a este en la proporción de ejecuciones exitosas.

La pasarela elige el modelo por el empleado

La lógica tradicional para controlar el gasto en IA se basaba en presupuestos, límites y la asignación de costes a personas concretas. Cloudflare describe así el camino habitual de las empresas. Primero se reparten claves de API sin restricciones y se prueba cada herramienta nueva. Después quedan unas pocas soluciones principales para programación, tareas no técnicas y ejecución de agentes. Pero en OpenCode, Claude Code y Codex sigue siendo el propio usuario quien elige el modelo, y con frecuencia escoge uno más potente de lo necesario. No hace falta Opus para resumir un correo o una conversación de chat. Aun así, bloquearlo desde el equipo de seguridad tampoco resulta deseable.

AI Gateway ya ve cada solicitud de usuarios, agentes y herramientas, así que puede tomar esa decisión de forma centralizada. La empresa se queda con el ahorro sin que los empleados tengan que cambiar sus hábitos.

Un esquema en dos etapas: clasificador y matriz de puntuaciones

Primero, la pasarela forma un conjunto de modelos admisibles. Descarta los que no admiten el formato de la solicitud o el modo de ejecución, y tiene en cuenta las claves, los ajustes de facturación, las políticas de acceso y los límites de gasto. Los modelos y proveedores con caídas se excluyen temporalmente y vuelven cuando se restablece el servicio.

Después entra en juego un clasificador multicabeza en Workers AI, desplegado en GPU por toda la red periférica de Cloudflare. El clasificador analiza un fragmento comprimido de la conversación, con prioridad para los mensajes más recientes, y genera dos conjuntos de señales. El primero son las probabilidades para 14 categorías de tareas: programación, planificación, investigación, análisis de datos y otras. El segundo son puntuaciones de 1 a 5 en cuatro ejes: complejidad, ambigüedad, coste del error y dependencia del contexto previo.

Estas señales pasan a una matriz de puntuaciones independiente, donde se combinan con los benchmarks de los modelos. Los pesos se han calibrado con un conjunto de ejemplos para los que se definió de antemano el modelo preferido. El resultado se calcula con la fórmula utility = calidad esperada − penalización adaptativa por coste. En las solicitudes simples, el precio pesa más y gana un modelo más pequeño. A medida que aumenta la complejidad, la penalización baja y se imponen los modelos potentes. A la salida, el router entrega una lista ordenada, y la pasarela prueba el primer modelo y, si el proveedor lo rechaza, pasa al siguiente.

La ventaja del esquema es su transparencia: se puede ver la categoría y la complejidad que se han predicho para la tarea y entender por qué se ha elegido ese modelo. Un modelo nuevo se añade sin reentrenar nada: basta con introducir en la matriz los pesos derivados de sus benchmarks.

El caché, una partida de gasto oculta

En sesiones agénticas largas, como la depuración de código, el coste no lo determina la lista de precios, sino la lectura del caché, que se encarece a medida que crece la sesión. Cambiar de modelo vacía el caché, y el nuevo modelo tiene que volver a escribir todo el contexto. Por eso, dentro de un mismo turno (el ciclo de procesamiento de una entrada del usuario), el router casi siempre se mantiene en el modelo actual. Entre turnos aplica una penalización por cambio que crece con el número de tokens del contexto. El modelo con el caché activo se evalúa con la tarifa de lectura, y el resto de candidatos, con el precio completo de reescribir el contexto.

Hay un segundo coste oculto: la mayoría de los modelos no leen los tokens de razonamiento de los demás. Tras un cambio, el nuevo modelo puede volver a hacer lo que ya estaba hecho, pero a tarifas de salida. En el futuro, Cloudflare quiere que el router prefiera modelos de la misma familia al cambiar.

Qué mostró el benchmark interno

La prueba simula un espacio de trabajo con correo, calendario, Slack, archivos, viajes y finanzas. Cada tarea exige dar una respuesta verificable o ejecutar una acción. En total son 97 tareas, con tres ejecuciones por modelo, es decir, 291 intentos. Los intervalos de confianza del 95% se calcularon mediante bootstrap con 10 000 muestras.

• cloudflare/auto: 252 de 291 exitosas, 86,6% (+6,2/−6,9 p. p.), coste total $2,10, $0,0084 por éxito • Anthropic Claude Opus 5.5: 281 de 291, 96,6% (+2,7/−3,8 p. p.), $5,91, $0,0210 por éxito • OpenAI GPT-6 Sol: 245 de 291, 84,2% (+6,5/−6,9 p. p.), $2,64, $0,0108 por éxito

Cloudflare califica el resultado de comparable al de los mejores modelos de uso diario: el router cuesta el 80% de Sol y el 35% de Opus. Pero conviene leer las cifras con atención. Frente a Sol, auto ofrece una calidad similar y es más barato.

Frente a Opus se queda unos 10 p. p. por detrás y los intervalos no se solapan, de modo que el ahorro de 2,5 veces por éxito se paga con una pérdida de calidad.

Para resúmenes y consultas rutinarias es un intercambio razonable; para tareas críticas, no. Por separado, la compañía señala que un modelo barato según la lista de precios puede gastar muchos más tokens de forma desproporcionada, por lo que el router minimiza el coste previsto de toda la trayectoria, no el precio por millón de tokens.

Cómo conectarlo y qué viene después

Se puede empezar ahora mismo: en la beta, Auto Router es gratuito y basta con indicar cloudflare/auto en la configuración del agente o del cliente. Lo lógico es pasar primero por él los escenarios no técnicos y la programación rutinaria, y dejar en el modelo de gama alta las tareas con un coste del error elevado. Para ello hará falta un benchmark propio con datos reales, como el de Cloudflare.

Entre los planes figuran ampliar el conjunto de modelos, tener en cuenta los requisitos de zero data retention al filtrar, considerar la capacidad de los proveedores, elegir el nivel de razonamiento para cada solicitud, añadir compatibilidad completa con Responses API y WebSockets, y probar modelos estructurados de toma de decisiones como clasificador primario. Más adelante llegará cloudflare/auto-best, que usará el mismo conjunto de modelos y el mismo clasificador, pero elegirá el modelo con la máxima calidad esperada sin tener en cuenta el precio.