Enviei as mesmas tarefas de programação para o Kimi K2.7 Code e o Claude Opus 4.8 por meio de uma única API e medi o que retornou. Em termos de corretude, eles empataram: ambos resolveram com precisão uma armadilha de precedência do SemVer e um bug oculto de mesclagem de intervalos. Mas o Opus respondeu de 3 a 9× mais rápido, com um quarto dos tokens de saída, enquanto o Kimi custou cerca de 46% menos por tarefa no preço de tabela. Então a escolha não é sobre qual modelo é "mais inteligente". Se você estiver executando trabalho de codificação sensível a custo ou em lote, o Kimi K2.7 vence no preço. Se você precisa de baixa latência, de um contexto de 1M de tokens ou de um modelo de revisão final em que confia, o Opus 4.8 vale o preço extra, e muitas equipes acabam alternando entre os dois.
Na prática: executei as mesmas tarefas de programação em ambos
Como eu testei: IDs de modelo kimi-k2.7-code e claude-opus-4-8, chamados por um único endpoint de gateway compatível com OpenAI em 2026-07-13, uma única tentativa por tarefa com parâmetros padrão e sem cache de prompt. A latência é medida pelo relógio em tempo real no lado do cliente, então inclui tempo de rede e de fila, não apenas a geração. Antes de pontuar, pedi a cada modelo que se identificasse como uma checagem de sanidade (o Kimi respondeu "made by Moonshot AI," o Opus respondeu Anthropic); isso é uma verificação de roteamento, não prova de versão. Esta é uma amostra de duas tarefas, não um benchmark. Ela mostra um comportamento que você pode sentir; não pode medir desempenho agentic em múltiplas interações.
Tarefa 1 pediu a cada modelo para implementar uma função compare_semver() seguindo a especificação SemVer 2.0.0, incluindo a parte em que a maioria das implementações erra: a precedência de pré-lançamento, em que 1.0.0-alpha.1 < 1.0.0-alpha.beta, identificadores numéricos têm prioridade abaixo dos alfanuméricos, e beta.11 > beta.2 numericamente em vez de pela ordem lexicográfica. Eu atribuí nota a cada resposta com base em uma matriz de 72 comparações construída a partir da ordem canônica da especificação. Tarefa 2 entregou uma função merge_intervals() com bug, cujo defeito real era last[1] = cur[1] em vez de max(...), uma linha que engole silenciosamente um intervalo totalmente contido como [1,10],[2,3]; eu avaliei com base em 5 casos, incluindo esse intervalo contido.
Métrica | Kimi K2.7 Code | Claude Opus 4.8 |
|---|---|---|
Precisão da Tarefa 1 (72 precedência + casos extremos) | 72/72 | 72/72 |
Precisão da Tarefa 2 (5 casos incl. intervalo contido) | 5/5 | 5/5 |
Latência da Tarefa 1 (no lado do cliente) | 49.1s | 5.3s |
Latência da Tarefa 2 (no lado do cliente) | 11.5s | 7.6s |
Tokens da Tarefa 1 (entrada / saída) | 172 / 1,907 | 774 / 418 |
Custo da Tarefa 1 (preço de tabela nativo) | $0.0078 | $0.0143 |
O custo é calculado a partir das contagens de tokens acima, com os preços de tabela nativos (Kimi $0.95/$4 por milhão de entrada/saída, Opus $5/$25): Kimi = 172×$0.95/M + 1,907×$4/M ≈ $0.0078; Opus = 774×$5/M + 418×$25/M ≈ $0.0143. As contagens de tokens de entrada diferem (172 vs 774) porque o tokenizador de cada modelo e a contabilização do gateway contam o mesmo prompt de forma diferente, não porque as tarefas eram distintas. Ambos os modelos produziram código totalmente correto nas duas tarefas. A diferença estava em como chegaram lá. Opus foi conciso e rápido, retornando 418 tokens em 5.3 segundos na Tarefa 1. Kimi levou 49.1 segundos e emitiu 1,907 tokens, grande parte deles um rastro de raciocínio passo a passo que retornou junto com o código. Ainda assim, como os tokens do Kimi são cerca de 6× mais baratos, a execução mais verbosa continuou custando menos.
O que o duelo prova e não prova
Isso prova que, em problemas de programação bem delimitados e com limites definidos, o Kimi K2.7 Code chega à mesma resposta correta que um modelo de fronteira. Isso não prova que o Kimi iguale o Opus em sessões agentivas longas e com várias etapas, algo que duas tarefas de execução única não conseguem avaliar. A própria afirmação mais forte do Kimi está justamente nesse território agentivo, que os benchmarks abaixo abordam diretamente.
Benchmarks: o que é de terceiros vs a própria tabela da Moonshot
Aqui está a análise, com cada número identificado por fonte. A tabela autodeclarada da Moonshot é onde o Kimi parece mais forte; a avaliação independente é mais limitada porque o modelo é recente e, onde ainda não existe um número de terceiros para o K2.7, a referência publicada mais próxima é a do K2.6 (marcada abaixo).
Benchmark | Kimi K2.7 Code | Claude Opus 4.8 | Fonte |
|---|---|---|---|
MCPMark Verified (tool use) | 81.1 | 76.4 | Moonshot, autodeclarado |
SWE-bench Verified | 60.4% | não publicado no mesmo formato | Moonshot, autodeclarado |
Intelligence Index | 35 (K2.6 proxy) | 56 | Artificial Analysis, de terceiros |
Output speed | ~45 tok/s (K2.6 proxy) | 59 tok/s | Artificial Analysis, de terceiros |
A única métrica em que a comparação se apoia, MCPMark Verified 81.1 vs 76.4, vem da tabela da própria Moonshot, e não de um laboratório independente. Isso não é motivo para descartá-la, já que o uso de ferramentas no estilo MCP é exatamente onde o Kimi foi ajustado. Mas leia a manchete “Kimi supera Opus” como uma दावा do fornecedor sobre um benchmark otimizado pelo fornecedor. No único confronto direto medido por uma parte externa, a Artificial Analysis coloca o Opus 4.8 bem à frente em seu Intelligence Index (56 vs 35), embora essa linha use o K2.6 como substituto porque o K2.7 ainda não havia recebido uma pontuação independente na época da redação.
A lacuna que os benchmarks da janela de contexto escondem
Opus 4.8 oferece uma janela de contexto de 1M tokens; o Kimi K2.7 chega a 256K. As pontuações de benchmarks raramente evidenciam isso, mas é o que decide o trabalho real. Uma janela de 256K comporta confortavelmente um repositório de médio porte e um longo trace de agente, e é suficiente para a maioria das sessões de programação. Você atinge o limite ao inserir um monorepo grande inteiro, conjuntos longos de documentos ou transcrições de agentes de várias horas em um único prompt. Nesse caso, a janela 4× maior do Opus faz a diferença prática, não um ponto em um gráfico.
Preços: a lacuna de 5–6× e a alavanca do cache
Nos preços de tabela nativos da API, o Kimi K2.7 Code custa US$ 0,95 por milhão de tokens de entrada e US$ 4,00 por milhão de saída; o Claude Opus 4.8 custa US$ 5 e US$ 25. Isso representa uma diferença de 5–6× na saída, e esse é o principal motivo pelo qual as equipes consideram o Kimi.
A alavanca que a maioria das tabelas de preços ignora é o cache. A Kimi cobra US$ 0,19 por milhão de tokens em um cache hit, um desconto de 80% na entrada que você já enviou. Em um loop agentic que relê a mesma base de código em cada etapa, a entrada em cache domina a conta, então o custo efetivo cai bem abaixo da diferença nominal. Philip Kiely, da Baseten, relatou uma economia de cerca de 82% em uma carga de trabalho de exemplo após trocar do Opus 4.8 para o Kimi 2.7 Code, o tipo de tarefa pesada em cache e em input em que a precificação da Kimi se acumula. Seu número vai variar de acordo com a relação entre entrada e saída, mas a direção é consistente: quanto mais você relê o contexto em relação ao que gera, mais a Kimi ganha em custo.
O Opus recupera seu custo pelo lado da saída. Ele gerou um quarto dos tokens que o Kimi gerou na minha Tarefa 1, então, em trabalhos com muita geração, como escrever arquivos grandes ou refatorações verbosas, a diferença por token diminui no gasto real, e a velocidade do Opus reduz o tempo de espera total pelo qual você está pagando um engenheiro.
A promessa dos pesos abertos versus a realidade de 577 GB
Kimi K2.7 é disponibilizado como open weights sob uma licença MIT modificada, então você pode hospedar e ajustar o modelo por conta própria. O Opus 4.8 é somente via API; seu código e rastros de raciocínio vão para a Anthropic. No papel, isso dá uma vantagem decisiva de privacidade e dependência de fornecedor para o Kimi. Na prática, verifique primeiro a conta de hardware.
Kimi K2.7 é um modelo Mixture-of-Experts de 1 trilhão de parâmetros (32B ativos por token, 384 experts). Revisores independentes estimam uma implantação INT4 completa em cerca de 577GB de VRAM, quando se contam os pesos, o KV cache e o overhead de runtime, o que coloca a configuração prática mínima em torno de 8× H100 80GB ou uma máquina classe DGX Spark. Uma única RTX 4090 (24GB) não consegue executar o modelo completo com configurações utilizáveis. Para todos, exceto um punhado de equipes bem financiadas, “open weights” significa a liberdade de direcionar para um provedor de hospedagem ou fazer fine-tuning em GPUs alugadas, não um modelo que você implanta internamente. Se o seu motivo para escolher o Kimi é o controle de dados on-premises, faça o orçamento do cluster antes de se comprometer; para a maioria das equipes, o self-hosting continua sendo teórico.
Qual você deve escolher
Ajuste o modelo à carga de trabalho em vez de coroar um vencedor:
Escolha Kimi K2.7 Code para codificação com sensibilidade a custo, em alto volume ou agentic, quando você relê uma base de código repetidamente, a latência não é crítica e um contexto de 256K é suficiente. O desconto de cache se acumula a seu favor.
Escolha Claude Opus 4.8 quando precisar de baixa latência, de um contexto de 1M tokens para repositórios grandes ou sessões longas, de uma saída mais concisa, ou de um modelo de revisão final em que você possa confiar para mudanças de alto risco, onde sua vantagem em pontuações de raciocínio independente é mais importante.
A estratégia híbrida: rascunhos com modelo barato, finalização com modelo de fronteira
O padrão mais comum entre equipes que usam ambos não é escolher um, e sim fazer roteamento. Deixe o Kimi K2.7 cuidar da geração em massa e das iterações de forma barata, e então passe o resultado para o Opus 4.8 para a revisão final ou para as partes que precisam de julgamento de fronteira. O Kimi fala o formato da OpenAI nativamente, enquanto o Opus usa a própria API da Anthropic, então a forma prática de fazer o roteamento entre eles é um gateway que coloca ambos atrás de um único endpoint compatível com OpenAI; em uma plataforma como AIReiter, por exemplo, ambos ficam sob uma única chave, tornando uma troca de Kimi para Opus uma mudança de string de modelo, em vez de uma reintegração. A economia de 82% acima veio exatamente desse tipo de roteamento, e não de eliminar o Opus completamente.
FAQ
O Kimi K2.7 é melhor que o Claude Opus 4.8 para programação?
Em tarefas bem definidas e delimitadas, eles ficam empatados; no meu teste, ambos retornaram código totalmente correto. A vantagem do Kimi está no uso agêntico de ferramentas (MCPMark 81,1 vs 76,4, segundo a Moonshot); o Opus lidera em raciocínio geral, velocidade e trabalho com contexto longo.
Quão mais barato é o Kimi K2.7 do que o Opus 4.8?
Cerca de 5–6× mais barato no preço de tabela ($0.95/$4 por milhão vs $5/$25). Com acertos de cache ($0.19/M de entrada) em cargas de trabalho repetitivas, a economia no mundo real pode chegar a 80% ou mais.
Qual é a janela de contexto do Kimi K2.7 vs Opus 4.8?
Kimi K2.7 lida com 256 mil tokens; Opus 4.8 lida com 1 milhão, quatro vezes maior.
Posso executar o Kimi K2.7 localmente?
Apenas com hardware sério. Um deployment INT4 completo reportedly precisa de cerca de 577GB de VRAM (aproximadamente 8× H100 ou um DGX Spark). Uma única GPU de consumo como uma RTX 4090 não consegue executar o modelo completo.
O Kimi K2.7 é open source?
Ele é disponibilizado com pesos abertos sob uma licença MIT modificada, então você pode hospedar por conta própria e fazer fine-tuning. O Opus 4.8 é fechado e disponível apenas via API.
Em resumo
Se o seu gargalo é orçamento, use por padrão o Kimi K2.7 Code e deixe o caching fazer o resto. Se for latência, comprimento de contexto ou uma alteração que você não pode se dar ao luxo de errar, pague pelo Opus 4.8. Trate a licença de open weights como um bônus que você só vai aproveitar se for dono das GPUs. E, se não tiver certeza, integre os dois e faça o roteamento por tarefa em vez de apostar o fluxo de trabalho em uma única aposta que você terá de desfazer depois.