Fleets, brokers & compute

Three words describe where a session runs: fleet, broker, and compute provider. Getting these straight makes the rest of Sessions legible.

Fleet

A fleet is your org’s pool of ephemeral session machines. It has settings you control — pool size, idle and inactivity timeouts, the default agent and model, the default personality, and how credentials are distributed. See the configuration reference.

Broker

The broker is the orchestrator. It keeps the warm pool, claims a machine when a session starts, provisions it, and runs the Slack / Discord surfaces and the HTTP API. You don’t operate the broker directly; you configure your fleet and start sessions, and the broker does the scheduling. Each org gets its own single-tenant broker at <org>.norisessions.com.

Compute provider (not the same as harness)

Two independent axes are easy to confuse — keep them apart:

• Compute provider — where the VM runs. The backend is pluggable behind one contract, selected per fleet: Sprites (Fly) is the default, and Modal is the alternative. A “sprite” is one Fly VM — it is a backend, not a synonym for “session machine.”
• Harness — what runs inside the VM. The coding agent: Claude Code, Codex, Gemini, or a custom agent. Chosen per session.

So “any compute” and “any harness” are two separate promises. You can run Claude Code on Modal, or Codex on Sprites — the axes don’t constrain each other.

Note

Which backend a fleet uses is a fleet-level choice, not something you set per run — and switching it drains and rebuilds the pool. See the configuration reference.

Next steps

• What is a session — the lifecycle a machine moves through.
• Harnesses & personalities — the other axis: what runs inside the VM.
• Configuration reference — every fleet-level knob.