Choose an agent runtime

September 21, 2026 · View on GitHub

Claude Code is the stable default. The fleet agents have run on Claude Code in production for a long time; it is what a new installation gets unless you ask for something else. pi and codex are experimental — pi works end to end for triage, prioritize, code, fix and review/retro; codex runs OpenAI models through the same secretless credential path but has no sub-agent roster yet, so review/retro are best left on Claude Code there. Neither runtime has completed a fleet pilot. Unless you are taking part in one, keep the default.

This page explains what the choice means and where it is made. You do not select anything on this page — the selection happens in the next step. On GitHub, Configuring GitHub asks when you run fullsend github setup (press Enter for claude) or you pass --runtime. On GitLab, pass --runtime to fullsend repos install — see Configuring GitLab.

Fullsend supports multiple agent runtimes. A runtime is the program that runs inside the sandbox and drives the model — it owns the tool-use loop, hook wiring, and transcript format. The runner (fullsend) owns everything outside: sandbox lifecycle, credentials, metrics, and the verdict.

Available runtimes

RuntimeStatusDescriptionWhen to use
claudeStable (default)Claude Code on Vertex AIEvery production deployment — mature, full sub-agent support for review/retro
piExperimental (enablement phase)Pi — Claude on Vertex by default; any provider pi supports by model name (e.g. Gemini on Vertex with the same credentials)Opt-in pilots only; see Runtimes for known constraints
codexExperimentalCodex — OpenAI models only, through the same secretless credential pathOpt-in pilots only, when you want GPT specifically. No sub-agent roster, so keeping review/retro on Claude Code is recommended; needs an OpenAI model named (FULLSEND_CODEX_MODEL) because the fleet harnesses ask for opus; see Codex

When and how the runtime is selected

  1. Next step — configure the forge. On GitHub, fullsend github setup <owner/repo> asks which runtime to use when run from a terminal; press Enter to keep claude. Passing --runtime skips the prompt. The setup PR it opens records the choice in .fullsend/config.yaml. On GitLab, pass --runtime to fullsend repos install (there is no interactive prompt). Nothing runs on this page — continue with Configuring GitHub or Configuring GitLab.
  2. Later — changing it. Edit runtime: in the repo's .fullsend/config.yaml (the setup PR shows the key), or, on GitHub, re-run fullsend github setup <owner/repo> --runtime <claude|pi|codex> (GitHub-only; it does not update a GitLab install). To put one agent on a different runtime or model than the rest — say code on Claude Code while triage runs Grok on pi — set runtime: on that agent's agents: entry in the same file (fullsend agent set code --fullsend-dir .fullsend --runtime claude); see Runtimes — per-agent settings. On GitLab (and for fleets managed through repos.yaml generally), edit .fullsend/config.yaml directly — converge does not rewrite that file for already-installed repos, so neither repos set-default defaults.runtime nor a per-entry runtime plus repos install changes an existing repo's runtime. --runtime on repos install only applies to repos newly added by that command. For a single agent, fullsend agent set code --fullsend-dir .fullsend --runtime claude also works. See fullsend repos.
  3. Per run — trying without changing the repo. fullsend run --runtime pi --model google-vertex/gemini-2.5-flash, or the FULLSEND_RUNTIME / FULLSEND_MODEL / FULLSEND_EFFORT environment variables (flag beats environment beats the agent's agents: entry beats repo-wide config). In CI the same names work as repository variables. Reference: fullsend run and Runtimes — selecting and overriding.

Where to see what ran

After a run completes, the selected runtime and model appear in several places:

  • Run plan block — Runtime: <name> (from <source>) printed at the start of every fullsend run
  • Status comment — the terminal status comment on the issue/PR includes a footer with runtime, model, effort, and cost (see Cost data contract for how cost is sourced and aggregated)
  • metrics.json — runtime, requested_runtime, runtime_source, requested_model, and override_source fields record what was selected and why
  • stderr — runtime: selected "<name>" from <source> for script consumers

Next steps