Architecture
How Slack, the gateway, hosts and runners fit together
The pieces
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
TODO
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.