方法論

開發方案相關頁面上的數字是怎麼來的,以及每個數字允許聲稱到什麼程度。

可信度分級

每條額度都帶一個等級。它說的是我們證據的強度,不是數字的大小。

official
廠商定價頁或文件寫明。必須有來源連結和廠商原話。
measured
我們或社群實測。必須有可查出處,並寫清測法。
estimated
由其他已知量推算。必須把推算依據寫下來。

派生指標取輸入裡最弱的一檔。本比較頁只出現 official 和 measured;estimated 只出現在規劃器裡,那裡你能看見並改動假設。

廠商公開到什麼程度

這跟可信度是兩碼事,但經常被混為一談。Anthropic 那句「比 Pro 多 5 倍用量」是 official 級證據——廠商自己的話——而它描述的額度依然不是一個數字。

published
給了絕對數字,或明確寫了「不限量」。
relative
只給了相對另一檔的倍數,而那一檔自己的額度可能也沒公開。
undisclosed
什麼數字都沒有。

未公開不是我們沒查到。不承諾數字,正是廠商日後收緊額度卻無需公告、也不算違背承諾的前提,所以我們把它標成一條風險提示,而不是一個空格。

能力檔

檔位只是給廠商公布過可比分數的模型貼的標籤,出現在模型 chip 上,別處不用。檔是粗篩,不是打分,檔內也不排序,站內沒有任何一處按檔篩選或排序。

有廠商公布的 Terminal-bench 2.1 分數就按分數劃:80 及以上為 frontier,70 到 79.9 為 strong,低於 70 為 efficient。沒有分數但廠商對自家模型給出了明確排序的,按那句話定檔並原樣記錄。兩者都沒有的,留空不劃。

未劃檔不等於弱,只是沒人公布過可比的數字。它曾經的代價是過不了能力下限——那個下限已經撤掉了,因為被它擋住的絕大多數不是能力不夠的模型,而是不公布基準分的廠商。現在價值數字改為標明它是按哪個模型算出來的。

兩樣東西我們刻意不用:跨版本的基準分數,它能僅憑版本差異就把一個模型挪一整檔;以及經銷商的計費分檔,它跟價格貼得太緊,拿它劃檔再按「價值除以價格」排名就成了循環論證。

目前覆蓋:19 個 base model 中有 9 個已劃檔。

ModelVendorTierEvidence
Claude Fable 5AnthropicfrontierNo Terminal-bench score published; Anthropic reports benchmarks as chart images. Tiered on Anthropic's own ordering: the Claude Opus 5 launch post (2026-07-24) describes Opus 5 as coming "close to the frontier intelligence of Claude Fable 5 at half the price", placing Fable 5 at the vendor's capability ceiling. https://www.anthropic.com/news/claude-opus-5
Claude Haiku 4.5Anthropic未劃檔
Claude Opus 4.6Anthropic未劃檔
Claude Opus 4.8Anthropic未劃檔
Claude Opus 5AnthropicfrontierNo Terminal-bench score published. Tiered on Anthropic's own claim in the launch post (2026-07-24): "on Frontier-Bench v0.1, Opus 5 surpasses all other models, and more than doubles Opus 4.8's performance at a lower cost per task", and "It's the new default model on Claude Max, and the strongest model on Claude Pro." https://www.anthropic.com/news/claude-opus-5
Claude Sonnet 4.6Anthropic未劃檔
Claude Sonnet 5AnthropicfrontierTerminal-bench 2.1 (Terminus-2 harness) 80.4%, as reported by Google in the Gemini Flash model table, retrieved 2026-07-27. At or above the 80.0 frontier threshold. https://deepmind.google/models/gemini/flash/
Composer 2.5Cursor未劃檔
Gemini 3.1 ProGooglestrongTerminal-bench 2.1 (Terminus-2 harness) 73.8%, published by Google in its own Gemini Flash model table, retrieved 2026-07-27. The same model scores 68.5% on Terminal-Bench 2.0 in Google's Gemini 3.1 Pro table — the two versions are three points apart on one model, which is why they are not mixed. https://deepmind.google/models/gemini/flash/
Gemini 3.5 FlashGooglestrongTerminal-bench 2.1 (Terminus-2 harness) 76.2%, published by Google in its own Gemini Flash model table, retrieved 2026-07-27. https://deepmind.google/models/gemini/flash/
Gemini 3.6 FlashGooglestrongTerminal-bench 2.1 (Terminus-2 harness) 78.0%, published by Google in its own Gemini Flash model table, retrieved 2026-07-27. Within the 70.0-79.9 strong band. https://deepmind.google/models/gemini/flash/
Gemini 3 FlashGoogle未劃檔
GPT-5.3 CodexOpenAI未劃檔
GPT-5.5OpenAIfrontierTerminal-bench 2.1 83.4%, as reported by Anthropic in the Claude Opus 4.8 launch post's footnotes, retrieved 2026-07-27. Harness caveat recorded because it matters: the figure is OpenAI's self-reported score using the Codex CLI harness, not the Terminus-2 harness the other tiered figures use, so it is not strictly comparable with them. https://www.anthropic.com/news/claude-opus-4-8
GPT-5.6 LunaOpenAIfrontierTerminal-bench 2.1 (Terminus-2 harness) 84.7%, as reported by Google in the Gemini Flash model table, retrieved 2026-07-27 — the highest figure in that table. Note the tension worth keeping visible: OpenAI positions Luna as the lightweight, high-volume member of the GPT-5.6 family, while the benchmark places it above both flagships that have scores. https://deepmind.google/models/gemini/flash/
GPT-5.6 SolOpenAI未劃檔
GPT-5.6 TerraOpenAI未劃檔
Grok 4.5xAIfrontierTerminal-bench 2.1 (Terminus-2 harness) 83.3%, as reported by Google in the Gemini Flash model table, retrieved 2026-07-27. xAI's own docs publish no benchmark figures. https://deepmind.google/models/gemini/flash/
Grok Build 0.1xAI未劃檔

假設參數

把額度折算成金額,需要一個「編碼工作階段怎麼消耗 token」的模型。這些是編輯假設而非實測,在規劃器裡可以調。

參數取值依據
單輪輸入 tokeninputTokensPerTurn12,000Agent 編碼單輪平均脈絡,含檔案讀取
快取命中率cacheHitRatio0.7長工作階段下典型的 prompt cache 命中率
單輪輸出 tokenoutputTokensPerTurn1,500單輪平均生成量
每小時輪次turnsPerHour20活躍編碼時的互動頻率
每日小時數hoursPerDay6全職開發者每日實際編碼時長
每月天數daysPerMonth22工作日

價值數字是怎麼算出來的

一個方案的 API 等效價值,來自一條額度、按一個模型折算。三步決定是哪一條、哪一個。

  1. 1對同一個模型,各行是約束。一條整體額度和一條點名該模型的行不是二選一,後者是把前者收窄,所以這個模型的上限取兩者中更緊的那個。
  2. 2跨模型,各行是備選。共用一個五小時視窗的幾個模型,視窗花在你挑中的那個上,所以這一組值最好的那個選擇。勝出的模型就是這個數字的計價模型。
  3. 3跨組,各行同時生效。五小時視窗和週上限你都會撞上,所以方案值其中最緊的一條。

價值倍數 = 這個數字 ÷ 月費。大於 1.00 表示按公開 API 單價算,這份額度值的錢超過訂閱費本身。

計價模型標在數字旁邊,必須和倍數一起看。跨模型取最優意味著一個方案可以靠最便宜模型的一個大額度撐起整個倍數——數字沒算錯,但它描述的可能是你根本不會用的模型。標出模型是這裡唯一的防線。我們不按能力篩掉模型:那需要的基準分覆蓋率這份目錄並不具備,下一節寫明了缺到什麼程度。

四種情況我們不給數字,而不是給一個軟化過的數字:需聯絡業務的方案;鏈路上任何一處有已公布卻折算不出美元的額度;免費方案,沒有可作除數的價格;公布的額度沒有對應到我們列出的任何模型。

哪個模型做哪類工作

成本試算頁把每一類工作路由到一個模型。這是全站可信度最弱的一層,下面的覆蓋率應當先讀。

覆蓋情況

品類基準有分數的模型
架構設計無公開基準0
疑難除錯DeepSWE v1.16
後端實作SWE-Bench Pro (Public)7
前端 UI無公開基準0
重構與測試無公開基準0
DevOps 與指令稿Terminal-bench 2.1 (Terminus-2)6

有基準的品類,檔位按同一品類內已公布最高分的相對位置劃定:達到 92% 以上判 preferred,70% 以上判 capable,低於則判 unfit。用相對值而非絕對值,是因為這些基準難度並不相同——有的滿場最高約 85%,有的只有 65%,固定門檻會僅因試題難度就把同一個模型劃到不同檔。

沒有基準覆蓋的品類,模型從能力檔繼承 capable,且不帶解決率。它仍可被路由,但永遠不會在一場它從未被測量過的成本比較中勝出,頁面會把那一列標為「按檔位」選出。

三類證據,按強度排列:廠商在自家比較表中公布的基準;第三方排行榜反映的聚合行為,因需逐個核對再散布授權,目前尚未啟用;以及本站讀者回饋,它只能產生一條待審改動,本身不會改動任何資料。

架構設計沒有成熟的公開基準,也不預期會有,因此這一品類只給出應當尋找的能力檔,不點名模型。

從 token 單價到每任務成本

更強的模型每 token 更貴、需要的嘗試更少,所以「每 token 更貴」和「每任務更便宜」在同一個模型上經常同時成立。試算比較的是完成一個任務的期望成本:品類基線 token 數按模型調整後,除以它的解決率。

各品類單任務基線 token

架構設計120,000
疑難除錯180,000
後端實作90,000
前端 UI70,000
重構與測試45,000
DevOps 與指令稿35,000

所有結果都是區間,由 token 消耗 ±30%、解決率 ±10 個百分點傳播得到。用一個編輯部基線乘以一個基準解決率再算出的單點數字,會是全站看起來最確定、實際最站不住的數。

回饋門檻

對某個品類該用哪個模型的異議,需累計 5 條同向、且佔該(模型,品類)全部投票的 70% 以上,才產生一條待審改動。改動交人工,對照公開基準核定;回饋本身永遠不改資料庫。

撞上限的回報按方案、週期、使用強度分組,絕不跨強度合併——重度使用者天然集中在更大的方案上,合併會得出「越貴的方案越容易撞上限」這種由購買族群造成的假象。單一格累計滿 20 筆才顯示比率,不足則如實標註樣本不足。

數字怎麼保持新鮮

監測每 3 天重讀一次各家頁面,把讀到的和庫裡的比對。它發現的任何改動,都要有人核對原文確認之後才會上線。廠商頁面讀不動了,這件事會顯示在方案上,而不是被悄悄吸收掉。

最近核實: 2026-07-29

全部開發方案