feat(grok): inject per-model reasoning effort into Grok Build config

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

@@ -21,7 +21,18 @@ base_url = "http://127.0.0.1:10100/v1"
 api_backend = "chat_completions"
 api_key = "opencodex-loopback"
 name = "OCX gpt-5.6-sol"
-# ... one [model.ocx-*] table per visible model ...
+extra_headers = { "x-opencodex-grok" = "1" }
+context_window = 372000
+supports_reasoning_effort = true
+reasoning_effort = "low"
+
+[[model.ocx-gpt-5-6-sol.reasoning_efforts]]
+id = "low"
+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 ...
 # <<< opencodex managed block <<<
 ```
 
@@ -33,7 +44,7 @@ name = "OCX gpt-5.6-sol"
 - **Supprimé à l’arrêt :** `ocx stop`, `ocx eject`, `ocx uninstall` et l’arrêt normal
   du démon hors service suppriment le bloc délimité et restaurent votre fichier
   octet pour octet. Sous un gestionnaire de service, le démontage passe par `ocx stop`/`ocx
-  uninstall` (les processus en mode service maintiennent intentionnellement le blocage lors des réapparitions).
+  uninstall` (les processus en mode service conservent intentionnellement le bloc lors des relancements).
 - **Les alias en conflit** déjà définis dans vos propres tables `[model.*]` sont respectés
   (opencodex ajoute un suffixe à ses propres entrées) ; un bloc délimité endommagé (marqueur de début sans marqueur de fin)
   refuse tout changement automatique et demande une réparation manuelle.
@@ -51,15 +62,20 @@ grok -m ocx-anthropic-claude-opus-4-8 -p "hello"
 Les commandes `/effort` et `--effort` de Grok Build ne fonctionnent que pour les modèles dont l’entrée de catalogue
 annonce une échelle d’effort : la récupération de la liste des modèles lit la réponse brute de `GET /v1/models`, et
 les entrées doivent contenir `supports_reasoning_effort` ainsi que les choix du menu
-`reasoning_efforts`. Pour les entrées de modèles routés, opencodex reflète les niveaux configurés pour le fournisseur
+`reasoning_efforts`. Une projection compatible avec Grok de cette échelle est également écrite dans chaque table
+`[model.*]` gérée, avec `supports_reasoning_effort`, la valeur par défaut `reasoning_effort` et les lignes
+`[[model.<alias>.reasoning_efforts]]`, afin que le menu soit présent lorsque Grok lit le modèle depuis
+`config.toml`. Pour les entrées de modèles routés, opencodex reflète les niveaux configurés pour le fournisseur
 (`reasoningEfforts` / `modelReasoningEfforts`, et la valeur par défaut de
-`modelDefaultReasoningEfforts`) dans cette réponse. Ces métadonnées décrivent l’échelle des modèles routés
-configurée dans le proxy ; elles ne prétendent pas que le fournisseur prend nativement en charge ces niveaux.
+`modelDefaultReasoningEfforts`). Ces métadonnées décrivent l’échelle des modèles routés configurée dans le proxy ;
+elles ne prétendent pas que le fournisseur prend nativement en charge ces niveaux.
 Les adaptateurs peuvent émuler le raisonnement ou mapper les niveaux sur des champs propres au fournisseur.
 Les modèles routés qui possèdent une échelle configurée affichent le contrôle de l’effort dans Grok Build comme
 dans Codex. Ceux dont la liste de niveaux est vide n’affichent aucun contrôle d’effort, conformément au comportement
 de Codex. Les entrées GPT-5.6 natives sont distinctes : elles conservent et exposent leurs échelles de raisonnement
-en amont fixes, et non les métadonnées configurées pour les modèles routés.
+en amont fixes, et non les métadonnées configurées pour les modèles routés. Les niveaux Grok valides, notamment
+`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
@@ -74,26 +90,25 @@ Grok Build exige une clé API non vide pour les modèles personnalisés, même s
 injectées contiennent une valeur fictive (`opencodex-loopback`) ; opencodex ignore les clés d’admission pour les
 connexions de bouclage, de sorte qu’aucun véritable secret n’est utilisé.
 
-**L’enregistrement automatique est réservé au bouclage.** Lorsque opencodex se lie à un hôte hors bouclage, y compris
-les caractères génériques `0.0.0.0` et `::`, qui exposent chaque interface — les requêtes ont besoin de votre réel
-jeton d’admission, et un bloc géré ne peut pas en transporter un en toute sécurité. Écrire le jeton littéral
-mettez votre secret dans `~/.grok/config.toml` et écrasez tout ce que vous y avez défini lors du prochain
-`ocx start`/`ensure`/`restart`. Donc opencodex n’écrit rien du tout dans ce cas (et supprime
-tout bloc restant d'une liaison de bouclage précédente), et vous configurez les modèles vous-même
-en dehors des marqueurs gérés, où rien de ce que opencodex fait ne peut les écraser. Voir
-[Recette manuelle](#recette-manuelle-sans-enregistrement-automatique) pour le tableau exact et réglez les deux
-`base_url` (un hôte réellement accessible à partir de l'endroit où vous exécutez `grok`) et `api_key`
-(votre `OPENCODEX_API_AUTH_TOKEN`).
-
-Ne remplacez pas `api_key` par `env_key` ici. Sans `model_provider` défini, un `env_key`
-qui ne parvient pas à résoudre n'arrête pas la demande — Grok passe à votre xAI session
-et l'envoie à n'importe quel `base_url` nom d'entrée, ce qui pour un LAN déploiement est un
-texte en clair HTTP point de terminaison qui n'est pas xAI.
-
-Le modèle injecté `api_key` se trouve en premier dans la chaîne d'informations d'identification de Grok pour ces modèles,
-donc les tours contre opencodex n'ont pas besoin de connexion Grok supplémentaire. Gardez votre `grok login` /
-`XAI_API_KEY` configuration pour les modèles Grok natifs et toutes les fonctionnalités de harnais qui contactent xAI
-directement.
+**L’enregistrement automatique est réservé au bouclage.** Lorsque opencodex écoute sur une adresse qui n’est pas
+de bouclage — y compris les caractères génériques `0.0.0.0` et `::`, qui exposent toutes les interfaces — les
+requêtes doivent présenter votre véritable jeton d’admission, qu’un bloc géré ne peut pas transporter en toute
+sécurité. Inscrire ce jeton en clair stockerait votre secret dans `~/.grok/config.toml` et écraserait toute valeur
+que vous y auriez définie lors du prochain `ocx start`/`ensure`/`restart`. Dans ce cas, opencodex n’écrit donc rien
+(et supprime tout bloc laissé par une ancienne liaison de bouclage) ; vous configurez vous-même les modèles en
+dehors des marqueurs gérés, où aucune opération opencodex ne peut les écraser. Consultez la
+[recette manuelle](#recette-manuelle-sans-enregistrement-automatique) pour obtenir la table exacte, puis définissez
+`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
+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
+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)
 
@@ -144,9 +159,10 @@ l'identifiant `grok-4.5`. Les alias générés évitent entièrement les points
   prévisibles. Grok Build surveille `~/.grok/config.toml` et recharge la configuration lorsque la table
   `[model]` change réellement (temporisation d’environ une seconde, avec comparaison du contenu) ;
   un bloc actualisé atteint une session ouverte sans redémarrage. Pour confirmer ce que Grok a analysé,
-  run `grok inspect` : il répertorie les sources de configuration qu'il a chargées et avertit de tout champ qu'il a chargé
-  rejeté. Il n'imprime pas la liste des modèles résolus. Notez qu’une seule erreur TOML
-  invalide *l'intégralité* de la couche de configuration utilisateur, c'est pourquoi opencodex écrit le fichier
-  atomiquement - Grok ne voit jamais une configuration à moitié écrite.
+  exécutez `grok inspect` : il répertorie les sources de configuration chargées et signale les champs
+  rejetés. Il n'affiche pas la liste des modèles résolus. La version actuelle de Grok Build signale et
+  ignore les champs de modèle invalides tout en conservant le reste de l'entrée. Une erreur de syntaxe
+  TOML empêche toujours le chargement du fichier. opencodex écrit de manière atomique, de sorte que
+  Grok observe un document complet à chaque rechargement.
 - **Mises à jour du catalogue :** le bloc délimité reflète le catalogue au moment de l’injection. Après
   l’ajout de fournisseurs ou de modèles, exécutez `ocx ensure` (ou redémarrez le proxy) pour l’actualiser.

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

@@ -21,7 +21,18 @@ base_url = "http://127.0.0.1:10100/v1"
 api_backend = "chat_completions"
 api_key = "opencodex-loopback"
 name = "OCX gpt-5.6-sol"
-# ... one [model.ocx-*] table per visible model ...
+extra_headers = { "x-opencodex-grok" = "1" }
+context_window = 372000
+supports_reasoning_effort = true
+reasoning_effort = "low"
+
+[[model.ocx-gpt-5-6-sol.reasoning_efforts]]
+id = "low"
+value = "low"
+label = "Low"
+description = "Quick, fast implementations"
+default = true
+# ... remaining rungs for this model, then one [model.ocx-*] table per visible model ...
 # <<< opencodex managed block <<<
 ```
 
@@ -51,15 +62,22 @@ grok -m ocx-anthropic-claude-opus-4-8 -p "hello"
 Grok Build's `/effort` (and `--effort`) only works for models whose catalog entry
 advertises the ladder: its model list fetch reads the raw `GET /v1/models` response, and
 entries there must carry `supports_reasoning_effort` plus `reasoning_efforts` menu
-options. For routed model entries, opencodex mirrors the configured provider tiers
-(`reasoningEfforts` / `modelReasoningEfforts`, and the default from
-`modelDefaultReasoningEfforts`) onto that response. This metadata describes the
-proxy-configured routed ladder — it does not claim native upstream reasoning support,
-and adapters may emulate reasoning or map levels onto provider-specific fields. Routed
-models with a configured ladder show the effort control in Grok Build just like they do
-in Codex. Models with an empty tier list keep no effort control, matching Codex
-behavior. Native GPT-5.6 entries are separate: they preserve and expose their pinned
-upstream reasoning ladders rather than provider-configured routed metadata.
+options. A Grok-compatible projection of that ladder is written into each managed
+`[model.*]` table
+(`supports_reasoning_effort`, default `reasoning_effort`, and
+`[[model.<alias>.reasoning_efforts]]` picker rows) so the menu is present when Grok
+reads the model from `config.toml`. For routed model entries, opencodex mirrors the
+configured provider tiers (`reasoningEfforts` / `modelReasoningEfforts`, and the default
+from `modelDefaultReasoningEfforts`). This metadata describes the proxy-configured
+routed ladder. Adapters may emulate reasoning or map levels onto provider-specific
+fields. Routed models with a configured ladder show the effort control in Grok Build
+just like they do in Codex.
+Models with an empty tier list keep no effort control, matching Codex behavior. Native
+GPT-5.6 entries are separate: they preserve and expose their pinned upstream reasoning
+ladders rather than provider-configured routed metadata. Valid Grok rungs, including
+`none` and `minimal`, are preserved when advertised. Unsupported or duplicate rungs,
+including Codex-only `ultra`, are omitted from the file, keeping every emitted picker
+option selectable.
 
 Grok Build talks to opencodex over Chat Completions and sends `reasoning_effort` when
 the ladder is advertised. The Chat Completions inbound translator defaults the internal
@@ -145,8 +163,9 @@ the id `grok-4.5`. Generated aliases avoid dots entirely for this reason.
   `[model]` table actually changes (roughly a one-second debounce, compared by content), so
   a refreshed block reaches an open session without a restart. To confirm what Grok parsed,
   run `grok inspect`: it lists the config sources it loaded and warns about any field it
-  rejected. It does not print the resolved model list. Note that a single TOML error
-  invalidates the *entire* user config layer, which is why opencodex writes the file
-  atomically — Grok never sees a half-written config.
+  rejected. It does not print the resolved model list. Current Grok Build reports and skips
+  invalid model fields while retaining the rest of the model entry. A TOML syntax error still
+  prevents the file from loading. opencodex writes atomically, so Grok observes a complete
+  document on every reload.
 - **Catalog updates:** the fenced block reflects the catalog at injection time. After
   adding providers or models, run `ocx ensure` (or restart the proxy) to refresh it.

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

@@ -17,7 +17,18 @@ base_url = "http://127.0.0.1:10100/v1"
 api_backend = "chat_completions"
 api_key = "opencodex-loopback"
 name = "OCX gpt-5.6-sol"
-# ... one [model.ocx-*] table per visible model ...
+extra_headers = { "x-opencodex-grok" = "1" }
+context_window = 372000
+supports_reasoning_effort = true
+reasoning_effort = "low"
+
+[[model.ocx-gpt-5-6-sol.reasoning_efforts]]
+id = "low"
+value = "low"
+label = "Low"
+description = "Quick, fast implementations"
+default = true
+# ... remaining rungs for this model, then one [model.ocx-*] table per visible model ...
 # <<< opencodex managed block <<<
 ```
 
@@ -38,6 +49,32 @@ grok -m ocx-anthropic-claude-opus-4-8 -p "hello"
 # or in the TUI: /model ocx-anthropic-claude-opus-4-8
 ```
 
+## 推論 effort
+
+Grok Build の `/effort`（および `--effort`）は、カタログ項目がラダーを公開している
+モデルで動作します。モデル一覧は生の `GET /v1/models` 応答を読み、その項目には
+`supports_reasoning_effort` と `reasoning_efforts` のメニュー選択肢が必要です。ラダーを
+Grok 互換に投影した内容が、管理対象の各 `[model.*]` テーブルにも
+`supports_reasoning_effort`、既定の
+`reasoning_effort`、`[[model.<alias>.reasoning_efforts]]` の各行として書き込まれます。
+ルーティングされたモデルでは、opencodex が設定済みのプロバイダー階層
+（`reasoningEfforts` / `modelReasoningEfforts` と
+`modelDefaultReasoningEfforts` の既定値）を反映します。このメタデータはプロキシで
+設定されたラダーを表し、アダプターは推論をエミュレートしたり、レベルを
+プロバイダー固有のフィールドへ変換したりできます。空の階層リストでは effort
+コントロールを表示しません。ネイティブ GPT-5.6 項目は、固定された上流の推論
+ラダーを保持します。モデルが公開する有効な Grok 段階（`none` と `minimal` を含む）は
+保持されます。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 では、ループバックでもカスタム モデルに対して空ではない API キーが必要です。挿入されたエントリにはプレースホルダー (`opencodex-loopback`) が含まれます。opencodex はループバック接続のアドミッション キーを無視するため、実際の秘密は関係しません。
@@ -80,6 +117,6 @@ api_key = "your-OPENCODEX_API_AUTH_TOKEN"
 アップストリーム沈黙中の `/v1/responses` ストリーム。 Grok Build の Responses デコーダは未知のイベント タイプを拒否するため、手動で構成された `api_backend = "responses"` モデルは低速なアップストリームではターン中に失敗する可能性があります。自動登録されたエントリは `api_backend = "chat_completions"` をピン留めしますが、生のハートビート フレームが表示されることはありません。
 - **サービスでインストールされた `ocx restart`:** 実行中のプロキシが再起動の認可とドレインの調整を担当し、古いプロセスの終了後はインストール済みのサービス マネージャーが置換プロセスを起動します。サービス監視は維持されます。ループバックの自動登録を使用している場合に限り、マネージド ブロックもハンドオフ中に維持されます。非ループバック構成では Grok 設定を手動管理します。同じポートで、別の ID 検証済みプロセスが正常になったことを確認した場合にのみ成功します。
 - **構成読み取りタイミング:** 最初に opencodex を起動し、その後 `grok` を起動します。
-予測可能な結果。 Grok Build は `~/.grok/config.toml` を監視し、`[model]` テーブルが実際に変更されると (内容で比較すると約 1 秒のデバウンス) 再ロードするため、更新されたブロックは再起動せずに開いているセッションに到達します。 Grok が解析した内容を確認するには、`grok inspect` を実行します。ロードされた設定ソースがリストされ、拒否されたフィールドについて警告が表示されます。解決されたモデルのリストは出力されません。単一の TOML エラーがユーザー設定レイヤー「全体」を無効にすることに注意してください。これが、opencodex がファイルをアトミックに書き込む理由です。Grok は書きかけの設定を決して認識しません。
+予測可能な結果。 Grok Build は `~/.grok/config.toml` を監視し、`[model]` テーブルが実際に変更されると (内容で比較すると約 1 秒のデバウンス) 再ロードするため、更新されたブロックは再起動せずに開いているセッションに到達します。 Grok が解析した内容を確認するには、`grok inspect` を実行します。ロードされた設定ソースがリストされ、拒否されたフィールドについて警告が表示されます。解決されたモデルのリストは出力されません。現在の Grok Build は無効なモデルフィールドを警告してスキップし、残りのモデル項目を保持します。TOML 構文エラーがあるとファイルは読み込まれません。opencodex はファイルをアトミックに書き込むため、Grok は再読み込みのたびに完全な文書を認識します。
 - **カタログの更新:** フェンスで囲まれたブロックには、射出時のカタログが反映されます。後
 プロバイダーまたはモデルを追加するには、`ocx ensure` を実行して (またはプロキシを再起動して) 更新します。