stamatios
← Voltar ao feed
Como o Cursor Router escolhe o modelo certo para cada tarefa
IA & Modelos · Dev & Engenharia

Como o Cursor Router escolhe o modelo certo para cada tarefa

resumo de ~3 min

O Cursor Router, lançado em 22 de julho de 2026 com duas configurações (Auto Intelligence e Auto Balance), é o sistema que decide qual modelo de IA usar para cada turno de trabalho no Cursor. O Auto Intelligence entrega satisfação de usuário acima do nível Fable com custo 68% menor, e o Auto Balance supera o Opus 4.8 com custo 41% menor e satisfação 3% superior.

Abordagem data-driven

A premissa central é que a seleção de modelo deve ser aprendida a partir do desempenho real em trabalho de desenvolvedores, não de benchmarks. O router usa sinais do turno atual e do estado recente da conversa (categoria da tarefa, tool calls recentes, contexto mais amplo). A decisão acontece em duas etapas: primeiro, o Compass (preditor de complexidade) decide se o turno é simples o suficiente para um modelo de baixo custo; segundo, se for complexo, uma taxonomia de tarefas, domínios e modificadores determina qual modelo frontier tem melhor desempenho naquele tipo de trabalho.

Dataset

O dataset foi construído com tráfego real do Cursor - centenas de milhares de turnos amostrados entre diferentes modelos. Cada ponto de dado registra os sinais disponíveis ao router e dois resultados: performance (inferida pela ação seguinte do usuário - avançar para a próxima tarefa é positivo, corrigir o agente é negativo) e custo (preço de API × tokens, incluindo cache misses causados por troca de modelo).

Compass: predição de complexidade

O Compass estima a complexidade de cada turno prevendo se o usuário ficará satisfeito com a resposta. Funciona como proxy de complexidade porque usuários raramente pedem correções em tarefas simples (ex: fazer um commit), mas frequentemente fazem follow-ups em tarefas complexas. Turnos que o Compass classificou como mais prováveis de sucesso receberam sinal positivo 96% das vezes; os menos prováveis, 71%. Na prática, o Compass atribui um score contínuo entre 0 e 1; um threshold determina quais turnos ficam no modelo barato e quais são escalados para um frontier.

Forças de cada modelo

A taxonomia classifica cada turno em três dimensões: domínios (backend, frontend, schemas de banco), tarefas (corrigir bugs, rodar comandos, escrever testes) e modificadores (edições delimitadas, perguntas de produto, mudanças visuais). Nenhum modelo domina tudo:

  • Grok: bom custo-benefício em trabalho rotineiro (comandos Git, operações de banco).
  • Sol: forte em planejamento e compreensão de codebase.
  • Opus: bom em trabalho de execução pesada (devops, queries, otimização de performance).
  • Fable: excelente em debugging e implementação visual, justificando custo maior em tarefas complexas.

Algoritmo combinado

Se o score do Compass fica abaixo do threshold, o turno vai para o modelo de baixo custo (Grok). Se acima, o task router aplica duas regras: (1) só rotear para um modelo quando há 75% de confiança estatística de que a melhoria é real; (2) escolher a combinação que maximiza ganho de performance dentro do orçamento de custo médio por turno. Auto Balance mantém mais tráfego no caminho barato com orçamento menor; Auto Intelligence dá mais liberdade para selecionar modelos frontier.

Avaliação em produção

A avaliação usa cross-validation offline para tunar thresholds e orçamentos, seguida de testes em tráfego real. O tráfego ao vivo captura efeitos difíceis de modelar offline (uso de tokens, caching, custo de troca de modelo). Desde o lançamento, o sistema já adicionou o Opus 5 ao mix e melhorou as predições do Compass.

Direção futura

O objetivo é tornar o router mais adaptativo: prever qualidade e custo esperados de cada modelo, aprender continuamente com resultados de produção e atualizar-se automaticamente à medida que novos modelos chegam ao mercado.