Persistent compute: the Matrix OS whitepaper

AI coding agents have a fundamental infrastructure problem. They're powerful enough to write code, fix bugs, run tests, and open pull requests — but they depend entirely on the machine running them staying awake. Close your laptop, lose your connection, or let your terminal time out, and the session is gone. Everything the agent was doing stops.

This whitepaper covers the architectural thinking behind Matrix OS: what persistent agent compute actually means, why current infrastructure options fall short, and how a dedicated hosted computer changes the way developers work with agents.

The Core Problem: Agents Are Stateful, Laptops Are Not

Many developers run terminal agents such as Claude Code and Codex CLI locally. That works for short tasks but ties execution to the laptop. Managed remote agents, including Cursor Background Agents, already use provider-owned remote environments.

The problem isn't the agent. It's that laptops sleep, terminals close, and home internet connections drop. None of that is compatible with long-running agent work.

This is the architectural gap Matrix OS is built to close: agents need a home that's always on, independent of any local device.

What Persistent Agent Compute Actually Means

Persistent agent compute isn't just "a VM in the cloud." The architecture has to satisfy three requirements at once.

Session continuity across disconnects. The agent's process, working directory, open files, and in-progress tasks all survive when the developer's device goes offline. Reconnect and everything is exactly where you left it.

Dedicated, isolated compute per developer. Shared sandboxes introduce noise, resource contention, and security concerns. Each developer needs their own machine with predictable resources — not a slice of a shared pool.

Agent-agnostic design. The infrastructure shouldn't be tied to one agent or one model. Developers use Claude Code today, Codex tomorrow, Gemini CLI next week. The compute layer shouldn't care which agent is running.

Matrix OS is built around all three. Sessions run on a dedicated Hetzner VPS provisioned per user rather than a shared application container. The VPS runs independently of the developer's laptop. Terminal agents such as Claude Code, Codex CLI, OpenCode, Pi, and Gemini CLI can use separate sessions and worktrees on the same machine; Cursor Background Agents use Cursor's managed runtime.

Why Existing Infrastructure Categories Fall Short

The existing infrastructure market wasn't built for this use case. Three categories exist, and each has a meaningful gap.

Sandbox Providers

E2B, Daytona, and Modal are the most commonly cited options for running agents in the cloud. Each has a session time cap or an architectural constraint that makes it unsuitable for persistent workloads.

E2B provides API-created sandboxes with lifecycle and persistence controls. That model fits programmatic isolated execution but differs from retaining one dedicated development computer across many tasks. Verify current limits and prices in the E2B documentation.

Daytona provides development infrastructure and isolated workspaces. Compare its current architecture, persistence controls, and pricing with the lifecycle your agents require.

Modal is serverless and optimized for batch jobs. Cold starts are intentional — it's not designed for a process that needs to stay running for hours or days.

Autonomous Agent Products

Devin ships PRs end-to-end, which sounds appealing, but it brings its own proprietary agent. You can't point Claude Code or Codex at Devin's infrastructure. If you've already built a workflow around a specific model, Devin doesn't help.

OpenHands is open-source, model-agnostic, and widely respected — but it doesn't provide the compute. You bring your own infrastructure and your own model keys. That's fine for teams with DevOps capacity; it's friction for a solo developer who wants to hand off a task and close their laptop.

AI-Native IDEs

Cursor is a good IDE. But its cloud features are tied to the Cursor editor workflow. There's no concept of a dedicated remote machine running independently of your device — the session lives inside the editor session.

The Architecture of a Dedicated Hosted Computer for Agents

Matrix OS provisions one dedicated VPS per user. The VPS runs continuously. The developer's local device is a viewer — it can attach to the session, send instructions, and check progress, but nothing depends on it staying connected.

Compute Tiers

Three hardware tiers are available, all on Hetzner VPS:

• Starter — 2 vCPU, 4 GB RAM, 80 GB disk — $14/month. Handles most single-agent workflows.
• Builder — 4 vCPU, 8 GB RAM, 160 GB disk — $19/month. Right fit for running multiple agents simultaneously or heavier build tasks.
• Max — 12 vCPU, 24 GB RAM, 480 GB disk — $49/month. Suited for parallel workloads or large codebases.

Multi-Agent Isolation

Multiple agents can run on the same machine in isolated sessions, each with its own process space. A Claude Code session working on a feature branch doesn't interfere with a Codex session running tests on main. This is architecturally different from spinning up separate sandboxes for each agent — the sessions share the same file system, so agents can hand off work to each other without copying files across environments.

Symphony: Orchestration Layer

Symphony is the orchestration layer built into Matrix OS. It handles parallel task queues, tracks agent status across sessions, manages branch and diff review, and supports human-in-the-loop handoff. When an agent finishes a task and opens a PR, Symphony surfaces it for review before the next step proceeds.

This is the piece that makes multi-agent workflows practical rather than just technically possible. Without orchestration, running three agents simultaneously means manually tracking what each one is doing. Symphony makes that visible and manageable.

Hermes: The Resident Agent

Hermes is a Matrix-native agent that lives on the VPS. It's not a substitute for Claude Code or Codex — it handles a different class of work: scheduled workflows, tool connections, notifications, and approvals. Hermes can watch a Sentry error feed, trigger a Claude Code session when a new error class appears, and notify you on Slack when the fix is ready for review.

It's what makes the platform feel like infrastructure rather than just a remote terminal.

Access Layers

The platform is accessible through multiple surfaces:

• Web shell from any browser: windows, terminals, file manager, previews, and agent sessions
• CLI for attaching to any running session from any terminal
• Mobile web shell for checking in on agent progress from a phone

Integrations include GitHub, Linear, Slack, Discord, Gmail, Google Calendar, Google Drive, Sentry, and Datadog. Native macOS desktop app and native mobile app are in progress.

What This Architecture Makes Possible

The practical shift is significant. Instead of watching a terminal while an agent works, you hand off a task, close the laptop, and come back to finished work. The agent ran on your dedicated VPS, committed its changes, and is waiting for your review.

For a solo developer, that means overnight runs are reliable. For a small team, it means multiple agents can work in parallel on the same codebase without infrastructure overhead. For teams evaluating agent infrastructure at scale, the dedicated-machine model provides the isolation and predictability that shared sandboxes can't match.

The broader architectural argument is that a cloud computer built for agents is a distinct product category from both cloud IDEs and sandbox infrastructure. It's not a development environment you code inside. It's a machine your agents live on.

This connects to a wider shift in how development environments are organized. The canvas-first workspace model reflects the same principle: the developer's role is increasingly about directing work and reviewing output, not staying attached to a running process.

Summary of Key Architectural Decisions

Dedicated VPS per user — eliminates resource contention; provides predictable compute.

No session time caps — continuous workloads require sessions that run as long as needed.

Agent-agnostic design — developers shouldn't be locked into one model or one agent.

Shared file system across sessions — enables agent handoffs without cross-environment file transfers.

Symphony orchestration — makes multi-agent workflows visible and manageable.

Hermes resident agent — handles scheduled and reactive workflows without manual triggering.

Getting Started

Matrix OS is free to sign up and explore at matrix-os.com. Hosted runtime requires an active billing plan, starting at $14/month for the Starter tier. Additional machines and storage are available as add-ons. Enterprise and pilot plans are available for teams evaluating at larger scale.

Frequently Asked Questions

What does "persistent agent compute" mean in practice?

Your agent's session keeps running on a dedicated cloud machine even when your laptop is closed, your internet drops, or you reboot locally. The process doesn't stop because your device did.

Which AI coding agents does Matrix OS support?

Matrix OS supports Claude Code, Codex, Cursor, OpenCode, Pi, and Gemini CLI. Multiple agents can run simultaneously in isolated sessions on the same machine.

How is Matrix OS different from E2B or Daytona?

E2B and Daytona center on programmatically managed sandboxes or workspaces. Matrix OS centers on a retained computer for a developer or team. Current provider limits change; the stable distinction is which party manages the environment lifecycle.

What is Symphony and how does it relate to running multiple agents?

Symphony is the orchestration layer built into Matrix OS. It manages parallel task queues, tracks agent status across sessions, handles branch and diff review, and supports human-in-the-loop handoff — making it practical to run multiple agents on the same machine without losing track of what each one is doing.

What is Hermes, and is it a replacement for Claude Code or Codex?

Hermes is a Matrix-native resident agent that handles scheduled workflows, tool connections, notifications, and approvals. It's not a substitute for Claude Code, Codex, or other coding agents — it works alongside them, handling coordination and reactive tasks those agents aren't designed for.

Can I access my Matrix OS machine from a phone or tablet?

Yes. A mobile web shell is currently available, so you can check on agent progress or review output from any browser-equipped device. Native mobile and macOS desktop apps are in development.

What happens to my files and data if I cancel my plan?

Your files, database, and runtime are owner-controlled and exportable. Matrix OS doesn't lock your data to the platform.

---

The infrastructure question for AI-assisted development is no longer just "which agent should I use?" It's "where should that agent run?" A dedicated, always-on machine purpose-built for agent workloads is a different answer than a local terminal or a shared sandbox. That's the architectural bet Matrix OS is making.