delegate_task: let the caller choose completionWake, or skip waking a parent whose prompt cache has expired #30155

Summary

When an async delegate_task child finishes, the server starts a new run on the parent thread (completionWake: "always", the default for mode: "async"). If the parent has been idle longer than the provider's prompt-cache TTL, that wake turn re-writes the whole parent context to the cache. The caller cannot choose a different wake policy: completionWake is not an argument of delegate_task, and settled_only is only applied to mode: "wait".

Request: let the caller choose the wake behaviour, and/or let T3 avoid waking a parent whose cache has expired.

Measurements (T3 Code 0.1.1, Claude provider, 1h cache — all cache writes were ephemeral_1h)

Parent idle gap = child completed_at minus the end of the parent's last run. Usage is from the first assistant record of the wake turn.

Every wake after a gap of 82 min or more was a full re-write (3 of 3); every wake after 47 min or less was a cache hit (8 of 8). I did not measure between 47 and 82 min, so the exact boundary is unknown; the split is consistent with a 1h TTL. Cases with a parent run active at completion were excluded.

How to reproduce

1. In a thread on a Claude provider with a large context (>200k tokens), call delegate_task with mode: "async" for a task that takes longer than the cache TTL (or end the parent's turn and let it idle for >1h while the child runs).
2. When the child completes, T3 posts Delegated task … [completed] into the parent and starts a run.
3. Compare cache_creation_input_tokens / cache_read_input_tokens on that run's first assistant message with the previous turn's.

Requested behaviour

Either or both:

1. A caller-selectable wake policy on delegate_task (for example completionWake: "always" | "settled_only" | "never", where the result is queued for the parent's next turn instead of starting one).
2. A server-side option to skip the wake when the parent's prompt cache is known to be expired (the same cache-expiry knowledge that idle compaction already uses), and deliver the result with the next user/parent turn.

Current workaround

A caller-side PreToolUse gate that denies async delegate_task unless the task declares an expected duration of 45 minutes or less, and routes longer work to a separate session that reports through a file. This works only for the one harness that supports hooks, and it relies on a self-declared estimate, so a server-side option would be more robust.

Related but different: #28505 and #23086 are about idle compaction and resuming a cold context on user return, not about child-completion wakes.