> ## Documentation Index
> Fetch the complete documentation index at: https://db6e2ea-opencomputer.manicule.dev/llms.txt
> Use this file to discover all available pages before exploring further.
> For every page in one file, fetch https://db6e2ea-opencomputer.manicule.dev/llms-full.txt (large).
> To search and read these docs as tools, connect the MCP server at https://db6e2ea-opencomputer.manicule.dev/api/mcp.
> Every agent surface: https://db6e2ea-opencomputer.manicule.dev/.well-known/llms-manifest.json

# Architecture (/getting-started/architecture)

<!-- agent-signals: reading_time_min: 2 · est_tokens: 552 · updated: 2026-11-11 -->
Related: [What is OpenComputer](/getting-started/introduction.md), [Quickstart](/getting-started/quickstart.md), [Develop locally](/getting-started/local-development.md)

> How Slack, the gateway, hosts and runners fit together

## The pieces

![How OpenComputer works](/_assets/77cb6af498ff2c9f86caeb7b2c672cb8a0fc60e309fe6bb53d6cce1872bfbaae)

## Gateway

The front door. Messages from Slack, the web dashboard, the API and the CLI arrive here, and the gateway passes them on to the right session. It also handles setup and connects to GitHub. It doesn't run any agents itself, so you can restart it at any time without losing work.

## Host agent

The manager on your VM. It connects to the gateway and picks up new work. For every thread it creates a workspace with a copy of your repositories and starts a session in it. It stops sessions that go quiet and brings them back after a restart.

## Runner

One coding agent working on one thread. Each session in the diagram is a runner. It posts its replies straight to Slack, so you see the agent's work as it happens.

## Where state lives

A session's state is written to the VM's durable disk first, then persisted to a durable git store. The disk keeps sessions fast; the git store makes them portable.

Portability is what lets you scale horizontally: another VM can pick up the same session when needed. If two copies of a session conflict, git resolves it.

The gateway keeps its own small SQLite database: which session runs on which VM, the people and VMs it knows, and messages waiting for a VM that's offline.

## Sandboxes only when you need them

Most platforms give every session its own sandbox, which sleeps and wakes up between turns. We tried that in early iterations of the product and ran into three problems:

* **It's slow.** Starting and resuming a session this way was too slow, even with several optimizations applied.
* **Cost scales linearly with sessions.** Every session pays for its own sandbox.
* **Most sessions don't need one.** Think of an exploratory session where you fix a few items in your docs: it doesn't need a separate sandbox and dedicated compute.

In many cases a shared VM can handle hundreds of concurrent sessions. A session only needs a sandbox when it runs a heavy build or spins up a preview environment, and at that moment OpenComputer delegates the session to the sandbox.