リソースグループのランタイム
SubLane ガイド: リソースグループのランタイム。
これを使用して、ビジーなアカウント、クールダウン、または会話ルーティングを調査します。失敗した通話を初めて確認するには、次のことから始めます。 日常使い.
SubLane は、アカウントを共有するすべてのプールにわたるモデル要求のリースと一時的なアカウント障害を追跡します。管理者は、スケジュール状態を次から検査できます。 アカウント、アカウントごとの制限を変更する スケジュール設定で、完了したすべての呼び出しを検査します。 管理 → すべてのリクエスト。管理者を含む、サインインしているすべてのユーザーには、個人用の 一般→リクエスト ビュー。
入学と親和性
新しいアカウントのデフォルトの同時モデル リクエストは 30 件で、1 ～ 1,000 まで構成可能です。アップグレードでは、保存されたアカウント制限が維持されます。これはローカル ゲートウェイの容量であり、プロバイダーが保証するものではありません。ワークスペース容量のデフォルトは 128 操作 (ウェイターや共有メタデータ読み取りを含む) で、起動時に構成できます。メンバーの同時実行数のデフォルトは 10 で、0 から 1,000 まで設定できます。 0 を指定するとメンバー制限が解除されます。アカウントのリースは、HTTP/SSE にわたるボディの閉鎖、圧縮、および WebSocket ターンまで保持されます。制限を下げると、既存のリクエストが完了できるようになります。
アイドル状態の会話または開いている WebSocket 接続は、ターン間にモデル要求スロットを消費しません。完了した応答は、ボディが閉じるときにスロットを解放します。クライアントがキャンセルされた後、Codex ストリームはスロットを解放する前に最終使用量を収集するために最大 3 秒間読み取りを続けることがあります。構成可能な合計リクエスト期限 (デフォルトでは 30 分) とプロセスのシャットダウンは引き続き適用されます。クライアントがキャンセルを送信せずにリクエストを実行したままにした場合、そのリクエストは終了するかリクエストの期限に達するまでスロットを保持します。
バインドされた会話はそのアカウントを保持します。クライアントが開始した、完全なポータブル履歴を持つ別のモデルへの変更では、現在のアカウントで対応できない場合にサポート アカウントを選択できます。 モデルルーティング 継続制限について説明します。容量と健全性の変更だけではバインディングを動かすことはできません。容量がいっぱいになると、新しいリクエストは最大で待機します。 デフォルトでは 30 秒、最大でも デフォルトではプールごとに 100 の待機リクエスト。アカウント スロットが解放されるか、同時実行制限が増加すると、待機中のリクエストがウェイクアップされます。キューがいっぱいになると、HTTP 429 が返されます。 account_queue_full;期限切れの待機は HTTP を返します 429 account_wait_timeout、両方とも Retry-After: 1。待機およびこれらのローカル拒否によってアクティブなストリームが中断されたり、上流のアカウントの健全性が損なわれることはありません。
待機中のリクエストはメンバーの同時実行数とワークスペースの入場制限にカウントされ、メンバー RPM の許容量を 1 回消費します。許可されるまで、割り当てを予約したり、アカウント スロットを消費したりすることはありません。グループアクセス、モデル ポリシー、メンバーの有効化、キーの有効化/取り消し/有効期限、アカウントの健全性、サブスクリプション クォータおよび許容量が、ディスパッチ前に再度チェックされます。クライアントのキャンセルとサービスのシャットダウンにより、待機中のリクエストが即座に削除されます。待機するとアドミッション ロックが解放され、データベース トランザクションは保持されません。完了した使用状況は、解放されたスロットが別のリクエストで使用可能になる前に記録されます。
クールダウンが戻る HTTP 429 account_cooling 制限された Retry-After ヘッダーを持ち、キューに入れられません。既存の会話を別のアカウントに自動的に切り替えるリクエストはありません。セッションレスまたは新しい会話では、別の対象となるアカウントをすぐに使用できます。バインドされた会話は元のアカウントのみを待機します。サブスクリプション クォータの枯渇、メンバー/ワークスペースの制限、および割り当ての承認エラーには、通常のガードが維持されます。
それなし Session_id または空ではない prompt_cache_key、すべての呼び出しは独立した選択とランダムなアップストリーム相関 ID を取得します。アフィニティ エントリの読み取りや作成は行いません。新しいネイティブ選択は、モデルをサポートする適格なサブスクリプション アカウント間で各プール内でローテーションされます。明示的なレガシー プレフィックスは、選択をプロバイダーに制限します。既存の明示的なデフォルト グループの会話には、履歴ダイジェストが保持されます。
この制限にはモデルのリクエストが含まれます。アカウント検証、モデル検出、およびクォータ読み取りは、既存のグローバル アドミッション ポリシーによって制限されたままであり、モデル要求スロットを消費しません。これらのメタデータ操作では、モデル要求のクールダウンはクリアされません。
合成値を使用したアカウント スケジュールとサブスクリプション クォータ ビューの例:
クールダウンと回復
アカウント全体の冷却は、上流の 429 応答のために予約されています。 Retry-After 1 ～ 3600 秒以内に受け付けられます。存在しないか無効な場合、構成可能なフォールバックはデフォルトで 5 秒になります。資格情報の更新の失敗には独自のバックオフがあります。リクエストの期限、HTTP 408、および不明なネットワーク障害によってアカウント全体が冷却されるわけではありません。
明示的なアップストリーム 5xx 応答と無効/中断されたストリームは、選択したアカウントとモデルに対してカウントされます。デフォルトのしきい値は、2 分以内に 3 つの論理障害が発生し、その後 10 秒間のモデルのクールダウンが続きます。失敗が繰り返されると、遅延が最大 5 分増加します。しきい値、ウィンドウ、および初期期間は構成可能です。しきい値を 0 にすると、一時的なモデルのクールダウンが無効になります。他のモデルも引き続き対象となります。通常の回復リクエストが成功すると、該当する状態がクリアされます。結果が遅いと、新たな障害を解決できません。既存の構造化された Antigravity モデルのレート制限は、範囲指定されたリカバリ ルールを保持します。
成功したアップストリーム応答を受け入れる前に、明示的な HTTP 408、500、502、503、および 504 の拒否が、制限されたバックオフを使用して同じアカウントで 2 回再試行される可能性があります。再試行では、現在のメンバーシップ、キー、グループ/モデル ポリシー、クォータ、アカウント ライフサイクル、およびコンテンツ ルールが再確認されます。 1 つのリース、リクエスト ID、履歴記録、および最終決済を保持します。長い上流の再試行ヒントは、早期に再生されずに返されます。ネットワークの不確実性、400/401/403/429、受け入れられたストリームおよび部分的な出力は、このメカニズムによって自動的に再生されません。既存の明示的な 401 認証情報の更新の試行は別個に行われます。
HTTP SSE は、アップストリーム イベントの読み取りが継続している間、10 秒ごとにコメント ハートビートを送信します。オプションのストリーム アイドル タイムアウトでは、アップストリーム イベントのみがカウントされます。ダウンストリーム ハートビートでは、停止したモデルを隠すことはできません。デフォルトではオフになっています。推論ヘッダーのタイムアウトはデフォルトで 5 分に設定され、メタデータはその短いタイムアウトを維持し、合計リクエスト/ターン タイムアウトはデフォルトで 30 分に設定されます。見る 導入構成.
管理者は、アカウントを有効にしたり、認証を更新したり、サブスクリプション割り当てを復元したりせずに、クールダウンをクリアできます。既存の会話は元のアカウントを保持します。アカウント/モデルのクールダウンは再起動後も継続します。アップグレードすると、実際のレート制限を維持しながら、モデルの範囲が不明であった従来のアカウント全体の一時的なペナルティがクリアされます。
資格情報の更新と回復
Codex 認証情報は、有効期限が切れてから 2 分以内にオンデマンドで更新されます。その更新が一時的に失敗した場合、残りが 30 秒以上あり、アップストリームによって拒否されていない間のみ、既存のアクセス トークンを使用してリクエストを続行できます。更新試行後に有効期限が再度チェックされます。 Claude および Antigravity は、既存の有効性要件を保持します。
更新試行が失敗すると、アカウント固有の再試行遅延が発生します: 30 秒、1 分、2 分、4 分、最大 5 分。より長い OAuth Retry-After 最長 1 時間まで尊重されます。遅延が経過すると、次の資格情報の読み取りまたはモデル要求を再試行できます。追加のバックグラウンド ポーリング ループはありません。他のアカウントは独自の再試行スケジュールを保持します。
使用可能なトークンが残っていない場合、モデル リクエストは返されます。 503 account_refresh_failed と Retry-After。更新の失敗によってモデル呼び出しのクールダウン ペナルティが蓄積されることはありません。更新または再認証が成功すると、更新再試行状態がクリアされます。再試行の遅延はプロセスローカルですが、アップストリームの拒否は暗号化された資格情報とともに保存されるため、再起動によってそのトークンが再びフォールバックの対象となることはありません。
Codex トークン エンドポイントは、次のような明示的な資格情報の失敗を返す必要があります。 invalid_grant または refresh_token_reused、再認証を要求します。不明な HTTP 400/401、プロキシ応答、または共有 OAuth クライアント構成エラーだけでは、アカウントは再認証が必要であるとマークされません。更新されたトークンが依然としてモデル エンドポイントによって拒否されている場合は、引き続き再承認が必要です。既存の会話は、回復中もアカウントのバインドを維持します。
クォータを意識した選択
Codex、Claude、および Antigravity モデル トラフィックは、プロバイダー IO を待たずに、適格なプール アカウントの共有バックグラウンド クォータ更新を開始します。ワークスペース アドミッション スロット内で同時に実行されるクォータ読み取りは最大 2 つです。重複した読み取りは結合され、既存のクールダウン/バックオフ ルールが適用されます。一般的なアイドル ポーリング ループはありません。マネージド共有リソースは、リクエストの完了後も制限付き再試行を実行して、最後のリクエストの後など、待機中の使用状況を調整します。見る 和解と休止。 Claude メイン ウィンドウでは、枯渇したアカウントを除外できます。 Antigravity は、正規化された SDK 思考サフィックスを使用して、要求された正確なネイティブ モデルのみをチェックします。他のモデルは引き続き対象となり、アカウント全体のランタイム状態は引き続き利用可能になります。
Codex および Claude の場合、選択は永続化された正規化された値を読み取ります。 主要 プール ポリシーおよびアフィニティと同じ短いトランザクション内のサブスクリプション制限。明示的な拒否、制限に達したフラグ、または 100% 使用済みのウィンドウは、観察が新しい間 (2 分、リセットにより短縮されます) のみ、新しい選択からアカウントを除外します。不明なデータ、古いデータ、将来の日付のデータ、またはすでにリセットされたデータは、クォータがゼロであることを意味するものではありません。追加の名前付き制限はモデルにマップされるとは想定されていないため、アカウント全体を除外することはできません。低いがプラスのクォータは、ラウンドロビンの重みを変更しません。失敗した更新では、最後に成功した観察が保持されます。スケジュールに影響を与えることができるのは、元の鮮度期限までのみであり、無期限に影響することはありません。
アカウントまたは要求された Antigravity モデルが枯渇したバインドされた会話は、HTTP 403 を返します。 quota_exhausted。スナップショットの鮮度/リセット期限が経過すると、プロバイダーが再度チェックされます。その時期に達したからといって、手当が回復するという保証はありません。別のアカウントに移動することはありません。クォータの拒否によって一時的な障害が増加することはありません。 クールダウンをクリアする サブスクリプション割り当ては消去されません。アカウントには、明確なクォータを使い果たしたスケジューリング状態が表示されます。
成功した観察は公開前に保存され、再起動後も存続します。クォータ行には、既存のアカウントのライフサイクル リビジョンが含まれます。無効化/有効化および再認証は以前の観察を無効にし、条件付き書き込みは古い実行中の更新を拒否します。統合スキーマには、ライフサイクル リビジョン メタデータとクォータ行およびリクエスト診断が保存されます。
最近のリクエスト記録
記録には、アカウント容量/クールダウンの拒否を含む、ゲートウェイ スケジュールに達する認証済みモデルの試行が含まれます。認証失敗、HTTP 本体/コンテンツ タイプ検証失敗、グローバル アドミッション拒否、モデル検出、クォータ クエリ、および WebSocket プリウォームでは、モデル呼び出しレコードは作成されません。
保存されるメタデータは、ユーザー/キー/プール/アカウント ID、プロバイダー、境界モデル識別子、プロトコル/操作、開始時間、期間、リクエスト相関 ID、NULL 許容の最初の出力レイテンシー、結果、サニタイズされたエラー コード、アップストリーム HTTP ステータス、および報告された入力/出力/キャッシュされたトークン数に限定されます。プロンプト、応答本文、生のプロバイダー エラー、ヘッダー、IP アドレス、セッション ID、資格情報は記録されません。欠落しているトークン数は null のままです。カウントは、観察された個々の反応を表します。これらは請求や利用枠台帳ではありません。独立した毎日の概要とメンバーのリクエスト制限については、次のセクションで説明されています。 チームコントロール。ストリームには HTTP 200 があってもエラーで終了する場合があるため、結果とアップストリームのステータスは異なります。
個人レコードは、ページネーションの前に SQL で認証されたセッション ユーザーによってフィルタリングされます。クライアントが指定したユーザー ID またはスコープではアクセスを拡張できません。サブスクリプション アカウント ID と名前は、個人 API 応答でクリアされます。ユーザーは、結果、正確なモデル、API キー、リクエスト ID、時間間隔によって自分の履歴をフィルタリングできます。これには、その後取り消されたキーを介した通話も含まれます。管理者は、メンバーおよびサブスクリプション アカウントごとに個別にフィルターできます。呼び出し元オプションは、同じ所有権スコープ内で保持されている履歴からのみ派生します。どちらのビューも 50 のバッチでページ分割されます。7 日間のウィンドウ内に最大 5,000 件のレコードが保持されます。クリーンアップは、記録時および履歴の読み取り時にアトミックに実行されます。アイドル データは、次回の同様の操作で再利用されます。単調レコード ID は、保持クリーンアップ後に再利用されません。削除されたアカウント名は、履歴メタデータを削除せずに、削除済みとして表示されます。
個人および管理者のリクエスト テーブルには、キャッシュされたトークン数の横に入力トークン キャッシュ ヒット率が表示されます。これは、キャッシュされた入力トークンを合計入力トークンで割ったもので、小数点以下 1 桁までのパーセンテージとしてフォーマットされます。これは、キャッシュにヒットしたリクエストのシェアではなく、アップストリーム キャッシュから提供される入力トークンのシェアを測定します。正の入力でレポートされたキャッシュ数が 0 の場合、0% が表示されます。カウントが欠落している場合、入力がゼロである場合、またはキャッシュ カウントが合計入力を超えている場合は、em ダッシュが表示されます。レートは既存のリクエスト メタデータから導出され、格納された列やアップストリーム リクエストは追加されません。
新しいモデルを試行するたびに、サーバーによって生成された req_… 識別子。発信者が指定した ID は無視されます。 HTTP 応答はそれを返します X-Request-ID; WebSocket ターン追加 request_id 作成/完了/不完全なイベントとゲートウェイ エラー。アップストリーム応答 ID は変更されません。アップグレード前のレコードには相関 ID も最初の出力測定もありません。リクエスト テーブルには、各開始時刻の下にコンパクト ID が表示され、完全な値のコピー アクションが示されます。開始時間をクリックすると、完全な ID を含む詳細が開きます。
first_token_ms メジャー ゲートウェイ処理は、スケジューリングと上流の待機を含め、最初の空ではない正規化テキスト、推論、推論の概要、またはツールの引数デルタから開始されます。最初のライフサイクル イベントまたはクライアントによってレンダリングされたトークンの時期ではありません。圧縮、観察されたデルタのないストリームと古いレコードは null のままです。 UI がそれを呼び出す 最初の出力。合計持続時間は依然として体の閉鎖をカバーします。
合成レコードを使用した個人リクエスト診断の例:
API とストレージ
GET /api/accounts/runtime: 現在のスケジューリング状態とモデルリクエスト数。PATCH /api/accounts/{id}/limits： セットmax_concurrency(1 ～ 1,000 の整数)。POST /api/accounts/{id}/resume: クールダウン/失敗を明示的にクリアします。GET /api/me/requests?cursor=0&outcome=: いずれかの有効なロールの現在のユーザーのリクエスト メタデータ。GET /api/requests?cursor=0&account_id=&outcome=: 管理者リクエストのメタデータ。結果は、成功、不完全、エラー、キャンセル、拒否のいずれかになります。
両方の履歴エンドポイントも受け入れます model, request_id, key_id, from (Unix秒を含む)および until (排他的な Unix 秒);管理者エンドポイントは受け入れます user_id。要求された範囲に関係なく、保存期間は 7 日間のままです。 GET /api/me/requests/filters および管理者のみ GET /api/requests/filters サブスクリプション ID やシークレット値を含まない、制限された呼び出し元/キーの選択肢を返します。
明示的に個人履歴エンドポイントを除いて、これらのルートには有効な管理者セッションが必要です。突然変異は、origin/JSON の保護を保持します。統合スキーマは、ワークスペースをスコープとしたランタイム テーブルと履歴テーブルを作成します。停止したデータベースをバックアップし、 credentials.key 開発用インストールを置き換える前に、一緒にインストールしてください。
モデル固有の制限
明示的な構造化された Antigravity レート制限応答は、エラー ドメイン、理由、およびモデルが選択した要求と一致する場合にのみ制限されます。不明な 429 応答はアカウント全体のクールダウンを保持します。モデル制限は再起動後も維持され、現在のアカウントのライフサイクルに属します。再認証、無効化/有効化、および手動クールダウンのクリアにより、以前の状態が無効になります。
限定モデルが帰ってくる 429 model_cooling;元のプロバイダーの制限は次のように報告されます 429 model_rate_limited。どちらも制限付き再試行ヒントを保持します。他のモデルは引き続き使用可能であり、既存の会話は元のアカウント バインドを保持します。クールダウン後、そのモデルに対する通常のリクエストは一度に最大 1 つずつ回復を試みます。追加の推論プローブは送信されません。古い成功や無関係な成功によって、新しい制限を消去することはできません。永続化の試行が失敗すると、現在のプロセスに制限が残り、永続化の失敗として記録されます。
アカウント カードには限定モデルの数が表示されますが、アカウント全体のスケジュールは引き続き利用可能です。 スケジュール設定 → クールダウンクリア 有効化、認可、またはサブスクリプション割り当てを変更せずに、アカウントとモデルのクールダウンをクリアします。アップストリーム HTTP 403 は次のように報告されます。 upstream_forbidden、再承認のリクエストではなく。
Codex の自動承認レビュー
guardian または review と識別された codex-auto-review リクエストでは、整合する親スレッドのメタデータを使い、同じ認証ユーザーとリソースグループ内で親の会話のアカウントを優先できます。既存の子セッションの紐付けが優先され、候補アカウントにはモデル対応、権限、クォータ、利用割当、同時実行容量の確認が引き続き適用されます。親の情報が欠落、矛盾、不明確、期限切れ、または利用不可の場合は通常の選択に戻り、親の紐付けは変更しません。親とレビューのセッション ID およびキャッシュ ID は独立しています。HTTP と WebSocket のルーティングは合成データでテスト済みですが、実際の Codex クライアントでの受け入れは未検証です。
残りクォータによる新規会話の振り分け
SUBLANE_GATEWAY_QUOTA_WEIGHTED=true で、最も制約の厳しい期間の残り割合に応じて振り分けます。同じ優先順位の全候補が同一の対応プロバイダーに属し、新鮮で完全な数値を持つ場合だけ適用します。Antigravity は指定モデルのみを参照します。不明、古い、不完全、混在データでは均等のままです。
初期値は無効で、変更には再起動が必要です。既存の会話、親アカウント優先、権限、割り当てと同時実行の検査は維持します。割合は振り分けの目安であり、プラン間の絶対容量の比較ではありません。