[Bug] Multi-step agent tasks stall for hours with zero user-visible feedback (ttft up to 243s, vanished requests, silent 429 retry loops)

Environment

• CLI: 0.29.2 → 0.31.1 (auto-updated during the affected period)
• macOS arm64 (darwin/arm64), Terminal TUI
• Provider: kimi (moonshot-cn, pay-as-you-go), model kimi-k3, thinkingEffort=high
• Dates: 2026-08-02 ~ 2026-08-03

Summary

During ordinary multi-step agent tasks (10+ LLM round trips), the CLI repeatedly appears completely frozen for tens of minutes to hours. Messages sent while it is "thinking" get no visible reaction. From the user's seat the session looks dead; the session diagnostic log (logs/kimi-code.log) shows three compounding causes.

Evidence from session logs

1. Extreme server-side latency

• Time-to-first-token routinely 30–60 s, peaks of 171.9 s and 243.3 s (serverFirstTokenMs=243271).
• Single responses streamed for 382.7 s and 412.4 s (streamDurationMs=412386) — one model turn can take 6–7 minutes.

2. Requests that never return (see also #1050)

2026-08-03T08:54:40.431Z INFO  llm request  turnStep=2.1
2026-08-03T08:58:57.273Z INFO  llm request  turnStep=3.1   # no response line for 2.1
2026-08-03T09:21:07.197Z INFO  llm request  turnStep=4.1   # again no response recorded

No error, no timeout, nothing surfaced in the TUI.

3. Silent retry loops on non-retryable errors (see also #2025)

The account was suspended (insufficient balance). Every turn then burned the full 10-attempt retry loop (~20 min per turn) before failing:

2026-08-02T17:13:57Z INFO  llm request  turnStep=1.10 attempt=2/10
... attempts 3/10 → 10/10 ...
2026-08-02T17:17:06Z WARN  llm request failed  errorName=APIProviderRateLimitError
  errorMessage="429 Your account org-*** <ak-***> is suspended due to insufficient balance, ..."

The 429 reason appears only in the session log — the TUI gave no indication.

Impact

A task that should take minutes stretches to hours. The user cannot distinguish "server is slow" from "request is lost" from "account is suspended", and abandons sessions believing the CLI is broken.

Suggestions

1. Client-side idle timeout on streaming requests, with a clear error and auto-retry (not silent hanging).
2. Visible turn status in the TUI: elapsed time, current retry attempt, and last server signal — so the user can tell slow from dead.
3. Fail fast on account-level 429s (suspended / insufficient balance): these are not transient, retrying 10 times over 20 minutes only hides the real fix (recharge) from the user.

Happy to provide full session logs; also cross-referenced in #1050, #1890, #2025.

Reproduce a 10+ round-trip task with the kimi provider and inspect logs/kimi-code.log, focusing on the missing response entries, long streaming durations, and repeated 429 attempts. Use the cross-referenced issues #1050, #1890, and #2025 for context. Done means slow or lost requests and account-level failures are distinguishable in the TUI rather than appearing frozen.