Cursor Router 深入解析：請求級智慧路由，怎麼靠它省下 30–50% 成本

瀏覽次數: 1

你在 Cursor 裡按下 Auto，然後呢？多數人不知道那背後其實有一套機制在幫你「這個請求該用哪個模型」做決定。2026 年 7 月 22 日，Cursor 背後的團隊 Anysphere 把這套機制正式產品化，叫做 Cursor Router——一個在「模型真正開跑之前」就先讀懂你這一則請求、再分派到最合適模型的分類器。官方回報：在維持前沿品質的前提下，成本可以砍掉三到六成。

這篇不談趨勢，直接拆給你看它怎麼運作、數字的前提是什麼、三種模式該怎麼選，以及你（或你的 team admin）今天要怎麼把它開起來、設對。

本文大綱

先講清楚它要解決什麼

現在一個工程團隊桌上同時擺著 Fable 5、Opus 4.8、Grok 4.5 這種模型組合，每個模型的強項和價格差很多。問題是：大部分請求根本不需要最貴的前沿模型。改個 CSS、補個 type、寫個 log，你卻常常用 Opus 在跑；反過來，一個需要長流程推理的重構，你可能又剛好掛在便宜模型上，來回被卡。

過去要嘛你手動切模型（沒人真的每則都切），要嘛全程押一個貴模型（品質穩、但錢燒得兇）。Cursor Router 想解的就是這個中間地帶：讓「選模型」這件事變成請求級（per-request）的自動決策，貴模型只在真正需要它的時候上場。

運作原理：一個「先看再派」的分類器

核心其實不複雜——它是一個分類器（classifier），在每個請求送進模型之前先攔一下，判斷「這則請求要交給誰」。

它看四個訊號來下判斷（引自官方 blog）：

query——你到底問了什麼、要它做什麼
context——這則請求帶了多少上下文
task complexity——任務有多複雜
domain——落在哪個領域

再結合「它對每個模型行為的認知」，路由出去。官方給的三條路由邏輯很直白：

簡單的工作 → 丟給最有性價比的模型
UI 更新 → 丟給「品味（taste）最好」的模型
更複雜、長流程（long-horizon）的問題 → 丟給前沿推理模型

這套分類器是用 60 萬則以上的真實請求（600k+ live requests）訓練出來的，再透過「跨數百萬則真實請求的線上 A/B 測試」驗證，最佳化的訊號是 user satisfaction（使用者是否滿意）。

一個容易被忽略、但很關鍵的細節：cache-aware

值得特別點出來的是——Router 在訓練和評估時都是 cache-aware（快取感知）的。

為什麼這重要？因為每切換一次模型，前面累積的 prompt cache 就作廢了，等於要重付一次昂貴的 cache miss 成本。很多「路由省錢」的宣稱會刻意忽略這塊，結果實務上一換模型反而更貴。Cursor 的說法是：它是在「路由會造成 cache miss」的資料集上訓練的，所以它回報的節省數字，已經把這些切換成本算進去了。這點如果屬實，會讓數字比一般 router 更可信一些。

它怎麼衡量「有沒有做對」

除了 user satisfaction，官方還用一個叫 keep rate 的指標：agent 產生的程式碼，隨時間留在 codebase 裡的比例有多高。留得住 = 這段程式碼是有用的、沒被 revert 掉。用 keep rate 當品質訊號，比單純看「跑完沒報錯」誠實很多——不過要注意，這是 Cursor 自訂的內部指標，不是業界公認的標準 benchmark。

數據與限制：數字很漂亮，但看清前提

先把官方回報的數字擺出來，再講前提。

線上 A/B 測試（跨數百萬請求）：在前沿品質下，成本節省約 60%。
早期存取（early access）的數十家企業：相對全程使用 Opus 4.8，省下 30–50%。
每次 commit 的平均成本：Auto Intelligence $6.76、Auto Balance $4.63；對照組 Fable 5 $12.69、Opus 4.8 $7.34。

看數字時，請把這幾個前提放在心上：

這些都是 Cursor 自己回報的數字，不是第三方獨立驗證。方向可信、但別當成鐵板釘釘。
「省 60%」的基準是「全程押最貴前沿模型」。如果你本來就會手動混用便宜模型，你的實際省幅不會有這麼大——省的是「你原本沒在省的那部分」。
cost per commit 依專案而異。你的 codebase 大小、上下文長度、任務型態都會讓數字上下跳。
別把它想成「免費午餐」。它是把「品質/成本」這條線往上推，不是無損地變便宜——Cost 模式本質上就是拿一點品質換錢。

三種模式怎麼選（實際招式）

Router 給你三個檔位，這是你日常最常碰的設定：

Intelligence（前沿品質）——效能對齊「最貴、最強」的模型。適合：關鍵路徑重構、跨檔案的長流程任務、上線前不能出錯的東西。
Balance（平衡）——效能對齊「大家日常愛用的前沿模型」。適合：當預設。多數功能開發、debug、寫測試，這檔就夠。
Cost（省成本）——在盡量壓 token 花費的前提下，仍拿到「能拿到的最高智慧」。適合：批量雜活、大量但低風險的小改動、探索性嘗試、個人練習專案。

什麼時候別用 Auto？ 如果你正在追一個很微妙的 bug、或在做對「模型一致性」很敏感的長對話（每則都想留在同一個模型的 cache 上下文裡），中途被路由換模型反而可能打斷手感——這種時候手動鎖一個模型會更順。Router 的甜蜜點是「一大批彼此獨立、複雜度不一的請求」，不是「一條需要連貫心智的長鏈」。

上手三步：把它開起來、量出省幅

不用等 IT，個人／小 team 今天就能照這三步走一遍：

開 Auto、先鎖 Balance 當基準。在 Cursor 的模型選單切到 Auto，模式選 Balance。這是官方定位「大家日常愛用的前沿模型」的對齊檔，最適合當「日常工作」的對照起點，先別急著往 Cost 衝。
把「顯示被路由模型」打開。預設是隱藏的——先開起來，跑幾天你自己的真實任務，觀察哪類請求被派到便宜模型、哪類被送去前沿推理。這一步是你建立直覺的關鍵：你會很快看出「原來我這種改動根本不用 Opus」。
量成本，用你自己的帳單當證據。記下開 Router 前一週的花費當基準，開了之後再看同樣工作量的花費。官方那個「30–50%」是他們的資料；你要驗證的是你 codebase 上的數字。如果省幅遠低於預期，多半是你的任務結構偏向長流程推理（那本來就該走貴模型，省不了太多），這反而是有用的訊號。

驗證完再決定要不要把預設下放到 Cost、或用 hard enforcement 把整個 team 標準化——先量再鎖，不要反過來。

對工程團隊的意義：怎麼開、怎麼管

這是給 team lead / admin 的可操作清單。

開起來：

Cursor Router 目前給 Teams 與 Enterprise 方案，橫跨 desktop、web、iOS、CLI 與 SDK。
Teams 方案預設開啟；Enterprise 由 admin 從 dashboard 開通。
有一個前提要注意：官方列出需要有 Grok 4.5 作為高性價比的路由選項——換句話說，你的可用模型清單裡得留著它，Router 才有便宜檔位可派。

管理控制（admin 能調的東西）：

可以按 team 或 group 分別啟用，不必全公司一次上。
可以限制成員能選哪些模式（例如只開 Balance / Cost，不讓人隨手切 Intelligence 燒錢）。
可以設定預設模式。
可以允許或封鎖特定底層模型。
提供 soft / hard enforcement，把團隊標準化到 Auto 模式上（soft = 建議、hard = 強制）。
被路由到的實際模型可以顯示或隱藏，預設是隱藏——如果你的工程師想知道每則到底走了哪個模型來 debug 行為差異，記得手動把它打開。

帳單怎麼算： Balance 與 Intelligence 是按實際被路由到的那個模型的費率計費。所以省不省，取決於 Router 實際把多少比例的請求下放到便宜模型——這也是你上線後第一件該回頭量的事：攤開實際成本，對照開 Router 前的基準，用你自己的數字驗證那個「30–50%」。

一句話總結

Cursor Router 把「每則請求該用哪個模型」從一個沒人在做的手動決定，變成請求級的自動分類。它最紮實的兩個設計是 cache-aware 的成本估算和 keep rate 這種誠實的品質訊號；最該小心的是——所有漂亮數字都來自官方、基準是「全押最貴模型」。開起來、設好模式與 enforcement、然後用你自己 team 的帳單去驗證省幅，這才是把它用對的方式。