# I Put My OpenClaw Agent on a Diet

OpenClaw agents ship with local browser capability, but local Chromium is often
the heaviest part of an otherwise small agent host. Moving browser work to
Riddle turns browsing into an on-demand remote tool call: the agent keeps its
normal workflow, while Riddle runs the browser and returns screenshots, logs,
and artifacts.

[<- All Posts](/blog)

## The Starting Point

A chat-oriented agent can spend most of its time doing lightweight work: LLM
calls, message polling, small CLI actions, and state updates. The local browser
is different. Headless Chromium can force a larger EC2 instance even when the
agent only browses occasionally.

That fixed instance cost is the fat-agent tax. You pay for browser capacity
while the browser is idle.

## The Migration

The migration is conceptually simple:

1. Remove local browser work from the agent host.
2. Install and allow the Riddle OpenClaw plugin.
3. Configure the Riddle API key.
4. Use Riddle tools for screenshots, scripted workflows, console capture, and
   artifacts.
5. Downsize the instance once the agent no longer needs to keep Chromium local.

From the agent's point of view, the task is still "browse the web." The
difference is where browsing happens: Riddle's ephemeral browser environment
instead of Chrome on the EC2 instance.

## What Needed Attention

- Plugin allowlists are real configuration. Installing a plugin is not enough
  if the gateway refuses to expose its tools.
- Session state moves to explicit inputs. Cookies, headers, and localStorage
  should be sent only when a task needs them.
- Latency changes shape. One remote screenshot is slower than an already-open
  local tab, but batching steps into one browser job can still be cheaper and
  more reliable than action-by-action local driving.
- Local-browser assumptions need a pass. Any skill that expects a filesystem
  screenshot path, persistent page object, or direct DevTools access should
  consume Riddle artifacts instead.

## The Cost Model

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

- Local-browser baseline: t3.medium-class instance capacity just to keep
  Chromium from crowding the agent process.
- Thin-agent target: smaller instance for LLM calls, chat polling, and command
  orchestration.
- Riddle usage: $0.50/hour of browser time, billed per second with a 30-second
  minimum per job.
- Break-even intuition: occasional browsing favors Riddle; continuous scraping
  may justify dedicated browser infrastructure.

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?"

## The Security Win

With a local browser, every webpage your agent visits runs JavaScript on your
EC2 instance. A malicious page can attempt SSRF, scan reachable services, or
exploit browser bugs close to the agent's credentials.

With Riddle, the browser runs in an ephemeral remote environment. A risky page
interacts with that browser session, not the agent host. The agent receives
artifacts and results instead of executing untrusted JavaScript locally.

## Moltbook as a Test Venue

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

The right first post is not a sales pitch. It is a demonstration: the agent can
explain what changed about its own browser stack, attach proof artifacts, and
answer questions with concrete receipts.

## Takeaways

- The Fat Agent tax is real. If your agent browses occasionally, you are paying
  for Chrome to sit idle.
- Security isolation is the underrated win. Separating the browser from the
  agent host removes an entire class of local-browser risk.
- Moltbook is a useful agent-facing venue because proof beats claims: a route
  check, screenshot, console log, and artifact URL are more persuasive than a
  generic announcement.