Skip to content
Orcho Docs

Runtime Economics for AI Coding Runs

Runtime economics is the operating discipline of choosing which worker runtime does each phase of an AI coding run.

It is not “always choose the cheapest model.” It is the more useful rule: spend strongest reasoning where ambiguity and risk are highest, route bounded implementation work through cost-efficient compatible workers when appropriate, and keep independent review in the loop.

Run economics

Orcho treats runtime choice as phase policy. A run can plan with one worker, implement on a GLM-backed runtime, review with another worker, and still leave one evidence record with runtime labels, findings, retries, tokens, and cost signals.

phase routingruntime identityGLM-backed runtimeindependent reviewcost accounting
Setup note

There is nothing to install for claude-glm: it invokes the same claude CLI against a GLM endpoint. What it needs is a working claude on PATH and a GLM Coding Plan key in ANTHROPIC_AUTH_TOKEN in the process that starts Orcho. The adapter supplies the endpoint, the model mapping, and its own CLI configuration directory, so it does not disturb a Claude subscription you are logged into for the ordinary claude runtime.

Why this exists

Section titled “Why this exists”

AI coding cost tends to grow in loops, not in single prompts. A task may plan, implement, review, repair, review again, and then reach final acceptance. If every phase uses the same expensive worker, the run can become costly before anyone knows which phase actually needed that intelligence.

Per-phase routing lets you ask better questions:

QuestionRuntime economics answer
Which phases need the strongest reasoning?Usually ambiguous planning, risk analysis, review, and final acceptance.
Which phases are more bounded?Often implementation and repair after a plan and acceptance criteria exist.
How do we avoid hidden substitutions?Use a distinct runtime id such as claude-glm so artifacts and metrics show the worker identity.
How do we keep quality from falling with cost?Keep review and final acceptance separate from the implementation worker.
How do we know whether the policy helped?Compare retries, findings, runtime labels, tokens, and cost reports over several runs.

The policy shape

Section titled “The policy shape”

Start from risk, not from vendor preference:

  1. Use strong reasoning for unclear planning or high-risk final decisions.
  2. Use a cost-efficient compatible worker for bounded implementation or repair.
  3. Let another phase review the result.
  4. Inspect outcomes by runtime, phase, retry count, and findings.
  5. Tune the routing only after you have several comparable runs.

In workspace config, that can look like this:

{
  "phases": {
    "plan": { "runtime": "claude", "model": "claude-opus-4-8[1m]", "effort": "high" },
    "validate_plan": { "runtime": "codex", "model": "gpt-5.5", "effort": "medium" },
    "implement": { "runtime": "claude-glm", "model": "glm-5.3", "effort": "medium" },
    "repair_changes": { "runtime": "claude-glm", "model": "glm-5.3", "effort": "medium" },
    "review_changes": { "runtime": "codex", "model": "gpt-5.5", "effort": "medium" },
    "final_acceptance": { "runtime": "codex", "model": "gpt-5.5", "effort": "low" }
  }
}

The exact model ids should match your installed runtimes and account access. The important contract is the shape: implementation and repair may use claude-glm, while review and acceptance remain independent.

Set up the GLM-backed runtime

Section titled “Set up the GLM-backed runtime”

claude-glm is a routing identity, not a command. There is no separate executable to install: the adapter invokes the same claude CLI you already have, against a GLM endpoint, and Orcho keeps the identity distinct in phase routing, events, metrics, and retry labels — so a GLM-backed phase is never a hidden claude substitution.

Two prerequisites, both in the process that starts Orcho:

Terminal window
claude --version                                    # a working Claude CLI on PATH
export ANTHROPIC_AUTH_TOKEN='<GLM Coding Plan key>'

That is the whole setup. The adapter supplies the endpoint, the model mapping, and its own CLI configuration directory — the last one matters: without it the child would resolve credentials from your ordinary Claude configuration and authenticate as your subscription rather than with the GLM key. Because that directory belongs to the adapter, claude-glm and the plain claude runtime can both be authenticated in the same pipeline.

CLAUDE_GLM_BIN is optional and points at the Claude-compatible executable itself — not at a claude-glm command:

Terminal window
export CLAUDE_GLM_BIN='/opt/claude/bin/claude'

The GLM endpoint owns provider behaviour and model availability. Orcho owns phase routing, lifecycle, gates, artifacts, and metrics.

When GLM-backed implementation is a good fit

Section titled “When GLM-backed implementation is a good fit”

Use a GLM-compatible implementation runtime when the work is bounded and the review boundary is real:

  • the plan is already accepted;
  • target files and acceptance criteria are clear;
  • the change is easy to test or inspect;
  • review/final acceptance runs on another worker or a human gate;
  • the run can tolerate repair rounds if the implementation misses a criterion;
  • you care about comparing cost and retry behavior across runs.

Avoid it as the default for:

  • unclear architecture or product intent;
  • security-sensitive reasoning without a strong review path;
  • final acceptance on high-risk changes;
  • work where no test, review, or evidence gate can reject the result.

Cost control should never bypass readiness control. If the review phase cannot say no, the runtime mix is not the main risk.

What to measure

Section titled “What to measure”

Do not judge a routing policy from one successful run. Track the pattern:

SignalWhy it matters
Phase runtime labelsConfirms implementation really used claude-glm and review used a separate worker.
Retry countShows whether lower-cost implementation creates more repair loops.
Review findingsDistinguishes useful savings from work that repeatedly misses the contract.
Tokens by phaseShows whether plan, implementation, review, or repair dominates the workload.
API-equivalent costEstimates how the same workload would look under metered API economics.
Final verdictConfirms the run was accepted, blocked, or explicitly waived.

Use:

Terminal window
orcho metrics --last 5
ORCHO_ACCOUNTING=1 orcho cost --window 30d

Then inspect the run’s metrics.json, events.jsonl, findings, and evidence bundle for the detail behind the rollup.

Deep reference

Section titled “Deep reference”

The canonical engineering docs live with the code:

Section titled “Related”