02 / SYSTEM
Operate the instruments.
Each module is described in the plugin’s own terms and runs a port of its rules from the source. Change the inputs and watch what Cockpit would decide. Every instrument here is a simulation: none is connected to Claude Code, and nothing on this page runs a model.
MODULE 01
Agent orchestration
With orchestration on, Opus stays the single commander. Sonnet engineers bounded changes and independent reviews; Haiku scouts and does extractive, repetitive work; small or tightly coupled work stays in the main session.
The swarm tool records each assignment before anything spawns: task ID, tier, role, objective, scope, dependencies, resource ownership, read or write mode and the reason for spawning. A queued task waits for capacity, a blocked one for its dependencies, and writers whose scopes intersect are serialized. Read-only scopes may overlap. Agents report; the commander verifies.
TrySpawn REV-1 before the engineers finish. Then switch on ENG-3, a writer whose claim covers all of src/, while ENG-1 is running.
- SCOUT-1HAIKU scoutreadqueued
owns src/middleware
↳ Nothing recorded stops it: it is admissible now and has not been admitted.
- ENG-1SONNET workerwritequeued
owns src/limiter.ts
↳ Nothing recorded stops it: it is admissible now and has not been admitted.
- ENG-2SONNET workerwritequeued
owns tests/limiter.test.ts
↳ Nothing recorded stops it: it is admissible now and has not been admitted.
- REV-1SONNET reviewerreadqueued
owns src/limiter.ts, tests/limiter.test.ts · depends on ENG-1, ENG-2
↳ Waiting for task ENG-1 (queued).
Spawn an agent. Cockpit answers with what the admission rule decided.
MODULE 02
Neural Flow and progress
One row of the HUD: INPUT → DISCOVERY → ROUTING → WORKERS → VERIFY → DONE. Each state is derived again at every draw from the task’s milestones and gates and the agents the host reported, so evidence that goes stale regresses the flow by itself.
Progress is completed milestones over all milestones. When every milestone is done but the evidence is not, it holds at 99%. A completed turn does not complete a task.
TryMark every milestone done with the evidence switch off: the bar stops at 99%. Fail a WORK milestone and watch WORKERS turn to ✕.
Milestones, as Claude reports them
FLOW ● INPUT → ● DISCOVERY → ● ROUTING → ◉ WORKERS → ○ VERIFY → ○ DONE verified INPUT, DISCOVERY, ROUTING · active WORKERS · pending VERIFY, DONE observed running: HAIKU 1 · SONNET 2 · work is live · main model OPUS
Amber is Haiku, cyan Sonnet, violet Opus, green a verified result; every state also has its own glyph. A ◆ travels only while work is live, and nothing is called a tier’s work unless an agent of that tier was observed running.
MODULE 03
Agent Inspector
/cockpit agents lists every swarm task, the ones that need attention first, with the wave, the capacity in use and a delegation funnel per tier. /cockpit agents <task> explains one: objective, ownership, dependencies, requested versus applied effort, reported versus verified outcome, and why it waits.
Blockers are explained from the swarm’s own admission rule, not a second scheduler. A suggestion is labelled information only; nothing is changed.
TryInspect REV-1 while the engineers run, then move to “Results reported” and compare ENG-1 with ENG-2.
AGENTS · wave ENGINEERING · 3 active · 1 waiting · 0 stalled · 0 escalated · 0 completed of 4
CAPACITY · 3 of 16 slots · SONNET 2/8 · HAIKU 1/16 · OPUS in the main loop
ROUTE HAIKU · suggested 1 · requested 1 · admitted 1 · spawned 1 · completed 0 · verified 0
ROUTE SONNET · suggested 3 · requested 3 · admitted 2 · spawned 2 · completed 0 · verified 0
REV-1 SONNET reviewer · blocked · no agent · none: not started
↳ Waiting for task ENG-1 (running).
SCOUT-1 HAIKU scout · running · agent bound · last observed just now
ENG-1 SONNET worker · running · agent bound · last observed just now
ENG-2 SONNET worker · running · agent bound · last observed just now
Read-only. /cockpit agents <task> explains one; /cockpit ready, what is left before DONE.TASK REV-1 · SONNET reviewer · blocked objective: Review the limiter and its tests against the criteria agent: none bound model: SONNET assigned; model not observed (no agent bound) route: SONNET, as the route suggested effort: requested AUTO · launch: none set on the call · applied: not observed wave: ENGINEERING owns: read src/limiter.ts, tests/limiter.test.ts depends on: ENG-1 running · ENG-2 running activity: none: not started outcome: none yet blocker (dependency): Waiting for task ENG-1 (running). suggestion (information only; nothing was changed): Wait for ENG-1; /cockpit agents ENG-1 shows where it stands.
Read-only: the inspector starts, admits and cancels nothing and clears no hold. It explains a blocker from the swarm’s own admission rule, and where the host reported no figure it says so instead of inventing one.
MODULE 04
Verification Readiness
/cockpit ready applies the completion rules to the recorded task: open milestones and blockers, the six gates, the goal check’s acceptance criteria. It says PERMITS DONE exactly when the task’s own status is DONE. A pass Claude reported is labelled as reported, never as verified; a pass that went stale is STALE.
A VERIFY milestone cannot be completed while a required gate or the goal check is unsatisfied: Cockpit holds it and says why. Verification records observed exit status and reported evidence. It is a hold on progress, not a proof of correctness.
TryAsk Claude to complete m5 now. Then press “Satisfy everything”, complete m5 again, and mark one gate STALE.
The six gates
A failing required gate reopens the completed milestones it invalidates: TEST reopens TEST, FIX and VERIFY milestones; any other gate reopens FIX and VERIFY.
Verdict
DOES NOT PERMIT DONE
status ACTIVE
READY · DOES NOT PERMIT DONE · 40% · status ACTIVE STANDING IN THE WAY ✗ milestones 2 of 5 done · open: m3 Write limiter tests [pending]; m4 Fix failures [pending]; m5 Verify [active] ✗ CODE not reported yet ✗ TEST FAILED · npm test (failed) ✗ TYPE not reported yet ✗ BUILD not reported yet ✗ SECURITY not reported yet ✗ GIT not reported yet ✗ goal alignment PENDING · acceptance criteria 0 of 3 met with evidence Read-only: approves nothing, clears nothing; a reported result is not a verified one.
MODULE 05
Cobalt Guard
Everything here is off until you turn it on. Owner alerts tell a person when a run needs one, through Claude Code’s own notification channel: no webhook, no email, no push. Record-only mode writes incidents down and tells nobody. Quiet hours defer ordinary alerts; a security failure is notified unless you choose to defer it too.
Separately, stopGuard: ENFORCE holds a stop until a verification script you enrolled by its sha-256 exits 0, within an attempt limit. None of it approves, releases or clears anything.
TryTurn on guardAlerts, then quiet hours. Compare run-blocked with security-failure, then switch alerts off and record-only on.
Outcome / NORMAL
NOTHING NEW
Nothing new is recorded or told. Earlier history can still be read.
(no pinned alert row)
Unchanged, whatever happens above: the gates, any hold, any review, any release approval and the task’s percentage. An alert, a reminder, an acknowledgment or a silence never changes a verdict, and SENT never means someone saw it.
MODULE 06
Run Ledger and replay
The Run Ledger records observed runs, agents, tools, usage, verification and optional local-control receipts for up to eight sessions in Claude Code’s plugin store, each stored ledger trimmed to 384,000 bytes, oldest detail first.
Replay keeps at most 24 snapshots and 96,000 characters; a snapshot is omitted when its file name looks sensitive, its text matches a credential pattern or it is over 12,000 characters. /park stores a deterministic checkpoint; resuming the same session restores it.
TryRecord an edit to .env and to a .pem file, then start sessions until the ninth evicts the first.
Stored ledgers: the eight most recent sessions
ledger:session-01ledger:session-02ledger:session-03- empty
- empty
- empty
- empty
- empty
3 of 8 kept. Each stored ledger is trimmed to 384,000 bytes, oldest detail first.
What is never a ledger field
Shell commands and tool arguments are not stored. Hidden reasoning is never stored. A ledger holds identifiers, tool names and paths, counts, timings, model usage, verification results, orchestration text, a 160-character excerpt of each subagent’s answer and bounded replay snapshots.
Replay: record an edit
No snapshot yet. Record an edit.
CONTROL
Reasoning effort, per task
Model selection and effort selection are separate decisions. AUTO names a level from the task; a commander can name one per assignment; the operator’s maxEffort caps every subagent request; the model’s own capability may lower it again. Requested and applied are kept apart, and a difference is named.
A failing task escalates one step at a time: effort within the tier first, then the next tier, never straight to the top, and it stops at a budget instead of retrying forever.
TryGive a HAIKU task complex debugging, then set maxEffort to medium. Raise the failure count and read the ladder.
- ChosenxhighAUTO: complex debugging
- Requestedxhighwithin maxEffort max
- Applied xhighSONNET declares low, medium, high, xhigh
SONNET xhigh → OPUS (effort chosen again on this tier) the same failure repeated 1 time and the effort ceiling is reached; escalating to OPUS
The applied level in a real session is the one the engine reports, kept apart from the request and named when they differ. It is host-resolution evidence, not an independently captured wire receipt. Your main loop’s effort is yours: /effort, settings and CLAUDE_CODE_EFFORT_LEVEL decide it, and Cockpit never writes it.
CONTROL
Configuration and optional enforcement
Observing is the public default. Model routing, budgets, ownership, Fable blocking and subscription-only authentication are separate switches, each off until you turn it on. Two command guards, blast-radius and attribution, are on by default and only ask or refuse. None of it replaces Claude Code’s permission rules or model controls: a guard can refuse a call or ask you, never approve one.
The builder reads every option from the plugin manifest at the synced commit and writes the documented command for the ones you change. Restart Claude Code after changing configuration.
TryChoose SONNET_LED with orchestration off, then turn orchestration on. Turn on cobaltStrict and see what it overrides.
Policy
On by default
Options, types and defaults are read from the plugin manifest at the synced commit (43 options). 21 of them, the Stop guard’s and the alerts’, are accepted only from you in /config, so this builder never writes them.
- Observe only: no model routing, subagent budget or task ownership is enforced.
- OPUS_LED (default): Opus 5.5 is the main loop and commander; AUTO budgets 16 subagents, up to 8 Sonnet and 16 Haiku.
- Fable is not blocked.
- Authentication is not restricted.
- Asks before genuinely destructive commands (hard reset, clean, force push, broad deletes, database drops, teardown).
- Keeps AI attribution out of commits, pull requests and files; asks before CLAUDE.md or AGENTS.md is created unasked.
- Local model telemetry: bounded files under your state directory, nothing uploaded.
- Unchanged in every configuration: Claude Code’s permission check. Cockpit can refuse or ask, never approve.
Every option is at its public default: observe by default. There is nothing to configure.
METHOD
How the demos work
The homepage mission and every instrument above run a TypeScript port of the rules in the plugin’s own source, reduced to what each demo needs: completion, gates and the goal check from hooks/model.ts and hooks/discovery.ts, the flow row from hooks/flow.ts, /cockpit ready from hooks/readiness.ts, admission from hooks/swarm.ts, effort from hooks/effort.ts, alerts from hooks/alerts.ts and replay bounds from hooks/replay.ts.
The site’s test suite checks the port against the outputs the README quotes from the plugin’s captured demo. The scenario, its calls, its evidence strings and the refusal reply come from the repository’s demo capture script (docs/assets/src/demo-capture.ts) and the README; the other replies are short paraphrases of what Cockpit records.
What the demos are not: a live session, a recording, or Cockpit itself. The main loop is shown by its tier; model ids, agent ids, token counts and context figures are not simulated, and where a real session would show what the host reported, the demos say so instead of inventing a value. The plugin’s behaviour is defined by its repository; when the two disagree, the repository is right.