チームの使用量と制限

リクエストと使用状況の確認については、次から始めてください。 日常使い。パスワードの回復、リクエストの制限、および詳細な統計については、このリファレンスを使用してください。無料の共有アクセスには、追加の制限構成は必要ありません。

パスワードのライフサイクル

どちらの役割も開くことができます 環境設定 → パスワードの変更。現在のパスワードが必要です。新しいパスワードには 8 ～ 20 文字の Unicode 文字が含まれている必要があります。最初のワークスペースのプラットフォーム管理者は、次のワークスペースを開くことができます。 メンバー → その他のアクション → パスワードをリセット 障害のある会員を含む会員の場合。無効化されたメンバーをリセットしても、そのアカウントは有効になりません。

変更が成功すると、Argon2id ハッシュがアトミックに置き換えられ、現在のセッションを含むそのユーザーのすべてのブラウザ セッションが取り消されます。他のユーザーはサインインしたままになります。パスワードの検証とセッションの作成では同じハッシュが再チェックされるため、古いパスワードを検証したログインは同時リセット後にセッションを作成できません。パスワードの変更では、同一生成元/JSON チェック、既存のピア/グローバル認証スロットル、および制限付きハッシュ ワーカー数が保持されます。

ゲートウェイ API キーには独立したライフサイクルがあり、有効なままです。必要に応じて、影響を受けるキーを個別に取り消します。メンバーを無効にしても、すべてのキーは引き続き一時停止されます。管理者 API によってパスワードやハッシュが返されたり、ブラウザのストレージに保存されたりすることはありません。パスワード フォームを閉じると、保留中の変更データが破棄されます。

管理者がサインインできない場合は、ローカル回復コマンドを使用します。インスタンスを停止してデータベースをバックアップし、 credentials.key まずは一緒に。ポイント SUBLANE_DATA_DIR 既存のインスタンスで、標準入力 (プライベート ファイルなど) を介して新しいパスワードを指定します。

SUBLANE_DATA_DIR=/path/to/data ./bin/sublane reset-admin-password --password-stdin < /secure/path/new-password

入力ファイルは所有者のみが読み取り可能な状態にしておき、使用後は削除してください。このコマンドは 1 行を受け入れ、コマンドライン引数にパスワードを取り込むことはなく、端末への直接入力を拒否し、パスワードを出力することはありません。既存のデータベースと管理者が必要で、サポートされているデータベース スキーマを確認し、管理者のブラウザ セッションを取り消します。 HTTP サーバーの起動、新しい管理者の初期化、ゲートウェイ キーの変更、またはサブスクリプション資格情報の変更は行われません。パブリックな回復エンドポイントはありません。

メンバーリクエストの制限

管理者が開く メンバー → その他のアクション → リクエスト制限。 1 分あたりのリクエスト数のデフォルトは 0 (無制限)、メンバーの同時実行数のデフォルトは 10 です。いずれかの制限を 0 に設定すると、その個人制限が無効になります。メンバーシップの制限はすべての役割に適用されます。共有ワークスペース/アカウント容量は引き続き適用されます。アップグレードでは、保存されている既存の制限が維持されます。

レート制限では、固定の UTC 分境界が使用されます。境界は、隣接する各ウィンドウからのリクエストを連続して受け入れることができます。これはスライディング ウィンドウの制限ではありません。リクエストは、検証とメンバーの同時承認の後、アップストリーム アカウントの選択前に 1 つのレート スロットを消費します。利用できないアカウント、クールダウン、またはその後のプロバイダー障害によっても、そのスロットは消費されます。メンバーの同時実行またはレート アドミッションによってすでに拒否されたリクエストは、別のレート スロットを消費しません。モデルの検出、サブスクリプション クォータの読み取り、およびローカル WebSocket プリウォームでは、モデル リクエストの制限は消費されません。

HTTP/SSE、Chat Completions、圧縮、および各 WebSocket モデル ターンは同じアドミッション パスを使用します。 1 つの論理リクエスト内でのアップストリームの再試行では、余分なスロットは消費されません。メンバーのリースは、既存の応答ライフサイクルが終了するまでアクティブのままで、正常に完了、キャンセル、失敗、またはシャットダウンしたときに 1 回だけリリースされます。変更は後続のリクエストに適用されます。同時実行制限を下げると、許可された呼び出しが終了します。個人制限が無効になっている場合でも、共有ゲートウェイとアカウントの制限は引き続き適用されます。

HTTP 制限拒否は 429 を返します。 member_busy または member_rate_limited および制限された Retry-After ヘッダー。 WebSocket は、対応するエラー イベントを返します。ローカルでの拒否によって上流アカウントにペナルティが課されることはありません。ポリシーと分カウンターは SQLite に保持されます。実行中のカウンターはプロセスローカルであり、再起動後は空になります。データベースごとに 1 つの SubLane プロセスを実行します。

合成値を使用したメンバーごとのリクエスト制限の例:

利用枠

専用リソースグループを作成してメンバーに権限を付与したら、利用枠の追加画面で割合、金額、Token、時間枠ごとの方式を選択します。割合は設定した Token または内部 USD 予算を分配し、時間枠は複数の期間別 USD 上限を同時に適用します。所有者と管理者には個別のグループ権限付与は不要です。同じメンバーの同じ利用枠に結び付いたキーは残高を共有します。設定とリセットは利用枠を参照してください。

アップグレードに関するメモ: 以前の標準キー トークンの予算ではリクエストが制限されなくなりました。トークン制限を維持するには、利用枠とそれにバインドされた新しいキーを作成します。既存の予算行はアップグレードされたデータベースに残りますが、アプリはそれらを読み取りまたは更新しなくなります。ロールバックすると、このバージョンでの使用量は古いカウンターに追加されません。

使用法の概要

一般 → 概要 → 使用状況 現在のユーザーの通話と現在の個人制限を示します。 管理 → チーム利用 選択したワークスペースを示します。今日、または現在の部分的な日を含む過去 7、30、または 90 UTC 暦日を選択します。概要には、リクエスト数、結果数、完了率、平均期間、報告された入出力トークンが含まれます。日次、モデル、およびプールの内訳は両方の役割で利用できます。チームビューにはメンバーも含まれます。非日次の内訳にはリクエスト数の上位 20 エントリが表示され、合計は常に選択した期間全体をカバーします。毎日の傾向はインタラクティブな折れ線グラフを使用します。モデル、プール、メンバーの比較では水平バーを使用します。リクエスト、入力トークン、出力トークンを切り替えて展開します。 詳細を見る 正確な表の値については。トークンギャップはゼロとしてプロットされるのではなく、不明のままです。毎日のポイントは、ポインター/タッチ検査と矢印キー ナビゲーションをサポートします。

完了率は、完了したリクエストを記録されたすべての試行で割ったものです。不完全な応答には別のカウントが含まれます。平均期間には、ローカルの拒否、キャンセル、失敗が含まれます。欠落トークンのレポートは不明のままであり、部分的な合計には明示的にラベルが付けられます。キャッシュされたトークン カウンタも API によって保持されます。これらは運用統計です。強制力のある 利用枠 別の台帳を使用します。合計額は請求書や残りの手当ではありません。

初期化されたデータベースで統計収集が開始されるとカバレッジが開始され、インターフェイスにそのタイムスタンプが表示されます。保持されている履歴がすでに不完全である可能性があるため、既存のリクエスト レコードはバックフィルされません。試みは、 リクエスト履歴のカバレッジ境界: 認証失敗、ゲートウェイに入る前の HTTP 検証失敗、グローバル アドミッション拒否、メタデータ クエリ、およびプリウォームは除外されます。ゲートウェイ スケジュール内のメンバー制限の拒否が含まれます。

集計は、ユーザー、プール、プロバイダー、正規化モデルごとに、最近のリクエスト レコードとは独立して UTC 日次バケットに保存されます。ユーザーごとに 1 日あたり最大 64 個の異なるモデル ラベルが保持されます。追加のラベルは次のようにグループ化されます その他のモデル カウントや報告されたトークンをドロップすることはありません。 Codex プレフィックスの有無にかかわらず、モデル エイリアスは 1 つのラベルを共有します。プロンプト、応答、生のプロバイダー エラー、資格情報、IP アドレス、またはセッション ID は保存されません。

集計は 90 暦日保存されます。クリーンアップは概要の記録または読み取り時に実行されるため、アイドル状態のデータベースは次の操作で再利用されます。集約とリクエストレコード書き込みは一緒にコミットされ、各概要読み取りでは 1 つのデータベーススナップショットが使用されます。ストレージ障害はログに記録されますが、どちらの書き込みも正常に永続化されたとは報告されません。個人フィルタリングは、認証されたセッション ID を使用して SQL で行われます。指定されたユーザー ID またはスコープではアクセスを拡張できません。サブスクリプション アカウント ID は概要には表示されません。

総合合計を含む管理者の使用状況の概要の例:

時間ごとのアクティビティのヒートマップ

概要の個人使用セクションとチーム使用ページの両方に配置 時間ごとのアクティビティ プライマリ グラフの下、およびオプションの詳細行の上。 7 行は月曜日から日曜日を表し、24 列は UTC 時間を表します。色は、選択した期間の一致する平日/時間スロットを合計した現在のリクエスト/入力トークン/出力トークンのメトリックを反映します。主要な内訳を変更しても、ヒートマップの個人/チームの範囲は変更されません。

時間ごとの集計ではリクエストの開始時刻が使用され、モデルの試行が終了したときに、日ごとの集計や最近の履歴と同じトランザクションに記録されます。これらには、ユーザー ID、UTC 時間、リクエスト数、レポートされた入力/出力トークンの合計とそのレポート数のみが含まれます。ストレージは、モデルやプールのカーディナリティに関係なく、保持される 90 暦日にわたって、1 ユーザーあたり 1 時間あたり最大 1 行に制限されます。

時間ごとのアクティビティには、個別の収集開始タイムスタンプが記録されます。以前の日次合計とプルーニングされたリクエスト レコードは時間単位にバックフィルされません。将来のスロットを含め、一致する収集された時間ウィンドウがないセルは、ゼロではなく不明のままになります。リクエストのない観察されたウィンドウにはゼロが表示されます。トークンレポートのない呼び出しは、未報告の状態を保持します。部分的に報告された合計にはラベルが付けられています。最初の時間枠と現在の時間枠は部分的である可能性があり、API は収集の開始と観察のタイムスタンプを公開します。

セルにホバー、タップ、またはフォーカスすると、その合計と一致する時間単位のウィンドウの数が表示されます。矢印キーはグリッド内を移動します。 Home/End で行内を移動し、Ctrl+Home/End で最初/最後のセルにジャンプします。幅の狭い画面はヒートマップ内でスクロールします。既存の使用状況の応答には、 activity カバレッジのタイムスタンプと、月曜日から始まる固定の 168 セル グリッドを含むオブジェクト。所有権のフィルタリングはサーバー側のままです。

エンドポイントとストレージ

起動時に新規データベースを初期化し、サポート対象の既存データベースには未適用のマイグレーションを順に適用します。001_settings.sql を含む初期の非互換構造は拒否されるため、元のディレクトリを保存して新規ディレクトリを使用してください。更新前にバックアップを作成して検証します。イメージの切り替えだけでは移行済みデータを元に戻せません。