I Put My OpenClaw Agent on a Diet (and Let It Loose on Moltbook)

I've been running an OpenClaw agent on EC2 for a while now—connected to Telegram, handling tasks on demand, generally being useful. But there was always an annoying part of the setup: the instance had to be way bigger than the agent actually needed.

OpenClaw bundles Playwright and headless Chromium for web browsing. That's roughly 500MB–1.5GB of RAM just sitting there, waiting for the agent to visit a webpage. My agent browses maybe a few minutes per day. The rest of the time, Chrome is dead weight.

I was paying for a t3.medium (4 GB RAM, ~$30/month) because anything smaller risked the OOM killer showing up mid-conversation. The agent itself—just Node.js doing LLM calls and Telegram polling—barely uses 200MB.

The idea is simple: rip out the local browser, point all web interactions at Riddle's API, and downsize the instance.

This turned out to be straightforward. OpenClaw's skill system means the browser capability is modular—you can swap the underlying implementation without changing how the agent thinks about browsing.

There's an official OpenClaw plugin that handles everything. Install it:

One gotcha: OpenClaw requires plugins to be in the plugins.allow list. The CLI doesn't have an append flag, so you need to add it manually. Check your current list and add openclaw-riddledc to the array:

Once installed, your agent gets five new tools: riddle_screenshot, riddle_screenshots, riddle_steps, riddle_script, and riddle_run. The plugin saves screenshots to workspace files instead of inline base64, keeping your agent's context lean.

From the agent's perspective, nothing changed—it still “browses the web.” The difference is where that browsing happens: Riddle's ephemeral containers instead of Chrome on your EC2 instance.

Without Chrome to feed, the instance requirements dropped dramatically. The agent runs comfortably on a fraction of the original resources.

No migration is perfectly smooth. Here's what I ran into:

The useful migration pattern is to keep the agent's intent stable while changing the browser boundary: browser work becomes a remote, receipt-producing call instead of a long-lived local process.

The exact savings depend on how often the agent actually browses, but the model is simple: stop paying for Chrome to sit idle and pay for browser time only when a task needs it.

For personal or event-driven agents, the important question is not “can this host run Chrome?” It is “how many minutes per day does this agent actually need a browser?” If the answer is small, the thin-agent setup keeps the fixed monthly bill low.

Cost was the original motivation. But the security improvement might matter more.

With a local browser, every webpage your agent visits runs JavaScript on your EC2 instance. A malicious page could attempt SSRF against your instance metadata (169.254.169.254), scan your VPC, or exploit a Chrome sandbox escape to read environment variables—including your LLM API keys and any credentials the agent holds.

With Riddle, the browser runs in an ephemeral container on someone else's infrastructure. A sandbox escape compromises a disposable Riddle session, not your agent's host. SSRF attempts hit Riddle's network, not your VPC. Your agent never executes untrusted JavaScript.

This is especially relevant for OpenClaw agents that handle Telegram messages, where a prompt injection could trick the agent into visiting a weaponized URL. With Riddle in the middle, the blast radius is contained.

With the migration done, I wanted to test the setup in the wild. And right now, the wildest place for AI agents is Moltbook.

If you haven't seen it yet: Moltbook is a Reddit-style social network where only AI agents can post. Humans can observe, but the content is created entirely by autonomous agents. It launched days ago and already has 150,000+ agents and over a million human spectators.

OpenClaw agents can join Moltbook by reading the instructions at moltbook.com/skill.md, signing up, and having their human verify ownership.

The useful signup test is not whether a human can read the instructions. It is whether an agent can follow moltbook.com/skill.md, navigate the forms, preserve whatever verification state is required, and return screenshots plus logs when a step needs review. That is exactly the kind of workflow a remote browser boundary should make inspectable.

The right first post is not a sales pitch. It is a demonstration: the agent can explain what it changed about its own browser stack, attach proof artifacts, and answer questions from other agents or their humans with concrete receipts instead of vibes.

Moltbook is useful precisely because the audience is strange: agents are the visible participants, but humans still inspect the outcomes. A browser product for agents has to speak to both sides. The agent needs a simple tool contract; the human needs evidence that the tool did the right thing.

This is the question I set out to answer. My read: