Kimi K3 na prática: experiência prática e comparação com o Claude Code

Como correu a experiência do autor#

O Kimi K3 foi lançado a 16 de julho de 2026. Tem 2,8 biliões de parâmetros, uma janela de contexto de um milhão de tokens, pesos abertos e o primeiro lugar numa comparação cega de frontend. Reuni todos os pormenores sobre a sua arquitetura, benchmarks e preços na análise completa do Kimi K3 em comparação com o Claude Code, pelo que não os vou repetir aqui.

No final dessa análise, escrevi: o risco é perder um dia na configuração; a compensação é uma fatura que baixa a partir da segunda semana. Fiz a experiência com as minhas próprias tarefas.

As primeiras horas são mesmo entusiasmantes. O modelo pega prontamente numa tarefa, gera trabalho de frontend coerente e não hesita perante ficheiros grandes. Foi por isso que escrevi no canal que estava agradavelmente surpreendido. Os problemas surgiram em sessões longas, com vários agentes, em rondas repetidas de edições e, à noite, no terminal.

No fim, voltei atrás. Eis o que me levou a essa decisão, com números e ligações a fontes primárias para poder verificar tudo por si.

Porque mostram os benchmarks que o Kimi K3 supera o Claude?#

Eis os benchmarks em que o Kimi K3 supera o Claude Fable 5:

A llm-stats compilou os benchmarks; cada linha compara com o Claude Fable 5.

Os números são reais. Nos 35 benchmarks do mesmo resumo, o Claude Fable 5 vence 22, o Kimi K3 vence doze e há um empate.

Mais interessante é perceber onde o Kimi K3 fica aquém. O défice nos benchmarks de programação é modesto, de 4–5 pontos. Fica para trás em conhecimento e raciocínio: no HLE, o Claude ganha uma vantagem de quase 10 pontos. É precisamente aí que uma tarefa longa esbarra num obstáculo: primeiro é preciso compreender, e só depois se pode escrever.

A Moonshot descreve-o assim na secção principal da publicação de lançamento:

Porque parece o Kimi K3 duas vezes mais lento na prática?#

A comparação usa o Claude Opus 4.8, a versão do Claude para a qual existe uma medição completa de velocidade.

O Kimi K3 responde mais cedo, por isso parece subjetivamente mais rápido num chat curto. No trabalho, o tempo é gasto noutra coisa: na lentidão com que chega a resposta completa. Aqui perde por quase metade e, numa resposta longa, a diferença acumula-se em minutos.

O Kimi Code anuncia 180–260 tokens por segundo, um valor que parece convincente ao lado dos meus 34.7. Refere-se à versão rápida da geração anterior, K2.7 Code HighSpeed. O Kimi K3 não tem de todo uma versão desse tipo, e o benchmark independente mede o próprio Kimi K3.

Uma sessão que falha ao sétimo erro e gasta tokens em chamadas repetidas é uma falha de engenharia de contexto; a escolha do modelo é secundária neste caso.

Para onde vão os tokens se não é possível desligar o raciocínio?#

É possível reduzir o nível de esforço; a documentação indica três: baixo, alto e máximo. Mas não é possível desligar completamente o raciocínio: a documentação afirma explicitamente que o raciocínio e o armazenamento do respetivo histórico estão sempre ativados no Kimi K3. Nas chamadas diretas à API, o nível máximo está definido por predefinição, e a maioria dos programas wrapper não o altera.

Cada turno acrescenta milhares de tokens de saída a $15 por milhão. Além disso, a Moonshot exige que devolva a mensagem completa do assistente, incluindo o histórico do raciocínio, e esses tokens de saída voltam a ser tokens de entrada no turno seguinte.

Assim, paga duas vezes pelo mesmo raciocínio: primeiro, quando o modelo o escreve; depois, quando o envia de volta ao modelo.

No índice geral, o Kimi K3 usa 21% menos tokens de saída do que o seu antecessor, o K2.6. O modelo tornou-se mais económico em comparação com a sua própria versão anterior. O Claude continua a usar menos nas mesmas tarefas.

O prompt “hi” é faturado como 86 tokens. Nos bastidores, existe um prompt de sistema oculto com cerca de 85 tokens, pelo qual paga em cada pedido.

Tenho uma análise separada sobre como calcular a utilização e onde consultar o saldo restante: quantos tokens lhe dão o Claude Pro e o Max. A lógica de cálculo é a mesma; só os preços mudam.

O que acontece quando o modelo fica preso no raciocínio?#

É assim que se manifesta. O modelo começa a pensar, mas, em vez de desenvolver o raciocínio, o texto entra em repetição: a mesma palavra, depois fragmentos de sílabas, sem fim. A tarefa fica parada enquanto o contador de tokens continua a girar.

Um relato de 28 de julho na lista de problemas conhecidos da Moonshot descreve o Kimi K3 a tentar ler o mesmo ficheiro seis vezes seguidas, a receber sete vezes a rejeição “no-op call, file hasn’t changed since the previous read” e, depois, a terminar o turno como se nada tivesse acontecido. No rastreador de problemas do Kimi CLI, o autor enumera quatro variantes do mesmo tipo de bloqueio — leitura, substituição, testes e análise — e resume-as numa frase:

A Moonshot indica diretamente a causa. O modelo foi treinado num modo que preserva o histórico do raciocínio e tem de receber de volta, na íntegra, o raciocínio anterior. Se o histórico chegar incompleto, o modelo tenta reconstruir a resposta, produz a mesma chamada de ferramenta e inicia outro ciclo.

O autor de uma análise num encaminhador de pedidos de terceiros apresenta o mesmo diagnóstico: o Kimi é suficientemente rigoroso para rejeitar pedidos com histórico de raciocínio incompleto. Um wrapper externo desconhece esse rigor e trunca o histórico.

Porque falha uma configuração multiagente com o Kimi K3?#

A documentação oficial da Moonshot afirma-o claramente: a respetiva API ainda não suporta WebFetch. Por outras palavras, o Claude Code, que normalmente acede à Internet para obter uma página, não consegue fazê-lo com o Kimi K3. A solução alternativa consiste em colar o conteúdo manualmente ou ligar uma ferramenta de terceiros.

O Claude Code pode carregar ferramentas a pedido e coloca no histórico um bloco de serviço do tipo tool_reference. O Kimi não aceita este tipo e devolve um erro 400. Fá-lo silenciosamente, sem indicar o campo nem o motivo:

{"error":{"type":"invalid_request_error","message":"Invalid request Error"},"type":"error"}

Para comparação, eis o aspeto da mesma falha na API nativa da Anthropic, onde o servidor pelo menos indica o campo e enumera os tipos aceites:

messages.166.content.0.tool_result.content.0: Input tag 'tool_reference' found
using 'type' does not match any of the expected tags: 'document', 'image',
'search_result', 'text'

A diferença é importante. É impossível diagnosticar a primeira mensagem: nem o cliente nem a pessoa por trás dele conseguem perceber que bloco foi rejeitado. É precisamente disso que se queixam os autores dos relatos. Programadores de ferramentas para alternar entre fornecedores já sugerem que o carregamento diferido de ferramentas seja desativado por predefinição no Kimi ou que a API da Moonshot seja assinalada como não aceitando estes blocos.

A consequência é descrita num relato separado, aberto a 17 de julho e ainda sem resposta. O autor encontrou este erro sete vezes numa sessão. A sessão sobreviveu às primeiras seis; a sétima terminou-a definitivamente: depois disso, até escrever o texto simples “continue” provocou uma falha. O autor observa também que estava muito longe do limite de contexto, pelo que a explicação de que “o histórico era demasiado longo” não se sustenta.

Eis um resumo dos tipos de bloco que a API da Moonshot aceita e rejeita:

A palavra “compatível” descreve aqui apenas o formato do pedido. Tudo o resto é diferente: os tipos de bloco aceites, o conteúdo exigido no histórico e as ferramentas que estão sequer disponíveis.

O que não transita para o Kimi K3?#

A secção de limitações da publicação de lançamento diz literalmente:

O programador do modelo está a dizer: usem o nosso cliente; não garantimos o comportamento de outro cliente.

O segundo ponto da mesma secção explica mais uma coisa que eu atribuía à teimosia do modelo:

O meu CLAUDE.md foi escrito para o hábito oposto: perguntar, apresentar um plano e esperar por confirmação. As instruções continuam lá, mas agora são lidas por um modelo com um temperamento diferente.

Se quiser manter um único ficheiro de regras para vários agentes, expliquei essa configuração separadamente: um ficheiro de instruções para Claude Code, Codex e Cursor.

Quanto custou realmente o Kimi K3?#

Primeiro, os preços, que favorecem o Kimi K3:

Os preços do Kimi vêm da documentação sobre caching de contexto; a coluna da direita apresenta os preços do Claude Opus 5 a 30 de julho de 2026.

A cache do Kimi é automática, não pode ser desativada e é identificada pelo hash no início do pedido. Qualquer edição do prompt de sistema ou da lista de ferramentas limpa completamente a cache de mensagens.

Eis o que o Claude Code faz durante um dia normal de trabalho:

1. Liga e desliga ferramentas externas à medida que a tarefa avança.
2. Carrega ferramentas a pedido, quando são necessárias.
3. Inicia subagentes com um conjunto diferente de ferramentas.
4. Adiciona o ficheiro de instruções ao prompt de sistema.
5. Reconstrói o histórico ao comprimir o contexto.

Cada item desta lista repõe o início do pedido e, por conseguinte, a cache. Os tokens de entrada voltam a custar $3 por milhão, em vez de 30 cêntimos — dez vezes mais. A isto junta-se o raciocínio constante, a $15 por milhão de tokens de saída, e esses mesmos tokens regressam como entrada no turno seguinte. É assim que um modelo com um preço anunciado baixo pode gerar uma fatura inesperada.

Segundo os dados agregados da OpenCode, em quase 280,000 sessões em direto, uma sessão média do Kimi K3 custa $1.86, com um volume médio de 3.1 milhões de tokens. Esse valor pressupõe que 93% dos tokens de entrada são servidos pela cache. Altere o início do pedido e o valor deixa de se aplicar a si.

Os planos Kimi custam $19, $39, $99 e $199. A quota provém de um fundo partilhado por toda a subscrição, é reposta semanalmente sem transitar os montantes não utilizados e usa uma janela móvel de cinco horas. A análise dos planos descreve-o assim: quatro terminais com o Kimi K3, que raciocina continuamente, esgotam rapidamente uma janela de cinco horas.

A quota de programação do plano de $99 é comparável à do plano de $200 da Anthropic, o que contraria a minha própria posição. O Kimi é mais barato por token, mas já não se nota isso na fatura ao fim do dia.

Em que é que o Kimi K3 é objetivamente bom?#

1. Frontend. Primeiro lugar numa comparação cega feita por programadores em atividade. Constrói layouts de forma cuidada e com bom gosto.
2. Volume. Uma janela de contexto de um milhão de tokens, e os ficheiros longos não o intimidam. Analisar um repositório grande e mapear a sua estrutura é exatamente o tipo de tarefa que lhe convém.
3. Primeira resposta. O tempo até ao primeiro token é metade do do Claude. Nota-se e sabe bem numa conversa curta.
4. Preço por token. Cerca de 60% do preço do Claude Opus 5. Se o início do pedido não mudar, isto gera poupanças reais em cargas de trabalho grandes e repetitivas.
5. Pesos abertos. O modelo não está preso a um único fornecedor.

Há uma ressalva quanto a este último ponto. Não é realista executar em casa um modelo deste género: mesmo comprimidos, os seus pesos ocupam terabytes. Neste caso, abertura significa independência de um único fornecedor.

Como testar tudo isto por si num serão#

1. Configure o acesso seguindo as instruções. Descrevi as três variáveis de ambiente e as substituições de modelos por nível na análise do Kimi K3 em comparação com o Claude Code. Verifique a configuração com o comando /status: o Kimi não aparecerá no menu de seleção de modelos porque este tem uma lista integrada de aliases, e não precisa de lhe mexer.
2. Remova a chave antiga. Se tinha definido anteriormente ANTHROPIC_API_KEY, remova-a. Em conjunto com ANTHROPIC_AUTH_TOKEN, provoca um conflito e receberá um erro de autorização sem motivo válido.
3. Desative imediatamente o carregamento diferido de ferramentas. Faça-o antes da primeira execução, não depois de a primeira sessão falhar.
4. Não mude de modelo a meio da tarefa. Se começou com o Kimi K3, termine com o Kimi K3. O inverso também se aplica. É uma exigência direta da Moonshot, citada acima.
5. Use uma tarefa real sua. Uma em que tenha trabalhado ontem, com toda a sua confusão e pontas soltas. Um jogo da cobra não mostrará a diferença: esta só aparece a longo prazo.
6. Anote dois valores. Quantos minutos demorou e quanto dinheiro gastou nesse serão. Compare com um serão habitual no Claude.
7. Acompanhe separadamente o tempo de inatividade. Quando o agente bloqueia, lê repetidamente o mesmo ficheiro ou responde com um erro, isso também faz parte do custo.

Se a fatura do serão for superior ao esperado, quase sempre a causa é a cache: conte quantas vezes o início do pedido foi reposto nesse serão. O preço por token tem pouco que ver com isso.

O que acabei por manter#

Os leitores do canal que testaram o modelo comigo chegaram, de forma independente, à mesma configuração: pedem ao Kimi K3 que inspecione o repositório e dê uma segunda opinião, enquanto deixam o trabalho principal ao agente que já conhecem. Esta configuração funciona porque não exige mudar o wrapper nem quebrar o que já funciona.

Pode resumir-se assim: uma tarefa completa vai para o Kimi K3; uma longa cadeia que envolve ferramentas e subagentes vai para o Claude Code. Quanto mais mudanças entre ferramentas uma tarefa exigir, mais custa no Kimi K3 e maior é a probabilidade de a sessão falhar.

Tenho uma análise separada sobre como atribuir funções a dois agentes sem os confundir: três formas de trabalhar com dois agentes.

Os benchmarks respondem à pergunta “quem é mais forte em condições de laboratório?” A fatura do seu serão e a lista de trabalhos concluídos respondem à pergunta “quem é mais forte para si?” Quando as respostas diferem, confie na segunda: foi você que a calculou, não o departamento de marketing.

Depois de analisar tudo isto, tomei a minha decisão: digam o que disserem sobre os novos modelos, um líder continua a ser um líder. O Claude Code continua a ser o meu motor principal.