A review that runs on every pull request is, underneath, about 250 model calls of roughly 35,000 tokens each [OURS], and most of the decisions that shape the answer are not the model’s. OrcaRouter publishes the code review harness those calls run inside — the rules and the merge gate are on GitHub under MIT — which makes it one of the few review tools whose behaviour can be read rather than inferred from its output. That harness decides which files enter the diff, what the prompt asks, how much of the context is billed from cache, and what happens when a finding comes back that nobody agrees with.
Swap the model behind a review tool and the output changes a little. Swap the harness and the output changes completely: a different set of files reaches the model, a different prompt asks the question, a different parser decides what counts as a finding, and a different gate decides whether anyone has to act on it. The model is the cheapest component in that stack to replace and the least interesting one to argue about, which is why a review tool that will not show you its harness is asking you to trust the single part you cannot inspect.
A harness is everything that is not the model
Start with the size of the thing. On the vendor’s own measured runs, the default review recipe issues about 250 model calls at roughly 35,000 tokens each, and 96% of that input is served from cache and billed at 10% of the input rate [OURS, read 2026-10-14]. Those are harness numbers, not model numbers. A model has a rate per million tokens; a harness decides how many million tokens the job takes.
The distinction is not academic once you price it. One harness might send a forty-file pull request to a single model call with the whole diff pasted in; another fans the same pull request out across 250 focused calls with the surrounding context assembled per file. The two will find different things, finish at different times, and bill at rates that differ by more than the price gap between any two models you were thinking of comparing. That is the argument for looking at the harness first: it is the larger lever, and it is the one that does not appear on a pricing page.
What the harness decides before the model sees the diff
Four things are settled before a single token is spent. Which files enter the review, and which are skipped as generated or vendored. How the repository’s surrounding context is assembled. How the prompt is worded. And whether anything in the diff should be caught by a rule instead of by a model.
That last one is the cheapest and usually the most reliable. The guardrails that run by default cover secrets, personal data, prompt injection and code security [OURS], and a credential pasted into a diff is a string that a matcher can find without a model call anywhere near it. A harness that routes those cases to a language model has chosen to pay for a probabilistic answer to a question with a deterministic one.
Whether those guardrails run before or after the review is itself a harness decision, and it changes what the reader experiences. A secret blocked on the way in is a stopped merge with one clear reason attached. The same secret reported as one line among forty review comments is a merge that proceeds while somebody reads the other thirty-nine.
The prompt is the part you can read
Review quality is mostly a prompt question, and in most tools the prompt is the least visible component of the product. When a review misses a bug, you cannot tell whether the model failed or the prompt never asked. The page answers that with three claims stacked at the top of it — open engine, open prompt, open bill — and the prompt here is published, with the rules and merge gate on GitHub under MIT [VENDOR, read 2026-10-14]. A missed finding is therefore traceable to the sentence that should have caught it, which is a different kind of complaint from “the reviewer was not good enough”.
The demonstration on the page shows what that traceability looks like in practice. A cache key built from a workspace identifier and a wall-clock timestamp is replaced with one built from a charge identifier, and the reviewer’s comment on that hunk carries a severity tag rather than an adjective — the demo uses `P1`. The tag is a harness artifact. Severity vocabulary is defined by the review system rather than produced by the model, and a fixed vocabulary is precisely what lets a gate act on a finding automatically instead of asking a human to interpret a sentence.
Cache state is a harness property
The 96% cache share quoted earlier is the largest number in the review’s cost structure, and it is not something the model gives you. Caching rewards a stable prefix: the same instructions, the same repository context, the same conventions, in the same order, on every call [OURS]. A harness that rebuilds its prompt in a different order on each run, or that interleaves unrelated jobs through the same window, pays the full input rate for work it had already sent once.
Two consequences follow, and the second is the useful one. The first is that the same model behind two different harnesses can differ in cost by more than the gap between two model tiers, which makes model shopping a poor first move. The second is that the cache share is measurable from the run’s own accounting, as a ratio of two token counts, so it can be tracked as a regression metric the way test coverage is. The default recipe’s figure works out to about $0.28 per review [OURS]; that number moves the moment the cache share does, and nothing else on the page moves with it.
Swapping the model changes the rate, not the shape
Because the harness fixes the call count and the token shape, changing the model behind it applies a new rate to a volume that stays roughly constant. That is a real saving and sometimes a large one, but it is bounded by the spread of the rows you are willing to consider, and it does nothing at all about the two things that usually hurt more: how long the reviewer waits, and how many findings turn out to be false.
Latency is the clearest illustration. Provider-page medians for a first token run from 1600 ms on the OpenAI page and 1816 ms on DeepSeek, up through roughly 4000 ms to 5000 ms on the Qwen, Z.ai, Anthropic and Grok pages, reaching 5681 ms on Kimi [OURS, read 2026-10-14]. A review making 250 calls does not make them one after another, but the median still sets how long the slowest branch of the fan-out takes, and moving from the fastest row to the slowest is a change of more than three seconds per call. Prompt tuning does not recover that. Only the harness’s concurrency does.
The gate is where a harness becomes a policy
A review that nobody has to act on is documentation. The gate is the line between a comment and a merge that stops, and it is the part of a review harness people actually notice, usually by resenting it.
Two design choices decide whether the gate keeps its authority. The first is what it blocks on: a gate that fails on every finding teaches a team to click past it, while a gate that fails on one narrow severity class keeps its meaning for years. The second is where the rule lives. Here the rules and the gate are the MIT-licensed half of the product [VENDOR, read 2026-10-14], so a change to what blocks a merge arrives as a diff and can be reviewed, blamed and reverted like any other change. A gate configured through a console cannot be reviewed that way, and after a few months nobody can say why it blocks what it blocks.
The takeaway
Read a review tool as a harness with a model slotted into it and the questions sort themselves out. How many calls, how many tokens each, how much of that input is cached, what runs before the model, what the prompt says, and what the gate blocks. Six questions, five of which have nothing to do with which model is behind the thing. Changing the model is the easy lever and the bounded one. Changing the harness is harder, and it is where both the cost of a review and its usefulness are actually decided.
Sourcing note: the call count, token size, cache share, guardrail list, per-review figure and the MIT licensing of the rules and merge gate are the vendor’s own published account of its product and its measured runs, read 2026-10-14 [OURS]; the per-review figure is derived from the vendor’s own published arithmetic rather than a third-party measurement. Provider-page latency medians are OrcaRouter production telemetry, read 2026-10-14 [OURS]. Price and licence claims are vendor-published [VENDOR] and are checkable against the source repository.
