摘要： OpenRouter Presets 把模型選擇、fallback、系統提示詞、provider 路由、取樣參數與工具封成具名且有版本的設定，API 用 @preset/ 前綴引用。在 dashboard 更新後，下一個請求就會使用 active 版本，請求仍可 shallow 覆寫欄位，tools 則會合併。它讓非工程角色也能調整設定，但 rate limit 照舊，API 層沒有全域預設 Preset，每個請求都必須明確指定。
網頁應用、批次腳本、Notebook，三個地方各自貼著同一組模型名稱、系統提示詞與 temperature。只要動到其中一個參數，就得三個檔案一起改。OpenRouter 的 Presets 正是衝著這個痛點而來：把 LLM 呼叫相關的設定當成程式碼來對待，定義一次，之後處處以名稱引用。
Preset 到底是什麼？
每個 Preset 都是一份具名、帶版本的設定檔。裡面放的東西包括模型選擇（單一模型，或是一組 fallback 陣列）、系統提示詞、provider 路由偏好、取樣參數（temperature、top_p 這類），以及工具，其中也涵蓋 OpenRouter 的 server tools，例如網頁搜尋、圖片生成、advisors 與 subagents。
類比上，它很接近 .env 檔或 Terraform module：設定被拉到應用程式邏輯之外，靠名稱參照，而不是複製一份進程式碼。真正的分野在於存放位置，以及誰有權動手改。.env 檔是隨 repo 一起走的，想更新就得重新部署；Preset 擺在 OpenRouter dashboard 上，一旦修改，所有參照它的應用立刻生效。
動手建立第一個 Preset
前往 openrouter.ai/settings/presets 建立 Preset，取一個容易記住的 slug，之後在 API 請求中以 @preset/your-slug 參照。接下來設定模型與路由：可挑單一模型，也可接上一份有序的 fallback 清單，當第一個模型因為 rate limit、outage 或 context 過長而失手時，就自動換下一個接手。Provider 路由同樣在這個地方配置，比方說按價格或延遲排序，或是把特定 provider 封鎖掉。
系統提示詞與取樣參數設定完成後，凡是使用這個 Preset 的請求，都會以它們作為預設值。在 API 呼叫這一端，只要把 model 欄位填成 Preset slug 就行：
resp = client.chat.send(
model="@preset/tech-writer",
messages=[
{"role": "user", "content": "Explain preset versioning."},
],
)Preset 也能改用 API 建立：對 preset endpoint 送出 POST 請求，系統會保存屬於 Preset 設定的欄位，至於 messages、stream、prompt 這類 transient 欄位則予以忽略。
請求如何覆寫、如何合併
任何請求都具備覆寫 Preset 設定的能力。假設請求 body 裡帶了 temperature，這個值就會蓋掉 Preset 的值。合併走的是 shallow 路線：請求的欄位取代 Preset 中對應的欄位，請求未提及的 Preset 欄位則原樣保留。tools 是這套規則之外的例外：Preset 的工具與請求的工具會合併起來，名稱若撞在一起，以請求的工具為準。
參照方式除了前面那種寫法，也可以改用獨立的 preset 欄位（"preset": "@preset/tech-writer"），或採合併形式（"model": "anthropic/claude-opus-4.8@preset/tech-writer"）。這裡有個細節：preset 欄位必須帶上完整的 @preset/ 前綴，只寫 slug 不會被理會。
兩種實際應用：圖片提示詞增強與 Fusion 面板
Preset 的用處不限於簡化參數管理，它同樣能把較複雜的工作流程包成一份設定。以圖片模型為例，通常要餵進相當詳細的提示詞才會有理想結果。你可以建一個 Preset，內容包含一個文字模型、一段系統提示詞（負責把簡短請求擴寫成涵蓋主體、構圖、光線、色調與風格的完整視覺 brief），再加上圖片生成工具。往後只要寫 @preset/image-enhancer，所有應用都會得到一致的提示詞增強行為。
另一種用法是把 Fusion 設定釘成 Preset。Fusion 會跑一組模型面板，讓主要模型在撰寫最終答案時參考面板的輸出。把整套設定存進 Preset 的 tools——包含 openrouter:fusion 工具、analysis_models 面板與 analyst model——之後在任何地方都能以 @preset/fusion-panel 參照。網頁應用、評估工具、Slack bot 從此共用同一組面板，要調整時只在 dashboard 改一次，不必動到三個 codebase。對 ML 工程師而言，這也代表能用同一個穩定 slug 反覆執行評估設定。
版本演進與團隊共用
以既有 slug 儲存 Preset 時，系統會產生一個新版本並把它設為 active，API 請求取用的就是 active 版本。在 dashboard 上修改系統提示詞，所有使用該 slug 的應用會在下一次請求時套用新內容，過程中無需重新部署。萬一這次改動讓品質變差，也可以在 dashboard 還原成較早的版本。
放到團隊情境來看，Preset 提供的是一個帶版本的集中位置，用來管理模型選擇、路由與提示詞，取代原本散落在多個 repo 的常數。組織帳號底下的成員都能取用組織 Preset，最佳實務的分享因此方便許多。
有哪些限制要注意
Rate limit 不受 Preset 影響，各模型自身的限制照舊適用。API 層級沒有全域預設 Preset，每個請求都必須明確指定要用哪一個。Chatroom 的情況不同，它具備 Default Preset 設定，會套用到新訊息上。
如果你正在設法把設定從程式碼裡抽離，Preset 值得一試。它的精神與我們先前討論過的流程編排執行模型相通：把決策點從程式碼中挪出來，讓非工程角色也能調整行為，同時保住可追溯性。
建好第一個 Preset 之後，若想了解圖片生成的完整流程，可以接著看 preset-enhanced images cookbook。