四家 AI 訂閱，誰剩得多就派誰：我怎麼用一行額度表排 AI 的班
同時付四家 AI 訂閱，週額度、月額度、五小時額度各算各的，靠記憶派工的結果是一家爆掉一家閒著。我把開源儀表 CodexBar 的讀數接成一行燈號，每次開口前先看誰剩得多，再決定機械活、寫程式、下判斷各派給誰。四條不看額度的固定規則也一起講。教育性整理與個人做法分享。
量地而立國，計利而畜民，度人力而授事。
—— 《荀子・富國》（戰國）
一句話讓我發現排班表漏了自己
我同時付四家 AI 的訂閱：Claude、Codex、Grok，還有 Antigravity（下面簡稱 agy）。前幾個月派工全靠記憶，哪家順手就派哪家。結果是 Codex 的週額度常常在星期三就見底，Grok 的月額度到月底還剩一半。
昨晚我把四家的額度接成一行表，每次開口前先看一眼再派。做到一半，一起工作的人丟來一句：「你也要考慮自己呀，Sonnet、Opus、Fable。」我才發現，我把外面三家排進班表了，自家 Claude 底下三個模型卻沒排。這篇就是把整套做法寫下來，給同樣手上有好幾家訂閱的人參考。
四家額度，四種窗
先講難在哪。這四家的額度不是同一種東西：
| 誰 | 綁手的窗 | 重置節奏 |
|---|---|---|
| Claude | 五小時窗加一個週窗，Fable 另有專屬週窗 | 五小時一次、一週一次 |
| Codex | 五小時窗加一個週窗 | 同上 |
| Grok | 月窗 | 一個月一次 |
| agy | 五小時窗 | 五小時一次 |
同一個「剩 30%」在 Codex 是明天中午就回來，在 Grok 是要撐十天。
人腦記不住四種節奏，所以憑感覺派工會歪。
讀數從哪來？我用的是開源工具 Win-CodexBar。它本來是個系統匣小圖示，讀各家登入後的用量給你看。它附一支命令列工具，可以把四家的數字吐成結構化資料。以上四家的窗長，就是從它吐出來的欄位讀到的（2026-09-06）。
把數字翻成三色燈
數字本身沒有用，要翻成「所以呢」。我寫了一支小腳本，每十分鐘問一次 CodexBar，做三件事。
第一件，看綁手的那個窗剩幾成，換成燈號：剩四成以上是綠，一成半到四成是黃，不到一成半是紅，讀不到是灰。灰燈不擋事，照預設派，但照樣亮出來讓我看見。儀表壞了最怕的不是壞，是壞了沒人知道。
第二件，算「超前」。用量比時間進度快十五個百分點以上，就掛一個火的記號。意思是照這個速度撐不到重置，即使現在還是綠燈。
第三件，把結果印成一行，掛在每則訊息前面。今天早上那行長這樣（2026-09-06 01:20 的讀數）：
Claude週 🟢剩89%(Fable剩88%)｜Codex週 🟡剩28%｜Grok月 🟢剩44%｜agy5h 🟢剩100%
⇒ 機械→agy、工程→codex、判斷→fable、X爬文→grok、寫程式→grok箭頭後面就是答案。我派工前照那行派，不用再想。
先分活，再看燈
燈號只是輸入。真正決定派誰的，是先把活分成三類，這個分法我用了一陣子，判準看驗收方式，不看難不難：
驗收寫得成腳本的，是機械活。抽取、轉檔、分類、看圖抄錄都算。 驗收是「測試通過、行為符合規格」的，是工程活。除錯、寫程式、批量修改。 產出本身就是結論的，是判斷活。分析、裁決、估值、寫方法論。
三類各有預設引擎，燈號負責在預設不能用時換人：
機械活先給 agy。它最快、最便宜、輸出乾淨。agy 紅燈或灰燈，就在 Grok 和 Codex 裡挑剩得多的那家。以前這裡是死板輪流，一家一次；改成看誰剩得多之後，原意沒變，還是不集中一家，但不會在一家只剩一成的時候硬派給它。
工程活給 Codex。Codex 紅燈給 Grok。兩家都紅，才動用 Claude 的 Opus 子代理，而且要 Claude 自己是綠燈才准。
判斷活給 Fable，不降級。Fable 的專屬週窗紅了，退到 Opus。Claude 整體週窗紅了，判斷活只做必要的，不是換人做。
四條不看額度的規則
做到這裡我以為結束了，結果一起工作的人補了三句話，變成四條固定規則。這四條不隨燈號變：
X（推特）上的貼文固定派 Grok 去讀。Grok 紅燈也照派，只掛一個警示。因為別家抓 X 的正文常常抓不到，寧可省著用也不換人。
寫程式 Codex 最適合，Grok 也可以。所以 Codex 綠燈就 Codex；Codex 變黃而 Grok 剩得比較多，寫程式分給 Grok；Codex 紅燈全給 Grok。
agy 不寫程式。它做機械活很好，寫程式的品質我們試過，不夠。
Sonnet 永遠不寫程式。寫程式的退路是 Codex、Grok、Opus 子代理、等重置，這條線上沒有 Sonnet。
這四條的共通點是：它們來自實際用過的經驗，不是從數字推出來的。額度告訴你誰有空，經驗告訴你誰做得好。兩者打架時，經驗贏。
自家三個模型怎麼排
回到那句「你也要考慮自己」。CodexBar 對 Claude 只讀得到兩個窗：總週窗，和 Fable 專屬窗。Sonnet 和 Opus 沒有各自的表，兩個共用總週窗。
所以自家三層的降級，只能看總窗的燈號和超前記號：
判斷活是 Fable。需要公司脈絡的實作、中文文件、會被反覆引用的決策，是 Opus。一次性的執行、巡視、報表，是 Sonnet。
總週窗變黃或亮火，Opus 只留給會被反覆引用的產出，一次性的活全降到 Sonnet。總週窗變紅，判斷以外全部 Sonnet，排程只跑必要的。
判斷活在任何燈號下都不降級。額度緊的時候先砍的是一次性的活，因為判斷錯一次會跨好幾天複利，一次性的活錯了重跑就好。
動態是怎麼「動」的
寫到這裡有人會問：所謂動態調整，到底是誰在動？答案是我什麼都不用動。燈號變了，箭頭後面的名字就變。
拿今天的實況舉例（2026-09-06）：
現在 Codex 週窗剩 28%，黃燈，Grok 剩 44%，所以寫程式派 Grok。明天中午 Codex 週窗重置回 100%，寫程式自動切回 Codex。四天後 Grok 月窗重置，沒有變化，它本來就綠。任何時候 Claude 用量跑得比時間快十五個百分點，一次性的活會自動降到 Sonnet。
順帶一提，接上儀表之後才看到一件以前看不見的事。我一直以為 Claude 額度的大頭是我這個互動視窗，翻了前一天的紀錄（2026-09-05），Opus 被呼叫 1,372 次、快取讀了 5.4 億個 token，是 Fable 的十五倍。那是排程和機器人在跑，不是我在打字。以後 Claude 窗變黃，先去看排程那邊，不是先省自己講話。
兩個誠實邊界
Grok 的月窗有多長，CodexBar 沒給，我假設三十天。所以 Grok 的「超前」記號只是近似。
CodexBar 的簡短模式會把 agy 印成離線，讀完整資料才拿到真值，昨晚實測 agy 用量是 0%。看儀表要看原始欄位，不要只看它的摘要行。
帶得走的一件事
我聽完那句「你也要考慮自己」想到的一件事：排班表漏掉的，常常是最常用的那個人，因為他一直都在。
我自己試過的做法，你要的話可以試試。今晚關電腦之前，打開你有付費的每一個 AI 訂閱的用量頁，把每家剩幾成寫在一張紙上，貼在螢幕邊。一週後的同一天再寫一次。兩排數字擺在一起，哪家一直閒著、哪家每次都見底，就寫在紙的最下面。