處理 429 與重試，避免請求風暴
區分請求速率與並行數，避免無限重試，將任務輪詢與新生成提交分開控制。
技術核對日期:
RPM 不等於並行數
RPM 衡量一分鐘內的新請求，並行數衡量仍在處理中的工作。生成時間長時，即使 RPM 不高，也可能累積大量任務。接入端需要同時限制提交速率與進行中工作數。不要照抄截圖或其他帳號的限制：平台、金鑰、模型及上游限制可能不同，也可能調整。客戶端變快不會增加上游容量。
先判斷 429 的來源
HTTP 429 代表請求過多，伺服器可能附上 Retry-After，但不能假設一定存在。在 MaxAPI，應根據錯誤代碼與請求紀錄，區分入口拒絕、上游限流或任務失敗。暫停或減少新提交，保留既有 ID。一個使用者請求可能包含多次渠道嘗試，渠道次數不能代替自己的唯一工作數。
GET 與 POST 使用不同重試策略
暫時性的輪詢 GET 失敗，可以對同一任務進行有限次退避與隨機延遲重試；生成 POST 重送則可能建立新工作與額外費用。下載範例刻意在 HTTP 或網路錯誤時停止，不自動重新提交。日後加入重試前，先確認原任務是否存在，遵守有效的等待指示、限制總次數，並提供可見的失敗狀態。不要重試未修正的無效輸入，也不要規避安全限制。
分開觀測受理與結果
分別記錄唯一提交、受理任務、進行中任務、最終失敗與輪詢流量。受限診斷日誌可包含 request ID 與任務 ID，但排除金鑰、私人提示詞與完整參考圖網址。佇列增長時降低並行數，不要讓重試放大負載。自行設定有限的佇列容量與使用者等待策略，這些是應用控制，不是所有任務都能在固定時間內完成的保證。
各模型參數
這是公開設定快照，不代表即時可用性。參數、支援路由與參考圖限制請查看各模型頁面。
- Gemini 3.1 Flash Image Preview
google/gemini-3.1-flash-image-preview - Nanobanana Pro
google/gemini-3-pro-image-preview - GPT Image 2
openai/gpt-image-2