請求如何分配

每個請求最後都會落在某個供應商的某個帳號上。模型 id 決定供應商，你設定的順序決定帳號，接不了請求的帳號會被跳過。所有選項都用完時，請求會失敗，並回傳說明原因的錯誤。

1. 模型 id 決定供應商

在共用的 base URL /openai/v1 和 /anthropic 上，模型 id 的格式是 provider/model，從第一個 / 切開：

沒有 / 的 id，或前綴不是你擁有的供應商，會回 400 invalid_model。

在群組端點 /g/<group-slug>/... 上，模型必須和群組裡某個模型名稱完全相同。這個名稱接著展開成它的目標清單，依序排列。見 Groups。

proxy 會把請求整理成一份有順序的候選清單，每個候選是某個供應商上的一個帳號：

provider/model id：該供應商帳號池裡的每個帳號，順序跟 Providers 上顯示的一樣，Primary 排第一。
群組的模型名稱：它的目標，依清單順序。綁定帳號的目標只加入那一個帳號；標示 Any account 的目標會加入該供應商的整個帳號池，依帳號池的順序。

目前唯一的策略是 Ordered：第一個可用的候選接下請求。proxy 不會把流量平均分給各帳號。留在同一個帳號上，同一段對話就會一直打到同一個上游，prompt 快取才會持續有效。

在送出任何東西之前，符合以下情況的候選會被跳過：

被暫停。 最近送給它的請求以會導致暫停的方式失敗（見下表）。它會一直暫停到 Providers 上顯示的時間，或直到你按 Resume。
用量區間滿了。 供應商回報的任何一個區間，例如 5h 或 Week，到了 100%。帳號會顯示 Limit reached，等該區間重置才會恢復。Resume 無法略過這個限制。
不能服務這個模型。 目前只有一條規則：一般的 Claude Team 席位不能用 Fable 模型，所以 claude-fable-* 的請求會跳過它。它的其他請求不受影響。
帳號或供應商已經不存在，例如群組裡某個已刪除的自訂端點。

這些判斷只用 proxy 已經知道的帳號狀態，不會為此另外呼叫供應商。有流量時，用量會在背景更新，每個帳號最多每 2 分鐘一次。

供應商回傳錯誤時，proxy 會決定要不要試下一個候選：

供應商回應	帳號會怎樣	換下一個
`401`、`403`（登入或權限）、`402`（帳務）	暫停 5 分鐘	是
`429`（速率限制）	暫停到供應商的重置時間（能從回應或用量區間讀出時），否則 5 分鐘，最長 7 天	是
`520`、`522`、`524`（供應商自己的邊緣節點逾時）	只在這個請求中跳過。10 分鐘內第三次發生時暫停 30 秒	是
`529`（供應商過載）	不會暫停。約一秒後在同一個帳號重試一次	重試也失敗時換下一個。最後一個候選的 `529` 會原樣回傳
逾時內沒收到回應標頭（預設 3 分鐘）	只在這個請求中跳過	是
其他錯誤	不處理	否，錯誤直接回傳給客戶端

本機模型的電腦離線時，該供應商會暫停 60 秒。proxy 和 CLI 之間的其他連線問題，只會在那個請求中跳過它。

一個請求最多嘗試 8 次。供應商一旦開始串流回答，請求就會留在那個帳號上，因為中途切換會把兩份回答混在一起。

Logs 每個請求記一列，寫的是回應的帳號；請求失敗時則是最後嘗試的那個帳號。

情況	回應
前綴不是你擁有的供應商，或群組裡沒有這個模型	`400 invalid_model`
這個供應商沒有接上任何帳號，或沒有帳號能服務這個模型	`400 no_upstream_account`
有帳號，但全部被暫停或限制，或試過的每一個都以上表的狀態失敗	`503 upstream_unavailable`

503 會帶 Retry-After 標頭，值是最早恢復的帳號還要等幾秒，最多 60 秒。遵守這個標頭的客戶端會很快重試，而不是等到每週重置。使用 stream: true 時，因為回應已經開始，同樣的錯誤會以串流中的錯誤事件送出。所有錯誤代碼見錯誤訊息。