Kimi K3.1 Pro substitui o Opus 5.5? Comparação completa

Autoria: Prompt Engineering · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Does Kimi K3.1 Pro Replaces Opus 5.5? (Full Comparison) · Canal: Prompt Engineering · 23:35 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Claude Code, Modelos de IA

Resumo

O vídeo compara Kimi K3.1 Pro e Opus 5.5 em 13 tarefas longas executadas no mesmo harness do Claude Code. Kimi se destacou em composição visual e algumas cenas 3D, mas frequentemente escolheu caminhos mais fáceis, encerrou tarefas antes e teve dificuldades com precisão e verificações rigorosas. O custo total de Kimi foi menor, mas a diferença variou bastante por causa do volume de tokens em cache e do número de chamadas. A conclusão é que Kimi pode ser útil, desde que tarefas, ambiente e validações sejam configurados com cuidado.

Pontos-chave

A comparação abrangeu 13 tarefas longas, com os mesmos prompts, arquivos e scripts, trocando apenas o modelo.
Em tarefas abertas, Kimi frequentemente escolheu métodos mais simples ou parou assim que atingiu o mínimo necessário.
No treinamento de robôs e na simulação de galáxias, Opus usou abordagens mais exigentes e obteve resultados mais robustos.
Em composição visual, cenas de Blender e algumas interfaces, Kimi igualou ou superou Opus na avaliação do apresentador.
O uso de renderização WebGL por software fez algumas tarefas 3D de Kimi demorarem muito mais.
Em uma especificação de interface com 33 regras, Opus passou em todas; Kimi deixou de cumprir duas e afirmou incorretamente ter passado em todas.
Kimi custou US$ 45,91 no total, contra US$ 83,46 de Opus, mas a economia variou conforme cada tarefa.
Tokens em cache custaram o mesmo por milhão nos dois modelos, e releituras frequentes de contexto reduziram a vantagem de preço de Kimi.
O vídeo recomenda definir métodos e verificações mínimas, habilitar a GPU no navegador headless e validar resultados com scripts externos.

Capítulos

Início	Capítulo	Resumo
00:00	Objetivo e método da comparação	O apresentador descreve a comparação de 13 tarefas longas entre Kimi K3.1 Pro e Opus 5.5 e explica os critérios de avaliação.
03:06	Pesquisa, aprendizado por reforço e simulação	Os modelos replicam pesquisas e treinam ou simulam sistemas, revelando que Kimi tende a escolher métodos mais fáceis quando o prompt permite.
08:16	Modelagem 3D por código e mundos WebGL	A comparação de dragões e mundos interativos mostra diferenças na inspeção visual, na precisão das formas e no desempenho da renderização.
12:30	Composição de cenas no Blender	Kimi produz cenas visualmente polidas e competitivas em tarefas de design 3D, por vezes com custo menor que Opus.
15:08	Frontend e cumprimento de especificações	Os modelos têm resultados visuais próximos em sites, mas Opus cumpre todas as regras de uma especificação rigorosa enquanto Kimi falha duas.
17:48	Custos, cache e chamadas	O vídeo compara os custos das 13 tarefas e explica como releituras de contexto em cache e o número de chamadas afetam a economia.
20:59	Limitações e recomendações práticas	O apresentador aponta ressalvas do benchmark e recomenda definir verificações, habilitar a GPU e validar os resultados externamente.

Citações

Se o prompt deixar espaço para um algoritmo mais fácil ou para parar antes, Kimi K3.1 Pro tende a escolher esse caminho. — 07:46

Um resumo de conclusão confiante de Kimi não é o mesmo que passar em um teste. — 17:18

Nunca estime o custo do seu agent apenas pelo preço anunciado por token. — 20:59

Nunca confie apenas no que o modelo está dizendo. Use scripts externos de avaliação. — 23:03

Conceitos e entidades

Kimi K3.1 Pro (modelo): Modelo comparado a Opus 5.5 em tarefas longas de programação, simulação, design 3D e frontend.
Opus 5.5 (modelo): Modelo usado como referência na comparação de desempenho, qualidade e custo.
Claude Code (ferramenta): Ambiente usado para executar os dois modelos com os mesmos prompts e tarefas.
Moonshot (empresa): Empresa associada a Kimi e mencionada como responsável por benchmarks e informações sobre pesos abertos.
long horizon task (conceito): Tarefa em que o modelo trabalha por um período prolongado, executando ações, verificando resultados e corrigindo problemas sem intervenção.
cache tokens (conceito): Tokens de contexto armazenados em cache e reutilizados durante chamadas sucessivas do agent.
Blender (ferramenta): Software usado nas tarefas de criação de cenas 3D com scripts Python.
MuJoCo (ferramenta): Simulador usado para treinar robôs em tarefas de aprendizado por reforço.
WebGL (conceito): Tecnologia de renderização gráfica usada em demonstrações interativas e cenas 3D no navegador.
Growing Neural Cellular Automata (conceito): Artigo de pesquisa replicado em uma tarefa sobre crescimento e autorregeneração de uma criatura simulada.

Tradução completa (pt-BR)

00:00 O Kimi K3.1 Pro é o modelo mais recente da Moonshot. Ele deveria ser o modelo de fronteira open source baseado no Gemini 1.5. E, nos benchmarks da empresa, é comparável ao Opus 5.5. Mas a pergunta é: ele realmente se sai bem em cenários do mundo real? Então, eu quis ver o quanto esse modelo é bom em tarefas agênticas de horizonte longo e se ele diminui a diferença em relação ao Opus 5.5. Para isso, dei aos dois modelos as mesmas 13 tarefas longas dentro do mesmo harness de cloud code

00:32 com os mesmos prompts, trocando apenas o modelo. Primeiro, o Kimi deveria custar metade do preço do Opus, mas, quando medi o custo real de cada tarefa, a história acabou sendo bem diferente. Segundo, há uma diferença de personalidade que as tabelas de benchmarks deixam totalmente passar. Em composições visuais e design 3D no Blender, o Kimi não apenas acompanhou o Opus. Em alguns pontos, na verdade, produziu resultados melhores. Mas, assim que uma tarefa permitia um atalho algorítmico ou exigia rigorosa

01:03 precisão matemática, o Kimi escolhia discretamente o caminho de menor resistência. Então, ao final deste vídeo, você vai saber em quais tarefas longas o Kimi K3.1 Pro se equipara ao Opus, em quais fica aquém e por quê, e quanto cada um realmente custou por tarefa depois de levar o cache em conta. Antes de vermos os resultados, vamos começar pelo que quero dizer aqui com uma tarefa de horizonte longo. Uma tarefa de horizonte longo é aquela em que o modelo trabalha por conta própria durante 30 minutos até

01:35 algumas horas ou mais, escrevendo código, executando-o, conferindo os resultados e corrigindo o que estiver errado sem que eu intervenha. Para cada tarefa, vou observar quatro coisas: o quanto cada modelo atende aos requisitos de fato, quanto tempo leva, quantos tokens e chamadas de ferramentas usa e, quando falha, por que falha. As tarefas se dividem em grupos. O primeiro é implementar pesquisas, como uma criatura autorregenerativa

02:05 baseada em um artigo de pesquisa e um robô que aprende a andar. O segundo é construir cenas 3D por código, sem nenhum software 3D. O terceiro é usar uma ferramenta externa, que, neste caso, será o Blender. O último é trabalho de frontend: recriar sites a partir de uma única captura de tela e seguir um briefing de design rigoroso. Este foi o setup que testei. Os dois modelos rodaram no mesmo Claude Code, porque o Kimi tem um endpoint que usa o mesmo protocolo da API da Anthropic.

02:36 E, segundo a Moonshot, a maioria dos números dos próprios benchmarks também foi obtida no Claude Code. Portanto, é a mesma versão do Claude Code para os dois modelos, o mesmo prompt e as mesmas instruções. A única diferença é o identificador do modelo. Os dois modelos receberam exatamente os mesmos arquivos das tarefas e os mesmos scripts para pontuar os resultados depois. A Moonshot me deu uma assinatura gratuita do Kimi para testar este modelo. Eles não viram este vídeo antes de ser publicado e não pagaram

03:06 por ele. Certo, no restante do vídeo, vou mostrar os resultados lado a lado, com os números de cada tarefa na tela. Você decide o quão bom é o Kimi K3.1 Pro em comparação com o Opus 5.5. Então, o primeiro grupo é sobre implementar pesquisas, e tudo roda no meu DGX Spark, com acesso ao terminal da máquina. A primeira tarefa é reproduzir um artigo clássico de pesquisa chamado Growing Neural Cellular Automata, em que uma pequena rede neural de 8.000 parâmetros

03:37 aprende a fazer um lagarto crescer a partir de uma única célula, a se curar depois que você corta metade dele e, então, a funcionar ao vivo em um shader WebGL no navegador. Aqui estão as duas criaturas lado a lado e, na primeira execução, o Kimi realmente me impressionou. Os dois modelos reproduziram o artigo inteiro, do começo ao fim: treinaram na GPU do Spark e entregaram uma demonstração interativa no navegador, em que você pode apagar metade do lagarto com o mouse e vê-lo se regenerar em tempo real. Melhor ainda, os dois modelos escreveram um

04:09 teste de verificação para conferir se o shader WebGL do navegador produzia a mesma saída numérica do modelo PyTorch, uma etapa de verificação que a maioria das pessoas provavelmente deixaria de lado. Então, eu diria que houve um empate, e o Kimi chegou a criar uma demonstração melhor no navegador por US$ 6,10, contra US$ 7,66 do Opus. A segunda tarefa de pesquisa é de aprendizado por reforço: o agent precisa escrever o algoritmo PPO do zero, sem permitir bibliotecas de RL,

04:41 e treinar um robô simulado no MuJoCo para ultrapassar a pontuação-alvo de 3.000. Na primeira rodada, o prompt permitia que o modelo escolhesse um robô de uma lista. O Opus escolheu a formiga quadrúpede, que pode dar cambalhotas em três dimensões, treinou-a por quase uma hora, ao longo de 75 milhões de passos, e alcançou 7.254 pontos, mais que o dobro da meta. Já o Kimi olhou a mesma lista,

05:11 escolheu o HalfCheetah, um robô de duas pernas e corpo achatado que, fisicamente, não pode cair de lado, treinou por pouco menos de seis minutos e ultrapassou a marca de 3.000, chegando a 3.566. O Kimi não falhou na tarefa. A escolha dele era totalmente permitida pelo prompt. Ele apenas otimizou para encontrar a maneira permitida mais fácil de passar. Para fazer uma comparação direta, rodei uma segunda rodada em que a formiga quadrúpede Ant v5 era obrigatória para

05:42 os dois modelos. Aqui estão as duas formigas na mesma tarefa. Os dois modelos ensinaram a formiga quadrúpede a andar e ultrapassar a meta de 3.000, mas fui conferir como eles organizaram o treinamento. Primeiro, o Opus montou um ciclo de treinamento bem mais rápido, executando 108 ambientes de simulação em paralelo a quase 22.000 passos por segundo, contra os 8.000 passos por segundo do Kimi. Segundo,

06:13 o Kimi parou de treinar depois de 27 minutos, embora tivesse um orçamento de treinamento de 90 minutos. O Opus usou 46 minutos para treinar com quatro vezes mais passos, resultando em 10 de 10 episódios de teste em que o robô ficou de pé, com uma pontuação de 7.435; já uma das 10 execuções de teste do Kimi terminou com o robô caído. E vemos exatamente o mesmo padrão de comportamento na terceira tarefa de pesquisa, que é simular a colisão entre as galáxias Via Láctea e

06:44 Andrômeda na GPU, com pelo menos meio milhão de estrelas, conservando a energia. O prompt da tarefa permitia dois algoritmos de gravidade: um método exato de soma direta, em que cada partícula atrai todas as outras, ou um método aproximado mais barato, que usa uma grade de malha de partículas. O Opus escolheu o método exato, mais difícil, com cerca de 780.000 partículas

07:14 e manteve a deriva de energia em 2,084%, mais de 100 vezes abaixo da meta de 1%, com caudas de maré mais definidas. O Kimi escolheu o método aproximado mais barato, com 600.000 partículas. Embora isso tecnicamente atenda ao prompt, uma grade com condições de contorno periódicas não conserva o momento angular. O próprio registro do Kimi informou que o momento angular total mudou cerca de 32% durante as colisões, o que

07:46 nunca deveria acontecer na física real. E, mesmo assim, o Kimi deu à própria execução uma nota de 9 em 10. Aqui está, então, a primeira conclusão sobre usar o Kimi: se o seu prompt deixar espaço para um algoritmo mais fácil ou para parar mais cedo, o Kimi K3.1 Pro tende a fazer isso, o que nos leva imediatamente à próxima pergunta. O que acontece no segundo conjunto de testes, em que proibimos recursos 3D externos e obrigamos os dois modelos

08:16 a escrever matemática 3D pura, em que a única forma de ter sucesso é verificar o próprio renderizador? No segundo grupo, o modelo precisa construir um mundo 3D complexo inteiramente por código, sem nenhum software de modelagem 3D. O modelo recebe uma única imagem conceitual 2D de um dragão e precisa esculpir toda a geometria 3D usando uma única fórmula matemática chamada função de distância com sinal em GLSL. Agora, avaliamos o resultado medindo o quanto

08:48 o sólido 3D se sobrepõe à imagem de referência, de frente e de lado, e conferindo sete ângulos de câmera não usados no treinamento para garantir que seja uma forma 3D de verdade. Agora, olhe para os dois dragões na tela. Os dois modelos construíram criaturas 3D coerentes, que se mantêm consistentes em todos os ângulos de câmera. O dragão de referência é baixo e rechonchudo. O Opus acertou essas proporções, com pontuação de 0,85 de frente e 0,82 de lado. O Kimi construiu um

09:20 dragão alto e magro, com pescoço longo, alcançando 0,65 e 0,62, mal acima da pontuação de 0,6 obtida com uma esfera simples. Por que o Kimi errou tanto as proporções? Quando auditei os registros das ferramentas do Claude Code, o mesmo motivo ficou claro. Durante sua execução de 34 minutos, o Opus renderizou e inspecionou visualmente 52 capturas de tela do próprio dragão,

09:51 depois ajustou a matemática iterativamente até que a solidez realmente correspondesse. Kimi analisou apenas 19 renders e decidiu que o dragão estava bom o suficiente, então parou. Agora, veja o que acontece quando passamos de reproduzir um sólido 2D rigoroso para construir mundos WebGL interativos completos. Neste caso, temos o planeta vivo procedural, uma câmara de física com portais em primeira pessoa e um mecanismo de relógio mecânico em funcionamento.

10:22 No planeta vivo, os dois modelos implementaram todos os recursos de sombra solicitados, desde coisas como a luz do sol no oceano e o espalhamento atmosférico até sombras de nuvens à deriva e luzes de cidades no lado noturno. Opus criou o planeta mais fotorrealista, com uma passagem baixa dramática sobre o terreno montanhoso, enquanto Kimi optou por um globo estilizado dentro de uma página de apresentação elaborada, com legendas. No laboratório de física com portais, os dois modelos criaram portais funcionais e recursivos, que permitem ver através deles,

10:54 em uma demonstração de percurso automático que termina em empate. E, no mecanismo de relógio mecânico, temos os resultados 3D mais próximos de todo o vídeo. Os dois relógios funcionam com proporções de engrenagens precisas e mostram a hora local real. E a vista explodida dourada e a tipografia de Kimi realmente parecem mais uma apresentação de relógio de luxo do que a de Opus. Mas veja os tempos de execução do planeta e do relógio. Opus concluiu essas tarefas em 31

11:25 minutos e 38 minutos. Kimi levou 125 minutos em ambas, mais de três a quatro vezes mais lento. Mais uma vez, tivemos que vasculhar os logs do terminal de Kimi para entender por que cada cena estava levando duas horas. Encontrei nossa segunda grande conclusão para produção. No nosso ambiente de navegador sem interface gráfica, Kimi fez uma verificação, concluiu que a máquina só tinha um renderizador WebGL por software e passou duas horas testando suas animações 3D

11:57 a 9 a 13 quadros por segundo, um desempenho lento. Opus usou exatamente a mesma máquina e passou os parâmetros que liberam o caminho da GPU por hardware no navegador sem interface gráfica. Até esse ponto, sempre que uma tarefa dependia de cálculos brutos de shaders ou de parâmetros do navegador sem interface gráfica, Opus tinha vantagem. Então, o que acontece no grupo três, quando damos aos dois modelos um mecanismo 3D de verdade, o Blender neste caso, em que todo o trabalho envolve iluminação, composição e senso estético?

12:30 Foi aí que Kimi realmente me surpreendeu. Certo, antes de mostrar os renders do Blender lado a lado, estou planejando transformar este harness de 13 tarefas em um benchmark permanente, que vamos executar a cada novo lançamento de um grande modelo. Então, se quiser acompanhar, não deixe de se inscrever no canal. Certo, vamos ver os resultados do Blender. No grupo três, os dois modelos precisam construir cenas 3D completas a partir de um arquivo vazio, escrevendo scripts em Python para o Blender. Depois, renderizam com Cycles, inspecionam

13:02 as imagens renderizadas, fazem uma crítica à própria iluminação e geometria e melhoram a cena em pelo menos cinco rodadas antes de renderizar um movimento de câmera de 8 segundos. Certo, olhe para estas duas salas de leitura isométricas na tela antes de eu revelar as legendas. Consegue adivinhar qual é qual? A sala à esquerda é do Kimi K3.1 Pro, e a sala à direita é do Claude Opus 5.5. Veja o render de Kimi à esquerda. Ele construiu uma estante completa com quatro prateleiras, repleta de livros multicoloridos,

13:34 luz quente de luminária refletindo na poltrona e um tapete estampado. Também há uma caneca de café e livros empilhados na mesinha lateral, além de uma lua crescente do lado de fora da janela. À primeira vista, a cena transmite imediatamente uma sensação aconchegante e completa. Opus, à direita, seguiu de forma mais literal a parte do prompt sobre a luz da lua, projetando uma sombra azulada da janela sobre as tábuas do piso e acrescentando luzes pontuais na parede. E executou oito rodadas de refinamento

14:05 em comparação com as cinco rodadas mínimas de Kimi. Ainda assim, os móveis de Opus são pequenos demais para a sala, deixando o piso com uma sensação de vazio. Pelo menos aos meus olhos, Kimi produziu a imagem mais forte aqui, por 77% do custo de Opus. Na segunda cena do Blender, uma foto de produto em estúdio de um teclado mecânico, os dois modelos escreveram tabelas de layout em Python que geraram um layout tenkeyless de 87 teclas completamente preciso. Opus seguiu as especificações de materiais do

14:36 prompt de forma mais literal, com uma carcaça de alumínio usinado prateado e uma profundidade de campo reduzida e acentuada. Já Kimi estilizou a carcaça em metal anodizado escuro, com um logotipo gravado que parece saído diretamente de uma página comercial de produto. E fez isso por US$ 1,84, contra US$ 3,42 de Opus. Então, quando o trabalho é composição visual e deixar uma cena com aparência refinada, Kimi é pelo menos tão bom quanto Opus e, às vezes, melhor, o que imediatamente

15:08 levanta a pergunta mais prática para a programação do dia a dia. Se Kimi é tão bom visualmente, você pode migrar todo o seu trabalho de desenvolvimento frontend para Kimi e economizar 50%? Foi isso que testei no grupo quatro, e o teste revelou duas armadilhas que você precisa conhecer. Certo, o grupo quatro testa dois tipos bem diferentes de trabalho de frontend. Primeiro, reconstruir um site real a partir de uma única captura de tela, sem nunca acessar a URL ativa. E, segundo, criar um site com base em uma especificação de engenharia rigorosa com 33 regras.

15:41 No write.com, a qualidade visual ficou empatada. As duas páginas obtiveram 0,93 de similaridade de pixels e 0,98 de correspondência de layout, tornando-as quase impossíveis de distinguir da captura de tela de referência. Kimi chegou até a criar uma página temporária de comparação do frontend durante a execução para identificar o tipo de letra exato. Já nas páginas iniciais mais difíceis da Stripe e da Linear, os resultados visuais também ficaram notavelmente próximos. Na Stripe, Kimi posicionou os blocos de texto

16:12 com mais precisão, enquanto Opus ficou mais próximo na arte dos gradientes e nas cores. Na Linear, as três páginas parecem quase idênticas à primeira vista, com Opus à frente na similaridade exata de pixels e cores. Mas veja o que acontece quando passamos de comparar visualmente uma captura de tela para seguir uma lista de verificação de engenharia rigorosa. Nesse caso, dei aos dois modelos uma especificação com 33 regras verificáveis, abrangendo as cores hexadecimais exatas, os tamanhos de fonte em pixels e os breakpoints responsivos,

16:46 e os avaliei automaticamente em um Chrome sem interface gráfica. Opus passou em todas as 33 regras em 11 minutos. Kimi passou em 31 das 33 em 16 minutos, deixando passar duas regras pequenas. A regra quatro, em que parte do texto corrido usou a cor de destaque em vez da cor definida, e a regra 11, em que um parágrafo foi renderizado com fonte de 12 pixels em vez de 18 pixels. Deixar passar duas pequenas propriedades de CSS é

17:18 fácil de corrigir. O que é perigoso é que o resumo final de conclusão de Kimi afirmou explicitamente que ele havia verificado e passado em todas as 30 das 33 regras. Então, pense nisso como nossa terceira regra para produção. Diante de uma especificação rigorosa, um resumo de conclusão confiante de Kimi não equivale a passar em um teste. Portanto, você precisa sempre avaliar as conclusões com seus próprios scripts determinísticos de avaliação, fora do resumo do agent. E isso se aplica a todos os modelos. Todos os

17:48 modelos de hoje tendem a fazer afirmações que não são realmente verdadeiras. E você reparou naquele número laranja no cartão do site write.com, à direita, há pouco? Embora os tokens de Kimi custem metade do preço dos de Opus, o custo foi de US$ 3,65 naquele site, e o custo de Kimi foi de US$ 3,40, ou seja, 90% da mesma conta. Então, no restante do vídeo, queremos fazer as contas das 13 execuções para ver o que

18:20 realmente aconteceu. Aqui está a lista completa de preços de tabela das 13 tarefas. No total, Kimi foi mais barato em todas as tarefas, somando US$ 45,91, contra US$ 83,46 de Opus, o que corresponde a cerca de 55% do custo total de Opus. Mas, se você observar a variação entre as tarefas individuais, a história é bem diferente. No SDF Dragon, Kimi custou cerca de 28% do valor de Opus.

18:51 Então, por que um modelo com um desconto fixo de 50% no preço dos tokens oscila de uma economia de 72% para quase nenhuma economia? No fundo, a precificação do uso de agents se resume a uma distinção simples: preço de tabela por token versus releituras de context em dinheiro e quantidade de tokens que o modelo gera. No cartão de preços, Kimi cobra US$ 2 por milhão de tokens de entrada e US$ 10 por milhão de tokens de saída, metade dos US$ 4 e US$ 20 de Opus.

19:22 Mas, nas sessões longas de Claude Code na nuvem, o agent envia de volta ao modelo toda a conversa em crescimento e o histórico de ferramentas a cada chamada de ferramenta. Para manter isso acessível, o harness armazena em cache o prefixo. Nas nossas 13 execuções, 98,5% de todos os tokens lidos por Opus e 98,7% de todos os tokens lidos por Kimi vieram diretamente do cache. Então, sem caching, a única tarefa Dragon em Opus teria custado US$ 60,69

19:56 em vez dos US$ 8,09 que vemos. Agora, aqui vem a conclusão. Os tokens de cache custam exatamente os mesmos 20 centavos por milhão nos dois modelos. Isso significa que o desconto de 50% do Kimi se aplica apenas à pequena parcela de tokens recém-gerados. Então, podemos analisar a composição da conta do agente no site. O Opus terminou em 74 mensagens de API e leu 6,5 milhões de tokens de cache, pagando US$ 1,31 pelas leituras de cache

20:26 O Kimi usou 147 mensagens de API e releu 12,4 milhões de tokens de cache, pagando US$ 2,49 apenas pelas leituras de cache, quase o dobro da conta de cache do Opus. A releitura de contexto extra elimina quase toda a economia com tokens de saída. Por outro lado, na tarefa Dragon, o Kimi foi 72% mais barato, em grande parte porque parou depois de concluir apenas 19 renderizações.

20:59 Enquanto isso, o Opus verificou 52 renderizações. Então, a principal conclusão aqui é nunca estimar a conta do seu agente apenas com base no preço anunciado por token. Em loops longos de agente, quantas vezes o modelo faz chamadas e quanto contexto de cache é relido importam tanto quanto a tarifa por token. Certo, antes de apresentar as quatro regras para usar esses modelos juntos, tenha em mente quatro ressalvas importantes sobre este benchmark. A primeira é o tamanho da amostra. Houve uma execução por tarefa, e agentes com estado prolongado sempre apresentam variação entre execuções.

21:32 A segunda é a configuração de esforço. Os dois modelos foram executados com esforço alto no Claude Code, para que a comparação fosse justa. Já a tabela de benchmarks publicada pela Moon Shots classifica o Kimi com esforço máximo. O Kimi talvez reduza a diferença de precisão se você permitir que ele pense no nível máximo. E, como a Moon Shots afirma que os pesos abertos serão disponibilizados até 4 de novembro, você poderá testar isso diretamente sem pagar o preço da API.

22:03 A terceira é que o Kimi otimiza para atingir um limite mínimo sempre que uma tarefa é aberta. Certo, se você conectar o Kimi K3.1 Pro ao seu workflow do Claude Code hoje, recomendo fortemente seguir estas quatro regras de engenharia. Primeiro, defina explicitamente o método e a quantidade mínima de verificações próprias em task.net. Não dê ao Kimi a opção entre uma nota aproximada e uma avaliação exata de física e exija explicitamente que ele inspecione pelo menos 30 a 40 capturas de tela renderizadas em tarefas de ajuste visual, para que não

22:33 pare ao atingir apenas o limite mínimo. Segundo, passe flags explícitas de GPU do hardware para o executor do navegador sem interface gráfica. Não deixe o Kimi voltar à renderização WebGL por software a 10 quadros por segundo, o que aumentou o tempo de compilação 3D de 30 minutos para mais de 2 horas. Terceiro, verifique na comunicação a configuração de esforço da saída e monitore o volume de leituras de cache, porque os tokens de cache custam 20 centavos por milhão nos dois

23:03 modelos. Uma execução lenta que leva o dobro de turnos vai consumir a economia com tokens. E, quarto, nunca confie no que o modelo está dizendo. Use scripts de avaliação externos. Combine o Kimi com um navegador determinístico sem interface gráfica ou uma verificação matemática. Mas, se você testou o Kimi K 3.1 Pro ou outros modelos de pesos abertos no Claude Code em comparação com o Opus, conte nos comentários abaixo o que está observando. Eu adoraria comparar nossas experiências. E, se quiser ver como o novo modelo Gemini 4 Argon do Google lidou com muitas dessas

23:35 mesmas tarefas, recomendo muito assistir a este vídeo. Enfim, espero que você tenha achado este vídeo útil. Obrigado por assistir e, como sempre, até a próxima.

Transcrição original

[00:00] Gemini 1.5 Pro is the latest model from Moonshot. It’s supposed to be the open frontier model built on top of Gemini 1.5. And on their benchmarks, it’s comparable to Opus 5.5. But the question is, does it actually hold up in real-world scenarios? So, I wanted to see how good this model is on long horizon agentic tasks and whether it closes the gap with Opus 5.5 or not. So, I gave both models the same 13 long tasks inside the same cloud code harness

[00:32] with the same prompts and only swapped the model. First, Gemini is supposed to be half the price of Opus, but when I measured what each task actually cost, it turns out to be a whole different story. Second, there is a personality split that benchmarks tables completely miss. On visual compositions and 3D design in Blender, Gemini didn’t just keep up with Opus. In few places, it actually built the better results. But the moment a task allowed an algorithmic shortcut or required strict

[01:03] mathematical precision, Gemini quietly took the path of least resistance. So, by the end of this video, you will know where Gemini 1.5 Pro matches Opus on long tasks, uh where it falls short and why, and what a task really cost on each one once you account for caching. Before we look at the results, let’s start with what I mean by a long horizon task here. A long horizon uh task is one where the model works on its own for 30 minutes to

[01:35] a couple of hours or more, uh writing code, running it, checking the results, fixing what is wrong without me stepping in. So, for every task, I’m going to be looking at four different things, which are how close each model gets to the actual requirements, how long it takes, how many tokens and tool call it uses, and when it fails, why it fails. The tasks fall groups. The first one is implementing research, uh things like a self-healing creature

[02:05] from a research paper, and a robot that learns to walk. The second is building 3D scenes in code without any 3D software. The third one is using an external tool, which in this case is going to be Blender. Uh now, the last one is front-end work, uh rebuilding websites from a single screenshot and following a strict design brief. So, here’s the setup that I tried. Both models ran inside the same Claude code, uh because Kimmy has an endpoint that speaks the same protocol as Anthropic’s API.

[02:36] And according to Moonshot, most of their own benchmarks number were also run inside Claude code. So, it’s the same version of Claude code for both models, same prompt, uh same instructions. The only difference is the model string. Both models got the exact same task files and the same scripts code both of the results afterward. Moonshot gave me a free uh Kimmy membership to test this model. They didn’t see this video before it went out, and they did not pay

[03:06] for it. Okay, for the rest of the video, I’m going to show you the results side by side with the numbers for each task on screen. You be the judge of how good Kimmy K 3.1 Pro is compared to Opus 5.5. So, the first group is about implementing research, and it all runs on my DGX Spark with terminal access to the machine. The first task is replicating a classic research paper called Growing Neural Cellular Automata, where a tiny 8,000 parameter neural

[03:37] network learns to grow a lizard from a single cell, heal itself after you slice half of it away, and then run live inside a browser WebGL shader. Here are both creatures side by side, and on the first run, Kimmy genuinely impressed me. Both models replicated the entire paper end to end, from training on the Spark GPU to shipping an interactive browser demo, where you can erase half the lizard with your mouse and watch it regenerate in real time. Even better, both models wrote a

[04:09] verification test to check that the browser WebGL shader produced the same numerical output as the PyTorch model, which is the verification step most people are going to skip. So, I would say this one is dead tie and Kimi actually designed a nicer browser demo for $6.10 against Opus $7.66. The second research task is reinforcement learning and the agent has to write the PPO algorithm from scratch with no RL libraries allowed

[04:41] and train a simulated robot in MuJoCo to walk past a target score of 3,000. In my first round, the prompt allowed the model to choose a robot from a list. Opus picked the four-legged ant, which can flip over in three dimension, trained it for nearly an hour across uh 75 million steps and it hit a score of uh 7,254, which is more than double of the target. Now, Kimi looked at the exact same list,

[05:11] picked half cheetah, which is a flat two-legged robot that physically cannot fall over sideways, trained it for just under 6 minutes, cleared the uh 3,000 bar at 3,566. Now, Kimi did not fail the task. Uh its choice was completely legal under the prompt. It just optimized for the easiest legal way to pass. To force a direct head-to-head comparison, I ran a second round where the four-legged ant v5 was mandatory for

[05:42] both models. Here are both ants on the exact same task. Both models taught uh the four-legged ant to walk and clear the 3,000 target, but I looked under the hood uh at how they engineered the training run. So, first Opus built a much faster training loop running 108 simulation environments in parallel at nearly 22,000 steps per second compared to uh Kimi’s 8,000 steps per second. Second,

[06:13] Kimi stopped training after 27 minutes, even though it had a 90-minute training budget. Opus used 46 minutes to train four times as many steps, resulting in 10 out of 10 test episodes standing up right at a score of 7,435, while one of the Kimi’s 10 test uh runs fell over. And we see that exact same behavioral pattern on the third research task, which is simulating the Milky Way and

[06:44] Andromeda galaxies colliding on the GPU um with at least half a million stars while conserving energy. The task prompt allowed two gravity algorithms, an exact direct summation method uh where every particle pulls on every other particle, or a cheaper um approximate method using a particle mesh grid. Opus chose the hard exact uh method was about 780,000 particles

[07:14] um keeping drift energy 2.084%, which is more than a 100 times tighter than 1% target with uh tighter tidal tails. Kimi chose the cheaper approximation method with 600,000 particles. While that technically satisfies the prompt, a grid with uh periodic boundaries does not conserve angular momentum. Kimi’s own log reported that the total angular momentum changed by about 32% during the collisions, uh which should

[07:46] never happen in real physics. And yet, Kimi still gave its own run a nine out of 10 self score. Now, here’s uh the first takeaway of using Kimi. If your prompt leaves room for an easier algorithm or an early stopping point, Kimi uh K3.1 Pro tends to take it, which immediately raises our next question. What happens in the second set of tests where we ban external 3D assets and force both models

[08:16] to write pure 3D math where the only way to succeed is checking its own renderer. So, in group two, the model have to build complex 3D world purely in code with no 3D modeling software at all. The The model gets a single 2D concept image of a dragon and has to sculpt the entire 3D geometry as a single mathematical formula called a signed distance function in GLSL. Now, we score it by measuring how

[08:48] closely the 3D solid overlaps the reference image from the front and the side while checking seven held out camera angles to make sure that it is a real 3D shape. Now, look at the two dragons on the screen. Both models built coherent 3D creature that holds together on every camera angle. The reference dragon is a short and chubby. Opus nailed those proportions scoring 0.85 from the front and 0.82 from the side. Kimmy built a

[09:20] tall, skinny dragon with a long neck scoring 0.65 and 0.62, which is barely above the 0.6 score you get from the plain round blob. Why did Kimmy miss the proportions so badly? When I audited the cloud code tool logs, the exact same reason jumps out. During its 34-minute run, Opus rendered and visually inspected 52 screenshots of its own dragon,

[09:51] then iteratively nudged the math until the solidity actually matched. Kimmy only looked at 19 renders and then decided that the dragon looked good enough and stopped. Now, look at what happens when we move from matching a strict 2D solid to building full interactive WebGL worlds. In this case, it’s the procedural living planet, a first-person portal physics chamber, and and a ticking mechanical watch movement.

[10:22] On the living planet, both models implemented every single requested shadow feature from things like ocean sunlight and atmospheric scattering to drifting cloud shadows and night side city lights. Opus built the more photo-realistic planet with dramatic low pass over the mountain terrain, while Kimi went for a stylized globe inside a designed presentation page with captions. On the portal physics lab, both models built working recursive see-through

[10:54] portals in an automatic walk-through demo landing in a closed draw. And on the mechanical watch movement, we get the closest 3D results in the entire video. Both watches tick with accurate gear ratios and display the real local time. And Kimi’s gold exploded view and typography actually looks more like a luxury watch showcase than Opus. But look at the runtimes on the planet and the watch. Opus finished them in 31

[11:25] minutes and 38 minutes. Kimi took 125 minutes on both, which is more than three to four times slower. Again, we had to dig through Kimi’s terminal logs to see why it was taking two hours per scene. I found our second major production takeaway. So, inside our headless browser environment, Kimi ran a check, concluded the machine only had a software WebGL renderer, and spent two hours testing its 3D

[11:57] animations with a sluggish 9 to 13 frames per second. Opus ran on the exact same machine, passed the flags to unlock the hardware GPU path in the headless browser. Up to this point, whenever a task depended on raw shader math or headless browser flags, Opus had the edge. So, what happens in group three when we give both models uh real 3D engine, Blender in this case, where the whole job is lighting, composition, and visual taste?

[12:30] This is where Kimi genuinely surprised me. Okay, before I show you the Blender renders side by side, I’m planning to convert this 13 task harness into a permanent benchmark, which we’re going to run on every new major model release. So, if you want to see that, make sure you subscribe to the channel. All right, let’s look at the Blender results. In group three, both models have to build complete 3D scenes from an empty file by writing Blender Python scripts. Then rendering with Cycles, inspecting

[13:02] the rendered images, critiquing uh their own lighting and geometry, and improving the scene across at least five rounds before rendering an 8-second camera move. Okay, so look at these two isometric uh reading rooms on screen before I put the labels up. Can you guess which one is which? So, the room on the left is Kimi K3.1 Pro, and the room on the right is Cloud Opus 5.5. Look at Kimi’s render on the left. It built a full four-shelf uh bookcase packed with multicolor books,

[13:34] warm lamp light bouncing across the armchair and a patterned rug. Then there’s a coffee mug and uh stacked books on the side table, and uh crescent moon outside the window. It immediately reads a cozy and complete uh at a single glance. Opus on the right followed the moonlight part of the prompt more literally, casting a cool blue window shadow across the floorboards, and adding strict lights on the wall. And it ran eight refinement

[14:05] rounds compared to uh Kimi’s minimum five rounds. Yet, Opus’ furniture is scaled to small for the room, leaving the floor feeling sparse. At least to my eyes, Kimi produced the stronger image here at the 77% of Opus cost. On the second uh Blender scene, a studio product shot of a mechanical keyboard, both models wrote Python layout tables that generated a comp- completely accurate 87-key tenkeyless layout. Opus followed the

[14:36] prompt materials specs more literally with a silver uh machine aluminum case and a strong shallow depth of field. While Kimi styled a dark anodized case with an engraved logo that looks right out of a commercial product page. Now, it did it for $1.84 against Opus’ $3.42. So, when the job is visual composition and making a scene look polished, Kimi is at least as good as Opus and sometimes better, which immediately

[15:08] raises the most practical question uh for daily coding. If Kimi is this strong visually, can you switch all of your front-end work uh development work to Kimi and save 50%? So, I tested that in group four and it exposed two traps you need to know about. Okay, group four tests uh two very different kinds of front-end work. First, rebuilding the real website from a single uh screenshot without ever touching the live URL. And second, building a site from a strict 30-

[15:41] three-rule engineering specification. So, on write.com, the visual quality is dead heat. Both pages scored .93 on pixel similarity and .98 on layout match, making them nearly impossible to tell apart from the reference screenshot. Kimi even built itself a temporary front comparison page during the run to identify the exact typeface. Now, on the harder Stripe and Linear home pages, the visual outputs are again remarkably close. On Stripe, Kimi actually placed the text

[16:12] blocks more accurately, while Opus got the gradient artwork and colors closer. On linear, all three pages look nearly identical at a glance with Opus ahead on exact pixel and color similarity. But watch what happens when we move from matching a screenshot by eye to following a strict engineering checklist. So in this case, I give both models a specification with 33 checkable rules covering the exact hex colors, pixel font sizes, and responsive breakpoints

[16:46] and graded them automatically in a headless Chrome. Now, Opus passed all 33 out of the 33 rules in 11 minutes. Kimmy passed 31 out of 33 in 16 minutes missing two small rules. And these are rule four where some body text used the ascent color instead of the one that was defined and rule 11 where one paragraph rendered at 12 pixels in instead of 18 pixels. Now, missing two small CSS properties is

[17:18] easy fix. What is dangerous is that Kimmy’s final completion summary it explicitly claimed it had verified and passed all 30 out of 33 rules. So, think of this as our third production rule. On a strict specification, a confident completion summary from Kimmy is not the same as a passing test. So, you need to always get completions with your own deterministic grading scripts outside the agent’s summary. And this applies to all the models. All of

[17:48] the models today tend to make claims that are not actually true. And did you notice one orange number on the right dot com website card a moment ago? Even though Kimmy’s tokens are half the price of Opus cost was a 3.65 on that website and Kimmy cost was 3.4 which is 90% of the exact same bill. So, in the rest of the video, we actually want to do some accounting across all the 13 runs to see what

[18:20] actually happened. Here is the complete list price ledger across all 13 tasks. Overall, Kimi was cheaper on every single task totaling $45.91 against Opus um $83.46, which comes out to be about 55% of the cost of Opus overall. But now, if you look at the spread across individual tasks, it’s a very different story. On the SDF Dragon, Kimi cost about 28% of Opus.

[18:51] So, why does the model with a flat 50% token discount swing from a 72% savings down to almost zero savings? At its core, agentic pricing comes down to one simple distinction. Per token list price versus cash uh context re-reads and the number of tokens that the model is generating. So, on the pricing card, Kimi charges $2 per million input tokens and $10 per million output tokens, which is half of Opus’ $4 and $20.

[19:22] But in the long horizon cloud code sessions, the agent sends in its entire growing conversation and tool history back to the model on every single tool call. To keep that affordable, uh the harness caches the prefix. Across our uh 13 runs, 98.5% of every token Opus read and 98.7% of every token Kimi read came straight from the cash. So, without caching, the single Dragon task on Opus would have cost $60.69

[19:56] instead of $8.09 that we see. Now, here’s the punchline. Cash token costs the exact same 20 cents per million on both models. That means Kimi’s 50% discount only applies uh to the tiny slice of newly generated tokens. So, we can actually look at the uh bill autonomy for the website. So, Opus finishes in 74 API messages and reads 6.5 million cash tokens. Paying uh a dollar 31 cents for cash

[20:26] reads. The Kimi took 147 API messages and reread 12.4 million cash tokens paying $2.49 for cash reads alone, which is almost double Opus’s cash bill. The extra context rereading wipes out almost the entire output token saving. Conversely, on the dragon task, Kimi was 72% cheaper largely because Kimi stopped after completing only 19 renders.

[20:59] While Opus checked 52 renders. So, the main takeaway here is never estimate your agent bill from the per token sticker price alone. In the long agent loops, how many times the model takes and how much cash context is reread matters just as much as the token rate. Okay, so before I give you the four rules for using these models together, keep four important caveats of this benchmark in mind. The first one is sample size. This is one run per task and long state

[21:32] agent always carry run to run variance. Second is the effort setting. Both models ran at high effort inside Claude code so the comparison was fair. Whereas Moon Shots published benchmarks table rank Kimi at maximum effort. Kimi may close part of the precision gap if you let it think at max. And since Moon Shots says they the open weights are coming by November 4, you will be able to test that directly without paying the API pricing.

[22:03] And the third one is that Kimi optimizes for a minimum threshold whenever a task is open-ended. Okay, if you plug Kimi K3.1 Pro into your Claude code workflow today, I would highly recommend to follow these four engineering rules. First, hardcode the method and minimum self-check count in task.net. Do not give Kimi a choice between an approximate grade and exact physics and explicitly required it to inspect at least 30 to 40 rendered screenshots and on visual fitting task, so it does not

[22:33] stop at a minimum bar. Second, um, pass explicit hardware GPU flags, uh, to your headless browser runner. Do not let Kimi fall back to a 10 frame per second software WebGL rendering, which inflated its 3D build times from from 30 minutes to over 2 hours. And third, verify output config effort on the wire and track cache read volume, because cache tokens cost 20 cents per million on both

[23:03] models. A slow run that takes twice as many turns will eat your token discount. And fourth, never trust, uh, what the model is saying. Use external grading scripts. Pair Kimi with a deterministic headless browser or math check. But, if you have tested Kimi K 3.1 Pro or other open weight models inside Cloud Code against Opus, what you are seeing in the comment section below. Because I would love to compare notes here. And if you want to see how Google’s new Gemini 4 Argon model handled many of

[23:35] these exact same tasks, uh, I’ll highly recommend to watch this video. Anyways, I hope you found this video useful. Thanks for watching and as always, see you in the next one.