Summary
When the gateway restarts (SIGUSR1) and in-flight fetch requests are aborted (AbortError), OpenClaw retries the entire LLM run multiple times, re-sending 100k+ token context to Opus and burning cost, while showing misleading “API rate limit reached”.
Steps to reproduce
- Set primary model to anthropic/claude-opus-4-6 (Opus 4.6) on Telegram channel.
- Ensure the current session context is large (tens of thousands to 100k+ tokens).
- Trigger a gateway restart (e.g., via model switch/config.patch causing SIGUSR1, or running openclaw onboard --install-daemon).
- Send a normal message during/near the restart window.
- Observe “⚠️ API rate limit reached” or missing replies, while Anthropic console shows successful requests (tokens consumed). Also observe repeated isError=true retries.
Expected behavior
AbortError during restart/shutdown should not trigger full LLM-run retries. If Telegram delivery fails, retry only delivery (sendMessage) with backoff. Show accurate user-facing error messages (distinguish 429/402 vs abort/restart).
Actual behavior
Gateway restart/AbortError causes the run to be marked as error and retried multiple times (often 4 retries), re-sending the full session context to Opus each time. This causes large unexpected Opus cost. User sees misleading “API rate limit reached” even though Anthropic console shows successful requests with output tokens.
OpenClaw version
2026.2.14 (c1feda1)
Operating system
Ubuntu 24.04 (VM on Proxmox / R86S)
Install method
systemd service (openclaw-gateway), installed via OpenClaw CLI / npm global
Logs, screenshots, and evidence
Evidence from journalctl (openclaw-gateway) around incident:
[gateway] signal SIGUSR1 received
[gateway] received SIGUSR1; restarting
[openclaw] Suppressed AbortError: AbortError: This operation was aborted
[telegram] [default] starting provider (@wiipubot)
Also observed many runs with repeated `isError=true` (often 4 times per runId),
consistent with framework-level retries.
User-facing message often shown:
⚠️ API rate limit reached. Please try again later.
Anthropic Console shows successful Opus requests with output tokens, indicating
the error is not an upstream 429 but internal retry/exhaustion or delivery failure.
Impact and severity
Affected: Telegram users (DM) running OpenClaw gateway
Severity: High (unexpected Opus cost burn + missing replies)
Frequency: Intermittent but high risk during/near gateway restart windows (SIGUSR1 / onboarding / model switch)
Consequence: Gateway retries whole LLM runs (often 4 retries), re-sending 100k+ token context to Opus; user sees misleading "API rate limit reached".
Additional information
High severity: causes repeated 100k+ token Opus requests and unexpected cost spikes (~$10+ in one day). Also causes missing replies and misleading error messages.
Anthropic Console shows successful requests with output tokens during the incident; the error appears to be internal abort/restart + retry behavior rather than upstream rate limit.
Summary
When the gateway restarts (SIGUSR1) and in-flight fetch requests are aborted (AbortError), OpenClaw retries the entire LLM run multiple times, re-sending 100k+ token context to Opus and burning cost, while showing misleading “API rate limit reached”.
Steps to reproduce
Expected behavior
AbortError during restart/shutdown should not trigger full LLM-run retries. If Telegram delivery fails, retry only delivery (sendMessage) with backoff. Show accurate user-facing error messages (distinguish 429/402 vs abort/restart).
Actual behavior
Gateway restart/AbortError causes the run to be marked as error and retried multiple times (often 4 retries), re-sending the full session context to Opus each time. This causes large unexpected Opus cost. User sees misleading “API rate limit reached” even though Anthropic console shows successful requests with output tokens.
OpenClaw version
2026.2.14 (c1feda1)
Operating system
Ubuntu 24.04 (VM on Proxmox / R86S)
Install method
systemd service (openclaw-gateway), installed via OpenClaw CLI / npm global
Logs, screenshots, and evidence
Impact and severity
Affected: Telegram users (DM) running OpenClaw gateway
Severity: High (unexpected Opus cost burn + missing replies)
Frequency: Intermittent but high risk during/near gateway restart windows (SIGUSR1 / onboarding / model switch)
Consequence: Gateway retries whole LLM runs (often 4 retries), re-sending 100k+ token context to Opus; user sees misleading "API rate limit reached".
Additional information
High severity: causes repeated 100k+ token Opus requests and unexpected cost spikes (~$10+ in one day). Also causes missing replies and misleading error messages.
Anthropic Console shows successful requests with output tokens during the incident; the error appears to be internal abort/restart + retry behavior rather than upstream rate limit.