Proxying Reservations for Sub-Agents on an Agent Platform

Do not divide the pool evenly. Fan-out multiplies fixed overhead: every spawned sub-agent is a fresh model context that may need to carry system instructions, repo instructions, tool schemas, the skill catalogue, and the delegated task before it does any useful work the Codex subagent fan-out issue. Five agents investigating five small slices of the same repository can each reload substantially the same baseline, so an even split over-provisions agents that will never spend it.

A workable decision rule, expressed as constants you tune per provider:

A worked example. Suppose the parent run is granted 500,000 capacity units in USD micros, and the platform spends 14,600 per worst-case call at cache-write rates for a 1,200-input, 250-output request, which settles near 10,000 once the real token mix returns per-run budget reservation. Spawn four research workers:

• Each gets 36,500 (2.5 x 14,600), flooring to 3 calls.
• Total allocated: 146,000, or 29 percent of the pool.
• The parent keeps 354,000 as unallocated headroom.
• If two workers finish having spent 21,000 each, 31,000 returns to unallocated headroom at close.

That last step is the whole point of settlement: without a refund, worst-case holds compound turn over turn and the effective budget collapses to maximum / worst-case ratio after a handful of calls per-run budget reservation.

Every state change is an entry. Treat the ledger as the system of record; the reservation row is a materialized view you can rebuild from it.

{
  "entry_id": "led_01J8Z4M2QK",
  "request_id": "req_01J8Z4M1AB",
  "parent_run_id": "run_7741",
  "subagent_id": "research-agent-3",
  "action": "hold",
  "units": 14600,
  "currency": "usd_micro",
  "reason": "admission_worst_case",
  "balance_after": 231400,
  "ts": "2026-01-14T09:12:03.881Z",
  "idempotency_key": "req_01J8Z4M1AB:hold"
}

Three conventions keep attribution clean.

Units, not floats. Sub-cent arithmetic on floats accumulates rounding across hundreds of settlements, so the reference implementation runs on exact fractions per-run budget reservation. Store integer micros or tokens and format at read time.

Idempotency keys on every write. A retried HTTP call to the broker must not create a second hold. Key on request_id plus the action, and reject duplicates with the original entry returned.

Four actions only. grant (allocation created at spawn), hold (admission check passed), settle (actual cost moved from held to spent, delta refunded), release (allocation closed, remainder returned to headroom). If you are tempted to add a fifth action for a special case, you probably need a new reason on an existing action instead.

Then reconcile on a schedule. Aggregate the ledger by subagent_id for the run and compare against what the parent platform believes it consumed. When they disagree, the ledger wins, because it was written before the spend happened rather than sourced from a provider dashboard that reports only aggregate usage token budget controls.

A practical note on where the numbers come from: two writers have reported changing the arithmetic of multi-agent spend more by narrowing context and tiering models than by any cap. One team running six agents described going from roughly 75 dollars a month to 35 with tiered models, then to 18 with prompt caching and sub-agent timeouts the Dify discussion thread. Those figures are self-reported and workload-specific, but the direction is the same as the per-run reservation guidance: cap first, then optimize what you cap.

Overrides arrive from the parent platform, not from the sub-agent. A parent might raise a child's ceiling because the child found real work, lower it because a fan-out is burning capacity, or zero it to halt a looping agent. The mistake to avoid is letting the platform call the downstream service directly to "top up" allowance, which silently desynchronizes the ledger.

Expose exactly one endpoint:

POST /v1/reservations/{subagent_id}/override
{
  "override_id": "ovr_9912",
  "requested_by": "parent:run_7741",
  "new_granted": 60000,
  "reason": "worker_found_scope_beyond_plan",
  "expected_version": 4
}

Rules that make it safe:

• Writes a ledger entry, always. Every override produces a grant or release entry with the reason string, so the audit trail never has an unexplained balance change.
• Version check required. expected_version makes concurrent overrides fail loudly rather than last-writer-wins. A parent and an operator policy engine overriding the same child at the same instant is a real scenario once you have any automated guardrails.
• Deny by default below spent. A new ceiling lower than spent is legal, but it immediately puts the child in draining: in-flight requests settle, new admissions are refused. This is graceful degradation rather than hard termination, so partial task progress is retained token budget controls.
• Cap the override itself. The parent cannot raise a child beyond the parent's own unallocated headroom plus the child's current hold. Otherwise overrides become a way to breech the pool the broker exists to protect.
• Rate limit overrides. Not because they are dangerous individually, but because an agent loop that discovers the override endpoint will call it. The thundering herd pattern applies to overrides as much as to 429 retries: nine agents retrying at the same instant triggered a second and third wave of rate limit errors and burned a 5,000 request hourly quota in 90 seconds in Dresher's logs 9 AI Agents, One API Quota.

One more override to support: platform-level kill of a whole parent run, which closes every open reservation in one transaction and writes a release entry per child with the same reason. Cleaning up twenty orphaned reservations by hand at 3 a.m. is the failure mode you are preventing.

The ledger answers "what was spent by whom." The decision log answers "why did the broker say yes or no." Keep them separate but joinable on request_id.

{
  "decision_id": "dec_01J8Z4M1AB",
  "request_id": "req_01J8Z4M1AB",
  "parent_run_id": "run_7741",
  "subagent_id": "research-agent-3",
  "action": "allow",
  "priced_worst_case": 14600,
  "available_before": 246000,
  "available_after": 231400,
  "reason": "admission_worst_case_cache_write_ceiling",
  "pricing_table_version": "pt_2026_01",
  "decided_at": "2026-01-14T09:12:03.879Z"
}

Field discipline worth adopting:

Refusals are the records you will read most. A spike in denials for one subagent_id is the earliest signal of a runaway loop, earlier than a provider dashboard, which reports after the fact. Alert on anomaly rather than outright failure: a sudden jump in token consumption can indicate a reasoning loop even when every individual call succeeded Fastio's observability checklist. Pair that with a loop signal based on call signatures (tool name plus arguments) rather than raw call volume, because a legitimate planning agent issues many distinct calls while a broken one repeats a few token budget controls.

Shipping this to production usually happens in two steps. First, run the broker in shadow mode: it prices and logs every decision but forwards all traffic, then you compare its refusals against what actually happened. Second, turn on enforcement for one sub-agent class at a time. University of the estimate accuracy matters less than the invariant holding by construction: cumulative spend never exceeds the granted ceiling per-run budget reservation.

Unbounded recursion. A sub-agent spawns a sub-agent that does not have a reservation because the broker only meters calls it sees directly. If your platform allows grandchildren, the broker must require a reservation ID on every spawned agent and reject spawns that do not present one, or the delegation fan-out race documented in budget-overrun incidents simply moves one level down Token Budgets: an empirical catalog.

Reservations that outlive their run. An orphaned hold is capacity nobody can use. Sweep on a timer: close any open reservation whose parent_run_id is terminal upstream, and write a release entry with reason orphan_sweep.

Trusting the model to know its budget. Agents are poor at estimating their own remaining allowance; a benchmark that trained agents to predict their budget interval found coverage capping well below certainty, so the broker must price externally from its own table per-run budget reservation. This also means the broker must fail closed: if actual cost exceeds the hold, or returned usage is malformed, treat it as an overspend and block the run rather than warning.

One counter shared by all tenants. Provider limits are velocity controls, not budget controls. A per-process counter breaks under concurrency, is lost on crash, and does not survive restarts Cycles on hard limits. Use a shared store with compare-and-swap, or an existing gateway that already does hierarchical quotas per team and per key five LLM rate-limiting tools compared.

Over-tight caps. Aggressive thresholds terminate valid multi-step work. Test enforcement against real workloads before rollout, since under-tuned caps fail to stop loops and over-tuned caps kill legitimate research runs token budget controls.

If you would rather not operate the metering and routing layer yourself, Quanta Inference puts text, image, video, audio and embedding models behind one OpenAI-compatible API key with prepaid US dollar pricing, which gives the broker a single upstream to price against: https://quantaintelligence.ai/inference. The broker pattern in this article then wraps a much smaller surface than a per-provider integration.