At the same $0.10 per 1M input tokens, Mouse-1 is the faster judge. In five head-to-head runs of the same agent on the same task, the median task waited 4.5 s on decisions with Mouse-1 against 10.6 s with Haiku 5.5, and finished in 18.6 s against 25.8 s. Per-task cost came out about even.
Most agent harnesses already make small judgment calls with a cheap model: "is this command safe?", "is the task done?", "which tools does this need?". Claude Haiku 5.5 is a common choice, and at $0.10 per 1M input tokens it matches Mouse-1's price. So we raced them.
The race
The same Claude Sonnet 5.5 agent fixed the same planted bug (expired API keys still authenticate) twice per pair, five pairs, interleaved. Code-writing turns were identical. Only the harness's decisions changed hands:
| Decision | Haiku 5.5 arm | Mouse-1 arm |
|---|---|---|
Gate on every bash call | Haiku call, JSON yes/no | One noul |
| "Is the task done?" when the agent stops | Haiku call | One noul |
| Which of 50 connected tools to load | Loads all 53, as harnesses do | 50 nouls in one call; kept 3 |
All ten runs passed the hidden grader.
| Median of 5 runs | Haiku 5.5 judge | Mouse-1 |
|---|---|---|
| Time waiting on decisions | 10.6 s | 4.5 s |
| Wall time per task | 25.8 s | 18.6 s |
| Total cost per task | $0.0241 | $0.0262 |
| Mean cost per successful task | $0.0403 | $0.0258 |
| Frontier input tokens | 31,928 | 9,745 |
Median per task, 5 runs, seconds · Lower is better
| Mouse-1 | 4.5 s |
|---|---|
| Haiku 5.5 judge | 10.6 s |
Why the time drops
Each decision is shorter. Haiku has to read the prompt and generate a JSON answer. Mouse-1 scores the options without generating anything. On a single yes/no gate sent 20 times to each from the same machine, the median round trip was 344 ms for Mouse-1 and 1353 ms for Haiku.
Bad "not done" verdicts are expensive. In one of the five Haiku runs, the agent reported that both test suites passed, and Haiku answered "not done" three times in a row. The agent kept working, the run took 80 seconds instead of about 25, and it cost $0.097. Mouse-1 accepted the finished work in every run.
Where the cost goes
The honest result on cost is a draw. The median Mouse-1 run cost slightly more (0.0262 vs 0.0241 dollars). The decisions themselves were not the difference: the median run spent $0.00042 on Mouse-1 decisions against $0.00062 on Haiku's. The rest is run-to-run variation in the agent's own model calls. The mean cost per successful task favours Mouse-1 (0.0258 vs 0.0403), almost entirely because of the one looping Haiku run.
Tool routing cut the frontier model's input from about 32k to 10k tokens. Prompt caching already bills repeated tool definitions at about a tenth of the normal rate, so on a task this short that did not turn into a saving.
How we measured
- Traces for every run are in
bench/race/runs/2026-10-20-haiku-judge-n5(bench/race/race.py). The agent was Sonnet 5.5 at medium effort; the Haiku judge ran at low effort through OpenRouter with a strict JSON schema. - Single-gate latency:
bench/race/latency.py, 20 interleaved calls per model from one laptop. - Five pairs on one task is a small sample. Read the medians as direction, not precision.
Sources
Checked October 20, 2026.
See also: Mouse-1 vs Claude Opus as a judge · Mouse-1 vs GPT-6 Sol · All comparisons
FAQ
Is Mouse-1 faster than Claude Haiku 5.5 for agent decisions?
Yes. With the same Sonnet 5.5 agent fixing the same bug, the median task spent 4.5 seconds waiting on decisions with Mouse-1 against 10.6 seconds with a Haiku 5.5 judge, and finished in 18.6 seconds against 25.8. On a single yes/no gate, Mouse-1's median round trip was a fraction of Haiku's.
Is Mouse-1 cheaper than Claude Haiku 5.5?
Per input token they cost the same, $0.10 per 1M. Haiku also bills output at $0.50 per 1M and Mouse-1 doesn't, but a judge's output is a few tokens. In our race the median total cost per task was about the same ($0.0262 with Mouse-1, $0.0241 with Haiku); the mean cost per successful task was lower with Mouse-1 ($0.0258 vs $0.0403) because one Haiku-judged run looped.
Why use a decision model instead of a small LLM as the judge?
A decision model scores the options directly instead of generating an answer, so it returns in about 100 ms and gives a calibrated probability you can threshold. A small LLM judge returns a yes or no after generating text, typically in about a second, with no probability.