[BUG] Network timeouts misclassified as context window errors

[dimensi]

Bug Description

HTTP timeouts from LLM providers (e.g. z.ai) are incorrectly classified as context window errors. This causes:

1. Useless history compression triggered on network timeouts
2. Misleading message to users: "Context window exceeded. Compressing history and retrying..."
3. No actual retry of the failed request

Steps to Reproduce

1. Configure picoclaw with z.ai (or any provider with slow/unstable network)
2. Send a message that triggers an LLM call
3. Wait for HTTP timeout (2 minutes)
4. Observe the error in logs:

   error=failed to send request: context deadline exceeded 
   (Client.Timeout exceeded while awaiting headers)
   

Expected Behavior

• Timeout errors should be recognized as network timeouts
• The request should be retried with backoff
• No false "Context window exceeded" message

Actual Behavior

• context deadline exceeded matches the broad "context" substring check in the retry loop
• Client.Timeout matches the broad "token" substring check
• Error is classified as a context window error
• History compression runs (pointless for a network issue)
• User sees "Context window exceeded" (misleading)
• After compression + retry fails, the error is not retried further

Root Cause

In pkg/agent/loop.go, the context window error detection uses overly broad substring matching:

isContextError := strings.Contains(errMsg, "token") ||
    strings.Contains(errMsg, "context") ||
    strings.Contains(errMsg, "invalidparameter") ||
    strings.Contains(errMsg, "length")

• "context" matches both context_length_exceeded and context deadline exceeded
• "token" matches both token limit errors and Client.Timeout

Fix

PR #681

[nikolasdehor]

The root cause analysis in this issue is spot on. The substring matching in pkg/agent/loop.go is way too broad:

isContextError uses strings.Contains for 'token', 'context', 'invalidparameter', 'length' -- all of which match unrelated errors.

This matches at least 3 categories of false positives:

• 'context deadline exceeded' (Go net/http timeout) matches 'context'
• 'Client.Timeout' matches 'token'
• Any authentication 'token' error also matches 'token'

The fix in PR #681 should use more specific patterns. Suggested approach -- use substrings that are specific to actual context window errors from providers:

• 'context_length' / 'context_window' / 'token limit' / 'max_tokens' / 'maximum context' / 'too many tokens' / 'reduce the length'

And separately, network timeout detection should be added to the retry logic with exponential backoff:

• 'deadline exceeded' / 'Client.Timeout' / 'connection refused' / 'no such host'

This way timeout errors get retried (which has a good chance of succeeding), while context window errors trigger compression (which is the correct remediation). The two paths are fundamentally different recovery strategies and should not share detection logic.

Also worth noting: this misclassification can cascade. If a timeout triggers history compression, the compressed history may lose important context, and then when the retry succeeds against the compressed history, the LLM gives a degraded response. The user sees bad output but has no idea it was caused by a transient network blip.

[dimensi]

Well yes? I can’t understand why you’re retelling to me the same same thing that I wrote? I fixed the bug in my MR, why won’t it be merged?

[nikolasdehor]

@dimensi Apologies for the redundancy — I should have explicitly referenced your PR #681 instead of restating the analysis. Your fix is the right approach.

Regarding merge status: this repo has had a pattern of PRs sitting in review limbo, especially when maintainers are busy with the channel system refactor (see PR #877, merged Feb 27). I would suggest pinging @yinwm or @alexhoshina directly on the PR with a short "ready for review" comment — that has worked for other contributors to get attention on stale PRs.