Cap the advisor, catch the drift, compute the real discount

The advisor pattern (a cheap model executes; an expensive model is consulted rarely) is only as cheap as the word "rarely". The user is about to adopt it on the strength of a benchmark number. Your job is to make the savings enforceable instead of assumed: a hard cap on advisor calls, a drift-check so the executor can't run unchecked, and an effective-cost number computed from what actually happened.

Steps

1. Write down the pair with real unit prices: the executor model and the advisor model, each with usd_per_mtok_out from the current pricing page (never from memory). The reference result this pattern leans on: Anthropic's internal eval had Sonnet 5 executing with Fable 5 advising about once per task, landing ~92% of Fable's SWE-bench Pro score at ~63% of the price. That is their task and their call rate, not the user's.
2. Set max_advisor_calls for the task, a hard cap, not a hope. An uncapped advisor erodes the discount one "just checking" call at a time.
3. Set drift_check_every_n_steps: past this many executor steps, the executor must get a fresh advisor check-in before continuing. Between check-ins the executor can silently drift from the advice it was given; this bounds how far.
4. After (or while) running, record advisor_calls_actual and compute the effective cost from the actual call mix. Compare it against the benchmark's assumed rate. If the task pulled the advisor in more often than "about once", the real discount is smaller than the quoted one, say by how much.
5. Run the proof below. It fails on a missing cap, a missing drift-check, or an actual call count that blew the budget.

Prove it