PicoClaw vs OpenClaw: A Code-Level Deep Dive

Series:

1. PicoClaw vs OpenClaw: A Code-Level Deep Dive
2. What You Lose (and Gain) Running PicoClaw Instead of OpenClaw
3. Running an AI Agent on a $10 Board vs a Mac Mini
4. Running a PicoClaw Fleet from OpenClaw

Builder | Breaker | Fixer.

I spent time reading both codebases directly, not just README claims:

• PicoClaw source: /tmp/picoclaw
• OpenClaw source: /tmp/openclaw-src
• Installed OpenClaw package: /opt/homebrew/lib/node_modules/openclaw

I also pulled context from:

• https://picoclaw.net/
• https://github.com/sipeed/picoclaw
• https://www.hackster.io/news/forget-the-mac-mini-run-this-openclaw-alternative-for-just-10-da23b2819d25

The headline numbers

From direct file scans on the cloned repos:

• PicoClaw: 100 Go files, 25,539 LOC, 155 files total in repo
• OpenClaw: 4,036 TS/JS files, 717,486 LOC, 5,908 files total in repo

Dependencies:

• PicoClaw (go.mod): 43 required modules (15 direct + 28 indirect in grouped blocks)
• OpenClaw (package.json): 52 dependencies, 21 devDependencies, 2 peerDependencies
• OpenClaw lock graph (pnpm-lock.yaml): about 2,030 package entries

Sizes:

• PicoClaw built binary (arm64 macOS): 25 MB (/tmp/picoclaw/picoclaw-bin)
• OpenClaw installed npm package: 500 MB (/opt/homebrew/lib/node_modules/openclaw)
  • dist: 36 MB
  • extensions: 18 MB
  • plus large node_modules

Runtime memory, measured with both gateways idle and no active channels:

• PicoClaw gateway RSS: ~18 MB (/tmp/picoclaw/picoclaw-bin gateway)
• OpenClaw gateway RSS: ~57 MB (openclaw gateway)

That is the first real conclusion. PicoClaw is not pretending to be smaller. It is structurally smaller.

Language choice is not just taste, it changes architecture

PicoClaw is Go and intentionally monolithic. One process, one binary, explicit structs, no runtime plugin loading complexity.

OpenClaw is TypeScript and intentionally composable. It has a giant gateway, plugin registry, extension system, multiple channel drivers, browser/canvas/node integrations, and a lot of policy plumbing.

In practice:

• Go gives PicoClaw predictable startup and low baseline memory.
• TypeScript gives OpenClaw high feature velocity and breadth, at the cost of heavier runtime and dependency surface.

Entry points and startup model

PicoClaw

/tmp/picoclaw/cmd/picoclaw/main.go does command dispatch directly:

switch command {
case "onboard":
    onboard()
case "agent":
    agentCmd()
case "gateway":
    gatewayCmd()
...
}

Inside gatewayCmd(), PicoClaw builds provider, agent loop, cron service, heartbeat service, channel manager, and starts all of them in one pass.

OpenClaw

OpenClaw has a thin launcher (openclaw.mjs) that loads built dist output, then a rich CLI entry (src/index.ts), then many command modules, then gateway boot machinery.

src/gateway/server.impl.ts is a large orchestrator that loads config, migrates config schema, loads plugins, creates channel manager, cron, ws protocol handlers, node subscriptions, discovery, control UI, browser hooks, and more.

This difference is key: PicoClaw is one compact runtime. OpenClaw is a platform runtime.

Agent loop and tool-calling mechanics

PicoClaw loop: straightforward and readable

/tmp/picoclaw/pkg/agent/loop.go uses a classic iterative pattern:

1. Build messages
2. Call provider chat API
3. If tool calls exist, execute tools and append tool messages
4. Repeat until no tool call or max iteration

The core condition is explicit:

if len(response.ToolCalls) == 0 {
    finalContent = response.Content
    break
}

Tool execution is routed through ToolRegistry.ExecuteWithContext(...), then tool output is appended back as role: "tool" messages.

This is small, easy to reason about, and consistent with its low-resource goals.

OpenClaw loop: layered and policy-aware

OpenClaw uses pi-agent style abstractions and a larger tool pipeline in src/agents/pi-tools.ts and related modules.

It applies:

• tool policy resolution
• profile and provider based filtering
• sandbox wrappers
• schema normalization (provider-specific quirks)
• before/after hook pipelines
• channel-aware mutations

It is much more flexible, but with way more moving parts.

Tool systems compared

PicoClaw tool registry

/tmp/picoclaw/pkg/tools/registry.go is a direct map with simple registration and execution. The agent creates tools in createToolRegistry():

• filesystem: read/write/list/edit/append
• exec
• web_search / web_fetch
• i2c / spi
• message
• spawn / subagent
• cron (registered in gateway setup)

OpenClaw tool surface

OpenClaw builds a richer set in src/agents/openclaw-tools.ts and src/agents/pi-tools.ts:

• exec/process/read/write/edit
• browser tool
• canvas tool
• nodes tool
• gateway tool
• cron tool
• sessions tools (sessions_list, sessions_spawn, sessions_send, sessions_history, session_status)
• tts/image/web tools
• plugin-contributed tools via resolvePluginTools(...)

That plugin-contributed tool injection is one of the biggest architectural differences.

Subagents and session model

PicoClaw has a compact SubagentManager (pkg/tools/subagent.go). It stores tasks in-memory map, launches goroutine, runs tool loop, then announces completion via bus system message.

OpenClaw has persistent, restart-aware subagent registry (src/agents/subagent-registry.ts) with:

• announce retry backoff
• cleanup policy (keep vs delete)
• persistence to disk
• recovery/resume across restarts
• integration with gateway session methods

PicoClaw implementation is clean and pragmatic. OpenClaw implementation is operationally hardened.

Channels and plugin architecture

PicoClaw channels

pkg/channels/manager.go initializes channels directly from config booleans and credentials:

• telegram
• whatsapp
• feishu
• discord
• maixcam
• qq
• dingtalk
• slack
• line
• onebot

No plugin boundary, channels are compiled in.

OpenClaw channels

OpenClaw splits channel metadata, registry, and plugin runtime. src/channels/plugins/index.ts resolves active channel plugins from plugin registry, not hardcoded constructors.

Repository extensions include channels and related integrations such as:

• whatsapp, telegram, discord, slack, signal, imessage
• irc, googlechat, line, matrix, mattermost, msteams
• nextcloud-talk, twitch, nostr, zalo, feishu

It also supports webchat style flows through built-in gateway/web modules.

This is a massive difference in extensibility.

MCP / ACP reality check

PicoClaw currently has no implemented MCP server/client integration in core runtime code.

OpenClaw has ACP bridge code in src/acp/*. In src/acp/translator.ts, it currently declares MCP capability flags as false and logs that passed MCP servers are ignored:

mcpCapabilities: {
  http: false,
  sse: false,
}
...
if (params.mcpServers.length > 0) {
  this.log(`ignoring ${params.mcpServers.length} MCP servers`);
}

So, today, this is not full MCP-native execution in either stack, but OpenClaw has more protocol scaffolding around ACP/gateway interoperability.

Installed OpenClaw vs source OpenClaw

Installed package at /opt/homebrew/lib/node_modules/openclaw shows the expected production shape:

• dist/ with 2,011 files and ~821k text LOC equivalent
• extensions/ bundled
• skills/ bundled
• full node_modules footprint

That confirms the architecture is not just source complexity. The shipped artifact is also platform-grade.

Text architecture diagrams

PicoClaw

[CLI main.go]
   -> [Config + Provider]
   -> [AgentLoop]
       -> [ToolRegistry]
       -> [SessionManager + State]
   -> [ChannelManager]
   -> [CronService + Heartbeat]
   -> [Bus Inbound/Outbound]

OpenClaw

[openclaw.mjs] -> [dist entry/CLI]
   -> [Gateway server.impl.ts]
       -> [Config migration + validation]
       -> [Plugin registry + channel plugins]
       -> [Agent runtime + tool policy pipeline]
       -> [Subagent registry + sessions API]
       -> [Cron + heartbeat + hooks]
       -> [Browser + Canvas + Nodes + TTS/Image tools]
       -> [WS/HTTP protocol methods + Control UI]

What OpenClaw has that PicoClaw does not

At code level, these modules exist in OpenClaw and are absent in PicoClaw core:

• Browser automation subsystem (src/browser, browser tool + gateway methods)
• Canvas host subsystem (src/canvas-host, canvas tool)
• Paired node/device control over gateway (src/gateway/server-node-*, nodes tool)
• Rich plugin ecosystem (extensions/*, plugin runtime registry)
• Large cross-channel messaging action surface (src/agents/tools/message-tool.ts plus provider-specific actions)
• Deeper session APIs and tooling (sessions_* tools with policy rules)
• Advanced gateway protocol and control UI runtime

What PicoClaw does differently instead of skipping

Not everything is missing, some is intentionally simplified:

• Subagents exist, but implemented as a small local manager
• Cron exists, but with compact JSON job storage model
• Heartbeat exists, but lightweight file-driven prompt loop
• Security guardrails exist in exec, but fewer enterprise-level policy layers
• Channels exist, but built-in concrete implementations, not pluginized runtime

Final take

PicoClaw is not a “small OpenClaw clone”. It is a deliberate compression of the assistant stack into a Go binary with the minimum pieces needed for practical agent workflows.

OpenClaw is a full assistant platform with gateway protocol surface, extensibility layers, and integration breadth that PicoClaw does not try to replicate.

If I summarize in one line:

• PicoClaw optimizes for deployability and cost floor.
• OpenClaw optimizes for capability ceiling and ecosystem.

Both are valid engineering choices. They are just aimed at different limits.