Cloud Control Plane

What it is

Omniscio can run sessions and heavy verification on rented cloud machines instead of your local computer. The Cloud Control Plane is the surface that governs and observes that world: is the fleet healthy, is the queue backed up, can this project's cloud box read its repository, and does the whole cloud path actually work end to end.

It is a developer- and operator-facing surface rather than something an everyday user clicks through, but it is the honest answer to "should I send this to the cloud right now, or wait?".

Where to find it

This is reached through the app's control surface (and its CLI). The most tangible action is a live round-trip: it creates one fresh per-session cloud machine from the golden image, runs one real task on it, then deletes the machine and verifies it is gone — proving the go-live path. Alongside it are reads for fleet health, queue statistics, storage-transport status, and a project's repository access.

How it behaves

The control plane gathers several live signals that are worth knowing:

• Fleet health summary — the conditions the cloud health monitor tracks (pointer strand, queue fall-open storm, disk saturation, capacity, worker version skew, and more), each with its own state. Ask it before dispatching a cloud job, or when a run keeps failing.
• Queue stats — submit-to-claim latency and a congestion verdict over a window, so an average that looks fine cannot hide your own job sitting unclaimed.
• CAS status — whether the delta transport is on, and if not, why; it fails closed, collapsing "off", "absent", and "unreachable" into one false, so this read distinguishes a real outage from an operator turning it off.
• Monitor status — whether the cloud health monitor is alive; a dead monitor means every other cloud alert has gone quiet because nothing is watching, not because the fleet is well.
• Repo access — whether a project's cloud box may read the project's repository; enabling it creates a read-only deploy key from the working tree the project itself points at, so a caller can never name an arbitrary repository. It only asks, queuing an approval card.

Starting or waking cloud machines costs money, so the paid trigger is gated four times over: it demands the full-trust credential (a scoped agent token is refused), it exists only in a development build, it needs the in-development cloud-sessions feature to be visible, and it needs the owner to have switched the control plane on — that setting is off by default and lives in Settings → Lab. The task it runs is fixed, so a caller cannot supply a prompt. Everything else in this section is a read.

For agents

• The control plane's IPC is src/main/ipc/cloud-control-plane-handlers.ts; the CLI server is src/main/services/cli/cli-server-cloud-control-plane-routes.ts, gated by src/main/services/cli/cloud-control-plane-gate.ts.
• Key routes: POST /cloud/control-plane/live-roundtrip (full CLI token + the cloud-sessions feature), GET /cloud/control-plane/sessions, GET /cloud/fleet-health-summary, GET /cloud/queue-stats, GET /cloud/cas-status, GET /cloud/cq-monitor-status, and the GET/POST /cloud/repo-access/* family.
• The reads live in sibling route files, one per area: cli-server-cloud-monitor-routes.ts (fleet health summary, monitor status), cli-server-cloud-queue-ops-routes.ts (queue stats), cli-server-cloud-fleet-routes.ts (CAS status), and cli-server-cloud-repo-access-routes.ts (/cloud/repo-access/status, /enable, /disable).
• Session state is held in src/main/services/cloud/control-plane/cloud-session-store.ts and metered via src/main/services/cloud/control-plane/cloud-meter-sink.ts.

Related

• cloud-returned-work.md — how finished cloud work comes back and lands.
• cloud-session-templates.md — the templates used to start cloud sessions.
• cloud-session-when-it-wont-start.md — diagnosing a cloud session that will not start.
• cloud-enforce-window.md — the bounded window that routes work to the cloud.