lidge-jun · Ingwannu · Sep 4, 2026 · Sep 4, 2026
@@ -10,10 +10,11 @@ clé et les services auxiliaires, sans configuration d'authentification supplém
 ## Groupe de comptes OAuth Claude (expérimental)
 
 Vous pouvez vous connecter à plusieurs comptes Claude via le tableau de bord des fournisseurs (`ocx login anthropic` /
-ajouter un compte). Par défaut, chaque requête utilise uniquement le compte **actif**.
+ajouter un compte). Avec un seul compte éligible, chaque requête utilise ce compte actif. Avec au moins deux comptes,
+une erreur 429 en amont peut relancer la requête sur un autre compte même si le routage proactif est désactivé.
 
 Un groupe de comptes Claude **expérimental et facultatif** (`anthropicAccountPool.enabled`) ajoute l'affinité de
-session et le basculement en cas de délai de récupération 429 entre ces comptes OAuth. Pour les **nouvelles**
+session proactive et la sélection des nouvelles sessions entre ces comptes OAuth. Pour les **nouvelles**
 sessions uniquement, `anthropicAccountPool.strategy` sélectionne un compte éligible : `quota` (par défaut)
 choisit la plus faible utilisation connue dans la fenêtre configurée par `anthropicAccountPool.quotaWindow`
 (`five-hour` par défaut, `weekly` ou `max-utilization`) lorsqu'elle dépasse `autoSwitchThreshold` ; `round-robin`
@@ -23,18 +24,20 @@ un délai de récupération, une réauthentification ou le seuil, puis passe au
 Anthropic peut restreindre les comptes dont l'activité ressemble à une rotation automatisée ; la rotation ne
 protège pas contre l'application des règles du fournisseur.
 
-Comportement lorsque cette option est activée :
+Récupération réactive avec au moins deux comptes éligibles :
 
 - Un **429** en amont place le compte en temporisation selon `Retry-After` lorsqu'il est présent, ou selon un délai de repli,
-  efface ses affinités et peut faire basculer la requête vers un autre compte admissible, dans les limites prévues.
+  et peut faire basculer la requête vers un autre compte admissible, dans les limites prévues. Cette récupération reste active
+  lorsque `anthropicAccountPool.enabled` est absent ou vaut `false`. Ne conservez qu'un compte éligible si vous refusez tout
+  changement automatique de compte.
+- Lorsque le routage proactif est activé, un 429 efface aussi l'affinité de ce compte.
 - L'affinité est **locale au processus** et disparaît au redémarrage du proxy.
 - Les erreurs d'identification **401/403** mettent le compte en quarantaine (`needsReauth`) afin de l'exclure de la
   sélection jusqu'à sa réauthentification.
 - Si chaque compte éligible est en temporisation, le proxy renvoie **429** (et non 401) avec `Retry-After`
   lorsqu'il est connu.
-- La récupération, y compris le basculement 429, utilise `quotaWindow` pour classer les comptes de
-  remplacement admissibles, sans modifier les limites existantes de temporisation ou de basculement ;
-  `round-robin` ignore `quotaWindow`.
+- Lorsque le routage proactif est désactivé, la récupération utilise l'ordre du quota. Lorsqu'il est activé,
+  la stratégie du groupe choisit les remplacements admissibles ; `round-robin` ignore `quotaWindow`.
 
 Voir [Configuration](/fr/reference/configuration/providers/#anthropicaccountpool-expérimental).
 

@@ -149,7 +149,7 @@ sont ignorés à moins que `--all` soit présent. Avec un fournisseur, répertor
 La sortie destinée aux utilisateurs utilise `PROVIDER TYPE ID PLAN/LABEL PRIORITY STATUS` ; une ligne Codex sélectionnée manuellement porte la mention
 `selected`. `PRIORITY` est l'ordre de sélection Codex signé (`0` lorsqu'il n'est pas défini) et affiche `-` pour les lignes
 où l'ordre ne s'applique pas, comme les comptes OAuth et les clés API. Avec au moins deux comptes Kiro enregistrés et éligibles, par défaut une réponse 429 entraîne automatiquement une rotation vers un autre
-compte, en privilégiant celui dont l'allocation restante connue est la plus élevée ; la rotation est activée par la présence de plusieurs comptes et peut être désactivée avec `oauthAccountFailover.enabled: false` ; `ocx account login kiro` ajoute les comptes au pool un par un. Un résultat vide est toujours un succès. `--json`
+compte, en privilégiant celui dont l'allocation restante connue est la plus élevée ; la rotation réactive est activée par la présence de plusieurs comptes. `oauthAccountFailover.enabled: false` désactive seulement la préférence proactive avant envoi, pas cette nouvelle tentative ; `ocx account login kiro` ajoute les comptes au pool un par un. Un résultat vide est toujours un succès. `--json`
 renvoie :
 
 ```text

@@ -198,20 +198,22 @@ rotation automatique peut déclencher des restrictions du fournisseur.
 
 | Clé | Type | Par défaut | Description |
 | --- | --- | --- | --- |
-| `anthropicAccountPool.enabled?` | `boolean` | `false` | Active l'affinité persistante et le basculement après une temporisation 429. |
+| `anthropicAccountPool.enabled?` | `boolean` | `false` | Active l’affinité proactive persistante et la sélection des nouvelles sessions. Avec au moins deux comptes éligibles, la récupération réactive après 429 reste active même avec `false`. |
 | `anthropicAccountPool.autoSwitchThreshold?` | `number` | `80` | Pour les nouvelles sessions, lorsque le compte actif atteint ce seuil, choisir la plus faible utilisation connue et mise en cache dans la fenêtre configurée. `0` désactive la sélection selon le quota. |
 | `anthropicAccountPool.strategy?` | `"quota" \| "round-robin" \| "fill-first"` | `"quota"` | Stratégie des nouvelles sessions ; `quota` classe les comptes selon la fenêtre définie par `quotaWindow`, par défaut les barres sur 5 heures, et `fill-first` évalue son seuil d'évacuation dans cette même fenêtre. |
 | `anthropicAccountPool.quotaWindow?` | `"five-hour" \| "weekly" \| "max-utilization"` | `"five-hour"` | Barre d'utilisation signalée par le fournisseur, mise en cache et utilisée pour la sélection selon l'utilisation. `five-hour` conserve le comportement actuel. `weekly` utilise la barre hebdomadaire et ignore les comptes dont la barre sur 5 heures est épuisée tant qu'un autre compte admissible reste disponible, mais y revient si aucun autre ne reste. `max-utilization` utilise la valeur connue la plus élevée et peut donc employer la barre sur 5 heures avant que la barre hebdomadaire soit disponible ; si aucune n'est connue, le compte suit l'ordre des utilisations inconnues. Les utilisations connues précèdent les inconnues, mais si tous les comptes admissibles sont inconnus, la sélection en renvoie tout de même un dans leur ordre admissible. Après le départage documenté par la plus faible utilisation sur 5 heures, une égalité exacte conserve cet ordre. Une session saine avec affinité n'est pas rééquilibrée de manière proactive. Pour l'affectation des nouvelles sessions et la reprise du routage après un remplacement admissible à la suite d'un 429, `quota` classe directement les candidats admissibles avec cette fenêtre ; `fill-first` avance dans un ordre stable selon le seuil et les règles d'épuisement de cette fenêtre ; `round-robin` l'ignore. Le délai de récupération, les limites de basculement et l'éligibilité de réauthentification restent des états locaux distincts. Les barres hebdomadaires ne sont connues qu'après leur interrogation dans la page Fournisseurs du tableau de bord. |
 | `anthropicAccountPool.stickyLimit?` | `number` | `1` | Liaisons de nouvelle session réussies conservées sur une sélection à tour de rôle. Portée 1–100. |
 
-Lorsque cette option est activée, un 429 enregistre une temporisation bornée à partir de `Retry-After` ou d'un délai de repli, puis peut
-faire basculer la requête vers un autre compte. L'affinité est locale au processus et de taille bornée. Un 401/403 lié aux identifiants marque le compte
+Avec au moins deux comptes admissibles, un 429 enregistre une temporisation bornée à partir de `Retry-After` ou d'un délai de repli, puis peut
+faire basculer la requête vers un autre compte même si cette option est absente ou vaut `false`. L'activation du groupe ajoute l'affinité proactive
+et la sélection des nouvelles sessions. L'affinité est locale au processus et de taille bornée. Un 401/403 lié aux identifiants marque le compte
 comme devant être réauthentifié. Si tous les comptes admissibles sont en temporisation, les clients reçoivent un 429 accompagné de
 `Retry-After` lorsqu'il est connu, et non une erreur d'authentification.
 
 :::caution[Expérimental]
-Laissez cette option désactivée, sauf si vous comprenez les risques liés aux règles d'Anthropic concernant les comptes. En cas de doute,
-préférez le changement manuel avec `ocx account use anthropic <id>`.
+Laissez le regroupement proactif désactivé, sauf si vous comprenez les risques liés aux règles d'Anthropic concernant les comptes. Cela ne
+désactive pas la rotation réactive après 429 ; ne conservez qu'un seul compte admissible si vous refusez tout changement automatique. En cas
+de doute, préférez le changement manuel avec `ocx account use anthropic <id>`.
 :::
 
 ### Formes d'enregistrement gérées

@@ -10,10 +10,11 @@ included — with zero extra auth work.
 ## Claude OAuth account pool (experimental)
 
 You can log in multiple Claude accounts via the Providers dashboard (`ocx login anthropic` /
-add-account). By default every request uses the **active** account only.
+add-account). With one eligible account, every request uses that active account. With two or more,
+an upstream 429 may retry another account even while proactive pooling is disabled.
 
-An **experimental, opt-in** Claude account pool (`anthropicAccountPool.enabled`) adds sticky
-session affinity and 429 cooldown failover across those OAuth accounts. For **new** sessions,
+An **experimental, opt-in** Claude account pool (`anthropicAccountPool.enabled`) adds proactive
+sticky session affinity and new-session selection across those OAuth accounts. For **new** sessions,
 `anthropicAccountPool.strategy` selects among eligible accounts: `quota` (default) picks the
 lowest known usage in the window set by `quotaWindow` (`five-hour` by default, or `weekly` /
 `max-utilization`) when above `autoSwitchThreshold`; `round-robin` spreads evenly
@@ -22,18 +23,20 @@ reauthentication, or threshold, then advances. It is **off by default**, shows a
 and is not battle-tested — Anthropic may restrict accounts that look like automated rotation;
 rotation does not protect against provider enforcement.
 
-Operational contract when enabled:
+Reactive recovery with two or more eligible accounts:
 
 - Upstream **429** cools that account using `Retry-After` when present (else a default backoff),
-  clears its affinities, and may rotate to another eligible account within the same request
-  (bounded).
+  and may rotate to another eligible account within the same request (bounded). This remains active
+  when `anthropicAccountPool.enabled` is absent or `false`; keep one eligible account if you do not
+  accept automatic account switching.
+- When proactive pooling is enabled, a 429 also clears that account's affinity.
 - Affinity is **process-local** (lost on proxy restart).
 - **401/403** credential failures quarantine the account (`needsReauth`) so it is excluded from
   selection until re-authenticated.
 - If every eligible account is cooling, the proxy returns **429** (not 401) with `Retry-After`
   when known.
-- Recovery, including 429 failover, uses `quotaWindow` to rank eligible replacements without
-  changing the existing cooldown or failover limits; `round-robin` ignores `quotaWindow`.
+- Recovery uses quota ordering while proactive pooling is disabled. When it is enabled, the chosen
+  pool strategy governs eligible replacements; `round-robin` ignores `quotaWindow`.
 - `autoSwitchThreshold: 0` turns off **proactive** usage-based switching only. New-session
   selection and 429 recovery still consult `quotaWindow`, so the window is inert only under
   `round-robin`. `fill-first` evaluates its drain threshold in the selected window.

@@ -113,7 +113,7 @@ Codex pool selection applies to the next request after clearing existing affinit
 
 ### `ocx account list [provider] [--json] [--all] [--quota [--refresh]]`
 
-プロバイダーを使用しない場合、Codex プール、OAuth アカウント、および設定された API キー プールが一覧表示されます。 `--all` が存在しない限り、空のプロバイダーはスキップされます。プロバイダーを使用すると、その資格情報ファミリーのみがリストされます。人間の出力では `PROVIDER TYPE ID PLAN/LABEL PRIORITY STATUS` を使用します。手動で選択した Codex 行には `selected` というマークが付けられます。利用可能な Kiro アカウントが 2 つ以上保存されている場合、既定では 429 を受けると別のアカウントへ自動的に切り替え、既知の残り利用枠が最も多いアカウントを優先します。この切り替えはアカウントの存在によって有効になり、`oauthAccountFailover.enabled: false` で無効にできます。`ocx account login kiro` はアカウントを 1 件ずつプールへ追加します。結果が空であっても成功です。 `--json` は次を返します:
+プロバイダーを使用しない場合、Codex プール、OAuth アカウント、および設定された API キー プールが一覧表示されます。 `--all` が存在しない限り、空のプロバイダーはスキップされます。プロバイダーを使用すると、その資格情報ファミリーのみがリストされます。人間の出力では `PROVIDER TYPE ID PLAN/LABEL PRIORITY STATUS` を使用します。手動で選択した Codex 行には `selected` というマークが付けられます。利用可能な Kiro アカウントが 2 つ以上保存されている場合、既定では 429 を受けると別のアカウントへ自動的に切り替え、既知の残り利用枠が最も多いアカウントを優先します。この反応型の切り替えはアカウントの存在によって有効になります。`oauthAccountFailover.enabled: false` は送信前のプロアクティブな選択だけを無効にし、この再試行は無効にしません。`ocx account login kiro` はアカウントを 1 件ずつプールへ追加します。結果が空であっても成功です。 `--json` は次を返します:
 
 ```text
 { accounts: AccountRow[], notes: string[] }

@@ -165,16 +165,16 @@ affinity を維持します。これらの戦略は provider enforcement を回
 
 |キー |タイプ |デフォルト |説明 |
 | --- | --- | --- | --- |
-| `anthropicAccountPool.enabled?` | `boolean` | `false` |スティッキー アフィニティと 429 クールダウン フェイルオーバーを有効にします。 |
+| `anthropicAccountPool.enabled?` | `boolean` | `false` |プロアクティブなスティッキー アフィニティと新規セッション選択を有効にします。利用可能なアカウントが 2 つ以上ある場合、`false` でも反応型の 429 クールダウンとフェイルオーバーは有効です。 |
 | `anthropicAccountPool.autoSwitchThreshold?` | `number` | `80` |新しいセッションでは、アクティブなアカウントがこのしきい値に達すると、設定した期間で既知のキャッシュ使用量が最も低いアカウントを選択します。 `0` はクォータ選択を無効にします。 |
 | `anthropicAccountPool.strategy?` | `"quota" \| "round-robin" \| "fill-first"` | `"quota"` |新しいセッション戦略。`quota` は `quotaWindow` で指定した期間（既定は 5 時間足）でアカウントを順位付けし、`fill-first` も同じ期間で使い切りのしきい値を判定します。 |
 | `anthropicAccountPool.quotaWindow?` | `"five-hour" \| "weekly" \| "max-utilization"` | `"five-hour"` |使用量ベースのアカウント選択で使う、プロバイダー報告のキャッシュ済み使用率です。`five-hour` は従来の動作を維持します。`weekly` は週次使用量を使い、他に対象アカウントが残る間だけ 5 時間使用量が上限に達したアカウントを除外し、残らない場合はそれらへフォールバックします。`max-utilization` は判明している値のうち最も高いものを使うため、週次使用量が未取得でも 5 時間使用量を利用できます。どちらも不明なら unknown の順位付けに従います。既知の使用量は unknown より先ですが、対象がすべて unknown でも対象順の先頭を選択します。記載した 5 時間使用量による同点判定後も完全に同点なら、対象順を維持します。正常な affinity セッションを先回りして再配置することはありません。新規セッションの割り当てと、対象となる 429 代替後のルーティング復旧では、`quota` はこの期間で対象候補を直接順位付けし、`fill-first` はこの期間のしきい値と上限到達ルールを使って安定順に進み、`round-robin` はこの設定を無視します。クールダウン、フェイルオーバー上限、再認証の適格性は別のローカル状態です。アカウント別の週次使用量は、ダッシュボードのプロバイダーページで取得した後にのみ利用できます。 |
 | `anthropicAccountPool.stickyLimit?` | `number` | `1` |成功した新しいセッションのバインドは 1 つのラウンドロビン選択で保持されます。範囲は 1 ～ 100。 |
 
-有効にすると、429 レコードは `Retry-After` またはデフォルトのバックオフからの制限されたクールダウンを記録し、リクエスト内でローテーションする可能性があります。アフィニティはプロセスローカルであり、サイズ制限があります。資格情報 401/403 は、アカウントに再認証が必要であることをマークします。すべての対象となるアカウントが冷却されている場合、クライアントは、既知の場合、認証エラーではなく、`Retry-After` を含む 429 を受け取ります。
+利用可能なアカウントが 2 つ以上ある場合、429 は `Retry-After` またはデフォルトのバックオフから制限付きクールダウンを記録し、このフラグが未設定または `false` でもリクエスト内で別アカウントへ切り替わることがあります。プールを有効にすると、これに加えてプロアクティブなスティッキー affinity と新規セッション選択が有効になります。Affinity はプロセスローカルであり、サイズ制限があります。資格情報 401/403 は、アカウントに再認証が必要であることをマークします。すべての対象アカウントがクールダウン中の場合、クライアントは認証エラーではなく、既知であれば `Retry-After` を含む 429 を受け取ります。
 
 :::caution[実験的]
-Anthropic アカウント ポリシーのリスクを理解していない限り、これは無効のままにしてください。不明な場合は、`ocx account use anthropic <id>` を手動で切り替えることをお勧めします。
+Anthropic アカウントポリシーのリスクを理解していない限り、プロアクティブなプールは無効のままにしてください。これだけでは反応型の 429 ローテーションは無効になりません。自動切り替えを一切許容しない場合は、利用可能なアカウントを 1 つだけにしてください。不明な場合は、`ocx account use anthropic <id>` による手動切り替えをお勧めします。
 :::
 
 ### 管理されたレコードの形状