Zig-based nullClaw beats OpenClaw on memory and startup in local AI agent tests

NullClaw, an agent runtime written in Zig and shipped as a single binary, shows that a local AI agent does not have to drag a heavy stack along with it. In comparative tests against OpenClaw, the project started faster and used an order of magnitude less memory, especially in parallel tasks.

Why Zig

The article's main point is not to declare NullClaw the absolute winner among all agent platforms. The author compares it with OpenClaw only in short local scenarios: utility commands, a single agent run, a small coding task and a batch of parallel runs.

Against that backdrop, it is clear how expensive an ordinary AI agent is today as a process. Most such systems have Node.js, Python, dependencies, background services and a gateway layer under the hood. NullClaw takes a different approach: a maximally compact runtime without extra plumbing.

Hence the choice of Zig. The language is here not for fashion but for engineering directness: one binary, explicit memory control, no heavy managed runtime and a more transparent build. In `build.zig`, the author separately points out compile-time switches for channels and memory engines, which means the build can be narrowed to a specific scenario. This matters not only for startup speed but also for self-hosted and edge deployments, where every extra megabyte and every dependency quickly becomes a practical problem.

The numbers, without the noise

The measurements were taken on a Mac mini M4 with 16 GB of RAM running macOS arm64. Both projects used the same model via OpenRouter, and metrics were computed over series of runs: separately for fresh processes, for warm scenarios, and for coding runs and parallel tasks. The author deliberately separates pure runtime overhead from network latency to the model, because in the latter case even a very light runtime still hits the external round trip.

• `--help` command: NullClaw — 0.002 s and about 1.9 MB RSS, OpenClaw — 0.621 s and about 308 MB
• short agent run: 2.55 s and roughly 7.7 MB versus 3.37 s and roughly 567 MB
• small coding run: 4.86 s and roughly 7.7 MB versus 6.64 s and roughly 572 MB
• 10 parallel coding tasks: 9.3 s and about 54 MB total RSS versus 13.14 s and about 523 MB

The biggest difference is in memory. On time, NullClaw is more often faster, but not always dramatically, because some scenarios are limited by the model's network response. In short and parallel runs, OpenClaw consistently stays in the hundreds of megabytes, while NullClaw stays in the single or double digits. For local use, that means cheaper multi-agent launches, more predictable load and less friction when moving between machines.

What the comparison means in practice

The article also offers a more telling example than dry tables: ClawWatch, a project for smartwatches. It uses NullClaw as a static ARM binary together with offline Vosk speech recognition and built-in TTS, and it can handle some requests without calling a model. Here compactness stops being a nice optimization. For a device with a hard memory limit, the difference between a few megabytes and hundreds of megabytes determines whether the agent can be embedded in a product at all, rather than just run on a developer's laptop.

"On a watch, the difference between 'a few megabytes' and 'hundreds of

megabytes' is a question of whether it can be embedded at all."

The author also notes that there is no magic in the binary size. The README claims 678 KB for ReleaseSmall, but the published release artifacts are noticeably larger: about 3.9 MB for macOS arm64 and 3.1 MB for Linux arm64, while a local build came to roughly 2.6 MB. The main conclusion still holds: NullClaw's value lies not in the record figure from the README but in the combination of fast startup, small RSS and a narrow functional surface that is easier to control both operationally and from a security standpoint.

What this means

NullClaw brings the AI agent conversation back to a down-to-earth question: how much should a single process launch cost? If agent infrastructure moves toward edge, self-hosted and massively parallel workloads, the winners will be runtimes that save memory, start without a pause and do not haul half a server's worth of dependencies behind them.