> ## Documentation Index > Fetch the complete documentation index at: https://checkfu.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Brain plane > The qualified split design for running a harness loop on the worker plane and summoning a sandbox only when needed. The brain plane is the worker-hosted execution design for the loop half of a harness. On the container lanes, a Run binds a Runner and a Linux sandbox for the whole turn, and the harness loop runs inside that sandbox. In the locally qualified split composition, the loop — the **brain** — runs behind the same driver port as every other harness, and no sandbox exists until the brain issues a command that needs one. Once the worker host wire lands, a chat-shaped turn that never touches a shell or filesystem will bind **zero machines**. This page describes the capability as it stands. Parts of it are landed and proven; the deployment gates that keep it out of production are listed honestly at the end. ## What a brain is A brain is the loop half of a split-topology harness: a digest-pinned JavaScript module conforming to the published brain interface. It receives every platform dependency as data and ports — the documented environment contract (`CHECKFU_MODEL_*`, `CHECKFU_MCP_*`) carrying per-run scoped grants, a `fetch`, and a command executor — and performs every file and shell operation through that executor. It never receives ambient secrets: grants arrive as short-TTL per-run tokens minted at claim time, and the worker plane's own secret bindings are unreachable from the brain module by interface shape. The first-party checkfu harness is the reference brain, not the owner of the plane. The contract is designed so any conforming brain can enroll through the same profile, conformance, and capability-ceiling machinery as any harness once the lane is admitted. ## How the split works The topology is `split` (see RuntimeTopology): the brain runs on the worker plane; its **hands** — shell commands, file syncs — cross a durable command queue. The brain appends a command; a sandbox executor claims it under the same fenced-lease mechanics runners use to claim Runs; the result appends back. The two sides of a command never need to be alive at the same time, and there is no live RPC across the split. Files live in a governed workspace filesystem the platform can reach directly, so mounts, memory, skills, and deliverables work without a box. Placement is compiled at admission — provider, profile, and image digest are fixed before any command exists. Lazy summoning only changes when the sandbox starts; a command cannot choose a different one, or a weaker isolation tier than the one admission fixed. ## Zero-machine turns In the qualified brain-plane semantics, sandbox provisioning is triggered by the first durable command of a turn: * A turn that issues **no** command binds no sandbox. Its Budget reservation (made before work, like every turn) is released at settlement, and **no sandbox-compute usage entry is ever written** — the ledger shows exactly what didn't run. The turn's telemetry (`run.completed.turn`) records `execution: "model_only"`. * A turn whose first command needs a machine waits for a cold sandbox summon at that moment. This is the direction in which the brain plane is *worse* than a container lane: a container-lane run already had its machine when the command arrived. The recorded comparison journey measures both directions on the same chat turn. * Later commands in the turn reuse the summoned machine; usage is ledgered from the summon, and the machine is released at the turn's end like any sandbox. The recorded local comparison's chat-shaped turn also started faster: there was no sandbox boot between admission and the first observation. This is qualification evidence, not a production latency promise. Durability comes from the brain's turn journal in the governed filesystem — eviction of the worker isolate reconciles at wake, with unresolved work surfaced honestly to the model rather than silently re-run. ## Ceilings and refusal modes The brain plane declares an honest capability ceiling; nothing about the topology promotes a capability: * **Non-JavaScript brains route to the container lanes.** The brain interface is a JS module contract. A harness that cannot conform runs colocated in a sandbox, exactly as today. * **Overweight workspaces route to the container lanes.** The governed filesystem has pinned size and entry ceilings with typed quota refusals; work that exceeds them belongs in a sandbox with a real disk. * The server ceiling starts at `interrupt: kill_only` and `mid_run_input: unsupported`. A brain that declares the checkfu cooperative-steering extensions admits exactly `cooperative` and `native` for that live session; the split driver carries the matching control hooks and serializes them against teardown. A non-declaring brain stays at the floor. ActionApprovals are `end_reinject`; checkpoints ride the journal in the governed filesystem rather than a driver-exported artifact. * Conformance obligations are identical to any harness, plus brain-plane locus evidence: platform-recorded proof that MCP calls originate from the enrolled brain's plane identity and that hands commands executed under the workload envelope. ## Deployment gates The split lane is **not** admissible in production today: * `SPLIT_RUNTIME_AVAILABILITY` is `unavailable` and names its two missing qualifications — a qualified platform-remote brain and the governed remote filesystem passing conformance in a deployed environment. No Runner registers a split execution target. * The worker-plane brain host wire (the turn-hosting Durable Object and its command/file adapters) is in-flight follow-up work; locally the split composition is proven against the real first-party brain out-of-process, byte-indistinguishable from the container locus. * Digest-pinned brain module loading depends on dynamic Worker Loaders, which reached open beta on Workers Paid plans in April 2026. Availability is no longer the gate; the code-identity contract is recorded, and the integration itself is unbuilt. What is already implemented and proven independently: the admission vocabulary (the split driver family's server-owned envelope and lazy sandbox-binding function), the lazy summon semantics on the runner, and zero-machine settlement on the real Session aggregate — a turn that bound no machine settles with a released reservation, no sandbox-compute usage, and its telemetry on the event log. The production wire that composes those pieces remains a gate. ## Next steps * [Harnesses and models](/concepts/harnesses-and-models) — the adoption paths and conformance machinery every harness, brain or not, goes through. * [Sessions and runs](/concepts/sessions-and-runs) — the event log the brain plane settles into. * [Billing and platform supply](/concepts/billing-and-platform-supply) — how usage entries and Budget reservations work.