Expand description
Run mode — how an eval is dispatched, independent of which harness runs it.
There are two dispatch mechanisms in the code today:
DispatchMechanism::InSession— the runner hands tasks to in-session subagents (Claude Code’s Task tool). The reference is Claude Code.DispatchMechanism::Cli— each task is dispatched through a one-shot harness CLI subprocess (codex exec). The reference is Codex.
These two mechanisms underpin the three user-facing run modes documented in
the README: fully-interactive rides on InSession;
headless and hybrid both ride on Cli,
differing only in whether a human/agent session drives the loop — not in how
a single task reaches the harness.
This is distinct from the comparison Mode
(new-skill / revision), which selects the two conditions being compared,
not the dispatch path.
Structs§
- Harness
RunCapabilities - Run-option support for a harness’s currently wired dispatch mechanism.
Enums§
- Dispatch
Mechanism - How a single dispatch is delivered to a harness. The primary code axis for run-mode concerns (next-steps guidance, transcript source).
- RunMode
- The user-facing run mode — who/what drives the loop plus which dispatch
mechanism each task rides on. This is the parity vocabulary documented in the
README (§Run modes); it maps down to a
DispatchMechanismviaRunMode::mechanism.hybridandheadlessboth ride onCliand differ only in whether a session drives the loop — a distinction we persist (inconditions.json) even though it doesn’t change how a single task reaches the harness.
Functions§
- capabilities_
for - The focused capability table for generic
runoption validation. - resolve_
run_ mode - Resolve the effective run mode for a harness, defaulting per harness when
unspecified and rejecting unsupported
(harness, mode)combinations. TheErrstring is operator-facing.