feat(grok): migrate managed block to model_providers inheritance

docs-site/src/content/docs/fr/guides/grok-build.md

@@ -15,13 +15,16 @@ en `~/.grok/config.toml` :
 
 ```toml
 # >>> opencodex managed block — do not edit (removed by `ocx stop`) >>>
-[model.ocx-gpt-5-6-sol]
-model = "gpt-5.6-sol"
+[model_providers.opencodex]
 base_url = "http://127.0.0.1:10100/v1"
 api_backend = "responses"
 api_key = "opencodex-loopback"
-name = "OCX gpt-5.6-sol"
 extra_headers = { "x-opencodex-grok" = "1" }
+
+[model.ocx-gpt-5-6-sol]
+model = "gpt-5.6-sol"
+model_provider = "opencodex"
+name = "OCX gpt-5.6-sol"
 context_window = 272000
 supports_reasoning_effort = true
 reasoning_effort = "low"
@@ -32,7 +35,7 @@ value = "low"
 label = "Low"
 description = "Quick, fast implementations"
 default = true
-# ... autres niveaux de ce modèle, puis une table [model.ocx-*] par modèle visible ...
+# ... autres niveaux de ce modèle, puis une table [model.ocx-*] par modèle visible, chacun référençant model_provider = "opencodex" ...
 # <<< opencodex managed block <<<
 ```
 
@@ -77,12 +80,12 @@ en amont fixes, et non les métadonnées configurées pour les modèles routés.
 `none` et `minimal`, sont conservés lorsqu’ils sont annoncés. Les niveaux non pris en charge ou en double,
 notamment `ultra`, propre à Codex, sont omis du fichier afin que chaque option générée reste sélectionnable.
 
-Grok Build communique avec opencodex au moyen de Chat Completions et envoie `reasoning_effort` lorsque
-l’échelle est annoncée. Dans ce cas, le traducteur Chat Completions entrant définit par défaut le champ Responses
-`reasoning.summary` sur `auto` ; les traces de raisonnement parviennent donc à Grok sous la forme
-`delta.reasoning_content` au lieu d’être masquées. Réglez `include_reasoning: false` (ou
-`reasoning.summary: "none"`) si un client souhaite que le modèle réfléchisse sans renvoyer le
-tracé. Une valeur explicite de `reasoning.summary` prévaut lorsque les deux options sont présentes.
+Grok Build communique avec opencodex au moyen de l’API Responses. Lorsque la route annonce une
+échelle de raisonnement, le relais Responses transmet `reasoning.summary` tel que configuré, si bien
+que les traces de raisonnement parviennent à Grok nativement sous forme d’éléments de raisonnement
+Responses. Réglez `reasoning.summary: "none"` si un client souhaite que le modèle réfléchisse sans
+renvoyer le tracé. Une valeur explicite de `reasoning.summary` prévaut sur la valeur par défaut de la
+route.
 
 ## Note d'authentification
 
@@ -101,46 +104,49 @@ dehors des marqueurs gérés, où aucune opération opencodex ne peut les écras
 `base_url` (une adresse réellement accessible depuis l’endroit où vous exécutez `grok`) et `api_key` (votre
 `OPENCODEX_API_AUTH_TOKEN`).
 
-Ne remplacez pas `api_key` par `env_key` ici. En l’absence de `model_provider`, un `env_key` qui ne peut pas être
+Ne remplacez pas `api_key` par `env_key` ici. Un `env_key` qui ne peut pas être
 résolu n’interrompt pas la requête : Grok utilise alors votre jeton de session xAI et l’envoie à l’adresse
 `base_url` indiquée par l’entrée. Pour un déploiement sur le réseau local, cette adresse est un point de terminaison
 HTTP en clair qui n’appartient pas à xAI.
 
-La valeur `api_key` injectée pour chaque modèle se trouve en tête de la chaîne d’identifiants de Grok. Les requêtes
+La valeur `api_key` injectée sur l’entrée du fournisseur se trouve en tête de la chaîne d’identifiants de Grok. Les requêtes
 adressées à opencodex ne nécessitent donc aucune connexion Grok supplémentaire. Conservez votre configuration
 habituelle `grok login` / `XAI_API_KEY` pour les modèles Grok natifs et les fonctions qui contactent directement xAI.
 
 ## Recette manuelle (sans enregistrement automatique)
 
-Si vous gérez `~/.grok/config.toml` vous-même — ou si opencodex est sur une liaison sans bouclage — ajoutez
-tables par modèle avec **champs directs**, en dehors des marqueurs `# >>> opencodex managed block` :
+Si vous gérez `~/.grok/config.toml` vous-même — ou si opencodex est sur une liaison sans bouclage — ajoutez un bloc
+`[model_providers.opencodex]` et des tables par modèle qui le référencent via `model_provider`, en dehors des
+marqueurs `# >>> opencodex managed block` :
 
 ```toml
-[model.ocx-opus]
-model = "anthropic/claude-opus-4-8"
+[model_providers.opencodex]
 base_url = "http://127.0.0.1:10100/v1"
 api_backend = "responses"
 api_key = "opencodex-loopback"
+
+[model.ocx-opus]
+model = "anthropic/claude-opus-4-8"
+model_provider = "opencodex"
 ```
 
-Pour un proxy joignable sur le réseau, pointer `base_url` à l'adresse `grok` peut effectivement
-composez et utilisez votre jeton d'entrée :
+Pour un proxy joignable sur le réseau, pointez `base_url` vers l’adresse que `grok` peut réellement
+joindre et utilisez votre jeton d’entrée :
 
 ```toml
-[model.ocx-opus]
-model = "anthropic/claude-opus-4-8"
+[model_providers.opencodex]
 base_url = "http://192.168.1.10:10100/v1"   # the reachable host, not 127.0.0.1
 api_backend = "responses"
 api_key = "your-OPENCODEX_API_AUTH_TOKEN"
+
+[model.ocx-opus]
+model = "anthropic/claude-opus-4-8"
+model_provider = "opencodex"
 ```
 
-Ne comptez pas sur l'héritage `[model_providers.<id>]` pour le point de terminaison : à partir de Grok Build
-0.2.101 le `base_url` hérité n'est pas appliqué au routage d'inférence (les requêtes tombent
-jusqu'au proxy xAI par défaut et échoue avec 401). Itinéraire direct des champs par modèle
-correctement.
+Le bloc géré utilise désormais l’héritage `[model_providers.<id>]`, ce qui nécessite Grok Build 0.2.109 ou ultérieur (publié le 2026-07-21). Sur les versions antérieures, le `base_url` hérité n’est pas appliqué au routage d’inférence — mettez à niveau, ou utilisez des champs directs par modèle (`base_url`/`api_backend`/`api_key` sur chaque table `[model.*]`).
 
-Placez entre guillemets tout alias contenant un point : `[model.grok-4.5]` sans guillemets est un chemin de clé à trois segments, et non
-l'identifiant `grok-4.5`. Les alias générés évitent entièrement les points pour cette raison.
+Placez entre guillemets tout alias contenant un point : `[model.grok-4.5]` sans guillemets est un chemin de clé à trois segments, et non l'identifiant `grok-4.5`. Les alias générés évitent entièrement les points pour cette raison.
 
 ## Limitations connues
 

docs-site/src/content/docs/guides/grok-build.md

@@ -15,13 +15,16 @@ into `~/.grok/config.toml`:
 
 ```toml
 # >>> opencodex managed block — do not edit (removed by `ocx stop`) >>>
-[model.ocx-gpt-5-6-sol]
-model = "gpt-5.6-sol"
+[model_providers.opencodex]
 base_url = "http://127.0.0.1:10100/v1"
 api_backend = "responses"
 api_key = "opencodex-loopback"
-name = "OCX gpt-5.6-sol"
 extra_headers = { "x-opencodex-grok" = "1" }
+
+[model.ocx-gpt-5-6-sol]
+model = "gpt-5.6-sol"
+model_provider = "opencodex"
+name = "OCX gpt-5.6-sol"
 context_window = 272000
 supports_reasoning_effort = true
 reasoning_effort = "low"
@@ -32,7 +35,8 @@ value = "low"
 label = "Low"
 description = "Quick, fast implementations"
 default = true
-# ... remaining rungs for this model, then one [model.ocx-*] table per visible model ...
+# ... remaining rungs for this model, then one [model.ocx-*] table per visible model,
+# each referencing model_provider = "opencodex" ...
 # <<< opencodex managed block <<<
 ```
 
@@ -102,44 +106,51 @@ outside the managed markers, where nothing opencodex does can clobber them. See
 `base_url` (a host that is actually reachable from where you run `grok`) and `api_key`
 (your `OPENCODEX_API_AUTH_TOKEN`).
 
-Do not replace `api_key` with `env_key` here. With no `model_provider` set, an `env_key`
-that fails to resolve does not stop the request — Grok falls through to your xAI session
+Do not replace `api_key` with `env_key` here. An `env_key` that fails to resolve does not
+stop the request — Grok falls through to your xAI session
 token and sends it to whatever `base_url` the entry names, which for a LAN deployment is a
 plaintext HTTP endpoint that is not xAI.
 
-The injected per-model `api_key` sits first in Grok's credential chain for these models,
-so turns against opencodex need no additional Grok login. Keep your normal `grok login` /
-`XAI_API_KEY` setup for native grok models and any harness features that contact xAI
-directly.
+The injected `api_key` on the provider entry sits first in Grok's credential chain for
+these models, so turns against opencodex need no additional Grok login. Keep your normal
+`grok login` / `XAI_API_KEY` setup for native grok models and any harness features that
+contact xAI directly.
 
 ## Manual recipe (without auto-registration)
 
 If you manage `~/.grok/config.toml` yourself — or opencodex is on a non-loopback bind — add
-per-model tables with **direct fields**, outside the `# >>> opencodex managed block` markers:
+a `[model_providers.opencodex]` block and per-model tables that reference it, outside the
+`# >>> opencodex managed block` markers:
 
 ```toml
-[model.ocx-opus]
-model = "anthropic/claude-opus-4-8"
+[model_providers.opencodex]
 base_url = "http://127.0.0.1:10100/v1"
 api_backend = "responses"
 api_key = "opencodex-loopback"
+
+[model.ocx-opus]
+model = "anthropic/claude-opus-4-8"
+model_provider = "opencodex"
 ```
 
 For a proxy reachable over the network, point `base_url` at the address `grok` can actually
 dial and use your admission token:
 
 ```toml
-[model.ocx-opus]
-model = "anthropic/claude-opus-4-8"
+[model_providers.opencodex]
 base_url = "http://192.168.1.10:10100/v1"   # the reachable host, not 127.0.0.1
 api_backend = "responses"
 api_key = "your-OPENCODEX_API_AUTH_TOKEN"
+
+[model.ocx-opus]
+model = "anthropic/claude-opus-4-8"
+model_provider = "opencodex"
 ```
 
-Do not rely on `[model_providers.<id>]` inheritance for the endpoint: as of Grok Build
-0.2.101 the inherited `base_url` is not applied to inference routing (requests fall
-through to the default xAI proxy and fail with 401). Direct per-model fields route
-correctly.
+This uses `[model_providers.<id>]` inheritance, which requires Grok Build 0.2.109 or later
+(released 2026-07-21). On older versions the inherited `base_url` is not applied to inference
+routing — upgrade, or fall back to per-model direct fields (`base_url`/`api_backend`/`api_key`
+on each `[model.*]` table).
 
 Quote any alias containing a dot: bare `[model.grok-4.5]` is a three-segment key path, not
 the id `grok-4.5`. Generated aliases avoid dots entirely for this reason.

docs-site/src/content/docs/ja/guides/grok-build.md

@@ -11,13 +11,16 @@ opencodex はローカル ポート上で OpenAI 互換の `POST /v1/chat/comple
 
 ```toml
 # >>> opencodex managed block — do not edit (removed by `ocx stop`) >>>
-[model.ocx-gpt-5-6-sol]
-model = "gpt-5.6-sol"
+[model_providers.opencodex]
 base_url = "http://127.0.0.1:10100/v1"
 api_backend = "responses"
 api_key = "opencodex-loopback"
-name = "OCX gpt-5.6-sol"
 extra_headers = { "x-opencodex-grok" = "1" }
+
+[model.ocx-gpt-5-6-sol]
+model = "gpt-5.6-sol"
+model_provider = "opencodex"
+name = "OCX gpt-5.6-sol"
 context_window = 272000
 supports_reasoning_effort = true
 reasoning_effort = "low"
@@ -28,7 +31,8 @@ value = "low"
 label = "Low"
 description = "Quick, fast implementations"
 default = true
-# ... remaining rungs for this model, then one [model.ocx-*] table per visible model ...
+# ... remaining rungs for this model, then one [model.ocx-*] table per visible model,
+# each referencing model_provider = "opencodex" ...
 # <<< opencodex managed block <<<
 ```
 
@@ -67,47 +71,51 @@ Grok 互換に投影した内容が、管理対象の各 `[model.*]` テーブ
 保持されます。Codex 固有の `ultra` を含む、未対応または重複する段階はファイルから
 除外され、出力された選択肢はすべて実行できます。
 
-Grok Build は Chat Completions 経由で opencodex と通信し、ラダーが公開されている
-場合は `reasoning_effort` を送ります。Chat Completions の入力変換は、この場合に
-内部 Responses の `reasoning.summary` を `auto` に設定するため、推論トレースは
-`delta.reasoning_content` として Grok に届きます。トレースを返さずにモデルに
-推論させるクライアントは、`include_reasoning: false`（または
-`reasoning.summary: "none"`）を設定できます。両方が指定された場合は、明示的な
-`reasoning.summary` が優先されます。
+Grok Build は Responses API 経由で opencodex と通信します。ルートが推論ラダーを
+公開している場合、Responses パススルーは設定どおりに `reasoning.summary` を転送するため、
+推論トレースは Responses の reasoning 項目としてそのまま Grok に届きます。トレースを
+返さずにモデルに推論させるクライアントは、`reasoning.summary: "none"` を設定できます。
+明示的な `reasoning.summary` はルートの既定値より優先されます。
 
 ## 認証メモ
 
 Grok Build では、ループバックでもカスタム モデルに対して空ではない API キーが必要です。挿入されたエントリにはプレースホルダー (`opencodex-loopback`) が含まれます。opencodex はループバック接続のアドミッション キーを無視するため、実際の秘密は関係しません。
 
 **自動登録はループバックのみです。** opencodex が非ループバック ホスト (すべてのインターフェイスを公開するワイルドカード `0.0.0.0` および `::` を含む) をバインドする場合、リクエストには実際のアドミッション トークンが必要であり、マネージド ブロックはそれを安全に運ぶことができません。リテラルトークンを書き込むと、シークレットが `~/.grok/config.toml` に設定され、そこで設定した内容が次の `ocx start`/`ensure`/`restart` に上書きされます。したがって、その場合、opencodex は何も書き込みません (そして、以前のループバック バインドで残ったブロックはすべて削除します)。また、管理対象マーカーの外側でモデルを自分で設定します。opencodex が何をしてもモデルを破壊することはありません。正確なテーブルについては [マニュアルレシピ](#manual-recipe-without-auto-registration) を参照し、`base_url` (`grok` を実行する場所から実際に到達可能なホスト) と `api_key` (`OPENCODEX_API_AUTH_TOKEN`) の両方を設定します。
 
-ここで `api_key` を `env_key` に置き換えないでください。 `model_provider` が設定されていない場合、解決に失敗した `env_key` はリクエストを停止しません。Grok は xAI セッション トークンに到達し、それをエントリ名が `base_url` に送信します。LAN デプロイメントの場合、これは xAI ではないプレーンテキスト HTTP エンドポイントです。
+ここで `api_key` を `env_key` に置き換えないでください。解決に失敗した `env_key` はリクエストを停止しません。Grok は xAI セッション トークンに到達し、それをエントリ名が `base_url` に送信します。LAN デプロイメントの場合、これは xAI ではないプレーンテキスト HTTP エンドポイントです。
 
-注入されたモデルごとの `api_key` は、これらのモデルの Grok 資格情報チェーンの最初に位置するため、opencodex に対抗する場合は追加の Grok ログインは必要ありません。ネイティブ grok モデルおよび xAI に直接接続するハーネス機能については、通常の `grok login` / `XAI_API_KEY` セットアップを維持します。
+プロバイダー エントリに注入された `api_key` は、これらのモデルの Grok 資格情報チェーンの最初に位置するため、opencodex に対抗する場合は追加の Grok ログインは必要ありません。ネイティブ grok モデルおよび xAI に直接接続するハーネス機能については、通常の `grok login` / `XAI_API_KEY` セットアップを維持します。
 
 ## 手動レシピ（自動登録なし）
 
-`~/.grok/config.toml` を自分で管理する場合、または opencodex が非ループバック バインド上にある場合は、**直接フィールド**を持つモデルごとのテーブルを `# >>> opencodex managed block` マーカーの外側に追加します。
+`~/.grok/config.toml` を自分で管理する場合、または opencodex が非ループバック バインド上にある場合は、`[model_providers.opencodex]` ブロックとそれを参照するモデルごとのテーブルを `# >>> opencodex managed block` マーカーの外側に追加します。
 
 ```toml
-[model.ocx-opus]
-model = "anthropic/claude-opus-4-8"
+[model_providers.opencodex]
 base_url = "http://127.0.0.1:10100/v1"
 api_backend = "responses"
 api_key = "opencodex-loopback"
+
+[model.ocx-opus]
+model = "anthropic/claude-opus-4-8"
+model_provider = "opencodex"
 ```
 
 ネットワーク経由で到達可能なプロキシの場合は、`grok` が実際にダイヤルしてアドミッション トークンを使用できるアドレスに `base_url` を指定します。
 
 ```toml
-[model.ocx-opus]
-model = "anthropic/claude-opus-4-8"
+[model_providers.opencodex]
 base_url = "http://192.168.1.10:10100/v1"   # the reachable host, not 127.0.0.1
 api_backend = "responses"
 api_key = "your-OPENCODEX_API_AUTH_TOKEN"
+
+[model.ocx-opus]
+model = "anthropic/claude-opus-4-8"
+model_provider = "opencodex"
 ```
 
-エンドポイントの `[model_providers.<id>]` 継承に依存しないでください。Grok Build 0.2.101 では、継承された `base_url` は推論ルーティングに適用されません (リクエストはデフォルトの xAI プロキシにフォールスルーされ、401 で失敗します)。モデルごとのフィールドを正しくルーティングします。
+管理ブロックは `[model_providers.<id>]` 継承を使用するようになり、Grok Build 0.2.109 以降（2026-07-21 リリース）が必要です。旧バージョンでは継承された `base_url` は推論ルーティングに適用されません——アップグレードするか、各 `[model.*]` テーブルでモデルごとの直接フィールド（`base_url`/`api_backend`/`api_key`）を使用してください。
 
 ドットを含むエイリアスを引用符で囲みます。裸の `[model.grok-4.5]` は 3 セグメントのキー パスであり、ID `grok-4.5` ではありません。この理由により、生成されたエイリアスではドットが完全に回避されます。