個人用 API キー

すでにログインと承認されたリソースグループがある場合は、ここから始めてください。サブスクリプションの資格情報やクォータ アカウンティングの知識は必要ありません。

キーを作成して使用する

1. サインインして開きます API キー、次にキーを作成します。
2. 認識可能な名前を付け、承認されたプールを選択します。必要な場合にのみ有効期限を設定します。
3. キーをコピーし、そのキー、そのプールで使用可能なインスタンス アドレス、モデル ID を使用してクライアントを構成します。 Codex 人のユーザーがフォローできます クライアント構成.
4. メッセージを送信し、結果を確認します リクエスト.

終了した： クライアントは応答を受け取ります。このキーを使い続けてください。割り当てスキームを作成する必要はありません。

選択するプールがありませんか?管理者に直接確認するよう依頼してください プール補助金。最初のアカウントを設定する管理者は、次のことを行う必要があります。 最初にプールを作成します.

プール ピッカーには、各プールに含まれるサブスクリプション アカウントの数が表示されます。空のプールのキーを事前に作成できますが、アカウントが追加されるまでリクエストを処理できません。フォームは作成前に警告を出します。

次に、次を参照してください。 日常使い。以下のセクションは、必要に応じてキーをコピー、変更、無効化、または統合するためのものです。

実際の秘密を含まない個人キーのフォームの例:

所有権とライフサイクル

• ユーザーは、ワークスペースごとに最大 20 個の取り消されていないキーを持つことができます。制限はトランザクション的にチェックされます。
• リストは 50 件ずつページ分割され、新しいものから順に表示されます。各ユーザーは、個人キー エンドポイントを使用する管理者を含め、自分のキーのみを表示、編集、取り消します。
• キーはデフォルトで有効になり、有効期限はありません。作成時に有効期限を設定するか、後で名前、有効化、有効期限を編集します。 UI には有効期限がなく、7/30/90 日が設定されており、変更しない限り既存の期限が維持されます。 Expiry は絶対的な Unix タイムスタンプ (秒) です。そのタイムスタンプではキーは無効です。リストにはサーバーの時計を使用してステータスが表示されます。
• 一時停止は元に戻すことができ、シークレットと不変のプール バインディングが保持されます。一時停止されたキーと期限切れのキーは、取り消されていないキーの 20 個の制限に引き続きカウントされます。有効期限が切れたキーは、再度機能するまでに期限を延長/削除する必要があります。
• 取り消しは永久的です。同じキーは後続のゲートウェイ要求によって拒否されます。
• メンバーシップを無効にすると、次のゲートウェイ要求または WebSocket ターンで、ワークスペース内のそのメンバーのキーがブロックされます。他のワークスペースにあるキーは引き続き使用できます。メンバーシップを再度有効にすると、有効で有効期限が切れていない、取り消されていないキーが復元されます。取り消されたキーは無効のままです。
• 最終使用時刻には、その後プロバイダー使用不可応答を返す要求も含め、成功したキー認証が記録されます。書き込みはキーごとに 1 分に 1 回に制限されます。機種利用や課金のカウンターではありません。

既存のキーをコピーする

選択 コピー 完全なキーを取得します。別のユーザーが管理者であっても、その所有者のみがこれを行うことができます。 SubLane は、シークレットを保存せずに、監査ログに取得を記録します。クリップボードへのアクセスに失敗した場合は、一時的なダイアログからコピーできます。

ブラウザーは、コピーされたシークレットをローカル ストレージまたは Web URL に保存しません。ダイアログを閉じるか、アイデンティティを切り替えると、その一時的な値は破棄されます。以下のオプションの CC Switch インポートは、キーをローカル アプリケーション リンクに渡します。

一時停止したキーや期限切れのキーをコピーすることはできますが、コピーしても使用できるようになりません。取り消しにより、回復可能な価値は永久に削除されます。

オプション: 設定された許容値のキー

キー フォームには、選択したワークスペースで使用できるプールがリストされます。を使用するには 利用枠、シングルを選択してください 利用枠: 名前 · プール オプション。フォームは、手当とその専用プールを一緒に送信します。個別に選択する必要はありません。同じメンバーのキーと割り当ては、その割り当てを共有します。既存のキーは自動的に再バインドされず、割り当てのないキーは予約されたプールを使用できません。アローワンスを切り替える場合は、新しいキーを作成します。

CC Switch にインポート

インストール CC Switch ブラウザを実行しているコンピュータ上で。で API キー、アクティブなキーの外部リンク アイコンを選択します。

1. 選ぶ Codex, オープンコード, Claude コード, オープンクロー, エルメス, Gemini CLI、 または Grok Build。構成名、リソースグループ、インスタンス URL を確認し、そのプールで使用できるモデルを選択します。
2. 選択 インポートの準備 コピーに使用したのと同じ監査対象のエンドポイントを通じてキーを取得します。
3. 選択 CC Switch を開くをクリックし、そのアプリケーションの構成を確認してください。準備ができたら、そこで有効にします。

インポート パラメータは、CC Switch v3.20.4 のプロバイダー ディープリンク契約に従います。選択したクライアントをサポートする CC Switch バージョンをインストールします。

Claude コードのデフォルト モデルと Haiku、Sonnet、および Opus のエイリアスはすべて、選択したプール モデルにマップされます。 Gemini CLI は API キー認証を使用します。 SubLane は Gemini トークンカウントまたはネイティブモデル検出エンドポイントを公開しないため、インポート後にワークフローを確認してください。 Grok Build のインポートされた context-window 値は CC Switch から取得されます。選択したモデルと照らし合わせて確認してください。クライアントを選択しても、有効なサブスクリプション プロバイダーは変わりません。

の CC Switch インポートリンク 完全なキーをローカル アプリケーションに伝達します。リモートリレーを通過しません。 CC Switch は、インポートされたキーを独自の設定に保存し、自動的に切り替えません。手動セットアップについては、次を参照してください。 クライアント構成 そして クライアントプロトコル.

準備されたリンクはダイアログ内に残り、ダイアログを閉じるか編集すると破棄されます。準備後にクライアントを変更する場合は、 構成の編集 そしてまた準備します。インポートできるのは、グループアクセス権を持つアクティブでコピー可能なキーのみです。 SubLane では、CC Switch がインストールされているかどうか、またはそこでインポートを確認したかどうかを確認できません。 Gemini を含む手動プロトコルの例については、次を使用します。 セットアップガイド.

Magpie にインポートする

ブラウザーを使用するコンピューターに Magpie 0.1.8 以降をインストールします。「API キー」で、有効で期限内、コピー可能で、所属グループへのアクセス権があるキーの「Magpie にインポート」を選択します。ゲートウェイのアドレスとキー名を確認し、「インポートを準備」、「Magpie を開く」の順に選択して、Magpie 内でインポートを確認します。モデルはキーのグループから自動的に取得されるため、手動で選択する必要はありません。

準備時には、コピーと同じ、所有者のみが利用できる監査対象のシークレット取得 API を使用します。ローカルアプリへのリンクは、完全なキーと接続情報をこのデバイスの Magpie に渡します。ダイアログを閉じるかユーザーを切り替えると、準備済みのリンクは破棄されます。SubLane は Magpie のインストールやインポート完了を確認できないため、クライアントから一度リクエストを送って確認してください。

コネクトクライン

開ける APIキー → セットアップガイド → Cline / OpenAI互換。クライン設定で:

1. セット API プロバイダー に OpenAI 互換性あり.
2. ガイドを入力してください API ベース URL、 含む /v1.
3. 個人の SubLane キーをに貼り付けます API キー そしてセット モデルID キーのプールで利用可能なモデルに変換します。別々のプロバイダー設定を使用する場合は、Plan と Act の両方を構成します。
4. メッセージを送って確認してください リクエスト SubLane にあります。選択したモデルに一致するように、オプションのコンテキスト ウィンドウと機能のオーバーライドを設定します。

このガイドでは、テスト用のコピー可能な Chat Completions リクエストも提供しています。 SUBLANE_API_KEY。ガイドを開いたり、その例をコピーしたりしても、シークレットは決して取得されません。 Cline はここでは手動構成を使用します。これは CC Switch インポート メニューのエントリではありません。

ブラウザ API

これらのルートには、有効なユーザー セッション Cookie が必要です。ミューテーションは、ブラウザの残りの部分で使用される正確なオリジン、JSON のみ、および本体サイズの保護 API を保持します。所有者はセッションから取得されますが、送信されたユーザー ID から取得されることはありません。

不明なキー ID または他のユーザーのキー ID が返される 404 api_key_not_found。取り消されたキーを編集すると戻る 409 api_key_revoked。新しい有効期限値または変更された有効期限値は将来のものである必要があります。期限切れのキーの名前を変更するときに、変更されていない過去の期限を保持できます。 PATCH で有効期限を省略すると、期限をサイレントに削除するのではなく拒否されます。取り消されていないキーの制限が返されます 409 api_key_limit。キー名に制御文字を含めることはできません。

ゲートウェイ認証

顧客供給 Authorization: Bearer <api-key> に /v1/*。ネイティブ /v1/messages 追加で受け付けます x-api-key; Gemini /v1beta 受け入れる x-goog-api-key、ベアラー認証、または key クエリパラメータ。矛盾する資格情報は拒否されます。見る ネイティブクライアントプロトコル。ブラウザーのセッション Cookie だけでは、ゲートウェイ要求は認証されません。逆に、API キーにはアクセスできません。 /api/system, /api/members、 または /api/keys.

欠落、無効、一時停止、期限切れ、取り消し、またはブロックされたキーが返される 401 invalid_api_key。無効なユーザー、無効なワークスペース、または無効なメンバーシップは、影響を受けるキーをブロックします。有効なキーはモデルを検出し、設定されたサブスクリプション アカウントを通じて Responses HTTP/SSE/WebSocket、圧縮、および Chat Completions リクエストを転送できます。 WebSocket ターンごとに、キー、有効期限、ワークスペース、メンバーシップ、プール アクセス、モデル ポリシーが再チェックされます。機内で許可された通話は、変更後に終了する場合があります。新しいリクエストとターンは現在のポリシーに合格する必要があります。不明なゲートウェイ パスは、認証後に JSON 404 応答を返します。見る Codex ゲートウェイ 構成、制限、および残りのライブクライアント検証について。

開発ではバックエンドのオリジン、または Vite のオリジンを使用します。 /v1 プロキシ。実稼働バイナリは、同じオリジンで UI とゲートウェイを提供します。ネットワーク展開には HTTPS を使用し、実際のキーをソース管理、共有ログ、またはシェル履歴に入れないようにしてください。

統合初期化スキーマにより、キー テーブルとインデックスが作成されます。手動による変更はワークスペースに表示されます 監査ログ.

ストレージリファレンス

管理者とメンバーが開く API キー [全般] ナビゲーション グループで、独自のゲートウェイ資格情報を管理します。各キーには名前と表示されるプレフィックスがあります。新しいキーは、作成直後にコピーすることも、後でプレフィックスの横にあるコピー アイコンを使用してコピーすることもできます。メタデータ リストは、シークレット、暗号文、またはハッシュを返しません。

キーは sl_ プレフィックスの後に、パディングされていないbase64urlとしてエンコードされた暗号的にランダムな32バイトが続きます。 SQLite は、所有者 ID、名前、表示プレフィックス、ライフサイクル時間、有効化、およびオプションの有効期限とともに、認証用の SHA-256 ダイジェストを保存します。新しいキーには、AES-256-GCM で暗号化された完全な値も含まれます。 api_keys.encrypted_secret、既存のインスタンスローカルを使用 credentials.key。暗号文は API-key ドメイン、所有者およびレコード ID にバインドされており、復号化された値は認証ハッシュと一致する必要があります。ゲートウェイリクエストは引き続きハッシュを使用します。秘密を解読することはありません。

SQLite と credentials.key を一緒にバックアップしてください。キーは AES-256-GCM で暗号化し、認証には SHA-256 ハッシュを使います。暗号化されたキーがある場合、鍵ファイルの欠落や不一致で起動を拒否します。旧ハッシュのみのキーは認証に使えますが原文を表示できず、後続リクエストから原文を取得することもありません。 起動時に新規データベースを初期化し、サポート対象の既存データベースには未適用のマイグレーションを順に適用します。001_settings.sql を含む初期の非互換構造は拒否されるため、元のディレクトリを保存して新規ディレクトリを使用してください。更新前にバックアップを作成して検証します。イメージの切り替えだけでは移行済みデータを元に戻せません。