Kimi K3 é real, GLM-5.2 é uma aposta e nenhum é uma pechincha
Kimi K3 empata com GPT-5.6 no índice independente de código, mas demora 4,6 vezes mais. Os tokens de 1,40 $ do GLM-5.2 custam 6,51 $ por tarefa. O hype, medido.
O discurso por trás dos novos modelos chineses é simples: pesos abertos que igualam a fronteira ocidental por uma fração do preço. Os números independentes são mais concretos. No Coding Agent Index da Artificial Analysis, o Kimi K3 empata de facto com o nível medium do GPT-5.6, em 4,6 vezes o tempo ativo [1]. E os tokens de 1,40 $ do GLM-5.2 transformaram-se em 6,51 $ por tarefa tentada [2].
Ainda não corri nenhum dos dois modelos contra os meus próprios repositórios, portanto isto não é um teste prático. É uma leitura dos recibos que existem: as medições independentes de agentes, os votos das arenas, as tabelas dos próprios fabricantes com as suas próprias notas de rodapé, e os termos de licença que ninguém cita nos threads de lançamento. Versão curta: a capacidade é real, o desconto quase nunca.
De onde vem o hype?
De três factos verdadeiros que chegaram ao mesmo tempo. O Kimi K3 lidera a classificação fullstack da Arena [3] e está em segundo na WebDev Arena, à frente do Claude Fable 5 e do GPT-5.6 [4]. Os dois modelos publicam pesos abertos em tamanhos que ninguém tinha aberto antes [5] [6]. E ambos listam preços por token muito abaixo dos topos de gama ocidentais [5] [7].
Os resultados das arenas merecem ser levados a sério. Na tabela fullstack com data de 24 de julho de 2026, o Kimi K3 max ocupa o primeiro lugar com uma pontuação de 1.664, à frente do GPT-5.6 Sol com 1.633 e do Fable 5 com 1.623 [3]. Na WebDev Arena, quatro dias depois, o Claude Opus 5 max lidera com 1.712 e o Kimi é segundo com 1.682 em 3.777 votos, acima do Fable 5, do Sol e do GLM-5.2 [4]. As pessoas, quando podem escolher, continuam a votar no que este modelo constrói num browser.
A abertura também é real. A Moonshot apresenta o Kimi K3 como o primeiro modelo de pesos abertos com 2,8 biliões de parâmetros, com uma janela de contexto de um milhão de tokens, visão integrada e um preço de API de 3 $ por milhão de tokens de entrada e 15 $ de saída [5]. O GLM-5.2 é o irmão mais pequeno: 753 mil milhões de parâmetros sob uma licença MIT simples [6], listado a 1,40 $ de entrada e 4,40 $ de saída [7]. Ponha estas etiquetas ao lado da tabela de preços ocidental e a narrativa escreve-se sozinha.
A própria Moonshot é mais prudente do que os seus fãs. O post de lançamento admite que o K3 continua atrás do Fable 5 e do GPT-5.6 Sol, e reconhece “uma lacuna percetível na experiência de utilização” face aos dois [5]. Essa frase, escrita pelo próprio fabricante, acaba por ser também o resumo mais exato dos dados independentes.
O que dizem os números independentes?
A Artificial Analysis passa cada sistema pela mesma bateria em três partes: 113 tarefas de engenharia de software (DeepSWE), 84 tarefas agênticas de terminal (Terminal-Bench v2) e 124 perguntas técnicas sobre código (SWE-Atlas Q&A), com peso igual no Coding Agent Index v1.3 [8]. Consultado a 30 de julho de 2026: o Kimi K3 faz 61, exatamente ao nível do GPT-5.6 em esforço medium. O Opus 5 medium faz 62. O GLM-5.2 faz 43 [1] [2].
Um pormenor de enquadramento conta mais do que qualquer pontuação. O índice mede sistemas, não pesos: o Kimi correu dentro da sua própria Kimi Code CLI, o GLM-5.2 dentro do Claude Code, o Sol dentro do Codex, os modelos Claude dentro do Claude Code [1] [2]. Nunca está a medir um modelo. Está a medir um modelo vestido com um agente específico, num nível de esforço específico.
| Medição | Kimi K3 | GLM-5.2 | Sol medium | Opus 5 medium |
|---|---|---|---|---|
| Coding Agent Index | 61 | 43 | 61 | 62 (Melhor valor da linha) |
| DeepSWE, % | 64 | 29 | 64 | 63 |
| Terminal-Bench v2, % | 84 (Melhor valor da linha) | 72 | 78 | 79 |
| SWE-Atlas Q&A, % | 37 | 29 | 40 | 44 (Melhor valor da linha) |
| Custo por tarefa, $ | 3,18 | 6,51 | 2,99 (Melhor valor da linha) | 3,14 |
| Tempo ativo, min | 23,8 | 25,1 | 5,2 (Melhor valor da linha) | 12,2 |
A história da tabela está na diagonal: o Kimi ganha o terminal, o Opus ganha a compreensão, o Sol ganha o cronómetro e o GLM-5.2 não ganha nada com estas definições.
Olhe primeiro para o empate, porque é o resumo mais justo do Kimi numa linha. O mesmo 61 do Sol medium, a 3,18 $ por tarefa contra 2,99 $, ou seja, cerca de 6% mais dinheiro [1]. Mas precisa de 23,8 minutos ativos contra os 5,2 do Sol, que é o 4,6 vezes da entrada, e de 10,6 milhões de tokens contra 5,8 milhões. Contra o Opus 5 medium, o quadro repete-se: um ponto de índice abaixo, quatro cêntimos mais por tarefa, aproximadamente o dobro do tempo [2].
O teto continua ocidental. O Sol max chega aos 67 a 7,08 $ por tarefa [1]; o Opus 5 xhigh iguala esse 67 a 8,23 $ e assina a melhor compreensão de repositórios da bateria, 55% no SWE-Atlas Q&A [2]. O Fable 5 max fica nos 66 por 11,71 $ por tarefa, a forma mais cara de comprar um ponto que o Opus xhigh também vende [2]. Os 84% do Kimi no Terminal-Bench v2 são território de fronteira a sério, acima dos 83% do Sol high e a poucos pontos dos topos de gama em esforço máximo [1] [2].
O ponto fraco do Kimi é igualmente visível: 37% na componente de perguntas sobre código, abaixo dos 40% do Sol medium e muito abaixo do que assinam as configurações Claude [1] [2]. O perfil lê-se como um agente melhor a fazer do que a perceber o que já existe. Num projeto de raiz, quase não importa. Num repositório herdado com 300.000 linhas, é o trabalho inteiro.
Mais barato por token é mesmo mais barato?
Não por si só. Uma tarefa custa tokens vezes o preço do token, e um agente que precisa de mais voltas, mais repetições ou mais raciocínio multiplica o primeiro fator mais depressa do que qualquer desconto encolhe o segundo. O GLM-5.2 é a prova medida: o preço de tabela mais baixo do quadro e, ainda assim, um custo por tarefa acima de todas as configurações ocidentais em medium [2] [7].
Primeiro as tabelas de preços, porque duas surpreenderam-me. Até 31 de agosto de 2026, o Claude Sonnet 5 vende-se ao preço de lançamento de 2 $ por milhão de tokens de entrada e 10 $ de saída, passando a 3 $ e 15 $ a partir de 1 de setembro [9]. O Kimi K3 custa hoje 3 $ e 15 $ [5]. O famoso modelo chinês barato é 50% mais caro por token do que o modelo de volume da Anthropic este mês, e idêntico em tabela a partir do outono.
O resto do quadro: Opus 5 a 5 $ de entrada e 25 $ de saída, Fable 5 a 10 $ e 50 $ [9], GPT-5.6 a 5 $ e 30 $ com um escalão de contexto longo a 10 $ e 45 $ [10], e o GLM-5.2 abaixo de tudo a 1,40 $ e 4,40 $, com leituras de cache a 0,26 $ [7].
Duas notas de rodapé tornam escorregadias até estas etiquetas. Os tokenizers variam por fabricante: a Anthropic documenta que o seu tokenizer atual produz cerca de 30% mais tokens para o mesmo texto do que o anterior [9], pelo que um preço por milhão de tokens nem sequer é uma unidade fixa entre famílias de modelos. E o comportamento de raciocínio também varia: o Kimi K3 raciocina sempre, a FAQ da plataforma é explícita em que não se pode desligar, e o esforço por omissão é max [11]. Paga tokens que nunca vê.
- preço de tabela, por milhão de tokens de entrada
- 1,40 $
- o modelo mais barato desta comparação
- medido, por tarefa tentada
- 6,51 $
- dentro do Claude Code, 25,1 minutos ativos
- derivado, por tarefa resolvida
- 15,14 $
- custo por tentativa a dividir pela taxa de sucesso de 43%
Passe essa aritmética pelo quadro todo e a ordem muda. O Sol medium sai a cerca de 4,90 $ por tarefa resolvida, o Opus 5 medium a 5,06 $, o Kimi K3 a 5,21 $ e o GLM-5.2 a 15,14 $, três vezes a concorrência ocidental. A leitura do gráfico numa linha: sob medição, a etiqueta mais barata da comparação torna-se a alteração resolvida mais cara.
E isto ainda ignora a parte cara. Dez minutos de um engenheiro a fazer triagem de uma execução falhada custam mais do que qualquer número daquela figura. No momento em que as falhas caem sobre um humano em vez de um ciclo de repetição, a taxa de sucesso domina por completo o preço do token.
Em que é que o Kimi K3 é mesmo bom?
Trabalho pesado de terminal, desenvolvimento web com cara de produto, execuções longas de agentes e qualquer cenário em que possuir os pesos conte. A bateria independente sustenta-o, as arenas sustentam-no e o posicionamento da própria Moonshot encaixa [1] [3] [5]. O que ele não é, com a evidência atual, é um substituto barato para trabalho pesado em repositórios existentes.
O resultado de terminal aguenta-se dos dois lados: 84% medidos de forma independente na própria CLI do Kimi [1], 88,3% na configuração preferida da Moonshot [12]. A promessa de longa distância é medida pelo fabricante, mas é notável: o K3 lidera a tabela SWE-Marathon da Moonshot com 42, e a mesma tabela anota abertamente no rodapé que o Fable 5 caiu em modelos de recurso em 35% dessas tarefas e que algumas linhas do Kimi correram num ramo preliminar calibrado para hardware H20 [12]. Junte a visão nativa com um codificador dedicado e a janela de um milhão de tokens [12], e a ideia da Moonshot de iterar entre código e capturas de ecrã ao vivo [5] deixa de soar a marketing.
As fraquezas são igualmente concretas. Compreensão: 37% nas perguntas sobre código [1]. Velocidade: 23,8 minutos ativos por tarefa significam que paraleliza agentes ou espera; a sua própria atenção não se paraleliza. E “pesos abertos” merece umas contas por alto antes de alguém planear alojá-lo por conta própria: 2,8 biliões de parâmetros são cerca de 1,4 TB de pesos mesmo quantizados a 4 bits, antes da cache KV e do custo de serviço. Isso é um cluster, não uma estação de trabalho.
A papelada também conta. A licença é permissiva mas não é um texto genérico: um negócio de modelo como serviço acima de 20 milhões de dólares de receitas agregadas precisa de um acordo separado com a Moonshot, e qualquer produto acima de 100 milhões de utilizadores ativos mensais ou de 20 milhões de dólares de receitas mensais tem de mostrar “Kimi K3” em destaque; o uso interno está isento [13]. E os termos padrão da API permitem à Moonshot usar o conteúdo do cliente para fornecer, manter, desenvolver, apoiar e melhorar os seus serviços, com as restrições ao uso para treino de modelos remetidas para acordos empresariais separados [14]. Eu não apontaria a API pública a um repositório proprietário sem ter essa conversa por escrito.
Porque é que o GLM-5.2 se despenhou no Claude Code?
Ninguém fora da Z.ai sabe ao certo, e é exatamente essa a questão. Os mesmos pesos fazem 81% no Terminal-Bench dentro do harness Terminus da própria Z.ai [6] e 72% dentro do Claude Code [2]. O que ruiu na medição independente foi o sistema à volta do modelo: chamadas de ferramentas, recuperação de erros, comportamento da cache, encaixe nas convenções do agente. A medição condena uma configuração, não necessariamente os pesos.
A linha independente completa é uma leitura dura em qualquer caso: índice 43, DeepSWE 29%, perguntas sobre código 29%, 6,51 $ por tarefa tentada e, com 25,1 minutos ativos, a execução mais lenta de todo o quadro [2]. Uma trajetória que queima 25 minutos e 6,51 $ com uma tabela de 1,40 $/4,40 $ é uma trajetória que passou a maior parte do orçamento a andar às voltas.
Os números da própria Z.ai saem de maquinaria mais amiga, e a ficha do modelo di-lo sem rodeios: SWE-Bench Pro em 62,1 via OpenHands com um prompt de instruções à medida, DeepSWE com limites de duas horas em contentores isolados, Terminal-Bench via Terminus com orçamento de quatro horas [6]. Nada disto é batota. É um fabricante a mostrar o modelo no ambiente para o qual o afinou. Só que não é evidência sobre o agente que executa de verdade.
Ainda assim, sobra-lhe uma faixa racional. Com 753 mil milhões de parâmetros sob MIT [6], o GLM-5.2 é o candidato realista dos dois ao alojamento próprio, e a 1,40 $ por milhão de tokens é um piloto sensato para trabalho em massa com verificação automática: codemods com suítes de testes, candidatos de migração, tudo onde uma verificação determinística apanhe os 57% que falham e as falhas custem apenas computação. No momento em que um humano revê as falhas, a aritmética inverte-se.
Como ler uma classificação de código
Os lançamentos do Kimi e do GLM são um caso de estudo de literacia em benchmarks, por isso aqui fica o mapa que uso antes de acreditar num número.
| Sinal | O que premeia | O que não lhe pode dizer |
|---|---|---|
| DeepSWE, 113 tarefas | fechar tarefas de engenharia de ponta a ponta | o encaixe nas convenções do seu código |
| Terminal-Bench v2, 84 tarefas | levar uma shell a um estado final verificado | a compreensão de um grande repositório existente |
| SWE-Atlas Q&A, 124 tarefas | responder a perguntas técnicas sobre código | a capacidade de aterrar a alteração que descreve |
| WebDev e Fullstack Arena | o que as pessoas preferem em duelos | correção, testes, segurança, manutenibilidade |
| Fichas de modelo dos fabricantes | o modelo no seu melhor, em casa própria | a comparabilidade entre linhas |
Depois aplique três descontos. Primeiro, o ruído de infraestrutura: a equipa de engenharia da Anthropic mediu uma oscilação de 6 pontos percentuais no Terminal-Bench 2.0 só por causa dos limites de recursos, viu as taxas de erro de infraestrutura caírem de 5,8% para 0,5% ao aliviar os limites, e concluiu que diferenças de classificação abaixo de uns 3 pontos merecem ceticismo até as configurações estarem documentadas e emparelhadas [15]. O empate do Kimi com o Sol medium cai dentro dessa banda; trate-o como paridade, não como vitória de alguém.
Segundo, a assimetria das notas de rodapé. A tabela comparativa da Moonshot corre cada concorrente num harness diferente, inclui modelos de recurso nalgumas linhas e pontua o seu próprio benchmark interno, onde o Fable 5 registou 13 quedas para recurso e uma recusa em 80 tarefas [12]. Mérito a quem o tem: foi a Moonshot que imprimiu essas notas. Os threads de lançamento que citavam a tabela, não.
Terceiro, a disciplina de versões. O índice independente traz uma versão (v1.3 hoje) porque a sua mistura de tarefas muda [8]; uma pontuação de uma versão não é comparável com a de outra, por muito parecido que o nome seja. Qualquer comparação que não declare harness, esforço, orçamento e versão é um palpite disfarçado de casa decimal.
Onde os modelos ficam no meu encaminhamento
Tudo o que está acima muda o que eu experimentaria primeiro, não aquilo em que padronizaria. A minha tabela de encaminhamento hoje, com os dois recém-chegados arrumados com honestidade:
| O trabalho | A minha escolha hoje |
|---|---|
| Alterações de rotina com testes sólidos | Sonnet 5, a 2 $/10 $ até 31 de agosto de 2026 |
| Ciclos rápidos de agente e trabalho de terminal | GPT-5.6 em esforço medium ou high |
| Trabalho num repositório grande existente | Opus 5 em esforço medium ou high |
| Fullstack de raiz e builds carregados de UI | Kimi K3, a faixa que os votos de arena sustentam |
| Trabalho em massa com verificação automática | GLM-5.2 no seu harness nativo, como piloto |
| Escalada quando tudo o resto falha | Fable 5, com conta-gotas |
É a mesma aritmética que a semana de lançamento do Opus 5 me ensinou: o que compra de verdade são alterações aprovadas, e tudo o resto, tokens incluídos, é matéria-prima.
Dois resultados fariam mexer estas linhas. Uma execução do Kimi K3 num harness neutro (Claude Code ou Codex) que segure aquele 61, o que provaria que a pontuação pertence ao modelo e não à CLI da casa. E uma medição independente do GLM-5.2 no seu agente nativo, feita por alguém que não o venda. Até lá, o resumo honesto mantém-se: os modelos são reais, os preços são marketing e os recibos estão aqui em cima.
Fontes
- Codex vs Kimi Code CLI: coding agent comparison
- Claude Code vs OpenCode: coding agent comparison
- Fullstack Arena leaderboard
- WebDev Arena leaderboard
- Kimi K3
- GLM-5.2 model card
- GLM-5.2 API pricing
- Coding Agent Index
- Pricing
- API pricing
- Kimi K3 quickstart
- Kimi K3 model card
- Kimi K3 license
- Model use agreement
- Benchmark scores and infrastructure noise