Advisor pattern: cap how often the expensive model gets called, and catch drift
Run a cheap executor with a rarely-consulted expensive advisor, but enforce a hard cap on advisor calls per task and a drift-check before the executor can keep going, so the benchmark's 63% discount doesn't quietly erode into nothing.
Run this workflow
CI-verified, 2/2 fixtures passing.
Build this with your agent
One copy-paste hands Claude Code, Codex, or Cursor the full recipe, steps included, nothing to fetch.
Intended Use
Anyone adopting the advisor pattern who wants the savings to be real, not assumed. CI validates the task config: a hard cap on advisor calls, a drift-check step required before the executor can continue past a step budget without a fresh check-in, and an effective-cost calculation from the actual call count (not the benchmark's assumed rate). No key, no model call. The actual advice and executor's work are fenced.
Not for
- Trusting 63% or 46% as your number, those are Anthropic's internal eval on two specific benchmarks (SWE-bench Pro, BrowseComp), not independently reproduced and not your workload's token mix
- Tasks where difficulty is spread evenly, the advisor pattern assumes hard reasoning concentrates at a few forks; if it does not, one check-in per task misses it and the executor drifts uncaught
- Simple tasks, if the job is easy, skip the pattern and run the cheap model directly; orchestration only pays off on hard, multi-step work
- Letting the planner grade its own plan, if the advisor and executor share a wrong assumption, the setup amplifies it with confidence; use an objective check where correctness matters
The Stack
Tested Against
Anthropic developer thread, July 8 2026 (advisor/orchestrator patterns)node@20Side effects & data flow
- Network
- none, local only
- Writes
- ./advisor-task.json
- Credentials
- none required
Prerequisites
- A cheap executor model and an advisor model (Sonnet 5 + Fable 5 in Anthropic's own example, or any pairing)
Steps
- 1
Declare the call budget and drift-check, and compute the real effective cost
Set a hard cap on advisor calls for the task, require a drift-check every N executor steps before it can continue without a fresh check-in, and record the benchmark's assumed advisor rate next to your actual one. CI checks the budget and drift-check are present and computes effective cost from the real call count, not the assumed rate. Running the executor and advisor is fenced.
cat > advisor-task.json <<'JSON' { "executor": { "model": "sonnet-5", "usd_per_mtok_out": 15 }, "advisor": { "model": "fable-5", "usd_per_mtok_out": 50 }, "max_advisor_calls": 3, "drift_check_every_n_steps": 5, "task": { "steps": 20, "advisor_calls_actual": 2 }, "benchmark_assumed_advisor_rate": "about once per task" } JSON node -e ' const fs = require("fs"); const c = JSON.parse(fs.readFileSync("advisor-task.json", "utf8")); function bad(m) { console.error("BAD: " + m); process.exit(1); } if (!c.max_advisor_calls || c.max_advisor_calls < 1) bad("set a hard max_advisor_calls, an uncapped advisor erodes the discount"); if (!c.drift_check_every_n_steps || c.drift_check_every_n_steps < 1) bad("set drift_check_every_n_steps so the executor cannot run unchecked forever"); const t = c.task || {}; const actual = t.advisor_calls_actual; if (actual == null) bad("record advisor_calls_actual so you can compare it to the cap and the benchmark assumption"); if (actual > c.max_advisor_calls) bad("advisor_calls_actual (" + actual + ") exceeds max_advisor_calls (" + c.max_advisor_calls + "), the budget was not enforced"); const steps = t.steps || 0; const checksNeeded = Math.floor(steps / c.drift_check_every_n_steps); if (checksNeeded > 0 && actual < 1) bad("task has enough steps to require a drift-check but no advisor calls were made"); const exec = c.executor.usd_per_mtok_out, adv = c.advisor.usd_per_mtok_out; const mixShare = actual / (steps || 1); const effRate = ((1 - mixShare) * exec + mixShare * adv) / adv; console.log("advisor OK: cap " + c.max_advisor_calls + ", actual " + actual + " call(s) over " + steps + " steps, drift-checked every " + c.drift_check_every_n_steps + "; effective cost ~" + Math.round(effRate * 100) + "% of pure-advisor rate (benchmark assumed " + c.benchmark_assumed_advisor_rate + ")"); ' - 2
Run the task and watch the real call count (the model step, not checked by CI)
Run the executor with the advisor wired in, honoring the cap and the drift-check. Compare advisor_calls_actual to the benchmark's assumed rate after the run: if your task pulled the advisor in more often, your real discount is smaller than 63%. If the job turns out to be easy, skip the pattern next time and run the cheap model alone. The run and the judgement are fenced.
Eval, 2 fixtures
Last passed: verified todayadvisor-okcontainstimeout 30s · max $0Expected:
advisor OK: cap 3, actual 2 call(s) over 20 steps, drift-checked every 5; effective cost ~37% of pure-advisor rate (benchmark assumed about once per task)clean-exitexit_codetimeout 30s · max $0Expected:
0
Results
Anthropic's own internal eval reported the advisor pattern (Sonnet 5 executes, Fable 5 advises about once per task) at roughly 92% of Fable's SWE-bench Pro score for about 63% of the price. The number is real but conditional on the word rarely: if difficulty is spread evenly rather than bunched at a few forks, one check-in per task does not capture it, and the executor can silently drift from the advice it was given between check-ins. The 63% is what Anthropic measured on their task, not a guaranteed discount on yours.
Did this work for you?
Our CI checks the setup runs. You tell us if the whole thing worked. Tell us straight.
Related workflows
- Read your token receipts right: volume and cost are different leaderboards
- Wire GLM-5.2 into Hermes: valid route, 64k-context check, no key in config
- Route through a gateway with a tested open-weights fallback
- ReMe pattern: define prospective memory as a schedule your agent can tick off
- Grind a huge one-time job overnight on a free tier's tiny rate limit
- Run GLM-5.2 for the bulk, escalate the hard turns to Opus 4.8
Liked this workflow?
Get new verified workflows in WebAfterAI, three issues a week (Tue, Thu, Sat).