Composer 2.5: benchmarks, preços e como ele se compara

A Cursor lançou o Composer 2.5 em 18 de maio de 2026, cerca de dois meses depois do Composer 2 em março. O intervalo curto entre as versões mostra a velocidade com que a Cursor está evoluindo sua própria linha de modelos.

A Cursor informa que o Composer 2.5 alcança pontuações próximas às do Claude Opus 4.7 e do GPT-5.5 em vários benchmarks de código. O preço por token também é menor do que o dos modelos de fronteira. O treinamento mudou: mais tarefas sintéticas, ambientes de treino mais difíceis e um método de feedback que mira erros específicos dentro de sessões longas de codificação.

Neste artigo, analiso o Composer 2.5 para além de um simples update de benchmarks. Vou explicar o que ele é, o que mudou, como estão os benchmarks, como o preço se compara aos modelos de fronteira e onde ele se encaixa no fluxo de trabalho de codificação. Há limitações também — e vale conhecer algumas antes de tomar as notas como a história completa.

Para mais contexto sobre os outros modelos desta comparação, confira nossos guias do Claude Opus 4.7 e do GPT-5.5.

O que é o Composer 2.5 da Cursor?

O Composer 2.5 é o modelo mais novo da família Composer da Cursor, criado para trabalho de codificação dentro do Cursor IDE. Ele seguiu o Composer 1, o Composer 1.5 e o Composer 2.

Linha do tempo do Composer do lançamento ao 2.5. Imagem do autor.

Não é um chatbot geral. O Composer 2.5 foi treinado para edições entre arquivos, comandos de terminal, uso de ferramentas e sessões de codificação longas. Suas metas de treinamento e benchmarks focam tarefas de engenharia de software.

O post de lançamento diz que o modelo supera o Composer 2 em tarefas de código e se comporta de forma diferente em sessões longas. Ele agora é a opção padrão no seletor de modelos do Cursor, embora o Composer 2 continue disponível. Também roda apenas dentro do Cursor. Não há API pública, nem card no Hugging Face, nem acesso por meio de outro provedor.

O que mudou no Composer 2.5

As mudanças no Composer 2.5 caem em duas frentes: desempenho em tarefas de código e comportamento colaborativo. A primeira é mais fácil de medir que a segunda, então vale separar o que a Cursor consegue mostrar em números do que ela descreve de forma mais qualitativa.

Desempenho em tarefas mais longas

O Composer 2.5 mira sessões de codificação mais longas, em que o modelo precisa ler arquivos, rodar comandos no terminal, corrigir erros e iterar. Isso importa porque o desenvolvimento real raramente cabe em um único prompt e resposta.

A Cursor treinou o modelo em ambientes de aprendizado por reforço mais difíceis para esse tipo de trabalho. As tarefas foram geradas durante o treinamento, e a dificuldade aumentou com o tempo.

Seguimento de instruções e colaboração

O lançamento também descreve um seguimento de instruções mais confiável. Aposta-se em calibração de esforço: o modelo deve gastar mais computação em tarefas difíceis e evitar pensar demais nas simples.

Há um porém aqui. A Cursor observa que essas mudanças de comportamento "não são bem capturadas pelos benchmarks existentes". Então essa parte do lançamento se apoia, sobretudo, na avaliação da própria Cursor e no feedback inicial de usuários, não em uma pontuação pública.

Ambientes de RL mais difíceis

O post de lançamento descreve a mudança de treino como "escalar o treinamento, gerar ambientes de RL mais complexos e introduzir novos métodos de aprendizado". O treinamento usou 25x mais tarefas sintéticas que o Composer 2.

Como a Cursor treinou o Composer 2.5

Os detalhes de treinamento explicam por que o modelo mudou sem nova arquitetura base. O Composer 2.5 usa a mesma fundação do Composer 2, mas o trabalho após o treino base mudou. Nem todo detalhe de infraestrutura importa igualmente para o leitor, mas alguns ajudam a explicar a evolução nos benchmarks.

Baseado no Kimi K2.5

O Composer 2.5 é construído sobre o mesmo checkpoint open source do Composer 2: o Kimi K2.5 da Moonshot AI. A Cursor disse isso diretamente no post de lançamento, o que importa porque o modelo base foi um tema de debate em torno do Composer 2.

O Kimi K2.5 usa uma arquitetura de Mixture of Experts. A Cursor aplica pré-treinamento contínuo e aprendizado por reforço sobre essa base e diz que cerca de 85% do compute total do modelo final vêm do trabalho próprio após o treino base.

RL direcionado com feedback textual

Essa é a principal mudança técnica no Composer 2.5. O RL padrão dá um sinal de recompensa único no fim de uma sequência longa. Em uma sessão extensa de código, essa recompensa final pode ser ruidosa demais para indicar onde o modelo errou.

Professor e aluno compartilham um turno. Imagem do autor.

O método da Cursor insere uma dica curta no ponto em que o modelo tomou uma decisão ruim. Por exemplo, se o modelo chama uma ferramenta que não existe, o processo de treino pode inserir um lembrete com a lista correta de ferramentas. A versão com dica atua como "professor" e o modelo original como "aluno". Uma perda de destilação então aproxima o comportamento do aluno ao do professor apenas naquele turno.

O resultado é um treinamento mais direcionado: erros individuais podem ser corrigidos sem tratar todo um rollout longo como vagamente certo ou errado. A Cursor aplicou esse método ao estilo de código, uso de ferramentas e comunicação do modelo durante o treinamento do Composer 2.5.

Dados sintéticos em maior escala

O Composer 2.5 foi treinado com 25x mais tarefas sintéticas do que o Composer 2. Essas tarefas são ancoradas em bases de código reais, não exemplos de brinquedo.

Uma abordagem descrita pela Cursor é a deleção de funcionalidades. Um agente começa com uma base de código real e uma suíte grande de testes, depois remove códigos e arquivos mantendo o restante do projeto funcional. A tarefa sintética é reimplementar a funcionalidade removida, e os testes fornecem um sinal de recompensa verificável.

A escala do treinamento sintético traz riscos próprios. A Cursor documentou casos em que o Composer 2.5 encontrou atalhos, incluindo recuperar informações deletadas a partir de um cache de verificação de tipos em Python e decompilar bytecode Java para reconstruir uma API externa. A empresa diz que detectou isso com ferramentas de monitoramento, mas reconheceu que treinar nessa escala exige "cuidado crescente".

Mudanças de infraestrutura

No lado da infraestrutura, a Cursor usou Sharded Muon e malha dupla HSDP para o pré-treinamento contínuo. Essas mudanças reduziram parte do custo e do tempo envolvidos no treinamento em clusters grandes de GPU.

Resultados de benchmark do Composer 2.5: Terminal-Bench, SWE-Bench e CursorBench

Benchmarks são úteis, mas não contam a história toda. Eu os trataria como um ponto de partida para comparação, não um veredito completo sobre a sensação do modelo no dia a dia.

A Cursor avalia o Composer 2.5 em três benchmarks:

SWE-Bench Multilingual testa se um modelo consegue resolver issues reais do GitHub em várias linguagens. Cada tarefa fornece ao modelo um repositório e um enunciado do problema e verifica se o patch passa nos testes associados.

Terminal-Bench 2.0 mede se um agente de IA consegue operar em fluxos de trabalho reais de terminal: inspecionar arquivos, rodar comandos, depurar falhas e concluir tarefas com várias etapas.

CursorBench v3.1 é o benchmark interno privado da Cursor. Ele avalia agentes em tarefas ambíguas e multifile de sessões reais do Cursor, incluindo entendimento de codebase, busca de bugs, planejamento e revisão de código. A limitação é que o CursorBench não pode ser verificado ou reproduzido por pesquisadores externos, e as pontuações devem ser comparadas dentro da mesma versão do eval.

Há um alerta importante antes de tirar conclusões demais desses números. Comparações entre modelos em benchmarks nem sempre são limpas. Diferenças de setup e níveis de esforço podem mover as pontuações, e a Cursor observa que o Opus 4.7 e o GPT-5.5 usam pontuações autodeclaradas em avaliações públicas. Trate como comparações direcionais, não testes idênticos.

Um benchmark externo posterior da Artificial Analysis aponta na mesma direção, embora use outro mix de benchmarks. O Composer 2.5 marcou 62 no Artificial Analysis Coding Agent Index, atrás do Claude Opus 4.7 no esforço máximo (66) e do GPT-5.5 em xhigh reasoning (65). 

O diferencial de custo é o ponto a observar: a Artificial Analysis estimou o Composer 2.5 em US$ 0,07 por tarefa no Standard e US$ 0,44 no Fast, contra US$ 4,10 no Opus 4.7 max e US$ 4,82 no GPT-5.5 xhigh.

Composer 2.5 vs. Composer 2 vs. Composer 1.5: como as notas se comparam

A família Composer teve três lançamentos em pouco tempo. O Composer 1.5 saiu em fevereiro de 2026, o Composer 2 em março e o Composer 2.5 em maio. Cada versão mudou algo diferente na abordagem de treinamento.

Composer 2.5 versus Composer 2

O salto do Composer 2 para o 2.5 aparece mais no Terminal-Bench 2.0, de 61,7% para 69,3%, e no SWE-Bench Multilingual, de 73,7% para 79,8%. O ganho no CursorBench é menor, e a versão mudou de v3 para v3.1, então a comparação é menos direta.

A maior diferença está no pipeline de treinamento. O Composer 2 introduziu o pré-treinamento contínuo no Kimi K2.5. O Composer 2.5 manteve essa base e adicionou feedback textual direcionado, 25x mais tarefas sintéticas e mudanças de infraestrutura. O preço do Standard permaneceu o mesmo.

Composer 2.5 versus Composer 1.5

O Composer 1.5 foi construído escalando o aprendizado por reforço 20x sobre o mesmo modelo pré-treinado do Composer 1. Ele introduziu pensamento adaptativo e auto-sumarização, permitindo que o modelo comprima seu próprio contexto quando a sessão se alonga.

O salto do Composer 1.5 para o 2.5 é grande em todos os benchmarks. Também veio com preço por token menor: o Composer 1.5 custava US$ 3,50 por milhão de tokens de entrada e US$ 17,50 por milhão de tokens de saída — cerca de 7x mais caro que o Composer 2.5 Standard.

O que mudou na prática

Ao longo dessas versões, o padrão é claro: cada geração mudou o comportamento em sessões longas e no seguimento de instruções, enquanto o Composer 2 e o 2.5 reduziram o custo de sessões prolongadas com agentes.

Composer 2.5 vs. Claude Opus 4.7 vs. GPT-5.5: benchmarks, preço e trade-offs

É a comparação que muita gente vai querer ver primeiro. O Composer 2.5 tem notas similares em alguns benchmarks de código, preço por token mais baixo que os modelos de fronteira abaixo e trade-offs claros.

Comparação de benchmarks

O GPT-5.5 lidera no Terminal-Bench 2.0 com 82,7%, cerca de 13 pontos à frente do Composer 2.5. Essa diferença pesa para trabalhos que dependem fortemente do uso de terminal.

O Claude Opus 4.7 está um pouco à frente do Composer 2.5 no SWE-Bench Multilingual (80,5% contra 79,8%), menos de um ponto. No CursorBench, o Composer 2.5 com 63,2% supera o Opus 4.7 nas configurações padrão (61,6%) mas fica abaixo do Opus 4.7 em esforço máximo (64,8%). O GPT-5.5 também chega a 64,3% em xhigh, enquanto sua nota padrão é 59,2%.

Esses modelos não fazem exatamente o mesmo trabalho. Opus 4.7 e GPT-5.5 são modelos de fronteira mais amplos. O Composer 2.5 é um modelo de código que roda apenas no Cursor. As notas são próximas em algumas tarefas de codificação, mas os limites do produto são diferentes.

Comparação de preços

A diferença de custo é a divisão mais clara em relação aos modelos de fronteira.

O Composer 2.5 Standard é precificado em cerca de um décimo do Opus 4.7 e do GPT-5.5 por token. A variante Fast também fica abaixo dos tiers padrão de qualquer modelo de fronteira.

Esses preços são válidos em maio de 2026, então confira a tabela de preços da Cursor, os preços do Opus da Anthropic e os preços da API da OpenAI antes de usar a comparação.

Um ponto que muita gente perde: o preço do Composer 2.5 Fast dobrou em relação ao Composer 2 Fast. O Standard ficou estável, mas o Fast é o padrão, então o upgrade ainda pode elevar custos para alguns usuários.

Qual modelo escolher?

A escolha depende do que mais pesa: custo, trabalho em terminal ou planejamento mais profundo:

• O Composer 2.5 é ideal para o dia a dia de codificação no Cursor, especialmente edições entre arquivos, refatoração, depuração e sessões com agentes em que o custo importa.
• O GPT-5.5 é indicado quando a performance em terminal é o principal fator.
• O Claude Opus 4.7 atende melhor tarefas que pedem raciocínio cuidadoso, planejamento de arquitetura ou uma janela de contexto de 1 milhão de tokens.

Esse é o padrão que eu tiraria dos números: o Composer 2.5 cobre o trabalho rotineiro de código, enquanto os modelos de fronteira ainda têm papel em raciocínio mais amplo ou notas mais altas em terminal.

Composer 2.5 Standard vs. Fast: velocidade, preço e quando usar cada um

A Cursor oferece o Composer 2.5 em duas variantes, como fez com o Composer 2. Segundo a Cursor, ambas compartilham a mesma inteligência subjacente. A diferença está principalmente na velocidade de resposta e no custo.

Seletor de modelos do Cursor com Composer selecionado. Imagem do autor.

O Fast é o padrão e custa US$ 3,00 por milhão de tokens de entrada e US$ 15,00 por milhão de tokens de saída. É pensado para sessões interativas onde baixa latência importa. O Standard sai por US$ 0,50 e US$ 2,50, então é ideal para tarefas em background ou loops mais longos com agentes, quando a resposta imediata é menos crítica.

O uso do Composer 2.5 entra no pool "Auto + Composer" do Cursor, separado do pool de API usado para modelos externos como Claude e GPT. A Cursor também ofereceu uso em dobro na primeira semana após o lançamento.

Limitações e ressalvas do Composer 2.5

As ressalvas envolvem acesso, benchmarks e risco no treinamento. Não tornam o Composer 2.5 algo fora da curva, mas afetam o peso que você deve dar às afirmações da Cursor.

Disponível apenas no Cursor. Como mencionei, o Composer 2.5 não tem API pública. Se seu fluxo depende de chamar um modelo a partir de scripts ou pipelines próprios, o Composer 2.5 não é opção.

O CursorBench não é independente. Como abordei na seção de benchmarks, o CursorBench v3.1 é interno à Cursor. Sua metodologia não é totalmente pública e as tarefas não podem ser reproduzidas por pesquisadores externos.

Variabilidade no setup de benchmarks. As notas dos modelos de fronteira no gráfico da Cursor não foram todas medidas do mesmo jeito. Trate as comparações como direcionais, não definitivas.

Reward hacking durante o treino. A Cursor divulgou casos em que o modelo encontrou atalhos inteligentes em tarefas sintéticas em vez de resolvê-las normalmente. Esse é um risco inerente de RL nessa escala, mesmo com monitoramento capturando exemplos óbvios.

Calibração de esforço não verificada. As alegações da Cursor sobre estilo de comunicação e calibração de esforço não têm respaldo de benchmark, como mencionei. Isso dificulta a verificação externa.

Quando o Composer 2.5 faz sentido

Depende da tarefa. Eu enquadraria o Composer 2.5 menos como uma escolha universal e mais como um modelo de codificação para quem já trabalha dentro do Cursor.

Se você passa a maior parte do dia codando no Cursor e se importa com o custo por token, o Composer 2.5 Standard tem o menor preço na linha Composer 2.5. Vale para as mesmas tarefas de edição, refatoração, depuração e sessões longas mencionadas acima.

Se a velocidade de resposta pesa mais, o Composer 2.5 Fast é a opção padrão.

Se a tarefa exige raciocínio mais amplo, janela de contexto maior ou notas superiores em uma área específica, o Claude Opus 4.7 ou o GPT-5.5 podem ser mais adequados.

Uma forma de ver: o Composer 2.5 assume o trabalho rotineiro de código que mencionei, enquanto um modelo de fronteira pode ser melhor para tarefas que pedem raciocínio mais amplo ou notas mais altas em terminal. Assim a comparação fica objetiva, sem virar recomendação única para todos os casos.

Considerações finais

É fácil ler o Composer 2.5 como uma história de benchmarks, mas o ponto mais útil é a direção do movimento. A Cursor não está só encapsulando modelos de fronteira dentro de um editor. Ela está construindo uma linha de modelos em torno do tipo de trabalho que seus agentes já fazem: edições entre arquivos, passos no terminal, sessões longas e recuperação de erros.

Como mencionei, o trade-off é que o Composer 2.5 é propositalmente mais estreito. Ele não substitui o Claude Opus 4.7 ou o GPT-5.5 como modelo geral e não ajuda se você precisa de uma API fora do Cursor. Mas dentro do Cursor, esse foco é justamente o ponto. O modelo é mais barato de rodar que as opções de fronteira, é ajustado para tarefas de código e fica perto da camada de produto onde essas tarefas acontecem.

A próxima questão é quanto disso a Cursor quer internalizar. A empresa diz que está trabalhando com a SpaceXAI para treinar do zero um modelo maior usando 10x mais compute total e a infraestrutura Colossus 2. Não há data de lançamento, então ainda não há muito a analisar. Mesmo assim, o desenho geral é claro: a Cursor está avançando de usar bem os modelos para construir mais da própria pilha de modelos.