第 10 章 利用枠とコスト：1週間の利用枠を1週間持たせる
火曜日に利用枠を使い果たし、百ドル以上の請求が発生する原因の多くは、コンピュートリソースの空回りにあります。Bot はウェイクアップするたびに会話履歴全体を再読み込みするため、数時間で数十万トークンにまで膨れ上がってしまいます。
1週間安定して持たせるには、次の3点を徹底してください。
- バックグラウンドのオンデマンド従量課金をオフにする。
- 高頻度のポーリングや複数 Bot 同士の会話を減らす。
- セッションをコンパクトに保ち、チャット欄に大きなファイルを投入しない。
Grok Bot の利用枠の課金・消費の仕組みとは？
Grok Bot は呼び出しトークン数に応じて課金されます。その中核メカニズムは単一の長い会話であり、返信やウェイクアップのたびに過去のコンテキスト全体を再読み込みするため、総消費量はウェイクアップ回数×毎回再読み込みされるコンテキスト長に等しくなります。
Grok Bot はモデルが実際に呼び出したトークン数に応じて課金されます。その中核メカニズムは単一の長い会話であり、返信や定期的なウェイクアップのたびに、全履歴を最初からすべて読み直します。
每周总消耗 = Bot 唤醒的总次数 × 每次唤醒时重读的上下文长度セッションに大量のログやウェブページが溜まると、1回の再読み込みが数十万トークンに達し、1行返信するだけでも全量で計算されます。
コミュニティによる徹底解説は 『How to Stop Your Grok Bot From Eating a Week of Usage in a Day｜Fan Grok Bot Radar』 をご覧ください。
2026 年 10 月 12 日より The X Subscription 統一サブスクリプションプランが導入され、各プランの基準は以下の通りです：
| プラン | 個人サブスクリプション価格 | チームシート価格 | 利用枠倍率と Grok Bot 権限 |
|---|---|---|---|
| Free | $0 | 適用外 | Limited、完全版 Bot は非対応 |
| Plus | $8/月（$80/年） | 適用外 | Base、Grok Bot は明確に対象外 |
| Premium | $30/月（$300/年） | $30/席/月 | 4x、Grok Bot を含む |
| Super | $100/月（$1000/年） | $100/席/月 | 15x、Grok Bot を含む |
| Ultra | $200/月（$2000/年） | $200/席/月 | 50x、Grok Bot を含む |
利用枠のルールの詳細は Cursor 公式ガイド：プランと請求 を参照してください。日常的な利用にはいくつか厳格な制限があります。
- 利用枠プールは合算されない：複数のプランを契約していても、週間利用枠が最も高いプランのみが適用され、合算・蓄積はされません。
- 共有プールの適用範囲：週間利用枠は Grok Bot および Cursor 内の Grok をカバーし、Web 版、モバイル版、Imagine、Voice も含まれ、期日に固定リセットされます。
- サードパーティモデルは個別課金：Cursor 内で非 Grok モデルを呼び出す場合は、直接従量課金されます。
- オンデマンド従量課金と月間利用上限：週間利用枠を使い切った後に On-demand を有効にすると月間利用上限（Monthly Limit）にカウントされ、上限を超えても実行中のタスクは最後まで完了します。オフにすると応答を停止し、リセットを待ちます。
公式に「モデルセレクターは存在しない（there is no model picker）」と明記されており、低スペックモデルへの切り替えはできません。 コストを抑えるには、ウェイクアップの頻度を下げる、コンテキスト長を切り詰める、または高負荷な計算を外部にオフロードするしかありません。
Grok Bot で利用枠を大量消費するよくある落とし穴とは？
複数 Bot のグループチャット、会話への画像・動画の直接投入、終日の高頻度ポーリング、長時間の同一セッションの使い続け、保護機能のないリトライ無限ループ、そして月間上限を設定せずに無計画にオンデマンド従量課金をオンにすることは、絶対に避けなければなりません。
参考情報元：『4.1 利用枠とコスト：利用枠節約チェックリスト』、『Grok Bot 利用枠を劇的に長持ちさせる初心者向け完全ガイド（Bot に直接送信可能！）』。
| 大量消費する操作 | 利用枠を消費する原因 | 回避策 |
|---|---|---|
| 複数 Bot のグループチャット | 相互ウェイクアップによりトークンが倍増して空回りする | 1つの主導 Bot に Subagents でタスクを割り振るか、人間と1対1で会話する |
| 会話に直接画像や動画を投入 | 履歴にフレームが残り続け、毎ターン全量再読み込みで課金される | ターミナルのコマンドラインで処理し、Bot には100文字以内の構造化テキストのみを渡す |
| 終日の高頻度ポーリング | 15分に1回だと週672回になり、その大半が「変更なし」の確認に終わる | 勤務時間内に絞り込むか、システムスクリプト＋Webhook に切り替える |
| 1つのセッションを使い続ける | 数十ターン後に1ターンあたり数十万トークンの再読み込みが発生する | 1タスク1セッションとし、定期的に要約して Duplicate でリセットする |
| 保護機能のないリトライ無限ループ | エラー発生後に連続して何十回も自律的に再試行する | プロンプトでリトライ上限を2回に強制設定し、失敗時は即座に中断して人間に確認する |
| 無計画な従量課金の有効化 | 無限ループにより一晩で高額請求が発生するリスクがある | 普段はオンデマンド従量課金をオフにし、オンにする場合は厳格に低い月間上限を設定する |
利用枠節約の4ステップワークフロー：損切りからオフロードまで
課金とセキュリティのベースラインを固定する
- Settings > Usage & Billing に移動し、プラン（Premium $30/月 または Super $100/月）、利用量、リセットカウントダウンを確認します。フリーズした場合は Stop をクリックして強制終了します。
- デバッグ時は Additional Usage / On-demand をオフにします。有効にする場合は、cursor.com/dashboard > 支出 > Monthly Limit で月間上限（$10〜$20）を設定してください。
- Settings > General > Auto-review に移動し、send、post、buy、transfer、delete、permissions を Ask first（手動承認）に設定します。
セッションとインタラクションを標準化する
- 1タスク1セッションを徹底し、完了後は直ちにアーカイブします。
- ログや長文は
/workspace/に保存し、結論とパスのみを返信させ、会話への貼り戻しを厳禁とします。 - X 検索は毎分30回、1日1000回に制限されており（週間利用枠は消費しません）、Bot に対して「核心となる事実を抽出し、3〜5件の要点として出力する」よう制限します。
- セッションが肥大化したら Duplicate でリセットします。まず旧 Bot に10行以内のまとめを作成させ、それをコピーして新規 Bot に引き継がせ、旧 Bot は非表示にします。
機能のルーティングとオフロード
- メインの Bot はタスクの分解、割り振り、集約のみを担当させ、長いコードの記述や大きなファイルの変換は行わせません。
- コード生成は Cursor クラウド Agent を経由させ（Cursor の利用枠が適用され週間利用枠は消費されません）、または仮想マシン内でヘッドレスに Grok Build CLI / Codex CLI を実行します。
- スクリーンショットや音声・動画はクラウド PC のコマンドラインで処理するか、無料モデルでテキストに変換してから Bot に渡します。
定期タスクの改修
- Details > Routines で、過去1週間にわたり毎日「変更なし」と報告しているルーティンを一時停止または削除します。
- 低コストな Linux スクリプトによるポーリングに切り替え、変更があった場合のみ Webhook を送信して Bot をウェイクアップさせます。
- 残したルーティンにはサイレント指示を記述します：「確認後に変更がない場合は、タスクを直ちに終了し、一切のテキストを出力することを禁ずる」。
ルーティンとポーリングの徹底最適化：無駄な空回りと決別する
ルーティンは隠れた利用枠のブラックホールであり、高頻度のポーリングは1日で1週間分の利用枠を使い果たしてしまうことすらあります。
頻度の抑制と実行ウィンドウの制御
クライアント側で、まず Bot の Timezone がローカル環境と一致しているか確認してください。スケジュールの設定による消費の違いは以下の通りです：
| スケジュール設定 | 週間実行回数 | 適用シナリオ |
|---|---|---|
| 15分に1回（24時間常時） | 672回 | 1〜2日で利用枠を使い果たしやすく、必要とされることは極めて稀 |
| 1時間に1回（24時間常時） | 168回 | クリティカルなインフラの障害監視 |
| 平日 9:00〜17:00 に1時間に1回 | 45回 | カンバン追跡、チケット処理、メールの仕分け |
| 平日毎日 3回 | 15回 | 日々の受信トレイの朝・昼・夕のトリアージ、進捗フォロー |
| 週1回 | 1回 | 業界週報、技術動向まとめ、ドキュメントのアーカイブ |
勤務時間内に限定するには、標準的な cron 形式が使用できます：
CRON_TZ=Asia/Shanghai 0 9-17 * * 1-5この1行のルールにより、ウェイクアップ回数が93%削減されます。上海タイムゾーンの平日9:00から17:00の毎正時に実行され、1週間にトリガーされるのはわずか45回です。
スキルを指定しサイレントルールを厳格に適用する
ルーティンのプロンプトではスキルのみを指定し、詳細を展開しないようにします：
- スラッシュコマンドで具体的なスキル名とチェック対象を指定する
- 判定のしきい値、停止条件、1回のリトライ制限を明示する
- 変更がない場合は完全に沈黙を保ち、メッセージを一切送信しない
完全な沈黙は途中の障害を見落としやすくなります。組み合わせの運用案については Cursor 公式ガイド：ルーティン を参照してください。高頻度ルーティンは沈黙を維持し、低頻度ルーティンは毎日18:00に1行のハートビートログを送信して、過去1日の正常実行を確認します。
2つの役割の分離：Linux cron スクリプトによる巡回監視＋Webhook ウェイクアップ
Bot がスリープしていても基盤の Linux クラウド PC は動作し続けています。機械的な比較処理を大規模言語モデルにやらせてはいけません。
- チェック役：システム標準の cron で Python または Shell スクリプトをスケジュール実行して比較します。所要時間は数秒で、消費する利用枠はゼロです。
- 判断役：スクリプトが変更を検知したときのみ Webhook を送信して Bot をウェイクアップし、論理判断とレポートを行わせます。
Webhook によるウェイクアップ手順と検収基準：
- ルーティンの Webhook エリアで
POST toアドレスとkeyを取得します。 - その URL に対して
Authorization: Bearer <key>ヘッダーを付与した POST リクエストを送信します。 - レスポンスステータスコードを確認し、200 が返ってくればウェイクアップ成功です。
実践事例と落とし穴の回避
铁柱によるマーケティングディレクター Bot のルーティン6件の改修：成果物提出系のルーティン4件はそのまま維持し、返信待ちや PR レビュー待ちで空回りしていたタスク2件をシステム cron スクリプト＋Webhook に切り替えました。スクリプトは平日の日中に30分ごとにチェックを行い、新たな変更があった場合のみウェイクアップします。
改修の所要時間は約23分で、週あたり8〜10回の余計なウェイクアップを削減し、新たな動きの検知スピードは30分以内に向上しました。
Craig Hewitt 氏が24時間で Ultra の週間利用枠を使い切った事例：月額 $200 の Cursor Ultra プランを契約していたものの、2026年8月23日の1日で1週間分の利用枠を使い果たしました。
日常的にメインで会話していたマネージャー Bot 上で過去10年分の古いメールのアーカイブを実行したところ、API から取得した本文が会話に次々と追加され、コンテキストが数十万トークンにまで膨張して全量再読み込みの嵐を引き起こしました。
事例情報元：『How to Stop Your Grok Bot From Eating a Week of Usage in a Day｜Fan Grok Bot Radar』。
高負荷時の落とし穴回避ポイント：高負荷な単発タスクは、日常的に会話しているメイン Bot で絶対に実行してはいけません。専用の Bot を新規作成するか、Duplicate で複製を作成する必要があります。また、処理前にメールの振り分けルールでスパムをフィルタリングし、バッチタスクは必ず事前に1〜2件のサンプルで問題がないことを検証してから開始してください。
グループチャットと複数 Bot の制御：相互ウェイクアップを撲滅する
複数の Bot を同じグループチャットに絶対に追加しないでください。 新着メッセージが全員にブロードキャストされ、各 Bot が履歴全体を再読み込みして返信してしまいます。铁柱本人の記述によると、4つの Bot 同士が会話したことで、あっという間に週間枠の25%が消費されたとのことです（未検証）。
複数 Bot の連携では、ハブ＆スポーク型を徹底し、横方向の直接連携を禁止する必要があります。
- 唯一の主導者：対話のエントリポイントとなる主導 Bot は1つだけに絞る。
- 一方向のタスク割り当て：主導 Bot が Subagents を起動するか、A2A の1対1ハンドオフを行い、サブエージェントは実行完了後に自動終了させ、グループ内で発言を続けさせない。
- 成果のファイル保存：上流は
/workspace/ディレクトリ配下のファイルにデータを書き込み、下流はそれを直接読み込むようにして、チャット欄でやり取りを推敲しない。 - アイドル Bot の整理：紐づいているルーティンがないことを確認した上で、使っていない Bot を速やかに削除し、誤ってウェイクアップされるのを防ぐ。
情報元：『4.1 利用枠とコスト：利用枠節約チェックリスト』
Grok Bot で利用量監査と枯渇時の緊急対応はどう行うか？
毎週のリセット前日に15分かけてルーティン履歴と課金状況を確認しましょう。万が一利用枠を使い果たしてフロントエンドがロックされても、基盤の Linux クラウド PC は破棄されないため、ターミナルを直接開いてコードを引き継ぎ、手動でコミット・プッシュできます。
毎週15分の監査プロセス
毎週のリセット日の前日に、15分かけて以下の点を確認することをおすすめします：
- Settings > Usage & Billing を開き、消費パーセンテージを確認します。想定以上のペースで消費されている場合は、過去数日間のタスクを確認して異常が発生した日付を特定します。
- Details > Routines に進み、直近20回の実行履歴（Running、Succeeded、Failed）を確認し、エラーによるリトライや頻繁な空回りが発生しているルーティンを洗い出します。
- v0.66.0 以降のスター付きメイン Bot については、余計な雑務を勝手に引き受けないよう、説明文（Description）で自発的なタスク引き受けを明確に禁止します。
- cursor.com/dashboard にアクセスし、Monthly Limit と実際のオンデマンド請求額を照合して、異常な課金がないことを確認します。
監視の死角と対策
システムは Bot、ルーティン、セッション、モデルごとの詳細な消費明細を提供しておらず、20件の実行履歴にもトークン数や金額は記録されません。新しいワークフローをテストする際は、必ず変数を1つに絞ってテストしてください：
- 1回につき1つの Bot またはルーティンのみを新規作成または変更する。
- 実行の前後で Usage & Billing のパーセンテージをそれぞれ確認して増加分を比較し、決して複数の新しいルーティンを同時に稼働させない。
利用枠枯渇時のクラウド PC 引き継ぎ・緊急対応
週間利用枠を100%使い果たしてフロントエンドのチャットがロックされても、基盤の Linux クラウド PC は破棄されていません。クライアントからデスクトップまたはシステムターミナルを開くことで作業を引き継げます：
/workspace/ディレクトリ下の未納品コードやファイルを確認する。- 手動で
git commitとgit pushを実行し、リモートリポジトリにプッシュする。 - ターミナル上でローカルコマンドラインツールを使ってデバッグを引き継ぐ。追加利用枠を有償購入する必要は一切ありません。
情報元：『4.1 利用枠とコスト：利用枠節約チェックリスト』、『Grok Bot 利用枠を劇的に長持ちさせる初心者向け完全ガイド（Bot に直接送信可能！）』
Bot に直接送信できる利用枠節約プロンプト集
コンテキストの肥大化防止
- ルールを Bot に要約させて記憶させ、チャットで毎回繰り返し説明する手間を省きます。共有 Bot の場合は詳細の About に書き込むことも可能です。
请回顾我们至今的协作流程，执行两项沉淀工作：
1. 把你需要长期遵守的行为边界、汇报格式与约束规矩，提炼成一段不超过 300 字的精简文本，我将直接粘贴到你的描述（Description）中；
2. 把我们刚才已经跑通的标准操作流程，封装为一个可复用的技能（Skill），供后续例程直接调用。
完成提取后直接在对话中给出文本，不要展开多余闲聊。- 生のログや長大な資料は強制的にファイル保存させ、会話に直接貼り付けさせない。
从现在起执行上下文瘦身规则：
所有抓取的长篇网页、接口调试日志、大批原始数据和阶段性中间产物，一律直接保存为 /workspace/ 目录下的文本文件。在聊天窗口中回复我时，严格只提供核心结论、关键变动要点以及对应的文件绝对路径。严禁将大段原始文本或日志代码贴回对话。- マルチモーダル画像はコマンドライン解析に回し、チャット欄での高消費を回避します。
遇到查看多张截图、分析视频画面、逐帧拉片、音频转写或处理长扫描件的任务时，严禁在当前对话框中直接读取原始多模态文件。
你应当在云电脑终端中调用系统已配置的命令行工具（如 Grok Build 或相关转录 CLI）在后台执行，并输出简明的结构化文字摘要；你只需阅读生成的文字结论。如果当前环境无法执行命令行解析，请停下提醒我先在网页端转换成文字后再发给你。タスクとコードのオフロード
- 監視ルーティンは変更がない場合、サイレントで終了させる。
请列出当前你名下的全部例行任务（Routines），注明每条任务的触发频率、每周预计运行次数以及没有变化时的处理逻辑。
找出其中运行最频繁、消耗最大的任务，向我提出降低频率的具体建议；同时为所有监控类例程添加硬性约束：执行检查后若目标无实质变动，立刻静默退出，严禁向我发送「一切正常」或「没有新消息」等无有效信息的通报。- タスクは1対1チャットで割り振り、Bot が勝手にグループチャットを作って会話することを厳禁とします。
严格执行独立单聊工作模式：
只接收并执行我本人下达的直接指令。严禁在没有得到我明确授权的情况下，主动在会话中唤醒、提及或联络其他 Bot 开展群聊协同；如果任务涉及多个专业环节，请将结果写成文件并由我来负责跨 Bot 调度，或者将其派发给云电脑内的后台 CLI 工具独立运行。- Bot はオーケストレーションに専念させ、長いコードの記述やデバッグはバックグラウンドの Grok Build CLI にオフロードします。
明确你的角色定位是任务调度主管，核心职责是理解目标、拆解方案、组织逻辑和验收结果。
不要在聊天窗口中直接编写整段的长篇代码，也不要通读整个大型仓库做全量重构。涉及代码编写、项目调试和环境排查的工作，统一在后台调用云电脑内已经授权的 Grok Build 命令行工具执行。执行完毕后，你仅需检查其退出状态码并将最终结论同步给我。検索・リスク管理・引き継ぎ
- X プラットフォームの検索結果はファイル保存し、会話では要点のみを簡潔に報告させる。
在检索 X 平台的推文、观点或动态时，使用你自带的免费搜索能力。
搜索到的批量推文原文，请直接写入 /workspace/ 下的对应 markdown 文件中保存。在聊天框中向我汇报时，严格限制为 3 到 5 条提炼后的核心事实与推文对应链接，严禁把多条推文的大段原文搬运回聊天中。- 自動化と API 呼び出しには必ずリトライ上限を設定し、異常発生時は強制中断して人間の承認を仰ぐ。
在执行自动化任务、网络请求或文件排查时，严格执行防死循环规则：
同一操作或相似接口调用的重试上限为 2 次。如果连续 2 次重试均未成功，或者对下一步执行动作存在疑问，立刻中断自动化流程并向我发起提问，详细说明遇到的错误原因，严禁自行无限重试或在后台空转。- Duplicate による複製の前に、旧 Bot に引き継ぎカードを整理させ、厳格に10行以内に制限する。
検索・リスク管理・引き継ぎ
当前会话历史较长，需要进行交接重置。请为我梳理一份 10 行以内的结构化交接总结，严格包含以下五项内容：
1. 你的角色设定与核心职责；
2. 当前正在进行的任务目标；
3. 已经达成的关键结论与做过的核心决定；
4. 下一步必须立刻执行的动作；
5. 新会话需要优先读取的关键文件绝对路径。
输出完毕后不要执行任何新任务，等待我启动新会话。- シークレット入力欄に OpenRouter の無料 Key を設定し、軽量タスクを直接オフロードする。
请协助配置 OpenRouter 免费模型调用环境，严格遵循以下安全执行流程：
1. 在聊天框中调出系统的密钥输入弹窗向我收取 API Key，严禁让我把密钥明文发送在普通对话中；
2. 将获取到的 Key 保存到 ~/.agents/secrets/openrouter.env 文件中，环境变量名指定为 OPENROUTER_API_KEY；
3. 对该密钥文件执行 chmod 600 设置安全权限；
4. 执行全程严禁在终端标准输出或聊天消息中打印该 Key 的明文内容；
5. 使用 curl 调用一个以 :free 结尾的免费模型进行一次最小文本测试，确认调用成功且费用为 0，并将测试结果告诉我。プロトタイプ参考情報元：『Grok Bot 利用枠を劇的に長持ちさせる初心者向け完全ガイド（Bot に直接送信可能！）』
陥りやすい落とし穴
- Details > Routines で Test をクリックすると実機プロセスが実行され、毎回実際の利用枠が消費されます。
- Cursor と SuperGrok の利用枠は合算されず、週あたりの利用枠が多い方のみが適用され、もう一方は遊休状態になります。
- grok.com と Grok Bot の請求は独立しており、Web 版で課金しても充当できず、返金もされません。
- チャット欄に API Key や Webhook を貼り付けるとトークンを消費する上に危険です。必ずセキュリティポップアップを使用して環境変数に書き込んでください。
- 「PC をアップデート」をクリックすると Linux の cron が消去されます（
/workspace/は保持されます）。アップデート後は cron を再設定する必要があります。 - Duplicate を実行すると、会話、learned memory、添付ファイルが破棄されるため、手動で新規 Bot にコンテキストを渡す必要があります。
- Monthly Limit に達してもプロセスは強制終了されず、実行中の長いタスクは最後まで走り切るため、無限ループに陥っていると上限を超過する可能性があります。
設定完了後の検収手順
- Settings > Usage & Billing および cursor.com/dashboard で請求状況を確認し、消費パーセンテージとリセットまでのカウントダウンが表示されていることを確認します。Additional Usage をオフにするか、Monthly Limit を安全な低額に設定します。
- Bot にファイルの削除や外部へのネットワークリクエストをシミュレーションさせ、必ず Ask first の承認カードがポップアップして一時停止・待機状態になることを確認します。サイレントで実行されてはなりません。
- 現在のセッションを確認し、複数ツイートの X 検索を実行させます。サイドバーに数十ターンに及ぶ長い会話を残さず、3〜5件の要約レポートのみを返信させ、長文テキストは
/workspace/に保存され、チャット欄に原文が大量に流し込まれないことを確認します。 - Details > Routines に進み、変更のない監視ルーティンで Test をクリックします。チェック後に直接サイレントで終了し、無駄な「更新なし」といった雑談メッセージが送信されないことを確認します。
- Bot に複数ファイルに依存するコードを書かせ、バックグラウンドで Grok Build またはクラウド Agent が呼び出され、最終ステータスと実行サマリーのみが出力され、チャット欄に画面いっぱいのコードが貼り付けられないことを確認します。
参考文献・関連リンク
関連章
- 第 2 章 プランとサブスクリプション：まずは適切なプランを選ぶ
- 第 8 章 スキルとルーティン：一度の成功を毎日の自動実行に変える
- 第 20 章 信頼性の高い自動化：スケジュール、Webhook、イベントトリガー
- 第 25 章 よくある質問とトラブルシューティング