任務成本勝過 Token 成本

資料來源#

• Agent swarms and the new model economics
• Build more natural voice experiences with GPT‑Live‑1 in the API
• Building Prod with Jev and LangGraph
• Claude models explained: choosing the best model for your use case
• Codex from 0 to 10M Users: Building ChatGPT Work - Akshay Nathan, OpenAI
• Fable's judgement
• GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks
• Gemini 3.5 Flash-Lite Model Card
• HarnessTax: How Much Does the Harness Matter for Coding Agents?
• How is the Bun Rewrite in Rust Going?
• Introducing Gemini 3.8 Live and 3.8 Live Extended Thinking
• Introducing System One Models & Jev
• Recursive Self Improvement for Coding Agents
• Running a Software Factory Efficiently at Uber Scale
• September 2026 Ramp AI Index: Cracks in the AI thesis, part 2
• Startup ARR is less secure than ever, new research shows
• The Harness Effect: How Orchestration Design Sets the Token Economics of Enterprise Agentic AI
• The price is wrong: AI cost calculation has to consider task completion rates, not just token costs
• The state of AI in 2026: On the road to ROI

摘要#

Anthropic 對「這項工作負載該用哪個模型？」給出的公開答案（vendor-claim，2026 年 7 月）。預設建議顛倒了直覺：從一般可用模型中最聰明的那個開始，再用推理力度調低效能與成本——不要先從便宜的模型開始，再逐步升級。核心主張是，兩種成本指標會分道揚鑣：較強模型的每個 token 價格較高，但每項任務的成本往往較低，「因為能力更強的模型通常用較少回合、較少思考時間，就能把大多數任務做好。」

另一個獨立發揮作用的非經濟論點是：**從較小的模型開始，會更難分辨模型失敗與設定失敗。**弱模型在你的 harness 上失敗，無法告訴你 harness 是否有問題。先從一個失敗具有診斷意義的能力等級開始，再往下調。

Anthropic 兩種方向都有記錄——從強模型開始再往下調，以及從便宜模型開始，逐步升級直到品質達標——但主推前者。

為何兩種成本指標會分歧#

一項任務的成本是（每回合 token 數）×（回合數）×（每個 token 的價格）。模型類別會改變這三項，而且方向不盡相同：

• **回合數。**較強的模型第一次嘗試就能做好更多任務；重試、重新規劃與修復迴圈，才是便宜模型省下的錢流失之處。
• **思考 token。**在相同推理力度設定下，較強的模型能以較少的斟酌抵達答案。
• **價格。**較強模型的價格更高——這是唯一有利於便宜選項的項目。

主張是，前兩項通常影響更大。請留意這個論證沒有涵蓋的失敗模式：如果較強模型不是收斂，而是過度斟酌，同一套算式就會反轉——參見無效的自我驗證：Opus 5 在較高推理力度下表現更差，因為它反覆重新驗證已經驗證過的答案。每項任務成本的論點，只在額外能力帶來收斂而非反覆思索時成立。

推理力度是第二個軸#

模型類別與推理力度是兩個不同的旋鈕，而且兩者有重疊：「較高階模型搭配較低推理力度，有時會比小模型更有效率。」因此，選擇空間是 2D 網格，不是階梯——低推理力度的 Opus 與高推理力度的 Sonnet 是不同的點，成本卻可能相同。兩條公開曲線（品質對成本、品質對延遲）標註為**「僅供示意，並非根據基準測試資料繪製」**——取捨形狀是主張出來的，不是測量出來的。對廠商的選型指南而言，這種坦率相當少見，也代表這裡沒有任何可供規劃使用的數字。

這和大規模測試時運算所提出的「推論預算即能力」論點相同，只是以產品選項而非研究發現的形式呈現。

模型類別#

Anthropic 的說法是：類別不會依領域專門化（「我們不建議財務用一種模型類別、科學用另一種」）。每個類別都接受過程式設計、代理程式任務與知識工作訓練。唯一的軸線是這個類別能穩定處理多難的問題，以及相應的成本。

類別	定位	備註
Mythos / Fable	能力最強；各領域的前沿水準；程式設計、長期運行的代理程式、先前未解決的問題	以同一個底層模型提供的兩種方案：Mythos 提供給從事雙重用途網路／生物工作的 Project Glasswing 組織；Fable 則加入額外防護措施，使其適合公開使用。兩者都要求有限的資料保留期限
Opus	推理密集的企業任務	引用的基準測試：GDPval-AA（知識工作）、Terminal-Bench 2.1（代理程式程式設計）
Sonnet	日常任務；兼顧效能、成本與速度	特別指出適用於多代理程式協調中的高流量 sub-agent
Haiku	成本最低、速度最快	延遲與成本優先的高頻工作負載

Opus 與 Fable：基準測試看不出的差異#

這篇文章最有意思的主張。Opus 和 Fable 的「基準測試分數相近」，但：「在真實情境中，Fable 等較大型模型往往更有智慧、更有創意，寫作能力也更好。」因此提出的決策規則根本不是以基準測試為準——

如果你的評估或內部測試顯示 Opus 在某些任務上力有未逮，那麼 Fable 就是答案。如果 Opus 已達到品質門檻，那麼它的速度與價格特性可能讓它成為更好的選擇。

廠商承認自家基準測試分數無法區分相鄰的兩個類別，等於第一方承認建構效度不足——與研究面向的超越準確率飽和的測量記錄的是同一道落差：統計上無法區分的代理程式，在可靠性、效率與成本上仍有顯著差異。

四個選擇問題#

1. **任務有多難？**多步驟、長時間執行或先前未解決的任務 → 選較高階類別。
2. **延遲需求為何？**高頻、面向客戶的任務 → Sonnet。
3. **有哪些存取限制？**Mythos 僅限 Glasswing；並非每個組織都會向每種角色開放所有類別。
4. **單位經濟效益如何？**在大量生產情境中，若評估顯示任務能順利完成，較低階的類別可能更合適。

請注意，問題 4 交由評估決定，問題 1 則交由判斷決定。這套架構是測量工作的支架，不能取代測量。

顧問策略#

一種避免二選一的混合做法：較快、較便宜的工作者模型呼叫更聰明的顧問模型，請它檢查計畫並評估成果——「只有在需要時才由顧問模型指導執行模型。」

唯一量化的結果：在 SWE-bench Pro 上，由 Fable 5 擔任顧問的 Sonnet 5，得分落在 Fable 5 自身分數的 10% 以內，而成本是整項任務全程使用 Fable 5 的 63%。

有兩點讓這不只是省錢技巧：

• 這是第一方正式推薦的最佳化器與評估器解耦——評分工作的模型，在結構上不同於產出成果的模型。Anthropic 從成本角度得出與代理程式品質文獻從 Goodhart 角度得出的相同不變原則。
• 這部分回答了「便宜模型在何處應該換成昂貴模型？」這個尚未解決的問題（Claude Sonnet 5）：轉折點不在推理力度旋鈕上，而在於另一種拓撲結構。選擇性指導勝過「讓便宜模型更努力」和「全程使用昂貴模型」兩種做法。

注意：63% 的成本是和全程使用 Fable 5相比，而非只和 Sonnet 5 相比——顧問模型是在便宜路徑上加價；而 10% 的品質差距確實存在。

從廠商角度看這項區別#

DeepMind 的 Gemini 3.5 Flash-Lite 模型卡（2026-07-21，vendor-claim）展示了廠商只公布一半論點時，這頁主張會呈現什麼樣貌。它的基準測試表以價格列開場——列出自身、前代模型、GPT-5.4 mini 和 Claude Haiku 4.5 的每百萬輸入與輸出 token 價格——而它自身代際之間的變化，恰好就是 Anthropic 所描述的模式：輸出每個 token 的價格上漲 67%，能力則提升完整一個級距（SWE-Bench Pro 38.3 → 54.2、OSWorld-Verified 54.3 → 74.0）。如果每項任務成本的論點成立，那麼更貴的模型反而是較便宜的選擇；這是語料中第一個跨廠商的此類案例。

這也最清楚地說明了為何該論點仍未獲驗證。模型卡沒有公布四種模型各自每項任務的 token 數、回合數或思考預算——因此能決定勝負的那一項（較強模型是否能用更少回合、更少思考 token 收斂？）並未出現在唯一列出價格的資料中。兩家廠商都公布價格軸，卻都沒有公布 token 軸；至少 Anthropic 將曲線標示為「僅供示意」，而 DeepMind 的數字看起來很精確，卻漏掉了相同的乘數。每美元的計算方式見推論效率即能力；為何價格列不等於運算預算，見運算受控的基準測試。

四種混合配置、相同品質門檻、成本相差 8 倍（Cursor，2026）#

以上每個來源都列出價格，卻省略任務本身。Cursor 的 swarm 文章（Wilson Lin，2026-07-20，case-study）是語料中第一個反其道而行的案例：固定任務、harness 與時間預算，只改變各角色使用的模型，並公布金額。

任務是從頭以 Rust 實作 SQLite，並以保留測試集評分（平行代理程式協調）。四種配置都以四小時為限：GPT-5.5 同時擔任規劃者與工作者；Grok 4.5 同時擔任兩者；由 Opus 4.8 規劃、Composer 2.5 執行；由 Fable 5 規劃、Composer 2.5 執行。文字只提供成本範圍的兩端——從 Opus 4.8 混合配置的 $1,339 到僅用 GPT-5.5 的 $10,565（各次執行的長條圖未被這次擷取收錄）。

Cursor 的總結是：「每種模型混合配置都產生相近品質，但成本差異極大。」截止時的品質介於 73% 與 85% 之間，四種配置最終都通過了整套測試。這是罕見案例——在真實基礎設施上、Anthropic 以外、達到共同品質門檻時，成本相差 8 倍。

背後有三項發現：

• Token 與金額的分布不同，而這種分歧正是整個論點的核心。每次執行中，工作者至少承擔 69% 的 token 數，多數情況超過 90%。但在 Opus／Composer 混合配置中，規劃者只產生一小部分 token，卻占了大約三分之二的成本；工作者群組處理絕大多數 token，只花掉剩下的三分之一。前沿模型之所以負擔得起，正是因為很少需要前沿級判斷：「大型任務中真正需要前沿智慧的時刻很少……一旦前沿規劃者把模糊之處化為詳細明確的指令，較便宜的模型只需照做即可。」
• **工作者這一項才是花錢的地方。**GPT-5.5 同時做兩種工作時，光是工作者就花了 $9,373；Opus 負責規劃、Composer 負責執行，整個工作者群組只花了 $411——同一任務、同一評分，成本相差 23 倍。這是語料中最有力的證據，支持指南自己一句話的保留條件（「多代理程式協調中的高流量 sub-agent 使用 Sonnet」），但指南並未進一步說明。
• 每個角色內的每項任務成本維持原論點，到了系統層級卻反轉。Fable 5 規劃者的收費略低於 Opus 4.8 規劃者，儘管其每個 token 的價格約為兩倍，因為它產生的規劃 token 少得多——這頁的論點在規劃者角色上獲得證實。但 Fable 那次執行的整體成本明顯較高，因為工作者消耗了數倍的 token。更好的規劃者把成本轉嫁到了下游。每個角色各自計算的每項任務成本都可能正確，但帳單總額仍可能算錯。

最後這一點最值得記住。廠商指南談「一項工作負載」時，彷彿其中只有一個模型；一旦流程有兩種角色，模型成本就包含它促使其他模型執行的工作，單一角色的測量看不見這項成本。這是成本面對應於用戶端代理程式最佳化之組合抽象所描述跨階段耦合的雙生概念。

**適度看待這些結果。**研究由廠商撰寫、使用廠商自己的 harness，且兩種較便宜配置的工作者都使用廠商自家的模型 Composer 2.5——若以絕對數字比較各種配置，也會受到同時進行 harness 改版的混淆（此處未計算舊 harness 的執行成本）。能補足前沿模型成本圖像的 Opus 4.8 與 Fable 5 單獨執行結果，「只做了非正式評分」，所以 Cursor 明確表示不對其品質下結論。

模型選單之上的一層（Writer，2026）#

以上每個來源都改變模型。Writer 的 harness 替換論文（arXiv 2607.06906，2026-07-08，empirical）固定模型，改變協調層——22 項鎖定任務、來自五家廠商的六個模型、一組 LLM 評審小組、一份固定價格表，以及唯一變數：傳統生產代理程式迴圈（凍結於 2026-06-07）對比 Writer 的 Agent Harness。整體結果：每項任務成本 −41%（$0.21 → $0.12）、token 數 −38%（14.2k → 8.8k）、實際時間 −44%、品質持平（0.78 → 0.81，在 n = 22 時報告為無明顯差異）。

與這頁相關的結果是槓桿比較：在基準配置中，從最貴的模型（Palmyra X6，每項任務 $0.25）換到最便宜的模型（Qwen 3.6，$0.16），可省 36%；保留任一模型並換用新 harness，則可省 33–61%，六個模型無一例外。**在這項工作負載中，協調層對帳單的影響，大於整個模型選單的價差。**Writer 的說法是：「比較不同廠商每百萬 token 價格的團隊，比的是 p；帳單則是 p × τ，而 τ 由 harness 決定。」

這項研究也一次為六個模型補上這頁不斷記錄為缺漏的 token 軸——每項任務的 token 數、回合相關成本及延遲，全都採用同一份價格表。這項軸線上的結果並不支持從強模型開始的預設。將論文中各模型基準配置的品質平均值除以各自基準配置的成本（根據兩份已核實表格計算，並非論文直接列出的數字）：

模型，基準組	平均品質	$/任務	每美元品質
Palmyra X6	.789	$0.25	3.16
Claude Sonnet 4.6	.785	$0.24	3.27
GLM 5.1	.752	$0.21	3.58
Gemini 3.1	.765	$0.19	4.03
Gemini Flash 3.5	.740	$0.18	4.11
Qwen 3.6	.710	$0.16	4.44

排序呈單調趨勢，而且與「從能力最強的模型開始」背道而馳：最強的兩個模型每美元效益最差；支付溢價所換得的能力差距，只有能力平均分數的八分。將此視為反駁前有三點需要保留：各組的品質並未配對一致（這是比值，並非固定品質下的比較）；工作負載是企業助理任務集，而非理應靠減少回合數來賺回成本的長期代理程式工作；品質以 LLM 評分，n = 22。不過，這是語料中第一個在 Anthropic 以外的基礎設施上，同時公布各模型成本與品質的案例；價格與每項任務成本的相關性為正而非負。

利益衝突完全公開，應據此看待：33 位作者全是 Writer 員工，末位作者是共同創辦人兼 CTO，受測 harness 屬於 Writer，基準則是 Writer 自己已淘汰的迴圈，而 Palmyra X6 是 Writer 的模型。論文自行揭露利益衝突，研究設計也可稽核（基準已凍結、提示已鎖定、評審與價格表相同、候選模型失敗仍計分而非排除）。包括機制清單與「harness 槓桿」發現的完整分析，見協調方式決定 Token 經濟效益。

生產基準測試：Databricks 在自家程式碼庫上測試（2026）#

Writer 的論文是廠商以自家產品作基準測試。五天後發表的生產環境對應案例，在模型軸線上得出相反方向的結果。根據 The Register（Thomas Claburn，2026-07-13，case-study，對 Databricks 基準測試部落格文章及 CTO Matei Zaharia 社群貼文的二手報導），Databricks 表示，這項內部程式設計基準測試取材自員工在自家數百萬行程式碼庫中實際完成的工程任務——Zaharia 說，他們之所以建立這項測試，是因為模型會針對 SWE-Bench 之類的公開基準進行調校，而文章指出 OpenAI 曾稱這項基準「已經失效」。

模型	$ / 任務	任務成功率
Opus 4.8	$1.94	87%
Sonnet 5	$2.09	81%
GLM 5.2（Z.ai，開放權重）	$1.28	品質「與 Opus 4.8 在統計上不相上下」

「每個 token 較便宜，不代表每項任務也較便宜。例如 Sonnet 5 的每個 token 價格低於 Opus 4.8，但它使用了更多 token，因此成本更高、品質更低。」——Zaharia

Anthropic 這對模型，正是由第三方測量得出的本頁主張。Sonnet 5 的每個 token「大約便宜 1.7 倍」——符合公開牌價（每百萬 token $3/$15 對 $5/$25 = 1.67 倍；這是本文計算，不是 The Register 列出的數字）——但每項任務反而貴 8%，成功率低六個百分點。兩項非價格因素都對便宜模型不利：每次嘗試使用更多 token，而且嘗試次數也更多。這是語料中第一個案例，證明 Anthropic 對自家模型提出的確切主張，獲得別人在自家生產程式碼庫上、用別人的測量方式確認。有一點不清楚：文章從未說明 $/任務是按嘗試過的任務還是完成的任務計算。如果是按嘗試計算，將成功率納入後，每項完成任務的差距會擴大到大約 $2.58 對 $2.23（同樣是本文計算，並非已公布數字）。

GLM 這一組打破了整齊簡單的規則。開放權重模型進入頂尖能力級距，品質在統計上與 Opus 4.8 不相上下，價格為每項任務 $1.28，比 Opus 低 34%。（文章沒有提供每個 token 的價格；文章的說法是「像 Z.ai 的 GLM 5.2 這類開放權重模型，足以與前沿模型競爭」，而開放權重模型的託管服務屬於選單中的低價端。）因此，所提供選項中最便宜的模型，每項任務也最便宜，而且品質相當。「每個 token 越便宜，每項任務反而越貴」並非價格級距的定律，而是關於完成任務所需 token 數的主張。Sonnet 5 失利，是因為耗用更多 token 且較少完成任務；GLM 5.2 兩者皆非。嚴格來說，在這項工作負載上，從強模型開始的預設會選中現有選項中第二便宜的模型。（這個數字之所以留在原始資料中，只是因為這次擷取流程用 curl 抓到的 HTML 重建了文章內文——WebFetch 默默把它漏掉了。）

兩項基準測試、一項矛盾，值得保留並明確呈現。Writer 在企業助理任務集中發現，模型能力越強，每美元品質越低；Databricks 則在長期程式設計任務集中發現，Anthropic 較強的模型每項任務成本更低。兩者都不是 Anthropic。兩項研究共同支持、但都無法單獨證明的調和說法是：本頁仰賴的收斂因素（較少回合、較少重試），只有在有很多回合可省時才會占上風；這適用於程式設計情境，而非助理情境。請留意兩者可採信程度的不對稱：Writer 的研究屬於 empirical，存在完全的利益衝突，但有完整方法章節；Databricks 則是 case-study，由二手來源轉述，沒有任務數量、變異數、樣本數，也沒有「統計上不相上下」的信賴區間。兩者的數據共同支持的是否定性主張（標示的每 token 價格無法準確預測帳單），而這正是兩組數字實際能支持的主張。

文章引用了一項第三方概括性研究，但本文尚未閱讀。The Register 指向一項學術研究成果（arXiv 2603.23971，2026 年 3 月）：作者進行的模型比較中，約三分之一的案例裡，標示價格較低的模型最後反而更貴——「Gemini 3 Flash 標示價格比 GPT-5.4 便宜 80%，但它在所有任務中的實際成本高出 38%。」這是語料中對本頁主張最廣泛的陳述，目前卻只是線索，而非證據：wiki 尚未讀過論文，這個數字只因同一項 HTML 修復而保留在原始資料中，而且「約三分之一」也代表有三分之二的情況不會反轉。值得納入資料庫。

**利益關係說明。**Zaharia 表示，這些結果促使 Databricks 開發 Omnigent，一個用來組合與替換程式設計代理程式的包裝工具——因此這份報告談到的 harness 層（見協調方式決定 Token 經濟效益）與一項產品有關。不過比較中沒有 Databricks 的 harness 或模型，而 Databricks 也不販售這裡列出的任何模型。

基準測試何時失去幫助#

Anthropic 自己的指南指出，公開基準測試是「有助於掌握方向的參考」，也明確說明選擇何時會變得昂貴：在 Opus／Fable 級距，模型「幾乎能解出測試中的所有問題」（飽和）。指南建議改用一組精選問題，取自生產環境，包括目前工具能力不足的任務，並由團隊自行定義成功條件——這是廠商建議的源自生產環境的評估，也是評估即產品規格的實際做法。

值得指出這裡的循環性：選型架構中最難的兩個問題（任務有多難？單位經濟效益是否可行？）最後都以「建立一項評估」作答；然而，最重要的選擇所涉及的級距，廠商自己的基準測試又被宣告不足。

專案活動成本不等於交付成本#

語料中公開的每項任務成本最高數字，是 Bun Zig→Rust 移植所用的約 $165,000 API token 費用；對照基準是三名工程師工作一年的明確反事實估算。對同一專案的獨立稽核（Lockwood，2026-07-27，case-study）說明這種比較為何不能相提並論，而且這項修正適用範圍遠超 Bun：

• Token 數字以通過測試為界，而非以交付為界。$165,000 涵蓋移植到 5 月 14 日合併至 main 為止。它不包含 CI（一個持續運行的 Buildkite 叢集）、員工監控並重新提示約 50 個工作流程的時間，以及合併後的穩定化階段——距離上次發布標籤十一週後，這項工作仍明顯持續進行；代理程式 PR 佇列也在十八天內從 1,277 件增至約 2,475 件。
• 反事實估算計入全部成本，測量的一方沒有。「三個工程師年」包含薪資、管理費用、審查與 CI；「$165,000」則只有 token 費用。除非雙方採用相同的計算邊界，否則這樣比較必然有利於代理程式路徑。
• **外推數字不是修正後的成本。**Lockwood 估算的約 $800,000，是假設專案仍以每天 $10,000 的速度燒錢得出的——這是推定的速率，不是觀測值，而且他沒有界定計算邊界。他指出的方向成立；數字則是推測，不應當成測量結果重述。

因此，閱讀任何代理程式專案活動的每項任務成本時，實用規則是：先問這個數字的成本計算線畫在哪裡。**首次通過測試的成本，是最便宜且誠實的報告邊界，也是最不可能符合買方真正關心數字的邊界。**這相當於驗證成為新的瓶頸中的會計問題——工作的昂貴部分，位於容易定價的部分之後。

張力：能力最強的模型不一定是最佳元件#

「從強模型開始」的預設，針對的是一項工作負載，隱含假設是單一代理程式。這與用戶端代理程式最佳化的實證多角色結果格格不入：在 HotpotQA 上，Opus 4.6 是 81 種組合中最差的規劃者（它以參數知識作答，而非委派給求解器使用搜尋工具）；Ministral 3 8B 規劃者搭配 Opus 求解器，得分為 74.27%，而 Opus 同時擔任兩者則為 31.71%。AgentOpt 也測量到，準確度相同的流程組合之間，成本差距可達 13 至 32 倍。

依證據權重來看：AgentOpt 屬於 empirical 且採用多角色設計；Anthropic 的指南屬於 vendor-claim 且針對單一角色。兩者並非完全矛盾——「從強模型開始」作為第一個配置是合理的，因為如此一來失敗才有診斷價值——但在流程內指派每個角色時，「從能力最強的模型開始」並非安全建議，而廠商指南也沒有標明這項界線。Anthropic 曾以含蓄方式提過一次：建議多代理程式協調中的「高流量 sub-agent」使用 Sonnet。

另一家廠商的答案：不公布規則，直接提供預設#

Anthropic 對「用哪個模型、推理力度設多高？」的回答，是公布一套供使用者採用的決策程序（從強模型開始再往下調；四個選擇問題；建立一項評估）。OpenAI 在 ChatGPT Work 發布時給出的則恰好相反：**在產品中直接採取明確立場，並隱藏各個軸線。**Akshay Nathan（Codex from 0 to 10M Users: Building ChatGPT Work - Akshay Nathan, OpenAI，practitioner-opinion）：

「我們希望這個預設能做到最好。我的意思是，我們想對預設採取明確立場……我們也為進階使用者提供了底層選項。有人可能會說現在的選項太多，我們正努力簡化……但預設應該要夠好。」

如何將選項簡化說得很清楚。模型類別與推理層級共有「32 種選項」；實際推出的控制項則是單一維度的滑桿——「把它簡化成一個維度，雖然實際上有多個維度……一端是速度與效率，另一端是品質與周詳程度。」這正是本頁的兩個軸線（模型類別 × 推理力度）投射到單一面向使用者的標量；投射方式由廠商決定。

有三件事值得分開看：

• **升級觸發條件相同。**Nathan 建議何時離開預設：「如果你看不到成本面的效率，或智慧面的品質有所改善」——這和 Anthropic 架構所編碼的雙面檢驗相同。兩家廠商都沒有宣稱規定應該先往哪個方向調；兩者都說要測量自己的工作負載。
• **資訊揭露理念不同，而且只有其中一方能被公開證偽。**公開規則可能在眾人面前被證明錯誤（如用戶端代理程式最佳化所示，「從最強模型開始」按角色來看確實不對）。經過調校的預設可能悄悄出錯，使用者無從得知投射方式讓自己付出多少代價。Nathan 自己也有所保留——「對你個人來說，還有一種偏好：你喜歡如何與模型協作」——等於承認這種投射方式並非對所有使用者都一致。
• **兩家都未公布每項任務的 token 數。**前文對 DeepMind 與 Anthropic 提到的缺口，在這裡同樣存在：整段說法都沒有回合數、思考預算或每項任務成本數字。預設被宣稱「適用於多數使用情境」，卻沒有任何依據。

同一集節目中的實務工作者則提出相反的做法：Vibhu 表示，他會指示幾乎每項長時間執行的任務「盡可能使用 sub-agent」，原因是能縮短實際時間，也能「委派給許多較小、較便宜的模型」——這正是本頁反對的每 token 成本直覺，在 sub-agent 層級的實際應用；用戶端代理程式最佳化指出，在這裡它可能確實正確。

誰來挑選模型（Willison，2026 年 7 月）#

以上每個來源都在回答哪個模型或 harness 較便宜。Simon Willison（2026-07-03，practitioner-opinion）則把問題改成由誰決定，答案是模型。他轉述 Jesse Vincent 的一個技巧，向 Claude Code 下達提示：

「所有程式設計任務都請用你的判斷，挑選適合的較低階模型，然後在 subagent 中執行。」

沒有路由表、沒有門檻、沒有逐項任務規則——模型直接接手選擇決策。這是控制平面的選擇，而非定價選擇，也是 Claude Code 團隊建議的一般形式：見模型進步時 harness 的縮減，以「用你的判斷」取代硬性規則，正是 Anthropic 在自家系統提示中採取的相同做法。

接著模型寫進自己記憶檔案的政策，無人提示便重述了本頁結論——以成本／效率為考量，「實作工作很少需要最高階模型；判斷、審查與綜整則留給主迴圈」，並點名 Sonnet 負責實質實作、Haiku 負責瑣碎修改。這是某位開發者用一句話得出的 Cursor 規劃者／工作者分工。這種安排也是用戶端代理程式最佳化所指出失敗模式的例子——強模型自己作答，而沒有委派；但這個提示恰恰要求強模型自我監督，避免犯下該錯誤。

這裡沒有任何測量：「目前看來運作得不錯」，而且 Fable 使用額度「縮減得沒以前快」，但沒有基準、沒有任務集、沒有金額，也沒有檢查模型自行選擇的級距是否恰當。把它記錄為實際使用中的做法——也是前文提到的第二種相反趨勢案例，唯一有意思的差異在於：Vibhu 指定級距；Willison 則把指定級距這件事交給模型。

第三種單位：每分鐘的在場成本（OpenAI，2026 年 9 月）#

以上所有內容都以 tokens 計價，並將成本與 tasks 比較。GPT-Live-1 的 API 上線公告（OpenAI，2026-09-10，vendor-claim）提出一種兩種指標都未涵蓋的單位：全雙工語音層每分鐘 $0.05，後端模型在其後「配對」運作，並依照一般 per-token 方式另外計費。

這件事為何與本頁有關，而不只是語音相關頁面的議題：

• 同一個代理程式的兩個部分，現在以不同單位計費。互動部分按「在場時間」計價——不論使用者持續說話或保持沉默，也不論後端是否進行大量推理，成本都相同。背景部分則按「完成的工作量」計價。因此，cost-per-task 的框架只適用於系統其中一半；另一半的成本取決於對話的持續時間，而這個變數不受模型選擇控制。
• 這顛倒了努力程度的調節方向。本頁的第二個軸是努力程度：調低推理程度，token 費用就會降低。對語音代理程式而言，調低努力程度會縮短後端費用，卻不會延長任何事情；但調高努力程度會增加使用者等待的實際時間——而每分鐘計費器會對此收費。因此，推理努力程度會同時增加兩種單位的成本，而且方向相同；第二種成本在任何 token 帳目中都看不見。這是本語料中首次出現「思考越久，收費越多」的雙重計費。
• **這清楚呈現了「昂貴的部分，就是受硬性限制的部分」這個案例。**OpenAI 對無法停頓的部分計量（Live-Path Minimalism），並將可以停頓的部分商品化，甚至把第三方模型列為可接受的後端。Cost-per-task 的推理適用於商品化的那一半；另一半的定價方式則像租用專線。

這些內容沒有任何 cost-per-task 測量——該公告只公布價格，沒有使用資料，因此無法測試本頁的核心主張。本文將它記錄為框架必須納入的一種單位，而非模型選擇的證據。

五天後，第三方在某項工作負載上測量了這個單位（Google，2026-09-15）。Google 的 Gemini 3.8 Live 發表公告（vendor-claim）重現了一張 Artificial Analysis 圖表，標題為 每小時輸入音訊成本，以 Big Bench Audio 子集計算：Gemini 3.8 Live $0.84、Gemini 3.1 Flash Live minimal $1.50 / high $1.75、Gemini 3.8 Live Extended Thinking (high) $3.50、Grok Voice Think Fast 2.0 $4.80、GPT-Live-1 + Astra (medium) $5.83。這項資料補足了價格表無法提供的三件事。

• 這是以明確工作負載測得的帳單，也就是本頁一再指出沒人公布的資料。它不是要乘上未知 token 數量的費率，而是在跑完一個基準測試子集後實際產生的成本，並以使用者能控制的唯一數量作標準化。它的缺陷恰好與常見情況相反：揭露了分母，卻沒有揭露分子的組成。沒有說明後端 tokens、輸出音訊或思考時間是否計入；圖表上的方法註腳指向 Google 的頁面，而非評估者的頁面。
• 努力程度的調節現在以每單位時間成本呈現，代價是 4.2 倍。在同一供應商的項目中，以固定一小時輸入音訊比較，從 3.8 Live 切換到 Extended Thinking，帳單從 $0.84 → $3.50，增加 4.2 倍；綜合品質指數則從 76.0 → 82.6（+6.6 分），代理能力項目從 30.1 → 68.6（+38.5）。由於分母是使用者說話的時間，而非模型的工作量，這 4.2 倍全都是每分鐘對話所花的思考成本。這讓前一節所說的「思考越久，收費越多」不再只是結構上的特性，而是可測量的現象；但只有在接受一小時輸入音訊等同一項任務時，它才算是 cost-per-task 的結果。這與把一個基準測試項目視為一項任務，是同一種假設。
• 一項算術檢查，註明是推論而非發現。GPT-Live-1 + Astra 每小時音訊 $5.83，換算為每分鐘 $0.097；OpenAI 公布的前端層單獨計價為每分鐘 $0.05。兩者相符的解讀是，在這項工作負載中，委派工作的語音代理程式實際成本約有一半落在接縫後方——但前提是 AA 的一小時輸入音訊對應一個計費分鐘（未必如此：基準測試子集不是對話，而且模型思考期間的實際時間不等於音訊時長），也必須假設分子包含了推測所需的項目。記錄這項資料，是因為它首次讓本語料能比較定價拆分後的兩部分；刻意不將它當作數字用於 wiki 的其他地方。

Google 本身沒有公布任何一個模型的價格，因此這些費用都無法按費率實際購買——關於這種定價邊界的形式為何仍只有一個供應商案例，請見互動／背景模型拆分。

買方端，市場規模下的情況（Ramp，2026 年 9 月）#

以上每項測量都是基準測試，或單一組織內的正式環境執行結果。Ramp 2026 年 9 月 AI Index（Ara Kharazian，empirical，企業卡與帳單支付紀錄涵蓋約 70,000 家美國企業；研究工具與利益衝突見 Ramp）是本語料中首個呈現「買方群體如何面對本頁所描述選擇」的來源——而這個群體正逐漸遠離最強的模型。

• **前沿模型的 token 占比正在下降。**Opus、Fable 和 Sol 在 2026 年 8 月 2 日當週占 52.5% 的 tokens，到 8 月 30 日當週降為 44.7%；標準級模型（GPT-5.6 Terra、Claude 的 Sonnet 系列）則從 25.7% → 35.8%。該信函給出的解釋是，買方「施行全公司預設值，以減少前沿模型的使用；他們認為標準模型仍有很高的效能，而且更具成本效益」。
• 每個 token 的混合平均價格大幅下跌。每百萬 tokens 的有效價格從 2026 年 3 月的高點 $1.15 下跌 41%，來到 $0.68。這是混合指標——同時混合了公布的牌價降幅（兩家實驗室都在報告發布前一個月調降價格）與上面的級別轉移，沒有將兩者分開。
• **兩家實驗室的有效價格已經分歧，但信函完全沒提。**復原的每日序列顯示，OpenAI token 的混合平均價格從 $0.681（2026-03-01）→ $0.339（2026-09-02），Anthropic 則從 $1.512 → $0.891。這段期間結束時，Anthropic 每個 token 的有效價格是 OpenAI 的 2.6 倍，而且自 7 月以來大致持平（2026-07-01 為 $0.888）；因此，近期混合指數的跌幅幾乎全來自 OpenAI。（Vault 以圖表資料集計算。CSV 端點由 CDN 快取，資料尾端落後於正文；因此此處的價格水準取自序列，目前值則採正文的 $0.68。）

**這些資料能證明什麼，不能證明什麼。它不是 cost-per-task 測量：Ramp 只計算金額和 tokens，從不計算 tasks、對話輪次或完成次數，因此無法測試更強的模型能否用較少輪次完成任務。它提供的是市場規模下的顯示性偏好，而市場採用的規則並非本頁的規則。**買方採用的是「效能仍然很高」而且每個 token 更便宜的滿意化標準；這正是本頁開頭所反駁的 price-per-token 推理。現有資料仍支持兩種解讀，而這項研究工具無法區分：市場可能正犯下本頁一開始指出的錯誤（只最佳化看得見的單位，卻讓看不見的 tokens-to-completion 惡化）；或者，標準級模型已達到大多數正式環境工作的品質門檻，供應商預設值已經過時。上面的 Databricks 基準測試最接近能做出裁定的資料，但它也呈現相同分歧——在 Anthropic 自家系列中，Opus 的每項任務成本比 Sonnet 低；而在品質持平時，開放權重模型比兩者都便宜。

對以上內容的一項影響。本頁每個金額——Cursor 的 $1,339 對比 $10,565、Writer 的每項任務成本、Databricks 的 $1.94 對比 $2.09——都是以後來已經變動的價格表測量，混合價格整體約變動了 41%，且各供應商與級別的變化並不一致。這些比較並未失效，因為每項比較都來自單一研究，並以研究當天的價格計算；但它們都不能再被當作目前的金額引用。

買方希望計費器計算什麼（a16z 透過 TechCrunch，2026 年 9 月）#

以上內容都在討論賣方該用哪種分母來推理。Julie Bort 的 TechCrunch 文章（2026-09-03，practitioner-opinion——一篇報導某位創投人士貼文、但未取得原文的新聞文章）是此處首個詢問買方希望發票採用哪種分母的來源；其答案從交易桌另一側得出與本頁論點相同的方向：a16z 對 50 位技術領域 AI 買方的調查顯示，超過半數希望 AI 費用依產出的工作或其他成果計價，而非按 tokens 消耗量等使用量計價。

a16z 合夥人 Tugce Erten 與 Sarah Wang 從產品而非成本的角度提出論點——依「可辨識的工作成果」定價（處理的報告、結案的客服單、開發的潛在客戶），才能證明產品的價值，並讓產品「對雙方都具有經濟價值」；token 計量則是 SaaS 時代按席位與儲存空間計價的習慣，被套用到價值並不與用量成正比的產品上。

儘管聽起來相似，這與本頁的主張並不相同。本頁主張，cost-per-task 是做出模型選擇時的正確單位，因為 tokens-to-completion 會隨能力而變化。a16z 主張，outcome-per-fee 是做出商業決策時的正確單位，因為簽約者無法將 token 數量理解為價值。雙方都認為 token 是錯誤的單位，但對於應由誰承擔其變動風險看法不同：cost-per-task 框架告訴買方，別只看標價，還要看帳單；成果定價則告訴買方，帳單也不用看，並把全部 token 數量風險轉移給賣方——正是下文 McKinsey 的 Chui 所描述的風險：每個 token 的價格下降，但消耗量上升得更快。接受這種需求的應用供應商，等於直接把 price-per-token 與 cost-per-task 之間的差額寫進自己的毛利。

值得注意的是，這也與上面測得的顯示性偏好完全相反。Ramp 約 70,000 家企業正透過設定全公司模型預設值來降低自己的 token 帳單——更謹慎地購買 tokens。a16z 的 50 位買方則想停止購買 tokens。兩者並不矛盾：前一群體購買的是模型 API，後一群體購買的是以模型 API 為基礎的應用程式；這兩種說法自然導向的均衡，是 token 計量風險集中在中間層。兩項調查都沒有測量任務，而 n=50 且未公布抽樣框，是本頁人口資料中最薄弱的一項——此處僅將它視為計費單位的需求訊號，而非成本證據。

當帳單限制了工作量（McKinsey，2026 年 8 月）#

以上每項測量都為一項任務定價。The state of AI in 2026（McKinsey / QuantumBlack，2026-08-25，empirical，但為自陳資料；97 個國家、1,719 位受訪者）提供了市場規模下的組織後果：約 20% 的受訪者表示，AI 相關營運成本（包括 token 成本）限制了所屬組織使用 AI（Exhibit 8）——依產業別為 12% 至 25%，各公司規模大致持平；若分開計算聊天機器人、代理程式與程式設計代理程式，各自約有十分之一受此限制。

限制呈現的樣貌才是本頁關注的部分。限制集中在軟體程式設計代理程式，而且在較高績效者身上更為集中：在 AI 高績效者（6% 的受訪者表示 AI 對 EBIT 的貢獻至少為 5%）中，有 18% 表示程式設計代理程式的使用受到成本限制，其他受訪者則為 6%——這是 Exhibit 14 中唯一一類工具，領先群體回報的限制高於其他群體（聊天機器人 10 對 9、其他代理程式 8 對 9、專用工具 6 對 6）。Michael Chui 在文章的評論中說明了背後的機制：

「他們發現，在最能受惠於前沿模型的代理程式軟體開發和複雜推理任務中，AI 並非『便宜到不必計量』：即使每個 token 的成本下降，消耗與產生的 tokens 數量增加得更快。」

這是第三方對本頁論點的重述，且該第三方沒有模型可賣：每個 token 的價格下降，不代表帳單下降，因為消耗單位是任務，而任務的 token 數量取決於工作內容，不是價格表。這項調查無法做的是測試任何版本的 cost-per-task 規則——它沒有測量任務、輪次、完成次數或模型選擇；而 28% 的受訪者表示 AI 占 ICT 預算超過 10%，指的是支出水準，不是分母。應將其視為當下模型選擇問題的需求端背景，而非該問題的證據。

完整技術堆疊，從頭到尾測量（Uber，2026-08）#

以上每個來源都為一項調節手段定價——模型、harness、快取，或買方對不同計費器的需求。Uber 對其「軟體工廠」的描述（Medisetty，2026-08-27，case-study，第一方工程部落格）是本語料中首個在正式環境流量上，同時公布成本公式並為每個項目定價的來源：超過 70% 的 PR 歸因於代理程式、3,600 多項代理程式技能、每日 30K 多次技能執行。

公式。Total Spend = Users × Sessions/User × Turns/Session × Requests/Turn × Tokens/Request × Price/Token。依影響分組：{Users, Sessions/User} 增加（採用）；{Turns/Session, Requests/Turn, Tokens/Request} 與 {Price/Token} 減少（最佳化目標）——本頁的各項貢獻研究都分別為其中一兩項定價，同樣涵蓋六個面向。二月至七月期間固定使用同一模型，每 1,000 次請求的成本從高峰下降 34%，每個工作階段的成本則從六月高峰下降 52%——兩者都是在各自指標的最低點測得，而且到八月時都已稍微回升；來源對自家圖表提出這項但書，本頁也照實重述，沒有略過。

以明確的正式環境資料點進行 Pareto 模型選擇。uReview（為所有 PR 執行 AI 程式碼審查）使用已知有錯誤的真實 PR 進行基準測試，依難度評分，並測量 precision/recall/F1、每次審查成本、延遲、逾時與雜訊。十種配置以 F1 對照每次審查成本（對數尺度）：兩個封閉前沿資料點約為 $2.2–2.4/次審查、F1 為 0.47–0.48；第三個封閉前沿資料點約為 $1.05、F1 ≈ 0.39；正式環境選用的是泛稱為「Frontier Model C」的模型，每次審查 $0.47、F1 0.50，並標記為「我們採用的配置」；兩個開放權重資料點則分別為 $0.28（F1 0.48）和 $0.06（F1 0.31，最便宜也最差）。這張圖以一個例子呈現本頁論點：正式環境選用的不是最便宜，也不是 F1 最高的方案，而是團隊從 Pareto 前沿上挑出的方案。來源將模型名稱泛化，因此能佐證 Pareto 導向選擇的形式，卻無法逐一對照上表中的模型名稱。

**本頁尚未定價的一項調節手段：讓哪個模型擔任 subagent，是設為預設值而非硬性規則。**Uber 指出，「subagent 預設值已證明是影響 tokens/request 最顯著的調節手段」——subagent 預設使用較弱、較便宜的模型（可手動覆寫），因為其任務明確，不需要前沿推理；主要模型則負責分解任務與評估結果。該來源沒有為此標上美元金額，但這是Parallel Agent Orchestration中「subagent 使用 Sonnet」建議的正式環境規模版本：它作為組織預設值執行，而非由個別實作者自行委派的提示（該頁新增的 Uber 四層分類見該頁）。

**Tokens/request，其餘的調節手段清單。**即使使用 1M-context 模型，也在 400K tokens 時自動壓縮；推理努力程度預設為 Medium（輸出／思考 tokens 的計價倍數高於輸入）；依閒置間隔分布選擇 prompt-cache TTL，而非採用固定預設值（完整說明見 Prompt-Cache Economics）；將 MCP 工具結構描述改為由 CLI 解析的呼叫和按需工具搜尋（預先載入 100 多個工具，每個工作階段約耗用 50–70K tokens 的結構描述，透過搜尋加 CLI 降至「接近零」）；以 code-mode 批次處理，在同一 Claude Code 工作階段中測試 5 個相同的 SQL 查詢——小型結果集只因移除輪詢／結構描述開銷，tokens 就減少 55–71%；寬廣的 50 列結果減少約 100%（1,431,594 → 900 tokens）；聲稱大量 N 輪工作流程改為單一腳本後可減少超過 90%；SaaS MCP 伺服器（某工作區套件的 49 個工具約耗用 22K tokens 的結構描述）也透過相同的 gateway 加 CLI 加 code-mode-skill 模式路由。

**Requests/turn：以內容脈絡為依據，降低搜尋成本。**AI Context Graph（2,400 萬個 nodes、8,000 萬條 edges、86 種 node types、117 種 edge types、30 多個來源系統）將一個資料表使用問題，從未以內容脈絡為依據的代理程式花 20 分鐘、使用 2 個 subagents、出現 3 個錯誤——最後還答錯——轉變為 38 秒內正確作答。這是一組配對案例，不是分布，但也是本來源各項調節手段中，單次前後差距最大的案例。

**可見性本身就是一種調節手段。**依 harness／使用者顯示即時成本計數器；設置共用 harness 支出池，並在預期支出達到 50/80/100% 時透過 Slack 提醒；session-analysis 儀表板則標示 16 類反模式（次佳模型路由、MCP 持續保存大型 payload 所造成的內容脈絡膨脹、快取到期後重建、提示初始化開銷），並為每個發現估算美元金額。這是將驗證成為新的瓶頸應用在支出而非品質上的作法：直接整合進執行階段，而不是等別人提出要求後才製作報告。

適度折扣看待。case-study、第一方、未經稽核——沒有任何消融分析能獨立出各項調節手段對 34%/52% 標題數字的美元貢獻；有幾項數字只是單一說明案例，而非分布（內容圖譜的 38 秒／20 分鐘配對案例、code-mode SQL 查詢表只在「同一個工作階段」跑過一次）；兩項標題百分比都以已經在發布前部分回升的最低點計算。

第五種單位：固定模型，比較 harness（Arena.ai，2026-09）#

HarnessTax以受控網格而非單一替換，測試 harness 作為成本調節手段的問題：7 個 models × 3 個 harnesses（Claude Code、Codex CLI、Pi）× 2 個基準測試，並對成本與成功率都計算 bootstrap 信賴區間。標題結果與上方 Writer 的 harness 替換相同，但差距更清楚：在 SWE-bench Lite 上，Claude Code 的幾何平均成本是 Pi 的 2.0 倍、Codex CLI 的 1.6 倍，成功率差距則維持在 ±2% 之內。Claude Fable 5 是最清楚的單一資料點——97.8%（Claude Code，$1.329）對上 96.7%（Pi，$0.666）——輪次相同（15.3 對 15.4），帳單卻是兩倍。來源追查到這個倍數差異來自首次模型呼叫：Claude Code 首次呼叫的平均內容脈絡約為 Pi 的 13.7 倍（27.0k 對 1,972 tokens），原因是 Claude Code 的工具結構描述有 23 個工具、77,000 個字元，而 Pi 只有 4 個工具、2,873 個字元。與本頁已引用的 Writer 和 Databricks 來源不同，HarnessTax 與它評分的三個 harnesses 都沒有供應商利益關係。

第六種單位：每個工作流程的成本，由銷售低價方案的供應商定價（TypeSafe，2026-09）#

TypeSafe AI 的 Jev 發表公告（2026-09-15，vendor-claim）為完整決策圖定價——四個以程式碼定義的工作流程，每個都是由模型讀取資料及手寫分支組成的鏈——並將準確率與每次工作流程執行成本繪在一起。其非 LLM 決策模型每個工作流程約 $0.0004，與雙 LLM 參考結果約有 68% 一致率；前沿模型的成本與一致率則依序為 GPT luna（約 $0.0035、約 67%）、terra（約 $0.03、約 68%）和 sol（約 $0.085、約 74%）；Opus 5 約 $0.18、約 73%（圖表數值，近似值）。有兩點與本頁論點相符。第一，這是「先用最強模型」預設值的反面：供應商主張，對於形狀類似決策的呼叫，夠用的最便宜模型能以低兩個數量級的成本勝出，而最後約 6 個百分點的一致率要花約 200 倍成本。第二，模型呼叫方式對成本的影響，與選擇哪個模型一樣大：固定工作流程中的每次 LLM 執行成本，約為讓相同 LLM 以 chain-of-thought 執行邏輯時的一半，而且與參考結果的一致率更高——這是編排比模型選單更影響經濟效益的結果，此處的來源並未銷售任何 harness。所有調節項目（工作流程、參考結果、呼叫 LLM 所用的 wrapper）都由供應商自行提供；折扣幅度請見型別化決策驗證器。

級聯模式：「預設用便宜模型，例外情況才用前沿模型」（LangChain，2026-09-25）。LangChain 的 Jev 整合文章（vendor-claim，整合合作夥伴）闡述了這個第六種單位所隱含的路由規則，並借用 Jaya Gupta 的「智慧大解綁」一詞：策略從「預設使用前沿模型，之後再最佳化」轉為**「預設用便宜模型，例外情況才用前沿模型」。唯一具體案例是一種以信心門檻控制的級聯——Browserbase 重新打造 Stagehand 的 act()，讓 Jev 選擇瀏覽器動作和頁面元素，信心度低於 0.7 的項目則交給 LLM；中位延遲從 1.97 s → 0.46 s（Browserbase 早期測試，二手資料）。這是 FrugalGPT 式的逐次呼叫路由，也是將代理程式工作結晶為工作流程所稱與其自身調節手段正交的作法，而且其預設策略與上述「先選最佳模型」規則相反**：便宜模型是預設值，前沿模型則負責處理例外。文章沒有公布的兩項資料，決定了它降低的究竟是每項任務成本，還是每次呼叫成本——fallback rate（信心度高於 0.7 的呼叫占比）與前後的任務成功率。如果便宜階段很有信心地答錯，就會直接送出錯誤，不會觸發升級而產生費用；這正是 Jev 共用看板上的 retry-gate 實驗測得的 precision 失敗（403 個路由項目中有 216 個原本就正確）。文章唯一回報的軸是延遲。

相關連結#

• Harness Tax：跨 harness 的程式設計代理程式成本倍增，成功率幾乎不變——上述第五種成本單位：將 harness 選擇與模型分開，在成本上相差 2.0 倍（SWE-bench Lite，Claude Code 對 Pi），差距可追溯至首次呼叫的內容脈絡相差約 13.7 倍

• 共用預算下的計算分配——經過定價的批次處理方式。在單一預算下，以一個請求同時處理多項任務來攤銷成本並非免費：N=20 個問題、採用共用預算時，七種推理模型的表現都比將相同 tokens 總量平均拆分更差，低了 5.0 分，因為模型依提示順序而非任務價值花費預算。這是分配失敗，不是 token 計帳問題，而且在小批次時結果反轉（N=5 時高 2.6 分）——因此「每次呼叫包含幾項任務」是有測得最佳值的 cost-per-task 參數，不是單純省錢

• GDPval Benchmark——說明上方模型選擇表中的 GDPval-AA 列以什麼為基礎，也說明該列隱含的模型分工來自哪些證據。2026-09-10 收錄的主要論文提供了數據：依交付檔案類型區分勝率，Claude Opus 4.1 在 pdf（45%）、xlsx（43%）、pptx（45%）及「其他」（48%）領先；GPT-5 high 則在純文字任務領先（23%，Claude 為 14%）——供應商建議採用的分工，有了測量結果。「依任務類型挑選模型」是基準測試本身的發現，之後才成為供應商建議。該來源也提供本頁一直缺乏明確形式的成本面結果：將專家審查成本納入流程，GPT-5 相較於未輔助專業人士原有的 474 倍成本優勢，會降為 1.63 倍；GPT-4o 則降至 0.53 倍——cost-per-task 不只是模型本身的特性，也取決於模型的勝率能否達到品質門檻，因為每次失敗嘗試都要付兩次成本

• AI Product Economics Maturation——從賣方損益表為計費單位問題定價：在約 305 位 AI 建置者中，42% 採用依用量定價、23% 採用成果定價，平均使用 1.7 個模型，對照上文記錄的買方需求（超過 50%）；以及超支項目排名（token 支出居首，單一工作流程每次執行成本從 $0.10 升至 $1.50 以上），呈現成果計價的賣方要承擔什麼

• 企業 AI 支出強度與人數成長——上方買方端章節所用支付管道資料的來源；該頁以同一份九月指數研究採用情形與每位員工支出，並記錄其修訂方式（美元序列在首次公布後數月內會向上修正）

• 將代理程式工作結晶為工作流程——將成本框架推至極限：對於已解決且會反覆出現的問題，每項任務成本會降到零，而非降到較便宜模型的價格，因為系統直接移除推論，而不是讓它更便宜（正式環境中確定性執行比例從 0 上升至 45%，八個月內每起事件成本減少超過 70%，但沒有受控反事實比較）

• 編排決定 Token 經濟效益——再上一層的調節手段，也是本頁從未變動的因素。固定模型，只替換編排層，六種模型中每項任務成本降低 41%、tokens 降低 38%，沒有例外，差距大於模型選單本身（36%）。這也是首個在 Anthropic 基礎架構上，同時公布各模型成本與品質的來源——而資料顯示，品質／美元的排序與「先用最強模型」預設值相反。對總體供應商利益衝突打折看待（33 位 Writer 作者以 Writer 的 harness 對照 Writer 自家的凍結前版本進行基準測試）。此頁現在也收錄了 Databricks 基準測試的 harness 部分，其模型部分見上文——三個已推出的第三方 harness 在真實程式碼庫上測試，最精簡的 harness 達到相同成功率，成本「少 2 倍」，每項任務的內容脈絡成本相差 3.13 倍；這是由不銷售任何受測 harness 的一方測得的相同調節手段

• Prompt-Cache 經濟效益——本頁一直說沒人公布、如今實際公布的 token 軸——由第三方提供，端對端預算為 $98.96，並與 Anthropic 發票核對至誤差 1% 以內。它也以有用的方式打破本頁框架：每個 token 的價格不是可直接乘上 token 數量的固定常數，而是快取狀態、前綴大小與呼叫次數的函數；這正是所有具成本意識的路由論文都視為固定值的項目。至少有一個測量案例反轉了 cost-per-task 論點——依查詢壓縮提示詞雖將 tokens 減少 3 倍，但與完全不壓縮相比，帳單反而增加 40.1%，因為失效前綴的 cache-write 成本高於讀取節省的費用

• Tool-Output Pruning——同一系統內兩個軸互相衝突，是本頁問題最清楚的呈現。在 SWE-Bench Verified 上，SWE-Pruner Pro 在一個 backbone 上達到最大的輸入 token 降幅（−13.5%），但在兩個 backbone 上，它的 API 呼叫數都是所有方法中最高（111.8 對 94.8；139.8 對 131.9）——修剪縮短了每次呼叫，卻拉長了整段執行路徑；作者明確拒絕將兩者合併成單一效率數值，因為不同 backbone 上兩者走向相反。同一張表也有反例：在 MiMo-V2-Flash 上，每種修剪器都增加每段執行路徑的輸入 tokens（+6.6% 至 +14.9%），卻也都提高了任務解決率；因此這項技術在品質上有價值，成本面則有所損失。兩種結果都無法用「價格乘以 tokens」模型表達

• Context Lifecycle Management——從內容脈絡面來看本頁所稱無人公布的成本軸：修剪 tokens 會破壞供應商前綴快取，因此 token 減少與帳單成本可能朝相反方向變動。Self-GC 以公式為 commit 定價（CommitBenefit ≈ N_future·(C−C′) − L_cache_break − L_GC），並提出 0.3 的預期修剪損益平衡點——這是本語料首個公開的「這項內容脈絡刪減值得破壞快取嗎？」門檻；另報告正式環境輸入 tokens 減少 10–15%，並明確拒絕將此稱為帳單成本節省

• 用戶端代理程式最佳化——經驗上的反證：依完整流程組合而非依工作負載評估模型選擇，其中最強模型可能是最糟的元件。Cursor 的四種組合是在正式環境建置上使用相同抽象，並補上成本面耦合：規劃器的帳單包含它導致工作者耗用的 tokens

• 平行代理程式編排——測量這些成本數據時所用的 harness，也說明比較為何可信：配對任務、配對模型、配對時間預算、保留集 oracle

• Cursor——公布數據的供應商，以及應從數據中扣除的利益衝突

• 最佳化器與評估器解耦——顧問策略是從成本面得出的同一項不變原則；顧問是獨立評分器，而且讓它負責評估，比讓它擔任執行器更便宜

• 以正式環境資料來源進行評估——基準測試飽和後，供應商自己的建議：從正式環境流量整理 eval

• Evals 即產品規格——當選擇框架面臨最難的兩個問題時，它會將判斷交給的對象

• 大規模測試時推論計算——努力程度是推論預算論點產品化後的調節器；若不指明預算，「模型有多強？」就是個定義不清的問題，選擇建議也承認這一點，將模型級別與努力程度視為同一張網格

• 測量超越準確率飽和——從研究角度說明 Opus 與 Fable 的問題：基準測試分數已無法區分模型，但其他可測量的軸仍能區分

• 無效的自我驗證——反轉 cost-per-task 論點的失敗模式：能力消耗在反覆思索，而非逐步收斂

• 推論效率即能力——供應端的對應案例：從模型建置者角度觀察同一種價格與能力的取捨；Gemini 3.5 Flash-Lite 的輸出價格增加 67%，在一項基準測試上的相對表現提高 78%，在另一項則只提高 2%

• 計算量受控的基準測試——從評估角度陳述相同問題：公布的價格是費率，而供應商都不公布能將費率轉換為帳單的每項任務 tokens 用量

• Claude Code Best Practices——每個工作階段如何套用這些建議（努力程度預設值、內容脈絡預算），也討論本頁便宜扇出反向趨勢所涉及的 sub-agent 開銷問題

• 共用 harness，差異化操作表面——從另一種方向做出相同選擇：OpenAI 將模型級別 × 努力程度收斂到一維滑桿，並將其餘選項隱藏在偏重特定觀點的預設值背後，而非公布選擇規則

• 隨模型進步而縮減 Harness——同一問題的第三種答案，也是唯一完全不是規則的答案：將選擇交給模型。以「自行判斷」取代硬性規則，是 Anthropic 在自家系統提示中採取的作法；如今有實作者將此方法用於模型路由——公開的決策程序、隱藏的供應商預設值、委派的判斷，是三種不同的選擇落點

• Anthropic——建議的發布者

• 開放權重作為競爭策略——將本頁算術擴大為國家層級論述：Ng 將智慧的價格視為投入成本，會逐層複合影響整個下游產業；因此，不論誰掌握前沿技術，建置者若多付 3 倍，就會輸掉應用層。上面的 Databricks 基準測試是 Vault 中最接近此論點的證據——品質相同時，開放權重模型最便宜——同時也是最清楚提醒我們不要太快接受此論點的理由，因為本頁的整體發現正是：比較這類模型時，每個 token 的價格是錯誤的分母

• Claude Fable 5、Claude Opus 5、Claude Sonnet 5、Mythos Model——供選擇的模型級別

• 動態工作流程：代理程式的代數——已公開的最大規模案例：約 $165k 的 tokens（59 億 uncached input、6.9 億 output、720 億 cached reads），對照明確的反事實估算——三個工程師年；團隊表示原本不會嘗試該任務——而依獨立稽核，該數字上限是「達到綠燈」的成本，而非「交付完成」的成本

• 驗證成為新的瓶頸——對應的計帳問題：容易定價的工作（達到綠燈）並非主導帳單的工作（交付完成）

• Agent-Authored Harness Optimization——將最佳化活動本身當作成本問題：花費約 $680 與約 1B tokens，讓一次基準測試執行的成本從 $79 降至 $49.8，卻沒有說明損益平衡門檻——這與 Bun 的數據有相同的「達到綠燈」與「交付完成」模糊地帶，但層級更高

• Knowledge-Centric Self-Improvement——一項完全以美元而非 tokens 計算的自我改進比較，理由正是本頁關注的問題（「讓數據反映快取和未快取 tokens 的實際成本，並能在快取狀況不同的方法之間保持可比較性」）；使用 meta-loop tokens 的基線方法也將其計入。結果呈現較罕見的樣貌：相較於每一組對照，解決率都提高且成本都降低（SWE-bench Pro $208，DGM 為 $713），因此 cost-per-task 在沒有任何準確率取捨爭議的情況下降低

• 標準化基礎架構，而非工具——進行此計帳的組織層級前提：Shopify 的中央 LLM proxy 讓每個請求都能由單一計費器追蹤；分開計費的工具群做不到這一點

• 用於代理程式程式碼審查的確定性工程——第三方 harness 案例，tokens、實際時間和品質同時朝相同方向變化，在不同任務領域重現 Writer 所得「harness 是更大的調節手段」結果。固定後端模型，只替換審查系統，Claude-4.6-Opus 的數據從 5,664K tokens / 13m06s / 11.57% SEM-F1 變為 385K / 1m23s / 25.10%——tokens 和時間分別減少 14.7 倍與 9.5 倍，品質則提高 2.17 倍；測量者沒有銷售受比較的任何基線。不過，換成另一項基線後，這個清楚的解讀就不成立了：對 Codex 而言，token 節省幾乎消失（422K 對 525K），因為 Codex 自己的迴圈已經會提早終止，所以部分節省其實來自該基線的探索行為，而非受限設計的一般特性——而且與本頁其他來源一樣，該論文以 tokens 和秒數為自己定價，完全沒有提美元

• Agent Quality Flywheel——與本頁抱怨相反的案例，也因此值得保留。以上每個來源都以 tokens 而非美元定價；Shopify 對 Sidekick 的描述則只以美元定價，完全沒有使用量單位——「依平均 token 成本推算，每年輕易可能要花 $27M」，而「實際金額接近 $1M：服務成本降低 96%」（case-study，第一方）。兩個數字都是反事實年度總額，估算模型由文章自行提出；全文沒有任何每次請求或每項任務的分母，而且產生節省效益的迴圈本身也有持續成本（每日全參數微調、前沿評論模型小組、重播執行、專家標註合約），兩邊帳目都未納入。因此，96% 的「成本降低」只是兩個模型化總額的比率——與 tokens 數一樣，無法用於購買決策，只是方向相反

• 互動／背景模型拆分——產品化後的語音拆分以不同單位計算兩部分帳單：互動模型按分鐘計算在場時間，背景模型按 token 計算工作量

• Live-Path Minimalism——說明按量計費的部分為何不能停頓

• Gemini 3.8 Live——當月第二個前沿語音模型發表，完全沒有公布價格，只由第三方按每小時輸入音訊估算成本

• Artificial Analysis——公布特定工作負載實測成本，而非費率的評估者

• 代理程式程式設計下，以建置取代採購——實作成本下降後被取代的採購項目，也是 token 帳單如今成為 IT 預算項目、而非實驗預算項目的原因：建置決策以 tokens 衡量

• Interactivity Benchmarks——語音成本圖表應與哪些品質看板對照閱讀，也說明為何每音訊小時的美元數分母並非任務

• 型別化決策驗證器——上文第六種單位：每次工作流程執行成本；非 LLM 決策模型以低於前沿 LLM 約 200 倍的成本，在 Pareto 前沿領先，但一致率少約 5–6 個百分點（供應商執行的 eval）

開放問題#

• 「智慧程度較高的模型，每項任務成本較低」這個說法，經過非 Anthropic 生產流量的測量後還成立嗎？這項主張沒有附上數據，已發表的曲線也明確標示為示意圖。仍待解答，出現一次擦身而過的例子（2026-07-30）： DeepMind 的 Gemini 3.5 Flash-Lite model card 展現了這種形狀，是非 Anthropic 的案例：輸出價格上漲 +67%，能力則提升到完整的代理式等級；但它沒有提供每項任務的 token 數，因此只能支持前提，無法提供測量結果。部分獲得解答（2026-08-03），而且結果分歧： Cursor 的四種模型組合提供了測量：採用非 Anthropic 基礎架構、實際四小時工作負載、相同時間預算、相同品質，並公布成本。在規劃者角色中，這項主張成立：Fable 5 規劃者的費用略低於 Opus 4.8，儘管每個 token 的價格約為兩倍，因為它產生的規劃 token 少得多。但在整體執行層面，主張則不成立：同一個 Fable 組態的總費用高出許多，因為它的工作者耗用了數倍 token；而所有執行中最貴的，是全程使用能力最強模型的那次（$10,565 對 $1,339）。因此，這個論點看來適用於某個角色，而非整個系統；目前也沒有來源在 Anthropic 以外的單一代理工作負載上測量過它。論點進一步聚焦，並出現首筆反向數據（2026-08-03）： Writer's harness swap 在非 Anthropic 基礎架構上，以同一份固定價格表公布六個模型各自的成本與品質；在該工作負載中，每項任務的成本隨模型強度單調上升，而每美元品質最低的是兩個最強模型（Palmyra X6 3.16、Sonnet 4.6 3.27），最高的則是最便宜的模型（Qwen 3.6 4.44）。這是受控基準測試，而非生產流量；各組品質也未達同等，因此仍無法定論——但結果方向與廠商建議相反，而論文自己的結論也認為，模型選單的影響力較小。迄今最接近答案，但結果再次分歧（2026-08-04）： Databricks 的內部程式碼基準測試——在其自有數百萬行程式碼庫上執行真實工程任務，測量者既非 Anthropic，也非模型廠商——顯示 Opus 4.8 每項任務 $1.94、成功率 87%，Sonnet 5 則為 $2.09、81%；前者使用的 token 約便宜 1.7 倍。因此，在 Anthropic 自家模型系列內，這項主張成立；在機制理應最顯著的長期程式碼工作情境中，這也是它首次在第三方的真實程式碼庫上成立。但放到更廣泛的模型選項中，主張則不成立：開放權重的 GLM 5.2 品質與 Opus 4.8 在統計上相當，每項任務只要 $1.28。因此，這條規則仍成立的形式關乎完成任務所需的 token 數，而非價格級別——較便宜的模型若耗用更多 token、完成率又較低，每項任務反而更貴；這是有條件的結果，並非結構性規律。問題仍未定論：資料來自 case-study 二手報導，使用的是源自生產環境的任務，而非生產流量；「統計上相當」也沒有提供樣本數、變異程度或各組方法。本文引用的一般化論點（arXiv 2603.23971——三分之一的比較結果方向相反；Gemini 3 Flash 標價便宜 80%，實際使用卻貴 38%）最有可能解決這個問題，但尚未納入資料庫。相關證據（2026-09-22），但不是答案： September 2026 Ramp AI Index: Cracks in the AI thesis, part 2 首次大規模呈現的是決策而非成本：五週內，前沿級模型的 token 占比從 52.5% 降至 44.7%；企業表示，已全面改用非前沿模型作為預設選項，因為標準模型「效能仍然很高，而且成本效益也更好」。它沒有測量任務、回合或完成情況，因此無法檢驗這項主張；但它確實顯示，在過去六個月整體有效價格下降 41% 的市場中，採購者正依循本項主張所反對的每 token 價格規則行事。
• 顧問策略的結果（以顧問價格的 63%，取得距離顧問分數不到 10% 的成績），能否適用於 SWE-bench Pro 和 Sonnet-5/Fable-5 配對以外的情境？顧問呼叫的成本又會在何種交叉點高於其節省的成本？
• 鑑於 AgentOpt 發現能力最強的模型反而是最差的規劃者，「從最強模型開始」這項策略用在多角色流程中安全嗎？Anthropic 關於為子代理選用 Sonnet 的說明暗示了某個界線，但從未明說。部分獲得解答（2026-08-03）： Cursor 的生產環境代理群表示，這條規則安全的形式取決於位置——能力最強的模型擔任規劃者，有能力完成任務的最便宜模型擔任工作者；而所有角色都使用最強模型，是以相同品質完成任務最昂貴的方法。這也消除了與 AgentOpt 看似矛盾之處：Opus 在 HotpotQA 中是最差的規劃者，因為它依賴參數化知識作答，而不是交派任務；Cursor 的架構則讓這種行為不可能發生（「規劃者絕不負責實作」）。問題出在允許規劃者執行任務的 harness，而非由強模型擔任規劃者。尚未解決的是：當工作者的任務需要大量判斷、而非遵循指令時，這種排序是否仍成立；Cursor 自己的論述也排除了這種情境。

資料來源#

• GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks — Patwardhan et al.（19 位作者，OpenAI），arXiv 2510.04374 v1，2025-10-05，29 頁（empirical）。本文引用 A.2.4 圖 12（依交付檔案副檔名分類的勝率，於編譯時檢視），以及 §3.2 與表 2（naive 相較於 try-1×/try-n× 的速度與成本比，於編譯時使用 pdftotext -layout 重新驗證）。請留意適用範圍：成本估算僅針對 OpenAI 模型。完整分析與利益衝突資訊見 GDPval Benchmark
• Claude models explained: choosing the best model for your use case — Anthropic，2026 年 7 月（vendor-claim）：先選合適模型的預設做法、模型類別、四個選擇問題、顧問策略、飽和 → 自訂評估
• Gemini 3.5 Flash-Lite Model Card — Google DeepMind，2026-07-21（vendor-claim）：基準測試表格中的價格列、效率級別模型跨一代輸出價格上漲 +67%，以及未提供可用來估算任務成本的 token 或回合數
• Codex from 0 to 10M Users: Building ChatGPT Work - Akshay Nathan, OpenAI — Latent Space，2026-07-28（practitioner-opinion）：OpenAI 相反的選項呈現理念——將「32 個選項」收斂為一道一維滑桿，背後採用立場明確的預設值，並設有相同的升級觸發條件，也同樣沒有每項任務的 token 數
• How is the Bun Rewrite in Rust Going? — Tom Lockwood，lockwood.dev，2026-07-27（case-study，獨立來源）：從外部檢視 Bun 移植工作的公開產出，並指出專案標題所列的 token 成本，未計入 CI、員工時間及合併後的後續成本
• The Harness Effect: How Orchestration Design Sets the Token Economics of Enterprise Agentic AI — Sayed Ali et al.（33 位作者，皆來自 Writer, Inc.），arXiv 2607.06906，2026-07-08（empirical，完全存在廠商利益衝突——Writer 的 harness、Writer 的基準、測試組中的 Writer 模型，末位作者是共同創辦人兼 CTO）：§6.2 與表 4 提供各模型基準至 harness 的成本數據，以及 36% 的模型選單影響與 33–61% 的 harness 影響比較；表 6 提供上方品質／美元欄位所用的各模型能力平均值；§7.1 提出「$/Mtok 比較的是 p；帳單則是 p × τ」的說法。原始解析中的表 2 儲存格錯誤合併，表 7 列位置偏移——本文都未引用；模型清單取自 §5.3 內文。完整分析與解析注意事項見 Orchestration Sets Token Economics
• The price is wrong: AI cost calculation has to consider task completion rates, not just token costs — Thomas Claburn，〈The price is wrong〉，The Register，2026-07-13（case-study，二手報導：新聞文章轉述 Databricks 的基準測試網誌文章及 Matei Zaharia 的社群貼文；資料庫未收錄 databricks.com 上的原始來源）。提供每項任務 $1.94 / $2.09 / $1.28 的數字、87% / 81% 的成功率、每 token 價格「約便宜 1.7 倍」、SWE-Bench 經過調校的動機，以及引用的 arXiv 2603.23971 結果。644 字，沒有表格。值得記住的擷取風險： WebFetch 悄悄漏掉 GLM 5.2 的數字和 Gemini 3 Flash 的例子；這兩項內容之所以仍在原始資料中，是因為內文後來根據 curl 取得的 HTML 重建——而這兩項最能支持反駁廠商建議的數據，正是差點消失的內容
• Fable's judgement — Simon Willison，〈Fable's judgement〉，2026-07-03（practitioner-opinion，460 字）：自行委派模型路由的提示詞、自動儲存記憶檔案中所述的理由（將實作交給較便宜的模型，在主要迴圈中處理判斷、審查與整合），以及未量化的結果。這項建議是 Jesse Vincent 二手轉述，而判斷重於規則的底層建議則是 Cat Wu 和 Thariq Shihipar 的二手轉述；完全沒有任何測量
• Agent swarms and the new model economics — Wilson Lin，cursor.com，2026-07-20（case-study，廠商撰寫）：〈Results across model mixes〉和〈Model economics〉涵蓋四種規劃者／工作者組合、品質相同時 $1,339–$10,565 的總成本範圍、工作者耗用至少 69% token 卻只占三分之一成本的拆分、工作者支出從 $9,373 降至 $411，以及 Fable 相較 Opus 的規劃者成本反轉。註腳 1 指出，單獨執行 Opus 4.8 和 Fable 5 的測試（成本圖中以斜線標示的長條）只經過非正式評分，因此不對其品質作任何主張
• Build more natural voice experiences with GPT‑Live‑1 in the API — OpenAI，2026-09-10（vendor-claim）：每分鐘 $0.05 的前端語音層，另行計費的後端——計價單位是每分鐘，而非每個 token。這是價目表，不是測量；完全沒有任何使用量或每項任務成本數據
• Introducing Gemini 3.8 Live and 3.8 Live Extended Thinking — Google，2026-09-15（vendor-claim）：Artificial Analysis 的每小時輸入音訊成本圖，數值是編譯期間根據標示數據的長條圖讀取。這是基準子集上的測得成本，不是價格；該文章本身沒有公布價格
• The state of AI in 2026: On the road to ROI — Dan Tinkoff、Lieven Van der Veken 與 Michael Chui，Tara Balakrishnan 協作，〈The state of AI in 2026: On the road to ROI〉（McKinsey / QuantumBlack，2026-08-25，empirical，自我回報；線上調查，97 個國家共 1,719 位受訪者，調查期間為 2026 年 5 月 4 日至 6 月 8 日，依 GDP 加權）。本文引用展覽 8（依產業分類，20% 受成本限制）、展覽 14（不同群體中 coding agent 受限制的比例為 18% 對 6%）、28% 的 ICT 預算數據，以及 Chui 對 tokenomics 的評論。此研究沒有測量任務、回合或完成情況，因此無法檢驗本文的任何主張。利益衝突： McKinsey 提供 AI 轉型顧問服務；調查資料由其自有受訪者小組自我回報
• September 2026 Ramp AI Index: Cracks in the AI thesis, part 2 — Ara Kharazian，〈September 2026 Ramp AI Index: Cracks in the AI thesis, part 2〉（Ramp，2026-09-09，empirical）：內文提供下降 41% 至每百萬 token $0.68、3 月峰值 $1.15，以及 45% 的前沿模型 token 占比；每週級別序列和各實驗室每日價格序列取自 Datawrapper 資料集（頁面上沒有靜態圖表圖片）。各實驗室的差異是本資料庫根據這些資料集計算所得，並非 Ramp 的主張；價格 CSV 快取的尾端資料比內文落後數日。利益衝突： Ramp 的測量對象是偏向創投企業的公司卡片用戶群；完整的工具說明見 Firm AI-Spend Intensity and Headcount Growth 和 Ramp
• Running a Software Factory Efficiently at Uber Scale — Uday Kiran Medisetty，Uber Engineering 網誌，2026-08-27（case-study，第一方來源）：包含六項成本公式、uReview Pareto 基準（圖 5，模型名稱經泛化，依文章圖片手動轉錄——WebFetch 無法讀取圖片）、子代理預設模型這項調整因素、每個請求 token 數量的調整項目清單（壓縮上限、預設推理努力程度、MCP 工具搜尋／CLI 解析、code-mode 的五項查詢 token 表、SaaS MCP 路由）、AI Context Graph 的脈絡對應範例，以及支出可視化工具。資料不是從 PDF 取得，沒有 docling 表格解析風險；圖片取自網頁中以 base64 編碼的 img src 屬性，並直接檢視。各來源的完整註記見「來源」
• HarnessTax: How Much Does the Harness Matter for Coding Agents? — Pan、Yang、Arabzadeh、Chiang、Stoica 與 Zaharia，Arena.ai 網誌，2026-09-16/18（empirical）：SWE-bench Lite 的 21 種組合成本／成功率矩陣，以及圖 3 的首次呼叫脈絡表。完整分析（包括 Terminal-Bench 2.0 的擷取注意事項）見 Harness Tax: Coding-Agent Cost Multiplies Across Harnesses While Success Barely Moves
• Introducing System One Models & Jev — Diogo Almeida，TypeSafe AI，2026-09-15（vendor-claim）：工作流程評估的準確度與成本圖表（fig1；從圖片讀取的對數刻度數值，為約略值）。完整分析見 Typed Decision Verifiers
• Building Prod with Jev and LangGraph — Sydney Runkle 與 Hunter Lovell，LangChain 網誌，2026-09-25（vendor-claim，Jev 整合夥伴）：以 Jaya Gupta 的說法為基礎提出「預設使用便宜模型，例外時再升級至前沿模型」的做法，以及 Browserbase 的 Stagehand act() 級聯流程——信心度 0.7 時轉用備援模型，中位數耗時從 1.97 秒降至 0.46 秒；這些數據為二手轉述，沒有提供備援率或任務成功率