One Guide, Three Bills

An orchestrator is upgrading a repository to a new SDK. The review takes ten turns:

1. inventory SDK imports;
2. identify the target version;
3. inspect the current adapters;
4. map affected call sites;
5. inspect the compatibility tests;
6. isolate one unresolved retry-policy question;
7. evaluate that question against the migration guide;
8. apply the required change;
9. run the compatibility checks; and
10. report the result.

The fixed reference is a 10,000-token API migration guide. None of its content is needed before turn 7. Every arm consumes the same guide verbatim and produces the same compatibility report:

verdict: incompatible
evidence:
  - guide: "Retry policy §4.2"
    code: "src/client/retry.py:41"
required_changes:
  - "Replace max_attempts with stop_after_attempt."

The report contract permits compatible, incompatible, or needs-context, at most three guide-and-code evidence pairs, and at most three required changes. Its serialized form is capped at 300 tokens. Every arm emits that same final report at turn 10, after the last billed input pass. The offloaded arm carries a byte-identical copy back from the child before turn 8; that extra resident copy is charged at the full cap rather than granted a flattering sample-size discount.

The bill counts only context changed by the relocation decision. The orchestrator's repository context, conversation history, and outputs are identical across all three arms, so they cancel. Residency follows the The Context Economy's convention: tokens multiplied by the inference turns that re-read them. These are input-side residency bills, not output-token or dollar totals.

Frontloading guarantees that the guide is present when turn 7 arrives, but it also charges all ten turns for material that has no work during the first six. The visible input is 10,000 tokens; its residency bill is 100,000 token-turns.

That total hides two different questions. Could the same actor load the guide later? Could a different actor consume the guide and return only the decision? Both reduce the orchestrator's bill, but they move it along different axes and leave different costs behind.

Read the three arms as two adjacent Cost Relocation comparisons, each with its own declared baseline:

• When-axis — frontloaded → Deferred Context: retain a 50-token data pointer and fetch the guide immediately before turn 7. The orchestrator remains the consumer.
• Who-axis — deferred → Subagent Offload: hold the turn-7 payment point fixed, retain a 100-token function pointer, and synchronously dispatch the compatibility decision. A child consumes the guide in three turns and returns the bounded report before the orchestrator begins turn 8.

The second delta is not credited with the first one's six clean turns: its baseline is the turn-7 deferred arm, so only the payer changes. Distillation is also held out of the comparison. The guide is not summarized, filtered, or rewritten before use — the relocated payload is the same 10,000 tokens in every arm. The 300-token report is the offload seam's declared output, not a transformed replacement guide; the other arms produce the same report only as their final output.

The baseline admits the guide at session start:

turns 1–6     guide resident; no guide-dependent work
turn 7        orchestrator evaluates compatibility
turns 8–10    orchestrator applies, verifies, and reports

The orchestrator and system bills are identical because no child window exists:

Shift 1 — move the payment point to turn 7

The 50-token data pointer stays resident for all ten turns. The fetch admits the guide immediately before turn 7, so the guide is re-read on turns 7–10:

One decision moved: when the guide enters the same actor's window. The first six turns stop paying for it; the last four remain unchanged.

Shift 2 — move the payer to a child

The orchestrator keeps a 100-token function pointer for ten turns. At turn 7 it emits a 200-token dispatch; the child receives that dispatch, the complete guide, and a declared 4,000-token boot context. The child takes three turns:

1. locate the governing migration clauses;
2. compare the affected code with those clauses; and
3. return the compatibility report.

The dispatch and 300-token return remain in the orchestrator's history for turns 8–10. They cross the seam; the guide does not:

Against the turn-7 deferred baseline, one decision moved: who consumes the guide. The child boot and seam traffic are consequences of crossing that actor boundary; hiding either would make relocation look like deletion.

The three arms hold the guide, task, trigger turn, and report constant:

Against frontloading, deferral cuts the orchestrator's relocation-related bill by 59.5% because six guide-free turns stay guide-free. Against that turn-7 baseline, offload moves another 38,000 token-turns out of the orchestrator — while costing the system 4,600 token-turns more. The protected window and the cheapest system are different objectives.

The total is not a punchline. A one-turn child would change the offload bill; a turn-2 trigger would change the deferral bill; a larger return would erode the who-axis win. The example fixes those inputs so the two relocation decisions remain legible.

Every table row carries its arithmetic. Recompute the two deltas before the invariants:

• When: frontloaded 100,000 → deferred 40,500; the actor and outcome stay fixed.
• Who: deferred 40,500 → offloaded 2,500 in the orchestrator and 45,100 system-wide; the turn-7 trigger and outcome stay fixed.

Then inspect the placement:

• The bill moved. Deferred guide tokens appear only on orchestrator turns 7–10. Offloaded guide tokens appear only in the child's three turns.
• The outcome held. All arms are stipulated to return the same capped compatibility report; the comparison grants no arm a quality or output-size advantage.

The arithmetic proves placement under the declared scenario. It does not prove that a model will trigger the fetch, pack the dispatch adequately, produce the same verdict in sampled runs, or preserve quality under real window pressure. Those are the parent's trigger-fidelity and outcome-parity residues. Nor are the declared 10,000-, 4,000-, 300-, 200-, 100-, and 50-token inputs population estimates. Change any input and the table recomputes; the later/elsewhere distinction survives.

Ask which bill the design must protect. Deferral buys clean early turns for the same actor. Offload buys a clean orchestrator window by opening and paying another one. The system ledger is what prevents that second move from masquerading as free work.

The migration guide is furniture. The comparison travels to policy manuals, schema catalogs, audit standards, and any other fixed payload whose consumer and consumption time can be separated.