摘要： OpenRouter正式開放影片生成，首波支援Seedance 2.0/1.5、Veo 3.1、Wan 2.7/2.6與Sora 2 Pro，新端點為/api/v1/videos。它以非同步job、共用schema、能力探索與參數透傳，處理各家影片API在請求形狀、參數命名與計費單位上的差異。文章另說明LLM擴寫prompt、圖像模型繪製主角、影片模型讓角色進入場景的組合工作流。
OpenRouter 正式開放影片生成：頂尖影片模型透過單一 API 就能取用，並與文字、圖像、音訊、embeddings、rerankers 平起平坐，全部由同一套路由、治理與計費機制處理。首波就支援 text-to-video 與 image-to-video 兩種模式，可用模型包括 Seedance 2.0/1.5、Veo 3.1、Wan 2.7/2.6 與 Sora 2 Pro，名單還會陸續擴充；對應的新端點為 /api/v1/videos。
統一的必要性：各家影片 API 各走各路
每一家供應商的影片 API 都自成一格：request 的形狀、參數的命名、計費的單位互不相容。OpenRouter 以四項正規化設計拆解這個問題：非同步生成——一次生成動輒數分鐘，整個流程一律以 job 管理：送出 prompt、取得 job ID、影片就緒後再取回；正規化參數——所有模型共用同一份 schema，範圍含 resolution、duration、aspect ratio、音訊生成、frame images 與 reference images；能力探索——實際呼叫之前，先用程式查清每個模型支援哪些項目；透傳參數——碰到模型專屬功能，直接原樣下傳即可。
容易踩雷的參數：一個 duration 就足以讓請求失敗
這些模型之間的分歧比肉眼可見的還深。最常被拿來說明的例子是 duration：Veo 3.1 接受 4、6、8 秒，Wan 2.6 只接受 5 或 10 秒——數值一不對，請求當場失敗。碎片化的另一層藏在端點家族：同一個模型常把 text-to-video、image-to-video、reference-to-video 分別做成不同 endpoint；OpenRouter 會依你傳入的參數自動把請求導向正確端點，呼叫端完全感覺不到這層複雜度。reference images（角色設定）與 frame images（首尾幀）的傳遞方式也一併標準化。
能力探索端點：為 coding agent 而設計的介面
對 /api/v1/videos/models 發一次請求，就能拿到每個模型支援的 resolution、aspect ratio、定價、輸入圖片與時長——官方稱它為「給你的 coding agent 的完美端點」：手上有了這份資料，agent 可以自行適應各個模型，不必靠錯誤訊息慢慢試出合法參數。模型專屬功能同樣留了出口：Veo 3.1 獨有的 personGeneration 參數（決定輸出裡要不要出現人物）就是透傳參數的實例。模型頁面另外多了 Playground 分頁，能直接試跑、查看產出。
多模態工作流：LLM 擴寫 prompt、圖像模型生主角、影片模型拍出場景
在官方眼裡，最令人興奮的應用是組合式工作流：先由 LLM 把粗糙的想法擴寫成完整 prompt，接著圖像模型把主角畫出來，最後影片模型讓角色走進場景——全程走同一個 API。實務心得說得直白：這些模型獎勵具體的描述，運鏡、光線、質地、節奏、動態風格每一項都會左右結果，給得越細、掌握越多，影片生成與 LLM 產出的 prompt 因此是天生一對。OpenRouter 也把示範應用 multimedia-explorer 開源（程式碼放在 GitHub），完整示範這條多模態管線。
上手建議
三個能立刻動手的切入點：第一，把 /api/v1/videos/models 先接進你的 agent 或程式碼生成流程，參數驗證交給能力探索處理，別再靠 try-and-error；第二，計費依各模型自己的定價計算，同一份清單就能完成跨模型比價；第三，想打造產品級的多模態管線，可直接參考 multimedia-explorer 的開源碼，LLM→圖像→影片這條鏈已經在裡面跑通。想回饋意見、或點名下一批該收的模型，官方在 Discord 開了 #video-feedback 頻道。