Otimização de desempenho do OpenClaw: da análise de logs à redução de 80% nos custos

No mês passado, recebi a fatura da Anthropic e travei quando vi $347. Eu só tinha usado o OpenClaw para escrever alguns artigos e fazer algumas revisões de código. Pior: nas últimas semanas, o OpenClaw estava respondendo cada vez mais devagar. Às vezes eu esperava mais de 20 segundos por uma resposta.

Fiquei olhando para a fatura por um bom tempo. Depois comecei a vasculhar os logs.

As linhas rolando uma atrás da outra mostraram o problema: cada conversa carregava o histórico completo. Depois de 10 rodadas, o contexto tinha acumulado 150K tokens. É como se, a cada fala, você precisasse repetir toda a conversa anterior. Não é surpresa que a conta tenha vindo tão alta.

Passei duas semanas testando métodos diferentes: reset de sessão, troca de modelo, estratégia de cache, limite de contexto. No fim, o custo mensal caiu de $347 para $68, e o tempo de resposta saiu de 23 segundos para 4 segundos.

A raiz do consumo excessivo de tokens no OpenClaw não é “usar demais”. É usar do jeito errado. Este artigo mostra um caminho prático, da análise de logs às estratégias de otimização, com comandos que você pode copiar e adaptar diretamente.

Guia de baixo custo para “criar camarão”: ArkClaw deixa AI Agent realmente acessível

O OpenClaw, que ficou bem popular recentemente, é poderoso, mas a configuração assusta? O ArkClaw, da ByteDance Volcano Engine, baixa a barreira quase ao chão. Sem brigar com servidor nem configurar Token, você ganha com um clique um “burro de carga de IA” online 24 horas por dia, capaz de controlar navegador, rodar scripts e gerenciar calendário.

O ponto principal é que ele é barato de verdade: a mensalidade é só 9,9 yuans. Usando meu convite ZLKUK54M (cadastre-se aqui), sai por apenas 8,9 yuans. Se você é programador, entrar direto no Coding Plan Pro ainda permite usar de graça.

A raiz do problema de desempenho: por que o OpenClaw fica lento

Os 5 maiores vilões do consumo de tokens

Você talvez pense: consumo alto de tokens não é simplesmente porque usei muito? Não é tão simples.

Vilão 1: contexto de conversa acumulado sem limite

Por padrão, o OpenClaw preserva todo o histórico de conversa. A primeira rodada pode ter só 5K tokens; na décima, já virou 150K. Sempre que você faz uma pergunta, o OpenClaw precisa reenviar tudo o que veio antes para a Claude API. É como conversar com um amigo e, antes de cada frase, repetir as conversas da semana e do mês passado. Muito esforço para pouco ganho.

Eu testei um pedido simples, tipo “dá uma olhada neste código e veja se tem problema”. Se o contexto já acumulou 100K tokens, mesmo que a resposta tenha só 200 palavras, a cobrança considera aqueles 100K.

Vilão 2: saída de ferramentas armazenada sem limite

O OpenClaw lê arquivos, consulta logs e executa comandos. O problema é que a saída de cada ferramenta fica salva por completo no contexto. Você pediu para ele olhar um log de 500 linhas? Essas 500 linhas continuam na memória. Depois consulta um arquivo de configuração? Mais algumas centenas de linhas entram na conta.

Antes, pedi ao OpenClaw para analisar um log de erro de 10MB. O trecho ficou ocupando contexto; depois disso, cada nova conversa pagava por aqueles 10MB.

Vilão 3: system prompt reenviado a cada rodada

O system prompt do OpenClaw costuma ter 5K-10K tokens e define as capacidades e o comportamento da ferramenta. Esse conteúdo é enviado em toda rodada. Se você conversar 50 vezes com o OpenClaw em um dia, só o system prompt consome 250K-500K tokens.

Vilão 4: escolha errada de modelo

O Claude tem modelos em diferentes níveis: Haiku, barato e rápido; Sonnet, equilibrado; Opus, poderoso e caro. A diferença de preço é de cerca de 15 vezes.

Muita gente escolhe o caminho mais fácil e define Opus como padrão. Aí tarefas simples, como conversão de formato ou consulta de informação, usam o modelo mais caro. É como ir ao mercado da esquina comprar uma garrafa de água pilotando um tanque. Chega lá, mas não faz sentido.

Vilão 5: heartbeat mal configurado

O OpenClaw tem um mecanismo de heartbeat que faz pings periódicos na API para manter a conexão. Se alguém define o intervalo em 30 segundos, são 120 chamadas API por hora. Cada chamada é pequena, mas a frequência pesa.

Vi um caso em que o intervalo de heartbeat estava curto demais. Em um mês, só o heartbeat gerou 3.600 chamadas. Nenhum trabalho real feito, mas a fatura já tinha crescido.

A verdade sobre o vilão da memória

Quando o OpenClaw fica lento, às vezes o problema não é a rede. É falta de memória.

Muita gente olha para o OpenClaw e pensa: é só uma ferramenta de chat, 2GB de memória devem bastar. Na prática, não é assim.

O OpenClaw é uma aplicação intensiva em memória. Ele roda processos Node.js, mantém conexões WebSocket, armazena memória de sessão e renderiza a Web UI. Somando tudo, só a base já consome por volta de 1,5GB. Dar 2GB para ele é como pedir para alguém correr uma maratona com uma mochila de 50 kg. Em teoria dá; na prática, pode cair a qualquer momento.

Minha experiência:

• 2GB de memória: inicia, mas começa a engasgar depois de algum tempo e cai com frequência
• 4GB de memória: uso normal, adequado para desenvolvimento pessoal diário
• 8GB de memória: fluido e estável, bom para equipes ou uso intenso
• 16GB de memória: padrão de produção, roda por longos períodos sem pressão

Ainda há outro problema: vazamento de memória. Depois de rodar por muito tempo, o uso de memória do OpenClaw cresce aos poucos. Você vê 1,8GB no início; uma semana depois, 3,5GB; mais alguns dias e passa de 4GB. Nesse ponto, o sistema começa a usar swap, ou seja, disco como memória, e a velocidade despenca.

Passei por isso. Meu VPS tinha 4GB e, no começo, funcionava bem. Duas semanas depois, o OpenClaw ficou muito lento. Rodei docker stats e o uso de memória já estava em 3,8GB; sobravam menos de 200MB no sistema. Reiniciei o contêiner e tudo voltou ao normal: memória de volta a 1,8GB.

Então, resposta lenta nem sempre é culpa do OpenClaw. Muitas vezes, a configuração do VPS é que está curta.

Análise de logs e monitoramento: deixe o OpenClaw sem esconderijo

O jeito certo de abrir logs do Docker

A pergunta é: como saber o que o OpenClaw está fazendo?

A resposta é simples: olhando os logs. Mas muita gente não sabe como olhar, ou olha e não entende.

Ver logs em tempo real

docker logs -f openclaw-gateway

Esse comando mostra os logs do OpenClaw continuamente, como se você estivesse encarando um painel. Envie uma mensagem e você verá como o OpenClaw processa, quais ferramentas chama e quantos tokens consome.

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

Ver os erros mais recentes

docker logs openclaw-gateway 2>&1 | tail -50

Esse comando mostra as últimas 50 linhas de log. Eu costumo usá-lo para localizar problemas rápido. O contêiner falhou ao iniciar? Comece pelas últimas 50 linhas; em 90% dos casos, a resposta está ali.

Identificadores de erro importantes

Alguns erros aparecem com muita frequência nos logs. Guarde estas palavras-chave para localizar a causa rápido:

• WebSocket Error 1008: autenticação expirada, limpe o cache do navegador
• No API key found for anthropic: problema na configuração da chave API
• Error: Address already in use: a porta já está ocupada
• FATAL ERROR: Reached heap limit: memória insuficiente, é hora de fazer upgrade

Uma vez, o OpenClaw parou de conectar e o log repetia WebSocket Error 1008. Depois de revirar a documentação, descobri que eu tinha ajustado o horário do sistema, invalidando o token de autenticação. Apaguei o localStorage do navegador e o problema sumiu na hora.

Ferramenta de monitoramento openclaw-telemetry

Se você quiser monitorar o OpenClaw de forma mais profissional, vale testar o openclaw-telemetry.

Ele registra todos os comandos, prompts e chamadas de ferramentas executados pelo OpenClaw. Os dados são coletados via syslog e também podem ser encaminhados para um sistema SIEM para auditoria de segurança. O mais importante: ele remove informações sensíveis automaticamente e protege a integridade dos logs com uma cadeia de hashes contra adulteração.

Sendo sincero, para usuário individual pode ser pesado demais. Mas se você usa OpenClaw em ambiente corporativo, ou precisa de trilha de auditoria, por exemplo ao lidar com dados de clientes, a ferramenta tem valor.

A instalação não é complicada e há documentação detalhada no GitHub. Eu mesmo não uso, porque para desenvolvimento pessoal não preciso, mas já vi equipes usando com bom retorno.

Comando de monitoramento de recursos

Quer saber quantos recursos o OpenClaw está consumindo? Um comando resolve:

docker stats openclaw-gateway

Ele mostra o uso de recursos do contêiner em tempo real:

CONTAINER ID   NAME               CPU %   MEM USAGE / LIMIT   MEM %   NET I/O
a1b2c3d4e5f6   openclaw-gateway   12.5%   1.85GB / 4GB       46.25%  15.2MB / 8.3MB

Preste atenção nestes indicadores:

• Uso de CPU: picos ocasionais de 80-100% são aceitáveis, porque indicam processamento; se ficar alto continuamente, há problema
• Uso de memória: é o indicador mais importante. Se ficar perto de 90% por muito tempo, faça upgrade
• Percentual de memória: acima de 80% já merece atenção; acima de 90%, pode cair a qualquer momento

Minha prática é olhar esse comando de vez em quando. Se a memória cresce continuamente, como 1,8GB ontem, 2,5GB hoje, 3,2GB amanhã, é sinal de vazamento de memória. A saída é reiniciar o contêiner ou resetar a sessão.

Uma vez, vi o uso de memória chegar a 3,6GB em um servidor de 4GB, mas o OpenClaw ainda funcionava. Pensei em aguentar mais um pouco. Na manhã seguinte, o contêiner tinha morrido, e o log estava cheio de erros Out of memory. Desde então, criei o hábito de reiniciar ativamente quando a memória passa de 3GB.

7 estratégias de otimização de desempenho: de 40% a 80% de economia

Estratégia 1: resetar sessões periodicamente, economizando 40-60%

Esta é a solução mais simples e mais efetiva.

Por que funciona?

Sempre que você reseta a sessão, o OpenClaw limpa o contexto acumulado. Histórico de conversa, saída de ferramentas, resultados intermediários: tudo volta a zero. A próxima conversa começa leve, sem carregar dezenas ou centenas de milhares de tokens antigos.

Como fazer?

Escolha uma das três formas:

# Método 1: reset pela linha de comando
openclaw "reset session"

# Método 2: apagar os arquivos de sessão diretamente
rm -rf ~/.openclaw/agents.main/sessions/*.jsonl

# Método 3: usar o comando embutido
# Digite na caixa de conversa do OpenClaw
/compact

Boas práticas

Meu hábito é resetar ao concluir cada tarefa independente. Terminou um artigo? Resete. Revisou um PR? Resete. Depurou um problema? Resete.

Assim, você usa sempre um OpenClaw “leve”: resposta rápida e custo baixo.

Alguém pode perguntar: resetar não perde o contexto? Sim. Mas, na maior parte das vezes, o contexto da tarefa anterior não ajuda na próxima. Os materiais que o OpenClaw leu para você escrever um blog ajudam em quê quando você vai depurar código? Em nada. Então por que deixar isso ocupando memória e consumindo token?

Dado real: antes eu gastava $347 em um mês. Depois de começar a resetar sessões periodicamente, o mês seguinte caiu para $195. Só essa mudança economizou mais de 40%.

Estratégia 2: isolar operações com saída grande, economizando 20-30%

Algumas operações geram muita saída: ver logs completos, exportar configurações, analisar datasets grandes. Quando essa saída entra na sessão principal, ela gruda em você, e cada conversa seguinte paga por ela.

Solução: use uma sessão separada

# Ver uma configuração grande em uma sessão debug isolada
openclaw --session debug "show full system config"

# Depois de ver, copie só as informações importantes
# Em seguida, volte para a sessão principal

É como separar lixo grande do lixo comum. Não enfie tudo no mesmo cesto diário.

Cenário real

Uma vez, precisei que o OpenClaw analisasse um log de erro de 300 linhas. Se eu colasse direto na sessão principal, essas 300 linhas ficariam ali para sempre. Fiz assim:

1. Abri uma sessão temporária com --session analyze-log
2. Colei o log e pedi análise ao OpenClaw
3. Ele concluiu: há uma exceção de ponteiro nulo na linha 127
4. Copiei essa conclusão para a sessão principal
5. Fechei a sessão debug; as 300 linhas não contaminaram o contexto principal

Essa estratégia dá um pouco mais de trabalho, mas economiza de verdade, principalmente se você lida com arquivos grandes e logs longos com frequência.

Estratégia 3: alternância inteligente de modelos, economizando 50-80%

Essa estratégia tem o maior impacto, mas muita gente nem percebe que pode fazer isso.

O Claude tem três modelos principais:

• Haiku: barato e rápido, bom para tarefas simples
• Sonnet: equilíbrio entre desempenho e custo
• Opus: mais poderoso, mas muito mais caro; custa cerca de 15 vezes mais que Haiku

O problema é que muita gente usa Opus para tudo por comodidade. É como pegar um avião para qualquer deslocamento: ir ao mercado, ir ao trabalho, tudo de avião. Chega, mas não precisa.

Princípio de classificação de tarefas

Minha divisão é:

Use Haiku para:

• Conversão de formato, como JSON para YAML ou Markdown para HTML
• Consulta de informação, como “Que linguagem é este trecho?”
• Perguntas simples, como “O que significa este erro?”
• Extração de texto, como “liste todos os nomes de funções neste trecho”

Use Sonnet para:

• Revisão de código, procurando falhas lógicas e problemas de desempenho
• Criação de conteúdo, como artigos e documentação
• Análise técnica, como arquitetura e avaliação de soluções

Use Opus para:

• Desenho de arquitetura de um sistema inteiro
• Refatoração complexa em larga escala
• Decisões críticas, como escolha tecnológica e avaliação de riscos

Exemplo de configuração

{
  "defaultModel": "claude-3-haiku",
  "complexTaskModel": "claude-3-5-sonnet",
  "triggerKeywords": ["análise", "refatoração", "arquitetura", "design"]
}

Minha prática é definir Haiku como padrão e só trocar manualmente quando a tarefa é complexa. Com isso, 80% das operações usam o modelo barato, e o custo cai rápido.

Resultado real: combinando com a estratégia 1, reset de sessão, meu custo mensal caiu de $195 para $68. Só a troca de modelo economizou quase 65%.

Estratégia 4: otimização de cache, economizando 30-50%

A Claude API tem um mecanismo de cache: se você envia prompts iguais ou parecidos em sequência, a API pode reaproveitar partes e cobrar menos nas próximas chamadas.

Como aproveitar cache?

1. Ative prompt caching, que já vem ligado na maioria das versões do OpenClaw
2. Reduza temperature para cerca de 0.2, deixando a saída mais estável e mais fácil de acertar cache
3. Configure heartbeat para manter o cache aquecido, mas sem exagero; recomendo uma vez a cada 5-10 minutos

{
  "temperature": 0.2,
  "enablePromptCaching": true,
  "heartbeatInterval": 300000
}

4. Use serviços intermediários com suporte a cache, se fizer sentido; alguns gateways de API de terceiros adicionam otimizações próprias

Efeito real

O maior ganho do cache é que o system prompt, de 5K-10K tokens, só é cobrado uma vez durante a validade do cache. Se você faz 10 requisições em uma hora, antes pagava o system prompt 10 vezes; agora, paga 1.

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

Esse ganho varia. Se você usa OpenClaw poucas vezes por dia, o cache expira com frequência e o efeito é pequeno. Se você usa muito, com dezenas de conversas por dia, o cache pode economizar 30-50%.

Estratégia 5: limitar a janela de contexto, economizando 20-40%

O OpenClaw aceita por padrão uma janela de contexto de 400K tokens. Parece ótimo, certo? O problema é que, quanto maior a janela, mais fácil é enchê-la sem perceber.

É como ganhar uma mochila grande: você acaba colocando mais coisas. Com uma mochila menor, você naturalmente simplifica.

Configuração

{
  "maxContextTokens": 100000
}

Por que funciona?

Depois de limitar a janela de contexto, o OpenClaw força limpezas mais frequentes. Quando o contexto se aproxima do limite, ele sugere resetar ou resumir. Assim, você não arrasta dezenas de rodadas de histórico.

Além disso, 100K é suficiente para a maioria das tarefas. A menos que você esteja fazendo uma refatoração enorme ou analisando milhares de linhas de código, 400K quase nunca é necessário.

Cuidados

Limitar demais tem efeito colateral. Se a tarefa realmente precisa de muito contexto, como analisar a arquitetura de um projeto inteiro, uma janela pequena pode fazer o OpenClaw “esquecer” o panorama.

Minha recomendação:

• Uso diário: 50K-100K
• Tarefas complexas: 200K
• Projetos gigantes: mantenha o padrão de 400K

Para mim, 100K é o ponto ideal: economiza dinheiro sem piorar a experiência.

Estratégia 6: usar modelos locais, economizando 60-80%

Se você aceita mexer um pouco mais, esse método pode zerar o custo de algumas tarefas.

Ideia básica

Com Ollama, configure um modelo local, como Llama ou Mistral, para que o OpenClaw envie tarefas simples ao modelo local. Assim você não chama a Claude API e não paga por essas tarefas.

Cenários adequados

• Conversão de formato, como JSON, YAML e Markdown
• Consultas simples, como “liste todos os comentários TODO”
• Extração de informação específica de um texto

Cenários inadequados

• Revisão de código, porque modelos locais costumam ficar abaixo do Claude
• Conteúdo criativo, como artigos e documentação, onde o Claude ainda é mais confiável
• Raciocínio complexo, como arquitetura e análise técnica

Exemplo de configuração

# Instale o Ollama e baixe o modelo
ollama pull llama3.2

# Configure o OpenClaw para usar modelo local em tarefas simples
{
  "localModel": "llama3.2",
  "localModelTasks": ["format", "extract", "simple-query"]
}

Experiência real

Para ser honesto, configurar modelo local dá trabalho, e a qualidade é menor que a do Claude. Testei modelos locais para conversão de formato; em 10 tentativas, 2 ou 3 saíam erradas e precisavam de correção manual.

Mas, se o orçamento estiver apertado ou se você tiver muitas tarefas simples e repetitivas, vale testar. Pelo menos essa parte do custo pode cair 60-80%.

Estratégia 7: desativar Skills e ferramentas desnecessárias

O OpenClaw suporta várias Skills: automação de navegador, operações de arquivo, execução de código e por aí vai. O problema é que cada Skill ativada ocupa contexto, porque as instruções de uso da ferramenta são enviadas à API. Em modelos menores, isso fica ainda mais evidente.

Revise as Skills ativadas

Olhe sua configuração do OpenClaw. Há um monte de ferramentas que você nunca usa? Automação de navegador? Quando foi a última vez que usou? Integração com Gmail? Você realmente precisa que o OpenClaw envie e-mail?

Estratégia de otimização

Ative só o que você usa de verdade. Na minha configuração, mantenho apenas:

• Leitura e escrita de arquivos, indispensável
• Operações Git, que uso com frequência
• Execução de comandos Bash, necessária para debug

Automação de navegador, agenda e integração de e-mail ficam desativadas. Com isso, o system prompt fica alguns milhares de tokens menor a cada requisição.

Exemplo de configuração

{
  "enabledSkills": [
    "file-operations",
    "git",
    "bash"
  ],
  "disabledSkills": [
    "browser-automation",
    "gmail",
    "calendar"
  ]
}

Sozinha, essa otimização não muda tudo, talvez 10-15%. Mas combinada com as outras, soma bastante.

Tabela rápida de falhas comuns: resolva 90% dos problemas em 5 minutos

Quando algo quebrar, não entre em pânico. Esta tabela ajuda a localizar e corrigir a maioria dos problemas comuns.

Algumas dicas práticas:

Dica 1: solução definitiva para problemas de WebSocket

Se limpar o localStorage não resolver, tente isto:

# Desative pareamento de dispositivo em ambiente Docker, apenas para rede interna
docker run -e OPENCLAW_DISABLE_DEVICE_PAIRING=true openclaw/openclaw

Dica 2: decidir rápido se é memória ou rede

# Monitorar vários indicadores ao mesmo tempo
watch -n 1 'docker stats openclaw-gateway --no-stream && curl -s https://api.anthropic.com'

Se a memória está estável, mas a resposta é lenta, talvez seja rede. Se a memória dispara, falta recurso.

Dica 3: logs demais e nenhuma pista?

# Ver apenas erros e avisos
docker logs openclaw-gateway 2>&1 | grep -E "ERROR|WARN|FATAL"

Eu já depurei um problema com milhares de linhas de log. Depois de filtrar com esse comando, encontrei o ERROR principal na hora: a API key tinha expirado.

Ajuste avançado: faça o OpenClaw render mais

Se você já aplicou as otimizações básicas e quer extrair mais desempenho, esta parte é para você.

Gerenciamento avançado de contexto

Triangulação de contexto (Context Triangulation)

Não coloque o arquivo inteiro dentro do OpenClaw. Injete só os trechos relevantes para a tarefa. Por exemplo, se você precisa alterar uma função, basta fornecer:

• O código dessa função
• As assinaturas das funções que ela chama
• As definições de tipos relacionadas

Isso pode reduzir o contexto em 70-80%.

Arquitetura de âncoras globais em camadas (TGAA)

Mantenha um ARCHITECTURE.md na raiz do projeto, registrando o desenho de alto nível do sistema. Quando precisar de visão global, peça ao OpenClaw para ler esse arquivo, não para varrer a codebase inteira.

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Minha prática é colocar um README.md em cada diretório de módulo, explicando brevemente o papel daquele módulo. Quando o OpenClaw precisa entender a estrutura do projeto, ler esses READMEs basta; não precisa carregar todo o código-fonte.

Carregamento dinâmico de ferramentas

Não carregue todas as definições de ferramentas no começo. Injete sob demanda: só carregue ferramentas de arquivo quando for mexer em arquivos; só carregue Git quando precisar de Git.

Isso exige mexer na configuração do OpenClaw e tem um pouco mais de barreira técnica, mas reduz cerca de 30% do custo do system prompt.

Atualização de memória pré-compactada

Antes de resumir ou resetar a sessão, peça ao OpenClaw para escrever as informações importantes em MEMORY.md. Depois do reset, a nova sessão só precisa ler esse arquivo enxuto para continuar.

# Salve as informações importantes antes do resumo
openclaw "Escreva as decisões importantes e pendências que discutimos em MEMORY.md"

# Depois resete a sessão
openclaw "reset session"

# No início da nova sessão, leia a memória
openclaw "Leia MEMORY.md e continue o trabalho anterior"

Reforço de segurança com Docker

Em janeiro de 2026, a empresa de segurança Bitdefender divulgou a vulnerabilidade CVE-2026-25253 e encontrou centenas de instâncias OpenClaw vazando chaves API e dados sensíveis por configuração incorreta. A falha já foi corrigida, mas o recado permanece: configuração de segurança importa.

Rodar sem root

services:
  openclaw-gateway:
    user: "1000:1000"  # use um usuário sem privilégios

Princípio do menor privilégio

docker run \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  --read-only \
  --tmpfs /tmp \
  openclaw/openclaw

Isolamento de rede

Se o OpenClaw não precisa acessar a internet, por exemplo quando você o usa só para lidar com arquivos locais, isole a rede completamente:

services:
  openclaw-gateway:
    network_mode: none

Precisa de internet, mas quer restringir o destino? Configure um proxy com whitelist.

Proteção de variáveis de ambiente

Não escreva a API key em texto puro dentro do docker-compose.yml. Use um arquivo de variáveis:

services:
  openclaw-gateway:
    env_file:
      - .env  # conteúdo do arquivo: ANTHROPIC_API_KEY=sk-xxx

Lembre de colocar .env no .gitignore. Não mande a chave para o GitHub sem querer.

Boas práticas em produção

Rotação de logs para evitar disco cheio

services:
  openclaw-gateway:
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

Assim os logs ocupam no máximo 30MB e não crescem sem limite.

Atualização periódica

O OpenClaw muda com frequência e costuma trazer melhorias de desempenho e correções de segurança. Confira a versão uma vez por mês:

docker pull openclaw/openclaw:latest
docker compose up -d

Monitoramento e alertas

Um script simples já monitora recursos:

#!/bin/bash
MEM_PERCENT=$(docker stats openclaw-gateway --no-stream --format "{{.MemPerc}}" | sed 's/%//')
if (( $(echo "$MEM_PERCENT > 85" | bc -l) )); then
    # Envie um alerta, por e-mail, Webhook etc.
    echo "Uso de memória do OpenClaw acima de 85%!" | mail -s "Alerta do OpenClaw" [email protected]
fi

Coloque no cron para rodar uma vez por hora.

Use VPN ou Tailscale em vez de expor à internet

Se você acessa o OpenClaw remotamente, não exponha a porta diretamente na internet. Use Tailscale para criar uma rede privada: é mais seguro e mais prático.

# Instalar Tailscale
curl -fsSL https://tailscale.com/install.sh | sh

# Iniciar e autenticar
sudo tailscale up

# Agora é possível acessar o OpenClaw pela rede Tailscale, sem IP público

É assim que configuro o meu. Em cafeteria ou aeroporto, ainda consigo acessar com segurança a instância do OpenClaw que está em casa.

Conclusão

De $347 para $68. De 23 segundos de resposta para 4. Esses números não são enfeite; são o efeito real da otimização.

Olhando para trás, o problema de desempenho do OpenClaw não é tão complicado. Ele se resume a três coisas:

1. Controlar contexto: não deixe acumular sem limite
2. Escolher o modelo certo: tarefas simples usam modelo barato
3. Monitorar recursos: descubra falta de memória cedo

Você não precisa aplicar as 7 estratégias de uma vez. Minha sugestão:

• Faça agora: verifique o uso atual de memória com docker stats; se não houver 4GB, faça upgrade
• Conclua nesta semana: configure alternância inteligente de modelo, com Haiku por padrão, e ative cache com temperature em 0.2
• Crie o hábito: resete a sessão com /compact ao concluir cada tarefa

Com esses três passos, o custo tende a cair pelo menos 50%.

Para fechar: OpenClaw é uma boa ferramenta, mas ainda é só uma ferramenta. O quanto ela funciona bem depende muito de como você a usa. Investir um pouco de tempo para entender seu funcionamento, configurar recursos adequados e criar bons hábitos de uso volta em forma de velocidade e economia.

Quando algo quebrar, não entre em pânico. Veja os logs, consulte a tabela rápida deste artigo; 90% dos problemas se resolvem em 5 minutos. Se ainda não der, as GitHub Issues do OpenClaw têm bastante gente da comunidade ajudando.

Que seu OpenClaw rode rápido e gaste pouco.