zerostack: a Rust coding agent that trades features for a 16MB footprint
Lightweight coding agent written in Rust, optimized for memory footprint and performance
At a glance
- What is it?
- zerostack is a GPL-3.0 coding agent written in Rust, positioned around a small binary and low memory use rather than breadth of integrations. The interesting part is not the feature list, it is how much of that list is behind compile-time gates and what that costs you at upgrade time.
- Who is it for?
- Adopt zerostack if you already run a Rust toolchain and your constraint is resident memory on a small or shared machine, and if you are willing to build with an explicit --features list rather than accept the defaults. Skip it if you need Windows, if you want a single static binary with every capability compiled in, or if a GPL-3.0 dependency is incompatible with how you ship software.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Rust, 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 constraint zerostack is actually built around
Most coding agents are Node or Python programs that pull in a runtime, a package tree and a large dependency graph before they do any work. The README frames zerostack against that: it lists a binary size of 26MB, a RAM footprint of roughly 16MB on average with peaks near 24MB, and compares those to figures it gives for opencode of about 300MB with peaks at 700MB. Those are the project's own numbers, measured according to the README on an Intel i5 7th gen, and they are the clearest statement of what zerostack is for. If you run an agent on a laptop that is already holding a compiler, a browser and a test suite in memory, the difference between 16MB and several hundred MB is the difference between leaving the agent running and killing it before a build. The target user is someone who treats the agent as one more process in a constrained environment, not as the main application on the machine. The README also notes Windows support is not tested in any way, which narrows that audience further to Linux and macOS.
What the compile-time feature gates mean for your build
zerostack's feature list is longer than its default install. The Cargo instructions show the default set as loop, git-worktree, mcp, subagents, archmd, status-signals and multithread, while acp, memory, hooks, advisor and multimodal sit behind an explicit --features flag. That is a real architectural decision, not a packaging detail. Anything gated out is not merely disabled at runtime, it is absent from the binary, which is part of how the 26MB figure is reached. The README describes persistent memory as plain-Markdown storage: a global MEMORY.md plus per-project daily logs, a scratchpad and notes, injected into the system prompt each session. Lifecycle hooks are described as external commands that observe or gate tool calls, prompts and session lifecycle events, using a settings.json schema the README calls largely compatible with Claude Code hooks. The advisor is a second model the agent can consult mid-session, with an optional human-handoff mode. If your workflow depends on any of these, you are not running the binary the performance table describes, and you should say so out loud before you quote that table internally. Build with the flags you need and measure your own build.
Getting it running, and the one flag worth reading twice
The README gives four install paths. The script is curl -fsSL https://raw.githubusercontent.com/gi-dellav/zerostack/main/install.sh | bash. Cargo is cargo install zerostack for defaults, or cargo install zerostack --all-features, or cargo install zerostack --features acp,memory,hooks,advisor. Homebrew needs brew tap gi-dellav/tap, then brew trust gi-dellav/tap, which the README marks as required for Homebrew 6.0.0 and later, then brew install zerostack. Nix users can run nix-run against the main tarball, add it with nix profile add --file, or import the overlay from nix/overlay. Once installed, the README says to run /prompt autoconfig inside zerostack to explore the documentation and configure the tool interactively. The flag worth reading twice is --sandbox. The README is unusually direct about it: sandbox mode runs every bash command in an isolated environment, requires bubblewrap on Linux, and is described as a seatbelt, not a boundary against untrusted code. More importantly, it is best effort. When the selected backend binary is missing, bash commands still run, unsandboxed, with a warning in the logs. Adding --sandbox-required, or setting sandbox-required = true in the config, turns that into a hard failure instead. If you install --sandbox and skip --sandbox-required, a missing bubblewrap leaves you silently unsandboxed. On macOS, bubblewrap is Linux only, so the README points to zerobox via cargo install zerobox and sandbox-backend = "zerobox".
Permission modes and subagents: the parts that shape daily use
Two mechanisms determine how zerostack feels in practice. The first is the permission system: five configurable modes with per-tool patterns, session allowlists, and configurable mode-to-rule application policies. The README does not enumerate the five modes, so you will have to read the configuration docs or run /prompt autoconfig to learn what each one permits. Treat that as the first thing to pin down, because the difference between a mode that asks before every write and one that does not is the difference between an agent you supervise and one you leave alone. The second is subagents, which the README describes as parallel and used for exploring the codebase. That is a narrow, sensible scope: codebase exploration is the task where a separate context window pays for itself, and the project does not claim subagents handle arbitrary work. Around these sit the prompts system, which switches system prompt modes at runtime between code, plan, review and debug, and prompt chaining, which offers to advance brainstorm, plan, code and review as each phase finishes with config-gated transitions. The prompts system is presented as an alternative to managing Skills, which is a fair description of the trade: you get a fixed set of modes rather than a user-extensible library.
Where zerostack is the wrong tool
The README's own caveats are the place to start. Windows is untested, so if your team is on Windows, this is not a decision you can make from the documentation. Sandbox mode is best effort by default, as described above, and the README explicitly says it is not a boundary against untrusted code, which rules it out as a containment mechanism for running code you did not write. The gated features cut the other way too: if you want memory, hooks, ACP editor integration, the advisor or multimodal input, you are building a larger binary than the performance section describes, and the numbers in that section no longer apply to you. There is also a maintenance signal in the release cadence. Three releases landed between 6 and 7 September 2026, with the last push on 9 September 2026, which is fast enough that configuration keys and feature flags can move under you. The README's sandbox section already shows a truncated config key, sandbox-required, and a reference to a settings.json schema for hooks, so pinning a version rather than tracking main is the safer default. Finally, the licence is GPL-3.0. If you distribute zerostack as part of a product, or link it into something you ship, the copyleft terms apply to that distribution. That is a question for your own legal review, not something this article can settle.
How it differs from opencode and pi in approach
The README names its inspirations directly: pi and opencode. The comparison it draws is not about features but about runtime. opencode is a JavaScript-based agent, and the README's performance table puts it at roughly 300MB with peaks at 700MB, against zerostack's roughly 16MB with peaks near 24MB, with idle CPU at 0.0% versus about 2%. Those figures come from the project and were measured on one machine, so treat them as a claim to verify rather than a settled result. The structural difference is that zerostack compiles to a native binary and pushes optional capability behind Cargo features, while a JS agent carries its runtime and dependency tree at every start. That has consequences beyond memory: a native binary is harder to patch in place, and a Rust build is slower to produce than an npm install. The README also points to multistack, a separate parallel agent manager, for orchestrating multiple zerostack agents from the terminal. If your reason for considering zerostack is that you want many agents running at once, multistack is the piece that makes that practical, and it is a separate install rather than something zerostack does on its own.
Upgrade and maintenance cost
The release history shows v1.8.2, v1.8.3 and v1.8.4 within roughly two days, and the repository was pushed again two days after the last release. A project moving that fast will occasionally change a feature flag, a config key or a hook schema, and the README's hook section already commits to a settings.json schema that is largely compatible with Claude Code hooks rather than identical to it. That word largely is where upgrade work lives. If you build from Cargo with an explicit --features list, a new release can move a feature out of the default set and your build will fail loudly, which is the outcome you want. If you install from the script or a release tarball, you get whatever the maintainers compiled, and you will not know which gates are open until you check. The practical maintenance posture is to pin a version, keep your feature list in a file you can diff, and re-read the sandbox and hooks sections on each bump. The licence is GPL-3.0, and the README also links a Ko-fi donation page and a sponsorship contact, which tells you the project is maintained by an individual rather than a company with a support contract. That is a real consideration if you are placing it in a team's daily workflow.
Editorial conclusion
Adopt zerostack if you already run a Rust toolchain and your constraint is resident memory on a small or shared machine, and if you are willing to build with an explicit --features list rather than accept the defaults. Skip it if you need Windows, if you want a single static binary with every capability compiled in, or if a GPL-3.0 dependency is incompatible with how you ship software. Before committing, verify three things on your own machine: whether your editor or workflow depends on any of the gated features (acp, memory, hooks, advisor, multimodal), whether bubblewrap or zerobox is present if you intend to use --sandbox, and whether the permission system's five modes and per-tool patterns map onto the commands your team actually runs.
Community notes