Eu Matei Meu OpenClaw — Construí a Memória, o Gateway, os Patches. Então Chegou a Conta de Tokens.

O Que Eu Realmente Construi

Entre março e abril de 2026, eu enviei 3 projetos em torno do ecossistema OpenClaw. Não forks. Trabalho original.

1. Engram — Memória Consciente de Escopo para IA Multi-Agente

Repo: lofder/Engram

O problema com a memória do OpenClaw era simples: ela é baseada em arquivos. Você escreve um SOUL.md, você manualmente curadoria habilidades como arquivos markdown, e a IA carrega tudo no contexto toda vez. Mais memórias = mais tokens = mais dinheiro. E nada é limpo automaticamente.

Eu construí o Engram como a solução. É uma arquitetura de memória completa alimentada por Mem0 + Qdrant + MCP:

• Memória escopo — global, group:project-x, dm, agent:coder. Diferentes pools de memória para diferentes contextos. Suas preferências de codificação não poluem a memória do agente de e-mail.
• 7 tipos de memória — preference, fact, procedure, lesson, decision, task_log, knowledge. Não apenas "lembre-se disso" — categorias estruturadas que o sistema de recuperação pode filtrar.
• Auto-limpeza — duplicatas se fundem automaticamente. Antigos registros de tarefas são resumidos em conhecimento compacto. Entradas obsoletas desaparecem. A IA gerencia sua própria memória em vez de você manter arquivos.
• Lógica de esquecimento — esta é a parte que ninguém mais faz. Lembrar é fácil. Saber o que esquecer é o problema difícil. O Engram rastreia a idade da memória, frequência de acesso e decadência de relevância. Um registro de tarefa de 3 semanas atrás que nunca foi lembrado novamente? Ele é comprimido em um resumo de uma linha, e então eventualmente descartado. Uma preferência que você declarou no dia 1 que é lembrada a cada sessão? Ela permanece para sempre. A IA não apenas acumula — ela curadoria. Sem isso, cada sistema de memória eventualmente se afoga em seu próprio contexto, e você volta a pagar por 12K tokens de história obsoleta em cada solicitação.
• Pontuação de confiança — alta / média / baixa. Preferências declaradas pelo usuário têm alta confiança. Inferências da IA têm baixa confiança. Quando as memórias entram em conflito, a confiança quebra o empate.
• 5 ferramentas MCP — mem0_add, mem0_recall, mem0_search, mem0_delete, mem0_compact. Qualquer cliente compatível com MCP pode chamá-las.

A filosofia de design:

OpenClaw:  Você escreve rules.md → IA lê isso → você atualiza rules.md → repete para sempre
Engram:    IA lembra por conta própria → comprime ao longo do tempo → você nunca mantém um arquivo

Quando o Hermes Agent foi lançado com "memória procedural auto-melhorável" como seu recurso principal, eu tive um momento. Porque o Engram já fazia isso — e mais. O Hermes armazena habilidades como arquivos markdown e usa a sumarização LLM para compressão. Ele lembra, mas não esquece. Não há decadência, não há ciclo de vida, não há "esta memória tem 3 semanas e nunca foi útil — descarte-a." O Engram tem categorias de memória tipadas, recuperação semântica baseada em vetores, pontuação de confiança, isolamento de escopo, lógica de esquecimento e gerenciamento automático de ciclo de vida.

Mas o Engram rodava no OpenClaw. E o OpenClaw rodava em tokens. E os tokens rodavam em dinheiro que eu não tinha.

2. Durable Gateway Runtime — Arquitetura Multi-Canal

Repo: lofder/durable-gateway-runtime

O gateway do OpenClaw é seu núcleo — o processo Node.js de longa duração que conecta WhatsApp, Telegram, Slack, etc. à IA. Mas os documentos de arquitetura estavam espalhados, e o modelo de execução tinha lacunas quando você tentava escalar além de uma única instância.

Eu escrevi um documento de arquitetura completo para um gateway multi-canal e modelo de execução:

• Normalização de entrada — como padronizar mensagens de diferentes plataformas em um formato unificado
• Esqueleto de execução — a fila de tarefas, montagem de contexto e pipeline de execução de ferramentas
• Durabilidade de estado — como persistir o estado da conversa entre reinicializações sem perder o contexto
• Roteamento de canal — como rotear diferentes grupos/usuários para instâncias de agente isoladas

Isso deveria ser o guia "como realmente executar o OpenClaw em produção". Não apenas npm start no seu laptop — implantação real multi-inquilino, recuperável de falhas.

Eu nunca terminei a implementação. Os documentos de arquitetura são públicos. O código é experimental. A razão pela qual eu parei? A mesma de tudo o mais: tokens.

3. Gateway Stability Patch — Kit de Ferramentas de Hotfix de Produção

Repo: lofder/openclaw-gateway-stability-patch

Este veio da dor. Eu estava rodando o OpenClaw com múltiplos canais, e o gateway continuava travando. Corridas de handshake do WebSocket. Desvio de tempo limite de conexão-desafio. Fechamentos de pré-conexão que eram recuperáveis, mas que não estavam realmente sendo recuperados.

Então eu construí um kit de ferramentas de sobreposição adequado:

• Patches baseados em regras — tempo limite de handshake configurável, tempo limite de conexão-desafio, tentativa limitada para falhas de loopback
• CLI de aplicar/verificar/desfazer — não "edite o arquivo e espere." Um fluxo de trabalho adequado com backups, manifestos e verificações de integridade
• Estrito em versão — se recusa a aplicar patches se a versão de execução não corresponder. Sem quebras silenciosas
• Idempotente — execute apply duas vezes, obtenha o mesmo resultado. Sem patches duplicados se acumulando

Puro Python, zero dependências, licenciado sob MIT. É o tipo de trabalho de infraestrutura entediante que ninguém estrela no GitHub, mas que todo mundo precisa em produção.

A Conta de Tokens Que Matou Tudo

Deixe-me contar como é assistir o dinheiro evaporar.

Você constrói algo do qual se orgulha. O Engram está funcionando. O gateway está estável (graças aos seus próprios patches). Três canais estão conectados. Você vai para a cama pensando "isso finalmente está funcionando."

Você acorda. Verifica o painel da API.

$14.37 durante a noite. Enquanto você dormia.

Seu agente estava vivo. Batendo o coração. Verificando tarefas a cada 5 minutos — 288 chamadas de API durante a noite. Cada uma carregando todo o histórico de conversas + prompt do sistema + todas as habilidades carregadas + memórias do Engram no contexto. Mesmo quando não havia literalmente nada a fazer, cada "nada a fazer" custava tokens. Sua IA estava acordada às 3 da manhã, gastando seu dinheiro para confirmar que ninguém havia enviado uma mensagem para ela.

Esse foi o momento em que comecei a fazer contas que não queria fazer.

Por Que o OpenClaw Consome Tokens Como Se Estivesse Faminto

A arquitetura do OpenClaw é fundamentalmente, estruturalmente, por design faminta por tokens. Não é um bug. É assim que funciona.

Carregamento de contexto — o assassino silencioso. Cada solicitação envia o HISTÓRICO COMPLETO da conversa + prompt do sistema + habilidades carregadas + memória. Não um resumo. Não as partes relevantes. Tudo. Uma conversa de 20 mensagens com 3 habilidades carregadas consome de 8K a 12K tokens por solicitação — apenas para contexto, antes que a IA pense um único pensamento. E os tokens de contexto contam em cada solicitação. Então a mensagem #21 paga por todas as 20 mensagens anteriores novamente. E novamente. E novamente.

Batimento cardíaco — pagando para respirar. O OpenClaw verifica tarefas agendadas periodicamente. Cada batimento é uma chamada de API completa com carregamento de contexto completo. Mesmo "nada a fazer" custa tokens. No intervalo padrão de 5 minutos: