メインコンテンツへスキップ
リトライループにスタックしたり、1000 のサブタスクにファンアウトしたり、あるいは単に プラン途中で暴走したりする推論エージェントは、誰かが気づく前に本当のお金を使えます。 cap_cost ファイアウォール判定はそのためのサーキットブレーカーです：実行ごとの セント上限を一度作成すると、ゲートウェイは実行の累積支出がそれを超えた瞬間に次の ツール呼び出しを deny します — その呼び出しがモデルやツールに到達する前にです。 これはエージェントループにボルト留めされたのではなく、ゲートウェイで強制される AI エージェントのコスト制御です。すべてのファイアウォール 判定と同様に、cap_cost ルールはワークスペース ポリシーに存在し、キーにアタッチされ、再デプロイなしで次の呼び出しから効力を持ちます。

​
1. 実行ごとの支出サーキットブレーカー

cap_cost は、1 つの追加フィールド — cap_cost_cents、実行の支出上限を USD セントで — とともに作成するルール判定です。ルールがツール呼び出しにマッチすると、エンジンは エージェント実行の累積支出をその上限と比較します：
  • 上限未満 → 呼び出しは許可されます；評価が続きます。
  • 上限超過 → 呼び出しはdeny されます。実行の合計と上限を名指しする理由が 付きます。それが終端の、サーキットブレーカーの結果です — 実行は新しい実行まで別の 統制された呼び出しを発行できません。
上限はエージェント実行にキー付けられ、単一のリクエストではありません。すでに 予算のほとんどを燃やした長い実行は、その 1 つの呼び出しが安くても次の呼び出しで deny されます — ブレーカーは限界コストではなく累積合計でトリップします。
実行スコープ、リクエストごとのフォールバック付き。 リクエストがエージェント実行 id を運ぶとき、上限は実行の累積支出に適用されます。実行の関連付けのない呼び出し （例：転送されたセッションのない裸の MCP ディスパッチ）は、代わりにリクエストごとの 比較にフォールバックします。いずれにせよ、ブレーカーは予算超過の呼び出しがディスパッチ される前にトリップします。

​
2. 具体例 1 つ

キー上の任意の実行を $5.00 の累積支出で上限します。単一のワイルドカードルールが それを行います — cap_cost_cents は 500（セント）です： 
{
  "label": "run cost ceiling $5",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
作成したポリシー上のコンソールのルールエディタでそれを作成します （ポリシーの作成 & アタッチを参照）。ルールの 書き込みは Developer+ のアクションです。ポリシーを firewall_policy_id 経由で キーにアタッチするか、ワークスペースデフォルトにすると、そのキーが駆動するすべての 実行が今や境界づけられます。 上限を「すべてのツール」より厳しくスコープできます。ツール名 グロブを絞り、高価なファミリーの呼び出しのみが ブレーカーにカウントされるようにします — 例えば *.search 上の cap_cost で、安価な ローカルツールを計測しないまま Web 検索のファンアウトを境界づけます。
優先度でより安価な警告ティアをスタックします。より高い優先度（より低い番号）の低い 上限の audit ルールは、強制 cap_cost ルールが トリップする前に、実行が予算に近づくのをevents フィードで 監視させます。最初にマッチしたものが勝つため、ウォッチャーを先に並べます。

​
3. どこで発火するか — そしてどこでできないか

cap_cost は呼び出しがディスパッチされる前にのみ意味を持ちます — それが呼び出しを 止めることで依然として支出を防げる唯一のポイントです。そのため、2 つのディスパッチ前の サーフェスでライブであり、ディスパッチ後のものでは 拒否されます：
サーフェスcap_cost？
inbound（アドバタイズされるツール）強制。
mcp（tools/call ディスパッチ）強制。
response（モデルが発行する呼び出し）保存時に拒否 — 止めるものが残っていない。
egress（アウトバウンド宛先）保存時に拒否 — 止めるものが残っていない。
response または egress に固定された cap_cost ルールは保存時に拒否されるため、 ルールがライブとして表示されながら deny できないということは決してありません。 両方のディスパッチ前サーフェスをカバーするにはステージを空のままにするか、 inbound / mcp に固定します。
cap_cost_cents は cap_cost ルールに対して必須かつ非負です。コンソールと API は 上限のない cap_cost ルールを拒否するため、設定を誤った上限がすべての呼び出しを サイレントに通すことはできません。

​
4. ブレーカーがトリップしたときどう見えるか

予算超過の呼び出しは通常のファイアウォール deny です：
  • inbound では、リレーはエラーコード firewall_blocked の HTTP 400 を返します。 ブロックはアップストリームのモデル呼び出しの前に発火するため、モデルトークンを 消費せず、skip-retry とマークされます — 同じ呼び出しを再実行してもまた ブレーカーがトリップするだけです。
  • mcp では、ツールエラーとして返ってくるため、モデルは拒否を見てクラッシュする のではなく停止したりユーザーに尋ねたりできます。
deny 理由は数字を名指しします。例：cap_cost: estimated run cost $5.40 exceeds cap $5.00。そのためevents フィードを読むオペレータは、 ブレーカーがなぜトリップしたかを正確に見られます。
events はリテラルの cap_cost を決して運びません。 判定を cap_cost として 作成しますが、エンジンはイベントが記録される前にそれを具体的な allow または deny に解決します。フィードはエージェントが実際に見た allow/deny を表示します — 実行コスト上限は判定ラベルではなく理由です。これは判定がどう 解決するかを 反映しています。

​
5. 安全にロールアウトする

トリップしたブレーカーは実行をハードに止めるため、強制する前に検証します。ポリシーで シャドウモードをオンにします：cap_cost ルールは 依然として評価し、deny になるはずのものが audit に格下げされ、[shadow] would … が 前置されます。events フィードを監視して、上限が期待する場所で — そして期待する場所 のみで — トリップすることを確認してから、シャドウモードをオフにして強制を開始します。 Test タブ（Developer+ サンドボックス）で サンプル呼び出しに対してポリシーをドライランし、何かが依存する前に解決された判定と マッチしたルールを見ることもできます。

​
6. ファイアウォールの残りとどう収まるか

cap_cost は 6 つの中のひとつの判定です。同じポリシー上の他のコントロールと自然に 組み合わさります：

判定

完全なセット — allow、audit、deny、sanitize、pending_approval、そして cap_cost が どう解決するか。

危険なツールをブロック

破壊的シェル、削除、その他の高リスク呼び出しを完全に deny。

ルールリファレンス

完全なマッチング言語 — グロブ、引数句、シーケンス。

異常検出

学習された曜日内時間ベースラインに対してフラグされるコストのスパイク。
実行コスト上限は静的で決定論的なバックストップです；ファイアウォールは各ワークスペースの 通常のコストの形も学習し、14 日間の曜日内時間ベースラインに対するスパイクを Member 可読の異常フィードでフラグします。ハードな停止には cap_cost を、早期シグナルには 異常を使います。
キー自体のクォータ制限（credit_limit_usd）はすべての実行をまたいだ総支出を境界 づけます；cap_cost は単一の実行を境界づけます。それらは合成されます — 暴走ループは キーの生涯クレジットを使い切るずっと前に実行ごとのブレーカーをトリップします。 スコープ：キー、ポリシー、ワークスペースを 参照。

​
次に進む場所

ポリシーの作成 & アタッチ

ポリシーを作り、デフォルト判定を選び、キーにバインドします。

シャドウモード

上限がトラフィックを変える前に測定します。
支出上限がバックストップする暴走エージェントの脅威については、 過剰なエージェンシーと 危険なツール呼び出しを参照してください。