Skip to content
Orcho Docs

Real Orcho Run Receipt, Annotated

Case study

Most docs pages explain one mechanism with a sanitized example. This page reads one real receipt end to end: a feature of Orcho’s own CLI, shipped through Orcho itself. Nothing below is synthetic; the receipt is trimmed for length, with the internal identifier and private price figures removed.

outcomereview loopcost anatomyscope honesty
Cost accountingVerification receipts
real spend2h 45m hands-offapproved with receipts

The outcome

Section titled “The outcome”

The run took a feature task — a compressed line-by-line summary grammar for the CLI’s --output summary view — and carried it through the full pipeline: plan, plan validation, implementation, review, repair, final acceptance.

✓ plan=ok | validate_plan=ok | implement=ok
  | review_changes=ok | repair_changes=ok | final_acceptance=ok


Tasks: 3 planned · 3 completed · 0 failed · 0 incomplete
Release: approved
Open risks: none

Two details are easy to miss and worth naming:

  • The plan did not pass on its first attempt. Both plan and validate_plan show attempts=2: plan validation found a P1 finding and pushed the plan back before any implementation started. That P1 was resolved on record.
  • The plan’s three tasks were decomposed into six DAG subtasks (T1–T6) for implementation, each with its own cost, time, and tool attribution in the full receipt.

There is a pleasant recursion here: the feature this run shipped is the compressed summary grammar for the very receipt surface you are reading about.

The loop that converged

Section titled “The loop that converged”

Review and repair are the run’s control flow, and this receipt shows them under real load:

review_changes    attempts=7
repair_changes    attempts=5
Review findings: 1 (P1=1) | resolved: 1 | active: 0

Seven review rounds and five repair rounds sound expensive until you look at what they bought: findings fell to zero active, and the reviewer read deeply. In this profile the reviewer and the implementer are different vendors: Claude (claude-opus-4-8) implements and Codex (gpt-5.5) reviews across eight sessions. The author does not grade its own work in this run.

Mid-run, the engine’s advisor intervened once on its own:

Agent advice: calls=1 · applied_retries=1

One stuck attempt was pushed to a retry without a human touching the run.

Where the cost lives

Section titled “Where the cost lives”

The full private receipt contains API-equivalent estimates rather than a provider bill — see Cost accounting for the model. The public case keeps the workload shape while omitting private prices:

usage shape       input dominated · output below 1%
input cache       roughly 95%


implement         attempts=2  (96% cache-read)
review_changes    attempts=7  (91% cache-read)
repair_changes    attempts=5  (96% cache-read)
plan + validate + final acceptance recorded separately

Read the shape, not just the total:

  • Output is below 1% of the recorded token volume. Almost the entire volume is input: agents re-reading their context as the run progresses.
  • Around 95% of that input was served from provider cache. Fresh, full-priced token traffic is a small fraction of the headline figure.
  • The workload concentrates where the work is: implementation dominates, followed by repair and review.

This is the reason Orcho reports usage per phase and per subtask instead of one headline estimate: a cache-heavy implementation phase and a fresh-token phase can represent very different workloads.

The receipt tells on the run

Section titled “The receipt tells on the run”

The release was approved — and the receipt still carries two honest warnings.

First, scope expansion. The worker touched 14 files it never declared in the task’s ownership contract (mostly test files it added coverage to, plus one support module):

Scope expansion risk: 14 files flagged — unverified · no-explanation

The detector fired, classified the touches as non-blocking, and printed every path in the full receipt. An approved release does not silence the flags: the next reader sees exactly what the agent did beyond its declared scope.

Second, gate residue. All five verification receipts ran and passed before final acceptance, and the receipt still marks them stale — they were recorded before the delivery commit moved HEAD:

pre-final auto-run: 5 ran / 5 pass
blocking (require): broad-non-e2e, verification-unit, cli-sdk-unit
warning (warn): env-provenance, lint — shipping allowed by policy
note: stale = passed before a later HEAD move, not a failed check

stale is a provenance statement, not a failure — the receipt explains this in its own footnote. Which gates block and which merely warn is policy; see Verification receipts for the classification model.

Reading a run like this yourself

Section titled “Reading a run like this yourself”

Every number on this page comes from artifacts any Orcho run leaves behind: the final summary, events.jsonl, metrics.json, findings, and verification receipts. The Evidence bundle page maps the artifact set; Feature run anatomy shows the same stream live, phase by phase.

Section titled “Related”