From 62800ddadba390e87816a9d5188152d6eb9c2be1 Mon Sep 17 00:00:00 2001 From: xxxigm Date: Tue, 4 Aug 2026 21:53:33 +0700 Subject: [PATCH] docs(delegation): note in-flight model waits count as progress Clarify that activity-timestamp ticks during a provider wait keep the staleness monitor from treating a slow completion as a wedged child. --- website/docs/user-guide/features/delegation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/user-guide/features/delegation.md b/website/docs/user-guide/features/delegation.md index 14fbad48058e3..625ecd7ec1f00 100644 --- a/website/docs/user-guide/features/delegation.md +++ b/website/docs/user-guide/features/delegation.md @@ -182,7 +182,7 @@ delegate_task( By default there is **no wall-clock timeout** on subagents. Children fail only from what they're actually doing — API errors, tool errors, or hitting their iteration budget — never from a delegation-level stopwatch. Earlier releases shipped a hard cap (300s, later 600s), which kept killing legitimately busy children mid-task: deep code reviews, large research fan-outs, and slow reasoning models routinely need more than 10 minutes while making steady progress the whole time. -Genuinely stuck children are still detected: the heartbeat staleness monitor stops refreshing the parent's activity when a child makes no progress (no API calls, no tool starts), letting the gateway inactivity timeout fire on a truly wedged worker. +Genuinely stuck children are still detected: the heartbeat staleness monitor stops refreshing the parent's activity when a child makes no progress (no API calls, no tool starts, and no activity-timestamp ticks), letting the gateway inactivity timeout fire on a truly wedged worker. An in-flight model wait still counts as progress — subagents refresh the activity clock while waiting on the provider, so a slow local / long-prefill completion is not treated as stalled. If you want a hard cap anyway (e.g. cost control on unattended cron-driven delegation), opt in per-install: