MicroClaw: A Self-Hosted Rust Agent Platform with Durable Execution

Server, Work Desktop, and SDK: Three Entry Points, One Engine

MicroClaw addresses the gap between simple chat wrappers and full agent infrastructure. Three entry points serve different use cases, all running the same Agent Engine underneath.

MicroClaw Server is a continuously running process that accepts requests through chat channels, a web UI at port 10961, REST APIs, and a scheduler for periodic work. It targets teams who need always-on agents that can receive tasks from Slack, Telegram, or other channels and complete them asynchronously.

MicroClaw Work is a native GPUI desktop application designed for local, workspace-centered agent work. It supports project and Git branch context, native file drag and drop, and an approval and checkpoint flow for reviewing agent actions before they run. The fully supported platform is Apple Silicon macOS 13 and later; Linux x86_64, arm64, and Windows x86_64 portable previews are available from the v0.6.1 release but are not yet at the same support level.

The microclaw-sdk crate lets any Rust application embed the same Agent Engine without depending on Server, channel code, or desktop UI. It supports stable Agent, Run, event, control, and Worker contracts. Feature sets range from minimal through standard, full, and remote-worker, controlled via Cargo feature flags, so an embedded deployment can include only what it needs. The minimum Rust version is 1.93.

How the Agent Engine Processes a Message

Every request through any of the three entry points follows the same six-step sequence. First, the engine resumes session state and loads the relevant memory, skills, and runtime context for that session. Second, it constructs a provider-neutral message and sends it to the selected model. Third, tool calls in the model response are executed through a shared tool layer that applies risk gates, scoped grants, egress controls, and sandboxing.

Fourth, side effects with uncertain outcomes are flagged for verification rather than blindly replayed if the process stops mid-execution. Fifth, results are stored in the embedded SQLite database along with a checkpoint that marks completed steps. Sixth, the reply is delivered to the originating channel or caller, with ordered chunking if the content exceeds the channel's size limit.

The checkpoint at step five is what makes sessions resumable. If the process stops between the model call and a tool execution, the engine reads the checkpoint on restart and picks up without replaying finished steps. The README describes this as a provider-neutral checkpoint because it does not depend on any single provider's session format.

Provider selection is handled through an internal message model that supports native Anthropic, a range of OpenAI-compatible endpoints, and local providers. Switching providers does not require changing application code that uses the SDK or the Server API.

Installing MicroClaw Server and the Work Desktop App

On macOS, install the Work desktop application with Homebrew:

brew tap microclaw/tap
brew install --cask microclaw-work

For MicroClaw Server on macOS or Linux, the install script handles the binary and service setup:

curl -fsSL https://microclaw.org/install.sh | bash

On Windows PowerShell:

iwr https://microclaw.org/install.ps1 -UseBasicParsing | iex

After installation, run three commands to verify the environment, complete configuration, and start the server:

microclaw doctor
microclaw setup
microclaw start

The web interface appears at http://127.0.0.1:10961. The `microclaw doctor` command checks the system before setup, which is the right place to catch missing dependencies or configuration issues before they surface at runtime.

For Docker, the repository includes a docker-compose.yaml that builds the server from source, persists the data directory to a host volume, and exposes port 10961. The multi-stage Dockerfile builds web assets with Node 24, then compiles the binary with Rust 1.95, and runs the result as a non-root user. The environment variable RUST_LOG=info controls verbosity.

The current stable release is v0.6.1. The README notes that the main branch moves quickly and may include breaking changes; production deployments should target the stable branch.

Checkpoint Recovery and Durable Delivery

MicroClaw documents four specific failure scenarios and its behavior in each.

When a reply exceeds a channel's size limit, the server accepts it, splits it into ordered chunks, and retries delivery without losing bytes at chunk boundaries. When the process stops between the model call and a tool execution, the checkpoint lets it resume completed work without replaying finished tool results. When a write-capable tool is interrupted, recovery stops at the uncertain side effect and asks for verification rather than retrying the call. When a channel is unavailable, task completion and message delivery are tracked separately, so the result can sit in a retry queue until the channel comes back.

The README references a reliability scorecard that ships as a machine-readable release asset with every release, reproducible locally with scripts/ci/reliability_scorecard.sh. The `microclaw doctor delivery` subcommand checks the delivery pipeline specifically.

This recovery model requires that tools report their side-effect risk accurately. The system cannot automatically determine whether a partially-completed tool call left data in a consistent state; it can only ask for human verification when a step is uncertain. Teams that use tools with external side effects need to consider how those tools handle being called twice.

Embedding the Agent Engine in a Rust Application

The microclaw-sdk crate exposes the same Agent Engine used by Server and Work. The workspace in Cargo.toml lists microclaw-sdk alongside microclaw-engine, microclaw-core, and the desktop application crates, all at version 0.6.1. A Rust application that wants to run agents without operating a full server can declare a dependency on microclaw-sdk and choose a feature set.

The four feature sets (minimal, standard, full, remote-worker) control which capabilities are compiled in. The README does not detail each feature set's exact contents, but the getting-started guide and SDK quickstart at site/docs/sdk-quickstart.md cover the integration steps. The SDK gives access to stable Agent, Run, event, control, and Worker contracts.

One practical constraint is that the SDK is Rust-only. Teams whose applications are in Go, Python, Node, or other languages cannot use it directly. They can interact with a running MicroClaw Server through its API, but that means operating a server process rather than embedding the engine in-process.

Limitations and Cases Where MicroClaw is the Wrong Choice

MicroClaw's documentation is honest about several constraints. The main branch may include breaking changes; the stable branch is the production-safe target. MicroClaw Work's full desktop support is Apple Silicon macOS 13 or later; Linux and Windows desktop builds are labeled portable previews.

The platform requires operating your own server. There is no hosted option in the repository. Teams that want agents without infrastructure work should look at hosted alternatives. The README's comparison to OpenClaw (referenced in the related searches for this project) does not appear in the repository material, so a direct technical comparison is not available from this source.

The project is inspired by nanoclaw and builds on ideas from it, but the documentation does not describe nanoclaw's approach in detail. The relationship is design-level rather than a fork or compatibility guarantee.

For applications that only need lightweight, stateless LLM calls, the embedded SQLite, session management, checkpoint system, and provider abstraction layer add overhead that is not justified. MicroClaw is designed for agents that operate over many turns, use tools with side effects, or need to survive process restarts. Single-turn question-and-answer flows do not require this level of infrastructure.

License, Maintenance, and Provider Compatibility

MicroClaw is released under the MIT license, which places no restrictions on commercial use or distribution.

The current stable release is v0.6.1, published on 2026-09-05. The last push to the repository was on 2026-09-05. The project appears actively maintained at the time of writing.

The release notes for v0.6.1 describe the focus as making releases faster and more deterministic through reusable Rust caches, an explicit artifact manifest, and updated GitHub Actions runtimes, rather than introducing new features.

Provider compatibility covers native Anthropic and a broad set of OpenAI-compatible and local providers through one internal message model. The Cargo.toml lists teloxide for Telegram channel support; matrix-sdk is available as an optional dependency under the channel-matrix feature. The MCP protocol is referenced in example config files (mcp.example.json, mcp.minimal.example.json), indicating that MCP server connections are part of the standard configuration surface.

Editorial conclusion

MicroClaw fits teams that need agents to keep running through process restarts, channel outages, or mid-task interruptions, and who are comfortable operating a Rust service on their own infrastructure. Developers who want a quick cloud-hosted agent or who work outside Rust will find the operational overhead and the Rust 1.93+ requirement a poor fit. Before adopting it, verify that the stable branch matches your feature needs, confirm your hardware meets the Work desktop requirements (Apple Silicon macOS 13+ for the fully supported release), and check that your preferred LLM provider is compatible with the internal message model documented in the getting-started guide.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes