A Cursor lançou o Composer 2.5 a 18 de maio de 2026 — um salto substancial em inteligência e comportamento por cima do Composer 2, mantendo a mesma espinha dorsal open-weights Moonshot Kimi K2.5. O preço do escalão standard mantém-se em $0,50/M de input e $2,50/M de output, com uma variante mais rápida a $3,00/M de input e $15,00/M de output. A Cursor afirma paridade com Claude Opus 4.7 em SWE-Bench Multilingual (Composer 79,8 % vs Opus 80,5 %) a sensivelmente um décimo do custo por token.
O modelo é K2.5, não K2.6 — e isso importa
O anúncio da própria Cursor é explícito: o Composer 2.5 é construído sobre Kimi K2.5, o mesmo checkpoint que o Composer 2 usou. Vários artigos de terceiros citam a Cursor a dizer que a equipa manteve a base K2.5 e acrescentou treino em vez de trocar para K2.6 (abril de 2026). A aposta é que RL direcionado numa base conhecida-boa supera uma troca de base num produto de agente de programação, onde a estabilidade e a compatibilidade com a harness importam tanto como os números brutos de benchmark.
(K2.6 é o modelo mais recente da Moonshot — 1T MoE, 32B activo, 256K de contexto, INT4 nativo, no topo do volume de tokens de programação da OpenRouter em maio. É um forte default para quem faz self-hosting, mas não é o que alimenta o Composer 2.5.)
O que mudou por cima do K2.5
A Cursor nomeia três alterações no treino:
- RL com feedback textual. Em vez de apenas moldar a recompensa no fim da execução, o treinador faz emergir pistas localizadas quando as tool calls falham a meio da tarefa. O modelo aprende a recuperar dentro de uma sessão em vez de reiniciar a execução.
- ~25× mais tarefas sintéticas. Incluindo puzzles de “feature deletion” — remover uma funcionalidade e depois reconstruí-la — o que força o modelo a reconstruir o contexto em vez de fazer correspondência de padrões a um diff já feito. A Cursor argumenta que isto está mais próximo da distribuição do trabalho real de engenharia do que tarefas puras de correção ao estilo SWE-Bench.
- Reformulação de infra à escala MoE. Optimizadores Muon partilhados (sharded) e HSDP de malha dupla para eficiência em tempo de treino. É o tipo de mudança de infra que permite a uma equipa pequena correr várias épocas de RL num MoE de 1T parâmetros num cluster sensato.
Nada disto altera os pesos base K2.5 que estão públicos no HuggingFace; vivem na variante alojada pela Cursor. Quem faz self-hosting usando K2.5 a partir de moonshotai/Kimi-K2.5 não obtém o comportamento do Composer 2.5 de graça — os deltas de RL são propriedade intelectual da Cursor. Os pesos base continuam a ser o substrato, contudo, e essa é a parte da história que importa para o ecossistema aberto.
Benchmarks (auto-reportados pela Cursor — tratar como números do fornecedor)
- SWE-Bench Multilingual: Composer 2.5 79,8 % — vs Opus 4.7 80,5 %.
- CursorBench v3.1 (definições padrão): Composer 2.5 63,2 % — vs Opus 4.7 61,6 %.
- Terminal-Bench 2.0: Composer 2.5 ≈ 69,3 % — vs Opus 4.7 ≈ 69,4 %.
Estes são números publicados pela Cursor; conte com leaderboards da comunidade (tbench.ai, benchlm.ai) a aterrar resultados independentes nas próximas semanas. Pela disciplina do UPDATE.md, quando o benchmark “Adaptive” do fornecedor e um leaderboard da comunidade divergem em 3+ pontos, prefira o leaderboard. Os deltas Composer-vs-Opus acima são suficientemente pequenos para que a próxima execução independente possa colocar qualquer um dos modelos em cima — não se ancore demasiado no auto-reporte do dia zero.
A afirmação estrutural maior é o rácio de custos. Opus 4.7 lista a sensivelmente $15/M de input e $75/M de output na API da Anthropic; o escalão standard do Composer 2.5 a $0,50/M de input e $2,50/M de output é ~30× mais barato no input e ~30× mais barato no output. Mesmo o escalão fast ($3/$15) é ~5× mais barato no input. Se a paridade em benchmarks se confirmar em execuções independentes, o Composer 2.5 aterra como o default óbvio para cargas de alto volume com agentes de programação onde cada tarefa é limitada e se consegue absorver um custo ocasional de retry — que são a maioria.
Porque é que isto importa para utilizadores de LLM locais
Composer 2.5 não é um produto de LLM local. Mas é o sinal mais forte até hoje de que uma base open-weights — licenciada Modified MIT, disponível no HuggingFace — pode alimentar uma UI de agente de programação em produção usada por centenas de milhares de programadores. A Anthropic, a OpenAI e a Google continuam a manter os seus pesos base fechados; a Moonshot publica-os. O acordo da Cursor valida a categoria de programação agentic open-weights como pronta para deployment, e não apenas ao nível de investigação.
Ressalva prática: K2.5 em precisão completa são sensivelmente 1 TB de pesos. Quantizado a INT4 ainda são ~540 GB — fora do alcance do escalão de 128 GB GB10 / Strix Halo que este site cobre maioritariamente. Correr K2.5 localmente exige um cluster multi-nó ou uma configuração 4× DGX Spark / 4× Strix Halo. É por isso que a Cursor (e o padrão de uso da OpenRouter) encaminha a maior parte da inferência de K2.5/K2.6 através da própria API da Moonshot ou de agregadores alojados em vez de hardware local. A história open-weights é “o substrato é público”, não “podes correr isto no teu computador este ano”.
Fontes
- Blog da Cursor — Composer 2.5 (anúncio principal, 18 de maio de 2026)
- Changelog da Cursor — preços standard/fast do Composer 2.5
- WinBuzzer — A Cursor lança o Composer 2.5 (artigo de terceiros que cita a Cursor sobre a base K2.5)
- moonshotai/Kimi-K2.5 no HuggingFace (pesos base, Modified MIT)
- Kimi K2.5 em LLMRequirements.com