CursorBench 3.1
Os novos resultados do CursorBench 3.1 da Cursor afirmam que seu modelo interno de codificação Composer 2.5 rivaliza com modelos de ponta como GPT-5.5 e Claude Opus 4.8 com um custo muito menor, gerando intenso escrutínio tanto do benchmark quanto do desempenho real do modelo. Comentadores contrastam velocidade, precisão, capacidade de planejamento, limites de contexto e eficiência de tokens entre modelos, argumentando que benchmarks feitos pelo próprio fornecedor são fáceis de superajustar e que o valor prático, no fim, depende da carga de trabalho: trabalho rotineiro na web e CRUD pode funcionar bem em modelos mais baratos e rápidos, enquanto engenharia complexa ou crítica de segurança ainda favorece sistemas mais lentos e caros como Opus, GPT-5.5 ou Fable.
Percepções sobre os modelos Anthropic / Claude
- Vários comentaristas reclamam que os modelos recentes da Anthropic pensam demais, gastam tokens e criam subagentes desnecessários, às vezes ignorando instruções para não navegar nem ler documentação extra.
- Outros relatam que o Opus 4.8 funciona bem quando configurado com cuidado, mas fica muito lento em níveis altos de “effort”, especialmente para implementação em vez de planejamento.
- Há preocupações de que o aumento do uso de tokens — incluindo um novo tokenizer que infla a contagem de tokens — possa ser motivado economicamente, especialmente à medida que modelos antigos são descontinuados.
Composer 2.5 vs GPT-5.5, Opus e outros
- Muitos usuários gostam do Composer 2.5 como um “cavalo de batalha” rápido e barato para trabalho típico na web e em apps, especialmente quando as tarefas são divididas em pequenas etapas e os planos vêm de modelos mais fortes.
- Outros acham o Composer 2.5 superficial, com qualidade de “projeto de faculdade” ou até contraproducente em tarefas mais difíceis ou não padronizadas (por exemplo, física, cinemática, engenharia complicada), dizendo que ele comete erros sutis com confiança e não pede esclarecimentos.
- Alguns afirmam que a qualidade de código dele é próxima da do Opus ou do GPT-5.5 para trabalho rotineiro de CRUD e UI; outros dizem que isso é “farsesco” e que GPT-5.5 ou Opus são claramente superiores.
- Há uma ênfase recorrente de que linguagem/stack, domínio do problema e horizonte de contexto afetam fortemente a qualidade percebida.
Validade e viés dos benchmarks
- Há forte ceticismo em relação ao CursorBench porque o próprio modelo da Cursor performa quase tão bem quanto os modelos de ponta, com custo muito menor.
- As pessoas contrastam isso com avaliações de terceiros (por exemplo, DeepSWE, FrontierCode), nas quais o Composer 2.5 pontua muito pior em tarefas de longo horizonte.
- Alguns observam que qualquer fornecedor tem incentivo ou inclinação natural para projetar benchmarks alinhados com sua distribuição de treinamento.
- Outros argumentam que todos os benchmarks são falhos: o design do harness, a falta de cache e o estilo irrealista das tarefas podem distorcer os resultados.
Velocidade, custo e contexto
- Muitos priorizam o tempo de execução: o Opus é frequentemente descrito como dolorosamente lento em comparação ao Composer, obrigando o uso de sessões paralelas ou horários fora do expediente.
- O GPT-5.5 é frequentemente visto como o programador mais forte em termos absolutos, mas os limites de contexto e os modelos de precificação complicam as comparações.
- Janelas de contexto grandes (Opus 1M, GPT maior opcional) importam mais em sessões longas e com muito planejamento; a compactação é apontada como prejudicial a esses fluxos de trabalho.
Críticas aos gráficos e à apresentação
- Várias pessoas não gostam do eixo de custo invertido por ser pouco intuitivo e potencialmente manipulador.
- Alguns pedem gráficos no estilo fronteira de Pareto (custo vs desempenho, além de velocidade) e relatórios mais transparentes, com múltiplos benchmarks.