proxy 記錄到 1,544 筆 HTTP 400 且呈重試風暴形狀，無任何機制在看 (sister concern from #33)

[kiki830621]

Problem

診斷 #33 時掃 gating 期間（2026-07-16 起 31 天）的 HTTP status 分佈，除了預期的 429，另外看到 1,544 筆 HTTP 400——而 plugin 目前沒有任何機制在看這個數字。

400 是 client 端錯誤（請求本身不合法）。跟 429 不同，重送一個 400 永遠不會成功，所以任何對 400 的重試都是 100% 純浪費。而實測顯示它確實是重試風暴的形狀：

叢集	期間	筆數	密度
2026-08-05 01:02 起	24.4 分鐘	396	~16 筆/分鐘
2026-07-29 07:07 起	29.5 分鐘	373	~13 筆/分鐘
2026-07-27 16:55 起	24.5 分鐘	198	~8 筆/分鐘

共 149 個叢集，最近一筆在 2026-08-17 10:55——現在進行式，不是歷史遺留。

model 分佈：claude-opus-5 1,442 / claude-fable-5 93 / claude-opus-4-8 9。

Type

feature

Expected

至少要能回答「這些 400 是什麼」。最小可行：proxy 對 400 的 response body 取樣記錄（error type / message），讓成因可辨識。之後才談要不要對它做任何事。

Actual

rate-state.jsonl 只記 status: 400，沒有任何 body 或 error type。所以現況只知道「有 1,544 筆」，不知道是什麼壞了。沒有任何 hook、nudge 或 report 消費這個數字。

Impact

• 每 24 分鐘 396 筆註定失敗的請求，是與 feat: usage 水位 limiter — 依方案別（Max 5x 90% / Max 20x 95%）達標即中斷一次，門檻可設定 #33 想攔的 429 浪費同類但完全未被涵蓋的一條浪費來源。
• 若成因是某個工具或 plugin 持續送出不合法請求，那是可修的 bug；目前完全不可見，所以沒人會去修。
• 誠實邊界：400 未必消耗 rate-limit 配額（多數 API 對格式錯誤不計費/不計額），所以這不必然是「額度浪費」，但確定是「時間與重試迴圈的浪費」，且指向某處有實際故障。

Related

• feat: usage 水位 limiter — 依方案別（Max 5x 90% / Max 20x 95%）達標即中斷一次，門檻可設定 #33 —— 本 issue 由該 issue 的診斷過程 surface；feat: usage 水位 limiter — 依方案別（Max 5x 90% / Max 20x 95%）達標即中斷一次，門檻可設定 #33 的 limiter 只處理 utilization 水位，不涵蓋 400。
• proxy 偵測 mid-stream SSE in-band error（HTTP 200 後才出錯，status 仍 200 看不到） #14 —— mid-stream SSE in-band error（HTTP 200 後才出錯）。同屬「proxy 看得到但沒在看的錯誤」家族，但層級不同：proxy 偵測 mid-stream SSE in-band error（HTTP 200 後才出錯，status 仍 200 看不到） #14 是 200 內含錯誤，本 issue 是明確的 4xx。
• proxy 記錄 transport failure（URLError：上游連不上時目前完全不寫 record） #15 —— transport failure（URLError，連不上時完全不寫 record）。同家族第三種。

---

Source: surfaced during /idd-diagnose #33 sister concern surfacing (Step 3.6)

Priority: P3（推定——使用者未指定。純觀測性缺口、無立即壞損，且成因未明前無法評估嚴重度。）