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 with a GLM-compatible wrapper, review with another worker, and still leave one evidence record with runtime labels, findings, retries, tokens, and cost signals.

phase routingruntime identityGLM-compatible wrapperindependent reviewcost accounting
Version note

claude-glm requires an Orcho build that includes the GLM-compatible wrapper runtime. If orcho runtimes install claude-glm is not available, upgrade Orcho after the runtime support release or use a source checkout that contains the wrapper.

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.2[1m]", "effort": "medium" },
    "repair_changes": { "runtime": "claude-glm", "model": "glm-5.2[1m]", "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 a GLM-compatible wrapper

Section titled “Set up a GLM-compatible wrapper”

claude-glm is a Claude Code-compatible wrapper runtime. Orcho treats it as a separate runtime identity from claude.

Install the packaged wrapper after installing Orcho:

Terminal window
orcho runtimes install claude-glm

That installs ~/.local/bin/claude-glm by default. Check the wrapper:

Terminal window
claude-glm --version

Then run a small direct smoke test once credentials are ready:

Terminal window
claude-glm --print --model 'glm-5.2[1m]' 'Reply OK only.'

If the wrapper is not on PATH, either add its directory to PATH or set:

Terminal window
export CLAUDE_GLM_BIN="$HOME/.local/bin/claude-glm"

The wrapper owns the provider endpoint, credential source, and model defaults. 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”