O Kimi K3 no Moonshot como agente de programação: integrando-o ao OpenClaw, comparando-o com o dsh em testes de desempenho e solicitando-lhe um widget de logotipo em pixel art.

Apontei meu agente trabalhador OpenClaw para o Kimi K3, o principal modelo de raciocínio da Moonshot, e o submeti aos mesmos cinco pequenos desafios de programação que usei em agosto para testar o DeepSeek Harness (dsh). O Kimi passou em todos os cinco. Em comparação com o dsh rodando no DeepSeek V4-Flash, executado no mesmo dia e com as mesmas cinco tarefas, o Kimi levou 9 vezes mais tempo (309,9 s contra 35,7 s) e custou 48 vezes mais ($0,531 contra $0,011). Depois disso, entreguei a ele o mesmo enunciado de criação do logotipo em pixel art que o dsh havia recebido. O Kimi precisou de três tentativas: na primeira, com o enunciado inalterado, nada foi produzido; na segunda, escreveu um widget completo, mas na pasta errada e foi interrompido pelo tempo limite antes de confirmar isso; só na terceira tentativa, após eu encurtar o enunciado e pedir que pulara a fase de planejamento, ele conseguiu produzir o resultado desejado.

Caminho A vs Caminho B, sinceramente

Tudo aqui segue o Caminho A: Kimi K3 executa o loop de agente da OpenClaw por meio do provedor Moonshot. Na minha máquina, o provedor já estava configurado; portanto, mudar o worker para o Kimi foi apenas uma alteração de modelo.

O Caminho B colocaria o Kimi atrás do próprio Codex app-server, que é executado pelo plugin Codex da OpenClaw (esse plugin gerencia o @openai/codex 0.153.4). Eu não desenvolvi esse caminho, e nada neste artigo utiliza o Codex. O motivo está no código do plugin: sua verificação de rota, configuredModelRouteNeedsCodex, retorna false para qualquer provedor cujo ID normalizado não seja openai. O ID do provedor Moonshot é moonshot; portanto, uma rota do tipo moonshot/kimi-k3 nunca chega ao runtime do Codex.

A solução conhecida é o codex-router, um “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 harness reconheça essa configuração, o parâmetro appServer.homeScope do plugin deve ser definido como "user"; isso faz com que o diretório ~/.codex (ou $CODEX_HOME) seja compartilhado entre o harness e o Codex, em vez de isolar o estado do Codex por agente da OpenClaw. Ainda não decidi se aceito essa abordagem; portanto, o Caminho B permanece apenas como uma possibilidade teórica.

O Caminho A também tem limitações que você deve conhecer. Os relatórios de execução indicam agentHarnessId: "openclaw", o mesmo formato usado por qualquer outro modelo nativo da OpenClaw. Contudo, não há suporte para retomada de threads do Codex, nem para a compactação de dados feita pelo próprio Codex, nem para a ponte dinâmica de ferramentas ou para o modelo de execução do app-server. Se você precisa desses recursos, o Caminho B é a única opção.

Configuração: em que ambiente executei

Estes são os comandos que executei na minha máquina em 11/09/2026, juntamente com suas saídas reais:

$ 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

Três coisas importantes para saber antes de executar qualquer coisa:

• O K3 sempre realiza raciocínio. O plugin envia por padrão reasoning_effort: "max" 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 similares) pois o K3 define esses valores automaticamente; minha entrada de modelo indica o mesmo, com supportsTemperature: false. Até mesmo a solicitação “Responda exatamente: PONG.” consumiu 53 tokens de raciocínio.
• O contexto de 1 milhão é anunciado, mas eu o limito. O catálogo Moonshot da OpenClaw lista o K3 com um limite de contexto de 1.048.576 tokens. No entanto, configurei contextTokens: 262144 na entrada do modelo, para que as sessões sejam compactadas no mesmo ponto que os demais modelos que uso. Na prática, espera-se um limite de 256 mil tokens, e não 1 milhão.
• O cache é responsável por reduzir significativamente o custo. Cada tarefa começa com cerca de 15 mil tokens referentes ao prompt do sistema e às definições das ferramentas. Após a primeira etapa, a maior parte desses dados é lida do cache, ao custo de US$ 0,30 por milhão de tokens, em vez de US$ 3. Na tarefa de renomeação, apenas as leituras do cache totalizaram 157.952 tokens.

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 documentação oficial do OpenClaw. Na minha máquina, o plugin e a chave já estavam configurados; por isso, executei apenas o comando de verificação da ú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 de MOONSHOT_API_KEY. Eu mantenho essa chave no arquivo de variáveis 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: o K2.7 exige que tanto thinking quanto reasoning_effort sejam omitidos na solicitação, e o plugin faz isso 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 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 custou uma regressão silenciosa: 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 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ê usar o campo compat, escreva todo o objeto, como mostrado acima.

A linha contextTokens: 262144 representa o limite indicado nas instruções de configuração. Se você aumentar esse valor, pode esperar um aumento nos custos relacionados à leitura do cache e na latência por turno da sessão.

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

Cada tarefa de benchmark consistia em uma chamada como esta, usando 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" é a assinatura do Caminho A. Uma execução pelo servidor de aplicações Codex exibiria "codex". winnerModel: "kimi-k3" indica que a execução realmente ocorreu no K3 e não recorreu a um modelo mais barato. reasoningTokens são contados dentro de output (o total é a soma de input + output); portanto, os 53 tokens de raciocínio fazem parte dos 70 totais.

Lado a lado: Kimi K3 no OpenClaw vs dsh

Ambos são loops de agente 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 (Caminho A)	dsh
Quem o desenvolve	Modelo: Moonshot AI. Loop de agente: OpenClaw	DeepSeek (modelo e ambiente de execução), 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 modelo	O parâmetro model.primary no arquivo openclaw.json	~/.dsh/settings.yaml
Teste em modo headless, 5 tarefas pequenas	309,9 s, ≈ $0,531, 5/5	35,7 s, ≈ $0,011, 5/5 (V4-Flash; a segunda execução foi mais rápida)
Criação de widget em pixel-art, mesmo comando	3 tentativas; duas delas resultaram em um widget; o exemplo 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 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 para o Reasonix. Retirei o Reasonix da 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 benchmark: as mesmas 5 tarefas

São as mesmas cinco tarefas executadas no artigo sobre o dsh; cada uma em uma pasta temporária diferente, com uma sessão nova para cada tarefa do Kimi. Re-executei o dsh no V4-Flash no mesmo dia, nas mesmas cinco tarefas, vinculando-o ao modelo deepseek-v4-flash em um arquivo de configuração temporário. A redação dos prompts não foi idêntica. O dsh roda na pasta onde é iniciado, então seus prompts mencionavam “o diretório atual”. Os prompts do Kimi indicavam 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 nunca executou o comando de instalação). Essa coluna representa a segunda execução: a primeira levou 44,8 segundos e custou $0,024, com o cache ainda “frio”; a segunda é a que uso para comparações em todo este artigo. As colunas do V4-Pro e Gemma-4-26B vêm do artigo sobre o dsh de agosto; essas execuções não foram repetidas. O tempo total inclui todo o processo. Os tokens e custos do Kimi são extraídos do arquivo JSON gerado pelo OpenClaw; os dados do dsh vêm de seu próprio log de sessão.

Tarefa	Kimi K3 (Caminho A)	dsh V4-Flash (mesmo dia)	dsh V4-Pro (agosto, dados históricos)	Gemma-4-26B (agosto, dados históricos)
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; comprovar que tudo funciona	✅ 128,9 s · 9 ferramentas (exec, write; um comando sed aplicado aos 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 / lidos 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 de tokens)	≈ $0,011 ($0,44 / $1,32 / $0,014 por milhão de tokens)	≈ $0,072	$0 (apenas custo de energia elétrica)

O número de ferramentas refere-se às chamadas feitas. Os dados do Kimi vêm de toolSummary.calls no arquivo JSON gerado pelo OpenClaw; os tipos de ferramentas estão entre parênteses. Os dados do dsh vêm de seu log de sessão. *Primeira chamada após o modelo ser carregado na máquina. As taxas cobradas pelo Kimi são as informadas no catálogo do OpenClaw, que utiliza esses valores para calcular o custo de cada tarefa; consulte a página de preços da Moonshot para ver os valores atuais. O custo do dsh V4-Flash usa as mesmas taxas máximas mencionadas no artigo sobre o dsh (preços da DeepSeek); os dados das colunas V4-Pro e Gemma são os do referido artigo.

O que a tabela revela:

• 5/5 em todas as colunas. Nenhuma dessas tarefas apresentou dificuldades para o Kimi. A correção de bugs deixou os testes inalterados; a renomeação da função exigiu apenas um comando sed aplicado a quatro arquivos, seguido por uma execução limpa dos testes e uma busca vazia com grep pelo nome antigo.
• O Kimi gasta mais tempo “pensando”. 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 realiza raciocínio, 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 processo de raciocínio e a etapas adicionais.
• O cache influencia bastante no custo. Nas cinco tarefas, o Kimi enviou 91.470 tokens de entrada sem uso de cache e leu 355.328 tokens do cache; ou seja, 80% dos tokens utilizados vieram do cache. Se fossem cobrados como tokens não em cache, o custo total seria cerca de $1,49, em vez dos $0,53 reais.
• Para tarefas simples, o V4-Flash é imbatível. O tempo total de 35,7 segundos e um custo de aproximadamente $0,011 representam um desempenho cerca de 9× mais rápido e 48× mais barato que o Kimi nas mesmas tarefas, com resultados idênticos. Só a renomeação da função consumiu 128,9 segundos e $0,180 no Kimi; já no dsh, foram apenas 12,3 segundos e $0,0043.

O teste divertido: o mesmo brief para criação de widget, Kimi vs dsh

No “teste divertido” do artigo do dsh, foi criado um widget em pixel-art com o logotipo deste site, desenvolvido por dsh no V4-Flash a partir de um brief escrito. Entreguei a Kimi o mesmo brief, sem edições, e cronometrei o processo. O brief era o seguinte:

Brief: widget interativo em pixel-art do logotipo LaserLloyd

Crie uma versão em pixel-art do logotipo LaserLloyd (ver reference-logo.png: um anel azul grosso, cor #1f3f8f sobre fundo branco, contendo duas letras “L” cursivas/inclinadas entrelaçadas — a parte inferior da “L” superior fica sob a parte superior da “L” inferior, como se as letras estivessem empilhadas diagonalmente).

Entregáveis (todos nesta pasta)

1. ll-pixel-logo.js — UM único arquivo em JavaScript puro, sem dependências, sem necessidade de compilação ou requisições de rede. Qualquer página pode incorporá-lo com: <div class="ll-pixel-logo" data-size="320"></div> + <script src="ll-pixel-logo.js"></script>. O código encontra todos os elementos .ll-pixel-logo e insere um elemento <canvas> dentro deles. Responsivo: o canvas preenche toda a largura do container, mantendo-se nítido em telas HiDPI (devicePixelRatio). Exponha window.LLPixelLogo.mount(el).
2. index.html — uma página de demonstração mostrando o widget em três tamanhos, com breves explicações sobre suas interações.
3. README.md — instruções para incorporação do widget, descrição das interações e dos atributos utilizáveis.

A arte

• Uma grade de pixels de 40×40 células. NÃO desenhe manualmente o bitmap (nada de linhas com caracteres ‘#’/‘.’ — isso é lento e propenso a erros). Em vez disso, gerar o bitmap proceduralmente a partir da geometria: uma função isLit(col,row) que retorna true para (a) pontos dentro do anel: distância do centro entre 0,82R e R; e (b) para os dois “Ls” inclinados, formados por dois paralelogramos (um caule inclinado ~20° e uma base); a base da “L” superior fica sob o caule da “L” inferior, conforme o modelo de referência. Ajuste as poucas constantes para que o resultado se assemelhe ao logotipo original em 200px. Calcule previamente os pontos iluminados no momento da montagem do widget.
• Paleta: azul do logotipo #1f3f8f; azul claro #2ea8ff; âmbar #ffb64a; ciano #00e6cf; fundo transparente.

Interações (o objetivo do exercício — que sejam agradáveis)

• Sobreposição do mouse/toque: os pixels próximos ao cursor reagem fisicamente — são “empurrados” para longe, como num efeito de repulsão magnética/fluida, depois voltam à posição original com amortecimento; enquanto se deslocam, brilham nas cores #2ea8ff/#00e6cf. A animação roda a 60fps via requestAnimationFrame, sem travamentos.
• Clique/toque: algo interessante e satisfatório. Escolha UM único efeito marcante e implemente-o bem; por exemplo: o logotipo se desfaz em pixels que voam para fora com gravidade/ressalto, depois voltam a formar o logo (aproximadamente 1,5–2 segundos); ou um “laser” percorre o canvas e re-desenha o logo pixel por pixel, deixando faíscas brilhantes. Clicks repetidos devem ter resposta agradável (não interrompa a animação em curso).
• Em repouso: um leve movimento ambiente (um brilho suave ou um piscar ocasional de pixels) para que o widget nunca pare “morto”, porém sem ser distrativo.
• Respeite prefers-reduced-motion: reduce (exiba apenas o logo estático, mantendo o brilho no efeito de hover).
• Funcione tanto com mouse quanto com toque. Não bloqueie o scroll da página.

Padrões de qualidade

• Código limpo, comentado; sem variáveis globais exceto LLPixelLogo. Indentação com 2 espaços. Aproximadamente 400 linhas no total.
• Funcione a partir de file:// sem erros no console. Teste-o você mesmo: crie um pequeno script Node ou abra o arquivo para verificar sintaxe e executar testes (ex.: jsdom NÃO está disponível — use node --check e também faça um teste unitário sem DOM, contando os pixels iluminados e confirmando a presença do anel e das duas “Ls” nos quadrantes corretos).
• Finalize com a impressão de um breve relatório: o que foi criado, como incorporar o widget e o que foi verificado.

Como Kimi lidou com isso:

• Tentativa 1 (brief original, sem edições): parou após 8,8 minutos, sem código do widget, custo de ≈ $0,31. O K3 analisou o logotipo de referência, raciocinou sobre geometria e ferramentas necessárias, mas não escreveu nenhum dos entregáveis. A primeira tentativa do dsh também falhou da mesma forma (um loop de 10 minutos desenhando um bitmap mentalmente), embora o brief permitisse então o desenho manual.
• Tentativa 2 (novo brief, nova sessão): widget completo, porém no local errado, custo de ≈ $0,72. Após cerca de 8 minutos, escreveu um arquivo ll-pixel-logo.js com 323 linhas, depois uma página de demonstração, um README e dois arquivos de teste; executou e ajustou os testes até que passassem, e por fim redigiu um relatório. Tudo foi salvo na pasta de trabalho do agente, e não na pasta monitorada pelo meu script; a sessão atingiu o limite de 15 minutos antes de responder. Do meu ponto de observação, a tentativa 2 parecia não ter produzido nada, então não esperei: iniciei a tentativa 3 após uns 7 minutos.
• Tentativa 3 (brief encurtado e instruções específicas): 7,4 minutos, três arquivos criados, custo de ≈ $0,47. Mantive os requisitos de entregáveis, arte e interações; adicionei TARGETED — write the widget file in one tool call, no exploration, no planning, no verification loop. no topo do brief, e substituí a seção de testes por uma instrução final Do NOT do a "node --check" or playwright test — just write the files and print a short report listing what you wrote. O widget inclui repulsão de pixels sob o cursor, efeito de fragmentação ao clique, brilho ambiente e modo de movimento reduzido. Minhas verificações estão na próxima seção.

Assim, as três tentativas consumiram 8,8, 15 e 7,4 minutos, custando aproximadamente $0,31, $0,72 e $0,47: somando cerca de $1,50 para dois widgets. O custo da tentativa 3 vem do recibo JSON gerado. As tentativas 1 e 2 não produziram recibos, portanto seus valores são as cobranças por mensagem do OpenClaw para cada sessão; esse total coincide com o valor informado no recibo da tentativa 3.

O widget da tentativa 2 reapareceu cerca de uma hora depois, quando um MiniMax M3 executado no mesmo worker encontrou os arquivos, rodou seus testes e os reportou como seu próprio trabalho. Essa história está descrita no relatório do MiniMax M3; ambos os widgets da Kimi ficam ao lado dos do dsh no desafio de widgets em pixel-art.

O que a Kimi produziu, primeiras ~30 linhas do ll-pixel-logo.js:

/*!
 * 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

E aqui está o widget rodando, construído pela Kimi K3, sem alterações:

A Kimi cria cada “L” a partir de dois paralelogramos (caule e base inclinados) usando uma pequena função makeL; testa os pontos com inPara dentro de isLit, mantendo todas as constantes de ajuste (raios do anel 0,82R a R, ângulo de 20° obtido via Math.tan, parâmetros de amortecimento e mola) num único bloco no início do arquivo.

Os arquivos criados pela Kimi (o ll-pixel-logo.js com 397 linhas, o index.html de 40 linhas e o README.md de 79 linhas) estão disponíveis em /assets/uploads/2026/09/kimi-codex/, ao lado do brief original como BRIEF.md.

Para comparação, as primeiras ~30 linhas do widget do dsh, servidas a partir de /assets/uploads/2026/08/deepseek-harness/ll-pixel-logo.js:

/*!
 * ll-pixel-logo.js — interactive pixel-art LaserLloyd logo widget.
 * Vanilla JS, zero dependencies, no network requests, works from file://.
 *   <div class="ll-pixel-logo" data-size="320"></div>
 *   <script src="ll-pixel-logo.js"></script>
 * Auto-mounts on .ll-pixel-logo elements; window.LLPixelLogo.mount(el) too.
 * Knobs: data-size, data-speed, data-static.
 */
(function (global) {
  'use strict';
  // ---- 0. palette -----------------------------------------------------
  var BLUE = [31, 63, 143];      // #1f3f8f — logo blue
  var HI = [46, 168, 255];       // #2ea8ff — hover / repulsion glow
  var AMBER = [255, 182, 74];    // #ffb64a — twinkle spark
  var CYAN = [0, 230, 207];      // #00e6cf — deep glow
  // ---- 1. art: procedural 40x40 raster (no hand-drawn bitmap) ----------
  // A cell is lit when it belongs to the ring or to one of the two slanted
  // interlocking Ls. Each L is two parallelograms (stem + foot), described by
  // top-left (ax,ay), width w, height h, sheared by SLANT (bottom edge shifts
  // left): TL=(ax,ay) TR=(ax+w,ay) BL=(ax-SLANT*h,ay+h). The upper-left L's
  // foot runs right and tucks under the lower-right L's stem, like the ref.
  var GRID = 40;                 // cells per side
  var RING_R = 19.7;             // outer ring radius (cells)
  var RING_IN = 0.80 * RING_R;   // inner ring radius (reference ~0.808R)
  var SLANT = 0.453;             // shear of stems/feet (~24deg)
  var LETTERS = [
    { ax: 15.0, ay: 5.2, w: 4.2, h: 10.6 },   // upper-left L: stem
    { ax: 10.2, ay: 15.8, w: 15.0, h: 3.8 },  // upper-left L: foot
    { ax: 24.7, ay: 13.8, w: 4.2, h: 14.7 },  // lower-right L: stem
    { ax: 18.0, ay: 28.5, w: 15.0, h: 3.8 }   // lower-right L: foot
  ];

Ambos os widgets são gerados da mesma forma: rasterizam um anel e duas “Ls” cursivas a partir de geometria; expõem window.LLPixelLogo.mount e respeitam prefers-reduced-motion. As constantes, porém, diferem. O dsh usa raio externo de 19,7, interno em 0,80R e ângulo de 0,453 (aproximadamente 24°); a Kimi utiliza 19, 0,82R e 20°. Os traços da Kimi também são mais finos: caules e bases possuem 3 células de espessura, enquanto os do dsh têm 4,2 células de largura e 3,8 de altura. Por isso o logo da Kimi ilumina 510 células e o do dsh, 656. Nenhum dos dois corresponde exatamente ao modelo de referência, mas ambos são reconhecíveis à primeira vista. A segunda tentativa do dsh gerou também um teste unitário Node e, sem pedido, um script Playwright; a terceira tentativa da Kimi recebeu instrução para pular 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. Por isso, apresento aqui o método utilizado, em vez de comandos que você possa copiar diretamente:

• Contagem de células iluminadas. Carreguei o arquivo do widget no Node usando um DOM fictício (objetos canvas, window e document vazios). Capturei a função isLit(col, row) definida no próprio arquivo e a chamei para cada célula da grade 40×40, contando as células iluminadas por quadrante. No total, foram 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. Usando o mesmo DOM fictício, confirmei que o arquivo define window.LLPixelLogo como um objeto e que a chamada a 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) corresponde a 352 das 510 células iluminadas; restam então 158 células para os dois “Ls”. Os scripts auxiliares são de minha autoria, não do Kimi, e servem apenas como teste preliminar; o teste real foi feito no navegador: a página que você está lendo é o resultado desse teste.

Armadilhas (as que eu realmente encontrei)

• “Compatível com OpenAI” não significa “compatível com o plugin Codex”. O endpoint /v1/chat/completions do Moonshot funciona perfeitamente como provedor no OpenClaw, mas o plugin Codex aceita apenas rotas cujo ID do provedor seja openai. Se você precisa especificamente da retomada de threads do Codex e da ponte dinâmica de ferramentas, o Caminho B (a ponte codex-router) é a única opção. Veja a comparação entre o Caminho A e o Caminho B acima.
• O K3 sempre realiza raciocínio, mesmo em respostas triviais. Para a solicitação “Responda exatamente: PONG.” foram consumidos 53 tokens de raciocínio. Isso faz parte do design do sistema e é previsível; planeje seu orçamento para isso.
• Um bloco compat substitui o conteúdo existente, não o mescla. Se adicionar compat à entrada do modelo para recusar o uso de temperature, copie também os campos relacionados ao esforço de raciocínio do plugin; caso contrário, eles serão perdidos silenciosamente.
• O limite de 1 milhão de tokens é divulgado, mas não é o que você obtém com minha configuração. O catálogo indica 1.048.576 tokens; porém, meu contextTokens: 262144 faz com que as sessões sejam compactadas em até 256 mil tokens. Aumente esse valor intencionalmente, não por acidente.
• O desconto pelo uso do cache existe, mas as tarifas aplicadas são as tarifas padrão. O custo de $0,30 por milhão de tokens lidos do cache equivale a cerca de 21 vezes o valor de $0,014 cobrado pelo dsh V4-Flash. Mesmo assim, o uso do cache reduziu o custo total para cerca de um terço do preço sem cache.
• Instruções criativas abertas podem fazer um modelo de raciocínio travar; um tempo limite pode mascarar um sucesso. Na primeira tentativa, o sistema levou 8,8 minutos para pensar e não gerou nenhum código. Na segunda tentativa, foi produzido um widget funcional, mas o tempo limite expirou com os arquivos na pasta errada, dando a impressão de falha. O que realmente gerou o widget esperado foi uma instrução mais curta: TARGETED — write the widget file in one tool call, no exploration, no planning, no verification loop., com a pasta de destino explicitamente definida. O K3 ainda realiza raciocínio mesmo com essa formulação; só não passa muito tempo planejando. Independentemente do status de saída, verifique o que foi efetivamente gerado na sessão.
• Um código de erro ao finalizar a execução não significa necessariamente falha na tarefa. Verifique os arquivos. Na primeira chamada para gerar o FizzBuzz, o código de saída foi 1; o sistema informou que “nenhum modelo adequado foi encontrado” e terminou com a mensagem “⚠️ Limite de requisições à API atingido. Tente novamente mais tarde.” Contudo, o arquivo fizz.py já havia sido criado e funcionava corretamente. Na nova tentativa, o sistema respondeu “Já foi criado e executado.”; apenas essa mensagem indicava conclusão. Meu script gravava os resultados JSON de cada execução no mesmo arquivo, então os dados da falha foram sobrescritos; porém, seu código de saída e a mensagem final permanecem no log da sessão responsável pelo teste. A tabela utiliza os dados de uma execução posterior, em uma sessão limpa.
• Não copie uma pasta de trabalho de uma execução concluída em outro plugin. Configurei a pasta de correção de bugs do Kimi copiando arquivos da pasta de execução finalizada pelo dsh; como este já havia corrigido os erros, a primeira execução do Kimi apenas verificou que os problemas estavam resolvidos. Depois reiniciei a pasta e executei novamente; a tabela mostra essa segunda execução. Adicionalmente, o dsh funciona no diretório onde é iniciado: meu primeiro script não fez cd para a pasta da tarefa, gerando os arquivos no local errado; tive então que executar todas as cinco tarefas novamente.
• Nenhum dos widgets produzidos corresponde exatamente ao logotipo de referência. As instruções pedem o ajuste das constantes para que o widget se assemelhe ao logotipo em 200px. Eu dedicaria uns dez minutos para ajustar larguras de traços e inclinação antes de liberar qualquer um dos dois.

O que isso significa para mim

Nessas cinco tarefas, o Kimi K3 teve sucesso, mas foi lento e caro. Para tarefas simples, o dsh no V4-Flash realizou o mesmo trabalho em cerca de um nono do tempo e por aproximadamente 1/48 do preço. Após esse teste, 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.

O Caminho B, que consiste na ponte codex-router para o servidor da aplicação Codex propriamente dito, ainda permanece apenas no papel, até que eu tenha certeza sobre o que o homeScope: "user" compartilha. Até lá, “Kimi como agente de programação” no meu sistema significa que o Kimi controla o loop nativo do OpenClaw, da mesma forma que qualquer outro modelo nativo do OpenClaw.

Relacionado: DeepSeek Harness (dsh) (o sistema com o qual fiz a comparação; de lá vieram os critérios e as instruções do teste), MiniMax M3 (o mesmo sistema rodando no modelo que meu agente utiliza desde 11/09/2026), Reasonix (versão histórica; retirado do meu sistema em 09/09/2026) e Quanto realmente custam meus agentes de IA (uma comparação mais ampla de preços).