The Orchestrator

Boundaries are set before the system runs, not after the bill lands.

• Spend limits per task, per day, per environment. A hard ceiling per task catches runaway loops — the agent that retries forever, the fan-out that spawned two hundred sub-agents. A daily ceiling catches drift. A lower ceiling in the test environment than in production makes the staging system structurally incapable of the production bill.
• Model routing as a standing decision. Cheap steps run on cheap models: classification, routing, summarization, heartbeat checks. Judgment runs where judgment is needed. The toolkit survey’s routing example is the pattern — five percent frontier, the rest cheap, a 94 percent reduction. The routing table is where the architecture becomes an economic decision, and the orchestrator owns the routing table.
• Kill switches tied to budgets, not just errors. Every orchestrated system has an error kill switch. The budget kill switch is the one that matters more: the rule that pauses the workload — and pages a person, not a model — when spend crosses the line. Cost, like failure, is a condition the system must be able to detect about itself.
• The boundary the system cannot widen. Agents can optimize routing and context use inside a budget. The organization grants that budget, and the orchestrator owns the trade between spend and acceptable quality. No agent may raise its own ceiling. A system that answers every employee question well but spends four hundred fifty dollars where twenty-eight would do still needs an owner who will change the routing.

15.6.1 Budget as a permission

Chapter 6 drew the line — text is guidance, credentials are rules — and cost belongs on the credentials side of it. A system-prompt sentence such as do not spend more than five dollars on this task is advice to a component that cannot see its own bill. A budget the harness or the account enforces stops the run whether or not the model agrees. As of October 7, 2026 the enforcement points look like this.

At the run level, the harnesses count. OpenAI’s Agents SDK takes a max_turns argument on every Runner entry point and raises MaxTurnsExceeded when the loop exceeds it; None disables the limit, and an error handler can turn the exception into a controlled final output.⁷ LangGraph counts super-steps against a recursion_limit passed in the run config and raises GraphRecursionError at the ceiling; since version 1.0.6 the default is a thousand steps.⁸ Claude Code’s non-interactive mode has --max-turns, which has no default limit and exits with an error when it is reached, and — the one that counts in dollars — --max-budget-usd, which checks a client-side cost estimate, counts sub-agent spend against the same cap, refuses to spawn another sub-agent once the cap is hit, and stops background sub-agents still running. The estimate can differ from the bill, and resuming a conversation starts a new cap; earlier spend is not restored into it.⁹ The first two count model calls or graph steps, proxies for money that break the moment one step re-reads a million-token context. Claude Code estimates dollars. All three stop one run; none knows about the other four hundred the scheduler started the same hour.

At the account level, the providers count in dollars, monthly, and with different teeth. OpenAI distinguishes a spend alert, which notifies while traffic continues, from a hard spend limit, which makes affected requests fail with a 429 and an organization_spend_limit_exceeded or project_spend_limit_exceeded code; the limit is monthly, per organization or per project, and enforcement is not instantaneous, so recorded spend can slightly exceed the cap.¹⁰ Anthropic’s API tiers carry monthly spend caps of $500, $1,000, and $200,000, with negotiated limits on custom tiers. Crossing a tier cap returns 429; an organization can also set its own limit below the cap, per organization or per workspace, and requests past that limit return a 400 beginning “You have reached your specified API usage limits.”¹¹ OpenRouter, the routing service the toolkit survey used to read the market, enforces an account balance and an optional per-key credit cap, readable as limit, limit_remaining, and limit_reset, and returns 402 when either is exhausted.¹² The per-key cap is the most useful of the lot, because a key is something you can hand to one workload and nothing else.

Task platforms can add a useful middle layer. Linear now lets administrators set workspace-wide and per-user spend limits that reset daily, weekly, or monthly, pausing additional AI credit usage when a limit is reached.¹³ That is closer to the interval a weekend runaway needs, and it joins model and sandbox costs within the platform. It still needs a place in the wider budget when work also runs elsewhere.

At the workflow level, durable execution engines can bound time. Temporal’s Workflow Execution Timeout caps how long a workflow may stay open including retries; it defaults to infinite, and Temporal’s documentation says it generally does not recommend setting it, because workflows are designed to be long-running.¹⁴ A long-running order workflow and an unbounded agent loop need different policies. Put the loop’s time and spend limits on the work it performs, whether or not the durable workflow around it remains open.

Each control measures a particular scope. A monthly cap is a fence around the wrong interval for a runaway loop: a loop that starts Friday night can spend the month by Monday and stay inside the rule. A turn count is a fence around the wrong unit. A hard limit at the organization level stops the good traffic with the bad — which is why OpenAI’s documentation warns that hard limits “can interrupt production traffic,” and why Anthropic’s guidance for its Enterprise plan recommends group and per-user limits over an organization-wide one, “without the risk of cutting off your entire org if a limit is hit.”¹⁵ None of that argues against the controls. It argues for layering them: a per-run dollar cap in the harness for the loop, a per-key cap at the gateway for the workload, a per-project or per-workspace cap at the provider for the team, and the organization cap as the fence you hope never to reach. Each layer catches what the one inside it cannot see.

What the layering buys is that the budget kill switch above becomes a real object with a real owner. The budget_id in the cost record points at one of these limits; the budget_owner is the person who set it, who can raise it, and who gets paged when a run reports stopped_by_limit. That is the shape of a credential: granted by a named person, enforced by a system that does not read prose, revocable without consulting the component. A budget in a prompt has none of those properties. An orchestrator who has written one and stopped there has documented an intention, not built a boundary.