# Resilience Guide (ಕನ್ನಡ)

🌐 **Languages:** 🇺🇸 [English](../../../../architecture/RESILIENCE_GUIDE.md) · 🇪🇹 [am](../../../am/docs/architecture/RESILIENCE_GUIDE.md) · 🇸🇦 [ar](../../../ar/docs/architecture/RESILIENCE_GUIDE.md) · 🇦🇿 [az](../../../az/docs/architecture/RESILIENCE_GUIDE.md) · 🇧🇬 [bg](../../../bg/docs/architecture/RESILIENCE_GUIDE.md) · 🇧🇩 [bn](../../../bn/docs/architecture/RESILIENCE_GUIDE.md) · 🇧🇦 [bs](../../../bs/docs/architecture/RESILIENCE_GUIDE.md) · 🇨🇿 [cs](../../../cs/docs/architecture/RESILIENCE_GUIDE.md) · 🇩🇰 [da](../../../da/docs/architecture/RESILIENCE_GUIDE.md) · 🇩🇪 [de](../../../de/docs/architecture/RESILIENCE_GUIDE.md) · 🇬🇷 [el](../../../el/docs/architecture/RESILIENCE_GUIDE.md) · 🇪🇸 [es](../../../es/docs/architecture/RESILIENCE_GUIDE.md) · 🇪🇪 [et](../../../et/docs/architecture/RESILIENCE_GUIDE.md) · 🇮🇷 [fa](../../../fa/docs/architecture/RESILIENCE_GUIDE.md) · 🇫🇮 [fi](../../../fi/docs/architecture/RESILIENCE_GUIDE.md) · 🇫🇷 [fr](../../../fr/docs/architecture/RESILIENCE_GUIDE.md) · 🇮🇪 [ga](../../../ga/docs/architecture/RESILIENCE_GUIDE.md) · 🇮🇳 [gu](../../../gu/docs/architecture/RESILIENCE_GUIDE.md) · 🇳🇬 [ha](../../../ha/docs/architecture/RESILIENCE_GUIDE.md) · 🇮🇱 [he](../../../he/docs/architecture/RESILIENCE_GUIDE.md) · 🇮🇳 [hi](../../../hi/docs/architecture/RESILIENCE_GUIDE.md) · 🇭🇷 [hr](../../../hr/docs/architecture/RESILIENCE_GUIDE.md) · 🇭🇺 [hu](../../../hu/docs/architecture/RESILIENCE_GUIDE.md) · 🇦🇲 [hy](../../../hy/docs/architecture/RESILIENCE_GUIDE.md) · 🇮🇩 [id](../../../id/docs/architecture/RESILIENCE_GUIDE.md) · 🇳🇬 [ig](../../../ig/docs/architecture/RESILIENCE_GUIDE.md) · 🇮🇹 [it](../../../it/docs/architecture/RESILIENCE_GUIDE.md) · 🇯🇵 [ja](../../../ja/docs/architecture/RESILIENCE_GUIDE.md) · 🇬🇪 [ka](../../../ka/docs/architecture/RESILIENCE_GUIDE.md) · 🇰🇭 [km](../../../km/docs/architecture/RESILIENCE_GUIDE.md) · 🇰🇷 [ko](../../../ko/docs/architecture/RESILIENCE_GUIDE.md) · 🇱🇹 [lt](../../../lt/docs/architecture/RESILIENCE_GUIDE.md) · 🇱🇻 [lv](../../../lv/docs/architecture/RESILIENCE_GUIDE.md) · 🇮🇳 [ml](../../../ml/docs/architecture/RESILIENCE_GUIDE.md) · 🇮🇳 [mr](../../../mr/docs/architecture/RESILIENCE_GUIDE.md) · 🇲🇾 [ms](../../../ms/docs/architecture/RESILIENCE_GUIDE.md) · 🇲🇹 [mt](../../../mt/docs/architecture/RESILIENCE_GUIDE.md) · 🇲🇲 [my](../../../my/docs/architecture/RESILIENCE_GUIDE.md) · 🇳🇵 [ne](../../../ne/docs/architecture/RESILIENCE_GUIDE.md) · 🇳🇱 [nl](../../../nl/docs/architecture/RESILIENCE_GUIDE.md) · 🇳🇴 [no](../../../no/docs/architecture/RESILIENCE_GUIDE.md) · 🇮🇳 [or](../../../or/docs/architecture/RESILIENCE_GUIDE.md) · 🇮🇳 [pa](../../../pa/docs/architecture/RESILIENCE_GUIDE.md) · 🇵🇭 [phi](../../../phi/docs/architecture/RESILIENCE_GUIDE.md) · 🇵🇱 [pl](../../../pl/docs/architecture/RESILIENCE_GUIDE.md) · 🇵🇹 [pt](../../../pt/docs/architecture/RESILIENCE_GUIDE.md) · 🇧🇷 [pt-BR](../../../pt-BR/docs/architecture/RESILIENCE_GUIDE.md) · 🇷🇴 [ro](../../../ro/docs/architecture/RESILIENCE_GUIDE.md) · 🇷🇺 [ru](../../../ru/docs/architecture/RESILIENCE_GUIDE.md) · 🇱🇰 [si](../../../si/docs/architecture/RESILIENCE_GUIDE.md) · 🇸🇰 [sk](../../../sk/docs/architecture/RESILIENCE_GUIDE.md) · 🇸🇮 [sl](../../../sl/docs/architecture/RESILIENCE_GUIDE.md) · 🇷🇸 [sr](../../../sr/docs/architecture/RESILIENCE_GUIDE.md) · 🇸🇪 [sv](../../../sv/docs/architecture/RESILIENCE_GUIDE.md) · 🇰🇪 [sw](../../../sw/docs/architecture/RESILIENCE_GUIDE.md) · 🇮🇳 [ta](../../../ta/docs/architecture/RESILIENCE_GUIDE.md) · 🇮🇳 [te](../../../te/docs/architecture/RESILIENCE_GUIDE.md) · 🇹🇭 [th](../../../th/docs/architecture/RESILIENCE_GUIDE.md) · 🇹🇷 [tr](../../../tr/docs/architecture/RESILIENCE_GUIDE.md) · 🇺🇦 [uk-UA](../../../uk-UA/docs/architecture/RESILIENCE_GUIDE.md) · 🇵🇰 [ur](../../../ur/docs/architecture/RESILIENCE_GUIDE.md) · 🇺🇿 [uz](../../../uz/docs/architecture/RESILIENCE_GUIDE.md) · 🇻🇳 [vi](../../../vi/docs/architecture/RESILIENCE_GUIDE.md) · 🇳🇬 [yo](../../../yo/docs/architecture/RESILIENCE_GUIDE.md) · 🇨🇳 [zh-CN](../../../zh-CN/docs/architecture/RESILIENCE_GUIDE.md) · 🇹🇼 [zh-TW](../../../zh-TW/docs/architecture/RESILIENCE_GUIDE.md)

---

OmniRoute ಮೂರು ವಿಭಿನ್ನವಾದರೂ ಪರಸ್ಪರ ಸಂಬಂಧಿತ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವದ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಹೊಂದಿದೆ. ಪ್ರತಿಯೊಂದಕ್ಕೂ ವಿಭಿನ್ನ ವ್ಯಾಪ್ತಿ ಮತ್ತು ಉದ್ದೇಶವಿದೆ. ರೌಟಿಂಗ್ ನಡವಳಿಕೆಯನ್ನು ಡೀಬಗ್ ಮಾಡುವಾಗ ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿರಿಸಿ.

![3-ಪದರದ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವ ಮಾದರಿ](../diagrams/exported/resilience-3layers.svg)

> ಮೂಲ: [diagrams/resilience-3layers.mmd](../diagrams/resilience-3layers.mmd)

## 1. ಪೂರೈಕೆದಾರ ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್

**ವ್ಯಾಪ್ತಿ:** ಸಂಪೂರ್ಣ ಪೂರೈಕೆದಾರ (ಉದಾ., `glm`, `openai`, `anthropic`).

**ಉದ್ದೇಶ:** ಅಪ್ಸ್ಟ್ರೀಮ್/ಸೇವಾ ಮಟ್ಟದಲ್ಲಿ ಪದೇಪದೇ ವಿಫಲವಾಗುತ್ತಿರುವ ಪೂರೈಕೆದಾರನಿಗೆ ಟ್ರಾಫಿಕ್ ಕಳುಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುವುದು.

**ಅನುಷ್ಠಾನ:**

- ಮುಖ್ಯ ಕ್ಲಾಸ್: `src/shared/utils/circuitBreaker.ts`
- ವೈರಿಂಗ್: `src/sse/handlers/chatHelpers.ts`, `src/sse/handlers/chat.ts`
- ಸ್ಥಿತಿ API: `GET /api/monitoring/health`
- ಮರುಹೊಂದಿಸುವ API: `POST /api/resilience/reset`
- ರ್ಯಾಪರ್ಗಳು: `open-sse/services/accountFallback.ts`
- DB ಟೇಬಲ್: `domain_circuit_breakers`

**ಸ್ಥಿತಿಗಳು:**

- `CLOSED` — ಸಾಮಾನ್ಯ ಟ್ರಾಫಿಕ್ಗೆ ಅನುಮತಿಯಿದೆ
- `DEGRADED` — ಟ್ರಾಫಿಕ್ಗೆ ಇನ್ನೂ ಅನುಮತಿಯಿದೆ, ಆದರೆ ಹೆಚ್ಚಿದ ಪೂರೈಕೆದಾರ ವೈಫಲ್ಯಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲಾಗುತ್ತದೆ
- `OPEN` — ಪೂರೈಕೆದಾರನನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ; ಕಾಂಬೊ ರೌಟಿಂಗ್ ಅದನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ
- `HALF_OPEN` — ಮರುಹೊಂದಿಸುವ ಕಾಲಮಿತಿ ಮುಗಿದಿದೆ; ಪ್ರೋಬ್ ವಿನಂತಿಗೆ ಅನುಮತಿಯಿದೆ

**ಸಂರಚಿಸಬಹುದಾದ ಡೀಫಾಲ್ಟ್ಗಳು (`open-sse/config/constants.ts`, ಡ್ಯಾಶ್ಬೋರ್ಡ್ → ಸೆಟ್ಟಿಂಗ್ಗಳು → ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವದಲ್ಲಿ ಲಭ್ಯ):**

| ವರ್ಗ   | ಕುಸಿತಗೊಳ್ಳುವುದು | ತೆರೆಯುವುದು   | ಮರುಹೊಂದಿಸುವ ಕಾಲಮಿತಿ |
| ------ | --------------- | ------------ | ------------------- |
| OAuth  | 5 ವೈಫಲ್ಯಗಳು     | 8 ವೈಫಲ್ಯಗಳು  | 60s                 |
| API-ಕೀ | 7 ವೈಫಲ್ಯಗಳು     | 12 ವೈಫಲ್ಯಗಳು | 30s                 |
| ಸ್ಥಳೀಯ | ಉತ್ಪನ್ನವಾದದ್ದು  | 2 ವೈಫಲ್ಯಗಳು  | 15s                 |

ಪೂರೈಕೆದಾರನು ಯಾವಾಗ `DEGRADED` ಸ್ಥಿತಿಗೆ ಪ್ರವೇಶಿಸಬೇಕು ಎಂಬುದನ್ನು `degradationThreshold` ನಿಯಂತ್ರಿಸುತ್ತದೆ; ಅದು ಯಾವಾಗ ತೆರೆಯಬೇಕು ಮತ್ತು ಬಿಟ್ಟುಬಿಡಲ್ಪಡಬೇಕು ಎಂಬುದನ್ನು `failureThreshold` ನಿಯಂತ್ರಿಸುತ್ತದೆ. ಸ್ಥಳೀಯ ಪೂರೈಕೆದಾರ ಪ್ರೊಫೈಲ್ಗಳು ಇನ್ನೂ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವದ ಸೆಟ್ಟಿಂಗ್ಗಳ ಪುಟದಲ್ಲಿ ಲಭ್ಯವಿಲ್ಲ.

**ಟ್ರಿಪ್ ಕೋಡ್ಗಳು:** ಪೂರೈಕೆದಾರ-ಮಟ್ಟದ ಸ್ಥಿತಿಗಳು `[408, 500, 502, 503, 504]` ಮಾತ್ರ. ಖಾತೆ-ಮಟ್ಟದ ದೋಷಗಳಿಗೆ (ಹೆಚ್ಚಿನ 401/403/429 — ಅವು ಕೂಲ್ಡೌನ್ ಅಥವಾ ಲಾಕ್ಔಟ್ಗೆ ಸೇರಿವೆ) ಟ್ರಿಪ್ ಮಾಡಬೇಡಿ.

**ಲೇಝಿ ಮರುಪಡೆಯುವಿಕೆ:** `OPEN` ಅವಧಿ ಮುಗಿದಾಗ, `getStatus()`, `canExecute()`, `getRetryAfterMs()` ಸ್ಥಿತಿಯನ್ನು `HALF_OPEN` ಆಗಿ ನವೀಕರಿಸುತ್ತವೆ. ಯಾವುದೇ ಹಿನ್ನೆಲೆ ಟೈಮರ್ ಅಗತ್ಯವಿಲ್ಲ.

---

### ಆಯ್ಕೆಮಾಡಿ ಸಕ್ರಿಯಗೊಳಿಸಬಹುದಾದ ಜಾಗತಿಕ ಪೂರೈಕೆದಾರ ಕೂಲ್ಡೌನ್ (ವಿಂಡೋ ಗೇಟ್)

ನಾಲ್ಕನೇ, **ಆಯ್ಕೆಮಾಡಿ ಸಕ್ರಿಯಗೊಳಿಸಬಹುದಾದ** ಪದರವು (`PROVIDER_COOLDOWN_ENABLED`, ಡೀಫಾಲ್ಟ್ ಆಗಿ **ಆಫ್**) ವಿಫಲಗೊಳ್ಳುತ್ತಿರುವ ಪೂರೈಕೆದಾರರ ಕ್ರಾಸ್-ವಿನಂತಿ ಸ್ಮರಣೆಯನ್ನು
`open-sse/services/providerCooldownTracker.ts` ನಲ್ಲಿ ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ; ಇದನ್ನು ಕಾಂಬೊ ಗುರಿ
ರೆಸಲ್ಯೂಷನ್ ಪರಿಶೀಲಿಸುವುದರಿಂದ, ಅನುಕ್ರಮ ಕಾಂಬೊ ವಿನಂತಿಗಳು ಆಗಷ್ಟೇ
ವಿಫಲವಾದ ಪೂರೈಕೆದಾರನನ್ನು ಪುನಃ ಪರಿಶೀಲಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತವೆ. ಪೂರೈಕೆದಾರ-ಮಟ್ಟದ ನಮೂದುಗಳು `PROVIDER_PROFILES` ವಿಂಡೋ ಗೇಟ್ ಅನ್ನು ಪಾಲಿಸುತ್ತವೆ:

| ಪ್ರೊಫೈಲ್ | ಇಷ್ಟು ವೈಫಲ್ಯಗಳ ನಂತರ ಟ್ರಿಪ್ ಆಗುತ್ತದೆ (`providerFailureThreshold`) | ಈ ಅವಧಿಯೊಳಗೆ (`providerFailureWindowMs`) | ಇಷ್ಟು ಅವಧಿಗೆ ಕೂಲ್ ಆಗುತ್ತದೆ (`providerCooldownMs`) |
| -------- | ---------------------------------------------------------------: | --------------------------------------: | ------------------------------------------------: |
| OAuth    |                                                             `10` |                                 `15min` |                                            `5min` |
| API ಕೀ   |                                                             `15` |                                 `30min` |                                           `10min` |

ಮಿತಿಗಿಂತ ಕೆಳಗಿರುವಾಗ ಪೂರೈಕೆದಾರನು ಕೂಲ್ಡೌನ್ನಲ್ಲಿದ್ದಾನೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುವುದಿಲ್ಲ; ಒಂದು ಯಶಸ್ಸು
ವಿಂಡೋವನ್ನು ತೆರವುಗೊಳಿಸುತ್ತದೆ. ಸಂಪರ್ಕ-ಮಟ್ಟದ ನಮೂದುಗಳು (`provider:connectionId`) ಬದಲಾಗಿ
ಘಾತೀಯ `minRetryCooldownMs → maxRetryCooldownMs` ಬ್ಯಾಕ್ಆಫ್ ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತವೆ. ಓವರ್ರೈಡ್ಗಳು:
`OMNIROUTE_PROVIDER_BREAKER_{OAUTH,API_KEY}_{FAILURE_THRESHOLD,FAILURE_WINDOW_MS,COOLDOWN_MS}`.
ರಿಗ್ರೆಷನ್ ರಕ್ಷಣೆ: `tests/unit/provider-cooldown-window-gate.test.ts`.

## 2. ಸಂಪರ್ಕ ಕೂಲ್ಡೌನ್

**ವ್ಯಾಪ್ತಿ:** ಒಂದೇ ಪೂರೈಕೆದಾರ ಸಂಪರ್ಕ/ಖಾತೆ/ಕೀಲಿ.

**ಉದ್ದೇಶ:** ಅದೇ ಪೂರೈಕೆದಾರದ ಇತರ ಸಂಪರ್ಕಗಳು ಸೇವೆ ಒದಗಿಸುವುದನ್ನು ಮುಂದುವರಿಸುವಾಗ, ಒಂದು ದೋಷಪೂರಿತ ಕೀಲಿಯನ್ನು ಬಿಟ್ಟುಬಿಡುವುದು.

**ಅನುಷ್ಠಾನ:**

- ಲಭ್ಯವಿಲ್ಲ ಎಂದು ಗುರುತಿಸುವುದು: `src/sse/services/auth.ts::markAccountUnavailable()`
- ಆಯ್ಕೆ: ಅದೇ ಫೈಲ್ನಲ್ಲಿರುವ `getProviderCredentials*`
- ಕೂಲ್ಡೌನ್ ಲೆಕ್ಕಾಚಾರ: `open-sse/services/accountFallback.ts::checkFallbackError()`
- ಸೆಟ್ಟಿಂಗ್ಗಳು: `src/lib/resilience/settings.ts`

**ಪ್ರತಿ ಸಂಪರ್ಕದ ಫೀಲ್ಡ್ಗಳು:**

- `rateLimitedUntil` — ಕೂಲ್ಡೌನ್ ಅವಧಿ ಮುಗಿಯುವವರೆಗಿನ ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್
- `testStatus: "unavailable"`
- `lastError`, `lastErrorType`, `errorCode`
- `backoffLevel` — ಘಾತೀಯ ಬ್ಯಾಕ್ಆಫ್ ಕೌಂಟರ್

**ಡೀಫಾಲ್ಟ್ ಕೂಲ್ಡೌನ್ಗಳು:**

- OAuth ಮೂಲ ಅವಧಿ: 5s
- API-key ಮೂಲ ಅವಧಿ: 3s
- API-key 429: ಅಪ್ಸ್ಟ್ರೀಮ್ನ `Retry-After`/ರೀಸೆಟ್ ಹೆಡರ್ಗಳು/ಪಾರ್ಸ್ ಮಾಡಬಹುದಾದ ರೀಸೆಟ್ ಪಠ್ಯಕ್ಕೆ ಆದ್ಯತೆ ನೀಡುತ್ತದೆ
- ಬ್ಯಾಕ್ಆಫ್: `baseCooldownMs * 2 ** failureIndex`

**ಥಂಡರಿಂಗ್-ಹರ್ಡ್ ವಿರೋಧಿ ರಕ್ಷಣೆ:** ಏಕಕಾಲೀನ ವೈಫಲ್ಯಗಳು ಕೂಲ್ಡೌನ್ ಅನ್ನು ಅತಿಯಾಗಿ ವಿಸ್ತರಿಸುವುದನ್ನು ಅಥವಾ `backoffLevel` ಅನ್ನು ಎರಡು ಬಾರಿ ಹೆಚ್ಚಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ.

**ಅಂತಿಮ ಸ್ಥಿತಿಗಳು (ಕೂಲ್ಡೌನ್ಗಳಲ್ಲ):**

- `banned` — ನಿಷೇಧಿತ-ಕೀವರ್ಡ್ / ಖಾತೆ-ನಿಷೇಧ ಪತ್ತೆಹಚ್ಚುವಿಕೆಯಿಂದ ಹೊಂದಿಸಲಾಗುತ್ತದೆ ([BAN_DETECTION](../security/BAN_DETECTION.md) ನೋಡಿ), ಹಾಗೆಯೇ ಸತತ ಮೂರು ಅಪ್ಸ್ಟ್ರೀಮ್ ಪ್ರತಿ-ವಿನಂತಿ ನಿರಾಕರಣೆಗಳಿಂದಲೂ (`request_rejected`, ಉದಾ. Anthropic OAuth 403 "ವಿನಂತಿಗೆ ಅನುಮತಿಯಿಲ್ಲ" — `open-sse/services/requestRejectedStreak.ts`) ಹೊಂದಿಸಲಾಗುತ್ತದೆ; ಒಂದೇ ನಿರಾಕರಣೆಯು ಸಂಪರ್ಕವನ್ನು ಕೇವಲ ಕೂಲ್ಡೌನ್ಗೆ ಒಳಪಡಿಸುತ್ತದೆ
- `expired` (ಮಿತಿಗೊಳಿಸಿದ ಮರುಪ್ರಯತ್ನಗಳ ನಂತರ ಅಂತಿಮ ಸ್ಥಿತಿಗೆ ಪರಿವರ್ತಿಸುತ್ತದೆ — ಘಾತೀಯ ಬ್ಯಾಕ್ಆಫ್ನೊಂದಿಗೆ `EXPIRED_RETRY_MAX = 3` — ಇದರಿಂದ ತಾತ್ಕಾಲಿಕ OAuth ದೋಷಗಳು ಖಾತೆಯನ್ನು ಶಾಶ್ವತವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ಮೊದಲು ಸ್ವಯಂ-ಚೇತರಿಸಿಕೊಳ್ಳಬಹುದು)
- `credits_exhausted`

ರುಜುವಾತುಗಳು ಬದಲಾಗುವವರೆಗೆ ಅಥವಾ ನಿರ್ವಾಹಕರು ಅವುಗಳನ್ನು ರೀಸೆಟ್ ಮಾಡುವವರೆಗೆ ಇವು ಉಳಿಯುತ್ತವೆ. ತಾತ್ಕಾಲಿಕ ಕೂಲ್ಡೌನ್ ಸ್ಥಿತಿಯಿಂದ ಅಂತಿಮ ಸ್ಥಿತಿಗಳನ್ನು ಓವರ್ರೈಟ್ ಮಾಡಬೇಡಿ.

**ವಿಳಂಬಿತ ಚೇತರಿಕೆ:** `rateLimitedUntil` ಸಮಯ ಕಳೆದಾಗ, ಸಂಪರ್ಕವು ಮತ್ತೆ ಅರ್ಹವಾಗುತ್ತದೆ. ಯಶಸ್ವಿ ಬಳಕೆಯಾದಾಗ, `clearAccountError()` ಎಲ್ಲಾ ದೋಷ ಫೀಲ್ಡ್ಗಳನ್ನು ತೆರವುಗೊಳಿಸುತ್ತದೆ.

### Claude OAuth ಬಳಕೆ ಮಿತಿ: ಕಡಿಮೆ-ಆದ್ಯತೆಯ ಲೇನ್ + ಸೆಷನ್-ಮಿತಿ ರೀಸೆಟ್

**ವ್ಯಾಪ್ತಿ:** ಒಂದು Claude ಚಂದಾದಾರಿಕೆ (OAuth) ಸಂಪರ್ಕ. ಎರಡೂ ವೈಶಿಷ್ಟ್ಯಗಳು **ಪ್ರತಿ
ಸಂಪರ್ಕಕ್ಕೂ ಆಯ್ಕೆಮಾಡಿದರೆ ಮಾತ್ರ ಸಕ್ರಿಯವಾಗುತ್ತವೆ** (ಸಂಪರ್ಕ ಸಂಪಾದಿಸಿ → Claude ವಿಭಾಗ → `lowPriorityMode` / `autoLimitReset` ಅನ್ನು
`providerSpecificData` ನಲ್ಲಿ ಹೊಂದಿಸಿ, ಎರಡೂ ಡೀಫಾಲ್ಟ್ ಆಗಿ ಆಫ್ ಆಗಿರುತ್ತವೆ) ಮತ್ತು Claude Code ನ `/low-priority` ಹಾಗೂ
`/limit-reset` ಕಮಾಂಡ್ಗಳನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತವೆ (ವೈರ್ ಒಪ್ಪಂದವನ್ನು Claude Code 2.1.263 ನಿಂದ ದಾಖಲಿಸಲಾಗಿದೆ).

**ಅನುಷ್ಠಾನ:**

- ಸ್ಟೇಟ್ ಮೆಷಿನ್ + ಪ್ರತಿಕ್ರಿಯೆ ವರ್ಗೀಕರಣ: `open-sse/services/claudeLowPriority.ts`
- ರೀಸೆಟ್ ಸ್ಥಿತಿ/ಕ್ಲೇಮ್ ಕ್ಲೈಂಟ್: `open-sse/services/claudeLimitReset.ts`
- ಎಕ್ಸಿಕ್ಯೂಟರ್ ಹುಕ್ (ಹೆಡರ್ ಇಂಜೆಕ್ಷನ್ + ಅದೇ-ಖಾತೆಯ ಮರುಪ್ರಯತ್ನ): `open-sse/executors/base.ts::execute()`
- ಆಯ್ಕೆಮಾಡುವಿಕೆಯ ನಿರಂತರ ಸಂಗ್ರಹಣೆ: `src/lib/providers/requestDefaults.ts::normalizeProviderSpecificData()`

**ಟ್ರಿಗರ್:** 5-ಗಂಟೆಯ ಬಳಕೆ ಮಿತಿ — ಅದರ ಹೆಡರ್ಗಳಲ್ಲಿ
`anthropic-ratelimit-unified-status: rejected` ಇರುವ `429` ಮತ್ತು, ಖಾತೆ ಅರ್ಹವಾಗಿದ್ದಾಗ,
`anthropic-ratelimit-unified-slow-offer: treatment`. ಆ ಮೊದಲ ಮಿತಿ
429 ಕ್ಕಿಂತ ಮೊದಲು ಏನನ್ನೂ ಕಳುಹಿಸಲಾಗುವುದಿಲ್ಲ; ಏಕೀಕೃತ ಹೆಡರ್ಗಳಿಲ್ಲದ ಬರ್ಸ್ಟ್ 429 ಸಾಮಾನ್ಯ ಕೂಲ್ಡೌನ್ ಮಾರ್ಗದ ಮೂಲಕ ಸಾಗುತ್ತದೆ.

**ಕಡಿಮೆ-ಆದ್ಯತೆಯ ಲೇನ್** (`lowPriorityMode`):

- ಮಿತಿ 429 ಬಂದಾಗ ಎಕ್ಸಿಕ್ಯೂಟರ್ ಆಫರ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿ, ತಕ್ಷಣವೇ **ಅದೇ**
  ಖಾತೆಯಲ್ಲಿ `anthropic-usage-limit: slow` ಜೊತೆಗೆ ಮರುಪ್ರಯತ್ನಿಸುತ್ತದೆ; ಘೋಷಿಸಲಾದ
  `anthropic-ratelimit-unified-reset` (+60s ಗ್ರೇಸ್ ಅವಧಿ) ವರೆಗೆ ಲೇನ್ ಸಕ್ರಿಯವಾಗಿರುತ್ತದೆ ಮತ್ತು ಆ ಅವಧಿಯ ಪ್ರತಿಯೊಂದು ವಿನಂತಿಯೂ
  ಹೆಡರ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ತಡೆಹಿಡಿಯಲಾದ 429 ಎಂದಿಗೂ `handleChatCore` ತಲುಪುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಸಂಪರ್ಕವನ್ನು
  ಕೂಲ್ಡೌನ್ಗೆ ಒಳಪಡಿಸಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಬೇರೆ ಸಂಪರ್ಕಕ್ಕೆ ತಿರುಗಿಸಲಾಗುವುದಿಲ್ಲ.
- ನಂತರದ ಪ್ರತಿಕ್ರಿಯೆಗಳಲ್ಲಿನ `anthropic-ratelimit-unified-slow-status`: `active` / `not_needed`
  ಲೇನ್ ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತವೆ; `slot_busy` (429) ಅಥವಾ `529`, ಸರ್ವರ್ನ
  `anthropic-ratelimit-unified-slow-retry-after` ಅವಧಿ ಕಾಯುತ್ತದೆ (ಡೀಫಾಲ್ಟ್ 20s, 5–600s ಗೆ ಕ್ಲ್ಯಾಂಪ್, ±30% ಜಿಟ್ಟರ್)
  ಮತ್ತು `anthropic-ratelimit-unified-slow-max-wait` ನಿಂದ ಮಿತಿಗೊಳಿಸಿಕೊಂಡು ಮರುಪ್ರಯತ್ನಿಸುತ್ತದೆ (ಡೀಫಾಲ್ಟ್ 20 min, ಕ್ಲ್ಯಾಂಪ್
  1 min–6 h) — ಅದನ್ನು ಮೀರಿದಾಗ ಲೇನ್ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು 10-ನಿಮಿಷದ ಕೂಲ್-ಆಫ್ ಮರು-ಸ್ವೀಕಾರವನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆ.
  ವಿನಂತಿಯ ಸ್ವಂತ ಅಪ್ಸ್ಟ್ರೀಮ್-ಪ್ರಾರಂಭ ಟೈಮ್ಔಟ್ನಲ್ಲಿ ಉಳಿದಿರುವ ಅವಧಿಯಿಂದ
  (`resolveFetchStartTimeout`, ಡೀಫಾಲ್ಟ್ ಆಗಿ 10 min) 5 s ಮಾರ್ಜಿನ್ ಕಳೆದು ಸಿಗುವ ಮಿತಿಗೆ ಕಾಯುವಿಕೆಯನ್ನು ಹೆಚ್ಚುವರಿಯಾಗಿ ಸೀಮಿತಗೊಳಿಸಲಾಗುತ್ತದೆ: ಆ ಮಿತಿಯಿಲ್ಲದೆ,
  20-ನಿಮಿಷದ ಡೀಫಾಲ್ಟ್ ಗರಿಷ್ಠ-ಕಾಯುವಿಕೆ ವಿನಂತಿಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಮುಂದುವರಿಯುತ್ತದೆ ಮತ್ತು ಕಾಯುವಿಕೆಯ ಮಧ್ಯದಲ್ಲೇ ಸ್ಲೀಪ್ ರದ್ದುಗೊಂಡು,
  ಸಮರ್ಪಕವಾದ `max_wait` ಅಂತ್ಯ + ಕೂಲ್-ಆಫ್ ಬದಲಿಗೆ `TimeoutError` ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ.
- `weekly_limit` / `budget_exhausted` / `off` / `ineligible`, 5h-ವಿಂಡೋ ರೋಲ್ಓವರ್, ಅಥವಾ
  `ineligible` + `anthropic-ratelimit-unified-overage-in-use: true` (ಪಾವತಿಸಿದ ಹೆಚ್ಚುವರಿ ಬಳಕೆ ಈಗ ಮಿತಿಯನ್ನು ಒಳಗೊಳ್ಳುವುದರಿಂದ, ಯಾವುದೇ ಸ್ಥಿತಿಯಲ್ಲೂ ಅದನ್ನು
  `extra_usage` ಆಗಿ ಅಂತ್ಯಗೊಳಿಸುತ್ತದೆ) ಲೇನ್ ಅನ್ನು ಕೊನೆಗೊಳಿಸುತ್ತವೆ; ನಂತರ
  ಪ್ರತಿಕ್ರಿಯೆಯು ಸಾಮಾನ್ಯ ಕೂಲ್ಡೌನ್ ಮಾರ್ಗದ ಮೂಲಕ ಸಾಗುತ್ತದೆ. ಘೋಷಿಸಲಾದ ಬಜೆಟ್ ರೀಸೆಟ್ವರೆಗೆ
  `budget_exhausted` ಅನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳಲಾಗುತ್ತದೆ (≤ 8 days).
- ಮಿತಿ ಪರಿಶೀಲನೆಯು ಎಕ್ಸಿಕ್ಯೂಟರ್ನ ಸ್ವಂತ 400-ಚಾಲಿತ ಪ್ರಯತ್ನದೊಳಗಿನ ಮರುಪ್ರಯತ್ನಗಳ ನಂತರ ನಡೆಯುತ್ತದೆ (ಕಾಂಟೆಕ್ಸ್ಟ್
  ಎಡಿಟಿಂಗ್, ಚಿಂತನೆ/ಪ್ರಯತ್ನದ ಕ್ಲ್ಯಾಂಪ್ಗಳು, ಪ್ಯಾರಾಮೀಟರ್ ಸ್ವಯಂ-ಕಲಿಕೆ), ಆದ್ದರಿಂದ ಆ ಮರುಪ್ರಯತ್ನಗಳಲ್ಲಿ ಒಂದರಲ್ಲಷ್ಟೇ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಮಿತಿ 429 ಕೂಡ
  ಕೂಲ್ಡೌನ್ ಮಾರ್ಗವನ್ನು ತಲುಪುವ ಬದಲು ತಡೆಹಿಡಿಯಲ್ಪಡುತ್ತದೆ.
- ಸ್ಥಿತಿಯನ್ನು ಪ್ರತಿ ಸಂಪರ್ಕಕ್ಕೆ ಇನ್-ಮೆಮೊರಿಯಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ (ರೀಸ್ಟಾರ್ಟ್ ಮಾಡಿದರೆ ಮರು-ಸ್ವೀಕಾರಕ್ಕಾಗಿ ಒಂದು ಹೆಚ್ಚುವರಿ ಮಿತಿ 429 ಬೇಕಾಗುತ್ತದೆ).

**ಸೆಷನ್-ಮಿತಿ ರೀಸೆಟ್** (`autoLimitReset`, ಎರಡೂ ಆನ್ ಆಗಿರುವಾಗ ಲೇನ್ಗಿಂತ ಮೊದಲು ಪ್ರಯತ್ನಿಸಲಾಗುತ್ತದೆ):

- `GET https://api.anthropic.com/api/oauth/usage?at_wall=1&skip_spend=1` → `juniper_tide`
  ಬ್ಲಾಕ್; `arm: "reset"` ಮತ್ತು `available: true` ಆಗಿರುವಾಗ,
  `POST https://api.anthropic.com/api/organizations/{orgUUID}/reset_rate_limits` ಅನ್ನು
  `{ "program": "juniper_tide" }` ಜೊತೆಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ (`providerSpecificData.organizationUUID` ನಿಂದ ಸಂಸ್ಥೆಯ UUID,
  ಬೂಟ್ಸ್ಟ್ರ್ಯಾಪ್ ಫಾಲ್ಬ್ಯಾಕ್).
- `result: reset|not_limited` → ವಿನಂತಿಯನ್ನು ಪೂರ್ಣ ವೇಗದಲ್ಲಿ ಮರುಪ್ರಯತ್ನಿಸಲಾಗುತ್ತದೆ (ಸ್ಲೋ ಹೆಡರ್ ಇಲ್ಲ).
  `already_used` / `not_offered`, `next_available_at` ಅನ್ನು ಮೆಮೊಯಿಸ್ ಮಾಡುತ್ತವೆ (ಡೀಫಾಲ್ಟ್ ಒಂದು ವಾರ); ಯಾವುದೇ
  ವೈಫಲ್ಯವು 15 ನಿಮಿಷಗಳವರೆಗೆ ಬ್ಯಾಕ್ಆಫ್ ಆಗುತ್ತದೆ. ರೀಸೆಟ್ ವಾರಕ್ಕೊಮ್ಮೆ ಮಾತ್ರ ಲಭ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಅದು ಇನ್ನೂ
  ವಾರದ ಮಿತಿಯಲ್ಲಿ ಲೆಕ್ಕವಾಗುತ್ತದೆ.

ರಿಗ್ರೆಷನ್ ರಕ್ಷಣೆಗಳು: `tests/unit/claude-low-priority-mode.test.ts`,
`tests/unit/claude-limit-reset.test.ts`, `tests/unit/claude-low-priority-executor.test.ts`.

### ಸೆಷನ್ ಅಫಿನಿಟಿ (#7274)

**ವ್ಯಾಪ್ತಿ:** **ಯಾವುದೇ** ಪೂರೈಕೆದಾರಕ್ಕಾಗಿ, ಒಂದು ಸಂಪರ್ಕಕ್ಕೆ ಪಿನ್ ಮಾಡಲಾದ ಒಂದು ಕ್ಲೈಂಟ್ ಸೆಷನ್ (`X-Session-Id` / `x-codex-session-id` / `x-omniroute-session` ಹೆಡರ್).

**ಉದ್ದೇಶ:** ಬಹು-ತಿರುವಿನ ಏಜೆಂಟ್ ಅನ್ನು (Claude Code, aider, ಕಸ್ಟಮ್ ಏಜೆಂಟ್ಗಳು) ವಿನಂತಿಗಳಾದ್ಯಂತ ಅದೇ ಖಾತೆಯಲ್ಲಿ ಉಳಿಸುವುದು; ಇದರಿಂದ ಪ್ರತಿ-ಖಾತೆ ಸೆಷನ್ ಸ್ಥಿತಿಯನ್ನು ಹೊಂದಿರುವ ಪೂರೈಕೆದಾರರಲ್ಲಿ ಖಾತೆಗಳ ನಡುವಿನ ಸಂದರ್ಭ ನಷ್ಟ ಮತ್ತು ಪುನರಾವರ್ತಿತ ಕೋಲ್ಡ್-ಸ್ಟಾರ್ಟ್ 429ಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು.

**ಅನುಷ್ಠಾನ:**

- TTL ನಿರ್ಣಯ: `src/sse/services/sessionAffinityPin.ts::resolveSessionAffinityTtlMs()`
- ಪಿನ್ ಆಯ್ಕೆ/ರಚನೆ: `src/sse/services/sessionAffinityPin.ts::selectSessionAffinityConnection()`
- ಹೆಡರ್ ಹೊರತೆಗೆಯುವಿಕೆ (ಸಾಮಾನ್ಯ, ಯಾವುದೇ ಪೂರೈಕೆದಾರ): `src/sse/services/auth.ts::extractSessionAffinityKey()`
- ಸ್ಥಿರವಾಗಿ ಸಂಗ್ರಹಿಸಲಾದ ಪಿನ್ ಕೋಷ್ಟಕ: `sessionAccountAffinity` (`src/lib/db/sessionAccountAffinity.ts`)
- ಸೆಟ್ಟಿಂಗ್: `sessionAffinityTtlMs` (ms ನಲ್ಲಿ ಜಾಗತಿಕ TTL, `0` ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ) — `src/lib/db/settings.ts`. ಇದನ್ನು Codexಗೆ ಮಾತ್ರ ಸೀಮಿತವಾಗಿದ್ದ `codexSessionAffinityTtlMs` ನಿಂದ `124_generic_session_affinity_ttl.sql` ಮೈಗ್ರೇಶನ್ ಮೂಲಕ ಮರುಹೆಸರಿಸಲಾಗಿದೆ; ಇದು ಹಿಂದೆ ಸಂರಚಿಸಲಾದ ಯಾವುದೇ Codex TTL ಅನ್ನು ಹೊಸ ಡೀಫಾಲ್ಟ್ ಆಗಿ ವರ್ಗಾಯಿಸುತ್ತದೆ.

#7274 ಕ್ಕಿಂತ ಮೊದಲು, `resolveSessionAffinityTtlMs()` ಎಂಬುದು `codex` ಹೊರತುಪಡಿಸಿ ಪ್ರತಿಯೊಂದು ಪೂರೈಕೆದಾರಕ್ಕೂ ನೇರವಾಗಿ `0` ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತಿತ್ತು; ಆದ್ದರಿಂದ ಪಿನ್ನಿಂಗ್ ಕಾರ್ಯವಿಧಾನ ಮತ್ತು ಹೆಡರ್ ಹೊರತೆಗೆಯುವಿಕೆ ಈಗಾಗಲೇ ಪೂರೈಕೆದಾರ-ಸ್ವತಂತ್ರವಾಗಿದ್ದರೂ, TTL ಸೆಟ್ಟಿಂಗ್ (ಮತ್ತು ಸೆಷನ್ ಹೆಡರ್ಗಳು) ಬೇರೆಲ್ಲಿಯೂ ಪರಿಣಾಮ ಬೀರುತ್ತಿರಲಿಲ್ಲ. ಸರಿಪಡಿಸುವಿಕೆಯು ಆ ಮುಂಚಿನ ಹಿಂತಿರುಗುವಿಕೆಯನ್ನು ತೆಗೆದುಹಾಕಿದೆ; ಈಗ TTL ಅನ್ನು ಜಾಗತಿಕವಾಗಿ `0` ಕ್ಕಿಂತ ಹೆಚ್ಚಿನದಾಗಿ ಹೊಂದಿಸಿದ ನಂತರ ಅದು ಪ್ರತಿಯೊಂದು ಪೂರೈಕೆದಾರಕ್ಕೂ ಏಕರೂಪವಾಗಿ ಅನ್ವಯಿಸುತ್ತದೆ.

ಮೂರು ಸೆಷನ್-ಅಫಿನಿಟಿ ಹೆಡರ್ಗಳನ್ನು ಎಂದಿಗೂ ಅಪ್ಸ್ಟ್ರೀಮ್ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಲಾಗುವುದಿಲ್ಲ — ಎಕ್ಸಿಕ್ಯೂಟರ್ಗಳು ಕ್ಲೈಂಟ್ ಹೆಡರ್ಗಳನ್ನು ಹಾಗೆಯೇ ರವಾನಿಸುವ ಬದಲು ತಮ್ಮದೇ ಅಪ್ಸ್ಟ್ರೀಮ್ ಹೆಡರ್ಗಳನ್ನು ಮೊದಲಿನಿಂದ ನಿರ್ಮಿಸುತ್ತವೆ; ಆದ್ದರಿಂದ ಇದು ಆಂತರಿಕ ಸಹಸಂಬಂಧ ID ಆಗಿಯೇ ಉಳಿಯುತ್ತದೆ.

### ವಿಶೇಷ ನಿರ್ವಹಿತ ಸೆಷನ್ ಸಂಪರ್ಕ ಲೀಸ್ಗಳು

**ವ್ಯಾಪ್ತಿ:** ಒಂದು ಸಕ್ರಿಯ ನಿರ್ವಹಿತ HTTP ಕ್ಲೈಂಟ್/ಸೆಷನ್ ಒಂದು ಅರ್ಹ OmniRoute ಸಂಪರ್ಕದ ಮಾಲೀಕತ್ವವನ್ನು ಹೊಂದಿರುತ್ತದೆ.

**ಉದ್ದೇಶ:** ವಿನಂತಿಗಳಾದ್ಯಂತ ಕಠಿಣ ರೂಟಿಂಗ್ ಗಡಿ ಅಗತ್ಯವಿರುವ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ದೀರ್ಘಕಾಲಿಕ ವಿಶೇಷ ಸಂಪರ್ಕ ಮಾಲೀಕತ್ವವನ್ನು ಒದಗಿಸುವುದು. ಇದು ಮೃದು ನಿರಂತರತೆಯ ಆದ್ಯತೆಯಾಗಿರುವ ಸೆಷನ್ ಅಫಿನಿಟಿಗಿಂತ ಭಿನ್ನವಾಗಿದೆ: ವಿಶೇಷ ಲೀಸ್ SQLite ನಲ್ಲಿ ಜೀವನಚಕ್ರ ಸ್ಥಿತಿಯನ್ನು ಉಳಿಸುತ್ತದೆ, ಜಾಗತಿಕ ಸಕ್ರಿಯ-ಮಾಲೀಕ ಮತ್ತು ಸಕ್ರಿಯ-ಸಂಪರ್ಕ ಅನನ್ಯತೆಯನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತದೆ ಹಾಗೂ ಪೂರೈಕೆದಾರರಿಗೆ ರವಾನಿಸುವ ಮೊದಲು ಹಳತಾದ ಜನರೇಶನ್ ಅನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ.

ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಪ್ರತಿ API ಕೀಲಿಗೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಆಯ್ಕೆಮಾಡಿ ಸಕ್ರಿಯಗೊಳಿಸಬೇಕು. ನಿರ್ವಹಿತ ಕೀಲಿಯು `lease:exclusive` ಸ್ಕೋಪ್ ಮತ್ತು ಸ್ಪಷ್ಟವಾದ, ಖಾಲಿಯಲ್ಲದ `allowedConnections` ಪಟ್ಟಿಯನ್ನು ಹೊಂದಿರಬೇಕು. ಯಾವುದೇ HTTP ಕ್ಲೈಂಟ್ ಜೀವನಚಕ್ರ ಎಂಡ್ಪಾಯಿಂಟ್ ಅನ್ನು ಬಳಸಬಹುದು; ಯಾವುದೇ ಕ್ಲೈಂಟ್ ಹೆಸರು, ಯೂಸರ್-ಏಜೆಂಟ್, ಪೂರೈಕೆದಾರ, OAuth ವಿಧಾನ ಅಥವಾ ಮಾದರಿ ಅಗತ್ಯವಿಲ್ಲ. ಲೀಸ್ ಸಂಪರ್ಕದ ಮಾಲೀಕತ್ವವನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಮಾದರಿಯದ್ದಲ್ಲ; ಆದ್ದರಿಂದ ಸಂಪರ್ಕವು ಸಾಮಾನ್ಯವಾಗಿ ಅರ್ಹವಾಗಿರುವವರೆಗೆ ಮಾದರಿಯ ಬದಲಾವಣೆಯು ಬೈಂಡಿಂಗ್ ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಸಾಮಾನ್ಯ ಮಾದರಿ, ಕೋಟಾ, ಆರೋಗ್ಯ, ಕೂಲ್ಡೌನ್ ಮತ್ತು ಅನುಮತಿ-ಪಟ್ಟಿ ನಿಯಮಗಳು ಅಧಿಕೃತವಾಗಿಯೇ ಉಳಿಯುತ್ತವೆ ಮತ್ತು ಅದೇ ಜನರೇಶನ್ ಅನ್ನು ಮತ್ತೊಂದು ಮುಕ್ತ ಅರ್ಹ ಸಂಪರ್ಕಕ್ಕೆ ವರ್ಗಾಯಿಸಬಹುದು.

ಜೀವನಚಕ್ರವು `acquire`, `renew`, ಮತ್ತು `release` JSON ಕ್ರಿಯೆಗಳೊಂದಿಗೆ `POST /api/v1/session-leases` ಆಗಿದೆ. ನಿರ್ವಹಿತ ಇನ್ಫರೆನ್ಸ್ ವಿನಂತಿಗಳು ಅಪಾರದರ್ಶಕ `X-OmniRoute-Lease-Owner` ಮೌಲ್ಯ ಮತ್ತು ನಿಖರವಾದ `X-OmniRoute-Lease-Generation` ಅನ್ನು ಒದಗಿಸುತ್ತವೆ. ಮಾಲೀಕ ಮೌಲ್ಯವು `vlo_` ನಂತರ 43 base64url ಅಕ್ಷರಗಳನ್ನು ಬಳಸುತ್ತದೆ; ಅದರ SHA-256 ಹ್ಯಾಶ್ ಅನ್ನು ಮಾತ್ರ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಅಂತಿಮ ಡಿಸ್ಪ್ಯಾಚ್ ಗಡಿಯು ದೃಢೀಕರಿಸಲಾದ API ಕೀ ID ಮತ್ತು ಸಕ್ರಿಯ ಸಂಪರ್ಕ ID ಯನ್ನೂ ಬಂಧಿಸುತ್ತದೆ. ಲೀಸ್ ನಿಯಂತ್ರಣ ಹೆಡರ್ಗಳನ್ನು ಲಾಗ್ಗಳು, ಉಳಿಸಿಕೊಂಡ ವಿನಂತಿ ಸ್ನ್ಯಾಪ್ಶಾಟ್ಗಳು ಮತ್ತು ಅಪ್ಸ್ಟ್ರೀಮ್ ಎಕ್ಸಿಕ್ಯೂಟರ್ ಹೆಡರ್ಗಳಿಂದ ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ.

ಸಾಮಾನ್ಯ ರೂಟಿಂಗ್ ಅರ್ಹ ನಿರ್ವಹಿತ ಅಭ್ಯರ್ಥಿಗಳನ್ನು ಹೊಂದಿದ್ದರೂ, ಪ್ರತಿಯೊಂದು ಮುಕ್ತ ಅಭ್ಯರ್ಥಿಯೂ ಬೇರೊಬ್ಬರ ಸಕ್ರಿಯ ಲೀಸ್ನ ವಶದಲ್ಲಿದ್ದರೆ, OmniRoute HTTP `429`, lease-capacity-unavailable ಕೋಡ್, ಸಾಮರ್ಥ್ಯಕ್ಕಾಗಿ-ಕಾಯುತ್ತಿರುವ ಸ್ಥಿತಿ ಮತ್ತು ಅತ್ಯಂತ ಸಮೀಪದ ಸಂಬಂಧಿತ ಅವಧಿ ಮುಕ್ತಾಯದಿಂದ ಲೆಕ್ಕಿಸಲಾದ ಮಿತಿಗೊಳಿಸಿದ `Retry-After` ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಸಾಮಾನ್ಯ ಖಾಲಿ ಅರ್ಹತೆಯು ಲೀಸ್ ಪೈಪೋಟಿಯಲ್ಲ ಮತ್ತು ಅದರ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ರೂಟಿಂಗ್ ದೋಷದ ಅರ್ಥವ್ಯವಸ್ಥೆಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ.

ಸಂಬಂಧಿತ ಕಾರ್ಯವಿಧಾನಗಳು ಪ್ರತ್ಯೇಕವಾಗಿಯೇ ಉಳಿಯುತ್ತವೆ:

- OAuth ಸೆಷನ್ ಆಕ್ಯುಪೆನ್ಸಿಯು OAuth ಖಾತೆಗಳಿಗಾಗಿ ಪ್ರಕ್ರಿಯೆ-ಸ್ಥಳೀಯ ಮೃದು ವಿತರಣೆಯಾಗಿದೆ.
- ಖಾತೆ ಸೆಮಾಫೋರ್ಗಳು ವಿನಂತಿ-ಸಮಕಾಲೀನತೆಯ ಅನುಮತಿಗಳನ್ನು ನೀಡುತ್ತವೆ ಮತ್ತು ವಿನಂತಿ ಪೂರ್ಣಗೊಂಡಾಗ ಅಂತ್ಯಗೊಳ್ಳುತ್ತವೆ.
- ವಿಶೇಷ ನಿರ್ವಹಿತ ಸೆಷನ್ ಲೀಸ್ಗಳು ಜನರೇಶನ್ ಗಡಿಯೊಂದಿಗೆ ದೀರ್ಘಕಾಲಿಕ ಜೀವನಚಕ್ರ ಮಾಲೀಕತ್ವವಾಗಿವೆ.

---

## 3. ಮಾದರಿ ಲಾಕ್ಔಟ್

**ವ್ಯಾಪ್ತಿ:** ಪೂರೈಕೆದಾರ + ಸಂಪರ್ಕ + ಮಾದರಿ ತ್ರಯ.

**ಸ್ಥಿತಿಯ ಪ್ರಕಾರ ಕೀ ವ್ಯಾಪ್ತಿ:** ವಿಫಲವಾಗುತ್ತಿರುವ ಸ್ಥಿತಿಯು ಲಾಕ್ಔಟ್ ಯಾವ ಕೀಗೆ ಬರೆಯಬೇಕು ಎಂಬುದನ್ನು
ನಿರ್ಧರಿಸುತ್ತದೆ (`open-sse/services/accountFallback/exactModelLock.ts` ನಲ್ಲಿರುವ `resolveLockoutScope()`):

- `429` / `403` / `402` — ಕೋಟಾ ಅಥವಾ ಅರ್ಹತಾ ಸಂಕೇತ — **ಕೋಟಾ ಕುಟುಂಬವನ್ನು** ಲಾಕ್ ಮಾಡುತ್ತದೆ:
  codex ಗಾಗಿ ಸಂಪೂರ್ಣ `codex` / `spark` ವ್ಯಾಪ್ತಿ (ಸಂಪರ್ಕದ ಪ್ರತಿಯೊಂದು `gpt-5*` ಮಾದರಿ),
  ಇತರ ಪೂರೈಕೆದಾರರಿಗೆ `getQuotaScopedModelForProvider()`.
- `404` ಮೂಲ ಮಾದರಿಯನ್ನು ಲಾಕ್ ಮಾಡುತ್ತದೆ (`getModelLockKey()` `not_found` ಅನ್ನು ಸಂಕುಚಿತಗೊಳಿಸುತ್ತದೆ).
- ಬೇರೆ ಯಾವುದೇ ಸ್ಥಿತಿ — `5xx` ಸಾರಿಗೆ/ಸರ್ವರ್ ವೈಫಲ್ಯಗಳು ಮತ್ತು ಗುಣಮಟ್ಟದ ಮೌಲ್ಯೀಕರಣದಿಂದ
  OmniRoute ಸ್ವತಃ ಸಂಶ್ಲೇಷಿಸಿದ `502` — **ನಿಖರವಾದ**
  ಪೂರೈಕೆದಾರ/ಸಂಪರ್ಕ/ಮಾದರಿ ಟ್ಯೂಪಲ್ ಅನ್ನು ಮಾತ್ರ ಲಾಕ್ ಮಾಡುತ್ತದೆ. ಒಂದು ಮಾದರಿಯಲ್ಲಿನ ದೋಷಪೂರಿತ ಸ್ಟ್ರೀಮ್
  ಖಾತೆಯ ಕೋಟಾದ ಕುರಿತು ಸಾಕ್ಷಿಯಲ್ಲ; ಈ ನಿಯಮದ ಮೊದಲು
  `codex/gpt-5.6-luna` ನಲ್ಲಿನ ಒಂದು ಖಾಲಿ ಪ್ರತಿಕ್ರಿಯೆಯು ಆ ಸಂಪರ್ಕದ ಪ್ರತಿಯೊಂದು `gpt-5*` ಮಾದರಿಯನ್ನು
  ಅದರ ಕೋಟಾ ಬದಲಾಗದೇ ಇದ್ದರೂ 2–30 ನಿಮಿಷಗಳವರೆಗೆ (ಹೆಚ್ಚುತ್ತಾ ಹೋಗುವಂತೆ) ರೂಟಿಂಗ್ನಿಂದ ತೆಗೆದುಹಾಕುತ್ತಿತ್ತು.
- ಕರೆಮಾಡುವವರ ಸ್ಪಷ್ಟ `scope` ಆಯ್ಕೆಯು ಯಾವಾಗಲೂ ಆದ್ಯತೆ ಪಡೆಯುತ್ತದೆ (Antigravity `"exact"` ಅನ್ನು ರವಾನಿಸುತ್ತದೆ).

**ಉದ್ದೇಶ:** ಕೇವಲ ಒಂದು ಮಾದರಿ ಲಭ್ಯವಿಲ್ಲದಾಗ ಅಥವಾ ಕೋಟಾ-ಸೀಮಿತವಾಗಿರುವಾಗ ಸಂಪೂರ್ಣ ಸಂಪರ್ಕವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದನ್ನು ತಪ್ಪಿಸುವುದು.

**ಉದಾಹರಣೆಗಳು:**

- 429 ಅನ್ನು ಹಿಂತಿರುಗಿಸುವ ಪ್ರತಿ-ಮಾದರಿ ಕೋಟಾ ಪೂರೈಕೆದಾರರು
- ಕಾಣೆಯಾದ ಒಂದು ಮಾದರಿಗೆ 404 ಅನ್ನು ಹಿಂತಿರುಗಿಸುವ ಸ್ಥಳೀಯ ಪೂರೈಕೆದಾರರು
- ಪೂರೈಕೆದಾರ-ನಿರ್ದಿಷ್ಟ ಮೋಡ್/ಮಾದರಿ ಅನುಮತಿ ವೈಫಲ್ಯಗಳು (ಉದಾ., Grok ಮೋಡ್ಗಳು)

**ಅನುಷ್ಠಾನ:** `open-sse/services/accountFallback.ts` — `lockModel()`, `clearModelLock()`, `getAllModelLockouts()`.

### ಮಾದರಿ ಕೂಲ್ಡೌನ್ಗಳ ಡ್ಯಾಶ್ಬೋರ್ಡ್ (v3.8.0)

UI: Settings → Model Cooldowns (`src/app/(dashboard)/dashboard/settings/components/ModelCooldownsCard.tsx`)

ಸಕ್ರಿಯ ಲಾಕ್ಔಟ್ಗಳನ್ನು ಇವುಗಳೊಂದಿಗೆ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ: ಪೂರೈಕೆದಾರ, ಸಂಪರ್ಕ, ಮಾದರಿ, ಕಾರಣ, expiresAt. ನಿರ್ವಾಹಕರು ಕಾರ್ಡ್ನಿಂದ ಮಾದರಿಯನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಮರು-ಸಕ್ರಿಯಗೊಳಿಸಬಹುದು.

**REST API:**

- `GET /api/resilience/model-cooldowns` — ಸಕ್ರಿಯ ಲಾಕ್ಔಟ್ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ
- `DELETE /api/resilience/model-cooldowns` — ಹಸ್ತಚಾಲಿತ ಮರು-ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆ. ವಿನಂತಿಯ ಭಾಗ: `{provider, connection, model}`. ದೃಢೀಕರಣ: ನಿರ್ವಹಣೆ.

### ಲಾಕ್ಔಟ್ ಸೆಟ್ಟಿಂಗ್ಗಳ UI + ಯಶಸ್ಸು-ಕ್ಷಯ ಮರುಪಡೆಯುವಿಕೆ (v3.8.23)

ಮಾದರಿ ಲಾಕ್ಔಟ್ ಯಾವಾಗಲೂ ಸಕ್ರಿಯವಾಗಿರುವ ಹಾರ್ಡ್ಕೋಡ್ ಮಾಡಿದ ವರ್ತನೆಯಿಂದ, ತನ್ನದೇ ಆದ ಸೆಟ್ಟಿಂಗ್ಗಳ ಕಾರ್ಡ್ ಮತ್ತು
ಸ್ವಯಂ-ದುರಸ್ತಿಗೊಳ್ಳುವ ಮರುಪಡೆಯುವಿಕೆ ಮಾರ್ಗವನ್ನು ಹೊಂದಿರುವ ಸಂಪೂರ್ಣವಾಗಿ ಸಂರಚಿಸಬಹುದಾದ, ಆಯ್ಕೆಯ ಮೂಲಕ ಸಕ್ರಿಯಗೊಳಿಸಬೇಕಾದ ವೈಶಿಷ್ಟ್ಯವಾಗಿ ಬದಲಾಗಿದೆ.

**ಸೆಟ್ಟಿಂಗ್ಗಳ ಕಾರ್ಡ್:** Settings → Model Lockout
(`src/app/(dashboard)/dashboard/settings/components/ModelLockoutCard.tsx`).
ಇದು ಮೇಲಿನ ಓದಲು-ಮಾತ್ರವಾದ `ModelCooldownsCard` ಗಿಂತ **ಭಿನ್ನವಾಗಿದೆ** (ಅದು ಸಕ್ರಿಯ ಲಾಕ್ಔಟ್ಗಳನ್ನು ಮಾತ್ರ
_ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ_) — ಹೊಸ ಕಾರ್ಡ್ _ನಿಯತಾಂಕಗಳನ್ನು ಸಂರಚಿಸುತ್ತದೆ_. ಡೀಫಾಲ್ಟ್ಗಳು
`DEFAULT_MODEL_LOCKOUT_SETTINGS`
(`src/lib/resilience/modelLockoutSettings.ts`) ನಲ್ಲಿ ಇವೆ:

| ಸೆಟ್ಟಿಂಗ್               | ಡೀಫಾಲ್ಟ್                         | ಅರ್ಥ                                                               |
| ----------------------- | -------------------------------- | ------------------------------------------------------------------ |
| `enabled`               | `false`                          | ಮುಖ್ಯ ಟಾಗಲ್ — ಮಾದರಿ ಲಾಕ್ಔಟ್ **ಡೀಫಾಲ್ಟ್ ಆಗಿ ಆಫ್ ಆಗಿರುತ್ತದೆ**.       |
| `errorCodes`            | `[403, 404, 429, 502, 503, 504]` | ಮಾದರಿ-ವ್ಯಾಪ್ತಿಯ ವೈಫಲ್ಯವಾಗಿ ಪರಿಗಣಿಸುವ ಅಪ್ಸ್ಟ್ರೀಮ್ ಸ್ಥಿತಿಗಳು.        |
| `baseCooldownMs`        | `120_000` (120 ಸೆಕೆಂ)            | ಮೊದಲ ವೈಫಲ್ಯದ ಆರಂಭಿಕ ಲಾಕ್ಔಟ್ ಅವಧಿ.                                  |
| `maxCooldownMs`         | `1_800_000` (30 ನಿಮಿಷ)           | ಹೆಚ್ಚಿಸಲಾದ ಕೂಲ್ಡೌನ್ನ ಗರಿಷ್ಠ ಮಿತಿ.                                  |
| `maxBackoffSteps`       | `10`                             | ಗರಿಷ್ಠ ಘಾತೀಯ-ಬ್ಯಾಕ್ಆಫ್ ಹೆಚ್ಚಳದ ಹಂತಗಳು.                             |
| `useExponentialBackoff` | `true`                           | ಪುನರಾವರ್ತಿತ ವೈಫಲ್ಯಗಳು ಕೂಲ್ಡೌನ್ ಅನ್ನು ಘಾತೀಯವಾಗಿ ಹೆಚ್ಚಿಸಬೇಕೇ ಎಂಬುದು. |

ಸೆಟ್ಟಿಂಗ್ಗಳು ಸಾಮಾನ್ಯ ಸೆಟ್ಟಿಂಗ್ಗಳ ಸ್ಟೋರ್ ಮೂಲಕ ಉಳಿಯುತ್ತವೆ ಮತ್ತು ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವದ ಸೆಟ್ಟಿಂಗ್ಗಳ ಸ್ಕೀಮಾ ಮೂಲಕ
ಮೌಲ್ಯೀಕರಿಸಲ್ಪಡುತ್ತವೆ; ಕಾರ್ಡ್ `baseCooldownMs`/`maxCooldownMs`
(`maxCooldownMs ≥ baseCooldownMs` ಜೊತೆಗೆ) ಮತ್ತು `maxBackoffSteps` ಅನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ.

**ಯಶಸ್ಸು-ಕ್ಷಯ ಮರುಪಡೆಯುವಿಕೆ:** ಮರುಪಡೆಯುವಿಕೆಯು ಸಂಪೂರ್ಣವಾಗಿ ಟೈಮರ್ ಅವಧಿ ಮುಗಿಯುವುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿಲ್ಲ. ಆರೋಗ್ಯಕರ
ಪ್ರತಿಕ್ರಿಯೆಯು ಮಾದರಿಯ ವೈಫಲ್ಯ ಎಣಿಕೆಯನ್ನು ಹಂತ ಹಂತವಾಗಿ ಇಳಿಸುತ್ತದೆ; ಇದರಿಂದ ಅವಧಿಯ ಮಧ್ಯದಲ್ಲೇ ಚೇತರಿಸಿಕೊಂಡ ಮಾದರಿಯು
ತನ್ನ ಟೈಮರ್ ಅವಧಿ ಮುಗಿಯುವ ಮೊದಲು ಹೆಚ್ಚಳವನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ (ಮತ್ತು ತೆರವುಗೊಳ್ಳುತ್ತದೆ). ಯಶಸ್ವಿಯಾದ
ಕಾಂಬೊ ಗುರಿಯಲ್ಲಿ, `open-sse/services/combo.ts` `decayModelFailureCount()` ಅನ್ನು ಕರೆಯುತ್ತದೆ
(`open-sse/services/accountFallback.ts`), ಇದು ಸಂಗ್ರಹಿತ
`failureCount` ಅನ್ನು **ಅರ್ಧಕ್ಕೆ ಇಳಿಸುತ್ತದೆ** (`Math.floor(failureCount / 2)`); ಅದು `0` ತಲುಪಿದಾಗ ಲಾಕ್ಔಟ್
ನಮೂದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅಳಿಸಲಾಗುತ್ತದೆ. ಇದರ ಪ್ರತಿರೂಪವಾದ `recordModelLockoutFailure()`
ಹೆಚ್ಚಳದ ಅವಧಿಯೊಳಗಿನ ವೈಫಲ್ಯಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಎಣಿಕೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ (ಮತ್ತು ಕೂಲ್ಡೌನ್ ಅನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ).
ಈ ಯಶಸ್ಸು-ಕ್ಷಯವು ಸಾಮಾನ್ಯ ಟೈಮರ್ ಅವಧಿ ಮುಗಿಯುವಿಕೆಗೆ ಹೆಚ್ಚುವರಿಯಾಗಿದೆ —
ಎರಡೂ ಮಾರ್ಗಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಮಾದರಿಯನ್ನು ಮರು-ಸಕ್ರಿಯಗೊಳಿಸಬಹುದು.

**ಸ್ಥಿತಿ:** ಲಾಕ್ಔಟ್ಗಳನ್ನು **ಮೆಮೊರಿಯಲ್ಲಿಯೇ** ಇರಿಸಲಾಗುತ್ತದೆ (`provider:connectionId:model` ಕೀ ಹೊಂದಿರುವ
`ModelLockoutEntry` ಯ ಪ್ರತಿ-ಪ್ರಕ್ರಿಯೆ `Map` ಗಳು, `provider:connectionId:exact:model` ಕೀ ಹೊಂದಿರುವ
ನಿಖರ-ವ್ಯಾಪ್ತಿಯ ಲಾಕ್ಗಳು), DB ಯಲ್ಲಿ ಉಳಿಸಲಾಗುವುದಿಲ್ಲ —
ಮರುಪ್ರಾರಂಭಿಸಿದಾಗ ಅವು ಕಳೆದುಹೋಗುತ್ತವೆ. _ಸೆಟ್ಟಿಂಗ್ಗಳು_ ಉಳಿಯುತ್ತವೆ; ಸಕ್ರಿಯ
ಲಾಕ್ಔಟ್ _ಸ್ಥಿತಿ_ ತಾತ್ಕಾಲಿಕವಾಗಿದೆ.

---

## 4. ಕೋಟಾ-ಹಂಚಿಕೆ ಸಮಕಾಲಿಕತೆ ನಿಯಂತ್ರಣ (v3.8.36)

ಚಂದಾದಾರಿಕೆ ಖಾತೆಗಳು (GLM, MiniMax, ಇತ್ಯಾದಿ) ಸಾಮಾನ್ಯವಾಗಿ ಏಕಕಾಲದಲ್ಲಿ ಕೇವಲ ~1–3
ವಿನಂತಿಗಳನ್ನು ಮಾತ್ರ ಸ್ವೀಕರಿಸುತ್ತವೆ; ಅದನ್ನು ಮೀರಿದರೆ 429ಗಳು ಮತ್ತು ಕೂಲ್ಡೌನ್ಗಳು
ಪ್ರಚೋದಿತವಾಗುತ್ತವೆ. ಹಲವು API ಕೀಲಿಗಳು ಒಂದೇ ಅಪ್ಸ್ಟ್ರೀಮ್ ಖಾತೆಯನ್ನು ಹಂಚಿಕೊಳ್ಳುವ
**ಕೋಟಾ-ಹಂಚಿಕೆ** (`qtSd/…`) ಕಾಂಬೊಗಳಲ್ಲಿ ಇದು ತೀವ್ರವಾಗಿರುತ್ತದೆ. ಹಂಚಿಕೆಯ ಖಾತೆಯು
ವಿನಂತಿಗಳ ಪ್ರವಾಹಕ್ಕೆ ಒಳಗಾಗದಂತೆ ಮೂರು ಪದರಗಳು ತಡೆಯುತ್ತವೆ.

### ಪ್ರತಿ-ಸಂಪರ್ಕ ಸಮಕಾಲಿಕತೆ ಮಿತಿ (`max_concurrent`)

ಪ್ರತಿ ಪೂರೈಕೆದಾರರ ಸಂಪರ್ಕವು `max_concurrent` ಗರಿಷ್ಠ ಮಿತಿಯನ್ನು ಘೋಷಿಸಬಹುದು
(`provider_connections.max_concurrent`, ಸಂಪರ್ಕ ಮೋಡಲ್ / API / DBಯಲ್ಲಿ ಹೊಂದಿಸಲಾಗುತ್ತದೆ).
ಯಾವುದೇ ಮಿತಿ ಬೇಡವಾದರೆ ಅದನ್ನು ಖಾಲಿ ಬಿಡಿ. ಕೆಳಗಿನ ಸರಣೀಕರಣ ಪದರವನ್ನು ನಿಯಂತ್ರಿಸುವ ಏಕೈಕ
ಸೆಟ್ಟಿಂಗ್ ಇದೇ — ಇದನ್ನು ಖಾತೆಯ ನೈಜ ಸಮಕಾಲಿಕತೆಗೆ ಹೊಂದಿಸಿ (ಉದಾ. GLM ~1, MiniMax ~2).

### ಕೋಟಾ-ಹಂಚಿಕೆ ವಿನಂತಿ ಸರಣೀಕರಣ

ಕೋಟಾ-ಹಂಚಿಕೆ ಡಿಸ್ಪ್ಯಾಚ್ ಧನಾತ್ಮಕ `max_concurrent` ಅನ್ನು ಘೋಷಿಸುವ ಸಂಪರ್ಕವನ್ನು
ಗುರಿಯಾಗಿಸಿದಾಗ, ಆ **ಖಾತೆಗೆ** ಬರುವ ಸಮಕಾಲಿಕ ವಿನಂತಿಗಳನ್ನು ಪ್ರತಿ-ಸಂಪರ್ಕ ಸೆಮಾಫೋರ್
(ಕೀಲಿ `qsconn:<connectionId>`) ಮೂಲಕ ಸರಣೀಕರಿಸಲಾಗುತ್ತದೆ: ಹೆಚ್ಚುವರಿ ವಿನಂತಿಗಳು
ಖಾತೆಯನ್ನು ವಿನಂತಿಗಳಿಂದ ತುಂಬಿಸುವ ಬದಲು **ಸರತಿಯಲ್ಲಿ ಕಾಯುತ್ತವೆ**. ಇದು
**ಫೇಲ್-ಓಪನ್** ಆಗಿದೆ — ಪೂರ್ಣಗೊಂಡ ಸರತಿ ಅಥವಾ ಸಮಯ ಮೀರುವಿಕೆ, ಡಿಸ್ಪ್ಯಾಚ್ ಮಾಡಬಹುದಾದ
ವಿನಂತಿಯನ್ನು ತಿರಸ್ಕರಿಸುವ ಬದಲು ಸ್ಲಾಟ್ ಇಲ್ಲದೆಯೇ ಮುಂದುವರಿಯುತ್ತದೆ. ಇದನ್ನು
**ಸೆಟ್ಟಿಂಗ್ಗಳು → ಸ್ಥಿತಿಸ್ಥಾಪಕತೆ → ಕೋಟಾ-ಹಂಚಿಕೆ ಪ್ರತಿ-ಸಂಪರ್ಕ ಸಮಕಾಲಿಕತೆ**
(`resilienceSettings.quotaShareConcurrencyLimit.enabled`, ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ
ಸಕ್ರಿಯ) ಅಡಿಯಲ್ಲಿ ಟಾಗಲ್ ಮಾಡಿ. `max_concurrent` ಮಿತಿ ಇಲ್ಲದಿದ್ದರೆ ವರ್ತನೆಯು ಬದಲಾಗುವುದಿಲ್ಲ.

> ಕೋಟಾ-ಹಂಚಿಕೆ ರೂಟಿಂಗ್ ಗೇಟ್ (`selectQuotaShareTarget`, DRR + P2C) ಸ್ವತಃ
> ಫೇಲ್-ಓಪನ್ ಆಗಿದ್ದು, ಮಿತಿಯನ್ನು ತಲುಪಿರುವ ಸಂಪರ್ಕಕ್ಕೆ ಕೇವಲ _ಕಡಿಮೆ ಆದ್ಯತೆ_ ನೀಡುತ್ತದೆ —
> ಒಂದೇ-ಸಂಪರ್ಕದ ಪೂಲ್ನಲ್ಲಿ ಅದು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಮಿತಿಗೊಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ಈ
> ಸೆಮಾಫೋರ್ವೇ ವಾಸ್ತವವಾಗಿ ವಿನಂತಿಗಳ ಪ್ರವಾಹವನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ.

### ಕಾಂಬೊ ಕೂಲ್ಡೌನ್-ಅರಿವಿನ ಮರುಪ್ರಯತ್ನ

ಪ್ರತಿ ಕಾಂಬೊ ತಂತ್ರಕ್ಕೂ (ಸಕ್ರಿಯಗೊಳಿಸಿದಾಗ), ಅಲ್ಪಾವಧಿಯ ತಾತ್ಕಾಲಿಕ ಕೂಲ್ಡೌನ್ಗಾಗಿ
429 ಅನ್ನು ಖಚಿತಪಡಿಸುವ ವಿನಂತಿಯು 429 ಅನ್ನು ಹಿಂದಿರುಗಿಸುವ ಬದಲು ಕೂಲ್ಡೌನ್ ಮುಗಿಯುವವರೆಗೆ
ಕಾಯುತ್ತದೆ ಮತ್ತು ಮರು-ಡಿಸ್ಪ್ಯಾಚ್ ಆಗುತ್ತದೆ — ಇದು ಬಹು-ಮಾದರಿ ಕಾಂಬೊಗಳಲ್ಲಿನ
Gemini-ವರ್ಗದ TPM/RPM ವಿಂಡೋಗಳನ್ನು (~60s retry-after) ಒಳಗೊಳ್ಳುತ್ತದೆ, ಉದಾ. 2-ಮಾದರಿ
ಕಾಂಬೊದ ಎರಡೂ ಗುರಿಗಳು ಪ್ರತಿ-ಮಾದರಿ ದರ ಮಿತಿಯನ್ನು ತಲುಪುವುದು. **ಸೆಟ್ಟಿಂಗ್ಗಳು →
ಸ್ಥಿತಿಸ್ಥಾಪಕತೆ** ಅಡಿಯಲ್ಲಿರುವ `comboCooldownWait` (`enabled`, `maxWaitMs`,
`maxAttempts`, `budgetMs`) ಮೂಲಕ ಇದು ಮಿತಿಗೊಳಿಸಲಾಗಿದೆ. ಇದು `quota_exhausted`
(ಮಧ್ಯರಾತ್ರಿಯವರೆಗೆ ಲಾಕ್ ಆಗಿರುತ್ತದೆ) ಅಥವಾ ದೃಢೀಕರಣ/ಕಂಡುಬಂದಿಲ್ಲ ಕಾರಣಗಳಿಗಾಗಿ ಎಂದಿಗೂ
ಕಾಯುವುದಿಲ್ಲ.

---

## 5. ವಿನಂತಿ ಕ್ಯೂ ಪ್ರವೇಶ ನಿಯಂತ್ರಣ (v3.8.49 · issue #6593)

**ವ್ಯಾಪ್ತಿ**: ಸ್ಥಳೀಯ ಪ್ರತಿ-provider+connection ದರ-ಮಿತಿ ಕ್ಯೂ (`open-sse/services/rateLimitManager.ts`,
Bottleneck ಬೆಂಬಲಿತ), ಮೇಲಿನ ಮೂರು ಕಾರ್ಯವಿಧಾನಗಳಿಗಿಂತ ಒಂದು ಹಂತ ಕೆಳಗೆ.

**`maxWaitMs` ಕ್ಯೂ ಕಾಯುವಿಕೆಯನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ; `executionMaxWaitMs` ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ.**
ಇವೆರಡನ್ನೂ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಲಾಗಿದೆ ಮತ್ತು ಯಾವುದೂ ಇನ್ನೊಂದಕ್ಕೆ ಮೌಲ್ಯವನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ.

`resilienceSettings.requestQueue.maxWaitMs` ಎಂಬುದು **ಕ್ಯೂ-ಕಾಯುವಿಕೆ ಬಜೆಟ್**: ಇದು
provider ಸ್ಲಾಟ್ಗಾಗಿ ಕಾಯುವುದನ್ನೂ, ನಂತರ QUEUED ಸ್ಥಿತಿಯಲ್ಲಿ ಇರುವುದನ್ನೂ ಒಳಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು
ಕೆಲಸವು QUEUED ಸ್ಥಿತಿಯಿಂದ ಹೊರಬಂದು ಕಾರ್ಯಗತಗೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿದ ತಕ್ಷಣವೇ ಅದರ ಟೈಮರ್ ಅನ್ನು
ತೆರವುಗೊಳಿಸಲಾಗುತ್ತದೆ (`rateLimitManager.ts`, `wrappedFn`). ಇದನ್ನು ಮೀರುವ ವಿನಂತಿಯು
upstream ಅನ್ನು ಎಂದಿಗೂ ತಲುಪುವುದಿಲ್ಲ. ಡೀಫಾಲ್ಟ್ 30000ms; ಇದನ್ನು
`src/lib/resilience/settings.ts` ನಲ್ಲಿರುವ `DEFAULT_REQUEST_QUEUE_MAX_WAIT_MS`
ಒದಗಿಸುತ್ತದೆ ಮತ್ತು `tests/unit/ratelimit-admission-control-6593.test.ts` ಮೂಲಕ
ಸ್ಥಿರಗೊಳಿಸಲಾಗಿದೆ. ಆದ್ದರಿಂದ, ಇದಕ್ಕೆ ಬದಲಾವಣೆ ಮಾಡಿದರೆ ಈ ಪ್ಯಾರಾಗ್ರಾಫ್ ಸದ್ದಿಲ್ಲದೆ
ಹಳತಾಗಿರುವ ಬದಲು ಆ ಪರೀಕ್ಷೆಯು ವಿಫಲವಾಗುತ್ತದೆ.

`resilienceSettings.requestQueue.executionMaxWaitMs` ಎಂಬುದನ್ನು Bottleneck,
ಕೆಲಸದ `expiration` ಆಗಿ ಸ್ವೀಕರಿಸುತ್ತದೆ; ಇದರ ಟೈಮರ್ dispatch ಆದ ನಂತರವೇ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.
ಸ್ವಂತ upstream timeout ಇಲ್ಲದ executorಗಳಿಗೆ ಇದು ಸುರಕ್ಷತಾ ಮಿತಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ
ಮತ್ತು executorನ ಸ್ವಂತ fetch-start timeout ಹೆಚ್ಚು ದೀರ್ಘವಾಗಿದ್ದರೆ ಇದನ್ನು ಅದಕ್ಕೆ
ಏರಿಸಲಾಗುತ್ತದೆ; ಹೀಗಾಗಿ ಇದು ಸರಿಯಾಗಿ ನಡೆಯುತ್ತಿರುವ in-flight ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಮಧ್ಯದಲ್ಲೇ
ನಿಲ್ಲಿಸಲಾರದು. ಡೀಫಾಲ್ಟ್ 600000ms (10 ನಿಮಿಷ).

ಕ್ಯೂ ಬಜೆಟ್ ಅನ್ನು `expiration` ಗೆ ಒದಗಿಸುವುದರಿಂದಲೇ ಹಿಂದೆ non-incremental
gatewayಗಳು mid-flightನಲ್ಲಿ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತಿದ್ದವು — ಅವು ಮೊದಲ bytes ಕಳುಹಿಸುವ ಮೊದಲು
ನ್ಯಾಯಸಮ್ಮತವಾಗಿಯೇ ಹಲವಾರು ನಿಮಿಷಗಳವರೆಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ — ಮತ್ತು ಈ ಕಾರಣದಿಂದ
expiration ಅನ್ನು `code: "RATE_LIMIT_EXECUTION_TIMEOUT"` (HTTP 504) ಎಂದು
ತೋರಿಸಲಾಗುತ್ತದೆ; ಕ್ಯೂ ಬಜೆಟ್ ಮಾತ್ರ queue-timeout code ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ.
`RATE_LIMIT_MAX_WAIT_MS` / `RATE_LIMIT_EXECUTION_MAX_WAIT_MS` (env) ಅಥವಾ
dashboard (**Settings → Resilience**) ಮೂಲಕ ಯಾವುದನ್ನಾದರೂ override ಮಾಡಿ.
normalise ಮಾಡಿದಾಗ ಎರಡನ್ನೂ 1ms–24h ವ್ಯಾಪ್ತಿಗೆ ಮಿತಿಗೊಳಿಸಲಾಗುತ್ತದೆ.

**ಎರಡಕ್ಕೂ ಅನ್ವಯಿಸುವ ಆದ್ಯತಾಕ್ರಮ:** env var ಕೇವಲ _ಡೀಫಾಲ್ಟ್_ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ.
`resilienceSettings.requestQueue` ನಲ್ಲಿ ಉಳಿಸಲಾದ ಮೌಲ್ಯವು (dashboard / API patch,
`key_value` ನಲ್ಲಿ ಸಂಗ್ರಹಿತ) ಅದಕ್ಕಿಂತ ಆದ್ಯತೆ ಪಡೆಯುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ-connection
`rateLimitOverrides.maxWaitMs` / `.executionMaxWaitMs` ಅದಕ್ಕಿಂತಲೂ ಆದ್ಯತೆ
ಪಡೆಯುತ್ತದೆ. ಆದ್ದರಿಂದ, ಈಗಾಗಲೇ ಉಳಿಸಲಾದ ಮೌಲ್ಯವಿರುವ deploymentನಲ್ಲಿ env var ಅನ್ನು
ಹೊಂದಿಸುವುದರಿಂದ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ — ಬದಲಾಗಿ ಉಳಿಸಲಾದ setting ಅನ್ನು ತೆರವುಗೊಳಿಸಿ ಅಥವಾ
ನವೀಕರಿಸಿ.

ಕ್ಯೂನಲ್ಲಿ ಉಳಿಯುವ ಅವಧಿಯನ್ನು `maxWaitMs` ಮಿತಿಗೊಳಿಸುತ್ತದೆ; ಕೆಳಗಿನ
`maxQueueDepth` ಒಂದೇ ಸಮಯದಲ್ಲಿ ಎಷ್ಟು callerಗಳು ಕ್ಯೂನಲ್ಲಿ ಇರಬಹುದು ಎಂಬುದನ್ನು
ಮಿತಿಗೊಳಿಸುತ್ತದೆ.

**`maxQueueDepth` — ಆಯ್ಕೆಮಾಡಿ ಸಕ್ರಿಯಗೊಳಿಸಬಹುದಾದ ಪ್ರವೇಶ ಮಿತಿ (ಹೊಸದು).** `resilienceSettings.requestQueue.maxQueueDepth`
ಒಂದು provider+connectionಗಾಗಿ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಕ್ಯೂನಲ್ಲಿ (ಇನ್ನೂ dispatch ಆಗದೆ)
ಎಷ್ಟು ವಿನಂತಿಗಳು ಇರಬಹುದು ಎಂಬುದನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ. ಕ್ಯೂ ಈಗಾಗಲೇ
`maxQueueDepth` ವಿನಂತಿಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಹೊಸ ವಿನಂತಿಯು `limiter.schedule()` ಅನ್ನು
ತಲುಪುವ **ಮೊದಲೇ** typed `code: "RATE_LIMIT_QUEUE_FULL"` ದೋಷದೊಂದಿಗೆ ತಕ್ಷಣವೇ
ತಿರಸ್ಕರಿಸಲ್ಪಡುತ್ತದೆ — ಆದ್ದರಿಂದ ತಿರಸ್ಕಾರವು ಕಡಿಮೆ ವೆಚ್ಚದ್ದಾಗಿದ್ದು, ಆ ವಿನಂತಿಗಾಗಿ
ನಡೆಯುವ ಯಾವುದೇ downstream prompt-compression / translation ಕೆಲಸಕ್ಕಿಂತ ಮೊದಲೇ
ಸಂಭವಿಸುತ್ತದೆ. ಡೀಫಾಲ್ಟ್ `0` = ನಿಷ್ಕ್ರಿಯ; ಇದು ಈಗಿರುವ ಮಿತಿಯಿಲ್ಲದ-ಕ್ಯೂ ನಡವಳಿಕೆಯನ್ನು
ಉಳಿಸುತ್ತದೆ; ವ್ಯಾಪ್ತಿ 0–100000ಕ್ಕೆ ಸೀಮಿತವಾಗಿದೆ.
`RATE_LIMIT_MAX_QUEUE_DEPTH` (env) ಅಥವಾ
`resilienceSettings.requestQueue.maxQueueDepth` (dashboard/API patch) ಮೂಲಕ
override ಮಾಡಿ.

ಪ್ರವೇಶ ಪರಿಶೀಲನೆಯೇ ಒಂದು pure function ಆಗಿದೆ
(`open-sse/services/rateLimitManager/admission.ts::checkQueueAdmission`), ಆದ್ದರಿಂದ
ನೈಜ Bottleneck limiter ಇಲ್ಲದೆಯೂ ಇದನ್ನು unit-test ಮಾಡಬಹುದು.

> #6593 ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದ RFC, `bypassCompressionOnRateLimit`
> flag ಅನ್ನೂ ಪ್ರಸ್ತಾಪಿಸಿತ್ತು. ಈ repoಯ `open-sse/services/compression/` pipeline,
> outbound LLM ವಿನಂತಿಯಲ್ಲಿನ prompt/context compression ಆಗಿದೆ (`chatCore.ts`,
> `resolveCompressionSettings`/`selectCompressionStrategy` block ಸುತ್ತಮುತ್ತ);
> synthesized 429 bodyಗಳ HTTP response compression ಅಲ್ಲ — ನೇರ bypass flagಗೆ
> ಹೊಂದುವ code path ಇಲ್ಲ. ಆ prompt-compression ಹಂತವು ಪ್ರಸ್ತುತ request pipelineನಲ್ಲಿ
> `withRateLimit()` ಗಿಂತಲೂ _ಮೊದಲು_ ನಡೆಯುತ್ತದೆ. ಆದ್ದರಿಂದ queue-full ತಿರಸ್ಕಾರವಾದಾಗ
> ಅದನ್ನು ಬಿಟ್ಟುಬಿಡಲು ಮರುಕ್ರಮಗೊಳಿಸುವುದು ಈ issue ವ್ಯಾಪ್ತಿಗಿಂತ ಪ್ರತ್ಯೇಕವಾದ ಮತ್ತು ದೊಡ್ಡ
> ಬದಲಾವಣೆಯಾಗಿದೆ; ಅದನ್ನು ಇಲ್ಲಿ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ **ಅನುಷ್ಠಾನಗೊಳಿಸಲಾಗಿಲ್ಲ** ಮತ್ತು CPU
> ಉಳಿತಾಯದ ಪ್ರಯೋಜನವು ಮರುಕ್ರಮಗೊಳಿಸುವ ಅಪಾಯಕ್ಕೆ ತಕ್ಕದ್ದಾಗಿದ್ದರೆ, ಅದನ್ನು follow-up ಆಗಿ
> ಬಿಡಲಾಗಿದೆ.

---

## 6. ನಿಧಾನ-ಸ್ಟ್ರೀಮ್ ಥ್ರೂಪುಟ್ ವಾಚ್ಡಾಗ್ (#9709)

ಐಚ್ಛಿಕ `resilienceSettings.streamRecovery.throughputWatchdog` ರಕ್ಷಕವು, ಇನ್ನೂ ಚಂಕ್ಗಳನ್ನು ಕಳುಹಿಸುತ್ತಿದ್ದರೂ ಸಂರಚಿಸಲಾದ ಉಪಯುಕ್ತ-ಔಟ್ಪುಟ್ ದರಕ್ಕಿಂತ ಕಡಿಮೆ ಸಹಾಯಕ ಔಟ್ಪುಟ್ ಉತ್ಪಾದಿಸುವ ಅಪ್ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತದೆ. ಇದನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಐಡಲ್ ಟೈಮ್ಔಟ್ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಲಾಗಿದೆ: ಹಾರ್ಟ್ಬೀಟ್ಗಳು ಮತ್ತು ಮೆಟಾಡೇಟಾ ಯಾವುದೇ ಟೈಮರ್ ಅನ್ನು ಮರುಹೊಂದಿಸುವುದಿಲ್ಲ ಮತ್ತು ಅವುಗಳನ್ನು ಪ್ರಗತಿ ಎಂದೂ ಪರಿಗಣಿಸಲಾಗುವುದಿಲ್ಲ. ಇದು ಹಾರ್ಡ್ ಅಟೆಂಪ್ಟ್ ಡೆಡ್ಲೈನ್ನಿಂದಲೂ (#9153) ಪ್ರತ್ಯೇಕವಾಗಿದೆ; ಔಟ್ಪುಟ್ ಗುಣಮಟ್ಟವನ್ನು ಲೆಕ್ಕಿಸದೆ ಅದು ಸಂಪೂರ್ಣ ಸುರಕ್ಷತಾ ಮಿತಿಯಾಗಿಯೇ ಉಳಿಯುತ್ತದೆ.

ವಾಚ್ಡಾಗ್ ಸ್ಥಗಿತಗೊಳಿಸುವ ಮೊದಲು ವಾರ್ಮ್-ಅಪ್ ಅವಧಿಯ ನಂತರ ಒಂದು ಸಂಪೂರ್ಣ ರೋಲಿಂಗ್ ವಿಂಡೋ ಪೂರ್ಣಗೊಳ್ಳುವುದು ಅಗತ್ಯ. ಇದು Chat Completions ಮತ್ತು Responses API ಔಟ್ಪುಟ್ ಈವೆಂಟ್ಗಳಿಂದ ಬರುವ ಪಠ್ಯ ಡೆಲ್ಟಾಗಳನ್ನು ಎಣಿಸುತ್ತದೆ (UTF-8 ಬೈಟ್ಗಳ ಸಂಯಮಿತ ಪ್ರಾಕ್ಸಿ), ಬಳಕೆ-ಮಾತ್ರ ಮತ್ತು ಖಾಲಿ ಈವೆಂಟ್ಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ ಹಾಗೂ ಟೂಲ್-ಕಾಲ್ ಅಥವಾ ರೀಸನಿಂಗ್ ಈವೆಂಟ್ಗಳು ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿರುವಾಗ ಮೌಲ್ಯಮಾಪನವನ್ನು ಅಮಾನತುಗೊಳಿಸುತ್ತದೆ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಇದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು `STREAM_THROUGHPUT_WATCHDOG_ENABLED=true` ಮೂಲಕ ಸಕ್ರಿಯಗೊಳಿಸಬಹುದು; ವಿಂಡೋ, ವಾರ್ಮ್-ಅಪ್, ಕನಿಷ್ಠ ದರ ಮತ್ತು ಕನಿಷ್ಠ ಅಳೆಯಬಹುದಾದ ಔಟ್ಪುಟ್ಗಳನ್ನು ಸಾಮಾನ್ಯ resilience-settings ನಾರ್ಮಲೈಸೇಶನ್ ಪದರವು ಮಿತಿಗೊಳಿಸುತ್ತದೆ.

ಸಕ್ರಿಯಗೊಳಿಸಿದಾಗ, ವಾಚ್ಡಾಗ್ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆಯನ್ನು ಸಕ್ರಿಯ ಅಪ್ಸ್ಟ್ರೀಮ್ ಪ್ರಯತ್ನಕ್ಕೆ ಮಾತ್ರ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ. ಕ್ಲೈಂಟ್ಗೆ ಗೋಚರಿಸುವ ಯಾವುದೇ ಬೈಟ್ಗಳಿಗಿಂತ ಮೊದಲು, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಅದೇ-ಖಾತೆಯ ಆರಂಭಿಕ-ಚೇತರಿಕೆ ಮಾರ್ಗವು ಪ್ರಯತ್ನವನ್ನು ಪುನಃ ತೆರೆಯಬಹುದು. ಕಮಿಟ್ ಆದ ನಂತರ, ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಎಂದಿಗೂ ವಿವೇಚನೆಯಿಲ್ಲದೆ ಮರುಚಾಲನೆ ಮಾಡಲಾಗುವುದಿಲ್ಲ; ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸುರಕ್ಷಿತ ಮಧ್ಯ-ಸ್ಟ್ರೀಮ್ ಮುಂದುವರಿಕೆ ಒಪ್ಪಂದ ಮಾತ್ರ ಸಫಿಕ್ಸ್ ಅನ್ನು ಜೋಡಿಸಬಹುದು. ಅಂತಿಮೀಕರಣವು ಒಂದೇ ಬಾರಿ ನಡೆಯುವುದರಿಂದ, ಬಳಕೆ ಲೆಕ್ಕಾಚಾರ ಮತ್ತು ಸೆಮಾಫೋರ್ ಬಿಡುಗಡೆಯನ್ನು ನಕಲು ಮಾಡಲಾಗುವುದಿಲ್ಲ.

---

## 7. ಅಪ್ಸ್ಟ್ರೀಮ್ ಸ್ಥಿತಿ ಮರುನಿರೂಪಣೆ (ತಪ್ಪಾಗಿ ಸೂಚಿಸಲಾದ ಕೋಟಾ ದೋಷಗಳು)

**ವ್ಯಾಪ್ತಿ:** ತಾತ್ಕಾಲಿಕ ಕೋಟಾ ಖಾಲಿಯಾಗಿರುವುದನ್ನು ತಪ್ಪಾದ HTTP ಸ್ಥಿತಿಯೊಂದಿಗೆ ವರದಿ ಮಾಡುವ ಒಂದು ಅಪ್ಸ್ಟ್ರೀಮ್ ಗೇಟ್ವೇ.

**ಉದ್ದೇಶ:** ವರ್ಗೀಕರಣದ ಮೊದಲು ತಪ್ಪುದಾರಿಗೆಳೆಯುವ ಸ್ಥಿತಿಯನ್ನು ಸರಿಪಡಿಸುವುದು, ಇದರಿಂದ ಡೌನ್ಸ್ಟ್ರೀಮ್ ಬಳಕೆದಾರರು (ಫಾಲ್ಬ್ಯಾಕ್ ಎಂಜಿನ್, ಕಾಂಬೊ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆ, ಕ್ಲೈಂಟ್ಗೆ ನೀಡುವ ಪ್ರತಿಕ್ರಿಯೆ) ವೈಫಲ್ಯದ ನಿಜವಾದ ಮರುಪ್ರಯತ್ನಿಸಬಹುದಾದ ಸ್ವರೂಪವನ್ನು ನೋಡುತ್ತಾರೆ.

ಕೆಲವು ಗೇಟ್ವೇಗಳು ತಾತ್ಕಾಲಿಕ ಕೋಟಾ ಖಾಲಿಯಾಗಿರುವುದನ್ನು ಮರುಪ್ರಯತ್ನಿಸಲಾಗದ HTTP ಸ್ಥಿತಿಯೊಂದಿಗೆ ಸೂಚಿಸುತ್ತವೆ. `agentrouter.org`, ಪ್ರಮಾಣಿತ `429` ಬದಲಿಗೆ ಚೀನೀ ಬಾಡಿಯೊಂದಿಗೆ (`用户额度不足` / `额度不足`) `403` ಅನ್ನು (ಕೆಲವೊಮ್ಮೆ `400`) ಹಿಂದಿರುಗಿಸುತ್ತದೆ. Claude Code ನಂತಹ ಕ್ಲೈಂಟ್ಗಳು `403` ಅನ್ನು ಶಾಶ್ವತವೆಂದು ಪರಿಗಣಿಸಿ ಸೆಷನ್ ಅನ್ನು ಸ್ಥಗಿತಗೊಳಿಸುತ್ತವೆ; ಸರಿಪಡಿಸದಿದ್ದರೆ ಫಾಲ್ಬ್ಯಾಕ್ ಎಂಜಿನ್ ಅದನ್ನು ಕೋಟಾ ಈವೆಂಟ್ ಬದಲಿಗೆ `AUTH_ERROR` ಎಂದು ವರ್ಗೀಕರಿಸುತ್ತದೆ.

**ಅನುಷ್ಠಾನ:**

- ರಿಜಿಸ್ಟ್ರಿ + ಮ್ಯಾಚರ್: `open-sse/config/upstreamStatusRestatement.ts` — ಪ್ರತಿ ಪ್ರೊವೈಡರ್ಗೆ ನಿಯಮಗಳ ಪಟ್ಟಿ (`{id, fromStatuses, toStatus, textMarkers,
excludeMarkers, defaultRetryAfterMs}`), ಇದನ್ನು `applyStatusRestatement()` ಮೂಲಕ ಹೊಂದಿಸಲಾಗುತ್ತದೆ.
- ಕಾಲ್ ಸೈಟ್: `open-sse/handlers/chatCore.ts` ನಲ್ಲಿನ `providerFailure:` ಬ್ಲಾಕ್ (ಸುಮಾರು 3654ನೇ ಸಾಲಿನಲ್ಲಿ), ದೋಷ HTTP ಸ್ಥಿತಿಯನ್ನು ಹೊಂದಿರುವ ಅಪ್ಸ್ಟ್ರೀಮ್ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು (`!providerResponse.ok`) `parseUpstreamError()` ಪಾರ್ಸ್ ಮಾಡಿದ ತಕ್ಷಣ ಮತ್ತು ಯಾವುದೇ ವರ್ಗೀಕರಣ ನಡೆಯುವ ಮೊದಲು; ಹೀಗಾಗಿ ಪ್ರತಿಯೊಂದು ಡೌನ್ಸ್ಟ್ರೀಮ್ ಬಳಕೆದಾರವೂ ಸರಿಪಡಿಸಿದ ಸ್ಥಿತಿಯನ್ನು ನೋಡುತ್ತದೆ. `200` SSE ಸ್ಟ್ರೀಮ್ನೊಳಗೆ ಅಡಕವಾಗಿರುವ ದೋಷಗಳು ಪ್ರತ್ಯೇಕವಾದ, ನಂತರದ ಸ್ಟ್ರೀಮ್-ಪಾರ್ಸಿಂಗ್ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸುತ್ತವೆ ಮತ್ತು ಇಂದು ಈ ಹುಕ್ನಿಂದ ಅವು **ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ** — ಇದು ತಿಳಿದಿರುವ ಮಿತಿಯಾಗಿದ್ದು, agentrouter ನ ತಪ್ಪು ಸ್ಥಿತಿಗೆ ಇನ್ನೂ ಅಗತ್ಯವಿಲ್ಲ (ಅದು ದೋಷ HTTP ಸ್ಥಿತಿಯಾಗಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ).
- ಮರುಪ್ರಯತ್ನ ಅರ್ಹತೆ: `429`, `RETRY_AFTER_ELIGIBLE_STATUSES` ನಲ್ಲಿ ಇದೆ (`open-sse/services/combo/unavailableRetryGate.ts`); ಆದ್ದರಿಂದ ಮರುನಿರೂಪಿಸಲಾದ ದೋಷವು ನಿಷ್ಕ್ರಿಯ `403` ಆಗಿ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಬದಲು ನೈಜ ಮರುಪ್ರಯತ್ನ ವಿಂಡೋವನ್ನು ಹೊಂದಿರುತ್ತದೆ.
- ಸಂಶ್ಲೇಷಿತ `60s` `defaultRetryAfterMs` (`upstreamStatusRestatement.ts`) ಎಂಬುದು ಮರುನಿರೂಪಿಸಲಾದ ಪ್ರತಿಕ್ರಿಯೆಯು **ಕ್ಲೈಂಟ್ಗೆ** ತಿಳಿಸುವ ಮಾಹಿತಿ ಮಾತ್ರ; ಅದು ಕನೆಕ್ಷನ್ನ ಆಂತರಿಕ ಕೂಲ್ಡೌನ್/ಲಾಕ್ಔಟ್ ಅವಧಿಯಲ್ಲ — ಅದನ್ನು ಮರುನಿರೂಪಿಸಲಾದ ದೋಷವನ್ನು ವಾಸ್ತವವಾಗಿ ನಿರ್ವಹಿಸುವ ಕಾರ್ಯವಿಧಾನವು ಪ್ರತ್ಯೇಕವಾಗಿ ನಿಯಂತ್ರಿಸುತ್ತದೆ (Connection Cooldown ನ ಹಂತಹಂತವಾಗಿ ಹೆಚ್ಚುವ ಬ್ಯಾಕ್ಆಫ್, §2, API-key ಪ್ರೊವೈಡರ್ಗಳಿಗೆ ಮೂಲ `3s`; ಅಥವಾ agentrouter ನಂತಹ ಪ್ರತಿ-ಮಾಡೆಲ್-ಕೋಟಾ ಪ್ರೊವೈಡರ್ಗಳಿಗೆ Model Lockout, §3). ಕ್ಲೈಂಟ್ಗೆ ಜಾಹೀರಾತು ಮಾಡುವ 60s ವಿಂಡೋಗಿಂತ ಮುಂಚೆಯೇ ರೂಟರ್ ಆಂತರಿಕವಾಗಿ ಮರುಪ್ರಯತ್ನಿಸಲು ಅರ್ಹವಾಗಬಹುದು — ಇದು ಉದ್ದೇಶಪೂರ್ವಕ ಹೆಚ್ಚುವರಿ ಅವಕಾಶವೇ ಹೊರತು ದೋಷವಲ್ಲ.

ಶಾಶ್ವತ ದೋಷಗಳನ್ನು (agentrouter ನ `无权访问模型` — ಈ ಮಾಡೆಲ್ಗೆ ಪ್ರವೇಶವಿಲ್ಲ) ಎಂದಿಗೂ ಮರುನಿರೂಪಿಸಲಾಗುವುದಿಲ್ಲ: `textMarkers` ಹೊಂದಿಕೆಯಾದಾಗಲೂ `excludeMarkers` ನಿಯಮವನ್ನು ವೀಟೋ ಮಾಡುತ್ತದೆ; ಆದ್ದರಿಂದ ದೋಷವು ತನ್ನ ಮೂಲ ಸ್ಥಿತಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಯಾವುದೂ ಅದನ್ನು ಅನಂತವಾಗಿ ಮರುಪ್ರಯತ್ನಿಸುವುದಿಲ್ಲ. ಹೊಂದಿಕೆಯಾಗುವ ಪ್ರೊವೈಡರ್ ವರ್ಗೀಕರಣ ನಿಯಮವನ್ನು (`open-sse/config/providerErrorRules.ts` ನಲ್ಲಿನ `agentrouter-model-access-denied`: `reason: "auth_error"`, `scope: "model"`, ಘೋಷಿತ ಮೂಲ ಕೂಲ್ಡೌನ್ `6h`) ಸಾಮಾನ್ಯ apikey-ವರ್ಗದ `FORBIDDEN` ಆರಂಭಿಕ-ರಿಟರ್ನ್ಗಿಂತ _ಮೊದಲು_ `checkFallbackError` (`open-sse/services/accountFallback.ts`) ಪರಿಶೀಲಿಸುತ್ತದೆ; ಇದು `honorsRuleLockScope(provider)` ಆಧಾರಿತವಾಗಿ ನಿಯಂತ್ರಿತವಾಗಿದೆ (#10334 — ಪ್ರಸ್ತುತ `providerErrorRules.ts` ನಲ್ಲಿರುವ `HONORS_RULE_LOCK_SCOPE_PROVIDERS` ಅನುಮತಿ ಪಟ್ಟಿಯ ಮೂಲಕ agentrouter ಗೆ ಮಾತ್ರ ಸೀಮಿತವಾಗಿದೆ). ನಿಯಮದ ಘೋಷಿತ 6h ಕೂಲ್ಡೌನ್ `fallbackResult.baseCooldownMs` ಆಗಿ ಮುಂದಕ್ಕೆ ಹರಿಯುತ್ತದೆ; ಆದರೆ ಅದು ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪ್ರತಿ-ಮಾಡೆಲ್-ಕೋಟಾ ಲಾಕ್ಔಟ್ ಮಾರ್ಗಕ್ಕೇ (`lockModelIfPerModelQuota()` / `recordModelLockoutFailure()`, ಕೂಲ್ಡೌನ್ ಮೂಲವನ್ನು ಹೊರತುಪಡಿಸಿ #10334 ರಿಂದ ಬದಲಾಗಿಲ್ಲ) ಒದಗಿಸಲಾಗುತ್ತದೆ: ಇತರ ಪ್ರತಿಯೊಂದು ಮಾಡೆಲ್ ಲಾಕ್ಔಟ್ನಂತೆಯೇ, ಅದನ್ನು ಆಪರೇಟರ್ನ `mlSettings.maxCooldownMs` (ಪೂರ್ವನಿಯೋಜಿತ `1_800_000ms` / 30min) ಮಿತಿಗೆ ಇಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು _ಉಳಿಸಲಾದ ಲಾಕ್ಔಟ್ ಕಾರಣವು_ ನಿಯಮದ `"auth_error"` ಬದಲಿಗೆ ಮೊದಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಹಾರ್ಡ್ಕೋಡ್ ಮಾಡಿದ `"forbidden"` ಆಗಿಯೇ ಉಳಿಯುತ್ತದೆ — ಕೂಲ್ಡೌನ್ ಅವಧಿಯನ್ನು ಮಾತ್ರ ಆರಂಭದಿಂದ ಅಂತ್ಯದವರೆಗೆ ಗೌರವಿಸಲಾಗುತ್ತದೆ, ಕಾರಣದ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಅಲ್ಲ. ಕನೆಕ್ಷನ್ ಸ್ವತಃ ಸಕ್ರಿಯವಾಗಿಯೇ ಉಳಿಯುತ್ತದೆ; ಅದೇ ಕನೆಕ್ಷನ್ನಲ್ಲಿರುವ ಇತರ ಮಾಡೆಲ್ಗಳಿಗೆ ಯಾವುದೇ ಪರಿಣಾಮವಾಗುವುದಿಲ್ಲ.

ಮರುನಿರೂಪಿಸಲಾದ ಕೋಟಾ ದೋಷಗಳು (`额度不足`) ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಒಂದು ಪ್ರೊವೈಡರ್ ನಿಯಮವನ್ನು ತಲುಪುತ್ತವೆ
(`agentrouter-user-quota-exhausted`: `reason: "quota_exhausted"`, `scope:
"connection"`, ತನ್ನದೇ ಆದ ಘೋಷಿತ ಕೂಲ್ಡೌನ್ ಇಲ್ಲ — ಪರ್ಸಿಸ್ಟೆನ್ಸ್ ಲೇಯರ್ನ
ಸ್ಕೇಲ್ ಮಾಡಿದ ಬ್ಯಾಕ್ಆಫ್ ಡಿಫಾಲ್ಟ್ ಅನ್ವಯಿಸುತ್ತದೆ). #10334 ರಿಂದ,
`ProviderErrorRuleMatch` ಮೇಲಿನ `scope` ಅನ್ನು ಆರಂಭದಿಂದ ಅಂತ್ಯದವರೆಗೆ ಬಳಸಲಾಗುತ್ತದೆ,
ಆದರೆ **ಕೇವಲ** `HONORS_RULE_LOCK_SCOPE_PROVIDERS` ಅನುಮತಿ ಪಟ್ಟಿಯಲ್ಲಿರುವ
ಪ್ರೊವೈಡರ್ಗಳಿಗೆ ಮಾತ್ರ (`providerErrorRules.ts` — ಪ್ರಸ್ತುತ `"agentrouter"`
ಮಾತ್ರ, `honorsRuleLockScope()` ಮೂಲಕ ಗೇಟ್ ಮಾಡಲಾಗಿದೆ). ಇತರ ಪ್ರತಿಯೊಂದು
ಪ್ರೊವೈಡರ್ಗೂ `scope` #10334 ಕ್ಕಿಂತ ಮುಂಚಿನಂತೆಯೇ ಕೇವಲ ಮಾಹಿತಿಪರವಾಗಿರುತ್ತದೆ.
`checkFallbackError` ಹೊಂದಿಕೆಯಾದ ನಿಯಮದ ಸ್ಕೋಪ್ ಅನ್ನು
`fallbackResult.ruleScope` ಆಗಿ ಹೊರತರುತ್ತದೆ;
`isAgentrouterConnectionQuotaScope()`
(`src/sse/services/auth.ts`) ಎಂಬುದು `ruleScope` ಅನ್ನು ಸಂಪರ್ಕ-ವ್ಯಾಪಿ,
ಸ್ವಯಂ-ಚೇತರಿಸಿಕೊಳ್ಳುವ ಸಂಕೇತವಾಗಿ ಗೌರವಿಸುವುದು ನಿಜವಾಗಿಯೂ ಸುರಕ್ಷಿತವೇ ಎಂಬುದನ್ನು
ದೃಢಪಡಿಸುವ ಹಂಚಿಕೆಯ ಗಾರ್ಡ್ ಆಗಿದೆ (ಸ್ಕೋಪ್ `"connection"`, ಕಾರಣ
`quota_exhausted`, ಎಂದಿಗೂ `permanent` ಅಲ್ಲ, ಎಂದಿಗೂ `creditsExhausted` ಅಲ್ಲ
— ಭವಿಷ್ಯದ ಯಾವುದೇ ನಿಯಮವು `"connection"` ಸ್ಕೋಪ್ ಅನ್ನು ಶಾಶ್ವತ ಖಾತೆ ಸ್ಥಿತಿಯೊಂದಿಗೆ
ಜೋಡಿಸುವುದರ ವಿರುದ್ಧದ ರಕ್ಷಣೆ). ಎರಡು ಕನ್ಸ್ಯೂಮರ್ಗಳು ಇದನ್ನು ಕರೆಯುತ್ತವೆ:

- **ಪರ್ಸಿಸ್ಟೆನ್ಸ್** (`markAccountUnavailable()`, `src/sse/services/auth.ts`):
  ಪಾಸ್ಥ್ರೂ-ಪ್ರೊವೈಡರ್ನ **ಪ್ರತಿ-ಮಾಡೆಲ್** ಲಾಕ್ಔಟ್ ಶಾಖೆಗೆ ಬೀಳುವ ಬದಲು
  (agentrouter ನಲ್ಲಿ `passthroughModels: true` ಇದೆ →
  `hasPerModelQuota()` `true` ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ), ಇದು ಒಂದು
  **ತಾತ್ಕಾಲಿಕ ಸಂಪರ್ಕ ಕೂಲ್ಡೌನ್** ಅನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ —
  `testStatus: "unavailable"` + `rateLimitedUntil`, ಆದರೆ ಎಂದಿಗೂ ಟರ್ಮಿನಲ್
  ಸ್ಥಿತಿಯನ್ನು (`credits_exhausted`/`banned`/`expired`) ಅಲ್ಲ — ಇದರಿಂದ ಕೂಲ್ಡೌನ್
  ಮುಗಿದ ನಂತರ ಸಂಪರ್ಕವು ಕೈಯಾರೆ ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಮರುಹೊಂದಿಸುವಿಕೆ ಅಗತ್ಯವಿಲ್ಲದೆ
  ಸ್ವಯಂ-ಚೇತರಿಸಿಕೊಳ್ಳುತ್ತದೆ. `disableCooling: true` ಹೊಂದಿರುವ ಸಂಪರ್ಕಗಳಿಗೆ
  ಇದನ್ನು ಬಿಟ್ಟುಬಿಡಲಾಗುತ್ತದೆ (#2997): ಆ ಆಯ್ಕೆಯಿಂದ ಹೊರಗುಳಿಯುವಿಕೆ ಬದಲಾಗಿ
  ಪ್ರತಿ-ಮಾಡೆಲ್ ಲಾಕ್ಔಟ್ಗೆ ಮುಂದುವರಿಯುತ್ತದೆ (ದಾಖಲಿಸಲಾದ ರಾಜಿ —
  ಶಾಖೆಯ ಮೇಲಿರುವ ಕೋಡ್ ಕಾಮೆಂಟ್ ನೋಡಿ).
- **ಅದೇ-ವಿನಂತಿಯ ಕಾಂಬೊ ರೂಟಿಂಗ್** (`applyComboTargetExhaustion()`,
  `open-sse/services/combo/targetExhaustion.ts`): ಅದೇ ಗಾರ್ಡ್ ಸಂಪರ್ಕವನ್ನು
  `${provider}:${connectionId}` ಕೀಲಿಯೊಂದಿಗೆ ಇನ್-ಮೆಮೊರಿ
  `exhaustedConnections` ಸೆಟ್ನಲ್ಲಿ ಗುರುತಿಸುತ್ತದೆ. ಇದು ತನ್ನ ಸ್ವಂತ ಟಾರ್ಗೆಟ್
  ಆಬ್ಜೆಕ್ಟ್ನಲ್ಲಿ ಅದೇ ನಿಖರವಾದ `connectionId` ಅನ್ನು _ಈಗಾಗಲೇ ಹೊಂದಿರುವ_
  ಉಳಿದಿರುವ SAME-REQUEST ಟಾರ್ಗೆಟ್ ಅನ್ನು ಮಾತ್ರ ಬಿಟ್ಟುಬಿಡುತ್ತದೆ
  (`getExhaustedTargetSkipReason()`,
  `open-sse/services/combo/comboPredicates.ts`, `if (provider &&
connectionId)` ಅನ್ನು `exhaustedConnections` ಲುಕ್ಅಪ್ಗೆ ಮೊದಲು) — ಸಹೋದರ
  ಟಾರ್ಗೆಟ್ಗಳು ತಮ್ಮದೇ ಆದ ಪಿನ್ ಮಾಡಿದ `connectionId` ಅನ್ನು ಹೊಂದಿರದ ಮತ್ತು
  ರೆಸ್ಪಾನ್ಸ್ನ `X-OmniRoute-Selected-Connection-Id` ಹೆಡರ್ನಿಂದ ಪ್ರತಿ-ಡಿಸ್ಪ್ಯಾಚ್ಗೆ
  ಒಂದನ್ನು ಮಾತ್ರ ಪರಿಹರಿಸುವ ಸರಳ ಮಾಡೆಲ್-ಪಟ್ಟಿ ಕಾಂಬೊ ಎಂದಿಗೂ ಆ ಕೀ ಹೊಂದಿಕೆಯನ್ನು
  ತಲುಪುವುದಿಲ್ಲ. ಆ ಸಾಮಾನ್ಯ ಸಂದರ್ಭದಲ್ಲಿ, ಉಳಿದ ಲೆಗ್ ಈಗಷ್ಟೇ ಖಾಲಿಯಾದ ಖಾತೆಯನ್ನು
  ಮರುಬಳಸದಂತೆ ಮಾಡುವ ನಿಜವಾದ ರಕ್ಷಣೆ ಈ Set ಅಲ್ಲ — ಅದು ಮೇಲಿನ ಪರ್ಸಿಸ್ಟೆನ್ಸ್ ಲೇಯರ್
  (ಸಂಪರ್ಕದ `rateLimitedUntil` ಈಗ ಭವಿಷ್ಯದಲ್ಲಿದೆ) ಮತ್ತು ಈ ವೈಫಲ್ಯಕ್ಕಾಗಿ
  `transientRateLimitedProviders` ಅನ್ನು ನಿಗ್ರಹಿಸುವ ಇದೇ ಗಾರ್ಡ್ನ ಸಂಯೋಜನೆಯಾಗಿದೆ
  ("ಎರಡು-ಹಂತದ ವಿನ್ಯಾಸ" ಮತ್ತು `targetExhaustion.ts` ನಲ್ಲಿನ
  `isAgentrouterConnectionQuotaScope` ಶಾಖೆಯ ಕೋಡ್ ಕಾಮೆಂಟ್ ನೋಡಿ): ಆ Set ಅನ್ನು
  ಗುರುತಿಸದೆ ಬಿಟ್ಟಾಗ, `combo.ts` ನ `allowRateLimitedConnection` ಬಲವಂತದ-ಅನುಮತಿ
  (`open-sse/services/combo.ts:1005-1013`, `:2734-2738`) ಪ್ರೊವೈಡರ್ನ ಉಳಿದ
  ಲೆಗ್ಗಳಿಗೆ ಸಕ್ರಿಯವಾಗುವುದಿಲ್ಲ; ಹೀಗಾಗಿ ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಆಯ್ಕೆಯ
  `rateLimitedUntil` ಫಿಲ್ಟರ್ (`src/sse/services/auth.ts:1238`) ಅನ್ನು
  ಸಾಮಾನ್ಯವಾಗಿ ಗೌರವಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಉಳಿದ ಲೆಗ್ ಬೇರೊಂದು, ಇನ್ನೂ ಅರ್ಹವಾಗಿರುವ
  agentrouter ಸಂಪರ್ಕವನ್ನು ಆಯ್ಕೆಮಾಡುತ್ತದೆ ಅಥವಾ ಯಾವುದೇ ಕ್ರೆಡೆನ್ಶಿಯಲ್ಗಳು
  ಲಭ್ಯವಿಲ್ಲದೆ ವಿಫಲವಾಗುತ್ತದೆ — ಈ ಶಾಖೆಯು ಈಗಷ್ಟೇ ಕೂಲ್ಡೌನ್ಗೆ ಒಳಪಡಿಸಿದ
  ಸಂಪರ್ಕದತ್ತ ಅದು ಬಲವಂತವಾಗಿ ಹಿಂದಿರುಗುವುದಿಲ್ಲ.

### ಎರಡು-ಹಂತದ ವಿನ್ಯಾಸ: ಸ್ಥಿತಿ ಮರುನಿರೂಪಣೆ, ನಂತರ ವರ್ಗೀಕರಣ

ಸ್ಥಿತಿ ಮರುನಿರೂಪಣೆ (`upstreamStatusRestatement.ts`) ಮತ್ತು ಪ್ರೊವೈಡರ್
ವರ್ಗೀಕರಣ ನಿಯಮಗಳು (`open-sse/config/providerErrorRules.ts`,
`providerRuleRegistry`) ಪ್ರೊವೈಡರ್ ಐಡಿ ಮತ್ತು ಪಠ್ಯ ಮಾರ್ಕರ್ಗಳೆರಡನ್ನೂ ಕೀಲಿಯಾಗಿ
ಬಳಸುವ ಪ್ರತ್ಯೇಕ ರಿಜಿಸ್ಟ್ರಿಗಳಾಗಿವೆ, ಆದರೆ ಅವು ವಿಭಿನ್ನ ಸ್ಥಳಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ
ಮತ್ತು ವಿಭಿನ್ನ ಉದ್ದೇಶಗಳನ್ನು ಪೂರೈಸುತ್ತವೆ: ಮರುನಿರೂಪಣೆಯು `chatCore.ts` ನಲ್ಲಿ
HTTP ಸ್ಥಿತಿಯನ್ನು ಆರಂಭದಲ್ಲೇ ಮರುಬರೆಯುತ್ತದೆ; ವರ್ಗೀಕರಣ ನಿಯಮಗಳು
`checkFallbackError()` ಒಳಗೆ ಫಾಲ್ಬ್ಯಾಕ್ `reason` ಮತ್ತು ಲಾಕ್ `scope`
(`model` / `provider` / `connection`) ಅನ್ನು ಆಯ್ಕೆಮಾಡುತ್ತವೆ
(`open-sse/services/accountFallback.ts`).

`providerErrorRules.ts` ನಲ್ಲಿರುವ `FULL_TEXT_RULE_PROVIDERS` ಅನುಮತಿ ಪಟ್ಟಿಯಲ್ಲಿ
ಸೇರಿಸಲಾದ ಪ್ರೊವೈಡರ್ಗಳಿಗೆ ಮಾತ್ರ ವರ್ಗೀಕರಣ ನಿಯಮಗಳು ಪೂರ್ಣ ದೋಷ **ಪಠ್ಯವನ್ನು**
(`额度不足` ನಂತಹ ಬಾಡಿ ಮಾರ್ಕರ್ಗಳಿಗೆ ಹೊಂದಿಸಲು ಇದು ಅಗತ್ಯ) ನೋಡುತ್ತವೆ — ಪ್ರಸ್ತುತ
`"agentrouter"` ಮಾತ್ರ. ಇತರ ಪ್ರತಿಯೊಂದು **ಅಂತರ್ನಿರ್ಮಿತ ಕ್ಯಾಟಲಾಗ್**
ಪ್ರೊವೈಡರ್ಗಾಗಿ, `checkFallbackError` ಪೂರ್ಣ ದೋಷದ ಬದಲಾಗಿ ಕೇವಲ ಸಂರಚಿತ ದೋಷವನ್ನು
(`{code, type}`) `getProviderErrorRuleMatch` ಗೆ ನೀಡುತ್ತದೆ; ಇದು
ಹೆಡರ್/ಸ್ಥಿತಿ/ಕೋಡ್-ಆಧಾರಿತ ನಿಯಮಗಳಿಗೆ ಸಾಕಾಗುತ್ತದೆ, ಆದರೆ ಬಾಡಿ-ಪಠ್ಯ ಮಾರ್ಕರ್ಗಳನ್ನು
ನೋಡಲಾರದು. `resolveRuleMatchBody()` ಸಹಾಯಕವು ಈ ಆಯ್ಕೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ:
ಅನುಮತಿ ಪಟ್ಟಿಯಲ್ಲಿರುವ ಪ್ರೊವೈಡರ್ಗಳಿಗೆ ಪೂರ್ಣ ದೋಷ ಪಠ್ಯ, ಇಲ್ಲದಿದ್ದರೆ ಸಂರಚಿತ ದೋಷ.
ಒಂದು **ಅಂತರ್ನಿರ್ಮಿತ** ಪ್ರೊವೈಡರ್ ಅನ್ನು `FULL_TEXT_RULE_PROVIDERS` ಗೆ ಸೇರಿಸುವುದು
ಸ್ಪಷ್ಟವಾದ ಪ್ರತಿ-ಪ್ರೊವೈಡರ್ ಆಯ್ಕೆಯಾಗಿದೆ — ಪಟ್ಟಿಯಲ್ಲಿಲ್ಲದ ಪ್ರತಿಯೊಂದು
ಪ್ರೊವೈಡರ್ನ ಡಿಫಾಲ್ಟ್ ಪಥವು ಬೈಟ್ಗೆ-ಬೈಟ್ ಬದಲಾಗದೆ ಉಳಿಯುವುದಕ್ಕಾಗಿ ಇದು ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ.

ನಿಯಮದ `scope` (`model` / `provider` / `connection`) ಎಂಬುದು
`FULL_TEXT_RULE_PROVIDERS` ನಿಂದ ಪ್ರತ್ಯೇಕವಾದ ಆಯ್ಕೆಯಾಗಿದೆ:
`checkFallbackError` ಅದನ್ನು ಕೇವಲ `fallbackResult.ruleScope` ಆಗಿ ಹೊರತರುತ್ತದೆ,
ಮತ್ತು ಡೌನ್ಸ್ಟ್ರೀಮ್ ಕನ್ಸ್ಯೂಮರ್ಗಳು ಅದನ್ನು ಕೇವಲ ಅದೇ ಫೈಲ್ನ
`HONORS_RULE_LOCK_SCOPE_PROVIDERS` ಅನುಮತಿ ಪಟ್ಟಿಯಲ್ಲಿರುವ ಪ್ರೊವೈಡರ್ಗಳಿಗೆ ಮಾತ್ರ
ಮಾಹಿತಿಪರ ಲೇಬಲ್ಗಿಂತ ಹೆಚ್ಚಿನದಾಗಿ ಗೌರವಿಸುತ್ತವೆ (`honorsRuleLockScope()` ಮೂಲಕ
ಗೇಟ್ ಮಾಡಲಾಗಿದೆ — ಪ್ರಸ್ತುತ `"agentrouter"` ಮಾತ್ರ). ಪ್ರೊವೈಡರ್ ಆ ಅನುಮತಿ
ಪಟ್ಟಿಯಲ್ಲಿದ್ದಾಗ `scope: "connection"` ಹೊಂದಿಕೆಯು ನಿಜವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ
ಎಂಬುದಕ್ಕಾಗಿ ಮೇಲಿನ "ಮರುನಿರೂಪಿಸಲಾದ ಕೋಟಾ ದೋಷಗಳು" ವಿಭಾಗವನ್ನು ನೋಡಿ.

**#11104 — ಆಪರೇಟರ್ ಘೋಷಿಸಿದ ನಿಯಮಗಳು ಎರಡೂ ಅನುಮತಿ ಪಟ್ಟಿಗಳನ್ನು ಬೈಪಾಸ್ ಮಾಡುತ್ತವೆ.** ಆಪರೇಟರ್ ಈ ಫೈಲ್ ಅನ್ನು
ತಿದ್ದುಪಡಿ ಮಾಡದೆಯೇ `settings.providerErrorRules`
(`open-sse/config/providerErrorRules.ts::setOperatorProviderErrorRules`)
ಮೂಲಕ ರನ್ಟೈಮ್ನಲ್ಲಿ ಪ್ರತಿ-ಪ್ರೊವೈಡರ್ ನಿಯಮವನ್ನು ಘೋಷಿಸಬಹುದು. ಅಂತರ್ನಿರ್ಮಿತ ಕ್ಯಾಟಲಾಗ್ ನಿಯಮಗಳ
**ಡೀಫಾಲ್ಟ್** ವರ್ತನೆಯನ್ನು ರಕ್ಷಿಸಲು ಉದ್ದೇಶಿಸಲಾದ ಅನುಮತಿ ಪಟ್ಟಿಗಳಾದ
`FULL_TEXT_RULE_PROVIDERS`/`HONORS_RULE_LOCK_SCOPE_PROVIDERS` ಹಿಂದೆ ಆಪರೇಟರ್ ನಿಯಮವನ್ನು
ನಿರ್ಬಂಧಿಸುವುದರಿಂದ, ಈಗಾಗಲೇ ಅಲ್ಲಿ ಪಟ್ಟಿಮಾಡಲಾದ ಪ್ರೊವೈಡರ್ಗಳನ್ನು ಹೊರತುಪಡಿಸಿ ಉಳಿದ ಪ್ರತಿಯೊಂದು
ಪ್ರೊವೈಡರ್ಗೂ ಸೆಟ್ಟಿಂಗ್ಗಳ ಕಾರ್ಯವಿಧಾನವು ನಿಷ್ಕ್ರಿಯವಾಗುತ್ತದೆ; ಏಕೆಂದರೆ ನಿಯಮವನ್ನು ಘೋಷಿಸುವುದೇ
ಆಪರೇಟರ್ನ ಸ್ಪಷ್ಟ ಆಯ್ಕೆಯಾಗಿದೆ. `resolveRuleMatchBody()` ಮತ್ತು `honorsRuleLockScope()` ಎರಡೂ
ಮೊದಲು `hasOperatorRuleForProvider()` ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತವೆ: ಆಪರೇಟರ್ ನಿಯಮವನ್ನು ಹೊಂದಿರುವ
ಪ್ರೊವೈಡರ್, ಅದು ಯಾವುದಾದರೂ ಅನುಮತಿ ಪಟ್ಟಿಯಲ್ಲಿಯೂ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಲೆಕ್ಕಿಸದೆ,
ಕಚ್ಚಾ ದೋಷ ಪಠ್ಯವನ್ನು ಪಡೆಯುತ್ತದೆ ಮತ್ತು ಅದರ ಘೋಷಿತ `scope` ಅನ್ನು ಗೌರವಿಸಲಾಗುತ್ತದೆ.

**ತಿಳಿದಿರುವ ಕೊರತೆ — HTTP 400 ಗಾಗಿ `providerRuleRegistry` ಅನ್ನು ಎಂದಿಗೂ ಪರಿಶೀಲಿಸಲಾಗುವುದಿಲ್ಲ.**
`checkFallbackError` ನ `BAD_REQUEST` ಶಾಖೆಯು status 400 ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತನ್ನದೇ ಪ್ಯಾಟರ್ನ್
ಅರೇಗಳ ಮೂಲಕ (`MODEL_ACCESS_DENIED_PATTERNS`,
`CONTEXT_OVERFLOW_PATTERNS`, ಇತ್ಯಾದಿ `accountFallback.ts` ನಲ್ಲಿ) ವರ್ಗೀಕರಿಸಿ,
ಅದರ ಮೇಲಿರುವ `configuredRule`/`getProviderErrorRuleMatch` ಶಾಖೆಯನ್ನು ತಲುಪುವ ಮೊದಲೇ
ರಿಟರ್ನ್ ಮಾಡುತ್ತದೆ. `status: 400` ಹೊಂದಿರುವ ಅಂತರ್ನಿರ್ಮಿತ ಕ್ಯಾಟಲಾಗ್ ನಿಯಮವು (ಅಥವಾ ಆಪರೇಟರ್
ನಿಯಮವು) ಸಿಂಟ್ಯಾಕ್ಸ್ ದೃಷ್ಟಿಯಿಂದ ಮಾನ್ಯವಾಗಿದ್ದರೂ ಎಂದಿಗೂ ಕಾರ್ಯಗತವಾಗುವುದಿಲ್ಲ. ಇಂದು ಯಾವುದೇ
ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ನಿಯಮವು 400 ಅನ್ನು ಗುರಿಯಾಗಿಸಿಕೊಂಡಿಲ್ಲ, ಆದ್ದರಿಂದ ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಯಾವುದಕ್ಕೂ
ಪರಿಣಾಮವಾಗುವುದಿಲ್ಲ — ಆದರೆ ಭವಿಷ್ಯದ 400 ನಿಯಮಕ್ಕೆ ಮೊದಲು ಈ ಶಾಖೆಯನ್ನು ಬದಲಾಯಿಸಬೇಕಾಗುತ್ತದೆ.
ಇದು ನಿಯಮವನ್ನು ಸೇರಿಸುವುದಕ್ಕಿಂತ ದೊಡ್ಡ ಬದಲಾವಣೆಯಾಗಿದೆ (ಇದು ಈಗಾಗಲೇ ಪ್ಯಾಟರ್ನ್-ಅರೇ ವರ್ತನೆಯ
ಮೇಲೆ ಅವಲಂಬಿಸಿರುವ ಪ್ರತಿಯೊಂದು ಪ್ರೊವೈಡರ್ಗೂ 400 ಅನ್ನು ಮರುವರ್ಗೀಕರಿಸುತ್ತದೆ) ಮತ್ತು ಒಂದೇ
ಪ್ರೊವೈಡರ್ನ ನಿಯಮ ಸೇರ್ಪಡೆಯ ವ್ಯಾಪ್ತಿಗೆ ಹೊರತಾಗಿದೆ.

### ಕೋಟಾವನ್ನು ತಪ್ಪಾಗಿ ನಿರೂಪಿಸುವ ಹೊಸ ಗೇಟ್ವೇಯನ್ನು ಸೇರಿಸುವುದು

1. `statusRestatementRegistry` ನಲ್ಲಿ ಒಂದು ನಿಯಮದ ಅರೇಯನ್ನು ನೋಂದಾಯಿಸಿ
   (`open-sse/config/upstreamStatusRestatement.ts`). `textMarkers` ಅನ್ನು
   ಪ್ರೊವೈಡರ್ಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿರಿಸಿ; `CREDITS_EXHAUSTED_SIGNALS`
   (`open-sse/services/accountFallback.ts`) ಜೊತೆಗೆ ಸಂಘರ್ಷಿಸುವ ಸಾಮಾನ್ಯ ಇಂಗ್ಲಿಷ್
   ಪದಗುಚ್ಛಗಳನ್ನು ಎಂದಿಗೂ ಮರುಬಳಕೆ ಮಾಡಬೇಡಿ.
2. ಸರಿಯಾದ ಲಾಕ್ ವ್ಯಾಪ್ತಿಯನ್ನು ಆಯ್ಕೆಮಾಡಲು (`connection` ಖಾತೆ-ವ್ಯಾಪಿ ಕೋಟಾಕ್ಕಾಗಿ,
   `model` ಪ್ರತಿ-ಮಾಡೆಲ್ ದೋಷಗಳಿಗಾಗಿ) ಐಚ್ಛಿಕವಾಗಿ
   `open-sse/config/providerErrorRules.ts` (`providerRuleRegistry`) ನಲ್ಲಿ
   ವರ್ಗೀಕರಣ ನಿಯಮಗಳನ್ನು ನೋಂದಾಯಿಸಿ. ಸಂಪೂರ್ಣ ದೋಷ ಪಠ್ಯ (ಬಾಡಿ ಮಾರ್ಕರ್ಗಳು) ಅಗತ್ಯವಿರುವ
   ನಿಯಮಗಳನ್ನು ಹೊಂದಿರುವ ಪ್ರೊವೈಡರ್ಗಳಿಗೆ ಮಾತ್ರ ಈ ಹಂತವು ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ:
   ಅದೇ ಫೈಲ್ನಲ್ಲಿರುವ `FULL_TEXT_RULE_PROVIDERS` ಗೆ ಪ್ರೊವೈಡರ್ id ಅನ್ನು ಸೇರಿಸಿ —
   ಇಲ್ಲದಿದ್ದರೆ `checkFallbackError` ನಿಯಮಕ್ಕೆ ರಚನಾತ್ಮಕ
   `{code, type}` ದೋಷವನ್ನು ಮಾತ್ರ ನೀಡುತ್ತದೆ ಮತ್ತು ಬಾಡಿ-ಪಠ್ಯ ನಿಯಮವು ಲೈವ್ ಟ್ರಾಫಿಕ್ಗೆ
   ಎಂದಿಗೂ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ಕೇವಲ `status`/`headers` ಮೇಲೆ ಹೊಂದಿಕೆಯಾಗುವ ನಿಯಮಗಳಿಗೆ
   (Opencode ಅಥವಾ Minimax ನ ನಿಯಮಗಳಂತೆ) ಈ ಆಯ್ಕೆ ಅಗತ್ಯವಿಲ್ಲ. ಪ್ರತ್ಯೇಕವಾಗಿ, ನಿಯಮವು
   `scope: "connection"` ಅನ್ನು ಘೋಷಿಸಿದರೆ ಮತ್ತು ನಿಜವಾದ ಕನೆಕ್ಷನ್-ವ್ಯಾಪಿ ಕೂಲ್ಡೌನ್ ಜೊತೆಗೆ
   ಅದೇ-ರಿಕ್ವೆಸ್ಟ್ ಕಾಂಬೊ ಸ್ಕಿಪ್ (ಕೇವಲ ಮಾಹಿತಿಗಾಗಿ ಇರುವ ಲೇಬಲ್ ಅಲ್ಲ) ಉದ್ದೇಶವಾಗಿದ್ದರೆ,
   ಅದೇ ಫೈಲ್ನಲ್ಲಿರುವ `HONORS_RULE_LOCK_SCOPE_PROVIDERS` ಗೆ ಪ್ರೊವೈಡರ್ id ಅನ್ನು ಸೇರಿಸಿ —
   ಇದೇ `markAccountUnavailable()` (`src/sse/services/auth.ts`) ಮತ್ತು
   `applyComboTargetExhaustion()`
   (`open-sse/services/combo/targetExhaustion.ts`) ನಲ್ಲಿ
   `isAgentrouterConnectionQuotaScope()`-ಶೈಲಿಯ ಬಳಕೆಯನ್ನು ಗೇಟ್ ಮಾಡುತ್ತದೆ; ಇದಿಲ್ಲದೆ,
   `scope` ಇನ್ನೂ `fallbackResult.ruleScope` ಮೂಲಕ ಹರಿಯುತ್ತದೆ, ಆದರೆ ಯಾವುದೂ ಅದರ ಮೇಲೆ
   ಕ್ರಮ ಕೈಗೊಳ್ಳುವುದಿಲ್ಲ.
3. `tests/unit/upstream-status-restatement.test.ts` ಮತ್ತು
   `tests/unit/agentrouter-error-rules.test.ts` ಅನ್ನು ಪ್ರತಿಬಿಂಬಿಸುವ ಯುನಿಟ್ ಪರೀಕ್ಷೆಗಳನ್ನು
   ಸೇರಿಸಿ (not-permanent / not-creditsExhausted ಗಾರ್ಡ್ಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ಮತ್ತು —
   ಪ್ರೊವೈಡರ್ಗೆ ಅನುಮತಿ ಪಟ್ಟಿ ಅಗತ್ಯವಿದ್ದರೆ — `resolveRuleMatchBody()` ಆ ಪ್ರೊವೈಡರ್ಗೆ
   ಮಾತ್ರ ಸಂಪೂರ್ಣ ಪಠ್ಯವನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸುವ ಪರೀಕ್ಷೆಯನ್ನೂ ಸೇರಿಸಿ).

`chatCore.ts`, `classifyError`, ಅಥವಾ ಕಾಂಬೊಗೆ ಯಾವುದೇ ಬದಲಾವಣೆಗಳ ಅಗತ್ಯವಿಲ್ಲ.

#### ಇಗ್ರೆಸ್-ಬಕೆಟ್ ಆಧಾರಿತ ಲಾಕ್ (#10880)

`EGRESS_BUCKETED_LOCK_PROVIDERS` ನಲ್ಲಿರುವ ಪ್ರೊವೈಡರ್ಗಳನ್ನು (opencode ಕುಟುಂಬ)
IP-ಬಕೆಟ್ ಆಧಾರಿತ ಅಪ್ಸ್ಟ್ರೀಮ್ಗಳಾಗಿ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ (opencode ಉಚಿತ ಟಿಯರ್
IP-ಬಕೆಟ್ ಆಧಾರಿತವಾಗಿದೆ, ಖಾತೆ-ಬಕೆಟ್ ಆಧಾರಿತವಲ್ಲ — #9611 ನೋಡಿ): `quota_exhausted`
**ಅಥವಾ** `rate_limit_exceeded` ಎಂದು ವರ್ಗೀಕರಿಸಲಾದ status-429, ರೊಟೇಶನ್ ಅವುಗಳನ್ನು
ಪ್ರಯತ್ನಿಸುವ ಮೊದಲು, ವಿಫಲವಾದ ಕನೆಕ್ಷನ್ನ ಕೊನೆಯದಾಗಿ ತಿಳಿದಿರುವ ಇಗ್ರೆಸ್ IP ಗೆ ಹೊಂದಿಕೆಯಾಗುವ
ಪ್ರತಿಯೊಂದು ಅನುಮತಿ-ಪಟ್ಟಿಯ ಕುಟುಂಬದ ಕನೆಕ್ಷನ್ಗೆ ಕೂಲ್ಡೌನ್ ವಿಧಿಸುತ್ತದೆ
— ಇದರಿಂದ ಖಚಿತವಾಗಿ ವಿಫಲವಾಗುವ N-1 ಅಪ್ಸ್ಟ್ರೀಮ್ ಕರೆಗಳನ್ನು ತಪ್ಪಿಸಲಾಗುತ್ತದೆ
(#10460/#10525 ರಂತೆಯೇ ಅದೇ ಸ್ವರೂಪ).
`rate_limit_exceeded` ಅನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸೇರಿಸಲಾಗಿದೆ: `markAccountUnavailable`
ಪಥದಲ್ಲಿ opencode-ನಿರ್ದಿಷ್ಟ ನಿಯಮಗಳು ಎಂದಿಗೂ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ (`checkFallbackError`
ಗೆ ಯಾವುದೇ ಹೆಡರ್ಗಳು/ಬಾಡಿ ನೀಡಲಾಗುವುದಿಲ್ಲ, opencode `FULL_TEXT_RULE_PROVIDERS` ನಲ್ಲಿ
ಇಲ್ಲ), ಆದ್ದರಿಂದ ಸಬ್ಸ್ಕ್ರಿಪ್ಶನ್-ಕೋಟಾ ಪಠ್ಯವನ್ನು ("monthly usage limit
reached") ಹೊಂದಿರುವ 429, `status_429` ನಿಯಮವನ್ನು ತಲುಪುವ ಮೊದಲೇ ಕೋಟಾ-ಪಠ್ಯ ಫಾಲ್ಬ್ಯಾಕ್
(`buildSubscriptionQuotaFallback`, `accountFallback.ts`; 1h ಕೂಲ್ಡೌನ್) ಮೂಲಕ
`quota_exhausted` ಎಂದು ವರ್ಗೀಕರಿಸಲಾಗುತ್ತದೆ — ಆದರೆ ಕೋಟಾ ಪಠ್ಯವಿಲ್ಲದ 429 (ಸರಳ ರೇಟ್
ಲಿಮಿಟಿಂಗ್) `status_429` ನಿಯಮದ ಮೂಲಕ `rate_limit_exceeded` ಎಂದು ವರ್ಗೀಕರಿಸಲ್ಪಟ್ಟು,
ಆದರೂ IP ಕುಟುಂಬಕ್ಕೆ ಕೂಲ್ಡೌನ್ ವಿಧಿಸುತ್ತದೆ. ಅನುಮತಿ ಪಟ್ಟಿಯಲ್ಲಿರುವ ಪ್ರೊವೈಡರ್ಗೆ
IP-ಬಕೆಟ್ ಆಧಾರಿತ ರೇಟ್ ಮಿತಿಯು ಖಾಲಿಯಾದ ಕೋಟಾದಂತೆಯೇ ಅದೇ ಸಂಕೇತವಾಗಿದೆ. ವಾಸ್ತವಿಕ ಮಿತಿಗಳು:

- **ಸಾಧ್ಯವಾದಷ್ಟು ಉತ್ತಮ ಪ್ರಯತ್ನ**: ಲಾಕ್, `proxy_logs` ನಿಂದ ಸಂಪರ್ಕದ ಕೊನೆಯದಾಗಿ ತಿಳಿದಿರುವ `egress_ip`
  ಅನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತದೆ (24h ವಿಂಡೋ, ಸಿಂಕ್ರೊನಸ್, ಕ್ಯಾಶ್ ಇಲ್ಲ). ಕೋಲ್ಡ್ ಕ್ಯಾಶ್ (egress
  IP ಅನ್ನು ಎಂದಿಗೂ ಪ್ರೋಬ್ ಮಾಡಿಲ್ಲ) ಅಥವಾ ಯಾವುದೇ ಸಾಲು ಇಲ್ಲದಿದ್ದರೆ → ವಿಫಲಗೊಳ್ಳುವ ಸಂಪರ್ಕವನ್ನು
  ಬ್ರಾಂಚ್ ಇನ್ನೂ ಕೂಲ್ಡೌನ್ ಮಾಡುತ್ತದೆ (ಈಗಿನಂತೆಯೇ ದಾಖಲಿಸಲಾಗುತ್ತದೆ), ಆದರೆ ಯಾವುದೇ ಸಹೋದರ ಸಂಪರ್ಕವನ್ನು ಲಾಕ್ ಮಾಡುವುದಿಲ್ಲ.
- **ಎಂದಿಗೂ ಟರ್ಮಿನಲ್ ಅಲ್ಲ**: ಕೂಲ್ಡೌನ್ ನವೀಕರಣಗೊಳ್ಳುವ ಕೋಟಾ ವಿಂಡೋ ಆಗಿದೆ
  (`testStatus: "unavailable"`); IP-ಮಟ್ಟದ ಸಿಗ್ನಲ್ನಿಂದ ಶಾಶ್ವತ ಸ್ಥಿತಿಯನ್ನು ಎಂದಿಗೂ
  ನಿರ್ಧರಿಸಲಾಗುವುದಿಲ್ಲ. `disableCooling` ಸಂಪರ್ಕಗಳು ಬ್ರಾಂಚ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಿಟ್ಟುಬಿಡುತ್ತವೆ.
- **ಅನುಮತಿಪಟ್ಟಿಯಲ್ಲಿರುವ ಕುಟುಂಬಕ್ಕೆ ಲಾಕ್ ಗ್ರ್ಯಾನ್ಯುಲಾರಿಟಿ ಬದಲಾಗುತ್ತದೆ**: ಇದು ಕೇವಲ
  ಸಹೋದರ ಆಪ್ಟಿಮೈಸೇಶನ್ ಅಲ್ಲ, ಸ್ಕೋಪ್ ಬದಲಾವಣೆ. opencode ಒಂದು `passthroughModels`
  ಪ್ರೊವೈಡರ್ ಆಗಿರುವುದರಿಂದ, ಈ ಬ್ರಾಂಚ್ಗಿಂತ ಮೊದಲು 429 ಪ್ರತಿ-MODEL ಲಾಕ್ಔಟ್ ಉಂಟುಮಾಡುತ್ತಿತ್ತು; ಈಗ ಅದು
  ಸಂಪರ್ಕದ ಕೂಲ್ಡೌನ್ ಉಂಟುಮಾಡುತ್ತದೆ — ಯಾವುದೇ ಸಹೋದರ ಸಂಪರ್ಕವಿಲ್ಲದೆ ಒಂದೇ ಸಂಪರ್ಕವನ್ನು ಚಲಾಯಿಸುವ
  ಆಪರೇಟರ್ಗೂ ಇದು ಅನ್ವಯಿಸುತ್ತದೆ. opencode ನಿಯಮಗಳ ಟೇಬಲ್ ಈಗಾಗಲೇ ಸರಿಯೆಂದು ಘೋಷಿಸಿರುವ
  ಗ್ರ್ಯಾನ್ಯುಲಾರಿಟಿ ಇದೇ (`scope: "connection"`,
  `providerErrorRules.ts`); opencode, `HONORS_RULE_LOCK_SCOPE_PROVIDERS` ನಲ್ಲಿ
  ಇಲ್ಲದಿರುವುದರಿಂದ ಇದುವರೆಗೆ ಇದನ್ನು ಪಾಲಿಸಲಾಗಿರಲಿಲ್ಲ. ಈ ಬ್ರಾಂಚ್, ಸಂಪರ್ಕ-ಸ್ಕೋಪ್ನ
  agentrouter ಬ್ರಾಂಚ್ ಅನ್ನು ಅನುಕರಿಸುತ್ತಾ, ವಿಫಲಗೊಳ್ಳುವ ಸಂಪರ್ಕದ ಕೂಲ್ಡೌನ್ + `backoffLevel`
  ಅನ್ನು ಸ್ವತಃ ಬರೆಯುತ್ತದೆ ಮತ್ತು ಹಿಂದಿರುಗುತ್ತದೆ — ಕೆಳಗಿನ ಪ್ರತಿ-model ಬ್ಲಾಕ್ ಮತ್ತು
  ಜೆನೆರಿಕ್ ಪಥವನ್ನು ಎಂದಿಗೂ ತಲುಪುವುದಿಲ್ಲ.
- **Combo ಒಳಗೊಂಡಿದೆ**: agentrouter ಬ್ರಾಂಚ್ನಂತೆಯೇ, combo ಕಾಲರ್ 429 ಗೆ ಅನ್ವಯಿಸುವ
  `persistUnavailableState`/`isCombo` ಡೌನ್ಗ್ರೇಡ್ ಅನ್ನು ಈ ಸ್ಕೋಪ್ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ
  ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ. ಪ್ರತಿ-model ಲಾಕ್ಔಟ್ ಈ ಸ್ಕೋಪ್ನ ದುರ್ಬಲ ರೂಪವಲ್ಲ, ಅದು ತಪ್ಪಾದ ಘಟಕ:
  ಖಾಲಿಯಾಗಿರುವ IP ಕುರಿತು ಅದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ combo ರೊಟೇಶನ್ ಪ್ರತಿ ಸಹೋದರ
  ಸಂಪರ್ಕಕ್ಕೆ ಖಚಿತವಾಗಿ ವಿಫಲಗೊಳ್ಳುವ ಒಂದು ಕರೆಯನ್ನು ವ್ಯರ್ಥಗೊಳಿಸುತ್ತಲೇ ಇರುತ್ತದೆ.
- **ಸಹೋದರ ಸಂಪರ್ಕದ ಸುರಕ್ಷತೆ**: ಈಗಾಗಲೇ ಟರ್ಮಿನಲ್ ಆಗಿರುವ (banned/credits_exhausted)
  ಅಥವಾ ಈಗಾಗಲೇ ದೀರ್ಘ ಕೂಲ್ಡೌನ್ನಲ್ಲಿರುವ ಸಹೋದರ ಸಂಪರ್ಕವನ್ನು ಎಂದಿಗೂ ಓವರ್ರೈಟ್ ಮಾಡಲಾಗುವುದಿಲ್ಲ.
- **ಪ್ರತ್ಯೇಕ ಅನುಮತಿಪಟ್ಟಿ**: `EGRESS_BUCKETED_LOCK_PROVIDERS` ಅನ್ನು ವಿಸ್ತರಿಸುವುದು
  ಸ್ಪಷ್ಟವಾದ ಮಾಲೀಕರ ನಿರ್ಧಾರವಾಗಿದೆ; ಜೆನೆರಿಕ್ ವೈರಿಂಗ್ ಅಲ್ಲ (pattern #10334/#10419).
  ಸಹೋದರ ಸಂಪರ್ಕದ ಕ್ವೆರಿ ಅದನ್ನು SQL ಲಿಟರಲ್ ಆಗಿ ಪುನರಾವರ್ತಿಸುವ ಬದಲು ಅದೇ ಅನುಮತಿಪಟ್ಟಿಯನ್ನು
  ಬೈಂಡ್ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ವಿಸ್ತರಿಸುವುದು ಒಂದೇ ಸಾಲಿನ ಬದಲಾವಣೆಯಾಗಿ ಉಳಿಯುತ್ತದೆ.
- **ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ Egress IP ರೊಟೇಶನ್**: ಲುಕ್ಅಪ್ ವಿಂಡೋ (24h), egress-IP ಕ್ಯಾಶ್
  TTL (5 min) ಗಿಂತ ಬಹಳ ವಿಶಾಲವಾಗಿದೆ, ಆದ್ದರಿಂದ "ಕೊನೆಯದಾಗಿ ತಿಳಿದಿರುವ IP" ಎಂಬುದು ಇತಿಹಾಸವೇ
  ಹೊರತು ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯಲ್ಲ. ವಿಂಡೋದೊಳಗೆ ಸಂಪರ್ಕದ ಪ್ರಾಕ್ಸಿ ರೊಟೇಟ್ ಆಗಿದ್ದರೆ ಲಾಕ್,
  ನಿಜವಾಗಿಯೂ ಹಂಚಿಕೊಂಡಿರುವ IP ಅನ್ನು **ತಪ್ಪಿಸಿಕೊಳ್ಳಬಹುದು** (ದಾಖಲಾದ IP ಹೊಸದು,
  ಖಾಲಿಯಾಗದಿರುವುದು) — ಮತ್ತು ಅದೇ ರೀತಿ, ಖಾಲಿಯಾದ IP ಯಿಂದ ನಂತರ ಬೇರೆಡೆಗೆ **ರೊಟೇಟ್ ಆಗಿರುವ
  ಸಹೋದರ ಸಂಪರ್ಕವನ್ನು ಕೂಲ್ಡೌನ್ ಮಾಡಬಹುದು**. ಎರಡನೆಯ ಸಂದರ್ಭವು ಆ ಸಹೋದರ ಸಂಪರ್ಕಕ್ಕೆ ಒಂದು
  ಕೂಲ್ಡೌನ್ ವಿಂಡೋದಷ್ಟು ನಷ್ಟ ಉಂಟುಮಾಡುತ್ತದೆ; ಇತಿಹಾಸ-ಆಧಾರಿತ ಲುಕ್ಅಪ್ನ ಸಾಧ್ಯವಾದಷ್ಟು ಉತ್ತಮ
  ಪ್ರಯತ್ನದ ಮಿತಿಗಳಾಗಿ ಎರಡನ್ನೂ ಸ್ವೀಕರಿಸಲಾಗಿದೆ.
- **ವೆಚ್ಚ**: `proxy_logs` ನ ಎರಡು ಮಿತಿಗೊಳಿಸಿದ ಸ್ಕ್ಯಾನ್ಗಳು (`idx_pl_timestamp` ಮೂಲಕ
  ವಿಂಡೋ-ಫಿಲ್ಟರ್ ಮಾಡಲಾಗಿದೆ), 429 ಸಂಭವಿಸುವ ಆವರ್ತನದಲ್ಲಿ ಮಾತ್ರ. ಹೊಸ ಇಂಡೆಕ್ಸ್ ಇಲ್ಲ (migration 134
  YAGNI). ಮಧ್ಯಮ ಗಾತ್ರದ ನೈಜ-ಟ್ರಾಫಿಕ್ DB ಪ್ರತಿಯಲ್ಲಿ ಅಳೆಯಲಾಗಿದೆ; ಹೆಚ್ಚಿನ-ಥ್ರೂಪುಟ್
  ಇನ್ಸ್ಟನ್ಸ್ ಅದೇ ವಿಂಡೋದಲ್ಲಿ ಅನುಪಾತಕ್ಕೆ ತಕ್ಕಂತೆ ಹೆಚ್ಚು ಸಾಲುಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ.

---

## ಇತರ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವ ವೈಶಿಷ್ಟ್ಯಗಳು

- **19 ರೂಟಿಂಗ್ ತಂತ್ರಗಳು** (priority, weighted, round-robin, context-relay, fill-first, p2c, random, least-used, cost-optimized, reset-aware, reset-window, headroom, strict-random, auto, lkgp, context-optimized, cache-optimized, fusion, pipeline) — [AUTO-COMBO.md](../routing/AUTO-COMBO.md) ನೋಡಿ.
- **ರೀಸೆಟ್-ಅವೇರ್ ರೂಟಿಂಗ್** (v3.8.0) — ಕೋಟಾ ಮರುಹೊಂದಿಸುವ ಸಮಯದ ಆಧಾರದಲ್ಲಿ ಸಂಪರ್ಕಗಳಿಗೆ ಆದ್ಯತೆ ನೀಡುತ್ತದೆ.
- **ಹಿನ್ನೆಲೆ ಮೋಡ್ ಡಿಗ್ರೇಡೇಶನ್** — Responses API `background: true` ಅನ್ನು ಎಚ್ಚರಿಕೆಯೊಂದಿಗೆ ಸಿಂಕ್ ಮೋಡ್ಗೆ ಇಳಿಸಲಾಗುತ್ತದೆ.
- **ಡೈನಾಮಿಕ್ ಟೂಲ್ ಮಿತಿ ಪತ್ತೆ** — ಟೂಲ್ಗಳ ಸಂಖ್ಯೆಯ ಮಿತಿಯನ್ನು ತಲುಪಿದಾಗ ಪೂರೈಕೆದಾರರಿಂದ ಹಿಮ್ಮೆಟ್ಟುತ್ತದೆ.
- **ತುರ್ತು ಫಾಲ್ಬ್ಯಾಕ್** — `OMNIROUTE_EMERGENCY_FALLBACK` ಮೂಲಕ ನಿಯಂತ್ರಿಸಲಾಗುತ್ತದೆ; ಆಪರೇಟರ್ಗಳು ಮರುಪ್ರಾರಂಭಿಸದೆಯೇ Feature Flags ಪುಟದಿಂದ ಇದನ್ನು ಅತಿಕ್ರಮಿಸಬಹುದು.

---

## ಡೀಬಗ್ ಮಾಡುವುದು

- ತೂಕ ನೀಡಲಾದ ಕಾಂಬೊ `503 all_targets_cooling_down` ಎಂದು ಉತ್ತರಿಸುತ್ತದೆ (`Retry-After` ಹೊಂದಿಸಲಾಗಿದೆ, `diagnostics.excluded` ಪ್ರತಿ ಗುರಿಯನ್ನೂ `model_lockout` / `circuit_open` / `provider_cooldown` / `unavailable` ಜೊತೆಗೆ ಪಟ್ಟಿಮಾಡುತ್ತದೆ) → ಪೂಲ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ ಸಂಪರ್ಕಿಸಲಾಗಿದೆ; ಪ್ರತಿ ಗುರಿಯೂ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವದ ಟೈಮರ್ನಿಂದ ಮಾತ್ರ ಹೊರಗಿಡಲಾಗಿದೆ; `[COMBO] Weighted selection: every target excluded before dispatch — …` ಎಚ್ಚರಿಕೆಯು ಕಾರಣಗಳು ಮತ್ತು ಉಳಿದಿರುವ ಸೆಕೆಂಡುಗಳನ್ನು ತಿಳಿಸುತ್ತದೆ. ಅದೇ ಕಾಂಬೊದಿಂದ ಬರುವ `404 no_executable_targets` ಎಂದರೆ ಯಾವುದೇ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವದ ಟೈಮರ್ ಒಳಗೊಂಡಿರಲಿಲ್ಲ (ಚಲಾಯಿಸಲು ಏನೂ ಇಲ್ಲ ಅಥವಾ ಪ್ರತಿ ಖಾತೆಯೂ ಲಭ್ಯತೆ ಪರಿಶೀಲನೆಯಲ್ಲಿ ವಿಫಲವಾಗಿದೆ). `targetResolution.ts` ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾದ ಹೊರಗಿಡುವಿಕೆಗಳಿಂದ `open-sse/services/combo/pinRecovery.ts` ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾಗಿದೆ.
- ಪೂರೈಕೆದಾರನ ಎಲ್ಲ ಕೀಗಳನ್ನು ಬಿಟ್ಟುಬಿಡಲಾಗಿದೆ → ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್ ಸ್ಥಿತಿ ಮತ್ತು ಪ್ರತಿ ಸಂಪರ್ಕದ `rateLimitedUntil`/`testStatus` ಎರಡನ್ನೂ ಪರಿಶೀಲಿಸಿ.
- ಮರುಹೊಂದಿಸುವಿಕೆ ಅವಧಿಯ ನಂತರ ಪೂರೈಕೆದಾರನನ್ನು ಶಾಶ್ವತವಾಗಿ ಹೊರಗಿಡಲಾಗಿದೆ → ಕೋಡ್ `getStatus()`/`canExecute()` ಬದಲಿಗೆ ಕಚ್ಚಾ `state` ಅನ್ನು ಓದುತ್ತಿದೆ.
- ಒಂದು ಕೀ ವಿಫಲವಾದರೂ ಇತರವು ಕೆಲಸ ಮಾಡಬೇಕು → ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್ಗಿಂತ ಸಂಪರ್ಕದ ಕೂಲ್ಡೌನ್ಗೆ ಆದ್ಯತೆ ನೀಡಿ.
- ಕೇವಲ ಒಂದು ಮಾದರಿ ವಿಫಲವಾಗಿದೆ → ಸಂಪರ್ಕದ ಕೂಲ್ಡೌನ್ಗಿಂತ ಮಾದರಿ ಲಾಕ್ಔಟ್ಗೆ ಆದ್ಯತೆ ನೀಡಿ.
- ಸ್ಥಿತಿಯು ಸ್ವಯಂ-ಚೇತರಿಸಿಕೊಳ್ಳಬೇಕು, ಆದರೆ ಆಗುತ್ತಿಲ್ಲ → ಭವಿಷ್ಯದ ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ ಮತ್ತು ಅವಧಿ ಮುಗಿದ ಸ್ಥಿತಿಯನ್ನು ರಿಫ್ರೆಶ್ ಮಾಡುವ ಓದುವಿಕೆ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ. ಶಾಶ್ವತ ಸ್ಥಿತಿಗಳಿಗೆ ಹಸ್ತಚಾಲಿತ ಬದಲಾವಣೆಗಳು ಅಗತ್ಯವಿವೆ.

---

## TLS ಫಿಂಗರ್ಪ್ರಿಂಟಿಂಗ್ ಮತ್ತು ಸ್ಟೆಲ್ತ್

ಪೂರೈಕೆದಾರ-ನಿರ್ದಿಷ್ಟ ಸ್ಟೆಲ್ತ್ (JA3/JA4, CCH, ಒಬ್ಫಸ್ಕೇಶನ್) ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ದಾಖಲಿಸಲಾಗಿದೆ — `docs/security/STEALTH_GUIDE.md` ನೋಡಿ (git; `/docs` ಒಳಗೆ ಕಂಪೈಲ್ ಮಾಡಲಾಗಿಲ್ಲ).

---

## ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವ ಪರೀಕ್ಷೆ (ಹಂತ 8 · ಬ್ಲಾಕ್ C)

ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವದ ಲಾಜಿಕ್ಗಾಗಿನ ಯುನಿಟ್ ಪರೀಕ್ಷೆಗಳ ಹೊರತಾಗಿ, ಮೂರು ಪರೀಕ್ಷೆಗಳು ನೈಜ ಒತ್ತಡ/ವೈಫಲ್ಯ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ರನ್ಟೈಮ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುತ್ತವೆ (ಎಲ್ಲವೂ ಇಂಟಿಗ್ರೇಶನ್/ನೈಟ್ಲಿ — ಯಾವುದೂ PRಗಳನ್ನು ತಡೆಯುವುದಿಲ್ಲ):

| ಪರೀಕ್ಷೆ     | ಏನು                                                                                                                                                                                                                                     | ರನ್ ಮಾಡಿ                                |
| ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- |
| ಕೆಯಾಸ್      | ನಕಲಿ-ಅಪ್ಸ್ಟ್ರೀಮ್ ನೋಡ್ ನೈಜ ಲೇಟೆನ್ಸಿ/ರೀಸೆಟ್/ಟೈಮ್ಔಟ್/503 ಅನ್ನು ಸೇರಿಸುತ್ತದೆ; ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್ ತೆರೆಯುತ್ತದೆ/ಚೇತರಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು `checkFallbackError` 503 ಅನ್ನು ಚೇತರಿಸಬಹುದಾದ ಫಾಲ್ಬ್ಯಾಕ್ ಎಂದು ವರ್ಗೀಕರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಮೌಲ್ಯೀಕರಿಸುತ್ತದೆ. | `RUN_CHAOS_INT=1 npm run test:chaos`    |
| ಹೀಪ್-ವೃದ್ಧಿ | `--expose-gc` ಅಡಿಯಲ್ಲಿ ಪ್ರತಿ `createSSEStream` ಗೆ ~500 ಸ್ಟ್ರೀಮ್ಗಳು; ಹೀಪ್ ನಿಗದಿತ ಗರಿಷ್ಠ ಮಿತಿಯನ್ನು ಮೀರಿ ಬೆಳೆದರೆ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ (OOM ಗಾರ್ಡ್ #3069).                                                                                       | `npm run test:heap`                     |
| k6 ಸೋಕ್     | `/api/monitoring/health` ವಿರುದ್ಧ ನಿರಂತರ ಲೋಡ್; p95/ದೋಷ ಮಿತಿಗಳು.                                                                                                                                                                          | `k6 run tests/load/k6-soak.js` (ನೈಟ್ಲಿ) |

`.github/workflows/nightly-resilience.yml` (cron + dispatch) ಮೂಲಕ ಸಂಯೋಜಿಸಲಾಗಿದೆ. ಡೀಫಾಲ್ಟ್ `test:integration` ನಲ್ಲಿ, ಕೆಯಾಸ್ ಮತ್ತು ಹೀಪ್ ಪರೀಕ್ಷೆಗಳು ಸ್ವಯಂ-ಸ್ಕಿಪ್ ಆಗುತ್ತವೆ (`RUN_CHAOS_INT`/`--expose-gc` ಇಲ್ಲದೆ).

---

## ಇದನ್ನೂ ನೋಡಿ

- [ಆರ್ಕಿಟೆಕ್ಚರ್ ಮಾರ್ಗದರ್ಶಿ](./ARCHITECTURE.md) — ಸಿಸ್ಟಮ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಮತ್ತು ಆಂತರಿಕ ಅಂಶಗಳು
- [ಬಳಕೆದಾರರ ಮಾರ್ಗದರ್ಶಿ](../guides/USER_GUIDE.md) — ಪ್ರೊವೈಡರ್ಗಳು, ಕಾಂಬೊಗಳು, CLI ಏಕೀಕರಣ
- [ಸ್ವಯಂ-ಕಾಂಬೊ ಎಂಜಿನ್](../routing/AUTO-COMBO.md) — 16-ಅಂಶಗಳ ಸ್ಕೋರಿಂಗ್, ಮೋಡ್ ಪ್ಯಾಕ್ಗಳು