Build a PicoClaw agent

PicoClaw is a single Go binary — the core is under ten megabytes — that speaks more chat protocols than runtimes ten times its size. It is the cheapest way to keep an agent online around the clock, and for a large class of jobs it is not a compromise.

Small is the feature

Most agent runtimes are Python or Node applications with a dependency tree, a runtime, and a resident memory footprint measured in hundreds of megabytes before they have done anything. PicoClaw is one compiled binary with no interpreter under it. That has three consequences that matter to you:

• It fits on the small box. See the fact card — this is the cheapest plan we host, and PicoClaw is comfortable on it rather than barely surviving.
• It starts fast. Agents here stop when idle to save you money, so cold start is a real user-facing latency. A Go binary wakes in a fraction of the time a Python gateway does.
• There is less to go wrong. No dependency resolution at runtime, no version drift, no import that fails at 3am. For a process whose whole job is to be up, that is worth something.

What you give up

Being honest about this is the point of the guide. PicoClaw is a chat agent with tools, not an agent platform. Compared with OpenClaw you do not get the deep skills/plugin system, sub-agent fan-out, or the same scheduling richness. Compared with the hosted coding agents it is not the thing you want writing and committing code — it has no persistent git workspace and no coding harness around the model.

What you do get is the loop that matters: it receives messages on a lot of channels, calls a model, uses tools, and answers. If that is the job, the extra machinery is machinery you are paying to keep warm.

The jobs it is exactly right for

• One-purpose bots. A bot that answers questions about your product in a Discord server. A bot that explains your docs in Telegram.
• Notifiers and monitors. Something checks, something reports. The model is there for judgment about what is worth telling you, not for a long reasoning chain.
• Reaching people on many chat apps at once. The adapter list punches far above the binary size, including several — DingTalk, WeCom, VK, MQTT, OneBot — that most runtimes simply do not speak.
• Your first agent. Cheapest way to find out whether you actually want an always-on agent before committing to a bigger box.

MQTT is a genuinely unusual one

MQTT in the adapter list means PicoClaw can sit on a message bus rather than a chat app — the protocol most home automation and IoT devices already speak. An agent that subscribes to sensor topics, decides whether something matters, and messages you on Telegram when it does is a real and slightly delightful use of a ten-megabyte binary on the cheapest box available.

Building one

1. Keep the brief narrow. PicoClaw rewards a specific job. "Answer questions about our API in Discord, and say you do not know rather than guessing" is a better brief than a job description.
2. Pick the model deliberately. It works with Anthropic, OpenAI, Bedrock and Azure, or the managed model at provider cost. On a narrow job a cheaper model is often genuinely fine, and this is the runtime where that decision has the biggest proportional effect on your bill.
3. Deploy and connect one channel. Then add others — the same agent answers on all of them.

Outgrowing it

The good news about starting here is that the brief is portable. If the agent needs real scheduling, sub-agents, or a skills system in a few months, the same description redeploys onto OpenClaw on a bigger box and you have lost nothing but a month of the cheapest hosting on the platform.

That is the argument for starting small: it costs almost nothing to find out you were wrong.

Is PicoClaw the right pick?

Not sure? Describe the job rather than the runtime — the builder's solutions engineer reads the same capability matrix this page does and will argue for a different one if it fits better.