How we measure

What the workspace figures count

These come from one workspace, ours, captured on 13 September 2026. They describe our own use of Orchard between June and September 2026. They are not a benchmark and not a typical result.

1,008,441Memory operations

Write operations plus successful reads: 1,002,688 writes and 5,753 read hits. Read misses are excluded. Writes include updates and deletes, so this is not a count of unique records or finished tasks.

348,054Records stored

Records held in the workspace store at the time of the capture. It is not the number of recalls, unique facts, or completed tasks.

176,450Recorded model calls

Persisted usage rows across the history we have. It counts calls, not sessions or tasks, and it is only as complete as the recorded telemetry.

918MTokens consumed

Fresh input, cache writes and output added together: 476M plus 346M plus 96M. Cached reads are counted separately below. This is not a bill.

25.9BCache-read prompt tokens

Prompt tokens served from cache, counting each reuse of a repeated prefix. The 97% share is cache reads divided by fresh input plus cache writes plus cache reads. It measures prompt reuse, not money saved or time saved.

155,422Tool calls

The sum of the fifteen most-used tool names, not every tool call. It says nothing about whether a call succeeded.

3,096Actions recorded for audit

Actions in the displayed 24-hour audit summary. It does not establish that every action was reviewed, or that any flagged action was blocked.

Not availableFinding totals

The source reports that finding totals are unavailable. Visible rows are the findings that loaded, so their count cannot stand in for the total. Treat this as missing, not as zero.

The two estimates we stopped headlining

The capture also produces an estimate of tokens avoided, shown as roughly 44.6 million, and an estimate of model compute saved, shown as 2.9 days. Both are models, not measurements. The token estimate carries a range from 3.3 million to 158 million, which is a forty-eight fold spread, and the compute estimate ranges from zero seconds to eleven days.

A number with a forty-eight fold range does not support a claim, so the homepage no longer leads with it. Both figures depend on assumptions about which entries were credited and what a derivation would have cost. They are separate from the caching your model provider already does, and the compute figure is model time, never human time.

What we do not measure

• Measured money saved. We have not run a controlled comparison. Dollar figures in the repeated-work calculator are assumption-driven API-equivalent estimates.
• Hours saved. No baseline was recorded for the work in these captures, so there is nothing to compare elapsed time against.
• Business impact. Nothing here connects Orchard to a shipped outcome or a revenue number.
• Whether more agents are cheaper. Parallel work saves time only when review and coordination cost less than the rework they prevent. Any honest comparison has to count every session, retry, review and rework round.

The repeated-work cost model

The landing-page calculator is an editable worked example, not observed savings. It estimates one thing only: model spend on work the provider is asked to do more than once. Staff time, tools, infrastructure and subscription charges are outside it, and it does not price Orchard.

• The unit of work: one task is one job handed to an agent, run as a multi-step session rather than a single question. The agent reads, runs something, reads the result and continues, and every step re-sends the context so far. The default assumes 180,000 input and 12,000 output tokens of work you actually wanted, per task.
• Six sources of repetition: oversized context (90,000 input tokens per task), verbose output (5,000 output), re-reading to self-check (45,000 in, 3,000 out), duplicated investigation (5% of tasks at 200,000 in and 12,000 out), overwritten changes (3% at 150,000 and 14,000) and builds on an unagreed approach (7% at 260,000 and 20,000). Each is separately switchable, and every figure is editable.
• Monthly estimate: people × tasks per person per day × working days, then each source’s share of those tasks at its repeated tokens and the selected model’s list price. The default 25 people, 15 tasks and 22 days produce 8,250 tasks and a modeled bill of $18,967 a month on Claude Opus 5, of which $9,067 — about 48% — is repetition.
• The prevention share is yours, not ours: the 50% default is a scenario to test. It is not measured Orchard effectiveness, a customer outcome or a quote. At 50% it avoids $4,533 a month.
• Coordination costs something: staying in step means extra calls, so the model charges an overhead as a percentage of the bill you still pay, never a flat fee — an empty workload therefore owes nothing. At the 5% default that is $722, leaving $3,812 a month, about 20% of the bill. Remove no repetition and the result is a loss of $948, not a floor at zero.

Rates checked 2026-09-17, in USD per million tokens (input / output / cache read): Claude Sonnet 5 $2 / $10 / $0.20; Claude Opus 5 $5 / $25 / $0.50; GPT-6 Astra $10 / $50 / $1.00. These are standard API rates; Astra uses its short-context tier. Tokens are priced uncached, so the estimate is conservative for teams already getting provider cache hits; caching is a separate saving and is excluded. Equal token counts compare prices, not model quality or equal work.

Useful first-time work is held constant across both bars: doing the job once costs the same either way, so only the repeated portion moves. Annualisation repeats one identical month twelve times and is not a forecast. These are API-equivalent costs; on a subscription, avoided work may preserve an allowance rather than reduce an invoice.

Before trusting the output, check the modeled monthly bill against a real invoice and adjust tasks per day until it matches. To establish actual savings, record a baseline and compare matched tasks at equivalent accepted quality, counting every provider usage category on both sides. Our workspace capture demonstrates recorded activity; it does not establish how much repetition Orchard removes. Downloading the scenario exports the selected assumptions, rates, sources, formulas and full-precision results.

How the recorded case was assembled

The build we show was reconstructed from the project's commits, review notes and CI runs. The phases group that evidence for reading; they are not a timeline and not a live feed of agents at work. Where we show a review finding and its correction, both come from the recorded development of that project, and the regression test named alongside them exists in its repository.

The verification counts we quote are the checks that ran against the production build of that project. Passing checks support the behaviour that was tested. They do not prove the absence of defects.

Which pictures are real

The homepage carries recorded graphs and illustrative diagrams. The “How a team divides the work” scene is an example: it shows roles and the shape of a handoff, with no recorded data behind it, and it is labelled as an example.

The communication network is a recorded capture of our workspace, anonymised, from 12 to 13 September 2026. It holds 37 participants, 354 directed sends and 73 message routes. On message routes, the number of moving dots follows the recorded message count, so a busy route shows more of them. Memory and action routes are counted in different units, so they carry one dot and claim nothing about volume, and dashed placement routes carry none. Timing is not measured latency: how fast a dot travels means nothing.

How the event explorer was built

The three paths are synthetic examples based on Orchard Engine source inspected on 13 September 2026. They explain the persistent PubSub adapter, local PTY messenger, and inbound relay event bridge. They do not replay the captured log, connect to a running engine, or measure elapsed time.

The tool example follows an instrumented hook through the raw occurrence ledger and a separate, derived coordination view. A failed ledger append blocks that agent-events broadcast. Independent hook ingestion may already be queued, and tool execution remains unknown. Stored envelopes are redacted; that does not mean every live transport carries only the redacted copy.

The message example follows the local PTY delivery lane. Native agents and remote targets use other paths. A delivered signal can include deferred input. A processed receipt comes from a target-session hook or turn boundary without matching the message ID. It is not evidence that a particular instruction was understood or completed.

The peer example uses an eligible derived coordination event. Inbound filtering, occurrence capture and local projection are separate boundaries. Raw tool hooks are not automatically forwarded through this route. Socket acceptance does not prove peer processing, and this is not a guarantee of lossless or identical history on every machine.

The JSON panels use authored identifiers and readable summaries. The occurrence ID, message ID and transport correlation ID represent different things. No private event payload, session identity or machine name is published.

Chat coordination and model choice

The Orchard Chat walkthrough uses sample briefs and replies to explain dispatch, status and report-back. It is an interactive explanation, not a product capture or a completed customer project.

Chat model selections and worker runtime settings are separate. Hosted model availability depends on configuration and provider access. Local Chat requires a compatible model and ready runtime; enabling a hosted DeepSeek option does not install a local model. These choices do not imply automatic selection of the cheapest model or equal capabilities across models.

Individual usage rows describe individual calls. Comparing prices or token counts alone cannot establish equivalent task scope, output quality or total delivery cost. Include coordination, review and rework in a comparison, and include hardware and operation for local inference.

Limits worth knowing

• Recall is best effort. Stored context can be incomplete or stale, so the underlying source stays the authority.
• Runtimes differ. Tool access, hooks and permissions are not the same across Claude Code, Codex and OpenCode. Configuring a runtime is not the same as Orchard choosing a model for you.
• Connecting a tool grants no universal access. Where your data goes depends on the provider, integration and runtime you configure. Orchard does not create a sandbox around them.

Numbers we do not publish yet

Orchard is early. Install counts and repository stars are small enough that quoting them would say more about our stage than about the product, and rounding them up would be worse. Instead we link to the sources, where the real figures are visible to anyone: the CLI on npm and our GitHub organisation.

We also publish no customer count. The quotes on the site are from named people at named companies who agreed to them, and two contributors who asked to appear by role only.