v0.9.14: a worker's reserved report turn is spent by its own descendants — budget death returns nothing at all

[Hmbown]

Why this matters

agent start promises (tools/subagent/mod.rs:9526): "the worker reserves an allowance for one tools-disabled partial-report turn within those limits and falls back to recorded work when reporting is unavailable." In practice the reserve is computed against the same scope pool the worker's descendants spend from, so by the time a budget-exhausted worker wants its report turn, the reserve is already gone. The most expensive failure mode in the fleet: the parent gets nothing back from 200k–400k measured tokens — no partial result, no summary, not even a clean list of what was read.

Current behavior

• mod.rs:5506 — exhaustion is measured including descendants, and the same pool funds the reserved report turn.
• Two live deaths today, both with no hand-back report:
  • agent_f47bc95d (single worker): 209,619 tokens, 12 steps — "No model hand-back report: the bounded report deadline expired", zero workspace changes.
  • agent_601841f0 (spawned 5 of its own children): shared pool hit 434,546/400,000 across 6 workers — all starved together, zero workspace changes, not even the skeleton of its deliverable.

Desired behavior

1. The report-turn reserve is not shareable with descendants: a child's own reporting allowance is held out before descendants can spend, or accounted in a separate bucket the descendant pool cannot draw down.
2. On budget death the parent reliably receives the child's recorded-work fallback (files written so far, findings so far) instead of silence.

Acceptance criteria

• Reproduction: parent spawns a worker with a small token_budget whose task forces it to spawn a descendant; when the pool exhausts, the parent still receives a partial report (not a bare budget error)
• Unit/integration test over the budget accounting showing the reserve survives descendant spend
• The mod.rs:9526 description matches the implemented behavior

Related

• Sub-agents die mid-task with no warning, no hand-back and uncommitted work: four failure modes observed in one session #6194 / Workflow: default shared token budget (120k) kills real runs; children hard-die mid-task with no hand-back #6189 (sub-agent death with no hand-back — this is one of its mechanisms)
• Sub-agents cannot reliably execute: wall-time deaths lose uncommitted work, provider-route failures block dispatch, shell tooling needs workarounds #5529

[Hmbown]

Verified the sizing mechanism (crates/tui/src/tools/subagent/budget_handback.rs:4-17):

pub(super) const MAX_HAND_BACK_TOKENS: u64 = 8_192;
pub(super) fn token_reserve(limit: u64) -> u64 {
    let reserve = (limit / 10).min(MAX_HAND_BACK_TOKENS);

The reserve is capped at 8,192 tokens and sized as limit / 10 — as if the hand-back turn cost only its output. But exhaustion is metered as input + output including descendants (subagent/mod.rs:5506), and a hand-back is a full model turn whose cost is dominated by the child's accumulated context: a child holding ~200k of context needs roughly that much input to emit even one line. 8k cannot buy it. So the reserve is structurally guaranteed to fail for exactly the children that most need it — the read-heavy ones. Two live deaths today both produced "No model hand-back report" while mod.rs:9526 promises the reserved partial-report turn.

Three concrete fixes to fold into this issue's scope:

1. Size the reserve off the child's current context size (plus output cap), not limit / 10.
2. Run the hand-back turn against a truncated context (recorded-work summary), which is what "falls back to recorded work when reporting is unavailable" was supposed to mean.
3. Descendants must not be able to spend the pool holding the parent's report reserve (the 6-worker/400k starvation observed today).

Also worth recording here: step caps are not the lever — one step has no cost ceiling (a single grep/read of this repo can pull 100k+ input tokens; today's deaths were 12 steps/209k and 6 steps/434k). The missing control is a per-step input ceiling on what one tool result can pull into context. And the 75%-consumed pacing notice (mod.rs:370-410) is evaluated between steps and fires once, so a child at 60% that runs one huge read dies without ever seeing it — it warns exactly the agents that didn't need warning.

[Hmbown]

Adopted designs from the harness comparison (codewhale-ops/designs/HARNESS-COMPARISON-20260916.md, citations in-tree):

For the hand-back (this issue's core): codex-rs's shape is Completed(last_agent_message) (refs/codex/codex-rs/core/src/agent/status.rs:10) — the child's last agent message IS the deliverable, streamed as status events, never a transcript replay. On limit death the parent receives (a) that message / best-so-far, (b) a stamped stop reason with fail-closed usage attachment (grokbuild xai-grok-pager/src/headless.rs:355-385). If a report turn must run inside the dying child, run codex's pre-flight feasibility check (guardian/input_budget.rs:28-58): estimate the request; if it cannot fit the remaining pool, truncate/drop history to fit instead of firing a request the pool cannot pay for. That converts every budget death from "total loss" to "partial result," which is the acceptance bar here.

For the pool: one session-tree pool with weighted tokens (output×sampling_weight + non_cached_input×prefill_weight — cached prefill must not burn the pool; codex context/rollout_budget.rs:17-121) + threshold-LIST reminders delivered per thread (every descendant sees every crossing) + a spawn-depth cap (agent/registry.rs:87-91) so a child cannot recurse 5-deep into one pool. Tonight's 6-worker/400k starvation is exactly the un-weighted, un-depth-capped shape.