Cursor 3: uma nova era da codificação com IA e agentes em paralelo

O que há de novo no Cursor 3?

A versão 3.0 é mais forte em infraestrutura do que em polimento de UI. Eis o que de fato mudou.

Workspace unificado para agentes

Toda a atividade de agentes agora vive em uma única interface. A barra lateral mostra cada agente em execução na sua máquina ou na nuvem, incluindo os iniciados a partir de Slack, GitHub, Linear, celular e web. Uma visão única.

O workspace é multi-repo por design. Um agente pode atualizar componentes de frontend enquanto outro corrige uma biblioteca de backend. Antes do Cursor 3, isso exigia janelas de IDE separadas e troca de contexto o tempo todo.

Duas adições que merecem destaque: Agent Tabs permitem ver vários chats de agentes lado a lado ou em grade. Os chats de agentes também são abas padrão do editor, então split-pane e atalhos de teclado funcionam como esperado. Sem reaprendizado. O Design Mode tem sua própria seção abaixo.

Vários agentes em paralelo

O comando /best-of-n roda no chat do agente dentro do IDE, não na Agents Window. Para usar, abra um repositório Git, abra o Agent Chat no layout clássico do editor e execute /best-of-n seguido por uma lista de modelos separada por vírgulas e sua tarefa. Exemplo: /best-of-n sonnet, gpt, composer corrija o teste intermitente de logout.

O Cursor cria uma Git worktree separada para cada modelo, impedindo que as execuções se atrapalhem. Quando o job termina, você revisa os resultados, faz commit e push a partir da worktree selecionada ou executa /apply-worktree para trazer as mudanças de volta ao seu workspace principal. Também dá para personalizar a configuração das worktrees por projeto via .cursor/worktrees.json.

Agora, o Cursor direciona execuções paralelas com múltiplos modelos pelo /best-of-n no chat do agente do IDE, enquanto o fluxo antigo de seleção deixa de ser o caminho recomendado.

O comando /worktree segue a mesma lógica: chat do agente no IDE, repositório Git obrigatório, worktree isolada por agente.

A escolha do "melhor" reflete as heurísticas de avaliação do Cursor, não necessariamente as suas. Leia os resultados por conta própria.

Observação prática: cada execução de modelo é cobrada de forma independente na sua taxa normal por tokens, sem desconto em pacote. Três modelos significam três cobranças separadas. Vou detalhar o sistema de créditos mais adiante.

Handoff entre agentes locais e na nuvem

Agentes em nuvem rodam em máquinas virtuais Ubuntu isoladas. A transferência funciona nos dois sentidos.

Mover da nuvem para o local dá acesso ao seu sistema de arquivos, servidor de desenvolvimento local e ferramentas de teste de desktop. Empurrar uma sessão para a nuvem permite que tarefas longas continuem rodando depois que você fecha o laptop. Quando o agente termina, os resultados ficam esperando na Agents Window. Agentes em nuvem também geram demos e capturas de tela do trabalho, que você pode revisar antes de puxar qualquer coisa de volta para o local.

Sessões de agentes migram nos dois sentidos entre local e nuvem. Imagem do autor.

Para times corporativos, agentes em nuvem self-hosted ficaram disponíveis em 25 de março de 2026. Código, execução de ferramentas e artefatos de build permanecem na sua própria infraestrutura. Um processo worker conecta-se para fora à nuvem do Cursor via HTTPS, sem precisar de portas de entrada ou VPN. Agentes self-hosted estão no plano Enterprise; agentes padrão em nuvem estão no Pro e superiores.

Você pode definir o ambiente de nuvem com um arquivo .cursor/environment.json na raiz do repositório. Guarde segredos na aba Secrets das Configurações do Cursor, não nesse arquivo.

Do commit ao pull request em um só fluxo

A nova interface de diffs permite ver mudanças em nível de palavra, preparar commits e abrir um pull request sem sair da Agents Window. A renderização de diffs de arquivos grandes ficou mais rápida e leve em memória no 3.0.

Ao usar /worktree no editor clássico, cada agente trabalha na sua própria worktree isolada, então os diffs já chegam limpos para revisão. Sem ter que desfazer mudanças sobrepostas.

O Cursor também anunciou um acordo definitivo para adquirir a Graphite, ferramenta de gestão de pull requests, em 18 de dezembro de 2025. Quase deixei isso de fora, já que a integração não está confirmada, mas a aquisição pode remodelar esse fluxo assim que for concluída.

Design Mode e o navegador integrado

Descrever uma mudança de UI em texto é mais lento do que apontar para ela. O Design Mode resolve isso.

Pressione Cmd+Shift+D para ativar uma ferramenta de seleção sobre o navegador integrado. Use Shift+arrastar para selecionar uma área, Cmd+L para injetar um elemento selecionado no chat do agente, ou Option+clique para adicioná-lo ao campo de entrada. O agente recebe o HTML, o CSS aplicado e a caixa delimitadora visual. Em vez de escrever um parágrafo descrevendo o problema de layout, você seleciona o elemento e diz "aperta isso".

O navegador também inclui o Chrome DevTools. Agentes podem subir um servidor local, clicar botões, ler logs do console e verificar se as mudanças realmente funcionaram.

Composer 2: o modelo de código nativo do Cursor

Composer 2 foi lançado em 19 de março de 2026, duas semanas antes do Cursor 3. É o modelo que alimenta os agentes no novo workspace.

Ele é construído sobre um Kimi K2.5 da Moonshot AI, com pré-treinamento contínuo e uma rodada de aprendizado por reforço 4x maior por cima. O Cursor não divulgou o modelo base no lançamento. Um usuário o encontrou nos headers da API no dia seguinte. O cofundador Aman Sanger reconheceu a falha: "Erramos em não mencionar a base Kimi no nosso blog desde o início. Vamos corrigir isso no próximo modelo."

Se números de benchmark não são a sua praia, a versão curta é: o Composer 2 é mais rápido e barato que alternativas de terceiros. Pule para a tabela de preços abaixo.

No CursorBench do próprio Cursor, o Composer 2 marca 61,3 contra 44,2 do Composer 1.5, um salto de ~39%. Ele roda a mais de 200 tokens por segundo, em parte por kernels de GPU customizados que o Cursor constrói internamente, em vez de depender só de stacks de inferência de terceiros. O CursorBench não é auditado de forma independente, então considere isso. O GPT-5.4 vence em tarefas mais difíceis, mas no trabalho do CursorBench (média de 352 linhas em oito arquivos), o Composer 2 supera o Claude Opus 4.6 com custo por token cerca de 90% menor. Esse gap de custo é o número mais interessante.

Aqui vai o detalhamento de preços:

Nos planos individuais pagos, o Composer 2 tem sua própria cota de uso separada dos créditos para modelos de fronteira selecionados manualmente. É baseado em gasto, não em número de requisições. O detalhamento completo de créditos está na seção de preços abaixo. O modelo tem janela de contexto de 200.000 tokens com auto-resumo: quando o contexto enche, ele comprime para cerca de 1.000 tokens e continua.

O Composer 2 é feito sob medida para codificação com agentes. Para outras coisas, ele não ajuda.

Cursor 3 como um ambiente de desenvolvimento orientado por agentes

O CEO do Cursor, Michael Truell, descreve o desenvolvimento de software com IA em três eras. Primeiro veio o autocompletar por Tab, preenchendo código repetitivo. Depois os agentes síncronos, dirigindo o modelo passo a passo. Agora, agentes em nuvem rodam de forma autônoma por períodos mais longos, com desenvolvedores atuando mais como diretores do que redatores.

Os dados de uso refletem essa mudança. Como dito, a proporção entre agentes e Tab se inverteu entre o início de 2025 e o início de 2026.

A moldura do Truell: "O Cursor não é mais, principalmente, sobre escrever código. É sobre ajudar desenvolvedores a construir a fábrica que cria seu software." Isso é uma visão, não uma descrição de produto. A maioria dos devs usando o Cursor 3 hoje ainda revisa e corrige a saída dos agentes o tempo todo. Ainda não vi um codebase em que a fábrica roda sozinha. Mas a interface foi feita acreditando que isso esteja mais perto do que parece.

Recursos-chave que permanecem e melhoram

Os recursos centrais das versões anteriores continuam lá e quase todos inalterados.

Arquivos e entendimento de código

O suporte completo ao Language Server Protocol (LSP) permanece. Ir para definição, busca por símbolos, documentação ao passar o mouse e navegação por arquivos funcionam como no VS Code. Referências de contexto como @Files, @Folders e @Docs são suportadas. A Agents Window não remove o acesso em nível de arquivo; ela adiciona uma camada acima.

Cursor Marketplace e plugins

O Cursor Marketplace adiciona capacidades aos agentes com instalações de plugin em um clique. Um plugin reúne alguma combinação de Skills (prompts que os agentes invocam sob demanda), Subagents, servidores MCP, Hooks e Rules. O detalhamento completo está na documentação do Cursor.

Os plugins disponíveis cobrem um amplo leque: AWS, Figma, Linear, Stripe, Vercel, Datadog, Snowflake e mais. Planos Teams e Enterprise podem criar marketplaces privados da equipe. No Enterprise, a importação de plugins de terceiros vem desativada por padrão, a menos que um admin ative.

Uma lacuna que não deveria existir: não há uma UI nativa para definir variáveis de ambiente dos servidores MCP de plugins do Marketplace. O contorno é adicionar o servidor manualmente em ~/.cursor/mcp.json com um campo env e desativar a entrada duplicada nas Configurações do Cursor. Funciona, mas é o tipo de coisa que não deveria exigir gambiarra em um produto pago.

Automations

As Automations, lançadas em 5 de março de 2026, são agentes sempre ativos disparados por eventos externos: agendas, mensagens no Slack, issues no Linear, eventos no GitHub e incidentes no PagerDuty. O agente sobe um sandbox em nuvem e segue instruções usando MCPs e modelos configurados. Com memory ativada, o agente acessa um bloco de notas persistente (arquivos de texto pequenos como MEMORIES.md que sobrevivem entre execuções). O próprio agente decide o que anotar: progresso, padrões que identificou, contexto de execuções anteriores. Na próxima execução, ele lê essas notas e continua dali. Você pode ver e editar esses arquivos na seção Automations do dashboard.

Preços do Cursor 3 e requisitos de plano

Nem todos os recursos estão em todos os planos. Aqui está o panorama atual:

Agentes em nuvem e o Composer 2 exigem Pro ou superior. Marketplaces de equipe exigem Teams ou Enterprise, e agentes em nuvem self-hosted são exclusivos do Enterprise.

O Cursor opera duas cotas de créditos separadas em planos individuais pagos: uma para o modo Auto e uso do Composer, descrita pelo Cursor como "generosa" sem teto publicado, e outra para modelos de fronteira selecionados manualmente, como Claude ou GPT. Quando você escolhe um modelo manualmente, ele consome dessa cota. O modo Auto não.

Observação para heavy users: devs no plano Pro que rodam sessões de agentes com frequência relatam gasto real mais perto de US$ 40 a US$ 50 por mês quando entram as excedências. Os US$ 20 são o piso.

Como o Cursor 3 muda o fluxo de trabalho do desenvolvedor

Aqui vai uma comparação concreta para uma tarefa padrão de API de backend:

A mudança não é de difícil para fácil. É de escrever para dirigir. Você gasta menos tempo na implementação e mais em definir requisitos e revisar a saída. Se a troca vale a pena depende da tarefa e, honestamente, de quanto você confia no agente naquele dia.

Tarefas longas são as que mais se beneficiam. Um refactor que levaria horas no terminal pode ir para um agente em nuvem; você fecha o laptop, o agente continua e os diffs ficam te esperando quando você volta.

Cursor 3 vs. versões anteriores do Cursor

O Cursor inicial (2022 a 2024) era uma ferramenta IDE-first. Edição de arquivos com IA em um ambiente VS Code.

Cursor 1.0 (junho de 2025) foi o primeiro release estável. O Cursor 2.0 (outubro de 2025) trouxe o primeiro modelo Composer e o navegador embutido. O Cursor 2.5 (fevereiro de 2026) adicionou subagentes assíncronos e o marketplace de plugins. O Cursor 2.6 (março de 2026) adicionou marketplaces de equipe.

O Cursor 3.0 oficializa a virada. Agentes em nuvem saíram totalmente do Editor e agora vivem exclusivamente na Agents Window. O suporte a worktree também mudou: o antigo dropdown foi descontinuado e substituído pelos comandos /worktree e /best-of-n , que rodam no chat do editor clássico. Se você tem documentação interna ensinando a usar o dropdown de worktree ou iniciar agentes em nuvem de dentro do Editor, ela está desatualizada.

O Cursor aproveitou a reconstrução do 3.0 para quitar dívida de performance do 2.x: correções de vazamento de memória e CPU, React Compiler. Robinson descreveu o resultado como mais rápido e menos sujeito a engasgos de UI. Windows é totalmente suportado, e a interface lida com múltiplos workspaces em uma única janela.

O salto do 2.x para o 3.0 é mais estrutural do que parece. Versões anteriores adicionavam recursos de agente a um IDE. O Cursor 3 adiciona um IDE a uma plataforma de agentes. A ordem importa.

Cursor 3 vs. IDEs tradicionais

IDEs tradicionais são centrados em arquivos. Você abre um arquivo, edita texto e o IDE ajuda a digitar mais rápido. Mesmo com o GitHub Copilot instalado, a abstração continua sendo o documento.

O Cursor 3 coloca o arquivo em segundo plano. A interface principal é a fila de tarefas. O IDE vira o fallback para edições específicas demais para descrever em um prompt.

A comparação, porém, está ficando mais turva. O GitHub Copilot agora oferece agentes em nuvem e code review em planos individuais. A JetBrains inclui o Junie, seu agente autônomo, nas assinaturas de IA. E, como mencionado, o Cursor agora roda dentro dos IDEs JetBrains via ACP. Todo mundo tem agentes agora. A diferença real do Cursor 3 é que o workspace foi construído ao redor deles, e não adicionado a um editor existente.

Limitações e pontos em aberto

A experiência do dia a dia tem mais atrito do que o material de lançamento sugere.

Supervisão do desenvolvedor

Agentes cometem erros. Em tarefas complexas envolvendo vários arquivos, eles cometem muitos. Revisar a saída do agente exige familiaridade suficiente com o codebase para identificar suposições incorretas, funções alucinadas e lógicas que quase funcionam. O tempo poupado na escrita migra para leitura e validação. Desenvolvedores que não conseguem ler o código gerado para checá-lo não conseguirão manter o codebase funcionando. Isso não é uma crítica ao Cursor especificamente; vale para qualquer ferramenta de codificação com agentes.

Confiabilidade de agentes em nuvem

Falhas na configuração de ambiente são um problema documentado e recorrente. Segredos não podem ser injetados durante o script inicial de setup, apenas após o setup. Sessões paralelas estendidas consomem muitos recursos; usuários relataram uso pesado de RAM em máquinas que deveriam dar conta. Mantenha sessões abaixo de duas horas quando possível e adicione checkpoints de reindexação para qualquer coisa mais longa.

Mais uma lacuna específica: o Plan Mode ainda não está disponível na interface web do Cursor. Dá para iniciar e rodar agentes em nuvem, inclusive o planejamento, no app desktop do Cursor 3, mas não diretamente em cursor.com/agents.

Há também um bug conhecido em que agentes travam quando a Agents Window não está em foco. Foi relatado logo após o lançamento e seguia sem correção no início de abril de 2026. Para uma ferramenta construída em torno de sessões longas, isso é um problema real.

Sobre agentes paralelos de forma mais ampla: pesquisa do Google DeepMind sobre sistemas multiagente encontrou amplificação de erros de até 17,2 vezes em redes não estruturadas. Mesmo com 99% de confiabilidade por agente, dez agentes encadeados caem para cerca de 90% no total. O comando /best-of-n usa worktrees isoladas, o que limita parte disso. Não elimina.

Considerações de segurança

Duas CVEs foram encontradas e corrigidas em 2025. A CVE-2025-54136 (MCPoison) permitia que ferramentas MCP aprovadas tivessem seus comandos modificados silenciosamente; corrigida na versão 1.3. A CVE-2025-64106 era uma vulnerabilidade de execução remota via deep link, com severidade 8,8, corrigida em dois dias. O Workspace Trust também vem desativado por padrão. Se você conecta ferramentas MCP em ambientes sensíveis, isso importa.

Agentes em nuvem self-hosted, como já mencionado, mantêm o trabalho do agente dentro da sua rede, mas a plataforma Cursor não está disponível como implantação totalmente on-premises. O Cursor não possui certificações FedRAMP ou HIPAA. A disponibilidade de BAA não é documentada publicamente, então confirme diretamente com o Cursor antes de depender disso para compliance. Se o seu ambiente exige FedRAMP ou implantação totalmente on-premises, o Cursor 3 não serve.

Mais duas limitações práticas: o Design Mode atualmente funciona apenas no Chrome; Firefox e Safari não são suportados. E, nos dias após o lançamento do Cursor 3, a comunidade relatou consumo de tokens do Composer 2 cerca de 10 vezes acima do normal para alguns usuários, ligado a problemas de leitura de cache.

O modelo de créditos

Como cobri na seção de agentes paralelos, cada modelo no /best-of-n é cobrado separadamente. Uma comparação com três modelos em uma tarefa complexa pode drenar grande parte da sua cota mensal em uma única sessão.

Quem deve usar o Cursor 3?

Se você já roda fluxos com agentes e quer tudo em um só lugar, isso foi feito para você. Faz mais sentido para times que trabalham em múltiplos repositórios, para tarefas longas que podem ser delegadas à nuvem e para equipes enterprise que precisam manter o código dentro da própria infraestrutura.

Eu não recomendaria para iniciantes. Não porque seja difícil de usar, mas porque agentes produzem código que você precisa ler com senso crítico. Se você não consegue perceber quando a saída está errada, não consegue consertar, e em seis meses o codebase vai refletir isso. Para scripts simples ou tarefas pontuais, o overhead de setup também não compensa. E se o seu ambiente é regulado por HIPAA ou é air-gapped, veja a seção de Segurança antes de avançar.

Monorepos legadas e muito grandes também são um problema real. As janelas de contexto ainda quebram nelas.

O futuro da codificação com IA no Cursor

Em fevereiro de 2026, o Cursor publicou "Towards Self-Driving Codebases", descrevendo experimentos com milhares de agentes orquestrados em grandes codebases. O objetivo declarado: "até que codebases sejam autônomas".

As janelas de contexto ainda quebram em monorepos grandes. Agentes alucinam com frequência. A visão ainda está longe; eu não planejava nada dependendo dela.

O que o Cursor 3 faz é colocar as peças principais no lugar: um modelo (Composer 2), uma interface (Agents Window), VMs em nuvem como runtime e opções self-hosted para enterprise. A codebase autônoma depende de avanços de modelos que o Cursor não controla totalmente.

A metáfora da "fábrica" do Truell ainda está distante da realidade. Por enquanto, é você quem continua fiscalizando o chão de fábrica.

Conclusão

A principal mudança do Cursor 3 não é um recurso. É o fato de que a interface foi reconstruída partindo de outra premissa: o agente, não o arquivo, é a unidade de trabalho. Dois anos atrás isso era uma aposta. Os dados de uso sugerem que ela está valendo a pena.

Se ele se encaixa no seu fluxo depende de coisas que eu não consigo determinar daqui: tamanho do codebase, requisitos de segurança e se você topa conviver com um produto lançado há poucas semanas e que ainda tem arestas. Se estiver em dúvida, eu releria a seção de Limitações antes de decidir.

Se você quiser ir além com o Cursor na prática, nosso curso Software Development with Cursor cobre prompting, refatoração, testes e fluxos com agentes.