docs/book/src/philosophy.md
ZeroClaw is built on four opinions, in priority order.
The binary runs on your machine, your VPS, or your SBC. Your API keys live in your config file. Your conversation history lives in your database. No telemetry, no cloud tenancy, no license server. If you pull the power cord, the agent stops — and nothing else breaks.
This is the foundational constraint. Every other decision below falls out of it.
Local-first doesn't mean consequence-free. An agent that can execute shell commands, call HTTP endpoints, and write files is a privileged process. The default autonomy level is supervised — medium-risk operations require approval, high-risk operations are blocked.
The runtime ships with:
zeroclaw estop) and OTP-gated actionsFor developers and home-lab users who understand the trade-offs, there's YOLO mode — one config preset that disables the guardrails. It's loud, logged, and obviously named. Not the default.
ZeroClaw is written in Rust and optimised for a small binary and fast startup. A microkernel roadmap (RFC #5574) is actively splitting functionality behind feature flags so you only ship what you use. A release build of the core runtime fits in tens of megabytes; adding channel integrations or hardware support is opt-in.
The same discipline applies to the agent's prompt surface. Tool descriptions are Fluent-localised and terse. There are no hidden system prompts injecting personality. The model sees what you configure.
The agent's brain is pluggable. Anthropic, OpenAI, Ollama, Bedrock, Gemini, Azure, OpenRouter, and any OpenAI-compatible endpoint (Groq, Mistral, xAI, and ~20 others) work out of the box. Fallback chains and routing rules let you run reasoning-heavy tasks on one model and cheap chat on another, with automatic failover.
This is deliberate. We have opinions about quality but not about vendors. If a better model ships tomorrow under a different banner, the config is a one-line change.
zeroclaw service subcommand manages systemd / launchctl / Windows Service registration out of the box.Substantive changes go through the RFC process — see Contributing → RFCs. Accepted RFCs are canonical. Open RFCs are discussion documents; they are the primary reference for what's coming next and why.
Ratified foundational RFCs: