Kimi K3 iguala o GPT-5.6, mas demora 4,6 vezes mais

A Artificial Analysis atribui ao Kimi K3 a mesma pontuação do GPT-5.6 medium no Coding Agent Index, mas o Kimi precisa de 23,8 minutos contra 5,2, ou seja, demora 4,6 vezes mais [1]. O GLM-5.2 fica pior: o preço de entrada de 1,40 $ transforma-se em 6,51 $ por tentativa [2]. Na minha leitura, os dois modelos são capazes, mas nenhum oferece a poupança sugerida pelo preço por token.

A comparação numa tabela: Kimi compete, GLM-5.2 fica atrás

O Kimi K3 é competitivo, mas não domina: empata com o GPT-5.6 Sol medium no índice combinado, lidera o teste de terminal, fica atrás na compreensão de repositórios e é muito mais lento. O GLM-5.2 fica atrás dos outros três modelos nestas configurações e não lidera nenhuma medição [1] [2].

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

O empate entre o Kimi e o Sol medium é a comparação direta mais útil: ambos fazem 61 pontos e os custos medidos por tarefa são próximos, 3,18 $ e 2,99 $, respetivamente [1]. A diferença está na forma como lá chegam. O Kimi usa 23,8 minutos ativos e 10,6 milhões de tokens por tarefa, contra 5,2 minutos e 5,8 milhões do Sol. O Opus 5 medium mostra algo semelhante, pois supera o Kimi por um ponto, custa menos quatro cêntimos e termina em cerca de metade do tempo [2].

Os modelos ocidentais ainda obtêm as pontuações mais altas do índice. O Sol max e o Opus 5 xhigh chegam ambos aos 67 pontos, por 7,08 $ e 8,23 $ por tarefa, enquanto o Opus também lidera a compreensão de repositórios com 55% no SWE-Atlas Q&A [1] [2]. O Fable 5 max surge logo depois, com 66 pontos, mas custa 11,71 $ por tarefa [2]. O Kimi continua competitivo onde é mais forte: os seus 84% no Terminal-Bench v2 superam os 83% do Sol high e ficam a poucos pontos dos modelos com esforço máximo [1] [2].

A compreensão de repositórios é a fraqueza evidente. O Kimi obtém 37% na componente de perguntas sobre código, abaixo dos 40% do Sol medium e bastante atrás das configurações Claude [1] [2]. Isso importa menos ao começar um projeto novo, mas numa base de código existente com 300.000 linhas, compreender o que já existe ocupa grande parte do trabalho.

Porque é que o Kimi K3 está a gerar tanto entusiasmo? Resultados no navegador

As classificações do Kimi nas arenas criaram grande parte do entusiasmo porque mostram que as pessoas preferem o seu trabalho no navegador, mesmo quando testes de agentes que cobrem mais tipos de trabalho revelam fraquezas. O modelo lidera a classificação de código fullstack da Arena [3] e ocupa o segundo lugar na WebDev Arena, à frente do Claude Fable 5 e do GPT-5.6 [4]. Os pesos abertos e os preços por token aparentemente baixos aumentam o interesse.

Os resultados das arenas são importantes porque medem o que as pessoas preferem, não se o código passa uma bateria de testes. Na tabela fullstack de 24 de julho de 2026, o Kimi K3 max ficou em primeiro lugar com 1.664 pontos, à frente do GPT-5.6 Sol com 1.633 e do Fable 5 com 1.623 [3]. Quatro dias depois, o Opus 5 max liderou a WebDev Arena com 1.712 pontos, enquanto o Kimi ficou em segundo com 1.682 após 3.777 votos, à frente do Fable 5, do Sol e do GLM-5.2 [4]. Os utilizadores gostam claramente daquilo que o Kimi cria no navegador.

Os lançamentos confirmam a afirmação sobre os pesos abertos. A Moonshot descreve o Kimi K3 como o primeiro modelo de pesos abertos com 2,8 biliões de parâmetros, uma janela de contexto de um milhão de tokens, visão integrada e preços de API de 3 $ por milhão de tokens de entrada e 15 $ por milhão de tokens de saída [5]. A Z.ai publica o GLM-5.2, mais pequeno, com 753 mil milhões de parâmetros e uma licença MIT [6], a preços de tabela de 1,40 $ pela entrada e 4,40 $ pela saída [7]. Considerando apenas o preço de tabela, ambos parecem muito mais baratos do que os concorrentes ocidentais.

O próprio artigo de lançamento da Moonshot é mais contido do que essa comparação sugere. A empresa diz que o K3 ainda fica atrás do Fable 5 e do GPT-5.6 Sol, com “uma diferença percetível na experiência de utilização” face aos dois [5]. As medições independentes de agentes tornam essa diferença concreta, sobretudo na velocidade e na compreensão de repositórios. Vale a pena recordar a prudência da própria Moonshot sempre que um laboratório chinês é apontado como a causa de alguma coisa, e é isso que defendo em a marca de água no texto do Claude responde à UE e não aos laboratórios chineses.

O que mede o Coding Agent Index? Sistemas completos de agentes

O Coding Agent Index mede sistemas completos de modelo e agente em engenharia de software, trabalho de terminal e perguntas sobre repositórios. A Artificial Analysis combina 113 tarefas DeepSWE, 84 tarefas Terminal-Bench v2 e 124 perguntas SWE-Atlas Q&A com o mesmo peso na versão 1.3 [8].

Esse limite é importante porque o Kimi correu dentro do Kimi Code CLI, o GLM-5.2 dentro do Claude Code, o Sol dentro do Codex e os modelos Claude dentro do Claude Code [1] [2]. Cada pontuação reflete, portanto, o modelo, o respetivo agente e o nível de esforço escolhido. A tabela permite comparar essas configurações em funcionamento, mas não revela como os mesmos pesos ficariam classificados num harness neutro.

O Kimi K3 e o GLM-5.2 são mais baratos? Não por tarefa concluída

Não. O custo de uma tarefa concluída depende de quantos tokens o agente utiliza e da frequência com que tem sucesso, não apenas do preço de cada token. O GLM-5.2 é o exemplo mais claro: tem o preço de tabela mais baixo, mas custa mais por tentativa do que todas as configurações ocidentais com esforço medium [2] [7].

A Anthropic tornou permanente o preço introdutório do Claude Sonnet 5, de 2 $ pela entrada e 10 $ pela saída por milhão de tokens [9]. O Kimi K3 custa 3 $ e 15 $ [5], pelo que os preços de entrada e saída são 50% superiores aos do Sonnet. O Kimi não tem uma vantagem de preço de tabela face a este modelo.

Nos escalões seguintes, a Anthropic cobra 5 $ pela entrada do Opus 5 e 25 $ pela saída, enquanto o Fable 5 custa 10 $ e 50 $ [9]. A OpenAI cobra 5 $ e 30 $ pelo GPT-5.6, ou 10 $ e 45 $ no escalão de contexto longo [10]. A Z.ai fica abaixo de todos com o GLM-5.2 a 1,40 $ e 4,40 $, além das leituras de cache a 0,26 $ [7]. Todos os valores são por milhão de tokens.

Estas unidades não permitem uma comparação perfeita. Os fabricantes usam tokenizers diferentes, e a Anthropic afirma que o seu tokenizer atual produz cerca de 30% mais tokens para o mesmo texto do que o anterior [9]. O guia de início rápido da Moonshot também diz que o Kimi K3 raciocina sempre, não permite desativar esse modo e usa max por omissão [11]. Os tokens de raciocínio ocultos continuam a aparecer na fatura.

preço de tabela por milhão de tokens de entrada

1,40 $

o modelo mais barato desta comparação

valor medido por tentativa

6,51 $

dentro do Claude Code, 25,1 minutos ativos

valor derivado por tarefa resolvida

15,14 $

custo por tentativa dividido pela taxa de sucesso de 43%

Quando comparo tarefas resolvidas em vez de tentativas, o Sol medium, o Opus 5 medium e o Kimi K3 ficam próximos, em cerca de 4,90 $, 5,06 $ e 5,21 $. O GLM-5.2 sobe para 15,14 $, cerca de três vezes mais. O preço por token mais baixo do grupo produz o custo estimado mais alto por resultado bem-sucedido.

A estimativa continua a favorecer as execuções falhadas porque exclui o tempo do engenheiro. Dez minutos a rever uma falha custam mais do que qualquer encargo da figura, por isso a taxa de sucesso conta muito mais do que o preço dos tokens quando uma pessoa tem de inspecionar o resultado. Resolvida a questão do custo, importa perceber quais as tarefas em que o Kimi é suficientemente adequado para justificar execuções mais lentas.

Em que é que o Kimi K3 é bom? Terminais e trabalho fullstack

O Kimi K3 é mais convincente em tarefas centradas no terminal, desenvolvimento web fullstack e execuções longas de agentes, sobretudo quando uma equipa precisa de pesos abertos e alojamento local. As medições independentes, os votos das arenas e os resultados da própria Moonshot apontam todos para esses usos [1] [3] [5]. Não sustentam a ideia de que o Kimi seja uma alternativa direta e mais barata para trabalhar em grandes repositórios existentes.

O resultado de terminal aparece tanto nos testes independentes como nos do fabricante: a Artificial Analysis mediu 84% na CLI do próprio Kimi, enquanto a Moonshot mediu 88,3% na configuração que prefere [1] [12]. O K3 também lidera a tabela SWE-Marathon da Moonshot com 42 pontos, embora as notas sejam importantes. O Fable 5 usou modelos de recurso em 35% das tarefas e algumas linhas do Kimi executaram um ramo de pré-lançamento calibrado para hardware H20 [12]. Juntando o codificador de visão dedicado do Kimi e a janela de contexto de um milhão de tokens, o fluxo de trabalho entre código e capturas de ecrã proposto pela Moonshot tem suporte técnico credível [5] [12].

Esses pontos fortes trazem limites práticos. Os 37% na componente de perguntas sobre código tornam o Kimi uma escolha duvidosa quando a compreensão do repositório domina a tarefa [1], e 23,8 minutos ativos por execução obrigam a correr agentes em paralelo ou a esperar. O alojamento próprio também não é simples: 2,8 biliões de parâmetros exigem cerca de 1,4 TB só para os pesos com quantização de 4 bits, antes da cache KV e dos recursos necessários para servir o modelo. Uma instalação prática exige, portanto, um cluster de servidores e não uma estação de trabalho.

As condições legais acrescentam outra verificação antes da adoção. Uma empresa que venda modelos como serviço e ultrapasse 20 milhões de dólares em receitas totais precisa de um acordo separado com a Moonshot, enquanto os produtos com mais de 100 milhões de utilizadores ativos mensais ou 20 milhões de dólares em receitas mensais têm de apresentar “Kimi K3” de forma destacada. O uso interno está isento [13]. Os termos padrão da API da Moonshot também permitem utilizar o conteúdo dos clientes para fornecer, manter, desenvolver, apoiar e melhorar os serviços, enquanto as restrições ao treino de modelos são tratadas em acordos empresariais separados [14]. Eu pediria essas restrições por escrito antes de enviar um repositório proprietário para a API pública.

Porque é que o GLM-5.2 tem dificuldades no Claude Code? O agente importa

A queda de nove pontos do GLM-5.2 no Terminal-Bench deve ser lida como um aviso sobre a configuração do agente, não como prova de que os pesos do modelo são fracos. O modelo obtém 81% no harness Terminus da Z.ai e 72% dentro do Claude Code [6] [2]. Ninguém fora da Z.ai consegue identificar a causa exata, mas a invocação de ferramentas, a recuperação de erros, a cache ou as convenções do agente podem explicar a diferença.

Seja qual for a causa, essa configuração tem um desempenho fraco. O GLM-5.2 faz 43 no índice e 29% tanto no DeepSWE como nas perguntas sobre código. Com 6,51 $ e 25,1 minutos ativos por tentativa, é também a configuração mais lenta da comparação [2]. Os preços de 1,40 $ pela entrada e 4,40 $ pela saída nunca se traduzem num custo baixo por tarefa.

A ficha do modelo da Z.ai mostra por que razão o sistema envolvente importa. O resultado de 62,1 no SWE-Bench Pro usa o OpenHands com um prompt adaptado, o DeepSWE corre em contentores isolados com limites de duas horas e o Terminal-Bench usa o Terminus com um orçamento de quatro horas [6]. São medições válidas do GLM-5.2 numa configuração escolhida para o modelo, mas não preveem como se comportará noutro agente.

O GLM-5.2 ainda pode fazer sentido quando é alojado pela própria equipa e o trabalho é verificado automaticamente. Os 753 mil milhões de parâmetros e a licença MIT tornam-no mais fácil de alojar do que o Kimi K3 [6], enquanto o preço de entrada de 1,40 $ é adequado para codemods em massa ou migrações apoiadas por verificações determinísticas. Essas verificações podem rejeitar os 57% de tentativas falhadas sem revisão manual. Se um engenheiro tiver de as inspecionar, o desconto nos tokens deixa de poupar dinheiro. Alojá-lo é um custo à parte, como vi com o DeepSeek V4.1 Flash, que tem API barata e pesos abertos enormes.

Como ler uma classificação de código: compare primeiro o harness

Comece pelo harness, pela versão do benchmark e pela tarefa medida, porque a pontuação de uma classificação pertence a essa configuração. A diferença entre o sucesso do Kimi nas arenas e os resultados do GLM dependentes do harness mostra por que razão o nome do modelo e o número final não chegam.

Sinal	O que premeia	O que não lhe pode dizer
DeepSWE, 113 tarefas	concluir tarefas de engenharia de ponta a ponta	adequação às convenções do seu código
Terminal-Bench v2, 84 tarefas	levar uma shell a um estado final verificado	compreensão de um grande repositório existente
SWE-Atlas Q&A, 124 tarefas	responder a perguntas técnicas sobre código	capacidade de implementar a alteração descrita
WebDev e Fullstack Arena	preferência em comparações diretas	correção, testes, segurança e manutenção
Fichas dos fabricantes	o modelo na melhor configuração do fabricante	comparação entre linhas

A infraestrutura é a primeira fonte de incerteza. A equipa de engenharia da Anthropic alterou uma pontuação do Terminal-Bench 2.0 em seis pontos percentuais apenas através dos limites de recursos, enquanto os erros de infraestrutura desceram de 5,8% para 0,5% quando esses limites aumentaram [15]. A equipa concluiu que diferenças inferiores a cerca de três pontos devem ser vistas com ceticismo até as configurações estarem documentadas e alinhadas. O Kimi e o Sol medium ficam dentro desse intervalo, por isso a pontuação igual indica paridade e não uma vitória de qualquer um deles.

O segundo problema é a falta de consistência na configuração dos testes. A Moonshot executa cada concorrente num harness diferente, usa modelos de recurso em algumas linhas e inclui um benchmark próprio. O Fable 5 recorreu a modelos de recurso 13 vezes e recusou uma de 80 tarefas nesse teste [12]. A Moonshot divulga os pormenores, mas uma comparação perde grande parte do valor quando essas notas desaparecem do resumo.

Por fim, a versão do benchmark tem de coincidir. A Artificial Analysis atribui versões ao índice porque o conjunto de tarefas muda, sendo a v1.3 a versão atual nesta análise [8]. As pontuações de versões diferentes não permitem uma comparação direta, mesmo que o nome do benchmark continue igual. Uma comparação útil indica, portanto, o harness, o nível de esforço, o orçamento da tarefa e a versão. A reavaliação do Muse Spark 1.3 no índice da Artificial Analysis mostra o quanto uma mudança de versão pode alterar uma posição.

A minha distribuição: Kimi para UI, GLM com verificações automáticas

Eu testaria o Kimi K3 em projetos fullstack novos e trabalho centrado na UI, enquanto manteria o GLM-5.2 atrás de verificações automáticas num harness nativo. Para o resto, continuaria a encaminhar o trabalho para o Claude ou o GPT-5.6 conforme a tarefa:

O trabalho	A minha escolha hoje
Alterações de rotina com testes sólidos	Sonnet 5, ao preço permanente de 2 $/10 $
Ciclos rápidos de agentes e trabalho de terminal	GPT-5.6 com esforço medium ou high
Trabalho num grande repositório existente	Opus 5 com esforço medium ou high
Projetos fullstack novos e muito trabalho de UI	Kimi K3, apoiado pelos resultados das arenas
Trabalho em massa com verificação automática	GLM-5.2 no harness nativo, como projeto-piloto
Escalada quando tudo o resto falha	Fable 5, com moderação

A tabela segue a mesma regra que usei durante a semana de lançamento do Opus 5: comparar o custo das alterações aprovadas, não apenas os preços dos tokens. Isso coloca o Kimi onde os resultados de terminal e das arenas são mais fortes e reserva o GLM para trabalho protegido por verificações automáticas.

Duas medições mudariam estas escolhas. O Kimi K3 precisa de manter os 61 pontos num harness neutro, como o Claude Code ou o Codex, o que permitiria separar a capacidade do modelo da vantagem do Kimi Code CLI. O GLM-5.2 precisa do teste oposto: uma execução independente no seu agente nativo, feita por quem não o vende. Até lá, ambos mostram capacidade útil em tarefas específicas, mas nenhum oferece a vantagem geral de custo sugerida pelo preço por token.