11 月 9 日上午，我打開 Muse 的用量儀表，額外 token 還剩 999M，屏幕上寫着已用 75%。已用 75% 就是還剩 25%，我拿 999M 除以 25%，整個池子反推出來約 4,000M，也就是約 40 億。
標題裏的 300 億，是邀請獎勵的封頂數。muse 給每個用戶一個邀請碼，別人註冊時填了這個碼，填一個，我這邊就多 10 億 token。這個碼最多能用 30 次，30 次全部用滿，才湊得出 300 億。我實際到手的，就是上面這約 40 億，已經燒得差不多了。
這組讀數是 Muse 自家儀表對額度的報告，它不是一張官方賬單，所以我下面講的燒速和餘量，用的都是這個儀表口徑。這個池子掉得很快。10 日早上還剩 875M，晚上剩 793M；11 日下午剩 704M，到了 12 日中午只剩 642M。三天燒掉 357M。那三天裏，我的周額度已經用滿了。周額度是我每週重置的那份額度，和額外池子分開記，它用滿之後，新增的開銷就記到額外池子上。
我每天讓 muse 做什麼
稿子是一攤。每天早上，muse 先選素材，選好之後我寫初稿。初稿交回來，它做潤色和審查，再配上圖。辦完這些，發到博客、X、小紅書和 dev.to。運營 X 賬號是一攤，我這邊叫它 X 巡邏。它全天抓時間線給人回帖，一天要回幾十條，點贊和關注也在同一套流程裏做。
定時任務是一攤，就是話題摘要、回覆自查和 GitHub 熱門日掃這幾件按點跑的事。剩下的是臨時任務，都是我臨時想起纔派的。查問題、寫代碼和做項目，全在這一攤裏。
每一攤每天燒多少
這幾攤事全天不停地跑，我拆過兩本賬。一本是儀表口徑，就是池子實際扣的數，10 日全天平均每小時約 5.8M，一天約 1.4 億。另一本是內部按 agent 記的原始量，大約是儀表量的 5 到 7 倍，因爲內部記的是上下文一遍遍重播的量。下面按項拆每天的賬，用的是儀表口徑。這些數是按統計時段的佔比折算的量級，對不到賬單精度，但大小關係錯不了。講機制時，我會換回原始量，兩個數各講各的事，不混着算。
最貴的一攤是 X 巡邏。最貴的那幾天，它佔了全賬號原始量的約一半，拿這個佔比去折全天約 1.4 億的儀表量，一天約 7,000 萬。負責寫回復的那個 agent，我這邊叫它消費者，它每小時上一班。最貴的一班，它一次派出去 125 個瀏覽器子任務，英文 65 個、中文 60 個。這些子任務做的事，全是把一條寫好的回覆發出去。這一班的原始量是 144.9M。
它貴就貴在開工費上。每個新 agent 開工之前，先要背約 8.8 萬 token 的常規上下文，這筆起步成本我叫它開工費。這筆上下文的大頭是兩塊，約 5.5 萬是產品固定的部分，約 2.7 萬是我自己的常駐檔案。每發一條回覆就開一個完整的瀏覽器 agent，開工費就扣一份，125 份疊起來，光開工費就是約 1,100 萬原始量。
11 月 10 日早上 8 個小時，稿子這一攤就分到約 31M，佔了那 8 個小時全賬號儀表量的一半。大頭在一條改稿的長聊天上。那條聊天連着跑了幾天，選材、潤色和審稿全在裏面辦。到了 10 日早上，這條聊天加上它派出去的子任務，整棵算下來佔了全賬號原始量的約四成。它的原始量是 124.7M，子任務一共 63 個。幾篇文章來回改和審，光原始量就燒掉一億多 token。
它貴的原因是歷史太厚。這條聊天每往前走一步，都要把前面幾天的記錄重讀一遍。它派出去的子任務，每個開工時又要把這段歷史再背一遍。就算順順利利，一篇稿子從開工讀材料到審完，單個會話也要喫掉 800 萬到 1,300 萬原始量。開工時把用得上、用不上的材料全讀進來，用不上的那部分也照樣付了錢。
定時任務裏的話題摘要，那時候每小時跑一輪，每輪還要派瀏覽器去 X 上搜 10 組帖子。10 日早上光 2 輪就分到約 3M，一天 24 輪折算下來是三千多萬的量級。每晚的回覆自查，要把前一天約 100 條回覆的原帖全部重抓一遍再審。
收集器也是定時任務的一種。它每 20 分鐘把時間線收一遍。這種定點重複的事，我早先也用 agent 定時任務跑。它跑了 31 輪，每輪都是一個 agent 在跑，31 輪實際跑的時間加起來約 2.4 個小時，花的全是 agent 的 token。
病根：重讀和開工費
前面幾攤賬拆完，共同的病根就清楚了。這筆賬裏最大的一塊，是上下文反覆重讀。我查過兩個統計時段的內部記錄，按原始量算，輸出只佔約 1%，輸入約佔 99%。輸入燒的是上下文，因爲 agent 每往前走一步，都要把之前的對話和文件重新讀一遍，讀的量比寫的量大兩個量級。
開工費一份約 8.8 萬，份數跟着 agent 的個數走。我做統計的那一段時間（下面都叫一個窗口），10 日早上的窗口裏全賬號開了 273 個 agent，11 日的窗口裏開了 480 個。480 個 agent，光開工費就是約 4,200 萬原始量。整改後的窗口裏只開了 242 個 agent，這筆開工費也跟着少了一半。
算總賬
燒得最快的一段是 10 日早上，8 個小時燒掉 63M，平均每小時 7.9M。10 日全天平均下來，每小時約 5.8M。11 日的窗口再降一點，每小時 5.15M。整改做完之後，11 日下午到 12 日中午的 22.9 個小時只燒掉 62M，每小時約 2.7M，只有 11 日窗口的一半左右。
燒得最快的時候，約 40 億的池子 21 天見底。燒速每降一檔，壽命就往上翻：每小時 5.8M 那一檔撐 29 天，整改後每小時 2.7M 那一檔撐 62 天。三種壽命用的是同一個池子，差別全在燒法。把池子換成封頂的 300 億，算法不變：最快那一檔約 158 天，中間那一檔約 216 天，整改後那一檔約 463 天。封頂數換成天數，也就是幾個月到一年多的量。
12 日中午剩下的 642M，按最快的燒法 3 天多就沒有了，按整改後的燒法能撐約 10 天。因爲周額度要到 11 月 15 日才重置，這 10 天就是我還敢不敢繼續派任務的邊界，燒法退回去，重置之前我就得停下來等。
Meta 幫助中心的公開頁寫的是 Power 每月 20 美元、每週 500M，Maximum 每月 100 美元、每週 3,000M。我賬號的儀表裏給的報價是每月 16 美元和 80 美元，兩個口徑的價格對不上，所以我按公開價算賬，按我賬號的報價算還要再便宜兩成。
按公開價折，約 40 億的池子約等於 1.85 個月的 Power 額度。Power 的月均額度是每週 500M 乘以 52 周再除以 12 個月，約 2,167M，所以 4,000M 折成錢約 37 美元。一個聽着很大的池子，換成訂閱也就是不到兩個月的量，我寫這篇，就是從這個數開始往下算的。
整改後我每週燒約 454M，Power 每週 500M 的額度裝得下，要用掉約九成。每小時 5.8M 的燒法每週要 974M，超過 Power 的 500M，就不夠了。最快的那種燒法每週要 1,327M，Maximum 每週 3,000M 裝得下，用量佔四成多。
換成月賬看得更清楚：整改後的用法一個月約 1,940M，中間那一檔一個月約 4,180M，最快的一檔一個月約 5,690M。所以用法收住，Power 一檔就夠我用一個月，用法收不住，就得按 Maximum 的價錢準備預算。
改了三件事
我改的第一件事，是分工的判據。一件事先看它需不需要動腦判斷，需要判斷的才交給 agent，審稿和決定一條帖子該不該回，都在這一類。動作全是定死的工作，就寫成腳本，比如發送和記賬。腳本跑多少遍都不花 token。agent 不一樣，每跑一遍，先付一遍開工費。
巡邏的發送改完之後，連續 20 班，每班都只有 1 個 agent，子任務總數是零。消費者佔全賬號原始量的比例，也從 43% 降到了 15%。前面講的燒速從每小時 5.15M 降到 2.7M，靠的就是這類改動，一班一班地把委派出去的子任務收回來。收集器也照同一條判據改了，它換成零 token 的腳本服務常駐，那筆每 20 分鐘一輪的開銷直接歸零。
第二件事，是子任務的派法。以前我常常直接派，圖的是自己省事。每派一個，子任務那邊就是一個新 agent 開工，要重新背一遍那 8.8 萬的上下文。現在只有必須隔離的事纔派，一件是發文前的獨立覈對，一件是深度回覆（巡邏裏寫得長又要展開講看法的那種回覆）的冷讀。
獨立覈對和冷讀這兩件事，都要請沒參與寫作的人來做。沒參與過的人讀稿子，讀到的就是讀者讀到的樣子，作者自己看不見的卡點，他一眼就能挑出來。混在一條會話裏自己審自己，寫的和審的是同一個腦子，這些卡點就挑不出來了。
稿子這邊照同一條規矩改。一篇稿子開一個新會話，辦選材、潤色和審查。交代任務時，只給這一篇用得上的那部分材料。改完之後，下一個窗口裏，稿子這一攤合起來只佔全賬號原始量的 1.4%，子任務是零。幾篇文章不再擠在一條聊天裏，後面每一篇也不用再替前面的文章重讀一遍歷史了。
第三件事，是會話和檔案的壽命。這類個人助理不止 muse 一家。dot 和 grok bot 本質上仍舊是多個 agent 協同工作，所以誰家都有開工必讀的常駐檔案，muse 裏就是 MEMORY.md 和 AGENTS.md 兩份。
這兩份檔案每天都在花錢，我把 MEMORY.md 從 9,355 個 token 瘦到 2,038 個，把 AGENTS.md 從 5,646 個瘦到 1,504 個。兩份合計，每個新 agent 開工時少讀約 1.15 萬 token。按 11 日那個窗口的 480 個 agent 算，光那一個窗口就少讀約 550 萬 token。
聊天本身攢厚了也要換。巡邏那條聊天用的時間一長，負責整條巡邏流程的主 agent，在單個窗口就喫掉 25.0M 原始量。它每走一步，都要把整條聊天的歷史重讀一遍，所以這筆錢是每一步都要付的。11 月 12 日我把巡邏換到一條新聊天，舊聊天歸檔，這筆重讀的錢纔不再付了。一條業務線用一個聊天，攢厚了就歸檔換新。現在我每改完一輪，就把儀表讀數記下來，再按燒速算一遍還剩幾天，不再等池子快燒空了才查賬。
改完之後
整改完，我的池子還是剩那 642M。它按整改後的速度能撐到 11 月 15 日周額度重置之後，還有富餘，所以我沒有再往下砍流程。要是燒法退回 10 日早上那個樣子，這個池子 3 天多就見底，我在重置之前就得停工。
如果你也在用 muse、dot 和 grok bot 這類個人助理做事，也想查自己的 token 到底燒在哪，這篇裏的查法和改法應該能幫你對上號。麻煩收藏一下，再訂閱這個博客，我會繼續把這類實測賬發出來，整改之後的復盤也會接着發。