如何讓你的 Grok 訂閱更耐用：我們實際測量的結果

當 Grok Build 跳出用量已達上限的訊息時，多數人會直覺認為是自己問得太多。但一旦你真正去量測流經一個工作階段的位元組數，畫面就不一樣了。真正燃燒限額的其實不是你的提示詞——而是 agent 自己讀進來的內容。

我們沒有止步於猜測——我們實際量測了，然後據此調整 meshcode 啟動 Grok 的方式。這篇文章記錄了我們量測了什麼、改了什麼，以及結果在哪些條件下成立、哪些條件下不再成立。

單一工作階段灌入的 30.4MB

2026 年 8 月 19 日，我們對一個 Grok 工作階段的全部輸入內容進行了完整的儀器化追蹤。總計達到 30.4MB。按類別拆解後，元凶一目了然。

這裡的重點是分布的形態。多數時候 Grok 自行讀取 20–80 行——這類呼叫沒問題。真正燃燒預算的是那 290 次完全沒有限額設定的呼叫，光這些就佔了 1.83MB。每一次都讀入了整份檔案。

Grok 的元搜尋工具 search_tool 呈現相同的分布。其 p90 僅 11KB，但峰值達 39KB，總量為 2.75MB。反觀 meshcode 自己的工具已經自行設有上限——實測最大值為 read 的 9.9KB 與 grep 的 8KB。無需修改。

為何一小段尾端就能吃掉整個工作階段

「1.83MB 佔 30MB 的 6%」是最容易得出的結論，也是陷阱所在。

在 agent 對話中，上下文會累積。如果一份 30KB 的檔案在第 3 輪整份落入，而工作階段總共跑 40 輪，那 30KB 就會在剩餘的 37 輪中每一輪都被重複計費。一次未經控管的讀取不是一次性成本——它會隨著工作階段的進行而不斷複利。

這正是 Grok Build 限額最敏感的地方。如我們之前所述，Grok 的免費限額不會告訴你重置時間——它只會顯示升級提示。你對預算何時回充的掌握越少，早期洩漏的成本就越高。

所以我們設定的目標不是「讓大家省著用 Grok」——範圍窄得多：不碰正常呼叫，只修剪尾端。

meshcode 加在 Grok 上的四道限幅

在 meshcode 中開啟一個 Grok 面板，與直接執行裸 grok 不同的是，會同時啟動四項機制。

1. read_file 上限 300 行。 Grok 的 read_file 是內建於 Grok 二進制檔中的工具，因此我們無法事後修改其輸出。取而代之的是，我們在呼叫發出前攔截，僅對無限額設定或要求超過 300 行的呼叫注入 limit=300。正常的 20–80 行呼叫完全不會觸及這個值。

2. MCP 工具輸出上限 12,000 位元組。 由於 search_tool 的 p90 為 11KB，12,000 位元組的天花板能修剪 39KB 的尾端而不影響正常回應。作用範圍僅限 meshcode 啟動的行程——你的 ~/.grok/config.toml 不會被觸碰。

3. 首輪不載入他人的目錄。 Grok TUI 預設會掃描 Cursor 的 MCP 設定和 skills/rules。meshcode 不在 Cursor 上運行，所以我們關掉了那些殘留的 Cursor 目錄——它們原本會在第一輪就附掛為工具 schema。

4. 大量探索轉交便宜模型。 最大的節省不是來自限幅本身，而是來自結構。當 meshcode 把「找到這個東西在哪裡」的工作交給一個更便宜的後端子工作階段時，子模型讀入的數十MB**根本不會進入你的 Grok 工作階段。**回傳的只是一小把 file:line 引用。meshcode 在工作階段啟動時植入這條規則，並在探索呼叫開始堆疊時以簡短提醒再次強化。

「少用一點」實際意味什麼——以及不意味什麼

我們需要坦誠面對這一點。我們不會宣稱「減少了 40% 的 token」之類的數字。那類數據會因工作負載而劇烈波動，那也不是我們測量的東西。

以下是我們能確實說的：

• 一個工作階段灌入了 30.4MB，其中最大的項目是 read_file 的 11.9MB。
• 在其內部，限幅實際瞄準的是 290 次無限額呼叫的 1.83MB 以及超過 10KB 的 1.32MB 尾端。
• search_tool 合計 2.75MB，其中峰值混入了一筆 39KB 的回應，12,000 位元組的限幅修剪了那段尾端。
• 被修剪掉的節省不是一次性生效，而是在剩餘的每一輪中都生效，因為上下文會累積。

不成立的是：這些機制都沒有讓 Grok 變聰明。如果 agent 需要的內容超過 300 行限額所允許的範圍，它會繼續讀取——只不過現在它只讀它真正需要的部分。限幅的意義不在禁止；而是把預設行為從「無上限」翻轉為「有意識地設定上限」。

不破壞裸 grok TUI 也是必要條件

這項工作最困難的部分不是節省本身——而是避免副作用。

Grok 的 hook 檔案不能放在專案層級——它們只會出現在全域的 ~/.grok/hooks/。這意味著 meshcode 安裝的任何 hook，也會在別人輸入裸 grok 時觸發。第一版實作讓 hook 在每次呼叫時執行 meshcode 二進制檔來檢查「這是不是我們的工作階段？」——光這個檢查每次呼叫就花費 895ms，而且在某些條件下，它會為每一次 read_file 呼叫都彈出一個視窗。在別人的工作階段裡。

所以我們把檢查從二進制檔移出，改為一個小型的外部 shell script。如果工作階段沒有攜帶 meshcode 啟動時種下的標記，script 什麼都不做，直接放行。

以下是我們昨日重新驗證的結果：

讓別人的工具變慢的節省不是真正的節省。這個 hook 對裸 Grok 用戶的成本必須是零，我們是在確認這一點之後才上線的。

meshcode 的角度

meshcode 是針對 macOS 和 Windows 的原生桌面應用程式，圍繞在並行面板裡同時跑多個 agent 來打造。你可以把既有的 Grok 訂閱直接接到一個面板——同一份帳單，同一套限額，meshcode 中間不多收一分。

差別在於同一份訂閱能用得更久。不是因為什麼特殊技巧，而是因為我們實際量測了流入工作階段的內容和數量，並設下了尾端上限。同時，大規模的探索工作從一開始就被設定在更便宜的模型上下文中進行——而不是在你的 Grok 上下文中。

如果你不想再管理限額，meshcode 自己的按量模型就在旁邊——沒有月費、沒有共享視窗，只有一筆隨用隨扣的餘額。這意味著當你的工具說「稍後再來」時，你還有地方可去。如果你想看同樣的分析關於 Claude，我們在如何讓你的 Claude Pro 訂閱更耐用中有詳述。

別試圖透過分配提示詞來節省限額——改為限制流入的內容。 meshcode 免費即可開始，Grok 面板首次啟動就啟用上述四道限幅。

👉 下載 meshcode — Mac、Windows。