Skip to content
Orcho Docs

Runtime Adapters for AI Agents

Orcho uses runtime adapters to call worker agents.

The runtime does the local agent work. Orcho owns the lifecycle around it: planning, phase boundaries, review, evidence, recovery, and delivery decisions.

What counts as a runtime?

Section titled “What counts as a runtime?”

A runtime is a local command-line worker that Orcho can invoke from a project checkout. It is not an IDE panel, web chat, or manual copy-paste session.

For a run to work, the selected runtime command must be available on PATH and already authenticated for non-interactive use.

Built-in runtime ids:

Runtime idTerminal commandRole in Orcho
claudeclaude --versionWorker backend for phases that route to Claude.
claude-glmclaude-glm --versionClaude Code-compatible wrapper identity for GLM-backed phases.
codexcodex --versionWorker backend for phases that route to Codex.
geminigemini --versionWorker backend for phases that route to Gemini.

The profile does not mean “one runtime for everything.” A profile can route different phases to different runtimes and models. For example, planning, implementation, review, repair, and final acceptance can each have their own runtime/model choice.

First-run check

Section titled “First-run check”

Before the first real run, check the commands your selected profile uses:

Terminal window
claude --version
claude-glm --version
codex --version

If a command is missing, the fix belongs at the runtime boundary:

  • install the missing CLI;
  • authenticate it;
  • expose it on PATH;
  • or override the phase runtime to one that is installed.

The run should fail because a worker is unavailable, not because the operator has to guess which hidden dependency was missing.

Adapter boundary

Section titled “Adapter boundary”

A runtime adapter should answer:

  • how to invoke the worker;
  • how to pass prompt input;
  • how to capture output;
  • how to preserve or reset session context;
  • how to report runtime failures.

It should not own:

  • final readiness policy;
  • delivery scope;
  • correction routing;
  • evidence schema;
  • workspace topology.

That boundary is what lets Orcho use different workers without becoming just another worker.

Proof: a full run on a non-Anthropic model

Section titled “Proof: a full run on a non-Anthropic model”

Because delivery policy stays outside the adapter, the whole pipeline is runtime-neutral — not just the implementation step. The run below routed every phase (plan, plan validation, a four-subtask implementation DAG, review, and final acceptance) through the claude-glm adapter on glm-5.2[1m], a GLM Coding Plan model with no Anthropic model anywhere in the loop. It still produced the same plan contract, per-criterion attestations, verification gate, and closing receipt — and opened a real pull request (orcho-core#78).

orcho run · every phase on glm-5.2, a non-Anthropic modelanimated

A real run, replayed from its event stream. It proves portability — the same delivery protocol runs on any capable worker. It is not a routing recommendation: Runtime economics still argues for spending top-model reasoning where it changes the outcome and keeping review independent of the author.

Phase-level routing

Section titled “Phase-level routing”

Runtime selection is phase-level policy. A local config can choose different workers for different jobs:

{
  "phases": {
    "plan": { "runtime": "claude", "model": "claude-opus-4-8[1m]" },
    "implement": { "runtime": "claude-glm", "model": "glm-5.2[1m]" },
    "repair_changes": { "runtime": "claude-glm", "model": "glm-5.2[1m]" },
    "review_changes": { "runtime": "codex", "model": "gpt-5.5" },
    "final_acceptance": { "runtime": "codex", "model": "gpt-5.5" }
  }
}

This is why the quickstart asks you to check the selected runtime commands instead of saying that one installed agent is always enough.

Deep reference

Section titled “Deep reference”

The canonical engineering docs live with the code:

Section titled “Related”