LLM 工程 · AI 代理 · 效能評測 · 評估簡報Spotify Engineering 發文，2026 年 9 月 3 日 · 記錄至 2026 年 9 月 8 日
LLM 工程 · 一個掛鉤、一個更便宜的模型，以及省下的數字所涵蓋的範圍
把大量讀取分流給更便宜的模型——那 90% 究竟砍掉了什麼
Spotify 的工程部落格介紹了 shunt——一個 Claude Code 外掛，會在大量讀取抵達前線模型之前將其攔截，改為分流給更便宜的工作模型（發布範例中為 gemini-2.5-flash），並回報 Claude 自身權杖用量平均省下 90%。就廠商自己公布的數字而言，這個數字是真的，但範圍比標題所暗示的要窄：它是四個評測情境中三個的均值，計算方式是估算而非實測權杖數，而且它說明的是權杖流向何處，而非總量是否真的減少。
事件經過
事件經過 依確立程度分級
| 確立程度 | 事件內容 | 出處 |
|---|---|---|
| 已確認 | Spotify 在 Portal 中發布了兩個 AiKA Modes——bulk-reader 與 code-writer——並推出 Claude Code 外掛 shunt，透過 PreToolUse hook（暫譯：工具呼叫前掛鉤）攔截大量讀取，改為分流給更便宜的工作模型。發布範例中，兩個模式皆設定為 gemini-2.5-flash，但模型欄位可接受 Portal 執行個體中設定的任何模型。 | Spotify Engineering——2026 年 9 月 3 日 |
| 已確認 | 這個攔截讀取的掛鉤，預設門檻為 350 行，可透過 SHUNT_MIN_LINES 調整；第二個掛鉤則攔截以 cat、head、tail、less 或 more 試圖讀取同一份大檔案的情形，但放行有管線或重導向的指令，視為針對性讀取。 | Spotify Engineering；spotify/portal-ai-plugins |
| 已證實 | 只有讀取那一半受到強制。儲存庫自身的「已知限制」段落載明，code-writer「並無強制機制」——僅 bulk-reader 由掛鉤把關，程式碼生成是否分流，全看 Claude 依技能說明自行決定。 | spotify/portal-ai-plugins 儲存庫 |
| 已確認 | 該外掛自行公布的評測回報，大量讀取的平均省下比例為 90%——正好是三個情境（82%、94%、94%）的均值。第四個「程式碼生成」情境不列入此均值，官方說明其權杖用量較難衡量。 | spotify/portal-ai-plugins 儲存庫 |
| 已確認 | 評測中的權杖數是以「字元數除以四」估算得出，該評測自身的說明寫道：其「衡量的是有無 shunt 時，Claude 情境視窗中的權杖數」——特指 Claude 自身的用量，並非兩個模型的合計總量。 | spotify/portal-ai-plugins 儲存庫 |
| 已確認 | 委派編輯與委派推理皆行不通：工作模型摘要中沒有可靠的行號，而工作模型也漏掉了一個執行緒安全性錯誤，文章作者表示，換成 Claude 拿到相同內容後便自行找出了這個錯誤。 | Spotify Engineering——2026 年 9 月 3 日 |
| 已確認 | Gartner 預測，AI 寫程式的成本將於 2028 年前超越一般開發人員的薪資——這正是 Spotify 該篇文章為此主張直接連結的出處。 | Gartner——2026 年 6 月 24 日 |
| 已確認但無法在此覆核 | 四分之一的工程主管，每位開發人員每月已花費 200 至 500 美元的權杖費用，部分甚至超過 2,000 美元——業界媒體將這組數字歸於同一份 Gartner 研究，但這組數字並未出現在該文章所連結的 Gartner 頁面上。 | DevOps.com 報導 Gartner 研究——2026 年 6 月 30 日 |
| 已確認但無法在此覆核 | 該評測所依據的內部單一儲存庫（monorepo）——據稱有 16.2 萬行 Java 程式碼——並未公開，不過該外掛最初的提交請求中，確實列出了真實的內部檔案名稱，而非佔位用的假名。 | spotify/portal-ai-plugins 儲存庫（兩個分支） |
| 未公開 | 目前沒有任何獨立第三方，針對不同的程式碼庫重現或驗證過這個已公布的 90% 數字。 | 已查核的來源中並無此紀錄 |
時間軸
時間軸 依序列出所有有日期的事件
- 2026 年 6 月 24 日Gartner 發布新聞稿，預測 AI 寫程式的成本將於 2028 年前超越一般開發人員的薪資。
- 2026 年 6 月 30 日DevOps.com 報導同一份研究，補充了每位開發人員的具體美元數字，並自行加註：2028 年的預測本質上具有推測性質。
- 2026 年 8 月 12 日
shunt外掛的提交請求開啟，其中列出了原始評測所依據的真實內部檔案。 - 2026 年 8 月 14 日
shunt併入公開儲存庫；其 README 中的評測表格於同日改為通用化的情境名稱。 - 2026 年 9 月 3 日Spotify Engineering 發布由 Dimitri Mazmanov 撰寫的文章，介紹
shunt及其評測結果。 - 2026 年 9 月 6 日獨立評論文章發表，明確表示不應將這個 90% 的數字，視為超出「自行回報」範圍的依據。
論點
論點 是轉嫁，不是消失——而且範圍比標題窄
shunt 並沒有讓權杖憑空消失，而是把它們轉移到別處。原本會填滿 Claude 自身情境視窗的大檔案，一旦遇上這個掛鉤，讀取便會被攔截，改交由另一個工作模型在其自身的情境視窗中處理。該貼文對「重複發送同樣的檔案為何不花額外成本」的解釋，正好點出了這一點：重新傳送檔案「在關鍵處是免費的，因為這批內容進了工作模型，從未進入 Claude 的情境視窗」——這句話講的是哪一個模型的情境視窗要負擔這筆成本，而不是說兩個模型加總後的總量變小了。該外掛自身評測檔案中的方法論說明，也印證了這個讀法：它「衡量的是有無 shunt 時，Claude 情境視窗中的權杖數」——特指 Claude 自身的用量，而非兩個模型合計的用量。工作模型自身消耗多少權杖、每個權杖要價多少，均未見於所查核的任何資料，因此並無任何資料證實總成本確實下降。
- 90%Claude 自身權杖用量，三個情境的均值
- gemini-2.5-flash發布範例中的工作模型
已公布的「90%」，正好是三個大量讀取情境的均值——82%（33,684 降至 5,737 個權杖）、94%（75,990 降至 4,148）、94%（16,221 降至 821），分別對應 4,014、7,408、1,281 行的檔案——並未納入第四個「程式碼生成」情境。文章本身指出，該情境「較難以權杖衡量」：若無此外掛，Claude 既要讀取參考檔案，還得把產出結果當成昂貴的輸出權杖生成；有了外掛之後，程式碼則直接寫入磁碟，Claude 完全不會看到它。這四個情境背後的權杖數字，本身也只是估算：評測檔案自行記載其方法為「字元數除以四」，並自稱是「對程式碼而言較為保守的估算法」——不論對哪一個模型而言，這都不是實測的權杖計數，也不是供應商回報的計費用量。
- 四之三情境數，納入已公布均值
- 字元 ÷ 4評測自訂的權杖計數方法
這些數字確實有真實的內部原始碼作為依據：在公開儲存庫的 README 改為通用說法之前，該外掛最初的提交請求，曾為三個大量讀取情境中的兩個，指名了真實的內部檔案 SpotifyUri.java，以及真實的儲存庫元件 PromotionRuleRepository——這證明評測確實跑在真實原始碼之上，儘管 Spotify 並未公開這份原始碼本身，讀者也無法針對同一批檔案重跑同一組比較。在所查核的範圍內，也沒有找到任何獨立第三方，針對不同程式碼庫重跑過這項比較；唯一找到的外部評論，明確將這個數字視為「自行回報」：「這個數字是自行回報、且與工作內容高度相關的……應將它視為 Spotify 對自家程式碼庫的測量結果。」
- 16.2 萬行評測所稱的 Java 單一儲存庫規模，本身並未公開
其他來源怎麼說
其他來源怎麼說 Anthropic 自家工具中也有同樣形狀的解法，旁邊還有兩個不同的問題
- 約 5.5 萬典型多伺服器工具目錄，光是工具定義就耗費的權杖數，尚未開始任何工作
- 85% 以上在同一情境下，tool search 回報可減少的比例，只載入請求所需的工具
- claude-haiku-4-5Anthropic 自家多代理範例中，用來委派高讀取量工作的較便宜模型
- 0已查核來源中，找到針對已公布的 90% 數字進行獨立重現的次數
| 機制 | 針對對象 | 運作位置 |
|---|---|---|
shunt（Portal by Spotify） | 大量檔案讀取與樣板程式碼生成 | 外部外掛與平台，透過 PreToolUse hook 路由 |
| Claude Code 子代理 | 任何高讀取量的子任務 | 內建於 Claude Code 本身；子代理可固定使用如 Haiku 等較便宜的模型 |
| Managed Agents 多代理連線 | 並行分派出去的獨立、高讀取量子任務 | Anthropic 自家的 Agent SDK／平台；每個受託代理都有自己的模型與獨立情境視窗 |
Tool search（defer_loading） | 工具定義本身造成的臃腫，而非檔案讀取 | Anthropic 自家的 tool-use API；只載入請求所需的少數工具 |
Context editing（clear_tool_uses） | 已進入情境視窗、但已過時的工具結果 | Anthropic 自家的情境管理 API；一旦超過設定門檻，便清除舊有結果 |
結論
結論 哪些可以確信，哪些應保留態度
確有其省，但名不副實
就其自身公布的數字而言，Spotify 回報的省下確有其事，但這是把支出從昂貴模型的情境視窗，轉嫁到較便宜模型的情境視窗，而非證實整體權杖用量真的減少——目前沒有任何公開資料說明工作模型本身要花多少成本。
三個情境，不是整個外掛
90% 這個數字，說的是三個大量讀取情境的均值，且權杖數本身是估算而來；第四個情境（程式碼生成）被明確排除在此均值之外，而這四個情境當中，沒有任何一個獲得外部重現驗證。
這種解法的樣式並不新
把高讀取量的工作，分流給在自身情境視窗中運作的較便宜模型，這種做法早已存在於 Claude Code 子代理與 Anthropic 的 Managed Agents 多代理連線之中，屬於官方自有機制。Spotify 這篇文章增添的，是一個具體實作範例，專門針對檔案讀取與樣板程式碼——而不是一個關於代理權杖該流向何處的新構想。