如何在編輯器中即時挑選最佳 AI 模型

要選擇 AI 模型，先定義任務，從實際使用與基準資料篩選候選模型，比較各供應商的價格與延遲，最後用自己的提示測試入圍者。以每完成一次任務的成本評估，而非每個 token 的成本，並預期隨著新模型發布答案會變化。

我們不會指定單一最佳模型。任何我們列出的名稱在一個月內都會過時，且正確的模型取決於你正在構建的專案以及你願意為正確結果支付的費用。

本文說明我們用來回答此問題的框架，以及如何在不離開編輯器的情況下執行。MCP 伺服器將你的助手連線到即時使用排名、第三方基準、各供應商定價，以及傳送測試提示給候選模型的方式。

TL;DR

• 最佳指的是你的任務、每完成一次任務的成本以及你的延遲預算。排行榜排名並非其中之一。
• 使用基準來篩選候選者，並用你自己的提示選出勝者。Ori Eval 能為你撰寫並執行這項比較。
• 透過 MCP 從編輯器查詢即時排名與價格，然後用 get-generation 測量每一次測試呼叫的成本。
• 若無模型明顯勝出，請使用 openrouter/auto-beta 逐請求路由，而非選擇單一模型。

為何沒有單一最佳 AI 模型

沒有單一最佳 AI 模型，只有適合特定任務、預算和時機的最佳模型。

不同任務需要不同的優勢。摘要與編碼對模型的要求不同。提取需要每次呼叫都產生有效的 JSON，這比寫好文章更重要。聊天功能取決於第一個 token 到達的速度，這與完整答案的質量分開。即使某模型在編碼基準中排名第一，在長篇檔案上仍可能表現不佳，且對於日常提取而言成本過高。

更有用的問題會包含具體工作。不要問「哪個 AI 模型最好」，而是問「哪個模型最適合從掃描發票中提取明細專案」，或「用於審查 TypeScript pull request」，或「用於摘要 90 分鐘會議記錄」。寫下你自己的問題版本，然後根據最新資料回答，而非舊有排名。

我們的流量顯示答案隨任務變化的幅度。我們將一部分請求分類為 29 種任務型別，並公佈市場佔有率。僅編碼就佔了其中九種，涵蓋程式碼生成、除錯、程式碼審查、倉庫掃描、SQL 工作與 DevOps 設定。這九種並沒有共用單一領先者。在截至 2026 年 7 月 25 日的七天視窗中，一個模型領先其中八種，另一個模型領先程式碼審查與安全。即使在編碼領域內，「最佳編碼模型」也過於籠統。

基準是篩選工具，而非答案

基準對於將數百種選項縮減為可正確測試的少數候選者非常有用。我們將第三方評分來自 Artificial Analysis 與 Design Arena 與我們自己的使用資料一起呈現。

排行榜無法為你做出最終選擇。分數雜訊大，熱門基準會被調優，且它們都未跑過你的提示。使用排行榜來篩選，並用你自己的測試來決定。

不同任務需要不同的優勢。編碼需要推理品質與可靠的工具呼叫。摘要需要較大的上下文視窗與較低的輸入價格。抽取需要更一致遵守模式，而非流暢度。聊天需要低延遲。視覺需要能接受影像的模型，這在品質重要之前就已縮小範圍。

沒有任何模型能在所有類別中領先。將同一模型用於所有需求會產生昂貴的預設值，雖在示範中表現良好，但在實際執行的工作上表現不佳。

設定 OpenRouter MCP 伺服器

以下每一步都會透過 MCP 伺服器執行，請先連線。

我們已經主機化 OpenRouter MCP server，因此不需要在本機安裝任何東西。任何 MCP 客戶端都能連線。以下設定涵蓋 Claude Code、Cursor 與 Codex CLI，檔案亦包含 OpenCode 與 Claude Desktop。只要連線一次，您的助手即可拉取即時模型、價格、信用、排名、基準與檔案，並傳送測試提示，而不必離開編輯器。在選擇模型時使用它。釋出時，照常呼叫 API。

Claude Code:

claude mcp add --transport http openrouter https://mcp.openrouter.ai/mcp
claude mcp login openrouter

您也可以在會話內執行 /mcp 來驗證，選擇 openrouter，並點選 驗證。

Cursor: 將此加入 ~/.cursor/mcp.json，然後以 cursor-agent mcp list 進行驗證。

{
  "mcpServers": {
    "openrouter": { "url": "https://mcp.openrouter.ai/mcp" }
  }
}

Codex CLI:

codex mcp add openrouter --url https://mcp.openrouter.ai/mcp
codex mcp login openrouter

驗證只需一步瀏覽器操作，並在所有三個編輯器中以相同方式運作。在 Cursor 中，它會在第一次請求時執行，而非從登入命令開始。未驗證的請求會回傳 401，啟動我們的 OAuth 流程，並在同意畫面上顯示您即將同意的內容。

我們鑄造一把標記為 OpenRouter MCP: <app name> 的金鑰，限定於該客戶端，七天後過期，並有可在該畫面調整的 $10 信用額度（MCP announcement）。此金鑰為短期且預設有限制，您可隨時斷線，且可從您的 keys dashboard 取消授權。

流程會重新導向至 localhost，這對於像 Claude Code 或 Cursor 這類桌面客戶端來說是正常的，但也意味著我們無法驗證是哪個本地應用程式接收到金鑰。只有在您剛才自行啟動連線時才允許批准。

您將使用的工具

大多數為只讀查詢即時資料。例外為 send-message、generate-image、transcribe-audio、generate-speech，它們會產生可計費的推論呼叫，及 send-feedback，該項會寫入您自己的產生結果的回饋（MCP docs）。

助理會為 code:general_impl 標籤呼叫 list-task-classifications，並回傳領先模型及其使用量與 token 份額，接著進行每個供應商的定價。此過程不涉及瀏覽器。

選擇模型的六步框架

按順序執行。第 2 步至第 5 步各對應助理可對即時資料發出的特定呼叫。第 1 步與第 6 步則是您的判斷：您先定義需求，然後決定釋出內容。

步驟 1：定義您將要釋出的任務

先以工作為起點，而非模型名稱。寫下輸入、預期輸出、何為良好、延遲目標，以及在成本與品質衝突時的取向。

最後一項會影響之後的每一步。向客戶展示的摘要可證明較高的價格合理；而跨越百萬筆資料的夜間抽取工作，即使在品質上略有犧牲，也能以較低價格合理，因為量級主導費用。說明你正在構建哪一種。

第二步：從即時資料篩選候選。

候選清單來自兩個問題：人們在這項工作中使用什麼，且哪些表現良好？

對於第一個，呼叫 list-task-classifications。它會回傳我們在往後七天視窗內的 29 個任務標籤，每個標籤都有使用比例以及服務該標籤的模型排名，資料來源於實際流量。對於第二個，呼叫 list-benchmarks 並將 task_type 設為 coding、intelligence 或 agentic，將回傳 Artificial Analysis and Design Arena 分數與價格。這三個分類故意比 29 個流量標籤更粗略，兩個呼叫設計為一起使用。基準過濾器會移除跨廣泛分類中得分低的模型，然後流量標籤顯示人們在你特定領域中使用的模型。

list-daily-model-rankings 對趨勢很有用。預設情況下，它會回傳前 50 個模型的每日 token 總量，以及每日一行的聚合 other。你可以以用例類別（如 programming 或 roleplay）、模態或工具呼叫活動來縮小範圍，但這些類別切片來自每週彙總的抽樣資料集，請將這些總量視為估算值。它告訴你哪些在成長，而非哪些在你的工作中表現良好。相同的檢視可於 openrouter.ai/rankings 取得。

第三步：比較成本、供應商與延遲。

對於每個入圍者，呼叫 list-model-endpoints。你會得到該模型所有供應商的價格、上下文長度、過去三十分鐘的吞吐量與延遲、正常運作時間、量化方式以及支援引數。相同模型在不同供應商之間可能在價格、速度與可靠度上有所差異，最好在此處發現差異，而非在正式環境中。

當你需要與他人分享時，compare page 會在瀏覽器中顯示相同資料。

第四步：在自己的資料上測試候選清單。

基準測試為你提供候選清單，而你自己的提示則決定最終選擇。

對你實際擁有的工作執行 send-message：真實票證、真實檔案、真實 schema，甚至包括通常導致失敗的專案。乾淨的評估集會使每個模型看起來都很能幹，這就是為什麼它無法將它們區分開來。

三種變體在測試時有所幫助。:floor 將請求路由至該模型最便宜的供應商，降低評估成本。:nitro 將請求路由至最快的供應商，這是檢查延遲預算的方式。:online 在任務需要即時背景時加入網路搜尋。

留意 :online 的成本。以相同簡單提示三種方式執行，:floor 成本為 $0.0000030，:nitro 為 $0.0000024，而 :online 為 $0.0052576。這大約是單一提示簡易呼叫的兩千倍，請有意使用，而非隨時開啟。

使用 Ori Eval 使比較可重複。

即時測試呼叫只回答一次。Ori Eval 使此步驟可重複。你以簡單文字提問，例如「什麼是最適合我的支援代理的模型」，你的程式編寫代理會在專案中尋找測試素材，將評估寫成 *.eval.ts 檔案，執行候選模型，並根據分數、時間與成本推薦其中一個。要從編輯器啟動，請給你的程式編寫代理以下指令：

run curl -fsSL https://openrouter.ai/skills/spawn-ori-eval and follow the instructions in its output to get started

Ori 為一次執行解析一個 harness 與一個模型，並將其保留於該執行中的每一次測試，因而同一組 eval 檔案的兩次執行將使用相同設定。它透過 OpenRouter 傳送請求，讓一次比較可包含多家供應商的模型。上述指令在臨時目錄中可行。若改為執行 manual steps，eval 檔案將保留於專案作為一般程式碼，你可在新模型發布時重新執行，或使用 --baseline 與較早的執行做比較，亦可在 CI 上排程執行。

步驟 5. 測量每完成任務的成本

每次測試呼叫後，將產生 ID 傳給 get-generation。你將得到精確成本、提示與完成的 token 數量、提供服務的供應商以及延遲。對代表性提示集合平均計算，調整任務成功率，並將該數值記錄於決策檔案。

需注意兩點。產生記錄在呼叫回傳時尚未可查詢，因此立即查詢會得到 404，數秒後才可解決。請重試，而非將第一次 404 視為失敗。另外，完成回覆已攜帶 usage.cost，若你只需要呼叫價格，可略過額外往返。若想取得供應商、延遲或原生 token 數量，請使用 get-generation。

步驟 6. 決策，或按請求路由

若某模型在你執行的工作中明顯勝出，直接使用它。

若結果相近，或你的流量混合多種工作，亦或不想每次新模型發布時重新評估，請指向 Auto Router 並使用模型字串 openrouter/auto-beta。舊版 openrouter/auto 仍能解析但已標示為棄用，請使用最新版。

路由器不會隨機選擇。它將每個請求分類為約 30 種細粒度任務型別，根據過去七天的實際支出份額對候選模型排序，套用你的成本與品質偏好，並以備援方式路由（Auto Router docs）。以上即為框架，按請求執行，使用你在步驟 2 查詢的相同任務分類資料。

以每個任務成本思考，而非每個 token 成本

每個任務成本，而非每個 token 成本，才是比較模型經濟性的正確單位。

人們之所以按 token 價格比較，是因為易於對比，且曾經難以衡量完整成本。隨著 get-generation 在每次呼叫時回傳真實數值，這一困難已消失。

單價低的模型在重試、產生超過 token 預算的完成、或需更強模型協助捕捉失敗時，便不再便宜。相反地，雖昂貴但能一次完成任務的模型，總體成本往往更低。

2026 年一項關於推理模型定價的研究測量了這一點。在 32% 的模型對比中，列價較低的模型實際產生了更高的總成本，極端情況下反轉達到 28 倍（Chen et al., “The Price Reversal Phenomenon”）。作者將其歸因於模型在思考時使用 token 的差異：同一查詢下，一個模型可能比另一個多使用 900%，單一查詢的重複執行差異可高達 9.7 倍。列價並未反映這些因素。

cost per task = ((input tokens × input price) + (output tokens × output price)) × expected attempts

大多數比較都忽略了預期嘗試次數，而這個專案通常決定結果。

以下以真實價格進行計算，已於 2026 年 7 月 27 日檢查。GPT-5.4 mini 列價為每百萬輸入 token $0.75、每百萬輸出 token $4.50。Claude Sonnet 5 列價為每百萬輸入 token $2.00、每百萬輸出 token $10.00，約高出 2.4 倍。假設任務為 2,000 個輸入 token 與 800 個輸出 token。若 Sonnet 5 在首次嘗試中 95% 成功，則每千個完成任務的成本約為 $12.63。為使 mini 匹配此成本，其首次嘗試成功率必須為 40%。低於 40% 時，按 token 低價的模型反而是完成工作更昂貴的選擇。

向他人報告時，請使用每千個完成任務的成本。擁有最低 token 價格的模型往往不是完成工作的最便宜方式。

下方圖表繪製了整條曲線，而非單一點。曲線更有用，因為盈虧平衡率會隨你比較的兩個候選模型之間的價格差距而變動。較寬的差距使較便宜的模型在失敗前能容忍更低的成功率。

同樣的例項，將所有成功率都繪製出來，而非單一點。Sonnet 5 以 95% 為參考保持平穩，mini 的成功率則變化。列價為 2026 年 7 月 27 日的價格，任務為 2,000 個輸入 token 與 800 個輸出 token，成功率為變數，而非我們測量的任何值。

按任務最佳化的物件

這是起點而非排名。每一行告訴你要最佳化的物件以及應該進行的呼叫，即時資料提供名稱。我們不列出勝者，因為任何勝者列表在下一次發布時都會過時。

編碼：決定你所指的編碼型別。我們的任務標籤將程式碼生成與除錯、審查、前端以及倉庫掃描分開，領先者也不同。將候選模型在你待辦清單中的實際工單上測試，而非玩具問題。

摘要：同時閱讀輸入價格與上下文長度，因為單獨考慮任何一項都會誤導你。較便宜、視窗較大的模型往往勝過輸入價格高的更強模型。

抽取: 每次都能返回有效 JSON 的小型模型，勝過每天會損毀兩次欄位的強大模型。測試困難輸入：缺失欄位、模糊記錄與格式錯誤的來源文字。

願景: 多模態品質依領域差異很大，請先過濾影像輸入，再自行執行截圖測試。使用標準示範集會讓每個候選模型看起來都不錯。

不論情況如何，先執行查詢、檢視本週資料，並從中挑選。

為何要透過 OpenRouter 執行迴圈

你根本不需要鎖定單一模型。

一個整合即可取得跨供應商的整體 目錄。若下個月有更佳模型發布，只需改變模型字串，而非整合另一 SDK 並重新測試整合流程。選擇與執行共處於同一平臺，且使用 MCP 時，選擇資料可在你已使用的編輯器中取得。你亦能享有 供應商冗餘與自動回退，以及足以精確計算成本的每次請求費用，讓上方的成本／任務計算更準確而非估算。

若你確信只需要從單一來源取得一個模型且不會改變，直接連線供應商是合理選擇。新模型不斷推出，請評估你有多確定。

選擇模型時常見錯誤

大多數錯誤的模型決策源於測量錯誤的指標，或是測量正確指標時太遲。以下為我們最常見的五項錯誤。

把排行榜位置當成生產決策: 公開排行榜上的高排名僅能進入你的備選名單，並非實際流量。先把提示送到模型測試。

按每個 token 價格購買: 低單價會掩蓋重試、長輸出與回退。直到 get-generation 告訴你每個完成任務的成本，你才知道模型實際費用。

忽略上下文結構: 檢查上下文長度及該長度下的費用。長上下文模型功能強大且昂貴。採用最小可靠的上下文策略完成工作，並在考慮更大視窗前先評估檢索。

一次選擇不再檢討: 你在一月選出的最佳模型，七月可能已不再最佳。我們在 2026 年 7 月 27 日之前的 30 天內新增約 40 款模型，故任何主要版本發布後請重新執行這六個步驟，保持一份 Ori 評估在倉庫中並按時重新執行，或將此問題交給 Auto Router。

延遲與可靠性留到上線才測: 在 list-model-endpoints 檢查延遲、吞吐量與正常運作率，然後以生產方式測試端點。上線後發現供應商不可靠是可避免的事件。

為任務選擇，並保持選擇更新

正確的問題不是哪個模型最好，而是哪個模型最適合你目前正在構建的專案、符合預算。

擁有明確的任務定義、即時資料與實際提示，你可以在一個下午內回答，若有變動亦能在數分鐘內重新回答。

• 最佳取決於任務與時間。以每個完成任務的成本與延遲評估，而非排行榜。
• 基準測試建立備選名單，自己的資料決定勝者。send-message 與 get-generation 就能決定。
• 整個流程在 MCP 伺服器連線後，即可從你的編輯器執行。

加入 OpenRouter MCP 伺服器，並請你的助手為本週交付的工作篩選並報價候選模型。如你尚未決定或同時處理多項任務，請使用帶有 openrouter/auto-beta 的 Auto Router，讓其依需求自行挑選。

常見問題

如何選擇最佳 AI 模型？

明確定義任務，從即時使用與基準資料中篩選候選模型，並比較各供應商對應模型的價格與延遲，最後在自己的提示上測試入圍者。以每個完成任務的成本評估勝者，而非每個 token 的成本。在 OpenRouter 上，你可透過 MCP 伺服器直接在編輯器中完成上述所有步驟。

哪一個 AI 模型最適合程式編寫？

沒有固定答案，程式編寫也不是單一任務。我們將程式流量分為九個獨立標籤：程式產生、除錯、檔案 I/O、Shell 執行、程式碼審查與安全、前端與 UI、倉儲掃描、SQL 與資料庫工作，以及 DevOps 設定，且各領域的領先模型並不相同。使用 list-benchmarks 以 task_type=coding 篩選候選，並以 list-task-classifications 與實際流量交叉驗證，最後在你自己的待辦清單中真實工單上測試候選模型。

OpenRouter MCP 伺服器是什麼？

它是我們託管的遠端 MCP 伺服器，無需在本地安裝任何東西。連線後，你的 AI 助手即可查詢即時模型資料、各供應商價格、使用排行、第三方基準與檔案，並向候選模型傳送測試訊息，全部不離開編輯器。任何 MCP 客戶端都能連線。我們已為 Claude Code、Codex CLI、OpenCode、Cursor CLI 與 Claude Desktop 提供設定說明。

如何在 Claude Code 或 Cursor 中設定 OpenRouter MCP 伺服器？

在 Claude Code 中，執行 claude mcp add --transport http openrouter https://mcp.openrouter.ai/mcp 後再執行 claude mcp login openrouter。在 Cursor 中，將伺服器 URL 加入 ~/.cursor/mcp.json，並以 cursor-agent mcp list 進行驗證。授權僅需一次瀏覽器操作，完成後我們將產生一把專用 API 金鑰，七天後失效，且每次使用上限為 10 美元。

成本 per token 與 cost per task 有何差異？

Cost per token 是輸入與輸出的標示單價。Cost per task 則是獲得一次成功結果的實際成本，包含重試、較長輸出以及必要時降級至更強模型的費用。即使 token 價格較低，某些模型每完成一次任務的成本仍可能更高。get-generation 會回傳每次呼叫的實際費用與 token 數量，讓你能直接衡量而非估算。

如何比較 AI 模型？

一次比較三個維度：任務品質、每完成任務的成本以及延遲。利用第三方基準建立候選清單，使用 list-model-endpoints 比較各供應商對應模型的價格、延遲與吞吐量，並以自己的提示做最後決策。並排比較的網頁位於 openrouter.ai/compare。

多久重新評估模型選擇？

在任務類別有任何重大版本更新，或成本、延遲、失敗率有波動時，重新執行此流程。自 2026 年 7 月 27 日前 30 天起，我們已新增約 40 款模型，故模型選擇應視為運營決策而非一次性設定。若不想追蹤此節奏，可改用 Auto Router 依需求自動路由。

如何讓模型評估可重複執行？

使用 Ori Eval。你以簡單文字提問，你的程式代理會在專案中尋找測試素材，將評估寫成 *.eval.ts 檔案，將候選模型送至 OpenRouter 執行，並推薦其中一個，並附上分數、時間與成本。評估檔案是普通程式碼，你可以在新模型發布時重新執行，使用 --baseline 比較執行結果，並在 CI 上按排程執行。

我應該使用單一模型還是在多個模型之間路由？

當任務範圍狹窄、提示語穩定、且有一個候選模型以明顯優勢通過評估時，使用單一模型。當請求複雜度變化、可靠性比模型一致性更重要，或你不想在每次發布週期都重新評估時，則使用路由。Auto Router 會將每個請求分類為大約 30 種任務型別，並根據社群在過去七天的支出份額為每個請求選擇模型。

參考文獻

本頁的每一項說法皆已對照這些來源進行驗證，包括實際的 API 呼叫。

• OpenRouter MCP 伺服器檔案。託管伺服器、每位編輯者的設定、完整工具清單，以及哪些工具需要計費。
• OpenRouter MCP 伺服器公告。OAuth 流程、七天金鑰過期與 $10 支出上限，以及模型字尾變體。
• 模型檔案。模型元資料欄位，包括定價、上下文長度、模態與支援引數。
• 模型變體檔案。:online、:nitro、:free 字尾及其對路由的影響。:floor 快捷方式已在 供應商選擇 中說明。
• Ori Eval 檔案。評估檔案格式、candidateModels、setupJudge、--baseline，以及在 CI 中執行評估。
• Auto Router 檔案。每個請求分類為大約 30 種任務型別，按過去七天支出份額排名，以及 openrouter/auto-beta 模型字串。
• 模型備援檔案。供應商冗餘與自動備援行為。
• API 參考。正式 API，選擇後可查詢請求後的成本與統計資料。
• 模型目錄。即時目錄，70+ 供應商共 400+ 模型。
• 排行榜。按模型每日 token 總量，以及任務分類市場佔有率。
• 比較。在基準、價格、上下文與延遲上進行模型並排比較。
• Artificial Analysis 與 Design Arena。兩個第三方基準來源出現在 list-benchmarks。
• 任務分類市場佔有率。list-task-classifications 背後的端點，回傳 29 個任務標籤的使用佔比與每個標籤的領先模型。
• 列出基準。list-benchmarks 背後的端點，可依 task_type 篩選。
• 取得生成的請求與使用元資料。單一呼叫的精確成本、token 數量、供應商與延遲。
• Chen, Zhang, He, Stoica, Zaharia and Zou, “The Price Reversal Phenomenon: When Cheaper Reasoning Models Cost More”。對模型對間的上市價格與總成本進行獨立測量。arXiv，2026年3月，修訂於2026年5月。