ZeroClaw allocates dedicated retry budgets for streaming recovery and bounds task log growth

ZeroClaw contributors opened PR #10803 on September 21, 2026, significantly improving the runtime's resilience against model provider stream failures. During high-throughput agent operations, upstream model providers frequently encounter transient transport interruptions, HTTP 429 rate limits, or 503 service overloads while streaming tokens. Previously, ZeroClaw's stream recovery loop lacked fine-grained error classification, treating transient provider throttling as fatal errors and aborting complex agent runs without retrying. PR #10803 equips single-candidate stream recovery with an explicit, configurable retry budget and integrates an overload classifier that distinguishes temporary upstream throttling from permanent protocol rejections. In tandem, PR #10931 bounds stdout and stderr log file accumulation for Windows scheduled tasks, preventing runaway disk consumption on long-lived daemon hosts. Meanwhile, issue #10981 reveals an adapter bug where outgoing WhatsApp images omit jpegThumbnail data and dimensions, causing mobile devices to render empty message cards, while RFC #10970 proposes host-scoped admission control and per-agent resource limits for multi-agent servers.

The facts

- PR #10803 assigns dedicated retry budgets to single-candidate stream recovery routines in ZeroClaw's Rust runtime. - Implements an upstream overload classifier to differentiate transient 429/503 stream drops from fatal protocol errors. - PR #10931 enforces log size limits on Windows task stdout and stderr files to prevent silent host disk exhaustion. - Issue #10981 diagnoses outgoing WhatsApp media drops where missing thumbnail metadata renders blank message placeholders on phones. - RFC #10970 outlines host-level admission control mechanisms to throttle concurrent agent processes on shared infrastructure.

Why it matters

Network and provider volatility is the primary cause of unassisted agent workflow aborts. A transient WebSocket disconnect or five-second upstream rate limit should never invalidate hours of accumulated planning and execution context. By granting stream recovery explicit retry budgets and intelligent classification, runtimes can self-heal through temporary provider dips. Similarly, unattended background daemons must regulate their own log footprints to prevent mundane disk exhaustion from crashing critical host infrastructure.

Current

Inspected on 2026-09-21. The ZeroClaw stable-channel baseline is v0.8.5 published 2026-09-05T07:31:19Z. The primary source was open (not merged) when captured. Mainline merges, open proposals and packaged releases are distinct availability states; the release baseline does not establish that a proposal has shipped.

Evidence

Primary evidence: zeroclaw-labs/zeroclaw PR #10803 (https://github.com/zeroclaw-labs/zeroclaw/pull/10803). Supporting context: zeroclaw-labs/zeroclaw PR #10931 (https://github.com/zeroclaw-labs/zeroclaw/pull/10931); zeroclaw-labs/zeroclaw issue #10981 (https://github.com/zeroclaw-labs/zeroclaw/issues/10981); zeroclaw-labs/zeroclaw issue #10970 (https://github.com/zeroclaw-labs/zeroclaw/issues/10970). The source bodies and linked context were inspected. Test results quoted from contributors remain attributed reports, not independently reproduced experiments.

Operator take

Stream recovery must be resilient by default. Autonomous agents running without human supervision cannot afford to surrender on the first dropped token chunk. ZeroClaw operators should tune stream retry parameters to accommodate provider volatility and ensure log rotation boundaries are active on all background service runners to maintain long-term host health.

Caveat

PR #10803 and PR #10931 are open proposals awaiting maintainer sign-off. WhatsApp channel media issues documented in issue #10981 require image pre-compression and manual thumbnail attachment until native adapter metadata generation is patched.