リソース引当会計

予算、直接制限、リセット期間、保留中の使用量を共有します。

から始める利用枠セットアップ用。ルールは、1 つのワークスペース内の 1 つの専用リソースグループに属します。ルールが存在する限り、そのアカウントのメンバーシップは固定されたままになります。メンバーには、直接プール許可とルールにバインドされた個人キーが必要です。通常のキーは自動的に変換されません。ルールの 1 人のメンバーのキーはすべて 1 つの台帳を共有します。

割合で指定は日次・月次の総予算、または最大 8 個の経過時間ウィンドウごとの総予算を扱います。合計 100% 以下の共通メンバー比率をすべてのウィンドウに適用し、トークンまたは内部 USD を基準に計測します。

トークンシェアごと: 合計を M トークン単位で入力します。報告された入力トークンと出力トークンは、各メンバーのシェアに対してカウントされます。キャッシュされた入力は入力の一部であり、2 回カウントされません。
金額シェア別: 内部合計 USD を入力します。各リクエストの入力、キャッシュされた入力、出力は、そのルールリビジョンで保存されたモデル価格を使用して変換されます。これらの価格には、プロバイダーのサブスクリプションの課金方式が記載されていません。

各ウィンドウの個人上限は、その総予算に比率を掛けて最小計測単位に切り捨てた値です。例えば 1 M トークンの 25% は 0.25 M です。正の比率がゼロに丸められる設定は拒否します。未分配分や丸めの余りを自動で貸し出しません。受付は個人上限とグループ総予算の両方を検証し、元メンバーの消費も含めます。アカウントごとに残枠をリセットすることはありません。

これらは 内部予算。構成されたトークンの合計からはサブスクリプションの実際の容量は明らかにされません。また、内部 USD は現金残高や請求書ではありません。 SubLane は、利用可能なアップストリームクォータを引き続きチェックします。プロバイダーは、内部予算が使い果たされる前にリクエストを拒否する場合があります。

時間枠の金額制限

時間枠ごとは別の割り当て方式です。整数の時間・日数（1 時間から 365 日）と内部 USD の共通上限を最大 8 条件まで設定します。各メンバーを独立して記帳し、条件を個人別に上書きできます。上限が空欄の条件は無制限で、利用量を記録しますが枠制限や仮の予約量は設けません。確定したリクエストは保存価格で一度だけ計価し、全ウィンドウに計上します。有限の条件が枯渇した場合や予約量の余地がない場合は新規受付を止めます。

経過時間ウィンドウは有効化の起点から固定の長さで独立して更新します。5 時間枠のリセットで 7 日間の利用量は消えません。過去を遡るローリング枠ではなく、上流のサブスクリプションのリセットにも追従しません。インスタンスのタイムゾーンは表示だけに影響します。

メンバー編集と予約変更

「現在のメンバーを編集」で比率や個人上限を直ちに変更できます。確定済み利用量と受付済みリクエストの予約量は残ります。増額は現在の共有ウィンドウすべてで予算に収まる必要があり、削除・再参加でも利用量は消えません。総予算 100 で A が 40 消費済みなら A/B/C 各 33 は 106 必要なので拒否し、40/30/30 は収まります。更新後も全ウィンドウを再検証し、通常の予約変更で不足を回避することはできません。

予算、ウィンドウの既定上限、価格は既存の予約時刻、なければ現在の計画の次の境界で反映します。複数ウィンドウでは現在の最長期間の次の境界を使います。起点と利用量を維持するため、短い枠が途中であれば減額後に枯渇することがあります。過去のリクエストを新価格で再計算しません。

通常の予算・価格編集は保存済みのメンバー設定をそのまま維持し、権限一覧から消えた受領者も勝手に削除しません。設定の保持はアクセス権の復活ではなく、新規受領者と新しい構造の期間には現在のグループ権限が必要です。

次のバージョンに独立したメンバー計画がある場合、即時変更の自動反映は競合として拒否します。その予約を明示的に見直すか取り消してください。他の互換な予算・価格予約は維持します。バックグラウンド更新で古い下書きに新しいバージョン条件を付け替えず、競合後は「更新して確認」を使います。

単位、割り当て方式、リセット計画の変更は、実際に構造が異なる置換として明示確認します。ルール・グループ・Key の ID を維持し、予約反映時刻を新しい計測起点にします。メンバーや価格だけの変更では新期間を要求できません。

「次の境界まで延期」は保存済み反映時刻より厳密に後の最初の自然境界だけに移します。現在の計画を使い、初回の有効化前は初期予約の計画を使います。サーバー時刻を確認してから確定し、条件の失効・変化は競合として返します。

「予約変更を取り消す」には現在有効なバージョンが必要です。初期予約しかない場合は一時停止または延期を使います。初期予約の延期は単一トランザクションで置換します。一時停止は予約時刻や読める設定を消さず、その後に初期版が有効になってもアクセスを拒否したままです。

初回の有効化前のメンバー修正には完全な編集画面（PATCH /api/allocations/{id}）を使います。確認済みのバージョン対と反映時刻が必要で、保存済み時刻と計測起点を保持し、対象メンバーの現在のグループ権限を再検証します。現在版も記録済みリクエストもない初期予約だけが対象です。版・メタデータ・監査を一つのトランザクションで保存し、失敗や有効化時刻の通過では全体を戻します。初期予約の取消は禁止のままです。

承認済みの次版が現在版と本当に異なる構造なら、下書きが次版の構造を維持していても既存の新期間確認を表示します。再確認すると予約対象のメンバーを編集できます。通常の予算・価格編集は再確認せずメンバーと起点を維持します。この任意の再確認を外すと、保存済みメンバー計画を表示し送信します。置換には現在版との実際の構造差が引き続き必要です。

有料手当の場合 (金額別, 金額シェア別、そして 時間枠ごと)、SubLane は専用プールでサポートされているモデルを読み取り、リビジョンを保存するときにカタログ価格を設定します。ユーザーが指定した価格は、このスナップショットをオーバーライドしません。モデルに現在のカタログ価格がない場合は、以前に保存されたレートが利用可能なときに再利用されます。価格のない新しく検出されたモデルはスナップショットから省略されるため、価格の改訂が有効になるまで、そのモデルへのリクエストはブロックされたままになります。価格カバレッジの警告は、リビジョンには保存されず、ルールが読み取られたときに計算されます。復元されたカタログ価格はカタログ警告を自動的にクリアしますが、保存された価格スナップショットに存在しないモデルには、新しいリビジョンにそのモデルが含まれるまでフラグが立てられたままになります。使用できないアカウントカタログでは、以前に保存されたレートが保持され、検出が回復するまで警告が表示されます。保存は、使用可能な価格が残っていない場合にのみ失敗します。ロードされた価格カタログまたは保存された価格キャッシュがなければ、新しい価格付き許容量を作成することはできません。再試行する前にカタログを更新するか、価格のフォールバックを提供してください。

保存価格にないモデルについては、今保存した修正版の反映予定時刻を管理者に示します。時間枠では現在の最長期間の次の境界を使うため、保存を繰り返しても価格は即時に利用可能になりません。既存予約があればその反映時刻を表示し、修正版で置換しなければ有効化後も対象モデルを拒否すると警告します。

直接制限と保留中の使用量

トークンによる メンバーのトークン制限を直接設定します。 金額別 保存されたモデル価格を使用して直接内部 USD 制限を設定します。どちらも、対応する株式ベースとして同じトークンまたは価格会計を使用します。

信頼できる最終利用量は上流の割合更新を待たずに確定します。総量が不明なら修正待ちとし、部分的な観測値を表示しますが、消費や予約量には計上しません。実行中は受付時の個人上限の 10%（最低 1 単位）を各有限ウィンドウで仮予約し、後の編集では変えません。各有限ウィンドウ内では同一メンバーの当該枠の実行中リクエストを最大 4 件とし、共有予算ではグループ全体も検証します。終了時に仮予約を解放します。大きなリクエストの超過や利用量不明は残るため、これはソフト上限です。最新 256 件の修正待ちを先に表示します。計測の所属時刻は待ち行列後の受付成功時刻で、診断の所要時間は到着から計ります。

Codex ストリームの場合、SubLane はクライアントが切断された後、信頼できる最終的な使用状況を取得するために最大 3 秒間アップストリームの読み取りを続ける場合があります。完全な使用量を含む失敗した端末イベントにも課金することができます。アップストリームの障害が繰り返されると、影響を受けるアカウントが一時的に冷却されます。最終的な使用を伴わない成功した応答は、アカウントを冷却することなく保留されたままになります。アカウンティング書き込みが一時的に失敗した場合、SubLane は、影響を受けるメンバーに対してさらに手当を裏付けとする作業を許可する前に、そのリクエストを再試行します。他のメンバーは続行できます。

日次・月次のリセットはインスタンスのタイムゾーンで指定した日時を使い、存在しない月日は月末に合わせます。既定は毎日 00:00 または毎月 1 日 00:00 です。通常編集は計測起点を維持します。一時停止や権限取消は以後のリクエストと WebSocket ターンを止めますが、履歴を消しません。上流の再取得、リセットカード、再認証、再起動でローカル予算は補充されません。

選択する 次の期間を開始する 時間枠ルールを作成する場合、設定された最長期間の後に開始されます。

残高を読んで修正する

メンバーは自分の手当を以下で確認できます 使用法。ワークスペース管理者が開く 利用枠 → 使用量の表示 完全なルールについては。構成されたすべての時間ウィンドウは、独自の制限、使用量、残量、リスクエクスポージャー、およびリセットの瞬間とともに 1 つのメンバーの下に表示されます。メンバーのステータスは最も制限的な条件を反映しています。金額残高には、報告されたトークンとともに内部 USD が表示されます。トークン残高には M が使用されます。 1 M = 1,000,000 tokens。個人レポートでは、サブスクリプションアカウントの ID が公開されることはありません。

バランスが分離します 使用済み 現在のサイクルでの処理中のリクエストと保留中の使用量からの（解決済みの使用量）。一時的な予約には機内のリクエストのみが反映されます。保留中の使用量は修正のために表示されたままになり、使用済みの許容量または予備容量としてカウントされません。アドミッションヘッドルームには自動リスクバッファーが含まれます。それは余分に使えるお小遣いではありません。したがって、プラスの残存許容量が一致する可能性があります。 新しいリクエストは一時的に停止されます 別のリクエストが現在のヘッドルームよりも多くの予約を必要とする場合、または 4 つのリクエストがまだ実行中の場合。ステータスは、ゲートウェイ許可と同じ現在のサイクルのリスクチェックに従います。これはスナップショットであり、リクエストが完了すると変更される可能性があります。現在のサイクル外の保留中のレコードは、修正のために表示されたままになりますが、承認は一時停止されません。

保留中のエントリを自動的に解決できない場合、管理者は信頼できる証拠によって裏付けられた入力、出力、およびキャッシュされた入力の合計を入力できます。修正では、リクエストの保存されたアカウンティングルールが使用され、監査イベントが書き込まれます。不足している使用量をゼロとして扱ったり、架空の合計を入力したりしないでください。

ワークスペース管理者は、次の場所でルールを管理します。 /api/allocations;メンバーは自分の残高を次の場所で読み取ります。 /api/me/allocations。キーはルールにバインドされます scheme_id。見るワークスペースそして個人用 API キー.

API 書き込み条件

読み取りの既存形式は維持し、write_conditions に null を許す expected_current_revision_id と expected_next_revision_id を追加します。既存ルールの完全な PATCH、メンバー変更、取消・延期、構造置換には両方が必須です。欠落・古い条件は HTTP 409 で、設定を変更しません。新しい ID を取得して古い下書きを自動再送せず、内容を再確認してください。個別の有効化・停止とリクエスト単位の修正は既存契約を維持します。

将来版の書き込みにはサーバー確認済み UTC 秒の expected_effective_at が必要で、構造置換には confirm_replacement=true も必要です。POST /api/allocations/{id}/preview の操作は schedule、reschedule、replace。メンバーは POST /api/allocations/{id}/members、予約操作は POST /api/allocations/{id}/cancel、POST /api/allocations/{id}/reschedule を使います。有効・無効は完全保存で変更せず POST /api/allocations/{id}/enabled を使います。

初回作成で時間条件を省略すると従来の即時・遅延開始を維持します。expected_effective_at を送る場合は start_next=true が必須で、暦の開始は次の境界に一致し、経過時間の開始は現在より未来かつ最長期間以内である必要があります。明示的な null は必須条件の欠落として 409、不正形式は 400、失効・変化は 409 です。POST /api/allocations/preview は初期時刻を返すだけで作成せず、確認失敗を無条件作成に切り替えません。