Kimi K3 no OpenClaw versus dsh: 5/5 tarefas, 9× mais lento, 48× o custo

Apontei o meu agente de trabalho OpenClaw para o Kimi K3, o principal modelo de raciocínio da Moonshot, e executei-o nas mesmas cinco pequenas tarefas de programação que usei em agosto para avaliar o DeepSeek Harness (dsh). O Kimi passou em todas as cinco. Voltei a executar o dsh com o DeepSeek V4-Flash no mesmo dia, duas vezes. Em comparação com a sua segunda execução (com cache aquecido), o Kimi levou cerca de 9 vezes mais tempo (309,9 s contra 35,7 s) e custou cerca de 48 vezes mais ($0,531 contra $0,011). Em comparação com a primeira execução do dsh (sem cache, 44,8 s, $0,024), a diferença é de cerca de 7× no tempo e 22× no custo.

Depois entreguei ao Kimi o brief do logotipo em pixel art a partir do qual o dsh tinha criado o seu widget. Foram necessárias três tentativas. A primeira não produziu nenhum widget. A segunda escreveu um widget completo na pasta errada e foi interrompida pelo meu timeout antes de o dizer, por isso inicialmente não o vi. A terceira funcionou depois de eu encurtar o brief e lhe dizer para saltar o planeamento. O widget abaixo é essa terceira tentativa, e a armadilha de configuração no Passo 2 é a parte que mais vale a pena copiar.

Configuração: em que ambiente executei

Estes são os comandos que executei na minha máquina em 11/09/2026, juntamente com a sua saída real:

$ node -v
v24.18.0
$ openclaw --version
OpenClaw 2026.9.2 (3928bad)
$ dsh --version
0.1.1-rc.2
$ openclaw plugins list --json | jq -c '.plugins[] | select(.id=="moonshot") | {id, enabled, version}'
{"id":"moonshot","enabled":true,"version":"2026.9.2"}
$ openclaw config get models.providers.moonshot.models.0.compat
{
  "supportsReasoningEffort": true,
  "supportsTemperature": false,
  "supportedReasoningEfforts": [
    "low",
    "high",
    "max"
  ]
}
$ openclaw config get models.providers.moonshot.models.0.contextTokens
262144

Duas coisas importantes para saber antes de executar qualquer coisa:

• O K3 sempre gera raciocínio. O plugin envia reasoning_effort: "max" por padrão e aceita os valores low, high e max; executei o benchmark com --thinking max. Ele também ignora as configurações de amostragem (temperature, top_p e afins) pois o K3 as define automaticamente; minha entrada de modelo indica o mesmo, com supportsTemperature: false. Até mesmo a instrução “Responda exatamente: PONG.” consumiu 53 tokens de raciocínio; portanto, tenha isso em conta no seu orçamento de tokens.
• O contexto de 1 milhão de tokens é divulgado, mas eu o limito. O catálogo Moonshot da OpenClaw lista o K3 com capacidade para 1.048.576 tokens de contexto. No entanto, configurei contextTokens: 262144 na minha entrada de modelo, de modo que as sessões sejam compactadas no mesmo ponto que os outros modelos que uso. Com esse limite, na prática você terá 256 mil tokens, e não 1 milhão. Caso aumente esse valor, o custo de leitura do cache e a latência por turno também aumentarão conforme o tamanho da sessão.

O caminho, do básico ao avançado

Os passos 1 a 3 permitem que você tenha um modelo funcionando. Os passos 4 e 5 são o que fiz em seguida.

Passo 1: instale o plugin e forneça a chave de acesso

Estes são os passos descritos na própria documentação do OpenClaw. Na minha máquina, o plugin e a chave já estavam configurados; por isso, executei apenas a verificação na última linha (cujo resultado está no bloco de configuração acima).

openclaw plugins install @openclaw/moonshot-provider
openclaw gateway restart
openclaw plugins list --json | jq -c '.plugins[] | select(.id=="moonshot") | {id, enabled, version}'

O plugin lê a chave de acesso a partir de MOONSHOT_API_KEY. Eu mantenho essa variável no arquivo de ambiente que meu serviço de gateway carrega; meu arquivo openclaw.json não contém nenhuma chave. A documentação também sugere o comando openclaw onboard --auth-choice moonshot-api-key caso você prefira ser guiado durante a configuração. O endpoint padrão é https://api.moonshot.ai/v1; para a região da China, utiliza-se https://api.moonshot.cn/v1 (com a opção de autenticação moonshot-api-key-cn).

O catálogo do plugin inclui os modelos K3, K2.7 Code e K2.7 Code HighSpeed. Ele cuida automaticamente das particularidades do modelo Kimi: para o K2.7, é necessário omitir tanto o parâmetro thinking quanto o reasoning_effort da solicitação – algo que o plugin faz por você. Fique atento ao nome da variável de ambiente: MOONSHOT_API_KEY refere-se à Plataforma Aberta do Moonshot; já KIMI_API_KEY pertence ao serviço de assinatura Kimi Code (kimi/kimi-for-coding).

Passo 2: aponte o seu agente de trabalho para o K3

As partes relevantes do meu arquivo openclaw.json durante o benchmark, com o meu agente de trabalho renomeado para worker:

{
  agents: {
    entries: {
      worker: {
        model: {
          primary: "moonshot/kimi-k3",
          fallbacks: ["deepseek/deepseek-v4-flash", "deepseek/deepseek-v4-pro"],
        },
      },
    },
  },
  models: {
    providers: {
      moonshot: {
        baseUrl: "https://api.moonshot.ai/v1",
        api: "openai-completions",
        timeoutSeconds: 1200,
        models: [
          {
            id: "kimi-k3",
            name: "Kimi K3",
            reasoning: true,
            input: ["text", "image"],
            cost: { input: 3, output: 15, cacheRead: 0.3, cacheWrite: 0 },
            contextWindow: 1048576,
            maxTokens: 131072,
            contextTokens: 262144,
            compat: {
              supportsTemperature: false,
              supportsReasoningEffort: true,
              supportedReasoningEfforts: ["low", "high", "max"],
            },
          },
        ],
      },
    },
  },
}

Um erro me causou um problema silencioso: na versão OpenClaw 2026.9.2, um bloco compat na entrada do modelo substitui o próprio objeto compat do plugin. Ele não é mesclado com o objeto original. Uma versão anterior da minha configuração continha apenas supportsTemperature: false, e isso fez com que o suporte à IA do plugin fosse desativado sem aviso. Se você for escrever um bloco compat, escreva todo o objeto, como mostrado acima.

Passo 3: o teste de verificação e o JSON que ele gera

Cada tarefa de benchmark consistia em uma chamada como essa, utilizando uma chave de sessão nova a cada vez:

openclaw agent --agent <your-agent-id> --model moonshot/kimi-k3 --thinking max \
  --session-key "<fresh-key>" --message-file prompt.txt --json > out.json

Estes são os campos importantes, extraídos do envelope salvo da tarefa PONG:

$ jq '.result | {harness: .meta.agentMeta.agentHarnessId, model: .meta.executionTrace.winnerModel, usage: .meta.agentMeta.usage}' out.json
{
  "harness": "openclaw",
  "model": "kimi-k3",
  "usage": {
    "input": 15068,
    "output": 70,
    "reasoningTokens": 53,
    "total": 15138,
    "cost": {
      "total": 0.046254
    }
  }
}

harness: "openclaw" significa que a rodada foi executada no próprio loop do OpenClaw; uma rodada executada pelo servidor de aplicações Codex exibiria "codex". winnerModel: "kimi-k3" indica que a rodada realmente foi executada no K3, sem recorrer a um modelo mais barato. reasoningTokens é contado dentro de output (o total é a soma de input e output); portanto, os 53 tokens de raciocínio fazem parte dos 70 totais.

O benchmark: as mesmas 5 tarefas

São as mesmas cinco tarefas executadas no artigo sobre o dsh; cada uma foi rodada numa pasta temporária nova, com uma sessão distinta para cada tarefa do Kimi. Re-executei o dsh no V4-Flash no mesmo dia, vinculando-o ao modelo deepseek-v4-flash num arquivo de configurações temporárias. A primeira execução levou 44,8 segundos e custou $0,024, com o cache ainda frio; a coluna abaixo mostra a segunda execução, com cache já aquecido, que é o resultado mais rápido e barato obtido pelo dsh – este é o valor utilizado em todas as comparações deste artigo, salvo indicação contrária. A redação dos prompts não foi idêntica: o dsh roda a partir da pasta onde é iniciado, então seus prompts mencionavam “o diretório atual”; os prompts do Kimi informavam o caminho absoluto de cada pasta de tarefa. Além disso, o prompt de correção de bugs do Kimi incluía a instrução “se o pytest não estiver disponível, instale-o primeiro com ‘pip install --user pytest’” (o pytest já estava instalado, e o Kimi nem chegou a executar o comando de instalação). As colunas referentes ao V4-Pro e ao Gemma-4-26B vêm do artigo sobre dsh publicado em agosto; essas execuções não foram repetidas. O tempo total inclui todo o processo. Os tokens e custos do Kimi foram extraídos do envelope JSON gerado pelo OpenClaw, enquanto os dados do dsh vieram de seu próprio log de sessão.

Tarefa	Kimi K3	dsh V4-Flash (mesmo dia)	dsh V4-Pro (agosto, histórico)	Gemma-4-26B (agosto, histórico)
Responder “PONG” (inicialização + uma chamada)	✅ 6,1 s · 0 ferramentas	✅ 1,7 s · 0 ferramentas	✅ 2,8 s	✅ 13,2 s*
Escrever e executar o FizzBuzz	✅ 22,8 s · 2 ferramentas (write, exec)	✅ 5,3 s · 3 ferramentas	✅ 8,4 s · 2 ferramentas	✅ 4,9 s · 2 ferramentas
Corrigir 2 bugs para que os testes unitários passem (testes inalterados)	✅ 86,6 s · 6 ferramentas (exec, write, edit)	✅ 11,3 s · 7 ferramentas	✅ 15,8 s · 7 ferramentas	✅ 10,4 s · 8 ferramentas
Resumir um código com 6 módulos (menos de 150 palavras)	✅ 65,5 s · 10 ferramentas (read, exec, write)	✅ 5,1 s · 7 ferramentas	✅ 10,9 s · 7 ferramentas	✅ 12,1 s · 7 ferramentas
Renomear uma função em 3 arquivos + testes; garantir que todos os testes passem	✅ 128,9 s · 9 ferramentas (exec, write; um comando sed aplicado a vários arquivos)	✅ 12,3 s · 11 ferramentas	✅ 18,2 s · 12 ferramentas	✅ 12,2 s · 11 ferramentas
Tempo total	309,9 s	35,7 s	56,1 s	52,8 s
Tokens: entrada não em cache / leitura do cache / saída (raciocínio)	91.470 / 355.328 / 9.990 (4.053)	6.141 / 147.328 / 4.697 (1.984)	41,4k / 107k / 3,2k	40,5k / 237k / 5,6k
Custo	≈ $0,531 ($3 / $15 / $0,30 por milhão)	≈ $0,011 ($0,44 / $1,32 / $0,014 por milhão)	≈ $0,072	$0 (apenas custo de energia elétrica)

O número de ferramentas refere-se às chamadas realizadas. Os dados do Kimi foram extraídos de toolSummary.calls no envelope JSON do OpenClaw; os tipos de ferramentas aparecem entre parênteses. Os dados do dsh vêm de seu log de sessão. *Primeira execução após o modelo ser carregado na máquina, com cache ainda frio. As taxas do Kimi são as informadas no catálogo do OpenClaw, usadas para calcular o custo de cada tarefa; consulte a página de preços da Moonshot para valores atualizados. O custo do dsh V4-Flash utiliza as mesmas taxas máximas citadas no artigo sobre dsh (preços da DeepSeek); as linhas referentes ao V4-Pro e ao Gemma-4-26B reproduzem os dados desse artigo.

O que a tabela revela:

• 5/5 em todas as colunas. Nenhuma das tarefas apresentou dificuldades para o Kimi. A resposta “PONG” veio exatamente como solicitado; o FizzBuzz imprimiu as 15 linhas corretas. Para a correção de bugs, foram feitas duas alterações simples (um comando return faltante e um == 1 que deveria ser == 0), mantendo os testes inalterados; todos os três testes foram aprovados. O resumo consistiu num único parágrafo de 107 palavras, descrevendo corretamente seis módulos idênticos responsáveis por buscar, transformar e validar dados. Na renomeação da função, foi utilizado um único comando sed aplicado a quatro arquivos, incluindo o método de teste; todos os testes também foram aprovados. Meu prompt solicitava uma busca vazia com grep em toda a pasta; como a própria instrução estava ali armazenada, o Kimi aplicou o mesmo comando sed nesse arquivo e mencionou isso na resposta. São tarefas simples; não testei um refactoring envolvendo múltiplos arquivos.
• O Kimi gasta mais em raciocínio. O K3 utilizou 53, 241, 315, 1.586 e 1.858 tokens de raciocínio nas cinco tarefas (totalizando 4.053). O dsh no V4-Flash também raciocina, porém em menor escala: 0, 52, 834, 5 e 1.093 tokens (total de 1.984). A maior parte do tempo extra gasto pelo Kimi se deve ao seu processo de reflexão e aos passos adicionais necessários.
• O cache reduz consideravelmente o custo. Cada tarefa do Kimi começa com cerca de 15 mil tokens referentes ao prompt do sistema e às definições das ferramentas. Nas cinco tarefas, o Kimi enviou 91.470 tokens de entrada sem cache e leu 355.328 tokens do cache (só na tarefa de renomeação foram 157.952 tokens). Ou seja, 80% dos tokens foram obtidos do cache, ao preço de $0,30 por milhão, em vez dos $3 cobrados por tokens não em cache. Se fossem contabilizados como entrada sem cache, o custo total seria cerca de $1,49, contra os $0,53 efetivamente pagos; o uso do cache reduziu-o para um terço desse valor. Mesmo assim, a taxa de $0,30 continua elevada: é aproximadamente 21 vezes maior que o preço de leitura do cache pelo dsh V4-Flash, que é de $0,014 por milhão.
• Para tarefas simples, o V4-Flash é a melhor opção. Comparado à execução com cache já aquecido, o dsh foi cerca de 9 vezes mais rápido e 48 vezes mais barato para produzir o mesmo resultado. Já na comparação com o cache frio, os ganhos foram de aproximadamente 7 vezes em velocidade e 22 vezes em custo. Em ambos os casos a conclusão é idêntica: a renomeação da função consumiu 128,9 segundos e $0,180 no Kimi, enquanto no dsh foram apenas 12,3 segundos e $0,0043.

Kimi K3 no OpenClaw vs dsh: um panorama rápido

Ambos são loops de agentes que leem arquivos, executam comandos shell e cobram por token. A diferença está em quem desenvolve cada um e em como eles são controlados.

	Kimi K3 no OpenClaw	dsh
Quem o desenvolve	Modelo: Moonshot AI. Loop de agente: OpenClaw	DeepSeek (modelo e harness), MIT
Como chamá-lo a partir de um script	openclaw agent --agent <id> --model moonshot/kimi-k3 -m "…" --json	dsh --profile headless "…"
Como trocar de modelos	O parâmetro model.primary no arquivo openclaw.json	~/.dsh/settings.yaml
Teste headless com 5 tarefas pequenas	309,9 s, ≈ $0,531, 5/5	35,7 s, ≈ $0,011, 5/5 (V4-Flash; na primeira execução o tempo foi de 44,8 s, custando ≈ $0,024)
Criação de widget em pixel art, mesmo comando	3 tentativas; duas delas resultaram em um widget; a que está aqui levou 7,4 minutos e custou ≈ $0,47	2 tentativas; a que deu certo levou 25 minutos e custou ≈ 49 centavos
Versão testada	OpenClaw 2026.9.2, plugin da Moonshot 2026.9.2	0.1.1-rc.2 (versão de prévia para desenvolvedores)

Comparações anteriores neste site incluíam uma coluna referente ao Reasonix. Desativei o Reasonix na minha máquina em 2026-09-09, por isso ele não aparece aqui; o artigo de julho sobre ele permanece como registro histórico. Também testei o MiniMax M3 com o mesmo conjunto de tarefas; a MiniMax é uma empresa distinta da Moonshot, e esse teste tem seu próprio artigo.

O teste divertido: o mesmo briefing para os widgets, Kimi vs dsh

O “teste divertido” do artigo do dsh consistia na criação de um widget em pixel-art com o logotipo deste site; esse widget foi feito pelo dsh usando o V4-Flash a partir de um briefing escrito. Entreguei a Kimi o mesmo briefing, sem alterações, e cronometrei o processo. Em resumo, era solicitado o seguinte:

• Um único arquivo em JavaScript puro, ll-pixel-logo.js, sem dependências ou chamadas de rede; esse arquivo deveria criar um canvas HiDPI em cada elemento .ll-pixel-logo e expor a função window.LLPixelLogo.mount(el). Além disso, era preciso um arquivo de demonstração index.html e um README.md.
• Arte procedural, não um bitmap desenhado à mão: uma grade 40×40 cujos pontos são ativados pela função isLit(col, row); o padrão inclui um anel (de 0,82R até R) e dois “Ls” inclinados, cada um formado por dois paralelogramos distorcidos.
• Interações: repulsão do cursor com efeito de “volta ao estado original”, um efeito visual ao clicar, uma animação sutil em estado ocioso, suporte para modo de movimento reduzido, além de um auto-teste (node --check) que conta quantos pontos estão ativados, sem precisar de DOM.

O teste dos widgets em pixel-art reproduz o briefing na íntegra.

Como Kimi lidou com isso:

• Tentativa 1 (o briefing original, sem alterações): interrompida após 8,8 minutos; nenhum código foi produzido, custo aproximado de $0,31. O K3 analisou o logotipo de referência, refletiu sobre geometria e ferramentas necessárias, mas não escreveu nada. A primeira tentativa do dsh também fracassou da mesma forma (um loop de 10 minutos desenhando mentalmente um bitmap), embora na época o briefing permitisse bitmaps desenhados à mão.
• Tentativa 2 (novamente o mesmo briefing, sessão nova): um widget completo foi gerado, porém no local errado; custo de cerca de $0,72. Após cerca de oito minutos, Kimi produziu um arquivo ll-pixel-logo.js com 323 linhas, além de uma página de demonstração, um README e dois arquivos de teste; todos os testes foram executados e corrigidos até darem certo. Contudo, tudo foi salvo no espaço de trabalho do agente, e não na pasta monitorada pelo meu script; a sessão atingiu o limite de 15 minutos definido por mim antes de retornar resposta. Do meu ponto de vista, nada havia sido produzido, então iniciei a tentativa 3 sete minutos depois.
• Tentativa 3 (briefing encurtado e instruções específicas): concluída em 7,4 minutos; os três arquivos foram escritos, custo de $0,47. Mantive os requisitos de arte e interações, coloquei no topo do briefing a instrução TARGETED — write the widget file in one tool call, no exploration, no planning, no verification loop., e substituí a seção de testes por: Do NOT do a "node --check" or playwright test — just write the files and print a short report listing what you wrote. O widget resultante possui repulsão do cursor, efeito de quebra e reagrupamento ao clicar, animação sutil em estado ocioso e modo de movimento reduzido. Minhas verificações estão descritas mais abaixo.

Portanto, as três tentativas levaram 8,8, 15 e 7,4 minutos, custando respectivamente $0,31, $0,72 e $0,47 — um total de cerca de $1,50 para dois widgets. O valor da tentativa 3 vem do recibo JSON gerado; as tentativas 1 e 2 não produziram recibos, então seus custos são a soma dos valores por mensagem cobrados pela OpenClaw em cada sessão; esse total coincide com o valor do recibo da tentativa 3.

Por volta de uma hora depois, o widget da tentativa 2 reapareceu: o MiniMax M3, rodando no mesmo worker, encontrou os arquivos, executou seus testes e os reportou como sendo seu próprio trabalho. Essa história está descrita no relato sobre o MiniMax M3; ambos os widgets da Kimi ficam ao lado do widget do dsh no teste dos widgets em pixel-art.

Abaixo, as primeiras ~30 linhas do arquivo ll-pixel-logo.js gerado pela Kimi:

/*!
 * ll-pixel-logo.js — interactive pixel-art LaserLloyd logo widget.
 *
 * Self-contained vanilla JS: no dependencies, no build step, no network.
 * Embed on any page with:
 *
 *   <div class="ll-pixel-logo" data-size="320"></div>
 *   <script src="ll-pixel-logo.js"></script>
 *
 * Every .ll-pixel-logo element gets a <canvas> mounted inside it at load.
 * Programmatic API: window.LLPixelLogo.mount(el) -> instance.
 *
 * Art: 40x40 pixel grid, rasterised procedurally from geometry (ring + two
 * interlocking italic Ls). Interactions: pointer repulsion with spring-back,
 * click/tap shatter-and-reassemble, idle shimmer/twinkle, reduced-motion
 * support. Mouse and touch. No scroll hijacking (all listeners passive).
 */
(function () {
  'use strict';

  // -- constants ------------------------------------------------------------
  var VERSION = '1.0.0';
  var GRID = 40;                                // logical grid: GRID x GRID cells
  var BLUE   = [31, 63, 143];                   // #1f3f8f logo blue
  var HILITE = [46, 168, 255];                  // #2ea8ff highlight blue
  var AMBER  = [255, 182, 74];                  // #ffb64a twinkle amber
  var CYAN   = [0, 230, 207];                   // #00e6cf max-displacement glow

  var CENTER = GRID / 2;                        // grid centre coordinate (20)
  var R_OUT = 19;                               // ring outer radius (cells)
  var R_IN = 0.82 * R_OUT;                      // ring inner radius
  var SLANT = Math.tan(20 * Math.PI / 180);     // ~20 deg italic shear

Kimi cria cada “L” a partir de dois paralelogramos (um “caule” e uma “base”) usando uma pequena função auxiliar makeL; verifica se um ponto está ativado por meio da função inPara, dentro de isLit. Todas as constantes de ajuste — raios do anel (0,82R até R), ângulo de inclinação de 20° calculado via Math.tan, parâmetros de “mola” e amortecimento — ficam reunidas num único bloco no topo do arquivo. Os arquivos produzidos (o ll-pixel-logo.js com 397 linhas, o index.html com 40 linhas e o README.md com 79 linhas) podem ser acessados em /assets/uploads/2026/09/kimi-codex/.

O widget do dsh (código-fonte, citado no artigo sobre o dsh) foi criado da mesma forma: ambos geram um anel e dois “Ls” entrelaçados a partir de cálculos geométricos; ambos expõem window.LLPixelLogo.mount e respeitam a preferência prefers-reduced-motion. As constantes, porém, diferem: o dsh usa raio externo de 19,7, raio interno de 0,80R e ângulo de inclinação de 0,453 (cerca de 24°); Kimi utiliza 19, 0,82R e 20°. Além disso, os traços da Kimi são mais finos: caules e bases têm 3 células de espessura, enquanto os do dsh possuem 4,2 células de largura e 3,8 de altura. Por isso o widget da Kimi acende 510 células e o do dsh, 656. Nenhum dos dois corresponde exatamente ao logotipo original, mas ambos são facilmente identificados à primeira vista. Na segunda tentativa, o dsh também criou um teste unitário em Node e, sem solicitação, um script Playwright; na terceira tentativa, Kimi recebeu instrução para pular os testes e assim o fez.

Comandos de verificação que executei no widget do Kimi

Executei novamente esses comandos em 11/09/2026, na cópia servida por esta página, localizada em /assets/uploads/2026/09/kimi-codex/:

$ wc -l ll-pixel-logo.js
397 ll-pixel-logo.js
$ node --check ll-pixel-logo.js && echo "node --check passed"
node --check passed

Houve mais duas verificações feitas por mim, executadas com dois pequenos scripts auxiliares (cada um com menos de 20 linhas) que não publiquei. Portanto, segue aqui o método utilizado, em vez de comandos que você possa copiar e colar:

• Contagem de células iluminadas. Carreguei o arquivo do widget no Node, utilizando um DOM fictício (objetos canvas, window e document sem funcionalidade alguma). Capturei a função isLit(col, row) presente no próprio arquivo e a chamei para cada célula da grade 40×40, contando as células iluminadas por quadrante. O resultado foi 510 células iluminadas: 124 no quadrante superior esquerdo, 103 no superior direito, 160 no inferior esquerdo e 123 no inferior direito.
• Verificação de montagem. Com o mesmo DOM fictício, confirmei que o arquivo define window.LLPixelLogo como um objeto e que a chamada à função mount() em um elemento fictício retorna um objeto, sem gerar erros.

Somente o anel (células cujos centros estão entre 0,82R e R, sendo R = 19) representa 352 das 510 células iluminadas; restam então 158 células para formar os dois “Ls”. Os scripts auxiliares são de minha autoria, não do Kimi, e servem apenas como teste preliminar; a execução real ocorre no navegador: esta página que você está lendo é o resultado dessa execução.

Por que isso não é executado pelo Codex?

O OpenClaw também inclui um plugin de integração com o Codex que executa o próprio app-server do Codex (ele gerencia o @openai/codex 0.153.4). Nada neste artigo é processado por esse plugin, pois ele não consegue aceitar este modelo: sua verificação de rota, configuredModelRouteNeedsCodex, retorna false para qualquer provedor cujo ID normalizado não seja openai. O ID do provedor do Moonshot é moonshot; portanto, uma rota do tipo moonshot/kimi-k3 nunca chega ao runtime do Codex. “Compatível com OpenAI” não significa “compatível com o Codex”.

Assim, o modelo Kimi é executado no próprio loop do OpenClaw, da mesma forma que qualquer outro modelo nativo do OpenClaw. Você não terá a retomada de threads pelo Codex, seu mecanismo de compactação, a ponte dinâmica para ferramentas ou o modelo de execução do app-server. Se precisar desses recursos com o Kimi, a solução conhecida é o codex-router, uma ponte local que direciona o Codex para um endpoint em 127.0.0.1:4202 e encaminha as requisições ao Kimi (conforme descrito no README dele). Para que o plugin do OpenClaw reconheça essa configuração, o parâmetro appServer.homeScope deve ser definido como "user"; isso compartilha seu diretório ~/.codex (ou $CODEX_HOME) com o Codex, em vez de isolar o estado do Codex por agente do OpenClaw. Ainda não decidi se aceito essa abordagem; por isso, ainda não a implementei.

Armadilhas (as que eu realmente encontrei)

• Instruções criativas muito abertas podem fazer um modelo de raciocínio travar, e um tempo limite pode mascarar um sucesso. Na primeira tentativa, o modelo pensou por 8,8 minutos sem escrever nenhum código; na segunda tentativa, ele gerou um widget funcional, mas o tempo limite expirou com os arquivos na pasta errada, dando a impressão de que houve outro fracasso. A solução foi usar instruções mais curtas, assim redigidas: TARGETED — write the widget file in one tool call, no exploration, no planning, no verification loop., indicando também a pasta de destino. O K3 ainda raciocina com esse texto; só não planeja indefinidamente. Independentemente do código de saída, verifique o que a sessão produziu e também consulte o próprio espaço de trabalho do agente.
• Um código de erro na saída não significa necessariamente que a tarefa falhou. Verifique os arquivos. A primeira chamada para gerar o FizzBuzz retornou código 1, indicando “nenhum modelo vencedor”, e terminou com a mensagem “⚠️ Limite de taxa da API atingido. Por favor, tente novamente mais tarde.” No entanto, o arquivo fizz.py já havia sido criado e funcionava corretamente. Na nova tentativa, a resposta foi “Já foi criado e executado.”; apenas essa mensagem indicava que a tarefa fora concluída. Meu script gravava o JSON de cada execução no mesmo arquivo, então os dados da execução falha foram sobrescritos; seu código de saída e mensagem final permanecem registrados no log da sessão que conduziu o teste. A tabela exibe os resultados de uma execução posterior, em uma sessão nova.
• Não copie uma pasta de arquivos temporários de uma execução concluída em outro ambiente. Configurei a pasta de correções do Kimi copiando os arquivos da pasta finalizada pelo dsh; como o dsh já havia corrigido os problemas, a primeira execução do Kimi constatou que os arquivos já estavam corretos e apenas os verificou. É preciso copiar os arquivos de uma fonte original e íntegra. Após redefinir a pasta, executei novamente o teste em uma sessão nova; a tabela mostra os resultados dessa segunda execução.

O que isso significa para mim

Nessas cinco tarefas, o Kimi K3 teve sucesso, mas foi lento e caro. Para pequenas tarefas, o dsh no modelo V4-Flash realizou o mesmo trabalho em aproximadamente um nono do tempo e por cerca de 1/48 do preço (resultado positivo). Após esse teste de desempenho, transferi meu agente de processamento do Kimi para o MiniMax-M3; o Kimi K3 permaneceu onde já estava: atrás do meu agente de revisão, onde uma resposta mais lenta e cuidadosa vale a pena pagar.

Relacionado: DeepSeek Harness (dsh) (o sistema com o qual fiz a comparação; os testes e as instruções vieram dele), O confronto entre widgets de arte pixelada (os três widgets comparados lado a lado), MiniMax M3 (o mesmo conjunto de ferramentas no modelo que meu agente utiliza desde 11/09/2026) e Quanto realmente custam meus agentes de IA (uma comparação mais ampla de preços).