Two layers, both measured.

Same tasks passed, at two thirds the price, with the gate running. The baseline is a single strong model in a tool loop — no planner, no verifier, no craft gate, no acceptance check. It spent zero tokens checking its own work. rung spent 20% of its budget on exactly that, and still came out 31% cheaper.

So the 24 extra seconds are not the price of routing. They are the verification the other column never does: the tests re-run, the baseline established, the claims checked against the transcript, the diff read for the shapes an agent uses to fake a pass. You are not choosing between cheap and careful. We could route harder and show a larger discount — starting a rung lower was measured and came out slightly worse — but a saving that costs correctness is a bill arriving later, when somebody has to redo the work.

Measured, not estimated. 56 runs on rung’s own suite, both configurations 28 of 28 with hidden tests grading every one, and every dollar read from the provider’s own accounting rather than a token count multiplied by a price list.

The ladder cost $0.153 per run against $0.221 for always running the strongest model — 31% less money for 34% more tokens, because the rung it routes to is cheaper per token than the one it avoids.

What it costs you: 62 seconds a run against 38. The ladder is 1.6× slower. Cheaper in money and more expensive in wall clock, and a page that published one without the other would be doing the thing this whole section exists to argue against. Two earlier list-price estimates on the same suite came out at 15% and 54%, depending entirely on how often the ladder escalated — which is why the number needs the run behind it. All three are in the repository.

git clone https://gitlab.com/rung-cli/rung
cd rung && uv tool install .

# once it is on PyPI:
# uv tool install rung-cli

cd your/project
rung review --mr 42 --no-llm

# no key, no model, no config —
# it runs your own tests and
# reads the diff

rung onboard
# profile · keys · models · health

cd your/project && rung
› add input validation to login()
  and cover it with tests

include:
  - component: $CI_SERVER_FQDN/rung-cli/rung/rung-review@0.3.1
    inputs:
      fail_on: error

rung run "fix the failing tests" --yolo --json

Config, contracts, the router, hooks and skills, MCP: in the documentation.

Verbatim output. The escalation to error rests on one fact and nothing else: this exact test was already failing on the base ref, and the change made it pass by rewriting it. Review checks that by running the suite once on a base worktree and reading the failing test ids — so it costs nothing unless there is a weakened test to escalate and the suite is green now.

Weakening a test on its own is only a warning, deliberately. That detector fires on 20.1% of 667 merged commits that change tests across axios, fastapi, flask, gin, httpx, pydantic, requests and zod — every one a false positive, because tests are supposed to change when behaviour changes. The baseline rule fires on zero of the same 667. Fixing the code and updating the test with it is still just a warning; only the cheat is an error.

Both halves, for the check that matters most. A detector that never fires has no false positives, so a false-positive rate on its own tells you nothing. The tampering row gives you the other number: across eight real repositories, 402 of 404 seeded cheats caught — a deleted assertion, a skipped test, a changed expected value, a comparison relaxed to something that cannot fail. It was 53% until we measured it and found two shapes the detector could not see.

The rate that decides whether your merge request is blocked is still 0 in 667 real merged commits. Both scripts are in calibration/ and a test asserts these figures against their output, so the words here cannot drift from the run that produced them.