ZeptoClaw: a single Rust binary for a local-first AI assistant

What ZeptoClaw actually replaces

Most personal AI assistants are an application plus a pile of services. ZeptoClaw compresses that into one binary that runs locally, at the edge, or on a VPS. The README lists the components as tools, memory, channels, providers and sandboxed autonomy, and the repository layout backs that up: src/ holds the implementation, skills/ holds bundled skills, panel/ holds the optional control panel, and deploy/ plus docker-compose.multi-tenant.yml cover hosted setups.

The target user is someone who wants an agent they control rather than an account they log into. The README's own comparison table positions the project against OpenClaw, NemoClaw, NanoClaw and PicoClaw, and the stated goal is to keep the integrations and security those projects demonstrated without their costs: OpenClaw's large TypeScript footprint, NemoClaw's Docker and k3s guardrail stack, NanoClaw's narrow core, and PicoClaw's Go-only edge story. That is a crowded space, and the differentiator ZeptoClaw claims is the combination of a small Rust binary with security layers enabled by default.

Who it is not for: anyone who wants a hosted assistant with a support contract, or who expects a marketplace of community skills. The README describes 33 built-in tools plus plugins, not an ecosystem.

One binary, six sandbox runtimes, and a provider stack

The architecture is a CLI and gateway over a set of built-in subsystems. `zeptoclaw agent` runs a single prompt; `zeptoclaw gateway` runs as a long-lived service that speaks to Telegram, Slack, Discord and webhooks; `zeptoclaw batch` processes a file of prompts and writes JSONL. The README states the binary is roughly 6MB, starts in about 50ms, and uses about 6MB of RAM, with 18 providers and 10 active built-in channels.

Sandboxing is per request, and the README lists six runtimes: Docker, Apple Container, Landlock, Firejail, Bubblewrap, or native. That choice matters more than the headline number. Landlock, Firejail and Bubblewrap are Linux kernel or userspace confinement mechanisms, so they do not require a container daemon; Docker and Apple Container do. The `zeptoclaw gateway --containerized` flag is the documented way to run the gateway with full container isolation per request.

The security layers are the part worth reading closely. Prompt injection detection uses an Aho-Corasick multi-pattern matcher over 17 patterns plus 4 regex rules. A secret leak scanner runs 22 regex patterns over outbound content before it reaches the LLM. A policy engine blocks system file access, crypto key extraction, SQL injection and encoded exploits across 7 rules. There is an input validator with a 100KB limit, a shell blocklist targeting reverse shells and `rm -rf`, SSRF prevention via DNS pinning and private IP blocking, chain alerting for dangerous tool sequences such as write followed by execute, and a tool approval gate. The README states every layer runs by default with no flags and no config to enable them. That is the design decision the rest of the project hangs on.

Installing ZeptoClaw and running a first prompt

The README gives four install paths. The one-liner and Homebrew target macOS and Linux; Docker and a source build cover the rest. Copy the command exactly as documented, since the install script is fetched from the main branch rather than a tagged release.

curl -fsSL https://raw.githubusercontent.com/qhkm/zeptoclaw/main/install.sh | sh

If you prefer a package manager, the tap is `qhkm/tap/zeptoclaw`, and the container image is published to GHCR:

brew install qhkm/tap/zeptoclaw
docker pull ghcr.io/qhkm/zeptoclaw:latest

Building from source uses cargo and pulls from the git remote rather than crates.io:

cargo install zeptoclaw --git https://github.com/qhkm/zeptoclaw

The control panel is not in the default build. The README states that `zeptoclaw panel` and `zeptoclaw serve` require a build with `--features panel`, which is a compile-time feature rather than a runtime flag. If you install from a prebuilt binary and those subcommands are missing, that is why.

First run is interactive setup, which the README says walks through API keys, channels and workspace:

zeptoclaw onboard

After that, a single prompt confirms the provider wiring. The README's own quick start uses this example:

zeptoclaw agent --stream -m "Explain async Rust"

With streaming on, output arrives token by token. The README's longer example shows tool activity interleaved with the response, with bracketed lines such as `[web_fetch]`, `[shell]` and `[longterm_memory]` marking each tool call before the final answer. If you see the tool lines but no model output, the provider key or model name from `onboard` is the first thing to check.

For non-interactive work, batch mode reads a prompt file and writes results as JSONL:

zeptoclaw batch --input prompts.txt --output results.jsonl

Default-on security is a trade-off, not a free win

The README is explicit that every security layer runs by default and that there are no flags to remember. For a self-hosted agent that executes shell commands and fetches URLs, that default is defensible. It is also the most likely source of friction.

A 100KB input limit is generous for chat and tight for pasting a large log or a source file. The secret leak scanner's 22 regex patterns will occasionally match something that is not a credential, and the README does not document an allowlist or a per-pattern bypass. The shell blocklist is regex-based, which means it catches the shapes it was written for and misses rephrasings; the README does not claim otherwise. The tool approval gate exists precisely because the other layers are pattern matching rather than proof, and a gate that asks for confirmation is only useful if a human is watching, which rules it out for unattended gateway deployments unless you accept the blocklist as your only barrier.

There is also a concrete gap in the provider stack. The Cargo.toml comments state that the mqtt feature is temporarily disabled because of RUSTSEC-2026-0049, with the code left behind `#[cfg(feature = "mqtt")]`. So MQTT-based channels are not available in 0.9.2 even though the source is present. If your setup depends on MQTT, this release is the wrong one.

Finally, the README does not document rollback for a bad upgrade, and it does not document what happens to long-term memory when you run `zeptoclaw uninstall --yes`, beyond removing state under `~/.zeptoclaw`. Treat the memory store as something to back up yourself.

ZeptoClaw against PicoClaw and NanoClaw

The nearest alternatives in the README's own comparison are PicoClaw and NanoClaw, and the differences are structural rather than cosmetic.

PicoClaw is a Go edge assistant with a sub-10MB RAM target, web search, memory and scheduled tasks. It shares ZeptoClaw's hardware ambition; the README's table lists both as running on $10 hardware. The divergence is the runtime and the security model. ZeptoClaw is Rust, and it ships the injection detection, secret scanning, policy engine and six sandbox runtimes as defaults. PicoClaw's listed isolation is a workspace sandbox. If your reason for choosing an edge assistant is minimal footprint and nothing else, PicoClaw's Go toolchain may be easier to cross-compile; if you want per-request confinement options, ZeptoClaw offers more of them.

NanoClaw is a small TypeScript assistant with a roughly 500-line core and OS containers, focused on WhatsApp. Its appeal is that you can read the whole thing and customize it. ZeptoClaw is the opposite bet: a larger surface with 33 built-in tools and 18 providers, where customization happens through plugins and configuration rather than by editing a tiny core. Neither is better in the abstract. If you want to understand every line your agent runs, NanoClaw's approach is more honest about what you are getting.

OpenClaw is the broad ecosystem play, with 100+ skills and wide chat integrations, and the README cites CVE-2026-25253, the ClawHavoc incident with 341 malicious skills, and 42,000 exposed instances as the threat model ZeptoClaw was built against. That framing is the project's argument: breadth and a permissive skill model create an attack surface that a single audited binary avoids. It is a real argument, but it also means you give up the ecosystem.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-15. The most recent tagged release in the provided list is v0.9.2 from 2026-04-07, with v0.9.1 and v0.9.0 both tagged on 2026-03-26. So commits are landing well ahead of releases, and the version in Cargo.toml matches v0.9.2. If you track main, you are running code that has not been through a release cut.

Upgrade cost is mostly the binary itself. `zeptoclaw uninstall --yes` removes state under `~/.zeptoclaw`, and `zeptoclaw uninstall --remove-binary --yes` also deletes a direct-install binary from `~/.local/bin` or `/usr/local/bin`. Package-managed installs are removed with `brew uninstall qhkm/tap/zeptoclaw` or `cargo uninstall zeptoclaw` instead. The README notes that package-managed installs still use their package manager, which is a small but useful clarification: the built-in uninstall does not try to manage files it did not place.

The project is Apache-2.0, which permits commercial and closed-source use and includes an express patent grant. It also requires that you preserve the licence and notice files when redistributing, and it does not grant trademark rights, so you cannot present a fork as the official project. That is a general description of the licence text, not legal advice; check the LICENSE file and your own counsel for anything that matters.

The dependency surface is worth watching. Cargo.toml pins tokio 1.52 with the full feature set, and the comment explains that minimal features do not reduce binary size because teloxide and reqwest pull in most features transitively. The MQTT dependency is disabled for a security advisory. Both are signs of a project that tracks upstream advisories, and both are reasons to read the changelog before jumping versions.

Editorial conclusion

Adopt ZeptoClaw if you want a self-hosted assistant that fits on a small VPS or a Raspberry Pi class board and you accept that the security layers run without opt-in. Skip it if you need a broad third-party skills marketplace or a managed control plane, because neither is in the repository. Before committing, run `zeptoclaw onboard`, then `zeptoclaw agent --stream -m "Explain async Rust"` to confirm your provider key works, and check whether your target runtime needs the `--features panel` build for `zeptoclaw panel` or `zeptoclaw serve`.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. qhkm/zeptoclaw on GitHub
4. README
5. Releases