エージェントを計測し、
顧客に課金する。
エージェントプラットフォームのための従量課金エンジンです。メトリクス、プラン、サブスクリプション、利用イベント、適応型上限制御、請求書発行まで — Stripeのような一般的な決済ゲートウェイを決済レールとして使い、顧客が自分のユーザーに直接課金できるベンダーモデルを備えています。
ドキュメントを読むエージェントの従量課金は、単なるStripe連携ではありません。
不変の利用台帳、段階的に緩和されるメトリクス単位の上限、按分計算、督促ポリシー、LLMコストのパススルー価格設定、そして毎リクエストにネットワークホップを追加しない上限チェックが必要です。Billing Serverがこれらすべてを担い — Stripeはあくまで決済処理者に過ぎないため、サブスクリプションロジックが二箇所に分散することはありません。
メトリクス
アプリケーションが報告する計測可能な単位 — API呼び出し、1日あたりのメッセージ数、LLMコスト（ドル）— リセット周期は分単位から請求サイクル単位まで、請求サイクルとは独立して設定できます。「月額プランで1日100メッセージ」は設定1行で済みます。
プラン
完全にセルフサービス：基本料金、請求周期、前払い/後払い/ハイブリッド、アップグレードや解約時の挙動、支払い失敗時のポリシー。メトリクス単位の価格設定は、含有単位、単位あたり課金、段階的階層、パススルーに対応 — 実コストを報告してマークアップを適用する、変動するLLM価格に対応した設計です。
サブスクリプション
サブスクライバー（ユーザーまたはアプリケーション）をプランに紐付けます。プランは別の組織が所有するものでも構いません。プランの条件は購読時点でスナップショットとして固定されるため、後でプランを編集しても既存サブスクライバーの条件は変わりません。
利用イベント
不変・追記専用で、冪等性キーを持ち（24時間以内の重複は無視）、7年間保持されます。訂正は編集ではなく新しいマイナスのイベントとして扱われます。
適応型上限
無制限、ソフト（追跡・通知）、ハード（ブロック）に加え、条件付きオーバーライドにも対応：1日の割り当てを使い切ると、急に遮断されるのではなく、分あたりのレートが絞られます。アプリは有効な上限をキャッシュし、サーバーが計算したrecheck_afterヒントに従うため、上限チェックがリクエスト処理のホットパスを塞ぐことはありません。
請求書発行
サイクルごとに、基本料金・利用料・パススルー・調整といった型付きの明細行で生成され、連番が振られ、永続的に保持され、シンプルな日割り計算による按分が行われます。
Stripe + Connect
Stripeがカードデータを保持し（Elements — プラットフォームのサーバーには一切触れません）、PaymentIntentを処理します。Connectは各ベンダー組織を接続アカウントとしてオンボーディングし、そのベンダーのプランへの支払いがベンダー自身のStripeアカウントへルーティングされるようにします。
ベンダーAPI
認証されたアプリケーションが、自身のユーザーを自身のプランに登録できます — 信頼境界はプランの所有権にあり、エンドユーザーのJWTがBilling Serverに届くことはありません。自動プロビジョニングにより、新規ユーザーの最初のAPI呼び出しだけでサブスクリプションが透過的に作成されます。
督促処理まで組み込まれた、リクエストから入金完了までの流れ。
メータリングループ
確認 — アプリはローカルにキャッシュされた有効な上限を参照します。recheck_afterのしきい値に達すると、Billing Serverから再取得します — ハード上限に近いほど頻繁に、遠いほどまれに。
処理と報告 — リクエストが処理され、消費量は冪等な利用イベントとして送信されます。パススルー型メトリクスは単位数ではなく実コストを報告します。
適応 — ソフト上限の超過はWebhookを発火させます。オーバーライドトリガーは関連する上限を自動的に絞り込み、トリガーとなるメトリクスがリセットされると元に戻します。
計算 — サイクル終了時：基本料金 + 単位あたり課金 + 段階的階層 + マークアップ込みのパススルーコストから、含有分を差し引きます。
請求 — 保存された決済手段に対してPaymentIntentが実行され、ベンダーの接続アカウントへルーティングされます。
確定または督促 — 成功すれば請求書は支払い済みとしてマークされます。失敗すればベンダーのポリシーに従い、猶予期間、再試行のスケジュール、延滞、停止、任意の自動解約が進み、各段階で両者にWebhookが送信されます。
プラン、サブスクリプション、利用状況、上限 — そしてベンダー専用API。
台帳のように設計されています — 実際、台帳そのものだからです。
不変の利用記録 — 追記専用で冪等なイベント。7年間保持され、請求書と課金イベントは無期限に保存されます。
変わらない契約条件 — プランのスナップショットにより、プランを編集しても既存サブスクライバーの契約条件は保たれます。
PCIはStripeにとどまる — カードデータがプラットフォームのサーバーに触れることはありません — ElementsとPaymentIntentがそれを保証します。
テナント分離 — ベンダーは自分のプランへのサブスクリプションのみを閲覧でき、サブスクライバー内部の課金情報は見えません。組織のスコープはすべてユーザー入力ではなくJWTから導出されます。
ホットパスを塞がない — サーバーが計算した再確認間隔によるキャッシュベースの上限適用。Billing Serverに一時的に到達できなくても、キャッシュされた上限でサービスを継続できます。
すべての変更に責任の所在 — 実行者情報付きの追記専用課金イベントログにより、紛争対応や監査に備えます。アウトバウンドWebhookはHMACで署名されます。
エージェントの実際のコスト構造に合った価格モデル。
1日100メッセージはソフト上限で、101件目からオーバーライドが分あたりのメトリクスをハード上限2件/分に切り替えます。ユーザーは遮断されるのではなく速度が落ちるだけで、深夜0時に自動解除されます。
アプリがエージェント実行あたり$0.0847のコストを報告すると、プランは最初の$5を含み、残りには実コストに20%のマークアップを乗せて課金します。
$0.02／$0.01／$0.005の階層にまたがるAPI呼び出し15,000件は、正確に$135が課金されます — 各レートはその階層内でのみ適用されます。
AgentOS上にサービスを構築する組織が、自社ユーザー向けに「Pro、月額$29」のプランを定義します。支払いは自社のStripe Connectアカウントへルーティングされ、アプリはベンダーAPI経由で登録のたびに自動的にサブスクリプションを作成します。
31日のうち15日を残して$10から$30へ変更すると、正確に$9.68が日割りで課金されます — 単純な日割り計算だけで、想定外の請求はありません。
一度計測すれば、エージェントが動くすべての場所で課金できます。
利用イベントから入金完了の請求書まで — Billing Serverが全プロセスを担うため、サブスクリプションロジックが二箇所に分散することはありません。