Cursor IA: quando usar Composer 2 e Composer 2.5

No Cursor IA, o Composer 2 é um bom ponto de partida para alterações de código bem definidas e fáceis de revisar, mas Composer 2.5 é a versão atual do Composer listada pelo Cursor. Use a família Composer para implementar mudanças de forma interativa; escolha um modelo mais forte em planejamento quando a dificuldade estiver em decidir o que o sistema deve fazer. O critério é a clareza da tarefa, não apenas a quantidade de arquivos a editar.

Verificado em 14 de novembro de 2026, com base na documentação atual de modelos, nos anúncios de lançamento e no relatório técnico do Cursor. Entender o Composer 2 ainda vale a pena porque ele estabeleceu a abordagem de treinamento usada pelo sucessor. Esta análise se apoia na documentação e oferece critérios práticos de escolha; não é um benchmark feito com testes próprios.

O que o modelo Composer 2 faz no Cursor IA

Composer 2 é um modelo de programação treinado para executar tarefas de software no ambiente de agentes do Cursor. Um agente combina um modelo com ferramentas que permitem examinar um repositório, alterar arquivos e verificar o resultado. O modelo decide a próxima ação; o software ao redor a executa e devolve o resultado.

Essa diferença importa ao encontrar o Composer no seletor de modelos. Você está escolhendo a inteligência que conduz o agente, não abrindo outro editor nem ativando um recurso de preenchimento automático. O Cursor é o ambiente de trabalho; o Composer é um dos modelos disponíveis nele.

Pense em um escritório de engenharia. O modelo é o engenheiro que decide qual conexão inspecionar. As ferramentas de busca, edição e terminal são os equipamentos. Os testes são as medições que mostram se a mudança funcionou. Um engenheiro mais capaz pode tomar decisões melhores, mas nem ele nem os equipamentos compensam indefinidamente a falta de uma especificação.

Por exemplo, exibir um campo de status da conta já existente em uma tela de configurações pode exigir mudanças em um componente, no mapeamento de dados e nos testes. A tarefa envolve vários arquivos, mas o comportamento esperado está claro. É uma boa atribuição para o Composer. Redefinir o significado do status da conta na cobrança, no controle de acesso e na lógica de migração é outro tipo de trabalho: a implementação depende de decisões que precisam vir antes.

Composer 2.5 é a versão a avaliar agora

Para uma nova avaliação, a versão relevante é o Composer 2.5. O Cursor lançou o Composer 2 em 19 de março de 2026 e apresentou o Composer 2.5 em 18 de maio de 2026. O anúncio do Composer 2.5 descreve melhorias na continuidade do trabalho, no cumprimento de instruções complexas e na colaboração.

Segundo o Cursor, o sucessor calibra melhor o esforço, ou seja, quanto trabalho o modelo dedica antes de responder, e incorpora feedback textual direcionado no treinamento. Em vez de depender apenas de uma pontuação final de sucesso, o treinamento pode atacar um erro específico, como escolher uma ferramenta indisponível. O Cursor também cria tarefas sintéticas mais difíceis a partir de bases de código reais, por exemplo, removendo uma funcionalidade e pedindo ao modelo que a reconstrua de acordo com os testes.

Para quem desenvolve, a consequência é prática: um modelo pode se tornar mais útil ao evitar ações desnecessárias ou se comunicar melhor, mesmo sem um salto espetacular nos benchmarks. Para quem lidera a engenharia, esses comportamentos devem entrar na avaliação junto com a correção do código. Conte o trabalho de esclarecimento, correção e revisão que a entrega gera.

O Composer 2.5 ainda parte do mesmo checkpoint de base do Composer 2. É um sucessor com treinamento adicional; isso não significa que toda afirmação histórica sobre o Composer se aplique ao modelo atual.

Relatório técnico do Composer 2: como o Cursor o treinou

O Cursor especializou um modelo existente em programação e depois o treinou para concluir tarefas no ambiente em que os desenvolvedores o utilizam. A visão geral do treinamento descreve um pré-treinamento continuado com uma mistura de dados rica em código, seguido de aprendizado por reforço em sessões realistas do Cursor, com as ferramentas e a configuração de agente usadas no produto.

Pré-treinamento continuado é ensinar mais ao modelo de base a partir de dados, reforçando seu conhecimento de programação. Aprendizado por reforço é fazê-lo tentar resolver tarefas e ajustar seu comportamento conforme a qualidade do resultado. A primeira etapa aprimora o que ele sabe; a seguinte melhora como ele usa esse conhecimento.

O relatório técnico completo detalha o treinamento com contexto longo, exemplos supervisionados direcionados e recompensas que moldam a comunicação e o uso de ferramentas. Também descreve penalidades para desestimular esforço excessivo em pedidos simples, sem impedir que o modelo trabalhe mais em tarefas difíceis. Isso ajuda a entender o objetivo do produto: inteligência útil para programar em um ritmo que permita interação.

Composer 2 e Kimi: qual é a relação?

O Composer 2 parte do checkpoint Kimi K2.5, da Moonshot. Chamá-lo de modelo próprio do Cursor não significa que o Cursor tenha feito o pré-treinamento da base original do zero. A empresa identifica explicitamente esse ponto de partida e descreve o treinamento adicional que realizou.

Da mesma forma, partir do mesmo checkpoint não torna os sistemas em produção intercambiáveis. O treinamento posterior muda o comportamento, e o ambiente do agente determina quais ações o modelo pode executar. Para o seu repositório, o que importa é saber se o sistema completo entrega um resultado correto e fácil de revisar. A origem do modelo explica a tecnologia, mas não resolve essa avaliação.

É por isso também que dizer apenas “treinado com código” é insuficiente. A especialização do Composer envolve escolher ferramentas, reagir aos resultados e dar continuidade a uma tarefa, não apenas gerar uma função plausível em uma resposta de chat.

Contexto e ferramentas: o limite que continua valendo

A referência atual do Composer 2.5 informa uma janela de contexto de 200k tokens. Tokens são os fragmentos de texto e código que um modelo processa; o contexto é seu espaço de trabalho para uma solicitação. A documentação atual do modelo Composer lista as capacidades Agent e Thinking, além de acesso a busca, leitura e edição de arquivos, comandos de shell e outras ferramentas de agente.

A mesma página descreve ferramentas de navegador e geração de imagens. São ferramentas disponíveis no ambiente do agente; a lista não comprova que o modelo de base aceite todo tipo de entrada. Em particular, a descrição genérica de leitura de arquivos condiciona a leitura de imagens ao uso de um modelo com capacidade de visão. Não deduza visão nativa a partir dessa lista compartilhada.

Em um repositório grande, o contexto de trabalho não equivale à base de código inteira carregada permanentemente na memória. Buscar e ler os arquivos relevantes faz parte da tarefa. Uma janela ampla ajuda a acomodar evidências, mas escolher as evidências certas continua sendo essencial.

O relatório do Composer descreve a autossumarização: o modelo condensa seu histórico de trabalho para continuar uma tarefa longa. O treinamento recompensa resumos que ajudam a chegar à solução e penaliza os que perdem informações importantes. É mais parecido com um engenheiro atualizando uma nota de passagem de trabalho do que com manter todas as conversas sobre a mesa para sempre.

O obstáculo é perder uma restrição essencial, não apenas ficar sem espaço. Se uma refatoração longa esquecer que uma API antiga precisa continuar funcionando, novas edições podem agravar o erro. Registre os requisitos de compatibilidade e as verificações de aceitação em instruções persistentes do projeto ou na especificação da tarefa. Quando a conversa sair do rumo, reafirme a restrição e inspecione o diff antes de deixar o agente continuar.

Benchmarks do Composer 2: o que os resultados do Cursor demonstram

Os resultados do Cursor sustentam uma melhora substancial em programação em relação aos modelos Composer anteriores, não uma vitória universal sobre todos os modelos de ponta. O anúncio de lançamento do Composer 2 informa 61.3 no CursorBench, 61.7 no Terminal-Bench 2.0 e 73.7 no SWE-bench Multilingual. São medições do Cursor, não resultados independentes deste artigo.

O CursorBench é construído a partir de sessões de programação dos engenheiros do Cursor. O Terminal-Bench avalia o trabalho de agentes em um ambiente de terminal, enquanto o SWE-bench Multilingual avalia a resolução de issues em repositórios de diferentes linguagens. As tarefas, os critérios de pontuação e as configurações dos agentes variam. Não dá para transformar essas notas na probabilidade de sucesso da sua próxima migração.

O anúncio também explica que as comparações podem usar configurações de agente diferentes, isto é, o software ao redor de cada modelo. Essa é uma limitação relevante: quando as ferramentas e os métodos de execução mudam, não é possível separar com precisão a nota do modelo da nota do agente completo.

Benchmark do Composer 2.5: não misture as versões

As notas publicadas do Composer 2 não passam a ser notas do Composer 2.5. O anúncio do sucessor afirma melhorias de inteligência e comportamento e apresenta seu próprio material de avaliação. Para uma escolha atual, mantenha essas evidências separadas dos números do lançamento anterior.

Uma avaliação útil é uma tarefa representativa do seu repositório, com uma condição de aceitação conhecida. Um modelo que produz uma correção limpa, com testes compreensíveis, vale mais do que outro que pontua bem em outro lugar, mas obriga você a reconstruir a intenção dele. Esta é uma recomendação de avaliação, não uma afirmação de que ela foi realizada neste artigo.

Composer 2 ou Composer 2 Fast?

Segundo o Cursor, Fast é uma opção de velocidade de execução, não um modelo mais inteligente. Tanto o anúncio do Composer 2 quanto a documentação atual do Composer descrevem a variante mais rápida como tendo a mesma inteligência. Escolha-a quando o problema for a espera entre interações; não espere que respostas mais rápidas corrijam falhas de raciocínio.

A comparação histórica de velocidade usou um recorte do tráfego do Cursor de 18 de março de 2026. O Cursor observa que a velocidade varia conforme a capacidade dos provedores e muda com o tempo. Por isso, um número de tokens por segundo medido no lançamento seria uma promessa pouco confiável para a sua sessão de hoje.

Há também uma exceção atual à descrição de Fast como padrão no lançamento: no Plus, Fast fica desativado, sem opção de ativá-lo. A referência atual de modelos e planos do Cursor tem prioridade sobre o anúncio antigo para as configurações da conta. O Composer consome a franquia de uso de modelos do Cursor incluída nos planos pagos; o acesso a Claude e GPT depende de um plano elegível e de regras de uso separadas.

Para entender as mudanças mais amplas de acesso, incluindo contas atuais e legadas, veja os modelos do Cursor após a mudança de outubro. Aqui, a medida importante é conferir a variante selecionada e os controles da sua conta antes de presumir que toda sessão do Composer funciona da mesma forma.

Quando escolher Composer, Claude ou GPT

Escolha o Composer para uma alteração bem definida; recorra a um modelo mais forte em planejamento quando a incerteza dominar o trabalho. Isso segue as orientações do Cursor para escolher modelos, que posicionam o Composer para programação interativa e recomendam Anthropic Claude Opus e OpenAI GPT-5.6 Sol para tarefas complexas com várias etapas.

Alteração rápida em vários arquivos: comece pelo Composer

Suponha que você precise exibir um campo que uma API já retorna, preservar a validação existente e atualizar os testes relevantes. Diga ao Composer qual comportamento muda, qual deve continuar igual e como a conclusão será verificada. Deixe que ele localize os arquivos afetados, em vez de tentar adivinhar cada nome de arquivo.

A vantagem é um ciclo curto de feedback: inspecionar uma mudança proposta, corrigir uma suposição errada e continuar. A tarefa pode envolver muitos arquivos sem trazer incerteza arquitetural. A quantidade de arquivos é um critério ruim para escolher o modelo; as decisões ainda em aberto são um critério melhor.

Pare de insistir em prompts mais elaborados quando a mesma falha continuar aparecendo. Se os requisitos estiverem claros, mas o modelo ignorar repetidamente uma dependência, leve a reprodução do problema e o diff atual a outro modelo. Se os requisitos não estiverem claros, esclareça-os antes de trocar.

Mudança arquitetural difícil: planeje com Claude Opus ou GPT

Suponha que as permissões das contas precisem sair de verificações espalhadas pelo código e passar para uma camada compartilhada de autorização. O risco não está em escrever a função auxiliar. Está em identificar quais serviços confiam em qual identidade, preservar o comportamento existente durante a migração e decidir como revertê-la.

Use um modelo mais forte em planejamento para mapear essas dependências e questionar o desenho da migração antes de editar. A referência do Claude Opus 5.5 no Cursor lista um contexto padrão de 300k e máximo de 1M, e recomenda a variante com nível alto de raciocínio. Essa capacidade documentada é um motivo para considerá-lo quando for preciso comparar um volume substancial de evidências ao mesmo tempo. O Cursor também indica o GPT-5.6 Sol para trabalhos complexos com várias etapas.

É nessas situações que a recomendação desses modelos faz sentido: incertezas caras, longas cadeias de dependências e revisão de projeto. Isso não significa que um deles vença em toda tarefa de repositório. Depois de fechar o plano, ainda é possível avaliar o Composer para partes bem delimitadas da implementação.

Escolher um modelo Claude dentro do Cursor é uma decisão diferente de escolher o produto Claude Code. A comparação entre Claude Code e Cursor trata dessa escolha de fluxo de trabalho; mudar a inteligência dentro do editor atual não exige trocar de editor.

Onde está o exagero: gerar rápido não é concluir o trabalho

O atalho enganoso é tratar velocidade, contexto longo ou liderança em um benchmark como prova de que uma alteração está pronta para merge. O próprio Cursor descreve um modelo treinado para tarefas difíceis. Isso não elimina a necessidade de conferir se o seu requisito específico foi atendido.

Um teste pode passar enquanto o comportamento que você esqueceu de especificar continua errado. Um contexto longo pode conter um requisito de compatibilidade sem que o agente o aplique de forma consistente. Um resumo confiante pode omitir um comando que falhou. Revise as mudanças e as evidências reais, não apenas a explicação final.

Na prática, o gargalo muitas vezes deixa de ser escrever código e passa a ser revisar decisões. Se você desenvolve sozinho, mantenha as tarefas pequenas o suficiente para conseguir explicar o diff resultante. Se lidera uma equipe de engenharia, defina quais evidências uma tarefa concluída deve apresentar: comportamento afetado, testes executados, falhas ainda não resolvidas e suposições que dependem de decisão humana.

Como colocar isso em prática na segunda-feira

Quem desenvolve deve experimentar o Composer atual em uma tarefa delimitada agora; quem lidera deve esperar por evidências do próprio repositório antes de padronizá-lo para toda a equipe. Preserve a configuração que funciona até que uma tarefa representativa ofereça um motivo concreto para mudá-la.

1. 1

   Confirme o modelo selecionado

   Abra o seletor de modelos no chat ou no painel de agentes do Cursor. Confira se está selecionando a opção atual do Composer e examine os controles de velocidade disponíveis. A seleção persiste entre conversas, então não presuma que um novo chat a redefine.

2. 2

   Defina a condição de conclusão da tarefa

   Escolha um item claro do backlog. Descreva o comportamento esperado, o que deve manter compatibilidade e as verificações que comprovam o sucesso. Peça ao agente para informar qualquer verificação que não tenha conseguido executar.

3. 3

   Leve a incerteza ao modelo adequado

   Se o trabalho revelar uma decisão de projeto ainda em aberto, pause a implementação e revise essa decisão com um modelo adequado para planejamento. Leve a reprodução do problema, as restrições e o diff, em vez de uma instrução vaga para tentar com mais empenho.

4. 4

   Avalie a alteração aceita

   Revise o diff e as evidências dos testes. Mantenha o Composer como padrão onde ele entregar trabalho aceitável com um esforço de correção administrável. Preserve uma alternativa para escalar tarefas quando o projeto ou as falhas repetidas justificarem isso.

Perguntas frequentes

O que é o Composer do Cursor?

No seletor de modelos, Composer é a família de modelos de programação próprios do Cursor. Ele conduz o trabalho do agente dentro do Cursor. A versão atual documentada é o Composer 2.5.

Como saber qual versão do Composer estou usando?

Leia o nome do modelo selecionado no chat ou no painel de agentes e compare com a referência atual de modelos. Auto é uma opção de roteamento e pode usar modelos diferentes entre turnos, portanto não confirma que você esteja usando o Composer.

O Composer 2.5 é bom para programar?

O Cursor o descreve como um modelo voltado à programação interativa, com melhorias na continuidade do trabalho. Comece com uma tarefa cujo sucesso você consiga verificar. Em uma mudança arquitetural ambígua, resolva o projeto antes de avaliar a implementação.

O que é Composer e para que serve?

Neste artigo, Composer é o modelo de programação do Cursor. Você o escolhe para trabalhar em repositórios com as ferramentas do agente, principalmente quando quer orientar a implementação de forma interativa.

Como usar o Composer?

Selecione o modelo Composer atual no painel de agentes do Cursor, descreva a alteração desejada e forneça as verificações de aceitação. Inspecione as edições e os resultados das ferramentas antes de aceitar o trabalho.

Para que serve o software Composer?

No caso do Composer do Cursor, o uso relevante é engenharia de software: entender uma tarefa, examinar arquivos, fazer alterações e verificar resultados com as ferramentas do agente. Outros programas com o mesmo nome estão fora do escopo deste guia.

Como o Composer funciona?

O modelo escolhe uma ação, uma ferramenta a executa e o resultado orienta a próxima ação. O Cursor treinou o Composer em tarefas de programação dentro de um ambiente de agentes correspondente ao do produto e treinou a autossumarização para ajudá-lo a continuar trabalhos mais longos.

Existe um aplicativo Composer gratuito?

Se você está falando do modelo de programação do Cursor, o plano Free do Cursor oferece uso limitado de Agent e Chat com modelos próprios. Isso não significa uso ilimitado do Composer. Este guia não compara aplicativos de composição musical.

Para que serve composer install?

Uma busca por um comando de instalação é diferente da escolha do modelo de programação do Cursor. Para o modelo discutido aqui, use o seletor de modelos do Cursor; este guia não é uma referência de comandos de instalação.

Assine a newsletter para receber guias práticos sobre modelos de programação e as tarefas que vale delegar a eles.