Capital de Tokens
Cursor Router: cómo elegir el modelo correcto para cada tarea sin pagar de más
Cuando usamos un coding agent solemos tomar una decisión bastante primitiva:
elige un modelo
↓
úsalo para todoEl problema es que no todas las tareas necesitan el mismo nivel de inteligencia, latencia ni coste.
Hacer un commit, cambiar un nombre o ejecutar un comando sencillo puede ser trabajo rutinario. Comprender una base de código grande, planear una refactorización o depurar un fallo visual complejo puede justificar un modelo mucho más caro.
Cursor está intentando convertir esa intuición en un sistema de routing aprendido con tráfico real.
En su explicación técnica de Cursor Router, la compañía describe una arquitectura que separa la decisión en tres preguntas:
1. ¿Qué tan compleja parece esta tarea?
2. Si es compleja, ¿qué tipo de tarea es?
3. ¿Qué modelo ofrece la mejor mejora esperada dentro del presupuesto?La idea importante no es simplemente “Auto selecciona un modelo”.
Lo interesante es que Cursor está tratando la selección de modelos como un problema de predicción + clasificación + optimización económica.
El problema: usar el mejor modelo para todo también es una mala estrategia
Una estrategia sencilla sería enviar cada request al modelo frontier más capaz disponible.
Eso maximiza capacidad potencial, pero desperdicia dinero en trabajo fácil.
request simple
↓
modelo frontier
↓
respuesta correcta
↓
pero a precio frontierLa alternativa opuesta tampoco funciona bien:
request difícil
↓
modelo barato
↓
correcciones
↓
reintentos
↓
más tokens + más tiempoPor eso el problema real no es minimizar el precio de una llamada.
Es minimizar algo más parecido a:
coste total
+
probabilidad de fallo
+
reintentos
+
fricción del usuarioUn modelo barato que obliga a repetir el trabajo puede terminar siendo más caro operacionalmente que uno potente usado una sola vez.
Cursor Router intenta encontrar ese punto de equilibrio automáticamente.
Primera pieza: aprender de trabajo real, no sólo de benchmarks
Cursor parte de una decisión interesante: el router no se entrena únicamente con benchmarks sintéticos.
La empresa construyó su dataset usando cientos de miles de turnos de tráfico real de desarrollo, respetando las configuraciones de privacidad y retención de los usuarios.
Cada ejemplo contiene las señales disponibles antes de hacer routing y dos resultados importantes:
- desempeño;
- coste.
Pero medir “desempeño” en un coding agent no es trivial.
Cursor utiliza lo que el usuario hace después como una señal indirecta.
Por ejemplo:
agente responde
↓
usuario continúa con otra tarea
↓
señal positivaMientras que:
agente responde
↓
usuario corrige / vuelve a pedir cambios
↓
señal negativaEso convierte el uso cotidiano del producto en una fuente de feedback para el router.
No es lo mismo que demostrar formalmente que una respuesta sea correcta, pero tiene una ventaja enorme: refleja el trabajo que los desarrolladores realmente están intentando hacer.
Compass: predecir cuándo una tarea merece un modelo más caro
La primera decisión del Router la toma un componente llamado Compass.
Compass produce un score continuo entre 0 y 1 que Cursor utiliza como proxy de complejidad.
La intuición es sencilla.
Las tareas fáciles suelen resolverse sin correcciones.
Las tareas difíciles tienen mayor probabilidad de generar follow-ups, cambios y nuevas instrucciones.
Conceptualmente:
Compass
request ───────────┬───────────
│
score 0..1
│
┌───────┴────────┐
│ │
bajo alto
│ │
modelo eficiente evaluar frontierCursor reporta que los turnos que Compass consideraba más fáciles terminaban con una señal positiva alrededor del 96% del tiempo, mientras que los del extremo más difícil rondaban el 71%.
Ese score permite mover un umbral τ dependiendo del objetivo del producto.
score < τ
→ modelo eficiente
score ≥ τ
→ router de tareasCambiar τ cambia directamente la economía del sistema.
Un threshold que conserva más tráfico en el modelo barato reduce coste.
Uno que escala más requests hacia modelos frontier compra mayor calidad potencial.
Ésa es la primera palanca del Router.
Segunda pieza: no existe un modelo que gane en todo
Una vez que Compass decide que la tarea merece más capacidad, todavía queda otra pregunta:
¿Cuál modelo?
Cursor afirma haber observado algo que cada vez es más evidente en sistemas multi-modelo: los modelos tienen perfiles de fortalezas distintos.
Para representarlo, Cursor clasifica el trabajo en tres dimensiones.
1. Domain
Dónde ocurre el trabajo.
Por ejemplo:
- backend;
- frontend;
- esquemas de base de datos.
2. Task
Qué quiere conseguir el desarrollador.
Por ejemplo:
- arreglar un bug;
- ejecutar comandos;
- escribir tests;
- planear una implementación.
3. Modifiers
Características que atraviesan distintos dominios pero pueden cambiar qué modelo funciona mejor.
Por ejemplo:
- edits muy acotados;
- preguntas de producto;
- cambios con fuerte componente visual.
El resultado puede verse como una etiqueta compuesta:
domain: frontend
task: debugging
modifier: visual-heavyEsa taxonomía permite dejar de preguntar:
¿Cuál es el mejor modelo?
Y empezar a preguntar:
¿Cuál es el mejor modelo para esta clase de trabajo?
El mapa de fortalezas que Cursor observó
Según los resultados publicados por Cursor, diferentes modelos sobresalen en distintas categorías.
En su tráfico:
- Grok ofreció una buena relación coste/rendimiento para trabajo rutinario, incluyendo comandos Git y operaciones generales de bases de datos;
- Sol destacó especialmente en planificación y comprensión de codebases, además de varias tareas de implementación;
- Opus rindió bien en trabajo intensivo de ejecución, incluyendo DevOps, queries de bases de datos y optimización de performance;
- Fable mostró fortalezas en debugging y trabajo visual complejo.
La conclusión arquitectónica es más importante que el ranking puntual.
Los modelos cambian rápidamente.
Lo durable es la idea de mantener un mapa:
task classes
│
┌───────────────┼───────────────┐
│ │ │
modelo A modelo B modelo C
fuerte aquí fuerte allá mejor costeEl router no tiene por qué casarse permanentemente con un proveedor.
Debe aprender continuamente dónde cada modelo produce suficiente valor para justificar su coste.
La tercera pieza: no enrutar por diferencias pequeñas
Un router agresivo puede cometer otro error: cambiar de modelo cada vez que detecta una ventaja minúscula o estadísticamente dudosa.
Cursor intenta evitarlo con una regla de elegibilidad.
Un modelo candidato sólo entra en consideración cuando la evidencia observada para esa categoría supera un umbral unilateral que Cursor describe aproximadamente como 75% de confianza en que la mejora frente al modelo eficiente es real.
Eso introduce una especie de zona de indiferencia:
modelo frontier parece 0.2% mejor
→ evidencia débil
→ no vale la pena cambiar
modelo frontier muestra ventaja consistente
→ candidato elegibleEs una decisión importante porque el routing también tiene costes secundarios:
- cache misses;
- diferencias de latencia;
- variación de comportamiento;
- mayor precio por token;
- más complejidad operacional.
La pregunta correcta no es si otro modelo puede ser mejor.
Es si es suficientemente mejor como para justificar el cambio.
Después entra el presupuesto
Una vez identificados los modelos candidatos, Cursor no selecciona simplemente el que obtiene el score máximo.
Utiliza un optimizador que busca la combinación de routing con mayor mejora esperada sujeta a un presupuesto promedio por turno.
Conceptualmente:
maximizar
calidad esperada
sujeto a
coste medio ≤ presupuestoEso convierte la selección de modelos en un problema parecido a asignar recursos en una plataforma de infraestructura.
No estamos preguntando:
¿qué modelo es mejor?Sino:
¿dónde produce cada dólar adicional
la mayor mejora esperada?Esta distinción explica por qué Cursor puede ofrecer distintos modos sobre el mismo Router.
Cost, Balance e Intelligence son políticas, no modelos
En la interfaz actual de Cursor, Auto expone tres objetivos:
- Cost;
- Balance;
- Intelligence.
No son necesariamente tres modelos diferentes.
Son tres posiciones sobre la curva coste-calidad.
Podemos pensarlo así:
coste bajo calidad máxima
│ │
├──── Cost ───── Balance ───── Intelligence ───┤La implementación puede variar dos grandes parámetros:
Compass threshold
+
budget del task routerBalance mantiene más tráfico en la ruta eficiente y dispone de un presupuesto menor para escalar.
Intelligence permite gastar más cuando la mejora esperada lo justifica.
El usuario no necesita escoger manualmente entre cuatro proveedores en cada turno.
Escoge una política económica.
El router resuelve el detalle.
Los resultados publicados son precisamente una curva de Pareto
Cursor reporta actualmente que Auto Intelligence supera el nivel de satisfacción de Fable con 68% menos coste, mientras que Auto Balance supera a Opus 4.8 con 41% menos coste y una mejora adicional de 3% en satisfacción respecto a la comparación publicada por la compañía.
Más allá de los números concretos, el objetivo es importante:
más calidad
↑
│ frontier model
│ ●
│ ● router
│ ●
└────────────────────────→ costeEl router intenta mover el sistema hacia afuera en la frontera de Pareto:
- misma calidad por menos dinero;
- o más calidad por un coste similar.
Ésa es una forma mucho más útil de evaluar routing que simplemente contar cuántas veces eligió “el modelo más inteligente”.
El detalle que muchos routers ignoran: cambiar de modelo puede romper la caché
El coste de un sistema multi-modelo no depende únicamente del precio nominal de los tokens.
Supongamos que una conversación larga ya tiene contexto cacheado en un proveedor.
Cambiar de modelo puede producir:
modelo A
contexto cacheado ✅
↓
router cambia a modelo B
↓
cache miss
↓
reprocesar contexto
↓
coste adicionalCursor dice que entrenó y evaluó su router teniendo en cuenta esos efectos, incluyendo los cache misses causados por switches de modelo.
Eso importa porque un router que ignore el cache podría verse excelente en un spreadsheet y resultar más caro en producción.
La economía real es:
precio del modelo
+
tokens reales
+
cache behavior
+
reintentos
+
latencia
+
calidad obtenidaNo sólo $ / millón de tokens.
En realidad, esto se parece a un scheduler
Hay una forma útil de interpretar Cursor Router.
No es sólo un selector de LLMs.
Es un scheduler de capacidad cognitiva.
En infraestructura tradicional hacemos algo parecido:
trabajo pequeño → recurso pequeño
trabajo pesado → recurso grande
GPU workload → nodo especializado
memory-heavy → máquina optimizada para memoriaCursor intenta aplicar una lógica equivalente al reasoning:
commit sencillo → modelo eficiente
plan complejo → modelo fuerte en planificación
DevOps pesado → modelo fuerte en ejecución
UI/debugging visual → modelo fuerte en visualEsto sugiere que el futuro de las plataformas agentic probablemente se parezca menos a:
mi agente usa modelo XY más a:
mi agente tiene acceso a un pool de modelos
y una política decide cuál merece cada pasoLa selección de modelos empieza a convertirse en parte del control plane
En un sistema agentic serio ya tenemos decisiones como:
qué herramienta usar
qué permisos conceder
cuánto contexto cargar
cuándo ejecutar en paralelo
cuándo pedir aprobación
cuándo reintentar
cuándo detenerseEl routing de modelos añade otra:
cuánta capacidad cognitiva comprar para este pasoEso convierte el model router en una pieza del control plane del agente.
Una arquitectura futura podría verse así:
Agent Control Plane
│
┌─────────────────┼──────────────────┐
│ │ │
task planner tool router model router
│ │ │
│ │ ┌───────┼───────┐
│ │ cheap Sol Opus/Fable
│ │
└──────── execution / verification ─────────┘El modelo deja de ser la plataforma completa.
Se convierte en un recurso intercambiable dentro de una plataforma más grande.
Pero hay una advertencia: satisfacción no es lo mismo que corrección
El enfoque de Cursor también tiene limitaciones que vale la pena entender.
Si el reward se aproxima mediante lo que el usuario hace a continuación, pueden existir casos ambiguos.
Por ejemplo:
usuario acepta respuestapuede significar:
- era correcta;
- parecía correcta;
- el usuario no detectó el error;
- no valía la pena seguir corrigiendo.
Y:
usuario pide otro cambiopuede significar:
- la respuesta falló;
- la tarea simplemente evolucionó;
- el usuario cambió de idea.
Por eso el feedback de producción es extremadamente valioso, pero no elimina la necesidad de:
- evals independientes;
- tests;
- señales de ejecución;
- verificación del resultado;
- métricas de latencia y coste;
- experimentos A/B.
El Router es un sistema estadístico, no una prueba de corrección.
Otro reto: el frontier cambia demasiado rápido
Un router entrenado hoy puede quedar viejo rápidamente.
Cada pocas semanas aparecen:
- nuevos modelos;
- nuevas versiones;
- cambios de precio;
- diferentes context windows;
- mejores tool-use policies;
- mejoras de coding;
- cambios de latencia.
Cursor ya ha añadido nuevos modelos a la mezcla después del lanzamiento y afirma que quiere que el router evolucione continuamente con esos cambios.
Eso obliga a pensar el routing como un sistema vivo:
nuevo modelo
↓
evaluación
↓
tráfico controlado
↓
medir por categorías
↓
actualizar mapa de fortalezas
↓
reoptimizar políticaLa ventaja competitiva deja de ser sólo tener acceso al mejor modelo.
También puede ser aprender más rápido cuándo usarlo.
La lección más grande: model routing es un problema de sistemas
Durante mucho tiempo hablamos de LLM routing como si fuera un simple if:
if task_is_hard:
use_expensive_model()
else:
use_cheap_model()Cursor está mostrando una versión mucho más madura.
Necesitamos combinar:
señales del request
+
historial reciente
+
complejidad estimada
+
tipo de tarea
+
fortalezas por modelo
+
confianza estadística
+
presupuesto
+
cache behavior
+
feedback real de producciónEso ya no es una feature del prompt.
Es una capa de infraestructura.
Y probablemente veremos más sistemas agentic evolucionar en esa dirección.
El futuro puede ser “model-less” desde el punto de vista del usuario
Hoy todavía preguntamos:
¿Uso Sol, Opus, Grok o Fable?
Pero ésa puede ser una etapa transitoria.
Cuando el routing mejore, la interfaz podría reducirse a algo más parecido a:
quiero minimizar coste
quiero equilibrio
quiero máxima calidadEl sistema elegiría el resto dinámicamente.
Es la misma abstracción que vimos repetirse en otras capas de computing.
El usuario expresa intención.
El scheduler asigna recursos.
Cursor Router es interesante porque lleva esa idea al recurso más nuevo del stack moderno:
la inteligencia del modelo también puede programarse, medirse y asignarse como capacidad.
Y cuando eso ocurre, la pregunta deja de ser cuál es el mejor LLM del mundo.
La pregunta útil pasa a ser:
¿cuál es el modelo correcto para este paso, en este contexto, bajo este presupuesto?
Ése es el problema que los model routers están empezando a resolver.