Cursor: дешёвые модели пишут код по плану frontier-моделей — стоимость упала в 15 раз

Em julho de 2026, a Cursor realizou um experimento: fez um enxame de agentes de IA reescrever do zero o banco de dados SQLite em Rust, tendo apenas a documentação — sem código-fonte, sem acesso à internet e sem testes prontos. A nova versão do "enxame" (agent swarm), que separa um modelo planejador dos modelos executores, acabou passando em 100% do conjunto de testes em todas as configurações, e a solução mais barata custou 15 vezes menos do que um único agente top de linha.

O que exatamente a Cursor testou

A Cursor deu aos agentes uma única tarefa — recriar o SQLite em Rust do zero, baseando-se apenas na documentação oficial. O resultado final foi verificado no benchmark sqllogictest, com milhões de consultas SQL; segundo a Cursor, cada configuração do novo sistema acabou chegando a 100% de aprovação nos testes, enquanto o "enxame" antigo ficava travado na faixa de 11–77%.

A ideia central da nova arquitetura é separar os papéis. O modelo frontier, caro, funciona como planejador: divide a tarefa e toma as decisões arquiteturais. A maior parte do código rotineiro é escrita pelos modelos worker baratos.

• Tarefa: reescrever o SQLite em Rust apenas com base na documentação, sem código-fonte nem internet
• Planejadores: GPT-5.5, Grok 4.5, Opus 4.8, Fable 5
• Executor: Composer 2.5 (também foi testado como agente único para comparação)
• Verificação: benchmark sqllogictest, milhões de consultas SQL
• Novo sistema após 4 horas: 73–85% no início, todos chegaram a 100%; o antigo: 11–77%

Por que o planejador elimina o caos

A separação de papéis livra o enxame dos conflitos de merge que ele mesmo costumava criar. Na configuração com Grok 4.5, o sistema antigo gerou 68.000 commits e mais de 70.000 conflitos de merge em duas horas — e se afogou neles. O novo enxame manteve um ritmo de cerca de 1.000 commits por segundo e, mesmo assim, nunca ultrapassou 1.000 conflitos simultâneos.

A diferença também aparece no volume de código, com qualidade comparável. A combinação "Fable 5 planeja + Composer escreve" ficou em 9.908 linhas, contra 64.305 da abordagem antiga. A dupla "Opus 4.8 + Composer" — 4.645 linhas, contra 19.013. Menos código significa menos bugs e manutenção mais barata.

Quanto foi possível economizar

O custo das execuções variou 15 vezes para um resultado comparável: de $1.339 pela combinação "Opus 4.8 + Composer" até $10.565 por um GPT-5.5 sozinho. Segundo a Cursor, os modelos worker consumiam 69–90%+ de todos os tokens, mas, devido à diferença de preços, a contribuição deles para a conta final foi bem mais modesta — pagar caro, no fim das contas, é sobretudo pelo planejamento.

O modelo frontier assume a decomposição e as decisões-chave, enquanto

os modelos worker mais baratos executam o plano com eficiência assim que a ambiguidade é removida — essa é a principal conclusão da equipe da Cursor após o experimento.

O que isso significa

A economia da programação com IA está mudando: pagar pelo modelo top de linha faz sentido na etapa de planejamento, enquanto a implementação em si pode ser entregue a executores baratos quase sem perda de qualidade. Para as equipes, isso significa uma redução multiplicada nos custos da geração autônoma de código — desde que alguém inteligente divida a tarefa corretamente.

Perguntas frequentes

O que é um agent swarm na Cursor?

Agent swarm é um enxame de vários agentes de IA que trabalham em paralelo na mesma tarefa. Na nova versão, a Cursor os dividiu em um planejador (um único modelo caro) e executores (muitos baratos), o que eliminou os conflitos de merge em massa.

Quais modelos planejavam e quais escreviam o código?

Os planejadores foram GPT-5.5, Grok 4.5, Opus 4.8 e Fable 5. O código foi escrito pelo modelo Composer 2.5 — que também foi testado sozinho para comparação.

Quanto mais barato ficou o código?

A variação foi de 15 vezes: de $1.339 pela combinação Opus 4.8 + Composer até $10.565 por um GPT-5.5 sozinho, com qualidade de resultado comparável.