Why Local-First Beats Cloud for Unattended AI Coding Agents

The unattended coding agent space is consolidating fast. In the last few months, three distinct architectural camps have emerged:

1. Cloud sandboxes — you pay a monthly subscription, they spin up a VM, your code runs there.
2. Kubernetes orchestrators — you bring your own cluster, they schedule agent pods.
3. Local-first composable loops — you pipx install the orchestrator, it wraps whatever agent runtime you already use.

This post is about why the third camp — local-first — is the right default for most teams. Not because cloud is bad, but because the tradeoffs of shipping your code into someone else's sandbox are worse than the alternatives suggest.

The Two Cloud Approaches (and Why They Cost More Than Money)

Twill.ai — Cloud Sandbox, $50/month

Twill (YC S25) is the cleanest cloud-sandbox approach. You describe a task, Twill spins up a sandbox with Claude Code or Codex, and the agent works unattended until it produces a PR. The pitch: zero setup, just describe the task and walk away.

What you actually trade away:

• Your code leaves your machine. This is a hard no for any codebase under IP restrictions, NDAs, or compliance requirements.
• $50/month per seat. For a solo dev, that is one more recurring subscription. For a team of five, that is $3,000/year on top of API costs.
• No control over the runtime environment. The agent runs in Twill's sandbox, not yours. If your repo needs a specific system dependency, you are waiting for their sandbox image to support it.
• Vendor lock-in. You cannot swap the underlying agent runtime, model, or provider without leaving the platform.

Optio — Kubernetes Orchestrator

Optio takes a different approach: give it a K8s cluster, and it spins up agent pods that run a ticket-to-PR pipeline with CI feedback loops. The demo is impressive — self-healing on CI failures, auto-resume on merge conflicts.

The problem: you need a Kubernetes cluster. For most solo developers and small teams, running K8s to run a coding agent is like installing an industrial conveyor belt to move a single box. Optio's Helm charts and pod scheduling are powerful for platform teams that already live in K8s. For everyone else, it is infrastructure overhead that adds nothing to the agent's actual output.

The Local-First Architecture

Ralph Workflow is the simplest implementation of this pattern. pipx install ralph-workflow and you are done. No cloud subscription, no cluster, no code leaving your laptop.

The core loop is the same pattern that Twill and Optio implement — plan, build, verify, follow-up — but the runtime is your own machine:

# Your spec lives in a TOML file on your own filesystem
ralph run --task "refactor the auth module to use JWT"

# Ralph wraps your existing agent runtime (Claude Code, Codex, OpenCode)
# Each phase runs as a checkpointed step on your local machine

What local-first gives you:

• Zero recurring cost beyond API usage. No platform tax. No per-seat subscription.
• Your code stays on your machine. For anyone working with proprietary codebases, this is non-negotiable.
• Your environment, your rules. The agent runs inside your dev environment with your toolchain, your dependencies, your shell.
• Vendor-neutral by design. Ralph wraps Claude Code, Codex, or OpenCode — swap providers without reconfiguring your entire workflow.
• Checkpoint and resume. If your laptop goes to sleep mid-run, Ralph resumes from the last completed phase instead of starting over.

When Cloud Actually Makes Sense

The local-first approach is not universally better. Cloud sandboxes win when:

• You do not have a dev machine available overnight. Twill's cloud sandbox keeps running after you close your laptop. A local orchestrator needs the machine to stay on.
• You are on a platform team that already runs K8s. Optio's pod scheduling is genuinely useful if your CI pipeline is already containerized and you want agent tasks to slot into that same infrastructure.
• You need fully managed, zero-config setup. Twill's "describe the task and walk away" experience is hard to beat if you have zero tolerance for configuration.

But for the majority of developers who already have a laptop, already pay for API access, and already have a dev environment, the local-first approach gives you the same unattended coding capability without a second subscription, without shipping your code to a third party, and without learning Helm charts.

The "But I Already Use Claude Code" Question

You can run Claude Code directly with --dangerously-skip-permissions, and many developers do. The difference is what happens after the agent finishes:

• Raw Claude Code produces a diff. You review it manually.
• Ralph produces a checkpointed session log, a summary of what changed, verification output, and a ready-to-review PR.

The orchestrator's value is not in making the agent smarter — it is in making the agent's output reviewable without archaeology. This is the same problem that Twill and Optio solve, just with different infrastructure.

The Real Comparison Table

The Bottom Line

The unattended coding agent space is converging on a shared pattern — plan, build, verify, follow-up — and the real differentiator is not which model runs the agent but how much infrastructure you have to manage to get that loop working.

If you already pay for API access, you do not need another monthly subscription or a Kubernetes cluster to run unattended coding agents. Install the orchestrator locally, write a TOML spec, and let the loop run while you sleep.

Try Ralph Workflow → Primary Codeberg repo · GitHub mirror · Quick start