[App][Ultra][RFC] Add utility-aware admission control for proactive subagent delegation

What variant of Codex are you using?

Codex App (Desktop) on macOS; GPT-5.6 Sol with Ultra.

What feature would you like to see?

Problem: a hard cap does not answer whether a spawn is worth it

Ultra can proactively delegate work to child agents. Hard total-agent and depth limits are necessary safety rails, but they do not prevent low-value fan-out: a child may duplicate work already being done by the parent or a sibling, consume more usage than the latency it saves, or produce a result that never affects the final answer.

Existing issues separately cover hard limits, user-selectable delegation modes, capacity preflight, permissions, cleanup, and stale UI state. The missing layer is a runtime admission decision for each proposed proactive child:

Given the work already in flight and the remaining resource budget, is this child worth creating now?

Proposal: two-phase, utility-aware delegation

Proactive mode should not call the low-level spawn path directly.

Phase 1: proposal

Before a proactive spawn, the parent submits a structured proposal containing:

• a stable task fingerprint;
• the independent work axis and expected artifact;
• the parent plan node this child will satisfy;
• an estimate of wall-clock benefit;
• the requested token, tool-time, and wall-time budget;
• the capabilities required; and
• whether nested delegation is requested.

The model's estimates are advisory, not a security boundary.

Phase 2: host admission

A host-owned admission controller should atomically check:

• whether the same task fingerprint is already active anywhere in the lineage;
• whether the parent is already performing materially identical work;
• remaining lineage-wide budget, rather than only the immediate parent's count;
• current concurrency, residency, and tool/MCP pressure;
• estimated coordination cost versus expected parallel benefit; and
• the user's delegation policy.

When the value is unclear, the controller should prefer a single agent or ask the user instead of silently fanning out.

If admitted, the runtime issues a short-lived, one-use delegation receipt that reserves work ownership and resource budget before the child exists. All proactive spawn, fork, derive, or equivalent worker-creation paths should require the same admission check. Children should be non-delegating by default; a grandchild requires an explicitly allocated sub-budget and a new receipt.

Explicit user-requested delegation may bypass the utility threshold, but never the hard safety envelope.

Close the loop after completion

The scheduler should record privacy-safe aggregate outcomes for each admitted child:

• whether its result was delivered and incorporated into the parent synthesis;
• whether it duplicated parent or sibling work;
• actual token, tool-time, and wall-time cost;
• estimated versus observed latency benefit;
• terminal delivery success; and
• whether the child expired, was cancelled, or became stale.

These outcomes can tune the automatic admission threshold within hard user-selected bounds such as Conservative, Balanced, or Aggressive. The policy must remain resettable and explainable. Prompt text, repository contents, and child output do not need to be retained for this calibration; aggregate counters are sufficient.

This creates a closed loop:

1. propose;
2. admit or reject with a reason;
3. reserve a bounded lease;
4. execute;
5. measure actual utility;
6. adjust the next admission threshold.

User-facing delegation ledger

For each task, the App should expose a compact ledger showing:

• proposed child and spawn reason;
• admitted, merged, deferred, or rejected;
• duplicate-task detection;
• budget reserved versus spent;
• receipt/lease expiry;
• terminal state; and
• remaining lineage budget.

The same surface should explain why Ultra did not create a child. Reasoning effort and delegation policy should remain independently selectable; Ultra may influence the default admission threshold only when the user has enabled automatic delegation.

Acceptance criteria

• A simple or bounded task does not fan out merely because Ultra is selected.
• Two equivalent task fingerprints cannot be admitted concurrently in the same lineage.
• Every proactive child has an auditable admission reason, one-use receipt, bounded budget, and terminal outcome.
• Budget enforcement covers direct spawn, nested spawn, fork, derive, and equivalent worker-creation paths.
• Terminal completion or lease expiry atomically releases reserved budget and work ownership.
• The user can inspect and reset the calibration data and can always select Never or Ask first.
• Fixed hard limits remain authoritative and cannot be relaxed by learned behavior.
• No prompt-only rule is treated as the enforcement boundary.

Relationship to existing issues

This RFC is deliberately not another request for a fixed agent cap or a generic delegation toggle:

• #38237 covers hard total-agent/depth enforcement and lineage-wide cleanup.
• #21858 covers user-level Ask, Auto, and Never delegation policy.
• #23479 covers capacity/status preflight before spawning.
• #36381 proposes host-enforced authority ceilings and one-use permission receipts.
• #38353 applies leased ownership to MCP capabilities and runtimes.
• #37687 proposes execution ownership leases for duplicate long-running goals across tasks.
• #38478 covers completed children remaining visibly active.

Those are compatible foundations. This RFC focuses on the economic and scheduling layer between “automatic delegation is allowed” and “create this particular child”: deduplication, budget reservation, measurable utility, and feedback-based calibration.

Why this is different

A hard cap answers: “How many agents may exist?”

A user policy answers: “May Codex delegate automatically?”

This proposal answers two questions that remain open:

1. “Is this specific child worth its coordination and usage cost right now?”
2. “Did the child actually provide enough value to justify similar fan-out next time?”

中文说明：固定数量上限只能防止失控爆炸，不能防止低价值扩散。本提案增加“先提案、后准入、结束后回测”的闭环：每次主动创建子 Agent 前，运行时先检查任务是否重复、全链路预算是否足够、预期收益是否高于协调成本；只有通过后才发放一次性准入收据。任务结束后再根据结果是否真正被主 Agent 使用、实际额度消耗和节省时间，校准后续 Ultra 的自动扩散阈值。

Additional information

• ChatGPT/Codex Desktop: 26.810.41047 (build 6570)
• Bundled runtime: codex-cli 0.148.0-alpha.9
• Platform: macOS 15.6 (build 24G84), Apple Silicon / arm64
• Model/mode: GPT-5.6 Sol with Ultra
• Observed repeatedly as of 2026-08-14

I would be happy to help turn this into a smaller design note, deterministic admission tests, or an invited implementation PR.