別再找「最強的模型」了

這裡最有用的觀念轉換其實很小。大家來的時候都想知道哪個模型最強，但這個問題沒有答案——不是因為它很難，而是這個問題本身就問錯方向了。

OpenRouter 之所以是個好的起點，正是因為它不是單一個模型。它是一個閘道——一支金鑰、一個端點，就能碰到很多不同開發商的模型。所以老實說，起點是這樣的： 你可能已經夠用了。接下來要講的，是怎麼判斷你什麼時候不夠用。

只靠一條路線會在哪裡開始卡手

以下三點來自「只依賴一條路線」這件事本身，不是 OpenRouter 有什麼問題。

flowchart TD
  A["你送出一個請求"] --> B{"Is your one route
working right now?"}
  B -->|"no"| C["任務到這裡就結束了"]
  B -->|"yes"| D{"Can the selected model
do this kind of work?"}
  D -->|"no，它讀不了圖片"| C
  D -->|"yes"| E["你拿到一個答案"]
  E --> F{"Was a premium model
needed for this?"}
  F -->|"no"| G["你多付了不該付的錢"]
  F -->|"yes"| H["對的工具，做對的事"]

家裡大部分的事，落在三種角色裡

模型目錄很長，名字從外面看根本看不出意義。與其把它們當成一份產品清單來讀，不如當成三種工作來讀，會有幫助。一個模型可以身兼不只一種角色。

同樣的概念，換成實際的決定來看：

在它們之間切換，就是訊息框下面的一個下拉選單。這不是改設定，也不會重啟任何東西。

切換模型選單就在訊息框下面。打勾的那個標的是這個對話目前用的模型。

• 那個 打勾記號 顯示的是這個對話目前的模型。
• 改了它，影響的是 下一則訊息，不是已經送出去的那些。
• 選單旁邊還有 reasoning 等級 跟 工具預設集 ——第 5 篇跟第 8 篇會講到。

你看得到表在跑

供應商用 token計算用量，送進去的跟拿回來的分開算。

有用的地方是，Pi Agent 在每個答案下面都會顯示這個數字，所以這不是紙上談兵。下面是一個實際工作區裡、真實的兩句話回答：

計費表每個答案都帶著自己的一行費用。這一個：1,094 tokens in、53 out、$0.0071。進行中的工作區

• 1,094 in ——問題只有一句話。剩下的是每次請求都會帶的 system prompt 跟工具定義。
• 53 out ——答案本身，只佔小小的一半。
• $0.0071 ——不到一分錢美金。想像一下換成高階思考型模型，問一樣簡單的問題，那一行會變成什麼樣子。

這個差距，就是留一個日常型模型在手邊的全部理由。不是因為貴的那個不好，而是因為你問的大部分事情根本用不到它。

供應商連線的三種方式

如果你真的打開 Add provider 畫面，目錄的分組方式在你選任何東西之前就先透露了有用的資訊：你自己填的自訂端點、你登入的訂閱方案，或是你貼金鑰進去的供應商。

供應商目錄依連線方式分組：自訂端點、你登入的訂閱方案，或是貼 API 金鑰的供應商。

• Subscriptions 靠登入連線——你本來就在某處付月費，這裡沿用那份訂閱。
• API key 供應商是按使用量計費，也就是這篇一直在講的隨用隨付模式。
• 只有 API key 這種卡片這裡帶著模型數量——訂閱制的卡片只寫 OAuth，因為你拿到的就是你方案裡包含的東西。

模型數量值得多看一眼，因為它們說明了為什麼閘道是個合理的預設選擇。

一個項目裡的廣度OpenRouter：一支金鑰後面就是 366 個模型。大部分直接的供應商只列得出小貓兩三隻。

這就是「先待在原地」的理由。一個項目、一支金鑰、幾百個模型——通常上面三種角色各自都有得選。直接供應商是一個範圍窄很多的東西，你是為了特定理由才加上去的。

老實說，答案通常是不用

第二家供應商值得加，是因為它給了你下面這幾樣東西之一，而且你要在加它之前就講得出來是哪一樣：

• 專精能力 ——閘道沒有用你需要的方式提供的原生能力。
• 備援 ——第一條路線斷線或碰到速率限制時，有一條獨立的路線可用。
• 比較 ——拿同一個重要問題問兩個模型。但要注意，兩個模型意見一致，不代表其中哪一個就是對的。
• 帳戶區隔 ——把不同用途的用量跟存取權限分開管理。
• 更好的判斷力 ——搞清楚哪些特性對你自己的工作真正重要，而不是相信一份通用的排行榜。

如果上面沒有一項對得上你現在真正的問題，正確的做法就是留著一條路線，好好用它就好。

接下來往哪走