OpenClaw se mostrou um agente autônomo caro: 81 milhões de tokens e conflitos com o servidor

OpenClaw parece ser um agente de IA universal que pode ser rapidamente implantado em seu próprio servidor e integrado em fluxos de trabalho familiares. Mas a experiência pessoal de instalação mostrou o oposto: o agente entra facilmente em conflito com serviços vizinhos, é exigente quanto a modelos e hardware, e o consumo de tokens rapidamente sai do controle.

Monstro no Servidor

O autor começou com um cenário típico: pegou um VDS funcionando onde havia sites em React, PostgreSQL, n8n e vários bots Telegram simples, e implantou OpenClaw lá. O primeiro problema surgiu quase imediatamente após um erro de configuração do token Telegram. Em vez de uma reinstalação indolor, o sistema deixou "resquícios" no systemd, configurações e na pasta `.openclaw`. Parâmetros antigos continuavam afetando novas execuções, então a abordagem familiar de "deletei e reinstalei" simplesmente não funcionou.

Depois ficou claro que OpenClaw não se sente bem como vizinho em um servidor já ocupado. Requer portas livres, ambiente limpo e configuração previsível. Descobrir o que exatamente quebrava a instalação levou horas de correspondência com outras ferramentas de IA e cerca de um milhão de tokens apenas para diagnóstico.

A conclusão principal aqui é simples: implantar OpenClaw em um servidor de produção com serviços já em funcionamento é uma má ideia. Precisa de um circuito separado, caso contrário a depuração rapidamente se transforma em limpeza manual e reinstalações intermináveis.

Não Gosta de Orquestradores

O próximo passo parecia lógico: transformar OpenClaw em uma das ferramentas dentro de uma configuração já configurada com Docker, PostgreSQL e n8n. A ideia era clara — chamar o agente através de webhooks, habilidades ou scripts e integrá-lo em cadeias existentes. Mas em vez de um componente subordinado, OpenClaw se comportou como um sistema autônomo que não quer seguir as regras de alguém e lida mal com controle externo.

Mesmo quando a solicitação chegava formalmente, não se transformava em uma resposta normal para o cenário.

• MCP exigia um token dinâmico que o orquestrador não conseguia obter
• Webhooks aceitavam solicitações mas não as passavam ao agente em si
• A invocação direta de script Python iniciava o comando mas não retornava o resultado
• Criar sua própria habilidade esbarrava em erro de autenticação

Em vez de um executor de tarefas flexível, emergiu um "diretor" autossuficiente que relutantemente se integra em processos externos. O autor o chama de ninja: o agente recebe uma tarefa, desaparece nas sombras e age por si só. Para trabalho solo isto pode ser um plus, mas para integrações tal autonomia rapidamente se torna um problema. Se você precisa de um módulo silencioso dentro de uma grande orquestra, OpenClaw é mais um obstáculo do que uma ajuda.

Em outras palavras, a força do agente se mostrou ser sua principal limitação.

"OpenClaw não é um assistente. É um ninja."

Hardware e Tokens

Outra surpresa desagradável surgiu ao conectar modelos locais através do Ollama. Opções leves como `phi3:mini`, `gemma2:2b` e `gemma3:4b` não se encaixavam porque não suportam tools ou function calling, sem os quais o agente não consegue funcionar adequadamente.

Modelos compatíveis foram encontrados, mas já em um peso diferente: `qwen2.5:7b`, `llama3.1:8b` e soluções similares exigem notavelmente mais recursos. Em um VDS com 32 GB de RAM, as respostas levavam de cinco a dez minutos cada, e a execução paralela de outros serviços levava a erros de memória.

Disso brotou o segundo nível de custos. Para operação local estável do OpenClaw, segundo a avaliação do autor, você precisa de um servidor separado com GPU como V100 ou RTX 4090 e pelo menos 12 GB de VRAM, o que já é dezenas de milhares de rublos por mês em aluguel. Tentar escapar deste problema via API também não ajudou.

Os 5 milhões de tokens comprados da DeepSeek foram consumidos pelo agente em uma noite praticamente sem tarefas úteis: verificou modelos, percorreu perfis, cometeu erros e acionou a API novamente. Após mudar para OpenRouter, três sessões ao longo de poucas horas queimaram mais 76 milhões de tokens.

No total durante três dias, o consumo chegou a aproximadamente 81 milhões de tokens, com uma porção significativa indo não para texto para o usuário, mas para verificações internas e chamadas repetidas de API.

O Que Isto Significa

OpenClaw parece não ser "mais um bot" mas uma camada autônoma pesada entre o modelo e ações reais em navegadores, messengers e outros serviços. Para entusiastas isto pode ser justificado se você precisa de um agente que trabalhe por conta própria.

Mas a promessa de "implante e esqueça" não funciona aqui: sem um ambiente dedicado, modelos compatíveis, monitoramento e um orçamento claro, o projeto rapidamente muda da categoria de experimento para um item permanente de despesas.