Grokのサブスクリプションをもっと長持ちさせる方法：実際に計測した結果
Grok Buildの使用量上限を圧倒するのは入力プロンプトではなく、エージェントが自分で読み込むファイルです。1セッションにどれだけ流入するかを正確に計測し、見つけた結果に合わせてmeshcodeのGrok起動方法を変えました。
Grok Buildが上限到達メッセージで止まると、多くの人は「単に使いすぎた」と思いがちです。しかし、実際にセッションを流れるバイト数を計測すると、見えてくる景色は違います。上限を圧倒するものの大半はプロンプトそのものではなく——エージェントが自分で読み込んでいるファイルです。
私たちはそれを推測のままにせず、計測し、見つけた結果に合わせてmeshcodeのGrok起動方法を変えました。この記事は、何を計測し、何を変え、結果がどこまで有効で、どこから有効でなくなるかの記録です。
1セッションで30.4MBが流入していた
2026年8月19日、1つのGrokセッションの全インバウンドコーパスに計測を仕掛けました。合計は30.4MB。カテゴリ別に内訳を見ると、原因は明白です。
ここで重要なのは、分布の形です。大半の場合、Grokは20〜80行を自分で読み込みます——その呼び出しに問題はありません。予算を圧倒するのは、制限をまったく設定しなかった290件の呼び出しで、それだけで1.83MBを占めます。それぞれがフルファイルを読み込んでいました。
Grokのメタ検索ツールsearch_toolも同じ傾向を示します。p90は控えめな11KBですが、最大値は39KB、合計は2.75MBに達します。対照的にmeshcodeのツールはすでに上限を設定済みで、計測された最大値はreadの9.9KB、grepの8KBでした。ここに修正すべきことはありません。
すでに契約しているClaude・Codexをそのまま接続。あとは数分の一のコストで動くワーカーに任せます。
meshcode をダウンロード →タイルがなぜセッション全体を食いつぶすのか
「30MB中の1.83MBは6%にすぎない」という結論に達するのは容易です。しかし、それは罠でもあります。
エージェントの会話ではコンテキストが蓄積します。30KBのファイルがターン3で丸ごと流れ込み、セッションが40ターン続いた場合、その30KBは残り37ターンすべてで再課金されます。一度の無制限な読み取りは単発のコストではなく、セッションが長引くほど複利のように膨らみます。
以前の記事で解説したように、これはGrok Buildの上限が最も敏感になる箇所です。Grokの無料プランの上限はリセット時刻を教えてくれず、アップセルを表示するだけです。予算がどこでリセットされるかの可視性が低いほど、早期の漏洩がもつコストは大きくなります。
したがって、私たちが設定した目標は「Grokを節約して使うこと」ではなく、もっと狭いものでした：通常呼び出しには一切触れず、タイルだけを削る。
meshcodeがGrokに課す4つの制限
meshcodeでGrokペインを開くと、素のgrokとは異なり、4つのメカニズムが同時に作動します。
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上で動作しないため、初回ターンにツールスキーマとして付加されそうな残存カタログをすべて無効化します。
4. 大量探索は安価なモデルに委譲。 最大の節約は上限そのものからではなく、仕組みから来ます。meshcodeが「ここにあるものを探せ」を安価なバックエンドの子セッションに委譲すると、その子が読み込む数十MBがGrokセッションに入ることはありません。 戻ってくるのはfile:line参照の束だけです。meshcodeはセッション開始時にこのルールを設定し、探索呼び出しが積み上がると短いリマインダーで再確認します。
「使う量を減らす」が本当に意味すること——そしてそうでないこと
率直に述べる必要があります。私たちは「トークンを40%削減」のような数字を主張するつもりはありません。その種の数字はワークロードによって大きく変動し、私たちが計測したものですでもありません。
実際に言えることは以下の通りです：
- 1セッションで30.4MBが流入し、最大項目はread_fileの11.9MBでした。
- その中で、上限が実際に狙っているのは制限なし290件の1.83MBと、10KB超のタイル1.32MBです。
- search_toolは合計2.75MBで、ピークに39KBの応答が混入し、12,000バイトの上限がそのタイルを削ります。
- 削られた量は1回だけでなく、コンテキストが蓄積するため残りのすべてのターンで節約されます。
事実でないこと：これらのメカニズムのいずれもGrokを賢くするものではありません。エージェントが300行の上限で許された以上にファイルを必要とする場合、それはただ読み続けます——ただし、実際に必要な部分だけを読むようになります。上限の目的は禁止ではなく、デフォルトを無制限から意図的なものへと転換することです。
素のGrok TUIを壊さないことも要件だった
この作業で最も難しかったのは節約そのものではなく、副作用の回避でした。
Grokのフックファイルはプロジェクトレベルには置けず、グローバルな~/.grok/hooks/にのみ格納されます。これはmeshcodeがインストールしたフックが、誰かが自分のターミナルで素のgrokを打った時にも発火することを意味します。最初の実装では、フックが「これはうちのセッションか？」を確認するために毎回meshcodeバイナリを実行していました——その確認だけで1回あたり895msがかかり、一部の条件下ではすべてのread_file呼び出しに対してウィンドウが開くことさえありました。他人のセッションで。
そこで、チェックをバイナリから小さな外部シェルスクリプトに移動しました。セッションがmeshcode起動時に仕込むマーカーを保持していない場合、スクリプトは何もせず即座にパススルーします。
昨日再検証した結果は以下の通りです：
| シナリオ | 結果 |
|---|---|
| 素のGrok TUI（マーカーなし） | 0.00s、プロセスゼロ、ウィンドウなし |
meshcodeセッション + 制限なしread_file |
limit: 300注入を確認 |
meshcodeセッション + limit: 50呼び出し |
変更なしでパススルー |
| meshcodeセッションフック遅延 | 895ms → 約12ms |
他人のツールを遅くする節約は節約ではありません。このフックが素のGrokユーザーに与えるコストはちょうどゼロでなければならず、それが確認されて初めてリリースしました。
meshcodeの視点
meshcodeはmacOSとWindows向けのネイティブデスクトップアプリで、複数のエージェントを並列ペインで動かすことを中心に作られています。すでに使っているGrokのサブスクリプションをそのままペインに接続できます——同じ請求、同じ上限、meshcodeからの追加料金はありません。
その違いは、同じサブスクリプションがより長持ちすることです。特殊なトリックのためではなく、セッションにどれだけ流入するかを実際に計測し、タイルに上限を設けたからです。また、大規模な探索作業は最初から安価なモデルのコンテキストで行われるようセットアップされているからです——Grokコンテキストではなく。
上限管理自体をやめたい場合は、meshcode自身の従量モデルが横にあります——月額なし、共有ウィンドウなし、使った分だけ下がる残高だけです。いずれかのツールが「後でもう一度来てください」と言った瞬間に場所があるということです。Claudeについても同様の分解が必要な場合は、Claude Proのサブスクリプションをもっと長持ちさせる方法で扱っています。
プロンプットを節約して上限を保存しようとしないで——流入するものに上限を設けましょう。 meshcodeは無料で始められ、Grokペインは初回起動から4つの上限すべてが有効です。
👉 meshcodeをダウンロード — Mac、Windows。