備援觸發後，Hermes 會保留目前的對話脈絡，改用備援模型繼續回應。但這個備援只在「當前這一輪對話」有效——下一次你發送新訊息時，Hermes 會再次優先嘗試主要模型。如果主要模型仍在被限制的狀態，就會再次觸發備援，於是你就又看到那行「switching to fallback」的警告 。

這就是為什麼這個警告會「反覆出現」：它並非一次性的提示，而是每一輪對話都重新執行一次的邏輯判斷結果。

為什麼偏偏是「sg claude opus 4.7 via custom」？

sg claude opus 4.7 via custom 這個標示透露了一個關鍵資訊：備援模型是透過**自訂端點（Custom Endpoint）**來連接的 。

在 Hermes 的架構中，自訂端點是儲存在 config.yaml 中的設定，允許使用者連接自己架設的 API 閘道或非官方支援的供應商 。備援鏈（fallback chain）同樣記錄在 config.yaml 的 fallback_providers 段落中 。

這裡有一個值得注意的問題：如果主要模型和這個自訂端點都依賴同一個上游服務、同一組 API 金鑰、或同一個資源池（pool），那麼當上游被限制速率時，即使「切換」到備援，實際上仍是走同一條路，自然也會一起卡住。 現有資訊不足以斷定你的環境確實是這個情況，但這是機率極高的可能性，值得優先檢查 。

常見的速率限制情境

速率限制並不只有「請求太多」一種面貌。根據 OpenClaw 及相關文件，HTTP 429 可能來自以下幾種情境：

1. 上游模型供應商配額用盡：這是最標準的場景，例如 Anthropic、OpenAI 等供應商在特定時間窗口內的 token/請求數量已達上限 。
2. 長上下文請求的額外限制：OpenClaw 官方文件明確指出，當請求的上下文過長時，可能觸發「Extra usage is required for long context requests」的 429 錯誤 。如果對話歷史很長或系統提示（system prompt）很大，就屬於這類情境。
3. 閘道層級的冷卻狀態（cooldown）：錯誤訊息雖然顯示為 rate limit，但實際上可能來自 OpenClaw/Hermes 內部的冷卻機制，而非上游供應商 。這種情況下，即使 API 本身正常，閘道仍會回報速率限制。
4. 用戶端或閘道金鑰過期／不一致：金鑰未正確放置在閘道主機的環境變數中，或閘道重啟後未讀取新的金鑰，也可能導致驗證失敗被歸類為速率限制類錯誤 。

具體的排查步驟

與其盯著那行警告乾著急，不如從以下幾個方向有系統地排查：

第一步：確認主要模型與備援鏈的設定

查看 ~/.hermes/config.yaml 中的以下段落：

• 主要模型：確認目前設定的是哪個 provider 和 model 。
• 備援鏈：fallback_providers 清單中列出了哪些備援組合 。每個項目需要同時有 provider 和 model 兩個欄位，缺一不可 。
• 自訂端點：如果備援是 via custom，檢查自訂端點指向的實際網址與金鑰是否與主要模型重疊 。

第二步：測試上游是否真的被限制

如果你的環境是透過 OpenClaw Gateway 或其他 API 閘道運作：

• 執行 openclaw gateway probe 來檢測閘道的可及性與驗證狀態 。
• 觀察原始錯誤代碼是否真的是 HTTP 429，或者有其他錯誤（如 401、403）。
• 用相同的 API 金鑰在閘道之外（例如直接呼叫 API 或用其他工具測試）確認上游是否正常 。

第三步：檢查長上下文因素

如果錯誤經常在對話長度變長後才出現，高度可能是長上下文請求觸發的額外配額限制 。此時可以嘗試：

• 精簡系統提示內容。
• 在對話過長時開新對話。
• 調整模型設定中的上下文長度限制。

第四步：確保金鑰與環境變數正確

如果你使用自訂端點或閘道（尤其是 systemd/launchd 管理的服務）：

• 確認 API 金鑰存放在 閘道主機上的正確位置（例如 ~/.openclaw/.env）。
• 在更改金鑰或設定後，務必重啟閘道服務 。
• 如果閘道和用戶端分開部署，確認兩邊的版本相容（protocol mismatch 也會導致奇怪的錯誤）。

第五步：考慮調整備援策略

如果你發現主要模型和備援模型確實共用同一個資源池，可以：

• 將備援模型改為另一個完全獨立的供應商（例如從 Anthropic 切換到 OpenRouter 上的模型），確保真正的冗餘 。
• 使用 hermes fallback add 指令，透過互動式選單設定新的備援 。

一個容易誤判的陷阱

有些使用者會看到「Rate Limit」就直覺認為只是暫時等待就好，但有時候問題根源其實是閘道內部的冷卻機制，並非上游的真實配額限制 。OpenClaw 的一個已知 Issue（#32828）就記錄了這種「假性速率限制」——API 實際上完全正常，但閘道仍然回報 rate limit 警告 。

如果你在閘道外測試 API 完全正常，但在 Hermes 中持續看到這個警告，可能需要檢查閘道的設定或重新啟動相關服務。

總結

那行「switching to fallback」不是問題本身，而是一個症狀。真正的病灶在於你目前的主要模型正處於無法服務的狀態。處理掉主要模型的限制，這行警告自然就消失了。

如果你需要，可以直接讓我看你目前的 config.yaml 內容，我就能明確指出哪個主要模型在失敗、sg-* 這個備援具體指向哪裡，以及為什麼每次對話都會回到原點。

備援觸發後，Hermes 會保留目前的對話脈絡，改用備援模型繼續回應。但這個備援只在「當前這一輪對話」有效——下一次你發送新訊息時，Hermes 會再次優先嘗試主要模型。如果主要模型仍在被限制的狀態，就會再次觸發備援，於是你就又看到那行「switching to fallback」的警告 。

這就是為什麼這個警告會「反覆出現」：它並非一次性的提示，而是每一輪對話都重新執行一次的邏輯判斷結果。

為什麼偏偏是「sg claude opus 4.7 via custom」？

sg claude opus 4.7 via custom 這個標示透露了一個關鍵資訊：備援模型是透過**自訂端點（Custom Endpoint）**來連接的 。

在 Hermes 的架構中，自訂端點是儲存在 config.yaml 中的設定，允許使用者連接自己架設的 API 閘道或非官方支援的供應商 。備援鏈（fallback chain）同樣記錄在 config.yaml 的 fallback_providers 段落中 。

這裡有一個值得注意的問題：如果主要模型和這個自訂端點都依賴同一個上游服務、同一組 API 金鑰、或同一個資源池（pool），那麼當上游被限制速率時，即使「切換」到備援，實際上仍是走同一條路，自然也會一起卡住。 現有資訊不足以斷定你的環境確實是這個情況，但這是機率極高的可能性，值得優先檢查 。

常見的速率限制情境

速率限制並不只有「請求太多」一種面貌。根據 OpenClaw 及相關文件，HTTP 429 可能來自以下幾種情境：

1. 上游模型供應商配額用盡：這是最標準的場景，例如 Anthropic、OpenAI 等供應商在特定時間窗口內的 token/請求數量已達上限 。
2. 長上下文請求的額外限制：OpenClaw 官方文件明確指出，當請求的上下文過長時，可能觸發「Extra usage is required for long context requests」的 429 錯誤 。如果對話歷史很長或系統提示（system prompt）很大，就屬於這類情境。
3. 閘道層級的冷卻狀態（cooldown）：錯誤訊息雖然顯示為 rate limit，但實際上可能來自 OpenClaw/Hermes 內部的冷卻機制，而非上游供應商 。這種情況下，即使 API 本身正常，閘道仍會回報速率限制。
4. 用戶端或閘道金鑰過期／不一致：金鑰未正確放置在閘道主機的環境變數中，或閘道重啟後未讀取新的金鑰，也可能導致驗證失敗被歸類為速率限制類錯誤 。

具體的排查步驟

與其盯著那行警告乾著急，不如從以下幾個方向有系統地排查：

第一步：確認主要模型與備援鏈的設定

查看 ~/.hermes/config.yaml 中的以下段落：

• 主要模型：確認目前設定的是哪個 provider 和 model 。
• 備援鏈：fallback_providers 清單中列出了哪些備援組合 。每個項目需要同時有 provider 和 model 兩個欄位，缺一不可 。
• 自訂端點：如果備援是 via custom，檢查自訂端點指向的實際網址與金鑰是否與主要模型重疊 。

第二步：測試上游是否真的被限制

如果你的環境是透過 OpenClaw Gateway 或其他 API 閘道運作：

• 執行 openclaw gateway probe 來檢測閘道的可及性與驗證狀態 。
• 觀察原始錯誤代碼是否真的是 HTTP 429，或者有其他錯誤（如 401、403）。
• 用相同的 API 金鑰在閘道之外（例如直接呼叫 API 或用其他工具測試）確認上游是否正常 。

第三步：檢查長上下文因素

如果錯誤經常在對話長度變長後才出現，高度可能是長上下文請求觸發的額外配額限制 。此時可以嘗試：

• 精簡系統提示內容。
• 在對話過長時開新對話。
• 調整模型設定中的上下文長度限制。

第四步：確保金鑰與環境變數正確

如果你使用自訂端點或閘道（尤其是 systemd/launchd 管理的服務）：

• 確認 API 金鑰存放在 閘道主機上的正確位置（例如 ~/.openclaw/.env）。
• 在更改金鑰或設定後，務必重啟閘道服務 。
• 如果閘道和用戶端分開部署，確認兩邊的版本相容（protocol mismatch 也會導致奇怪的錯誤）。

第五步：考慮調整備援策略

如果你發現主要模型和備援模型確實共用同一個資源池，可以：

• 將備援模型改為另一個完全獨立的供應商（例如從 Anthropic 切換到 OpenRouter 上的模型），確保真正的冗餘 。
• 使用 hermes fallback add 指令，透過互動式選單設定新的備援 。

一個容易誤判的陷阱

有些使用者會看到「Rate Limit」就直覺認為只是暫時等待就好，但有時候問題根源其實是閘道內部的冷卻機制，並非上游的真實配額限制 。OpenClaw 的一個已知 Issue（#32828）就記錄了這種「假性速率限制」——API 實際上完全正常，但閘道仍然回報 rate limit 警告 。

如果你在閘道外測試 API 完全正常，但在 Hermes 中持續看到這個警告，可能需要檢查閘道的設定或重新啟動相關服務。

總結

那行「switching to fallback」不是問題本身，而是一個症狀。真正的病灶在於你目前的主要模型正處於無法服務的狀態。處理掉主要模型的限制，這行警告自然就消失了。

如果你需要，可以直接讓我看你目前的 config.yaml 內容，我就能明確指出哪個主要模型在失敗、sg-* 這個備援具體指向哪裡，以及為什麼每次對話都會回到原點。