The simple model

Execution gateway

Cerver When your agent asks for a computer.

Your app uses sessions. Providers supply compute. Cerver sits between them so local and remote computers look the same upstream.

apps use sessions providers supply compute local or remote

Product layer

Your agent

A coding agent, browser agent, or workflow asks Cerver to start a session.

↓

Cerver

Cerver keeps the session API above the compute providers.

Session layer The part your app uses.

Manages

sessions runs input routes policies metrics stress tests

Compute layer The part providers implement.

Manages

providers local computers remote sandboxes adapters streams CLI processes worktrees

↓

Available computers

Connected computers

Local machines and remote providers both sit behind the same compute interface.

local computer remote sandbox persistent workspace ephemeral runtime

If you only remember one thing

Apps should use sessions. Providers should supply compute. Cerver keeps those jobs separate.

Layer 1

Session layer

This is the layer your app talks to.

Entities it manages

session message run route policy metric stress test

Sessions and task lifecycle
Routing between local and remote
Policy, visibility, latency, cost
Stress tests and canary decisions

Layer 2

Compute layer

This is how Cerver reaches the real computer that will do the work.

Entities it manages

provider local computer remote sandbox provider adapter CLI process output stream workspace

Local bridges for user-owned computers
Hosted providers for remote computers
One adapter per computer backend
Start, stream, resume, stop on the actual machine

Why local and remote both fit

Cerver only needs one compute model underneath the session API, so a local bridge and a hosted provider can appear the same upstream.

Local

Local computer

A local bridge can expose a user-owned machine as one compute provider.

Remote

Remote provider

Hosted sandboxes and workspaces can expose the same interface as another provider.

Result

One path for your app

Your app only uses sessions. It does not need different code for local and remote compute.

What the session layer exposes

This is the clean interface sitting above the compute layer.

startSession

Begin work

Choose a provider or let Cerver choose one, then bind the session to compute.

sendInput

Continue work

Send the next task step or user message into the same session.

streamSession

Watch output

Return output in real time to the chat or terminal UI.

getSession

Read status

Tell the app if the session is running, paused, failed, or done.

getMetrics

Explain performance

Return startup time, latency, uptime, engagement, and cost without exposing provider quirks.

stopSession

End work

Stop the computer session cleanly, local or remote.