fix(server): reclaim inbound body capacity with a configurable budget

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

@@ -64,6 +64,8 @@ Après une inscription ou une connexion OAuth dans l’interface, une boîte de
 | `codexPinnedTransientPolicy?` | `"hold" \| "detour-new-threads"` | `"hold"` | Quand un compte épinglé est dégradé, `hold` continue de l'utiliser et journalise un avertissement ; `detour-new-threads` ne déplace que les nouveaux fils. Un tour déjà envoyé n'est jamais renvoyé. |
 | `codexWsReuseAcrossTurns?` | `boolean` | `false` | Réutilisation optionnelle du WebSocket Codex entre les tours d'un même compte et fil. Désactivé par défaut. Activé, un socket occupé est attendu au plus 750 ms et jusqu'à deux sockets restent lors d'un changement de modèle ou de palier. |
 | `upstreamHostCircuitThreshold?` | `number` | `0` | Seuil facultatif du coupe-circuit pour les échecs DNS/TCP avérés avant connexion sur les requêtes Responses OpenAI natives en mode transfert et les envois compacts. `0` le désactive ; `1`–`20` ouvre, après ce nombre de requêtes logiques arrivées à leur terme, une temporisation de 30 secondes propre à l'origine du fournisseur. Tant que le circuit est ouvert, les requêtes reçoivent `503` avec `Retry-After` avant la sélection du compte ou l'envoi en amont ; après la temporisation, une requête est admise en état semi-ouvert. Les délais d'attente et les réponses HTTP ne sont jamais comptabilisés, et toute réponse HTTP ferme le circuit. Ce mécanisme s'applique uniquement au routage du pool Codex sans compte épinglé ; il reste inactif pour `codexAccountMode: "direct"` et les sélecteurs qualifiés par compte. |
+| `maxInboundBodyBytes?` | `number` | `0` | Limite en octets de la taille décodée d'un corps JSON entrant par requête. Une valeur absente ou `0` conserve les 256 MiB par défaut ; la valeur configurée est bornée à 1–512 MiB. Redémarrage requis. Un dépassement produit un HTTP 413 local avec le code `inbound_body_too_large`. Une limite effective supérieure à 256 MiB active aussi le contrôle partagé `maxConcurrentInboundBodyBytes` ; relever la limite par requête ne relève pas à lui seul le budget partagé. Routes concernées et détails : [admission des corps entrants](/fr/reference/inbound-body-admission/). |
+| `maxConcurrentInboundBodyBytes?` | `number` | `536870912` (512 MiB) | Budget partagé d'admission facultatif de premier niveau, en octets, actif uniquement si la valeur effective de `maxInboundBodyBytes` dépasse 256 MiB. Une valeur absente, `0` ou invalide utilise les 512 MiB par défaut, inchangés. Les entiers positifs valides sont bornés à 512 MiB–2 GiB (`536870912`–`2147483648`) lors de leur utilisation. Redémarrage requis ; tous les écouteurs d'un processus partagent un seul budget. Il s'agit d'un décompte d'admission, pas d'une préallocation mémoire, d'une limite RSS ou d'un dimensionnement automatique selon la RAM. Choisir 2 GiB exige une décision explicite de l'opérateur. Voir [l'admission des corps entrants](/fr/reference/inbound-body-admission/) pour l'exemple, les compromis de file et de cycle de vie des réponses, et la raison pour laquelle le budget par défaut ne permet qu'un seul envoi complet de 512 MiB avant l'analyse. |
 | `modelCacheTtlMs?` | `number` | `300000` | Fenêtre de fraîcheur pour le cache `/models` par fournisseur. |
 | `cacheRetention?` | `"none" \| "short" \| "long"` | Anthropic direct : `"long"` ; autres points de terminaison compatibles Anthropic : `"short"` | Politique Anthropic de mise en cache des invites : désactivée, éphémère pendant 5 minutes ou étendue à 1 heure. Sans valeur, les requêtes vers `api.anthropic.com` (clé API ou pools de comptes OAuth) utilisent un TTL d’une heure ; les passerelles et points de terminaison compatibles gardent 5 minutes. Une valeur explicite l’emporte toujours. |
 | `tokenGuardian?` | `OcxTokenGuardianConfig` | désactivé | Politique facultative d'actualisation proactive OAuth et de préchauffage des comptes Codex. |

docs-site/src/content/docs/fr/reference/inbound-body-admission.md

@@ -9,14 +9,67 @@ reste 256 MiB et les valeurs configurées restent comprises entre 1 MiB et 512 M
 proxy après avoir modifié la limite afin que l'écouteur et les lecteurs utilisent ensemble la
 valeur voulue.
 
+Conserver l'ancien budget partagé par défaut de 512 MiB ne supprime pas les compromis
+décrits ci-dessous concernant la file et la rétention pendant le cycle de vie des réponses.
+
+## Choisir explicitement le budget partagé
+
+`maxConcurrentInboundBodyBytes` est un réglage facultatif de **premier niveau** dans
+`config.json`, exprimé en octets. Sa valeur par défaut reste **512 MiB (`536870912`)**,
+comme auparavant. Une valeur absente, `0` ou invalide utilise cette valeur par défaut.
+Un entier positif valide est borné à **512 MiB–2 GiB (`536870912`–`2147483648`)** lors
+de son utilisation. Redémarrez le proxy après modification. Tous les écouteurs d'un même
+processus partagent un seul budget, distinct de `appOwnedMemoryBudgetMb`.
+
+Pour choisir une limite de 512 MiB par requête et activer explicitement un budget partagé
+de 2 GiB, ajoutez ces champs au premier niveau de votre `config.json`, puis redémarrez :
+
+```json
+{
+  "maxInboundBodyBytes": 536870912,
+  "maxConcurrentInboundBodyBytes": 2147483648
+}
+```
+
+Ce choix de l'opérateur augmente le pic potentiel de consommation mémoire. Le proxy ne
+détecte pas automatiquement la RAM disponible et ne choisit pas le budget en fonction de celle-ci.
+
 ## Augmenter la limite modifie la simultanéité
 
-Quand la limite résolue dépasse 256 MiB, chaque requête HTTP concernée réserve toute sa marge
-configurée dans un budget d'admission partagé de 512 MiB pour le processus entier. Au plus une
-requête de ce type peut donc s'exécuter à la fois, même si plusieurs écouteurs partagent le
-processus. Les petits corps réservent eux aussi toute la marge ; ni un petit Content-Length ni
-la compression ne contournent l'admission. La réservation demeure jusqu'à la fin du flux de
-réponse, son échec ou la fin de l'annulation, et pas seulement jusqu'à l'analyse du JSON entrant.
+Quand la limite effective dépasse 256 MiB, chaque requête HTTP concernée doit réserver toute
+sa marge par requête **avant toute lecture du corps**. Ces réservations partagent le budget
+`maxConcurrentInboundBodyBytes` du processus, dont la valeur par défaut reste **512 MiB**.
+
+Avant la fin de l'analyse JSON avec contrôle de taille, ni un petit `Content-Length` ni un petit
+corps compressé sur le réseau ne réduisent la réservation. L'admission ne considère pas ces
+valeurs comme une preuve fiable de la taille décodée ou normalisée du JSON.
+
+Après une analyse JSON réussie dans les limites de taille, le lecteur réduit la réservation
+au maximum des octets observés sur le réseau, des octets décodés et de la mesure existante du
+JSON normalisé lorsqu'un traducteur fournit un budget pour cette mesure. La réservation ne
+peut que diminuer et reste plafonnée à la marge initiale par requête ; une mesure du JSON
+normalisé supérieure à cette marge ne l'augmente jamais. Les contrôles UTF-8 et de JSON
+resérialisé sont conservés ; la longueur d'entrée ne remplace pas la taille potentiellement
+plus grande du JSON normalisé.
+
+Avec le **budget partagé par défaut de 512 MiB** et une **limite de 512 MiB par requête**,
+**un seul envoi non encore analysé** peut réserver toute sa marge. Même si l'analyse réduit
+sa réservation à **un octet**, la capacité restante est inférieure à 512 MiB. La prochaine
+marge complète doit donc attendre qu'assez de capacité soit libérée. La valeur par défaut
+**ne résout pas** le problème initial de simultanéité avec une limite de 512 MiB par requête.
+
+Définir explicitement `maxConcurrentInboundBodyBytes` à `2147483648` choisit **2 GiB** et
+permet jusqu'à **4 envois réservant chacun 512 MiB** avant l'analyse et les réductions après
+mesure. Ce budget de 2 GiB ne fixe pas un plafond de 4 requêtes après l'analyse : par exemple,
+**8 très petites requêtes peuvent diffuser leur réponse simultanément** lorsque les réservations
+réduites laissent de la place aux admissions suivantes, sous réserve du budget partagé et
+des autres limites.
+
+La réservation réduite reste détenue pendant le travail asynchrone et l'attente du fournisseur,
+jusqu'à la fin du flux de réponse (EOF), une erreur ou la fin de l'annulation. L'analyse seule
+ne la libère pas. Si le client se déconnecte, elle reste détenue jusqu'à la fin de l'annulation
+côté producteur. Elle est libérée exactement une fois, même si erreur, abandon et annulation
+se produisent en concurrence.
 
 Les points de terminaison POST concernés sont `/v1/responses`, `/v1/responses/compact`,
 `/v1/chat/completions`, `/v1/messages`, `/v1/messages/count_tokens`,
@@ -26,33 +79,51 @@ existantes par corps. Les traductions directes internes et les appels combo ne r
 une deuxième marge HTTP. Les limites de gestion, d'audio, d'historique de contexte et de
 WebSocket restent inchangées.
 
-Un réglage absent ou égal à zéro, ou une limite résolue inférieure ou égale à 256 MiB,
-n'active pas ce contrôle supplémentaire de simultanéité. Les limites existantes sur le nombre
-de requêtes et les autres ressources continuent de s'appliquer.
+Ce contrôle supplémentaire ne s'applique que si la valeur effective de `maxInboundBodyBytes`
+dépasse 256 MiB. Omettre ce réglage par requête ou le définir à `0` conserve sa valeur par
+défaut de 256 MiB et laisse le contrôle inactif. Omettre ou mettre à zéro
+`maxConcurrentInboundBodyBytes` choisit au contraire le budget partagé par défaut de 512 MiB,
+sans désactiver un contrôle déjà actif. Les limites existantes sur le nombre de requêtes et
+les autres ressources continuent de s'appliquer.
 
 ## Refus temporaire ou corps trop volumineux
 
-Si aucune marge n'est temporairement disponible, le serveur renvoie HTTP **503**,
-`Retry-After: 1` et le code d'erreur `server_busy`, avant l'analyse du protocole ou l'envoi au
-fournisseur. Les clients Messages et de comptage de jetons reçoivent une erreur au format
-Anthropic de type `overloaded_error` ; les clients compatibles OpenAI reçoivent
-`server_error`. Réessayez après la fin de la requête en cours, en respectant l'en-tête de
-nouvelle tentative et la temporisation du client. Augmenter encore la limite du corps ne
-résout pas l'indisponibilité de la marge.
+Si la marge complète est temporairement indisponible, la requête peut rejoindre une **file
+FIFO de 32 requêtes en attente au maximum**, avec une **attente limitée à 120 secondes**.
+Pendant l'attente, l'application ne lit pas les corps des requêtes. Une réduction après mesure ou une libération
+finale permet d'admettre les requêtes dans l'ordre de la file. Une requête abandonnée pendant
+l'attente est retirée de la file et son corps non lu est annulé sans être consommé.
+
+Une file pleine ou une attente expirée entraîne HTTP **503**, `Retry-After: 1` et le code
+d'erreur `server_busy`, avant l'analyse du corps ou l'envoi au fournisseur. Les corps non lus
+sont annulés lors du refus. Les clients Messages et de comptage de jetons reçoivent une erreur
+au format Anthropic de type `overloaded_error` ; les clients compatibles OpenAI reçoivent
+`server_error`. Les contrôles d'authentification et d'origine précèdent l'admission et la mise
+en file.
+
+Respectez l'en-tête de nouvelle tentative et la temporisation du client. L'attente bornée et
+les réservations mesurées réduisent les refus de capacité évitables, sans éliminer toutes les
+réponses 503. Augmenter encore la limite par requête ne résout pas un épuisement durable de
+la capacité.
 
 Un corps dépassant sa limite par requête suit toujours le traitement HTTP **413** existant.
 Une taille déclarée excessive emprunte cette voie plutôt que de devenir un refus pour serveur
-occupé. Une déconnexion conserve le comportement d'annulation existant. Les contrôles
-d'authentification et d'origine précèdent ce contrôle de simultanéité.
+occupé.
 
 ## Ce que mesure le budget
 
-512 MiB est la somme des marges admises par requête, **pas une garantie que la mémoire du
-processus restera sous 512 MiB**. Le décodage, les chaînes, les graphes d'objets, les copies
-de requêtes et les autres états de l'application consomment davantage de mémoire. Les mesures
-existantes des octets UTF-8 et du JSON resérialisé sont conservées ; la longueur de l'entrée
-en octets ne remplace pas la taille potentiellement plus grande du JSON normalisé.
+Le budget configuré compte des unités d'admission : les marges complètes avant l'analyse,
+puis les réservations mesurées. Il **ne préalloue ni 2 GiB ni le volume configuré** et
+**ne borne ni la RSS du processus ni le tas des objets analysés**. Le décodage, les chaînes,
+les graphes d'objets, les copies de requêtes et les autres états de l'application consomment
+de la mémoire supplémentaire ; la consommation réelle peut donc dépasser le budget.
+
+Choisir 2 GiB au lieu du budget partagé par défaut de 512 MiB quadruple la réservation totale
+possible. Avec une limite de 512 MiB par requête, ce choix explicite admet jusqu'à quatre envois
+complets avant l'analyse au lieu d'un, ce qui augmente le pic potentiel de consommation mémoire.
+Choisissez le budget selon la marge mémoire de votre déploiement. Une limite par requête
+inférieure ou égale à 256 MiB laisse ce contrôle inactif, quel que soit le budget partagé.
 
-Pour des petites requêtes parallèles, conservez si possible la limite par défaut. Augmentez-la
-volontairement pour un parcours avec un historique volumineux, en acceptant la restriction de
-simultanéité supplémentaire.
+Conservez si possible la limite par requête par défaut. Augmentez-la volontairement si un
+parcours avec un historique volumineux l'exige, en tenant compte du pic mémoire potentiellement
+plus élevé et de l'attente bornée.

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

@@ -62,6 +62,8 @@ GUI で登録または OAuth ログインが完了すると、Models ページ
 | `codexPinnedTransientPolicy?` | `"hold" \| "detour-new-threads"` | `"hold"` | 手動ピンが劣化したとき、`hold` は警告を出して使い続け、`detour-new-threads` は新しいスレッドだけを別アカウントへ置きます。送信済みのターンは再送しません。 |
 | `codexWsReuseAcrossTurns?` | `boolean` | `false` | 同一アカウントとスレッドで Codex WebSocket をターンをまたいで再利用します。既定はオフ。オンにすると忙しいソケットを最大750ms待ち、モデルやティアの変更では最大2本を残します。 |
 | `upstreamHostCircuitThreshold?` | `number` | `0` | ネイティブOpenAI forwardのResponses送信とcompact送信で、実証済みの接続前DNS/TCP障害に適用するオプトインのサーキットしきい値です。`0`で無効、`1`〜`20`ではその回数の終端論理リクエストが失敗するとprovider-originを30秒間遮断します。遮断中はアカウント選択やupstream送信の前に`Retry-After`付き`503`を返し、時間経過後はhalf-openリクエストを1件だけ許可します。タイムアウトとHTTP応答は数えず、HTTP応答が1件でもあれば回路を閉じます。 Codex Pool ルーティングでアカウントが固定されていない場合にのみ適用され、`codexAccountMode: "direct"` とアカウント修飾セレクターでは動作しません。 |
+| `maxInboundBodyBytes?` | `number` | `0` | 受信する JSON 本文 1 件のデコード後のサイズを制限するバイト単位の設定です。省略または `0` でデフォルトの 256 MiB を維持し、設定値は 1〜512 MiB に制限されます。変更後は再起動が必要です。超過時はコード `inbound_body_too_large` のローカル HTTP 413 を返します。適用される上限が 256 MiB を超えると `maxConcurrentInboundBodyBytes` の共有ゲートも有効になり、リクエスト単位の上限だけを上げても共有予算は増えません。対象ルートと詳細は[受信リクエスト本文の受け入れ](/ja/reference/inbound-body-admission/)を参照してください。 |
+| `maxConcurrentInboundBodyBytes?` | `number` | `536870912` (512 MiB) | バイト単位の任意のトップレベル共有受け入れ予算です。適用される `maxInboundBodyBytes` が 256 MiB を超える場合にのみ有効です。省略、`0`、無効な値は従来のデフォルト 512 MiB を使います。有効な正の整数は使用時に 512 MiB〜2 GiB (`536870912`〜`2147483648`) に制限されます。再起動が必要で、同一プロセス内のすべてのリスナーが 1 つの予算を共有します。受け入れの計上用であり、メモリの事前割り当て、RSS 上限、RAM に応じた自動調整ではありません。2 GiB には運用者の明示的な選択が必要です。設定例、キューとレスポンスのライフサイクルに伴う制約、デフォルトで解析前の完全な 512 MiB アップロードが 1 件だけになる理由は[受信リクエスト本文の受け入れ](/ja/reference/inbound-body-admission/)を参照してください。 |
 | `modelCacheTtlMs?` | `number` | `300000` |プロバイダーごとの `/models` キャッシュの鮮度ウィンドウ。 |
 | `cacheRetention?` | `"none" \| "short" \| "long"` | Anthropic ファーストパーティ: `"long"`、その他の Anthropic 互換エンドポイント: `"short"` | Anthropic プロンプト キャッシュ ポリシー: 無効、5 分間の一時的、または 1 時間の延長。未設定の場合、`api.anthropic.com`（API キーまたは OAuth アカウント プール）へのリクエストは 1 時間の TTL を使い、互換ゲートウェイやベンダーのエンドポイントは 5 分の TTL のままです。明示した値が常に優先されます。 |
 | `tokenGuardian?` | `OcxTokenGuardianConfig` |オフ |オプションのプロアクティブな OAuth 更新および Codex アカウントのウォームアップ ポリシー。 |