clikae Docs

艦隊作業流程:成本量測與派工規範

2026-09-17 · KITT(CVER Inc.)· 量測對象:reefbox 四個 tank(blenny/goby/tuna/wrasse)近 7 天全部對話紀錄,60,234 次模型呼叫,按 API 定價換算。

一句結論

訂閱不換、API 不開、Team 不買。錢不是燒在「想太多」,是燒在上下文太長 × 呼叫太多:76% 的成本是快取讀取。要省,就是讓每一層的上下文短、壽命短。省是目標,不是硬限制——下面所有數字都是目標值,不是閘門。

量到的數字

項目 數字
7 天總額(API 價) 約 $6,500,換成月費約 $28K;四個 Max 20x 實付 $800
成本組成 快取讀取 76%/快取寫入+新輸入 18%/輸出(含思考)6%
Fable 5.1 指揮艇 2,269 次、平均上下文 504K、每次 $0.21、合計 $467(7%)
Opus 座艙自己幹活 13,368 次、平均 208K、$1,986(最大一條)
Sonnet subagent 22,147 次、平均 313K、$1,834(第二大)
Haiku 23 次,等於沒用
subagent 壽命 206 支:中位數 96 步、p90 286 步;≤20 步的只有 2 支。最貴的六支全是 Sonnet,1,500~1,770 步、上下文衝到 950K
主 session 179 個:中位數 106 步;最大的到 960K 上下文

單價(每百萬 token,輸入/輸出/快取讀):Fable 5.1 $10/$50/$0.25;Opus 5 $5/$25/$0.50;Sonnet 5 $2/$10/$0.20;Haiku 4.5 $1/$5/$0.10。Fable 5.1 的快取讀取比 Opus 便宜一半,這是它適合坐指揮艇的原因。

成本模型

成本 ≈ Σ(每次呼叫的上下文 × 該模型快取讀取單價)+ 少量輸出

推論:

  • 一個 300K 上下文的 Sonnet agent 跑 300 步,比一個 100K 的 Opus agent 跑 30 步貴十倍。「便宜模型」不等於便宜,壽命才是變數。
  • effort 直接花費很小(輸出只佔 6%),它的代價是讓任務多跑幾輪。降 effort 排最後。
  • 換模型=全部重讀(每個模型各自一份快取)。中途 /model 是一次性大額支出。
  • 訂閱方案的主對話快取存活 1 小時(API 只有 5 分鐘),這是訂閱獨有的紅利,指揮艇受益最大。subagent 不論哪種方案都是 5 分鐘。

三層流程

1. 指揮艇(每人一艘,長命,Fable 5.1)

  • 只持有意圖、決策、紅線、進度;不自己讀檔、grep、跑測試——那些是 300K 上下文的來源。
  • effort 預設 low(2026-09-17 起的實驗,下週用尺驗)。座艙改不了自己的 effort——那是使用者旋鈕(/effort),模型端也觀測不到目前值。所以需要深思的回合不是「拉高」而是派出去:紅隊、綜合多份回報、架構裁決、要送出去的東西,開 Opus/high 或 Fable/high 的工人去想,座艙只收結論。
  • 派高 effort 的觸發綁在動作類型上(改共用管線、動錢/憑證/身分、對外發言、任何要 merge 的東西),不綁在「感覺難不難」——low 最會漏的正是看起來像小事的難題,而且答得很有自信。
  • 人要親自聽座艙判斷時自己撥 /effort:Fable 5.1 在訂閱下中途改 effort 不打掉快取(其他模型會全部重讀),撥了記得撥回來。
  • 任務邊界 /compact;不要等自動壓縮在任務中間觸發。廢掉的分支用 /rewind(回到已快取的前綴)不用 /compact。
  • 冷 session 重開用「從摘要恢復」,不要整段重送。

2. 工人(短命,單一產出)

  • 一份簡報一個產出。目標:40 步以內、150K 上下文以內;估起來會明顯超過就先拆,或改用 Workflow pipeline 串接。現在中位數 96 步是簡報寫得太大,不是模型太笨。這是目標不是閘門——工人快做完時別為了數字硬停。
  • 不等人:subagent 快取只活 5 分鐘,任何「等使用者回答」的設計都會讓下一步全額重讀。需要人裁決的點放回指揮艇。
  • 回報格式寫進簡報(例:≤15 行、只給結論與收據、不貼檔案內容),否則工人的輸出會變成指揮艇的上下文。
  • 模型與 effort 一律明寫,不寫就整隊繼承指揮艇的設定(實測:38 支 agent 全 Opus+xhigh,一輪燒爆額度)。
任務類型 模型 effort
機械勘查、找檔、格式轉換、普查 Haiku 4.5 low
已知範圍內的實作、修測試、寫文件 Sonnet 5 medium
跨模組設計、綜合多份報告、紅隊審查 Opus 5 high
需要長程判斷的單一難題 Fable 5.1 high/xhigh

3. Tank(clikae 多帳號)

  • 用途是隔離與並行(不同帳號、不同工作樹),不是預設的扇出手段。扇出走 Workflow > 背景 Agent > tank。
  • 每個 tank 的座艙同樣適用第 1 層規則:座艙自己用 Opus 幹活,就是本週最大的一條支出。

派工簡報範本

模型:sonnet   effort:medium
產出:<一個具體的東西>
範圍:<檔案/目錄清單>,不碰其他
完成定義:<可驗證的條件>
預期規模:約 40 步;明顯超過就回報進度與「需要拆」,不硬撐
回報:≤15 行,結論+收據(指令與輸出摘要),不貼原始檔

量到的禁忌

  1. 座艙自己讀檔、grep、跑測試(Opus 主 session $1,986)。
  2. 工人跑成 session(Sonnet agent 1,700 步、950K)。
  3. 派工不寫模型(整隊繼承)。
  4. 中途 /model(全額重讀)。
  5. 非 Fable 中途改 effort(全額重讀)。
  6. 讓工人等人回答(5 分鐘後快取消失)。
  7. 冷 session 整段 --resume(無快取可讀,全部重算)。
  8. 多支工人共用同一個建置輸出目錄或測試套件(互相洗掉對方的活)。

訂閱 vs API vs Team

  • API:同樣用量換算約 $28K/月,訂閱 $800。「API 有快取所以便宜」那個說法弄反了,訂閱下 Claude Code 一樣走快取,而且主對話還多拿 1 小時 TTL。
  • Team:額度是 Pro 的小倍數,跑這種用量半天就鎖。
  • 唯一該考慮 API 的情況:非互動的批次工作(Batch API 半價、沒有週額度),例如夜間跑全 repo 的稽核。互動座艙留在訂閱。

監看指標與尺

  • /usage 的 Prompt cache (main):命中率、miss 次數、最近一次 miss 的原因。
  • 狀態列 current_usage.cache_read_input_tokens vs cache_creation_input_tokens:write 連續偏高=前綴在變。
  • 每週重跑 tools/tank-cost.py、tools/tank-agents.py(讀 ~/.clikae/profiles/claude/*/projects/**/*.jsonl),看三個數:快取讀取佔比、subagent 中位步數、座艙自己幹活的呼叫數。目標:subagent 中位數從 96 往 40 走。

未驗證

  • 訂閱額度怎麼計,官方沒公布(查過 help center 三篇:只寫「Opus 每回合比 Sonnet 貴數倍」「每回合重送全部歷史」)。本文用 API 價當代理。若訂閱把快取讀取算全價,「Fable 便宜」不成立,但「上下文短、工人短命」兩種算法下都對。
  • Mac 那邊的 session 沒算進來,實際用量比上表高。
  • 40 步這個目標是從分布反推的,沒有實測「40 步夠不夠做完一個典型任務」;太緊會逼工人半途回報、指揮艇多派一輪。先當目標觀察一週再定。