What OpenClaw Actually Is — and Why Running Claws Needs a Cloud

I've seen the same question in three separate HN threads this week:

"I don't even know what OpenClaw is."

Fair enough. The name has been everywhere — Karpathy coined "Claws" as a category, Peter Steinberger joined OpenAI to scale the framework, and suddenly there are 1,400+ comments on HN about it. But the signal-to-noise ratio is terrible. Half the discussion is people explaining it to each other incorrectly.

So here's a straightforward breakdown from someone who's been building infrastructure for this exact category of software.

OpenClaw: the framework

OpenClaw is an open-source framework for building autonomous AI agents that can use computers. Not chatbots. Not autocomplete. Agents that open terminals, write files, make API calls, browse the web, and chain complex multi-step tasks together.

Think of it as the orchestration layer. You point it at a task — "refactor this module," "set up monitoring for this service," "research these 10 competitors and write a summary" — and it breaks that into subtasks, executes them, handles errors, and reports back.

The framework handles:

• Tool use — file I/O, shell commands, HTTP requests, browser automation
• Memory — persistent context across sessions so the agent remembers what it did yesterday
• Multi-agent coordination — multiple specialized agents collaborating on a task (one writes code, another reviews it, a third deploys it)
• The Gateway Protocol — a standardized way for agents to discover and call external tools and services

It started as Claude Code's backbone, but now it's a foundation project. Model-agnostic in theory, though Claude still runs it best in practice.

Claws: the category

Karpathy's contribution was naming the category, not the framework. A "Claw" is any autonomous computer-using agent — whether it's built on OpenClaw, LangChain, CrewAI, or duct tape and bash scripts.

His NanoClaw demo — ~4,000 lines of Python, fully auditable — showed that you don't need a massive framework to build one. And he's right. For tinkering, for learning, for running a single agent on your laptop while you watch it work, self-hosting is great.

But here's where the conversation keeps going off the rails.

The "I'll just run it on my Mac Mini" problem

Every other comment in these threads is some variation of:

"Why would I need cloud hosting? I'll just run OpenClaw on my home server."

And for a Saturday afternoon project? Sure. But the moment you want agents running 24/7 — doing real work, handling real data, costing real money in API calls — you run into the same infrastructure problems that every production service hits:

1. Uptime is not optional

Your Mac Mini reboots for updates. Your ISP has an outage. Your cat steps on the power strip. Meanwhile, your agent was mid-task on a 45-minute code refactor and just lost all its context.

2. Supervision is hard

What happens when an agent enters an infinite loop and burns through $200 in API tokens in 30 minutes? (This literally happened to someone this week — saw it on X.) You need something watching the watcher. Circuit breakers, spend caps, automatic restarts with state recovery.

3. Multi-agent coordination requires real infrastructure

Running one agent is a process. Running five agents that talk to each other, share memory, and coordinate tasks? That's a distributed system. You need process isolation, message passing, shared state management, and failure recovery. On your laptop, one crashed agent takes down the others.

4. Memory management is a bottleneck

Agents have limited context windows. When they compact, they lose information. Persistent memory across sessions — what the agent learned yesterday affecting what it does today — requires a proper storage layer, not a JSON file on disk.

5. Cost observability

When you're burning $0.02/request across 500 requests/day across 3 agents, you need dashboards. You need per-agent cost tracking. You need alerts before you get a $400 surprise on your Anthropic bill.

Why I'm building cloud hosting for Claws

I run 5 Elixir apps on Fly.io for under €50/month. The reason the economics work is the BEAM virtual machine — Erlang's runtime, which Elixir runs on.

OTP supervision trees are basically purpose-built for the exact problems Claws have:

# Each agent gets its own supervised process
children = [
  {AgentSupervisor, agent_id: "code-reviewer", model: :claude_sonnet},
  {AgentSupervisor, agent_id: "deploy-bot", model: :claude_haiku},
  {MemoryStore, persistence: :postgres},
  {SpendTracker, budget_cents: 5000, alert_at: 4000}
]

Supervisor.start_link(children, strategy: :one_for_one)

If an agent crashes, the supervisor restarts it. If a supervisor crashes, its parent restarts it. State is recovered from persistent storage. No systemd, no cron hacks, no Docker restart policies — just the runtime doing what it was designed for 30 years ago.

This is what I'm building with OpenClawCloud. Multi-tenant Claw hosting on BEAM:

• Process-per-agent isolation — one tenant's runaway agent can't affect another's
• Automatic supervision — crash recovery with state persistence
• Spend tracking — per-agent API cost monitoring with configurable caps
• Gateway Protocol support — agents discover and use external tools through the standard protocol
• Persistent memory — agent context survives restarts, compactions, even deployments

It's early. Really early. I have one paying subscriber and a handful of free users. But the timing feels right — people are building Claws faster than the infrastructure to run them.

The self-hosting vs. managed hosting tradeoff

I'm not going to pretend self-hosting is wrong. Karpathy's point about NanoClaw being ~4,000 lines of auditable code is a genuine trust argument. You can see exactly what it does. That matters.

But it's the same tradeoff web developers made 15 years ago. You can run your Rails app on a VPS you manage yourself. You can handle your own backups, SSL certs, log aggregation, and 3 AM pages. Most people eventually decide they'd rather pay someone to handle that so they can focus on what the agent actually does.

The infrastructure layer for Claws is going to be commoditized within a year. The question is whether you want to build it yourself or use something that already exists.

I'm biased, obviously. But even if you don't use OpenClawCloud — if you're running agents in production, please don't run them on your Mac Mini. At minimum:

• Set up spend caps on your API provider
• Use process supervision (systemd at minimum, OTP if you're lucky enough to be on BEAM)
• Persist agent state externally (not in-memory, not local JSON)
• Monitor costs per agent, not just in aggregate
• Have a kill switch

The Claws wave is real. The infrastructure to support it is still being built. That's the part I find interesting.

---

I'm João, a solo developer from Braga, Portugal. I build SaaS products with Elixir and ship them on Fly.io. OpenClawCloud is at clawdcloud.net.