OpenRouter Fusion Flash API：狀態、設定與 400 錯誤排解

搜尋OpenRouter Fusion Flash API，通常是想使用速度較快的 Fusion 預設，或正在處理 HTTP 400 錯誤。問題在於，官方文件列出的是 openrouter/fusion-flash，但即時模型清單未必會出現這個 ID。因此，正式整合前，務必先在自己的帳戶環境確認這個別名是否真的可用。

OpenRouter Fusion Flash 目前到底能不能用？

官方的 Fusion Router 文件，將 openrouter/fusion-flash 列為獨立的模型 slug，並說明它其實是採用 general-fast 預設的 Fusion 路由。這個預設主要針對更快的代理式互動，使用延遲表現較一致的模型面板。

同一份官方指南也說明，標準 Fusion 會讓面板中的模型平行回答，再由分析模型比較共識與分歧，最後交給外層模型撰寫回覆。Fusion Flash 是這套複合式路由器的快速預設，不是某一家供應商的單一模型。

本指南於 2026 年 9 月 11 日取得的即時 OpenRouter 模型目錄中，包含 openrouter/fusion，但沒有單獨列出 openrouter/fusion-flash。有使用者在 X 上回報了完全相同的情況：

「文件說 openrouter/fusion-flash 是獨立列出的模型，並且應該在 /api/v1/models 中有自己的項目，但目前 API 呼叫會回傳 400 錯誤：fusion-flash is not a valid model ID。」— @PeterDaveHello

這只是使用者回報，並非 OpenRouter 的官方確認。OpenRouter 官方文件確實介紹了 Fusion，但本指南查到的官方公告中，沒有任何一則確認 Fusion Flash 已獨立推出或遭到撤回。最穩妥的結論是：文件中有記載，但整合前仍要確認即時可用性。

開始排查程式碼前，先確認這些事項

使用應用程式實際採用的同一組金鑰與環境，查詢模型目錄：

curl https://openrouter.ai/api/v1/models \
  -H "Authorization: Bearer $OPENROUTER_API_KEY"

在 JSON 中搜尋完整字串 openrouter/fusion-flash。不要只根據模型頁面、SDK 的自動完成清單或快取中的整合資訊來判斷可用性。OpenRouter 的模型文件將模型目錄視為目前模型識別碼與支援參數的依據。

官方狀態頁面也值得查看，但平台整體狀態正常，不代表某個路由別名當下就能使用。狀態儀表板回報的是 Chat API、Data API 等廣泛服務元件；即使一般 Chat API 正常運作，仍可能單獨出現別名不存在或設定不一致的問題。

OpenRouter Fusion Flash API 的最小設定

先從最精簡的 Chat Completions 請求開始。第一輪測試先拿掉 SDK 轉接層、工具結構、串流，以及自訂 Fusion 設定，才能縮小問題範圍。

export OPENROUTER_API_KEY="your-key"

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/fusion-flash",
    "messages": [
      {
        "role": "user",
        "content": "Reply with the word: ready"
      }
    ],
    "stream": false
  }'

這段範例展示了端點與標頭；第一次測試請保留 stream: false，這樣比較容易完整檢視錯誤內容。

如果別名出現在 /api/v1/models，而且這個請求能成功，再逐一加回應用程式原本使用的欄位。若別名根本不存在，就不要繼續修改提示詞，或不斷重送同一個請求。可以改用文件所述的等效設定進行診斷：

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/fusion",
    "plugins": [
      {"id": "fusion", "preset": "general-fast"}
    ],
    "messages": [
      {"role": "user", "content": "Reply with the word: ready"}
    ],
    "stream": false
  }'

這個替代方案可以確認 Fusion 路由與快速預設是否能正常連通，但不能證明別名與明確設定在每個後端細節上完全相同。

OpenRouter Fusion Flash API 400 錯誤排查順序

400 通常代表請求遭拒，或供應商拒絕處理；確切原因仍要看回應內容。它和 500 服務中斷不同，也不同於 HTTP 200 但 Fusion 內部操作失敗的情況。按照以下順序測試，每一步都只回答一個問題，排查會更有效率。

1. 讀取完整錯誤內容

把回應保存下來，不要只記錄 400 Bad Request：

curl -i https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"openrouter/fusion-flash","messages":[{"role":"user","content":"ready"}]}'

留意錯誤代碼、訊息、供應商名稱、請求或生成 ID，以及其他中繼資料。若看到「fusion-flash is not a valid model ID」，通常指向模型探索或推出狀態不一致；若是「Provider returned error」，則代表請求已進入某條供應商路徑，但在該處遭到拒絕。若 400 完全沒有細節，應該查看 OpenRouter Activity 紀錄，不要靠猜測處理。

2. 確認模型 ID 完全正確

模型識別碼是區分大小寫的字串。將請求中的值與即時 /api/v1/models 回應逐字比較，包括標點符號與斜線。清除應用程式設定中的過時別名，也不要擅自把它替換成猜測中的 Gemini 或其他 Flash 模型名稱。

以下這張診斷對照表很實用：

3. 移除不支援的欄位

只送出 model、messages、stream: false，以及兩個必要標頭。接著依照以下順序逐步加回欄位：

1. temperature 或推理設定。
2. plugins 與 Fusion 預設。
3. 自訂的 analysis_models 或分析模型 model。
4. tools 與 tool_choice。
5. 串流及框架專用的回應選項。

OpenRouter 的 Fusion 指南記載了 analysis_models、model、preset、max_tool_calls、max_completion_tokens、reasoning 與 temperature。但某個端點或模型系列支援的欄位，不代表所有上游模型都接受。應以 OpenRouter Models 參考文件及模型支援參數的中繼資料為準。

4. 簡化工具與訊息歷史

啟用工具的用戶端可能造成難以理解的 400，因為最終請求內容可能包含無效的 JSON Schema、不支援的工具參數，或不完整的 assistant/tool 訊息順序。Hermes Agent 的公開回報記錄了版本 0.10.0 在多個測試模型中啟用工具時發生 OpenRouter 400；回報推測預設的 28 個工具可能是原因，但沒有提供停用工具後成功的對照測試，也沒有確認根本原因。請把 issue #13927 當成重現線索，而不是認定所有 Fusion Flash 400 都是工具造成的證據。

隔離問題時，可以依序嘗試以下三種方式：

• 送出相同提示詞，但移除 tools。
• 只送出一個使用簡單物件結構的最小工具。
• 開啟沒有先前工具呼叫或工具結果的新對話。

如果最小文字請求與精簡工具請求都能成功，就逐一把工具加回來。若長篇工具使用歷史會失敗，但新請求正常，先截斷或摘要歷史紀錄，再判斷是否真的是模型本身的問題。

5. 分清楚別名、路由器與供應商問題

Fusion 可能同時涉及面板模型、分析模型與外層回應模型，因此其中一個內部呼叫失敗時，表現不一定像一般單一模型的錯誤。OpenRouter 文件建議查看生成資料與 Activity 紀錄，確認實際執行了哪些內容。正常回應中的 model 欄位可以指出具體的外層模型，但單靠這個欄位，無法證明 Fusion 一定有使用或一定沒有使用。

成功執行 Fusion 時，文件所述的生成中繼資料包括：

{
  "router": "openrouter/fusion"
}

如果你提供了自訂的 analysis_models，先移除它們，再重新測試預設設定。若預設設定能成功，但某個自訂模型失敗，問題很可能與該模型的參數、供應商可用性或上下文限制有關。若只有透過 SDK 使用時所有模型都失敗，請比較 SDK 實際送出的內容與成功的 cURL 請求。OpenAI 相容用戶端可能會自行加入工具、串流旗標、回應格式或訊息轉換，而這些變更不一定會出現在應用程式層的程式碼中。

什麼時候該停止重試？

自動重試無法解決無效模型 ID 或固定會被拒絕的結構。對於標記為不可重試的 400，應該建立清楚的替代路徑：

• 別名不在模型目錄中：改用搭配 general-fast 的 openrouter/fusion，或先使用已知可用的一般模型，同時持續監控模型目錄。
• 特定請求內容造成 400：保留最小請求作為回歸測試，並修正第一個讓請求開始失敗的欄位。
• 供應商專屬的 400：移除受影響的面板模型，或使用已設定好的替代方案；同時保存供應商回應。
• Chat API 大範圍事故：查看 OpenRouter 狀態頁面，暫停推出，不要急著修改應用程式邏輯。
• HTTP 200 但內部操作失敗：記錄面板錯誤，再決定是否接受部分結果；不要把它歸類成驗證失敗。

官方 Fusion Router 文件估算，預設的三模型面板成本約為單次完成的 4–5 倍；實際帳單則取決於底層呼叫。當別名狀態不明時，準備替代方案不只可以提升可靠性，也能控制支出。

OpenRouter Fusion Flash API 常見問題

正確的 OpenRouter Fusion Flash 模型 ID 是什麼？

官方文件列出的是 openrouter/fusion-flash。部署前請透過 GET /api/v1/models 確認這個完整字串，因為文件與即時模型目錄可能暫時不同步。

Fusion Flash 是一般的快速模型嗎？

不是。文件將它描述為採用 general-fast 預設的 Fusion。它仍可能執行多次內部模型呼叫，因此「Flash」代表的是預設對延遲的目標，而不是單次呼叫的執行方式。

應該使用哪個端點？

使用 https://openrouter.ai/api/v1/chat/completions，搭配 Bearer 驗證與 JSON 請求內容。不要自行捏造 Fusion 專用的 URL 路徑。

可以強制 Fusion 執行嗎？

Fusion 文件支援 tool_choice: "required"。當 Fusion 是唯一可用工具時，這實際上會強制觸發工具呼叫；但若同時存在其他工具，required 只代表必須呼叫某個工具，不保證一定是 Fusion。

為什麼 OpenRouter 狀態頁面顯示正常，Fusion Flash 卻回傳 400？

狀態頁面回報的是廣泛的服務元件。別名不存在、路由器設定無效，或供應商拒絕請求，都可能只影響特定路由，而一般 Chat API 仍維持正常。

Fusion Flash 免費嗎？

不要直接假設免費。OpenRouter 的 Fusion 模型頁面說明，即使路由別名沒有顯示獨立的 token 價格，底層面板與分析模型的完成請求仍會計入費用。正式使用前，請查看 Activity 與所選模型的費率。

只有在即時模型目錄與最小請求結果一致時，才使用快速預設。否則請改用標準 Fusion 或已知可用的模型，並保存失敗的請求內容，不要盲目重試。