Melhor modelo local para OpenClaw: gemma4, gpt-oss:20b e qwen3-coder:30b medidos em quatro tarefas de agente

Em um M3 Max com 128 GB executando o OpenClaw 2026.9.7 com o Ollama 0.35.0, gemma4 — o modelo sugerido pela própria configuração do Ollama no OpenClaw — foi aprovado em todas as 12 execuções avaliadas nas quatro tarefas de agente; gpt-oss:20b foi aprovado em 11 de 12, com quase três vezes mais chamadas de ferramentas malsucedidas; e qwen3-coder:30b, a escolha habitual para programação, foi aprovado em 2 de 12 porque suas chamadas de ferramentas continuaram falhando no analisador do Ollama. Executamos cada modelo três vezes em cada tarefa, em um workspace novo, avaliamos o resultado por script e registramos as contagens de ferramentas e tokens do próprio OpenClaw e o log do servidor do Ollama. Medido em 1º de outubro de 2026.

Para saber quanto o próprio OpenClaw custa e quanto custaria um modelo hospedado, consulte Preços do OpenClaw; para executar um modelo local com fallback de API, consulte vários agentes e modelos no OpenClaw.

O que foi executado

As quatro tarefas

Resultados

Os tempos são de relógio corrido por execução, incluindo cerca de cinco a sete segundos de inicialização do OpenClaw. "Tokens de entrada" são as entradas não armazenadas em cache, conforme registradas pelo OpenClaw; o contexto reenviado do cache fica além disso e é contado na seção de custos abaixo. A coluna de chamadas de ferramentas malsucedidas conta as falhas registradas pelo OpenClaw; as falhas do qwen3-coder ocorreram antes de uma chamada chegar ao OpenClaw, por isso aparecem como zero nessa coluna e são explicadas abaixo.

O que os números indicam

• gemma4 e gpt-oss:20b são utilizáveis para tarefas curtas de agente. 23 das 24 execuções foram aprovadas, incluindo a correção em dois arquivos, que exige ler vários módulos, editar dois deles e executar os testes novamente.
• gemma4 usou as ferramentas de forma mais limpa. Na tarefa de leitura, fez exatamente uma chamada de ferramenta todas as vezes; gpt-oss fez três, duas das quais normalmente falharam antes de ler o arquivo. Nas doze execuções, gpt-oss teve 19 chamadas de ferramentas malsucedidas, contra 7 do gemma4, e teve em média 9.1 turnos do assistente por tarefa, contra 6.8 do gemma4.
• A única falha foi do gpt-oss na tarefa de contagem: após treze chamadas de ferramentas, ele escreveu um counts.json malformado e encerrou o turno sem responder.
• A velocidade não é o fator de diferenciação aqui. A mediana foi de 53 s para gemma4 e 54 s para gpt-oss em todas as execuções; a execução individual mais lenta foi a do gemma4, com 133 s na correção em dois arquivos e dezessete chamadas de ferramentas. As execuções do qwen3-coder foram mais curtas apenas porque falharam cedo.
• Os modelos maiores não trouxeram mais precisão nessas tarefas. gpt-oss:20b tem quase três vezes a quantidade de parâmetros do gemma4, e qwen3-coder:30b, desenvolvido para código, teve a menor pontuação dos três.

Doze execuções por modelo são suficientes para identificar um padrão nessas tarefas, mas não para classificar modelos de modo geral. Tarefas longas, bases de código maiores e outras quantizações não foram testadas.

Por que qwen3-coder:30b falhou

Não foi na programação. Das dez execuções malsucedidas:

• Cinco terminaram no analisador do Ollama. qwen3-coder escreve chamadas de ferramentas como XML e, quando um argumento continha código, fechava um elemento <parameter> com </function>. O log do servidor do Ollama 0.35.0 registrou "qwen tool call parsing failed … XML syntax error … element <parameter> closed by </function>", e o OpenClaw encerrou o turno com "Agent run failed".
• Quatro nunca fizeram uma chamada. A resposta anunciava a próxima etapa e então imprimia um </tool_call> isolado como texto, sem nada que o Ollama pudesse analisar como chamada; o turno terminava ali. Esse é o sintoma que a documentação do OpenClaw associa à URL /v1 — aqui, ele ocorreu na API nativa.
• Uma foi uma resposta errada: contou as linhas de cabeçalho do CSV como linhas de dados.

O analisador é do Ollama, portanto este é um resultado do Ollama 0.35.0, não um veredito sobre o modelo. Se você executar qwen3-coder com o OpenClaw, observe o log de ollama serve em busca de "qwen tool call parsing failed" antes de culpar o modelo e teste novamente após atualizar o Ollama.

A configuração que importou

• URL nativa do Ollama. A documentação do OpenClaw diz que a URL compatível com OpenAI /v1 "interrompe as chamadas de ferramentas e os modelos podem emitir JSON bruto de chamada de ferramenta como texto simples"; as execuções usaram baseUrl sem /v1, junto com api: "ollama".
• Fixe contextWindow nas entradas escritas manualmente. Em um teste rápido, uma entrada de modelo explícita sem esse parâmetro foi resolvida para um contexto de 200.000 tokens; a própria configuração do Ollama no OpenClaw escreve 32.768 para modelos locais, valor usado nestas execuções.
• O contexto do Ollama é separado. O Ollama 0.35.0 carregou gemma4 e gpt-oss com 131.072 tokens e qwen3-coder com 262.144 — 45,3 GB residentes — independentemente dos 32.768 do OpenClaw; é isso, e não o orçamento do OpenClaw, que determina a memória.
• Coloque o shell em uma sandbox. Um modelo local executando comandos de shell na sua máquina é o risco real aqui. Com sandbox.mode: "all", o exec foi executado na imagem Docker do OpenClaw, com apenas o workspace montado; a imagem é criada uma vez com o comando docker build na documentação de sandbox do OpenClaw.

// ~/.openclaw/openclaw.json — the runs used one model per config; the
// fallbacks line shows the pattern and was not part of the measured runs
{
  models: { providers: { ollama: {
    apiKey: "ollama-local",
    baseUrl: "http://127.0.0.1:11434",   // native Ollama URL — no /v1
    api: "ollama",
    timeoutSeconds: 600,
    models: [
      { id: "gemma4:latest", name: "gemma4:latest", contextWindow: 32768, maxTokens: 8192,
        params: { keep_alive: "30m" } },
      { id: "gpt-oss:20b",   name: "gpt-oss:20b",   contextWindow: 32768, maxTokens: 8192,
        params: { keep_alive: "30m" } },
    ],
  } } },
  agents: { defaults: {
    model: { primary: "ollama/gemma4:latest", fallbacks: ["ollama/gpt-oss:20b"] },
    sandbox: { mode: "all", workspaceAccess: "rw" },   // shell runs in Docker
  } },
  tools: { exec: { mode: "full" } },
}

Quanto custa localmente

Um modelo local troca uma cobrança por token por tempo, disco e eletricidade. Por execução, o OpenClaw registrou aproximadamente 16,415 tokens de entrada não armazenados em cache, 78,469 tokens de contexto reenviado do cache e 1,142 tokens de saída para gemma4, e 13,761, 88,688 e 1,192 para gpt-oss. Como cálculo aproximado — os tokenizadores diferem entre os modelos — as mesmas contagens às taxas da Kunavo para Claude Haiku 4.5 ($0.70 de entrada, $0.07 em cache, $3.50 de saída por milhão) chegam a cerca de $0.021 e $0.020 por execução. A potência elétrica não foi medida; a eletricidade por execução é watts × segundos ÷ 3.600.000 × seu preço por kWh.

O padrão prático é usar um modelo local como principal, com um fallback hospedado para os turnos em que o modelo local falha. O OpenClaw aceita uma lista de fallbacks por agente; uma chave Kunavo funciona como provedor compatível com OpenAI ao lado do Ollama, com cobrança por token a partir de um saldo pré-pago. Ninguém na Kunavo executou o OpenClaw contra seu endpoint — estas execuções foram totalmente locais.

Perguntas frequentes

Executado em 1º de outubro de 2026 em um Apple M3 Max (128 GB): OpenClaw 2026.9.7 (npm, Node 24.21.0), Ollama v0.35.0 (binário de release), gemma4:latest, gpt-oss:20b e qwen3-coder:30b obtidos do registro do Ollama e verificados por sha256. Cada uma das 36 execuções usou um workspace novo e um estado novo do OpenClaw, exec na sandbox Docker do OpenClaw e um avaliador por script; as chamadas de ferramentas e as contagens de tokens são a própria saída JSON do OpenClaw. Os fixtures das tarefas, os avaliadores e o script adaptador são publicados com as evidências desta página. Não medido: potência elétrica consumida, tarefas longas, outras quantizações ou máquinas menores.