摘要： OpenRouter 在 2026 年 9 月 11 日發布的 RSS 摘要，把 TTS、圖片、影片等供應商呼叫收斂到相近的請求格式、單一 key 與共用的非同步流程，讓換模型更像改設定而非重寫整合。設定、權限、支出控制、ZDR 與 in-region routing 也被拆成平台層的可管理項目。摘要未給出實際定價、供應商品質差異或 in-region 支援的完整模型清單，這些仍須實測與查證。
多供應商整合的成本，通常不在第一支 API
只有一家供應商的時候，事情看起來很乾淨。產品團隊第一次要接 TTS、影片或圖片生成，通常就挑一家，程式碼也確實好讀。真正的成本要等第二家、第三家進來才浮現：endpoint 不一樣、任務狀態不一樣、輪詢邏輯不一樣、輸出格式也不一樣，這些全都得自己寫一層抽象去吸收。
OpenRouter 在 2026 年 9 月 11 日發布的 RSS 摘要裡，TTS 模型（Mistral、xAI、Microsoft 等）被收在一個 OpenAI 相容的 speech endpoint 後面，cURL、Python、JavaScript 與 OpenAI SDK 都能用同一種請求形狀呼叫；摘要也提到回應檢查，用途是不讓 JSON 錯誤混進音訊檔。這與其說是新功能的軍備競賽，不如說做的是介面收斂——以後要「換供應商」，不再是重寫整合，而是改一個欄位。
影片與圖片走同一條路
其他幾篇摘要走的也是同一套邏輯。9 月 9 日的 Seedance 2.5 評測摘要描述的是拿解析度換長度：最長能跑到 30 秒，但上限停在 720p。8 月 25 日的影片 API 指南摘要把非同步影片 API 說成一條迴圈，Seedance、Veo、Wan 等供應商都被收進同一個 submit、poll、download 流程。8 月 17 日的圖片 API 教學摘要指出，一旦要支援多家圖片供應商，不同 endpoint、資料格式與計費模型就都得處理，而專用 Image API 給出的是單一請求格式與單一 key。
對產品團隊來說，這件事的意義很具體：「支援多供應商」過去是一筆自己扛的工程債，如今有一部分被移到平台層。要用哪個模型的決定權仍在你手上，但每個模型都得重寫一次呼叫流程這件事，可以不必再做了。
設定與權限也一起被拉出來
收斂不只發生在請求格式上。9 月 10 日的 Presets 教學摘要談的是一種 config-as-code 做法：模型、system prompt、供應商路由與取樣參數寫成具名、有版本的 preset，以 @preset/your-slug 引用，之後直接從 dashboard 更新，不需要重新部署。這與本部落格先前那篇把模型參數移出程式碼：用 OpenRouter Presets 管理 LLM 設定講的是同一件事：把會變動的決策從程式碼裡搬出來。
成本與資料邊界也被拆成可設定的層級。8 月 7 日的團隊支出控制教學摘要舉出五種控制手段：以共用 credit pool 運作的 organization、按工作負載限定可用模型的 preset、per-key 支出上限、用來強制成員預算的 guardrail，以及看得出誰花了什麼的 Activity dashboard。9 月 11 日的 ZDR 說明摘要強調，零資料保留是對保留期限的保證，不是通用的隱私政策，而且可在帳號、guardrail 或請求層級強制執行。9 月 9 日的 in-region routing 公告摘要指出，US In-Region Routing 已經上線，與 EU 並列；送到 us.openrouter.ai 的請求只在美國境內解密，服務它的供應商也只在當地營運。
這對你的架構決策意味著什麼
第一，重新算一次自建抽象層的價值。如果你的整合層做的只是把三家供應商的請求格式對齊，這塊正在被平台商品化；工程時間應該留給真正能差異化的地方，例如 prompt 設計、評估流程與產品邏輯。
第二，把「換模型」當成常態來設計。影片、圖片、語音既然都能用同一個 key 與相近的請求形狀呼叫，模型選擇就變成隨時可調的參數，而不是那種一次定案、之後不再變動的架構決定。
第三，留意摘要沒有回答的部分。上述 RSS 摘要並沒有說明這些功能的實際定價細節、各供應商的品質差異，也沒有說明 in-region routing 涵蓋哪些具體模型清單。這些要靠在你自己的任務與資料上實測，不能從公告推論。
最實際的下一步，是挑一個你已經在用的多供應商流程，量一量其中有多少程式碼只是在做格式轉換。那個比例，大概就是這波介面收斂能替你騰出的空間。