nullClaw, em Zig, supera o OpenClaw em memória e inicialização em testes locais de agentes de IA

O NullClaw, um runtime de agentes escrito em Zig e distribuído em um único binário, mostra que um agente de IA local não precisa arrastar uma pilha pesada. Nos testes comparativos com o OpenClaw, o projeto iniciou mais rápido e consumiu uma ordem de grandeza menos memória, principalmente em tarefas paralelas.

Por que Zig

A ideia central do artigo não é declarar o NullClaw o vencedor absoluto entre todas as plataformas de agentes. O autor o compara com o OpenClaw apenas em cenários locais curtos: comandos de serviço, uma execução de agente, uma tarefa pequena de programação e um lote de execuções paralelas.

Nesse contexto, fica evidente quanto custa hoje um agente de IA comum como processo. A maioria desses sistemas tem por baixo Node.js, Python, dependências, serviços em segundo plano e uma camada de gateway. O NullClaw propõe outra abordagem: um runtime o mais compacto possível, sem acessórios desnecessários.

Daí a escolha do Zig. A linguagem está aqui não por modismo, mas por objetividade de engenharia: um binário, controle explícito de memória, ausência de um runtime gerenciado pesado e um build mais compreensível. Em `build.zig`, o autor destaca separadamente chaves em tempo de compilação para canais e engines de memória, ou seja, o build pode ser enxugado para um cenário específico. Isso importa não só para a velocidade de inicialização, mas também para implantações self-hosted e edge, onde cada megabyte extra e cada dependência rapidamente viram um problema prático.

Os números, sem ruído

As medições foram feitas em um Mac mini M4 com 16 GB de RAM e macOS arm64. Os dois projetos usaram o mesmo modelo via OpenRouter, e as métricas foram calculadas em séries de execuções: separadamente para processos «novos», para cenários warm, e para execuções de programação e tarefas paralelas. O autor separa de propósito o overhead puro do runtime da latência de rede até o modelo, porque, no segundo caso, mesmo um runtime muito leve esbarra no round-trip externo.

• comando `--help`: NullClaw — 0,002 s e cerca de 1,9 MB de RSS, OpenClaw — 0,621 s e cerca de 308 MB
• execução curta de agente: 2,55 s e aproximadamente 7,7 MB contra 3,37 s e aproximadamente 567 MB
• execução pequena de programação: 4,86 s e aproximadamente 7,7 MB contra 6,64 s e aproximadamente 572 MB
• 10 tarefas de programação em paralelo: 9,3 s e cerca de 54 MB de RSS total contra 13,14 s e cerca de 523 MB

A maior diferença está na memória. No tempo, o NullClaw costuma ser mais rápido, mas nem sempre de forma dramática, porque parte dos cenários é limitada pela resposta de rede do modelo. Nas execuções curtas e paralelas, o OpenClaw fica de forma estável na casa das centenas de megabytes, enquanto o NullClaw fica na casa das unidades ou dezenas. Para o uso local, isso significa um lançamento multiagente mais barato, uma carga mais previsível e menos atrito ao mover o software entre máquinas.

O sentido prático da comparação

O artigo traz ainda um exemplo mais revelador do que tabelas secas: o ClawWatch, projeto para smartwatches. Ele usa o NullClaw como binário ARM estático, junto com reconhecimento de voz offline Vosk e TTS embutido, e pode processar parte das solicitações sem recorrer ao modelo. Aqui a compactação deixa de ser uma simples otimização agradável. Para um dispositivo com limite rígido de memória, a diferença entre alguns megabytes e centenas de megabytes determina se é possível embarcar o agente em um produto, e não apenas rodá-lo no notebook de um desenvolvedor.

«No relógio, a diferença entre “alguns megabytes” e “centenas de

megabytes” é a pergunta de se isso chega a ser embarcável».

O autor ressalva ainda que não há mágica no tamanho do binário. O README declara 678 KB para ReleaseSmall, mas os artefatos de release publicados são bem maiores: cerca de 3,9 MB para macOS arm64 e 3,1 MB para Linux arm64, enquanto um build local deu aproximadamente 2,6 MB. Mas a conclusão principal não muda: o valor do NullClaw não está no número recorde do README, e sim na combinação de inicialização rápida, RSS pequeno e uma superfície funcional estreita, mais fácil de controlar tanto na operação quanto na segurança.

O que isso significa

O NullClaw traz a conversa sobre agentes de IA de volta a uma pergunta terrena: quanto deveria custar a execução de um processo. Se a infraestrutura de agentes caminhar para edge, self-hosted e tarefas paralelas em massa, vão se dar bem os runtimes que economizam memória, iniciam sem pausa e não arrastam consigo meio servidor de dependências.