NullClaw: a 678 KB Zig AI assistant that boots in under 2 ms
Fastest, smallest, and fully autonomous AI assistant infrastructure written in Zig
At a glance
- What is it?
- NullClaw ships as a single static Zig binary with a vtable-based plugin architecture and a Docker Compose stack. Here is what the repository actually documents, and where it runs out of detail.
- Who is it for?
- Adopt NullClaw if you want an assistant runtime that fits on a $5 board, boots in milliseconds, and exposes providers, channels, tools and memory as swappable vtables you can implement yourself. Do not adopt it if you need a mature configuration reference: the README points at docs/en/configuration.md rather than inlining the schema, and the Dockerfile's config stage writes a single default model entry, so anything beyond that is on you to verify.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 59 days ago.
- What is it written in?
- Mainly Zig, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem NullClaw targets: assistant runtimes that assume a server
Most self-hosted AI assistant stacks bring a language runtime with them. The README's own comparison table puts OpenClaw at over 1 GB of RAM and NanoBot at over 100 MB, with NullClaw listed at roughly 1 MB peak RSS and a 678 KB binary. Those numbers come from a local macOS arm64 benchmark the README says was run in February 2026 and then normalized for a 0.8 GHz edge core, so treat them as the project's own measurement rather than an independent one.
The audience follows from that. If you are deploying on a $5 board, an ARM SBC, or a device where a Node or Python runtime is the largest thing on disk, the runtime itself is the problem, not the model. NullClaw is written in Zig and compiles to a static binary the README says requires nothing but libc. The trade-off is real: you get a small artifact, and in exchange you are working with a much smaller ecosystem of people who can read the source when something breaks.
Vtables all the way down: how NullClaw is put together
The README describes the core systems as vtable interfaces: providers, channels, tools, memory engines, tunnels, peripherals, observers and runtimes. That is the architectural claim worth taking seriously, because it explains the feature counts. 50+ providers and 19 channels are not 69 hand-written integrations; they are implementations of a small number of interfaces, and the repository ships an examples/external-channel-template/ directory so you can add one without forking.
Provider support is OpenAI-compatible, which is the pragmatic choice. Any endpoint that speaks that shape works, and custom endpoints are pluggable. The repository layout backs this up: config.example.json at the top level, a spec/ directory, and a vendor/ directory containing sqlite3, which suggests SQLite is available to the memory engines rather than each engine bringing its own storage.
The Dockerfile confirms the build path. It uses a two-stage build, compiling on the runner architecture with --platform=$BUILDPLATFORM and cross-compiling to x86_64-linux-musl or aarch64-linux-musl depending on TARGETARCH. Zig 0.16.0 is pinned and the Dockerfile asserts the version with test "$(zig version)" = "0.16.0", so a mismatch fails the build rather than producing a subtly different artifact. Stage 2 is a busybox image that writes a default config.json into the volume root.
Installing NullClaw with Zig or Docker Compose
There are two documented paths. The first is building from source, which the README gives as a reproduce-locally block. You need Zig 0.16.0; the repository has a docs/en/zig-installation.md page for that, and the Dockerfile shows the project installs Zig through .github/scripts/install-zig.sh rather than a package manager.
zig build -Doptimize=ReleaseSmall
ls -lh zig-out/bin/nullclaw
/usr/bin/time -l zig-out/bin/nullclaw --help
/usr/bin/time -l zig-out/bin/nullclaw statusThe build writes the binary to zig-out/bin/nullclaw, and the README suggests /usr/bin/time -l to check the binary size and the startup cost of --help and status yourself rather than trusting the table.
The second path is Docker Compose, driven by a Makefile at the repository root. The compose file defines two profiles, agent and gateway, plus an init-data service that creates /nullclaw-data/workspace and chowns it to NULLCLAW_UID and NULLCLAW_GID (both defaulting to 65534). The agent service runs the nullclaw agent command with a TTY; the gateway service runs nullclaw gateway --port 3210 --host 0.0.0.0 and binds the port to 127.0.0.1 by default.
make build
make config
make up
make logsmake config runs the onboard subcommand with --interactive inside the agent profile, which is where you supply credentials and pick a model. The Dockerfile's config stage seeds a single default: an agents.defaults.model.primary value of openrouter/anthropic/claude-sonnet-4. make up then starts the gateway profile in the background. If you would rather not use Compose, the Dockerfile itself is the reference for what the container expects.
Where NullClaw is the wrong tool
The binary size is the headline, and it is also the source of the sharpest limitation. A 678 KB static binary cannot embed a model runtime. Everything NullClaw does with language goes over the network to one of those 50+ providers, which means the $5 board is a client, not an inference host. If your requirement is offline operation with no external API, this architecture does not give it to you.
The second limitation is documentation depth. The README is a directory of links: installation, configuration, commands, usage, architecture, security, gateway API. That is a reasonable structure, but it means the README itself does not document the config schema, the rollback story, or how secrets are encrypted beyond the phrase "encrypted secrets". The security page is where sandboxing is described, and the README lists four backends (landlock, firejail, bubblewrap, docker) without stating which is active by default or what happens when none is available. That is a question to settle before deployment, not after.
The third is the release cadence. The most recent release listed is v2026.5.29 from 2026-05-29, with a nightly build dated 2026-07-13 and an earlier v2026.5.4. The last push to the repository was on 2026-07-19. There is a nightly channel, so tracking main is possible, but the gap between the last tagged release and the last commit means anyone pinning to a release is running code that is roughly two months behind the branch.
NullClaw vs ZeroClaw and PicoClaw: what actually differs
The README's benchmark table names ZeroClaw (Rust, under 5 MB RAM, under 10 ms startup, 1,017 tests) and PicoClaw (Go, under 10 MB RAM, under 1 s startup) as the nearest neighbours. The numbers in that table are the project's own, measured on the same machine, so the useful comparison is the approach rather than the digits.
ZeroClaw is Rust, which means a mature package ecosystem, a large pool of engineers who already write it, and a binary in the same order of magnitude. If your team already ships Rust, the marginal cost of ZeroClaw is close to zero and the marginal cost of NullClaw includes learning Zig's build system and its allocator model. PicoClaw is Go, which trades a larger binary for garbage collection and a standard library that covers HTTP, TLS and concurrency without extra dependencies. NullClaw's bet is that no runtime at all is worth more than either.
That bet pays off specifically when the deployment target is constrained: a microcontroller-class board, a container where every megabyte of image size costs pull time, or a system where you cannot install a runtime. Outside those, the language choice is a staffing decision, and NullClaw is the harder one to staff.
Licence, upgrades and the cost of tracking a nightly
NullClaw is MIT licensed, and the repository carries a LICENSE file at the root. MIT is permissive: you can embed the binary in a product, modify it, and redistribute it, provided the copyright notice and licence text travel with it. That is the whole of the obligation as the licence is normally read. The repository does not document any separate commercial tier, contributor licence agreement or trademark policy in the files at the root, so if you plan to ship NullClaw under your own name, read LICENSE and SECURITY.md yourself rather than treating this paragraph as advice.
Upgrade cost has two components. The Zig toolchain is pinned: the Dockerfile sets ZIG_VERSION to 0.16.0 and fails the build on any other version, so a Zig upgrade is a project-wide change, not a background one. The second is configuration drift. The Dockerfile writes config.json into the volume root and comments that this keeps existing compose volumes readable, which implies the config format has moved before. Back up that file before pulling a new image.
The nightly channel is the escape hatch for fixes that have not reached a tag. It is also the fastest way to run untested code on a device you cannot easily debug.
Editorial conclusion
Adopt NullClaw if you want an assistant runtime that fits on a $5 board, boots in milliseconds, and exposes providers, channels, tools and memory as swappable vtables you can implement yourself. Do not adopt it if you need a mature configuration reference: the README points at docs/en/configuration.md rather than inlining the schema, and the Dockerfile's config stage writes a single default model entry, so anything beyond that is on you to verify. Before committing, read docs/en/security.md and confirm which sandbox backend (landlock, firejail, bubblewrap or docker) your kernel and host actually support, because the README lists all four without saying which is the default.
Frequently asked questions
How do you install NullClaw?
Either build it from source with Zig 0.16.0 using zig build -Doptimize=ReleaseSmall, which produces zig-out/bin/nullclaw, or use the Docker Compose path at the repository root with make build, make config and make up. The README points to docs/en/installation.md for the full steps.
What is NullClaw?
It is a fully autonomous AI assistant infrastructure written in Zig and distributed as a static binary. The README describes it as a 678 KB binary with roughly 1 MB peak RSS, 50+ providers, 19 channels and 35+ tools, with providers, channels, tools and memory exposed as swappable vtable interfaces.
How does NullClaw compare with OpenClaw?
The README's benchmark table lists OpenClaw as TypeScript with over 1 GB of RAM and a startup time over 500 s on a 0.8 GHz core, against roughly 1 MB and under 8 ms for NullClaw. Those figures are the project's own local measurements, so the meaningful difference is the runtime: Node versus a static Zig binary.
How does NullClaw compare with PicoClaw?
PicoClaw is Go, listed at under 10 MB of RAM and under 1 s startup with a roughly 8 MB binary, while NullClaw is Zig at roughly 1 MB of RAM with a 678 KB binary. The trade is a garbage-collected standard library against a smaller artifact with a smaller ecosystem.
Community notes