fix(codex): isolate provider host transport health

docs-site/src/content/docs/ja/reference/configuration/providers.md

@@ -21,7 +21,7 @@ description: プロバイダー エントリ、認証、エンドポイント、
 | `autoSwitchThreshold?` | `number` | `80` | 使用量ベースのプロアクティブ切り替えしきい値。`quota` は紐付け済み/未紐付けタスクの次のリクエストを再評価でき、`fill-first` は未紐付け割り当ての使い切り基準としてのみ使用し、通常の `round-robin` 選択は使用しません。既知の 5 時間、週次、30 日 quota window の最大スコアを使います。`0` は使用量ベースの切り替えだけを無効にし、未紐付け割り当てや障害回復は無効にしません。 |
 | `accountPoolStrategy?` | `"quota" \| "round-robin" \| "fill-first"` | `"quota"` | 新規/未紐付け Codex リクエストの割り当て戦略。live な `(parent thread id, quota scope)` affinity がなければ未紐付けで、プロキシ再起動や affinity リセット後は既存の表示タスクも未紐付けになり得ます。`quota` はアクティブアカウントがなければ既知 usage 最小の適格アカウントを選び、適格なアクティブアカウントが `autoSwitchThreshold` 未満なら維持します。しきい値到達後は、未紐付けリクエストまたは紐付け済みタスクの次のリクエストを usage の低い適格アカウントへ移せます。`round-robin` は未紐付けリクエストを均等分散し、`fill-first` は cooldown、使用不可、または drain threshold までアクティブアカウントへ割り当てます。 |
 | `accountPoolStickyLimit?` | `number` | `1` | 1 回の round-robin 選択で次へ進む前に保持する新規/未紐付けタスク割り当て数。カウンターは上流の成功後ではなくタスクの紐付け時に増えます。範囲 1–100。`accountPoolStrategy` が `round-robin` のときのみ。 |
-| `upstreamFailoverThreshold?` | `number` | `3` |今後の新しいセッションがフェイルオーバーする前に一時的なエラーが連続して発生する。 `0` を無効に設定します。 |
+| `upstreamFailoverThreshold?` | `number` | `3` | 既存の紐付け済みタスクを含む後続リクエストでアカウントの failover を行えるようになるまでに必要な、アカウント単位の一時的な HTTP または意味上の失敗結果の連続回数です。`0` はアカウント failover だけを無効にします。HTTP status が観測される前に rejection で終了した論理リクエストは、`(provider, canonical HTTP(S) origin)` をキーとするプロセスローカルな host health だけを更新して account probe lease を解放します。アカウントの quarantine、cooldown/failure streak、affinity、pool rotation、active account selection は変更しません。5 分以内に論理リクエスト単位の終端 host failure が 3 回発生すると host circuit が 30 秒間開き、その後は正確に 1 件の half-open 論理リクエストだけが許可され、同時リクエストは引き続き拒否されます。観測された HTTP failure status はアカウント evidence として残ります。`503` response の後に rejection が起きた場合、順序付き evidence は `503` をアカウント用に、後の rejection を host 用に保持します。プールされた通常の Responses と native compact リクエストの Codex bearer redirect は手動処理され、追従せず、`Location` を公開せず、サイズを制限したアカウント単位の `502` に変換されます。peer が資格情報を伴うリクエストを消費した可能性があっても、HTTP status が観測される前に transport rejection が発生した場合、そのリクエストを別の資格情報では再送しません。その終端 rejection は、正常な代替アカウントを一時的にブロックする host circuit の成立に寄与する可能性があります。 |
 | `modelCacheTtlMs?` | `number` | `300000` |プロバイダーごとの `/models` キャッシュの鮮度ウィンドウ。 |
 | `cacheRetention?` | `"none" \| "short" \| "long"` | `"short"` | Anthropic プロンプト キャッシュ ポリシー: 無効、5 分間の一時的、または 1 時間の延長。 |
 | `tokenGuardian?` | `OcxTokenGuardianConfig` |オフ |オプションのプロアクティブな OAuth 更新および Codex アカウントのウォームアップ ポリシー。 |

docs-site/src/content/docs/ko/reference/configuration/providers.md

@@ -21,7 +21,7 @@ description: 공급자 항목, 인증, 엔드포인트, 모델 카탈로그, 할
 | `autoSwitchThreshold?` | `number` | `80` | 사용량 기반 선제 전환 임계값입니다. `quota`는 바인딩된 작업과 바인딩 없는 작업의 다음 요청을 모두 재평가할 수 있고, `fill-first`는 바인딩 없는 작업 배정의 소진 기준으로만 사용하며, 기본 `round-robin` 선택은 이 값을 사용하지 않습니다. 알려진 5시간, 주간, 30일 quota window 중 가장 높은 점수를 씁니다. `0`은 사용량 기반 전환만 끄며 바인딩 없는 작업 배정이나 실패 복구는 끄지 않습니다. |
 | `accountPoolStrategy?` | `"quota" \| "round-robin" \| "fill-first"` | `"quota"` | 새 작업/바인딩 없는 Codex 요청의 계정 배정 전략입니다. `(parent thread id, quota scope)`의 live affinity가 없으면 바인딩 없는 요청이며, 프록시 재시작이나 affinity 초기화 뒤에는 기존에 보이던 작업도 바인딩이 없어질 수 있습니다. `quota`는 활성 계정이 없을 때 알려진 usage가 가장 낮은 적격 계정을 선택하고, 적격 활성 계정이 `autoSwitchThreshold` 미만이면 유지합니다. 임계값 도달 뒤에는 바인딩 없는 요청이나 바인딩된 작업의 다음 요청을 usage가 더 낮은 적격 계정으로 옮길 수 있습니다. `round-robin`은 바인딩 없는 요청을 균등 분배하고, `fill-first`는 cooldown, 사용 불가 또는 drain threshold까지 활성 계정에 배정합니다. |
 | `accountPoolStickyLimit?` | `number` | `1` | 한 round-robin 선택이 다음으로 넘어가기 전에 유지하는 새 작업/바인딩 없는 작업 배정 수입니다. 카운터는 업스트림 성공 뒤가 아니라 작업을 바인딩할 때 증가합니다. 범위 1–100이며 `accountPoolStrategy`가 `round-robin`일 때만 적용됩니다. |
-| `upstreamFailoverThreshold?` | `number` | `3` | 연속된 일시적 실패가 이 횟수에 도달하면 이후 새 세션은 failover됩니다. `0`으로 두면 비활성화됩니다. |
+| `upstreamFailoverThreshold?` | `number` | `3` | 기존 바인딩된 작업을 포함한 후속 요청이 계정 failover될 수 있기 전에 필요한 연속 계정 범위의 일시적 HTTP 또는 의미상 실패 결과 수입니다. `0`은 계정 failover만 비활성화합니다. HTTP 상태가 관측되기 전에 최종적으로 거부된 논리 요청은 `(provider, canonical HTTP(S) origin)` 키의 프로세스 로컬 host health만 갱신하고 계정 probe lease를 해제합니다. 계정 quarantine, cooldown/failure streak, affinity, pool rotation, active account selection은 변경하지 않습니다. 5분 안에 논리 요청 단위의 최종 host failure가 3회 발생하면 host circuit이 30초 동안 열리고, 이후 정확히 하나의 half-open 논리 요청만 허용되며 동시 요청은 계속 차단됩니다. 관측된 HTTP 실패 상태는 계정 근거로 남습니다. `503` 응답 후 거부가 발생하면 순서가 보존된 근거는 `503`을 계정용으로, 뒤의 거부를 host용으로 유지합니다. 풀의 일반 Responses 및 native compact 요청에 대한 Codex bearer redirect는 수동으로 처리되어 따라가지 않고 `Location`을 노출하지 않으며, 크기가 제한된 계정 범위 `502`로 변환됩니다. peer가 자격 증명을 실어 보낸 요청을 소비했을 수 있더라도 HTTP 상태가 관측되기 전에 transport rejection이 발생하면 그 요청을 다른 자격 증명으로 재전송하지 않습니다. 이 최종 rejection은 정상인 대체 계정을 일시적으로 차단하는 host circuit의 성립에 기여할 수 있습니다. |
 | `modelCacheTtlMs?` | `number` | `300000` | 공급자별 `/models` 캐시의 최신성 창입니다. |
 | `cacheRetention?` | `"none" \| "short" \| "long"` | `"short"` | Anthropic 프롬프트 캐시 정책입니다. 비활성, 5분짜리 임시, 1시간짜리 확장 중 하나입니다. |
 | `tokenGuardian?` | `OcxTokenGuardianConfig` | 꺼짐 | 선택적 선제 OAuth 갱신과 Codex 계정 워밍업 정책입니다. |

docs-site/src/content/docs/reference/configuration/providers.md

@@ -22,7 +22,7 @@ authenticated.
 | `autoSwitchThreshold?` | `number` | `80` | Usage threshold for proactive switching. `quota` can re-evaluate both bound and unbound tasks on their next request; `fill-first` uses it only as the drain point for unbound assignment; normal `round-robin` selection does not use it. The score uses the hottest known 5h, weekly, or 30d quota window. `0` disables usage-based proactive switching only, not unbound assignment or failure recovery. |
 | `accountPoolStrategy?` | `"quota" \| "round-robin" \| "fill-first"` | `"quota"` | Assignment strategy for new/unbound Codex requests. A request is unbound when it has no live (parent thread id, quota scope) affinity; a visible existing task can become unbound after proxy restart or affinity reset. `quota` picks the lowest-usage eligible account when no active account exists, keeps an eligible active account below `autoSwitchThreshold`, and after the threshold may move an unbound request or proactively rebind a bound task to a lower-usage eligible account. `round-robin` distributes unbound requests evenly; `fill-first` keeps assigning unbound requests to the active account until cooldown, unavailability, or the configured drain threshold. |
 | `accountPoolStickyLimit?` | `number` | `1` | New/unbound task assignments retained on one round-robin selection before advancing; the counter advances when a task is bound, not after an upstream success. Range 1–100. |
-| `upstreamFailoverThreshold?` | `number` | `3` | Consecutive transient failures before future new sessions fail over. Set `0` to disable. |
+| `upstreamFailoverThreshold?` | `number` | `3` | Consecutive account-scoped transient HTTP or semantic failure outcomes required before subsequent requests, including existing bound tasks, may fail over; `0` disables only account failover. A terminal logical request that rejects before any HTTP status is observed updates only process-local host health keyed by `(provider, canonical HTTP(S) origin)` and releases any account probe lease; it does not change account quarantine, account cooldown/failure streak, affinity, pool rotation, or active account selection. Three terminal logical host failures within five minutes open the host circuit for 30 seconds; then exactly one half-open logical request is admitted while concurrent requests remain blocked. An observed HTTP failure status remains account evidence. If a `503` response is followed by a rejection, ordered evidence retains the `503` for the account and the later rejection for the host. Codex bearer redirects for pooled regular Responses and native compact requests are handled manually: they are not followed, `Location` is not exposed, and they become a bounded account-scoped `502`. If the peer may have consumed a credential-bearing request but the transport rejects before any HTTP status is observed, the request is not replayed under another credential; that terminal rejection can contribute to a host circuit that temporarily blocks an otherwise healthy alternate. |
 | `modelCacheTtlMs?` | `number` | `300000` | Freshness window for the per-provider `/models` cache. |
 | `cacheRetention?` | `"none" \| "short" \| "long"` | `"short"` | Anthropic prompt-cache policy: disabled, 5-minute ephemeral, or 1-hour extended. |
 | `tokenGuardian?` | `OcxTokenGuardianConfig` | off | Optional proactive OAuth refresh and Codex-account warmup policy. |

docs-site/src/content/docs/ru/reference/configuration/providers.md

@@ -22,7 +22,7 @@ description: Записи провайдеров, аутентификация,
 | `autoSwitchThreshold?` | `number` | `80` | Порог проактивного переключения по использованию. `quota` может повторно оценить следующий запрос как привязанной, так и непривязанной задачи; `fill-first` использует его только как точку исчерпания для непривязанных назначений; обычный `round-robin` его не использует. Оценка берёт самое горячее из окон 5 часов, недели и 30 дней. `0` отключает только переключение по использованию, но не назначение непривязанных задач и не восстановление после сбоев. |
 | `accountPoolStrategy?` | `"quota" \| "round-robin" \| "fill-first"` | `"quota"` | Стратегия назначения для новых/непривязанных запросов Codex. Запрос непривязан, если у него нет live affinity `(parent thread id, quota scope)`; видимая существующая задача может стать непривязанной после перезапуска прокси или сброса affinity. `quota` выбирает подходящий аккаунт с наименьшим известным usage, когда активного аккаунта нет, сохраняет подходящий активный аккаунт ниже `autoSwitchThreshold`, а после порога может перевести непривязанный запрос или следующий запрос привязанной задачи на подходящий аккаунт с меньшим usage. `round-robin` равномерно распределяет непривязанные запросы; `fill-first` назначает их активному аккаунту до cooldown, недоступности или порога исчерпания. |
 | `accountPoolStickyLimit?` | `number` | `1` | Число назначений новых/непривязанных задач на одном выборе round-robin перед переходом дальше. Счётчик растёт при привязке задачи, а не после успеха upstream. Диапазон 1–100; только при `accountPoolStrategy` = `round-robin`. |
-| `upstreamFailoverThreshold?` | `number` | `3` | Сколько подряд transient failure допустить, прежде чем новые сессии начнут делать failover. `0` отключает эту логику. |
+| `upstreamFailoverThreshold?` | `number` | `3` | Количество последовательных временных HTTP- или семантических результатов сбоя, относящихся к аккаунту, после которых последующие запросы, включая существующие привязанные задачи, могут выполнить failover; `0` отключает только failover аккаунта. Логический запрос, окончательно отклоненный до наблюдения какого-либо HTTP-статуса, обновляет только локальное для процесса состояние хоста с ключом `(provider, canonical HTTP(S) origin)` и освобождает lease account probe; он не меняет quarantine аккаунта, его cooldown/failure streak, affinity, pool rotation или выбор активного аккаунта. Три конечных сбоя хоста на уровне логического запроса за пять минут открывают circuit хоста на 30 секунд; затем допускается ровно один half-open логический запрос, а параллельные запросы остаются заблокированными. Наблюдаемый HTTP-статус сбоя остается свидетельством для аккаунта. Если за ответом `503` следует отклонение, упорядоченные свидетельства сохраняют `503` для аккаунта, а последующее отклонение для хоста. Перенаправления bearer-запросов Codex для обычных Responses из пула и native compact обрабатываются вручную: переход не выполняется, `Location` не раскрывается, а результат преобразуется в ограниченный по размеру ответ `502`, учитываемый для аккаунта. Если peer мог принять запрос с учетными данными, но до наблюдения какого-либо HTTP-статуса происходит transport rejection, запрос не повторяется с другими учетными данными. Такое конечное отклонение может способствовать открытию circuit хоста, который временно заблокирует исправный альтернативный аккаунт. |
 | `modelCacheTtlMs?` | `number` | `300000` | Окно свежести для кэша `/models` на уровне провайдера. |
 | `cacheRetention?` | `"none" \| "short" \| "long"` | `"short"` | Политика prompt-cache Anthropic: отключено, 5-минутный ephemeral или 1-часовой extended. |
 | `tokenGuardian?` | `OcxTokenGuardianConfig` | off | Необязательная политика proactive OAuth refresh и warmup'а аккаунтов Codex. |