All news

Cursor Composer 2.5 chega em open-weights Kimi K2.5 a $0,50/M de input

O lançamento do Composer 2.5 pela Cursor em 18 de maio mantém o backbone Kimi K2.5 do Composer 2 e aposta que o fine-tuning por RL fecha o gap até Opus 4.7 em benchmarks de programação. O tier standard é $0,50/M de input + $2,50/M de output — cerca de um décimo do preço de modelos frontier fechados.

A Cursor lançou o Composer 2.5 em 18 de maio de 2026 — um salto substancial em inteligência e comportamento em cima do Composer 2, mantendo o mesmo backbone open-weights Moonshot Kimi K2.5. O preço do tier standard se mantém 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 aproximadamente 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 em cima do Kimi K2.5, o mesmo checkpoint que o Composer 2 usou. Vários textos de terceiros citam a Cursor afirmando que o time manteve a base K2.5 e adicionou treinamento em vez de trocar para K2.6 (abril de 2026). A aposta é que RL direcionado em uma base sabidamente boa supera uma troca de base para um produto de agente de programação, onde estabilidade e compatibilidade com a harness importam tanto quanto os números brutos de benchmark.

(K2.6 é o modelo mais novo da Moonshot — 1T MoE, 32B ativo, 256K de contexto, INT4 nativo, no topo do volume de tokens de programação da OpenRouter em maio. É um default forte para quem faz self-hosting, mas não é ele que alimenta o Composer 2.5.)

O que mudou em cima do K2.5

A Cursor cita três mudanças no treinamento:

  • RL com feedback textual. Em vez de apenas modelar a recompensa no final da execução, o treinador faz emergir dicas localizadas quando tool calls falham no meio da tarefa. O modelo aprende a se 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 pattern-match em um diff pronto. A Cursor argumenta que isso é mais próximo da distribuição do trabalho real de engenharia do que tarefas puras de correção no estilo SWE-Bench.
  • Refatoração de infra em escala MoE. Otimizadores Muon shardeados e HSDP de malha dupla para eficiência em tempo de treinamento. É o tipo de mudança de infra que permite a um time pequeno rodar várias épocas de RL em um MoE de 1T parâmetros em um cluster razoável.

Nada disso altera os pesos base K2.5 que estão públicos no HuggingFace; eles vivem na variante hospedada pela Cursor. Quem faz self-hosting usando K2.5 a partir de moonshotai/Kimi-K2.5 não vai obter o comportamento do Composer 2.5 de graça — os deltas de RL são propriedade intelectual da Cursor. Ainda assim, os pesos base continuam sendo o substrato, e essa é a parte da história que importa para o ecossistema aberto.

Benchmarks (autorreporte da Cursor — tratar como números do fornecedor)

  • SWE-Bench Multilingual: Composer 2.5 79,8 % — vs Opus 4.7 80,5 %.
  • CursorBench v3.1 (configuraçõ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 %.

Esses são números publicados pela Cursor; espere que leaderboards da comunidade (tbench.ai, benchlm.ai) tragam resultados independentes nas próximas semanas. Pela disciplina do UPDATE.md, quando um benchmark “Adaptive” do fornecedor e um leaderboard da comunidade divergem em 3+ pontos, prefira o leaderboard. Os deltas Composer-vs-Opus acima são pequenos o suficiente para que a próxima execução independente possa colocar qualquer um dos modelos no topo — não se ancore demais no autorreporte do dia zero.

A afirmação estrutural maior é a razão de custos. Opus 4.7 lista a aproximadamente $15/M de input e $75/M de output na API da Anthropic; o tier 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 tier fast ($3/$15) é ~5× mais barato no input. Se a paridade em benchmarks se sustentar em execuções independentes, o Composer 2.5 aterrissa como o default óbvio para cargas de alto volume com agentes de programação onde cada tarefa é limitada e se pode absorver um custo ocasional de retry — o que é a maioria delas.

Por que isso importa para usuários de LLM locais

Composer 2.5 não é um produto de LLM local. Mas é o sinal mais forte até agora 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 desenvolvedores. A Anthropic, a OpenAI e a Google ainda mantêm seus pesos base fechados; a Moonshot os publica. O acordo da Cursor valida a categoria de programação agentic open-weights como pronta para deployment, e não apenas em nível de pesquisa.

Ressalva prática: K2.5 em precisão completa equivale a aproximadamente 1 TB de pesos. Quantizado em INT4 ainda fica em ~540 GB — fora do alcance do tier de 128 GB GB10 / Strix Halo que este site cobre majoritariamente. Rodar K2.5 localmente exige um cluster multi-nó ou um setup 4× DGX Spark / 4× Strix Halo. É por isso que a Cursor (e o padrão de uso da OpenRouter) roteia a maior parte da inferência de K2.5/K2.6 através da própria API da Moonshot ou de agregadores hospedados em vez de hardware local. A história open-weights é “o substrato é público”, não “você pode rodar isso no seu computador este ano”.

Fontes