The Orchestrator

The bill for a workload is not one number. It is a stack of behaviors, and each one is a design decision someone made:

• Tokens in and out. The obvious line. Every run reads context and produces output, and both are metered. Chapter 5’s price list covers the spread as of late September 2026: at the flagship list, GPT-6 Astra and Claude Fable 5.1 at $10 input and $50 output per million tokens; one generation down, GPT-6 Sol and Claude Opus 5.5 at $2 and $4 input, $10 and $20 output; at the cheap end, open-weight tiers under a dollar for output. Same job, order-of-magnitude different bills.
• Cached and repeated context. A system that re-reads the same context every run pays for it every run. Caching discounts it; memory that persists outside the model avoids it entirely — which is why Chapter 5 treated memory as an economic decision as much as a capability one.
• Tool calls and side effects. Searches, API calls, and sub-agents each carry their own price — some metered, some just slow.
• Retries and failures. A failed run is not a discounted run; it is a full-price run whose output got thrown away. Nondeterminism means the same task’s cost varies run to run, and a workload where one attempt in three fails costs one and a half times what the sticker suggests.
• The always-on tax. Heartbeats, watchers, and scheduled checks run whether or not there is work. Chapter 5’s arithmetic: a component with an hourly heartbeat re-reading a large context costs about a dollar a day on a cheap open-weight model and about seventy-five dollars a day on a frontier flagship — and a fleet of a thousand turns that into a thousand versus seventy-five thousand dollars a day, for the same job.

Itemize the bill this way and each line turns out to be a lever the orchestrator controls: what context the run reads, how long memory persists, which model the step runs on, whether a failed run retries, and whether the heartbeat exists at all. The bill is an architectural document that happens to be denominated in dollars.