[FEATURE] durable sub-agent execution log + limit-aware dispatch (work is silently lost when the usage wall hits mid-fan-out)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Problem

When orchestrating a long task by fanning out across delegated sub-agents
(Task tool), an in-flight sub-agent killed by the 5-hour usage wall loses all
its work, and there is no durable record to resume from. Two distinct gaps:

1. No durable execution log. A sub-agent's work lives in its return message.

If the window resets before that message is returned, completed-but-unreturned
work is unrecoverable — even when the sub-agent had effectively finished. There
is no on-disk log the orchestrator (or I, on resume) can read to know what the
sub-agent had done.

1. No limit-aware dispatch. The orchestrator will start sub-agents it cannot

possibly finish before the wall. There's no pre-flight signal ("you have ~X of
the window left; this dispatch won't bank") and no way to bound concurrency to
what can complete in the remaining budget.

Proposed Solution

Requested

• A persistent, on-disk execution log per sub-agent (inputs + incremental

progress/output), written as work happens — so an interrupted sub-agent is
recoverable instead of lost with its return message.

• A budget/remaining-window signal available to the orchestrator before each

dispatch, so it can avoid starting work that can't bank, and bound concurrency
to the remaining window.

Current workaround

I make the work resumable myself: each delegated unit commits within budget, the
worklist is regenerable on demand (so a kill costs one uncommitted unit, not the
plan), and any progress journal holds results inline rather than pointing at the
sub-agent's volatile return message. This works but is entirely user-side
scaffolding for what is really a harness-level durability gap.

Alternative Solutions

Manually monitoring and control aiming to avoid side effects.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

Repro (generic)

1. Start a large refactor delegated across, say, 6 sub-agents, one commit per unit.
2. Let the orchestrator dispatch them across the window without re-checking budget.
3. The 5-hour wall hits mid-fan-out: the in-flight sub-agent(s) are killed and any

not-yet-started ones never run. The killed sub-agent's work is gone with no log
to resume from.

Observed: the sub-agents that committed before the wall survived; the ones still
in-flight lost everything, regardless of how much budget they'd individually spent.
The kill axis is fan-out width and un-persisted state, not total token spend.

Additional Context

Environment

• Claude Code version: v2.1.179
• Plan: <Pro / Max 5x / Max 20x>
• OS: Linux