Modern Claude models have a reasoning-effort dial: low, medium, high. The default is high, and we were paying for it on routine jobs. We changed our model router to start at low effort and climb only when a cheap verifier rejects the answer. On a 17-task test set it came out 29% cheaper than the high default at exactly the same pass rate. The honest part: a flat low was cheaper still, and the climb only earns its keep on a narrow band of jobs.
What we did
A recent paper (arXiv 2610.34491) calls reasoning effort a "credence good":
you pay more for high effort on faith that it helps, but per task it often
does not. So we built the frugal version of the idea into Ruby, our model
router. A new function, chat_effort_escalating, runs a job at
effort=low first, hands the answer to a cheap deterministic
check, and only re-runs at medium, then high, if that check fails. The
check is the thing that makes it safe: do the tests pass, does the JSON
parse against the schema, is the self-reported confidence above a floor. No
judge model, no extra token spend to decide whether to climb.
Why it was worth doing
We measured it properly rather than trusting the paper. 17 verifiable tasks
(arithmetic, short logic, JSON extraction, classification, string work, two
genuinely hard ones), each with a deterministic pass check, run on
claude-sonnet-4-6 in four modes. Cost came from the real token
usage the API returns, not an estimate.
- high (today's default): $0.0209, 94.1% pass.
- medium: $0.0147, 94.1% pass.
- low: $0.0119, 94.1% pass.
- low-first-escalate: $0.0148, 94.1% pass.
Headline: low-first-escalate was 29.1% cheaper than the high default with a zero-point drop in pass rate, which clears the bar we set (at least 25% cheaper, within 2 points). And a flat low effort was 43% under high at the same accuracy. For this kind of routine routed work, effort barely moves the answer, exactly as the credence-good idea predicts.
What's still off
Escalation did not beat a flat medium default; the two tied on cost. It only pays when a low-effort answer fails on a task that a higher effort would then fix, and on our mix that never happened. The one task every mode failed (counting the letter "r" across two words) is a tokeniser blind spot that no effort level fixes, so the ladder burned all three rungs and still missed, costing more than plain low on that one job. The lesson: the climb is worth it only where some jobs genuinely need high effort, most do not, and you have a cheap signal to tell them apart. So we shipped the mechanism and left the premium-code tier at high effort, because our test set was routine work, not that tier. We will not flip a default we have not measured.
What's now in the stack
ruby.chat_effort_escalating(messages, category, verify, start_effort="low")plusEFFORT_LADDER = ["low","medium","high"].ruby.chat(..., effort=...)now takes an effort override to pin one call independent of tier.- Every escalating call lands in
workloft_audit_logasaction='chat_effort_escalating'. - Existing tier defaults unchanged, reversible from a backup, no regression.