Measured, or not claimed.

Two fixtures, both built the same way: the tests exist, the implementation does not, and the test files sit in each task’s reference scope rather than its write scope. A worker can read what it must satisfy and cannot edit it, so the only route to a green suite is code that is actually correct.

Leverage decides which intelligence deserves a job. RocketRide runs it. A worker whose cost class is not local or host executes as a RocketRide pipeline, so the sponsor is on the critical path rather than beside it.

These are credit deltas against the real staging organisation, written by npm run verify:rocketride to demo/evidence/rocketride-run.json. A health check would prove nothing, so the figure that matters is the one at the bottom: the worker inside the pipeline returned output.

One full mission ran this way. Mission LVR-bda3ba68 was started through the MCP tool leverage_run, not a script: 4/4 tasks verified across 8 proof checks in 311s, with 3 of 6 workers executing as RocketRide pipelines and $0.00 of paid inference.

A cold-start auction is blind: with no observations every candidate scores the prior, so the winner is effectively arbitrary. On the first real run the auction hired two models that return an empty response to any structured request, then burned three attempts discovering it.

So every reachable model is probed with small, real, executable tasks, verified by running what it wrote rather than reading it.

8 of 22 models completed every probe. The failure modes were not subtle: timeouts, HTTP 500 from the local runtime, malformed output, and one genuine HTTP 429.

The one derived number, and the one most likely to be abused. What it means, precisely: take the prompt and completion tokens observed during the run where the provider reported them, and counted from the text at 3.6 characters per token where it did not; price them at published frontier API rates; report the result.

It is not a saving, not a charge, and not a claim about what a frontier agent would have spent solving the problem. That agent would plausibly have used a different number of tokens and far fewer attempts. It prices this workload at those rates and nothing more.

The same scheduler that ran the missions above, driven over a 100-task graph (diamond, 4 per layer) with stub providers whose outages are scripted from a seeded generator. No provider is called and nothing is spent: this measures claiming, ordering, the auction and policy filter, the budget ledger, scoped writes, verification and handoff, and nothing about cloud throughput.

No baseline comparison. Running the same mission on a single frontier model needs a paid API key this build does not have. Rather than invent one, there isn’t one: no speedup multiple, no cost-reduction percentage, no “N× faster” anywhere in this repository.

One language, two fixtures. Nothing here generalises to a large polyglot repository and no such claim is made.

The benchmark plans are committed, not planner-generated. A benchmark whose task graph changes between runs measures the planner, not the workforce.

The rate limit in the canonical run is injected. It is deterministic, and labelled INJECTED in the event stream, the UI and here. What is being demonstrated is the recovery, not the coincidence.

It will not reproduce identically. These are stochastic models on free routes and the number of attempts and handoffs varies. What is stable is the shape: every task is verified before it is accepted, and paid spend is $0.00 every time, because that part is policy rather than luck.