The OpenClaw + OpenCode pillar closed with a paragraph on OpenCloud — sub-agents deployed to cloud instances while your computer is off. At the time of writing that essay, OpenCloud was still pre-release. As of this post (late April 2026), it's in limited beta, we have access, and we've spent enough time with it to have opinions.
This is a forward-looking post. The product will change. Everything below is accurate to v0.6 of the OpenCloud beta and our first three weeks of using it on agency workloads.
OpenCloud is a managed runtime for OpenClaw sub-agents that runs outside your local machine. The control plane lives in your existing OpenClaw session. Sub-agents that you'd normally spawn locally can be flagged for cloud execution and continue running when you close your laptop.
The mental model isn't "OpenClaw in the cloud." OpenClaw still runs locally. OpenCloud is specifically for sub-agents — leaf-node tasks with bounded scope, defined inputs, and outputs that come back to your local session when ready.
Architecturally, it looks roughly like this:
your local machine OpenCloud
───────────────── ─────────
OpenClaw (parent) ←── results ──── OpenCloud runner
│ │
├── local subagent 1 ├── cloud subagent A
├── local subagent 2 └── cloud subagent B
└── /opencloud spawn ──── plan ──── (queues here)
Spawning a cloud sub-agent looks like:
> /opencloud spawn lint-cleanup --tools=eslint,prettier --duration=2h
spawned: ojb-7f2a (queued)
It detaches. You close the laptop. The agent runs on a managed instance with the tooling you specified, hits a timeout or completion, and posts results back to your local session's pending-results queue. When you open OpenClaw next, the results are waiting.
Three workload patterns fit cleanly today:
1. Long-running mechanical work. Lint cleanups, dep bumps, mass refactors, doc generation across a large codebase. Tasks where you don't want to babysit and don't need real-time feedback. We've been running our weekly dep-bump pass on OpenCloud for a month — used to consume 90 minutes of someone's Friday, now it's a queued job.
2. Test generation and execution at scale. Spawn a cloud sub-agent per file in a directory; have each one write tests and run them. Wallclock is bounded by the slowest task, not the sum, and you didn't have to keep your machine awake.
3. Off-hours batch processing. Anything you'd normally script with cron + a CI runner, but where you want LLM-driven decisions in the loop. We use it for stale-PR triage, dead-link audits in our content, and a daily summary of new client repo activity.
Three things to not use OpenCloud for right now:
1. Anything needing your local secrets. OpenCloud runners get a sandboxed environment. Your local .env, your OS keychain, your local certificates — none of those exist in the runner. If your task needs production database access, you have to push those secrets into OpenCloud's secret manager, and then you've duplicated your secret surface for unclear gain.
2. Tight feedback loops. A cloud sub-agent typically takes 30-90 seconds to provision. For interactive work you'd lose to that latency. Anything you'd want results from in under 5 minutes is faster locally.
3. Cost-sensitive bulk work that K2 can handle. OpenCloud charges for runner time regardless of which model the sub-agent uses. If you're running a Kimi K2 task that takes 2 minutes, you save $0.04 on tokens but pay $0.50 in runner overhead. The economics flip when tasks run for 30+ minutes.
Authentication is more complex than billed. The "just spawn a cloud sub-agent" pitch glosses over the OAuth flow you go through to grant the runner access to your repo, your LLM provider keys, and any tools (linter binaries, language servers) the runner needs. First-time setup took us 40 minutes and one Slack with their support team.
Result delivery is best-effort. A finished sub-agent's output lands in your local session's pending queue, but the queue itself lives on your machine. If you don't open OpenClaw for a week, the results pile up. We hit a memory ceiling on day 9 of a vacation and lost a batch of intermediate state. Solved by adding a daily cron'd openclaw subagent flush --to-disk — but that should be the default.
Cost visibility lags. Runner usage shows up in OpenCloud's dashboard 4-6 hours after a job completes. For high-volume workloads, that's enough lag that you can be 4 hours into a runaway job before you notice. We rate-limit cloud sub-agents per hour as a hard guard.
Privacy questions are not fully answered. Your code goes to the runner. Your prompts go to the runner. The runner is OpenCloud-managed infrastructure. For client work under NDA, we ran the question past two clients before adopting it for their projects; one said yes, one said no. Read your contracts.
For a team that's already using OpenClaw locally with the opencode-controller skill and model routing configured, OpenCloud is an additive capability — not a replacement. The same routing rules, the same cost discipline, the same sub-agent orchestration patterns apply. You're just giving some sub-agents a different runtime.
Teams that haven't standardized on OpenClaw locally yet should not start with OpenCloud. The local stack is the prerequisite. The mental model that OpenCloud requires — sub-agents as leaf-node tasks with clean contracts — only forms after you've internalized it locally.
In our agency's experience so far, OpenCloud earns its keep for:
It's overkill for:
Per the OpenCloud roadmap as of v0.6, the next two releases focus on:
If those land, the use cases broaden a lot. Until then, OpenCloud is a useful tier for a narrow set of workloads — and the local-first stack remains where most of the value lives.
Founder & Lead Developer
With 8+ years building software from the Philippines, Jomar has served 50+ US, Australian, and UK clients. He specializes in construction SaaS, enterprise automation, and helping Western companies build high-performing Philippine development teams.
Tell us what you're building. We'll show you the fastest path to a production-ready launch.
Get My Free Proposal