- English · 한국어 · 简体中文 · 繁體中文 · Русский · 日本語 · Türkçe · 📖 Full documentation → + English · Français · 한국어 · 简体中文 · 繁體中文 · Русский · 日本語 · Türkçe · 📖 Full documentation →
opencodex is a lightweight local proxy that translates Codex's Responses API into whatever your diff --git a/docs-site/astro.config.mjs b/docs-site/astro.config.mjs index ab56fea23b..d71631d1cf 100644 --- a/docs-site/astro.config.mjs +++ b/docs-site/astro.config.mjs @@ -58,10 +58,11 @@ export default defineConfig({ baseUrl: "https://github.com/lidge-jun/opencodex/edit/main/docs-site/", }, lastUpdated: true, - // English at the site root; Korean under /ko, Simplified Chinese under /zh-cn, Traditional Chinese under /zh-tw, Russian under /ru, Japanese under /ja, Turkish under /tr. + // English at the site root; French under /fr, Korean under /ko, Simplified Chinese under /zh-cn, Traditional Chinese under /zh-tw, Russian under /ru, Japanese under /ja, Turkish under /tr. defaultLocale: "root", locales: { root: { label: "English", lang: "en" }, + fr: { label: "Français", lang: "fr" }, ko: { label: "한국어", lang: "ko" }, "zh-cn": { label: "简体中文", lang: "zh-CN" }, "zh-tw": { label: "繁體中文", lang: "zh-TW" }, @@ -72,91 +73,91 @@ export default defineConfig({ sidebar: [ { label: "Getting Started", - translations: { ko: "시작하기", "zh-CN": "开始使用", "zh-TW": "開始使用", ru: "Начало работы", ja: "はじめに", tr: "Başlangıç" }, + translations: { fr: "Démarrage", ko: "시작하기", "zh-CN": "开始使用", "zh-TW": "開始使用", ru: "Начало работы", ja: "はじめに", tr: "Başlangıç" }, items: [ - { label: "Installation", translations: { ko: "설치", "zh-CN": "安装", "zh-TW": "安裝", ru: "Установка", ja: "インストール", tr: "Kurulum" }, slug: "getting-started/installation" }, - { label: "Quickstart", translations: { ko: "빠른 시작", "zh-CN": "快速开始", "zh-TW": "快速入門", ru: "Быстрый старт", ja: "クイックスタート", tr: "Hızlı Başlangıç" }, slug: "getting-started/quickstart" }, - { label: "How It Works", translations: { ko: "동작 원리", "zh-CN": "工作原理", "zh-TW": "運作原理", ru: "Как это работает", ja: "仕組み", tr: "Nasıl Çalışır" }, slug: "getting-started/how-it-works" }, - { label: "Agent Quickstart", translations: { ko: "에이전트 퀵스타트", "zh-CN": "Agent 快速上手", "zh-TW": "Agent 快速上手", ru: "Быстрый старт для агентов", ja: "エージェント向けクイックスタート", tr: "Ajanlar İçin Hızlı Başlangıç" }, slug: "getting-started/for-agents" }, + { label: "Installation", translations: { fr: "Installation", ko: "설치", "zh-CN": "安装", "zh-TW": "安裝", ru: "Установка", ja: "インストール", tr: "Kurulum" }, slug: "getting-started/installation" }, + { label: "Quickstart", translations: { fr: "Démarrage rapide", ko: "빠른 시작", "zh-CN": "快速开始", "zh-TW": "快速入門", ru: "Быстрый старт", ja: "クイックスタート", tr: "Hızlı Başlangıç" }, slug: "getting-started/quickstart" }, + { label: "How It Works", translations: { fr: "Fonctionnement", ko: "동작 원리", "zh-CN": "工作原理", "zh-TW": "運作原理", ru: "Как это работает", ja: "仕組み", tr: "Nasıl Çalışır" }, slug: "getting-started/how-it-works" }, + { label: "Agent Quickstart", translations: { fr: "Démarrage rapide pour les agents", ko: "에이전트 퀵스타트", "zh-CN": "Agent 快速上手", "zh-TW": "Agent 快速上手", ru: "Быстрый старт для агентов", ja: "エージェント向けクイックスタート", tr: "Ajanlar İçin Hızlı Başlangıç" }, slug: "getting-started/for-agents" }, ], }, { label: "Guides", - translations: { ko: "가이드", "zh-CN": "指南", "zh-TW": "指南", ru: "Руководства", ja: "ガイド", tr: "Kılavuzlar" }, + translations: { fr: "Guides", ko: "가이드", "zh-CN": "指南", "zh-TW": "指南", ru: "Руководства", ja: "ガイド", tr: "Kılavuzlar" }, items: [ - { label: "Providers", translations: { ko: "프로바이더", "zh-CN": "提供商", "zh-TW": "供應商", ru: "Провайдеры", ja: "プロバイダー", tr: "Sağlayıcılar" }, slug: "guides/providers" }, - { label: "Factory Droid Bridge", translations: { ko: "Factory Droid 브리지" }, slug: "guides/factory-droid" }, - { label: "Model Routing", translations: { ko: "모델 라우팅", "zh-CN": "模型路由", "zh-TW": "模型路由", ru: "Маршрутизация моделей", ja: "モデルルーティング", tr: "Model Yönlendirme" }, slug: "guides/model-routing" }, - { label: "Codex Integration", translations: { ko: "Codex 통합", "zh-CN": "Codex 集成", "zh-TW": "Codex 整合", ru: "Интеграция с Codex", ja: "Codex 連携", tr: "Codex Entegrasyonu" }, slug: "guides/codex-integration" }, - { label: "Codex App Model Picker", translations: { ko: "Codex App 모델 선택기", "zh-CN": "Codex App 模型选择器", "zh-TW": "Codex App 模型選擇器", ru: "Выбор модели в Codex App", ja: "Codex App モデルピッカー", tr: "Codex App Model Seçici" }, slug: "guides/codex-app-models" }, - { label: "Model Ordering", translations: { ko: "모델 정렬에 관하여", "zh-CN": "模型排序", "zh-TW": "模型排序", ru: "Сортировка моделей", ja: "モデルの並び順", tr: "Model Sıralaması" }, slug: "guides/model-ordering" }, - { label: "Combos", translations: { ko: "콤보", "zh-CN": "组合", "zh-TW": "組合", ru: "Комбо", ja: "コンボ", tr: "Kombolar" }, slug: "guides/combos" }, - { label: "Claude Code", translations: { ko: "Claude Code", "zh-CN": "Claude Code", "zh-TW": "Claude Code", ru: "Claude Code", ja: "Claude Code", tr: "Claude Code" }, slug: "guides/claude-code" }, - { label: "Grok Build", translations: { ko: "Grok Build", "zh-CN": "Grok Build", "zh-TW": "Grok Build", ru: "Grok Build", ja: "Grok Build", tr: "Grok Build" }, slug: "guides/grok-build" }, - { label: "opencode", translations: { ko: "opencode", "zh-CN": "opencode", "zh-TW": "opencode", ru: "opencode", ja: "opencode", tr: "opencode" }, slug: "guides/opencode" }, - { label: "Pi", translations: { ko: "Pi", "zh-CN": "Pi", "zh-TW": "Pi", ru: "Pi", ja: "Pi", tr: "Pi" }, slug: "guides/pi" }, - { label: "Integrations", translations: { ko: "연동", "zh-CN": "集成", "zh-TW": "整合", ru: "Интеграции", ja: "連携", tr: "Entegrasyonlar" }, slug: "guides/integrations" }, - { label: "MiniMax clients", translations: { ko: "MiniMax 클라이언트", "zh-CN": "MiniMax 客户端", "zh-TW": "MiniMax 客戶端", ru: "Клиенты MiniMax", ja: "MiniMax クライアント", tr: "MiniMax İstemcileri" }, slug: "guides/minimax" }, - { label: "Sidecars: Web Search & Vision", translations: { ko: "사이드카: 웹 검색 & 비전", "zh-CN": "边车：网络搜索与视觉", "zh-TW": "邊車：網路搜尋與視覺", ru: "Сайдкары: веб-поиск и зрение", ja: "サイドカー: ウェブ検索 & ビジョン", tr: "Sidecar'lar: Web Arama ve Görme" }, slug: "guides/sidecars" }, - { label: "Image Bridge", translations: { ko: "이미지 브릿지", "zh-CN": "图像桥接", "zh-TW": "圖像橋接", ru: "Image Bridge", ja: "画像ブリッジ", tr: "Image Bridge" }, slug: "guides/image-bridge" }, - { label: "Video Bridge", translations: { ko: "비디오 브릿지", "zh-CN": "视频桥接", "zh-TW": "影片橋接", ru: "Video Bridge", ja: "動画ブリッジ", tr: "Video Bridge" }, slug: "guides/video-bridge" }, - { label: "Web Dashboard", translations: { ko: "웹 대시보드", "zh-CN": "网页控制台", "zh-TW": "網頁儀表板", ru: "Веб-дашборд", ja: "ウェブダッシュボード", tr: "Web Kontrol Paneli" }, slug: "guides/web-dashboard" }, - { label: "Sub-agent Surface", translations: { ko: "서브에이전트 서피스", "zh-CN": "子代理界面", "zh-TW": "子代理介面", ru: "Интерфейс подагентов", ja: "サブエージェントサーフェス", tr: "Alt Ajan Arayüzü" }, slug: "guides/sub-agent-surface" }, + { label: "Providers", translations: { fr: "Fournisseurs", ko: "프로바이더", "zh-CN": "提供商", "zh-TW": "供應商", ru: "Провайдеры", ja: "プロバイダー", tr: "Sağlayıcılar" }, slug: "guides/providers" }, + { label: "Factory Droid Bridge", translations: { fr: "Pont Factory Droid", ko: "Factory Droid 브리지" }, slug: "guides/factory-droid" }, + { label: "Model Routing", translations: { fr: "Routage des modèles", ko: "모델 라우팅", "zh-CN": "模型路由", "zh-TW": "模型路由", ru: "Маршрутизация моделей", ja: "モデルルーティング", tr: "Model Yönlendirme" }, slug: "guides/model-routing" }, + { label: "Codex Integration", translations: { fr: "Intégration de Codex", ko: "Codex 통합", "zh-CN": "Codex 集成", "zh-TW": "Codex 整合", ru: "Интеграция с Codex", ja: "Codex 連携", tr: "Codex Entegrasyonu" }, slug: "guides/codex-integration" }, + { label: "Codex App Model Picker", translations: { fr: "Sélecteur de modèles de Codex App", ko: "Codex App 모델 선택기", "zh-CN": "Codex App 模型选择器", "zh-TW": "Codex App 模型選擇器", ru: "Выбор модели в Codex App", ja: "Codex App モデルピッカー", tr: "Codex App Model Seçici" }, slug: "guides/codex-app-models" }, + { label: "Model Ordering", translations: { fr: "Ordre des modèles", ko: "모델 정렬에 관하여", "zh-CN": "模型排序", "zh-TW": "模型排序", ru: "Сортировка моделей", ja: "モデルの並び順", tr: "Model Sıralaması" }, slug: "guides/model-ordering" }, + { label: "Combos", translations: { fr: "Combinaisons", ko: "콤보", "zh-CN": "组合", "zh-TW": "組合", ru: "Комбо", ja: "コンボ", tr: "Kombolar" }, slug: "guides/combos" }, + { label: "Claude Code", translations: { fr: "Claude Code", ko: "Claude Code", "zh-CN": "Claude Code", "zh-TW": "Claude Code", ru: "Claude Code", ja: "Claude Code", tr: "Claude Code" }, slug: "guides/claude-code" }, + { label: "Grok Build", translations: { fr: "Grok Build", ko: "Grok Build", "zh-CN": "Grok Build", "zh-TW": "Grok Build", ru: "Grok Build", ja: "Grok Build", tr: "Grok Build" }, slug: "guides/grok-build" }, + { label: "opencode", translations: { fr: "opencode", ko: "opencode", "zh-CN": "opencode", "zh-TW": "opencode", ru: "opencode", ja: "opencode", tr: "opencode" }, slug: "guides/opencode" }, + { label: "Pi", translations: { fr: "Pi", ko: "Pi", "zh-CN": "Pi", "zh-TW": "Pi", ru: "Pi", ja: "Pi", tr: "Pi" }, slug: "guides/pi" }, + { label: "Integrations", translations: { fr: "Intégrations", ko: "연동", "zh-CN": "集成", "zh-TW": "整合", ru: "Интеграции", ja: "連携", tr: "Entegrasyonlar" }, slug: "guides/integrations" }, + { label: "MiniMax clients", translations: { fr: "Clients MiniMax", ko: "MiniMax 클라이언트", "zh-CN": "MiniMax 客户端", "zh-TW": "MiniMax 客戶端", ru: "Клиенты MiniMax", ja: "MiniMax クライアント", tr: "MiniMax İstemcileri" }, slug: "guides/minimax" }, + { label: "Sidecars: Web Search & Vision", translations: { fr: "Services auxiliaires : recherche web et vision", ko: "사이드카: 웹 검색 & 비전", "zh-CN": "边车：网络搜索与视觉", "zh-TW": "邊車：網路搜尋與視覺", ru: "Сайдкары: веб-поиск и зрение", ja: "サイドカー: ウェブ検索 & ビジョン", tr: "Sidecar'lar: Web Arama ve Görme" }, slug: "guides/sidecars" }, + { label: "Image Bridge", translations: { fr: "Pont d’images", ko: "이미지 브릿지", "zh-CN": "图像桥接", "zh-TW": "圖像橋接", ru: "Image Bridge", ja: "画像ブリッジ", tr: "Image Bridge" }, slug: "guides/image-bridge" }, + { label: "Video Bridge", translations: { fr: "Pont vidéo", ko: "비디오 브릿지", "zh-CN": "视频桥接", "zh-TW": "影片橋接", ru: "Video Bridge", ja: "動画ブリッジ", tr: "Video Bridge" }, slug: "guides/video-bridge" }, + { label: "Web Dashboard", translations: { fr: "Tableau de bord web", ko: "웹 대시보드", "zh-CN": "网页控制台", "zh-TW": "網頁儀表板", ru: "Веб-дашборд", ja: "ウェブダッシュボード", tr: "Web Kontrol Paneli" }, slug: "guides/web-dashboard" }, + { label: "Sub-agent Surface", translations: { fr: "Interface des sous-agents", ko: "서브에이전트 서피스", "zh-CN": "子代理界面", "zh-TW": "子代理介面", ru: "Интерфейс подагентов", ja: "サブエージェントサーフェス", tr: "Alt Ajan Arayüzü" }, slug: "guides/sub-agent-surface" }, ], }, { label: "Benchmarks", - translations: { ko: "벤치마크", "zh-CN": "基准测试", "zh-TW": "基準測試", ru: "Бенчмарки", ja: "ベンチマーク", tr: "Kıyaslamalar" }, + translations: { fr: "Bancs d’essai", ko: "벤치마크", "zh-CN": "基准测试", "zh-TW": "基準測試", ru: "Бенчмарки", ja: "ベンチマーク", tr: "Kıyaslamalar" }, collapsed: true, items: [ - { label: "Overview", translations: { ko: "개요", "zh-CN": "概览", "zh-TW": "概覽", ru: "Обзор", ja: "概要", tr: "Genel Bakış" }, slug: "benchmarks" }, - { label: "Coding", translations: { ko: "코딩", "zh-CN": "编程", "zh-TW": "程式設計", ru: "Кодинг", ja: "コーディング", tr: "Kodlama" }, slug: "benchmarks/coding" }, - { label: "Frontend", translations: { ko: "프론트엔드", "zh-CN": "前端", "zh-TW": "前端", ru: "Фронтенд", ja: "フロントエンド", tr: "Ön Yüz" }, slug: "benchmarks/frontend" }, - { label: "Terminal", translations: { ko: "터미널", "zh-CN": "终端", "zh-TW": "終端", ru: "Терминал", ja: "ターミナル", tr: "Terminal" }, slug: "benchmarks/terminal" }, - { label: "Security", translations: { ko: "보안", "zh-CN": "安全", "zh-TW": "安全", ru: "Безопасность", ja: "セキュリティ", tr: "Güvenlik" }, slug: "benchmarks/security" }, - { label: "Intelligence", translations: { ko: "인텔리전스", "zh-CN": "智能", "zh-TW": "智慧", ru: "Интеллект", ja: "インテリジェンス", tr: "Zeka" }, slug: "benchmarks/intelligence" }, + { label: "Overview", translations: { fr: "Vue d’ensemble", ko: "개요", "zh-CN": "概览", "zh-TW": "概覽", ru: "Обзор", ja: "概要", tr: "Genel Bakış" }, slug: "benchmarks" }, + { label: "Coding", translations: { fr: "Programmation", ko: "코딩", "zh-CN": "编程", "zh-TW": "程式設計", ru: "Кодинг", ja: "コーディング", tr: "Kodlama" }, slug: "benchmarks/coding" }, + { label: "Frontend", translations: { fr: "Frontend", ko: "프론트엔드", "zh-CN": "前端", "zh-TW": "前端", ru: "Фронтенд", ja: "フロントエンド", tr: "Ön Yüz" }, slug: "benchmarks/frontend" }, + { label: "Terminal", translations: { fr: "Terminal", ko: "터미널", "zh-CN": "终端", "zh-TW": "終端", ru: "Терминал", ja: "ターミナル", tr: "Terminal" }, slug: "benchmarks/terminal" }, + { label: "Security", translations: { fr: "Sécurité", ko: "보안", "zh-CN": "安全", "zh-TW": "安全", ru: "Безопасность", ja: "セキュリティ", tr: "Güvenlik" }, slug: "benchmarks/security" }, + { label: "Intelligence", translations: { fr: "Intelligence", ko: "인텔리전스", "zh-CN": "智能", "zh-TW": "智慧", ru: "Интеллект", ja: "インテリジェンス", tr: "Zeka" }, slug: "benchmarks/intelligence" }, ], }, { label: "Reference", - translations: { ko: "레퍼런스", "zh-CN": "参考", "zh-TW": "參考", ru: "Справочник", ja: "リファレンス", tr: "Referans" }, + translations: { fr: "Référence", ko: "레퍼런스", "zh-CN": "参考", "zh-TW": "參考", ru: "Справочник", ja: "リファレンス", tr: "Referans" }, items: [ { label: "CLI", - translations: { ko: "CLI", "zh-CN": "命令行", "zh-TW": "命令列", ru: "CLI", ja: "CLI", tr: "CLI" }, + translations: { fr: "CLI", ko: "CLI", "zh-CN": "命令行", "zh-TW": "命令列", ru: "CLI", ja: "CLI", tr: "CLI" }, items: [ - { label: "Overview", translations: { ko: "개요", "zh-CN": "概览", "zh-TW": "概覽", ru: "Обзор", ja: "概要", tr: "Genel Bakış" }, slug: "reference/cli" }, - { label: "Lifecycle & Service", translations: { ko: "라이프사이클 & 서비스", "zh-CN": "生命周期与服务", "zh-TW": "生命週期與服務", ru: "Жизненный цикл и служба", ja: "ライフサイクル & サービス", tr: "Yaşam Döngüsü ve Servis" }, slug: "reference/cli/lifecycle" }, - { label: "Providers, Accounts & Models", translations: { ko: "프로바이더, 계정 & 모델", "zh-CN": "提供商、账户与模型", "zh-TW": "供應商、帳號與模型", ru: "Провайдеры, аккаунты и модели", ja: "プロバイダー・アカウント・モデル", tr: "Sağlayıcılar, Hesaplar ve Modeller" }, slug: "reference/cli/providers-accounts" }, - { label: "Agents, Routing & Integrations", translations: { ko: "에이전트, 라우팅 & 통합", "zh-CN": "代理、路由与集成", "zh-TW": "代理、路由與整合", ru: "Агенты, маршрутизация и интеграции", ja: "エージェント・ルーティング・連携", tr: "Ajanlar, Yönlendirme ve Entegrasyonlar" }, slug: "reference/cli/agents" }, + { label: "Overview", translations: { fr: "Vue d’ensemble", ko: "개요", "zh-CN": "概览", "zh-TW": "概覽", ru: "Обзор", ja: "概要", tr: "Genel Bakış" }, slug: "reference/cli" }, + { label: "Lifecycle & Service", translations: { fr: "Cycle de vie et service", ko: "라이프사이클 & 서비스", "zh-CN": "生命周期与服务", "zh-TW": "生命週期與服務", ru: "Жизненный цикл и служба", ja: "ライフサイクル & サービス", tr: "Yaşam Döngüsü ve Servis" }, slug: "reference/cli/lifecycle" }, + { label: "Providers, Accounts & Models", translations: { fr: "Fournisseurs, comptes et modèles", ko: "프로바이더, 계정 & 모델", "zh-CN": "提供商、账户与模型", "zh-TW": "供應商、帳號與模型", ru: "Провайдеры, аккаунты и модели", ja: "プロバイダー・アカウント・モデル", tr: "Sağlayıcılar, Hesaplar ve Modeller" }, slug: "reference/cli/providers-accounts" }, + { label: "Agents, Routing & Integrations", translations: { fr: "Agents, routage et intégrations", ko: "에이전트, 라우팅 & 통합", "zh-CN": "代理、路由与集成", "zh-TW": "代理、路由與整合", ru: "Агенты, маршрутизация и интеграции", ja: "エージェント・ルーティング・連携", tr: "Ajanlar, Yönlendirme ve Entegrasyonlar" }, slug: "reference/cli/agents" }, ], }, { label: "Configuration", - translations: { ko: "설정", "zh-CN": "配置", "zh-TW": "設定", ru: "Конфигурация", ja: "設定", tr: "Yapılandırma" }, + translations: { fr: "Configuration", ko: "설정", "zh-CN": "配置", "zh-TW": "設定", ru: "Конфигурация", ja: "設定", tr: "Yapılandırma" }, items: [ - { label: "Overview", translations: { ko: "개요", "zh-CN": "概览", "zh-TW": "概覽", ru: "Обзор", ja: "概要", tr: "Genel Bakış" }, slug: "reference/configuration" }, - { label: "Providers", translations: { ko: "프로바이더", "zh-CN": "提供商", "zh-TW": "供應商", ru: "Провайдеры", ja: "プロバイダー", tr: "Sağlayıcılar" }, slug: "reference/configuration/providers" }, - { label: "Routing", translations: { ko: "라우팅", "zh-CN": "路由", "zh-TW": "路由", ru: "Маршрутизация", ja: "ルーティング", tr: "Yönlendirme" }, slug: "reference/configuration/routing" }, - { label: "Agents", translations: { ko: "에이전트", "zh-CN": "代理", "zh-TW": "代理", ru: "Агенты", ja: "エージェント", tr: "Ajanlar" }, slug: "reference/configuration/agents" }, - { label: "Server & Runtime", translations: { ko: "서버 & 런타임", "zh-CN": "服务器与运行时", "zh-TW": "伺服器與執行階段", ru: "Сервер и рантайм", ja: "サーバー & ランタイム", tr: "Sunucu ve Çalışma Zamanı" }, slug: "reference/configuration/server" }, + { label: "Overview", translations: { fr: "Vue d’ensemble", ko: "개요", "zh-CN": "概览", "zh-TW": "概覽", ru: "Обзор", ja: "概要", tr: "Genel Bakış" }, slug: "reference/configuration" }, + { label: "Providers", translations: { fr: "Fournisseurs", ko: "프로바이더", "zh-CN": "提供商", "zh-TW": "供應商", ru: "Провайдеры", ja: "プロバイダー", tr: "Sağlayıcılar" }, slug: "reference/configuration/providers" }, + { label: "Routing", translations: { fr: "Routage", ko: "라우팅", "zh-CN": "路由", "zh-TW": "路由", ru: "Маршрутизация", ja: "ルーティング", tr: "Yönlendirme" }, slug: "reference/configuration/routing" }, + { label: "Agents", translations: { fr: "Agents", ko: "에이전트", "zh-CN": "代理", "zh-TW": "代理", ru: "Агенты", ja: "エージェント", tr: "Ajanlar" }, slug: "reference/configuration/agents" }, + { label: "Server & Runtime", translations: { fr: "Serveur et environnement d’exécution", ko: "서버 & 런타임", "zh-CN": "服务器与运行时", "zh-TW": "伺服器與執行階段", ru: "Сервер и рантайм", ja: "サーバー & ランタイム", tr: "Sunucu ve Çalışma Zamanı" }, slug: "reference/configuration/server" }, ], }, - { label: "Adapters", translations: { ko: "어댑터", "zh-CN": "适配器", "zh-TW": "適配器", ru: "Адаптеры", ja: "アダプター", tr: "Adaptörler" }, slug: "reference/adapters" }, - { label: "Architecture", translations: { ko: "아키텍처", "zh-CN": "架构", "zh-TW": "架構", ru: "Архитектура", ja: "アーキテクチャ", tr: "Mimari" }, slug: "reference/architecture" }, - { label: "Proxy API Formats", translations: { ko: "프록시 API 형식", "zh-CN": "代理 API 格式", "zh-TW": "代理 API 格式", ru: "Форматы API прокси", ja: "プロキシAPI形式", tr: "Proxy API Formatları" }, slug: "reference/proxy-formats" }, - { label: "Management API", translations: { ko: "관리 API", "zh-CN": "管理 API", "zh-TW": "管理 API", ru: "API управления", ja: "管理API", tr: "Yönetim API'si" }, slug: "reference/management-api" }, + { label: "Adapters", translations: { fr: "Adaptateurs", ko: "어댑터", "zh-CN": "适配器", "zh-TW": "適配器", ru: "Адаптеры", ja: "アダプター", tr: "Adaptörler" }, slug: "reference/adapters" }, + { label: "Architecture", translations: { fr: "Architecture", ko: "아키텍처", "zh-CN": "架构", "zh-TW": "架構", ru: "Архитектура", ja: "アーキテクチャ", tr: "Mimari" }, slug: "reference/architecture" }, + { label: "Proxy API Formats", translations: { fr: "Formats de l’API proxy", ko: "프록시 API 형식", "zh-CN": "代理 API 格式", "zh-TW": "代理 API 格式", ru: "Форматы API прокси", ja: "プロキシAPI形式", tr: "Proxy API Formatları" }, slug: "reference/proxy-formats" }, + { label: "Management API", translations: { fr: "API de gestion", ko: "관리 API", "zh-CN": "管理 API", "zh-TW": "管理 API", ru: "API управления", ja: "管理API", tr: "Yönetim API'si" }, slug: "reference/management-api" }, ], }, { label: "Troubleshooting", - translations: { ko: "문제 해결", "zh-CN": "故障排除", "zh-TW": "疑難排解", ru: "Устранение неполадок", ja: "トラブルシューティング", tr: "Sorun Giderme" }, + translations: { fr: "Dépannage", ko: "문제 해결", "zh-CN": "故障排除", "zh-TW": "疑難排解", ru: "Устранение неполадок", ja: "トラブルシューティング", tr: "Sorun Giderme" }, collapsed: true, items: [ - { label: "Windows Memory Growth", translations: { ko: "Windows 메모리 증가", "zh-CN": "Windows 内存增长", "zh-TW": "Windows 記憶體增長", ru: "Рост памяти в Windows", ja: "Windows メモリ増加", tr: "Windows Bellek Artışı" }, slug: "troubleshooting/windows-memory" }, + { label: "Windows Memory Growth", translations: { fr: "Augmentation de la mémoire sous Windows", ko: "Windows 메모리 증가", "zh-CN": "Windows 内存增长", "zh-TW": "Windows 記憶體增長", ru: "Рост памяти в Windows", ja: "Windows メモリ増加", tr: "Windows Bellek Artışı" }, slug: "troubleshooting/windows-memory" }, ], }, - { label: "Contributing", translations: { ko: "기여하기", "zh-CN": "贡献", "zh-TW": "貢獻", ru: "Как внести вклад", ja: "コントリビュート", tr: "Katkıda Bulunma" }, slug: "contributing" }, + { label: "Contributing", translations: { fr: "Contribuer", ko: "기여하기", "zh-CN": "贡献", "zh-TW": "貢獻", ru: "Как внести вклад", ja: "コントリビュート", tr: "Katkıda Bulunma" }, slug: "contributing" }, ], }), ], diff --git a/docs-site/src/components/FrontierBoards.astro b/docs-site/src/components/FrontierBoards.astro index 264ef8d9ed..2cd29564cb 100644 --- a/docs-site/src/components/FrontierBoards.astro +++ b/docs-site/src/components/FrontierBoards.astro @@ -10,7 +10,7 @@ import data from "../data/frontier-benchmarks.json"; import { FRONTIER_STRINGS } from "../data/frontier-i18n"; interface Props { - locale?: "en" | "ko" | "zh-cn" | "zh-tw" | "ru" | "ja" | "tr"; + locale?: "en" | "fr" | "ko" | "zh-cn" | "zh-tw" | "ru" | "ja" | "tr"; /** Comma-separated board ids to render; omit for all boards. */ boards?: string; /** Show the page-level subtitle (overview pages only). */ @@ -26,7 +26,7 @@ const fill = (key: string, vars: Record` (hachage base36 de 3 caractères) | `claude-opus-4-8-ncb` |
+
+Le proxy choisit la famille pour chaque requête : `?ids=cli` ou `?ids=desktop` est prioritaire ; à défaut, l'agent utilisateur
+`claude-code/*` reçoit la forme lisible de la CLI et les autres clients reçoivent la forme hachée de Claude Desktop.
+Les deux familles restent toujours décodables : un modèle enregistré sous l'une ou l'autre forme dans `settings.json` continue de fonctionner.
+Chaque entrée porte un nom d'affichage explicite, comme `gemini-3-pro (gemini)`, ainsi que toutes les capacités du modèle
+(échelle d'effort de raisonnement et types de réflexion) dans la structure officielle ModelInfo. Le mode passerelle tierce de Claude
+Desktop peut ainsi proposer son sélecteur d'effort. Les véritables modèles Anthropic conservent leurs
+identifiants canoniques. La date synthétique 2026 désigne un emplacement interne, et non une date de publication. Les
+anciens alias hachés et les identifiants `claude-ocx---` des configurations antérieures sont
+toujours résolus.
+
+Si le sélecteur situé au bas de Claude Desktop ne modifie pas le modèle d'une conversation 3P déjà en cours,
+utilisez `/model ` dans cette conversation. OpenCodex ne peut pas observer l'état du sélecteur ; il
+achemine l’identifiant du modèle porté par chaque requête. Confirmez le résultat sous **Journaux → requestModel**.
+
+Les modèles dont la fenêtre de contexte de référence atteint 1M obtiennent une ligne supplémentaire `…[1m]` dans le sélecteur.
+Sa sélection indique à Claude Code la fenêtre complète de 1M pour ce modèle, tout en maintenant le compactage automatique ; le proxy retire
+le marqueur avant le routage.
+La sélection est conservée dans le champ `model` de `settings.json` ; pour les requêtes entrantes, l'alias est de nouveau
+résolu vers le modèle routé. Avec les anciennes versions de Claude Code, le sélecteur reste natif : définissez les modèles au moyen de
+`ANTHROPIC_MODEL` ou tapez n'importe quel identifiant routé avec `/model` (Claude Code fait passer les chaînes).
+
+**Règles de grammaire des alias :** le fournisseur ne doit contenir ni `/` ni `--`, et ne doit pas être égal à `native`.
+Les identifiants de modèle simples, sans `/` ni `~`, conservent le préfixe v1 `claude-ocx-…`. Ceux qui contiennent `/` ou
+`~` utilisent le préfixe v2 `claude-ocx2-…` avec des échappements (`/` → `~s`, `~` → `~t`), par exemple :
+`openrouter/anthropic/claude-opus-4-8` → `claude-ocx2-openrouter--anthropic~sclaude-opus-4-8`.
+Les alias v1 décodent littéralement (donc un identifiant de modèle historique qui contenait les séquences de deux caractères
+`~s` / `~t` est conservé) ; les alias v2 développent les échappements. Les routes impossibles à représenter sous une forme lisible
+utilisent l'alias haché. Les identifiants de modèle peuvent contenir `--` (la résolution se sépare uniquement au premier
+`--`) ; les identifiants natifs contenant `--` utilisent eux aussi la forme hachée.
+
+**Ordre de résolution du modèle :** retrait du marqueur `[1m]` → décodage de l'alias lisible → décodage de l'alias haché
+de Claude Desktop → correspondance exacte dans `modelMap` → correspondance sans date (suffixe `-20250514` retiré) → transfert direct.
+
+Chaque entrée porte un nom d'affichage tel que `gemini-3-pro (gemini)`, ainsi que toutes les fonctionnalités du modèle
+(échelle d'effort de raisonnement et types de réflexion) dans la structure officielle `ModelInfo`. Les véritables modèles Anthropic
+conservent leurs identifiants canoniques sur les deux interfaces.
+
+### Marqueur `[1m]` de variante contextuelle
+
+Les modèles dont la fenêtre de contexte de référence atteint 1M — ou, avec le contexte automatique, dépasse 200k tout en atteignant
+au moins le seuil de compactage — obtiennent une ligne supplémentaire `…[1m]` dans le sélecteur. En la sélectionnant, Claude Code
+tient compte d'un contexte complet de 1M. Le proxy supprime le suffixe `[1m]`, sans tenir compte de la casse, avant la
+résolution de l'alias et le routage.
+
+## Contexte automatique (modèles à grand contexte sans plafond 200k)
+
+Claude Code attribue une limite de 200k jetons à tout modèle qu'il ne reconnaît pas. Le **contexte automatique**, activé
+par défaut, corrige ce comportement :
+
+1. Les modèles dont la fenêtre réelle dépasse 200k **et** atteint au moins le seuil de compactage automatique obtiennent le
+ marqueur `[1m]` dans les lignes du sélecteur et les variables d'environnement qui les désignent.
+2. `CLAUDE_CODE_AUTO_COMPACT_WINDOW` (`350000` par défaut, plage `100000`–`1000000`) est injecté afin
+ que la conversation soit automatiquement résumée à ce seuil.
+
+Trois états de configuration :
+
+- **absent / `true`:** activé (par défaut)
+- **`false` :** désactivé — pas de marqueurs, pas d'injection de fenêtre de compactage
+- **ancien réglage `maxContextTokens` défini :** le contexte automatique est implicitement désactivé
+
+La valeur de compactage est réglable sur la page Claude. **Avertissement :** une valeur supérieure à la fenêtre réelle d'un modèle
+rend ce modèle inutilisable : les tours échouent avant que le résumé puisse se déclencher.
+
+Les modèles Anthropic natifs dont le contexte est inférieur à 1M ne sont jamais marqués automatiquement. Les valeurs que vous exportez vous-même
+restent prioritaires ; le proxy s'appuie sur votre valeur pour déterminer les modèles qui peuvent recevoir le marqueur sans risque.
+Les valeurs de configuration invalides définies manuellement reviennent à 350k.
+
+### Environnement effectif des modèles
+
+`effectiveModelEnv` calcule six emplacements injectés par `ocx claude`, l'environnement système ou le fichier d'environnement du shell :
+`ANTHROPIC_MODEL`, les quatre variables `ANTHROPIC_DEFAULT_{OPUS,SONNET,HAIKU,FABLE}_MODEL` et l'ancienne variable
+`ANTHROPIC_SMALL_FAST_MODEL`. Le modèle Haiku effectif vaut `tierModels.haiku ?? smallFastModel` et alimente
+les deux variables Haiku.
+
+Lorsque `tierModels.haiku` et `smallFastModel` sont absents, OpenCodex laisse les deux variables auxiliaires non définies ; Claude Code choisit ensuite son modèle d'assistance natif (actuellement Sonnet), qui peut entraîner des frais de fournisseur natif.
+
+## Agents de la liste (injectAgents)
+
+`ocx claude` (ainsi que le démon d'environnement système) synchronise la liste des sous-agents exposés (onglet Sous-agents,
+jusqu'à 5 modèles) ainsi que `ocx-self` dans `~/.claude/agents/ocx-*.md`.
+
+- **`ocx-self`** épingle le modèle par défaut de votre sélecteur `/model` (avec repli sur `claudeCode.model`) ; il est omis
+ quand ni l’un ni l’autre n’existe. Il utilise l'héritage de modèle.
+- Chaque corps d'agent contient une directive `` — le proxy l'utilise pour
+ épingler la véritable route. L'argument `model` de l'outil Agent est donc inopérant ; utilisez `"haiku"` comme
+ espace réservé.
+- Le frontmatter contient le nom d'affichage ; le routage est déterminé par les directives.
+- Seuls les fichiers `ocx-*.md` vérifiés par marqueur contenant `generated-by: opencodex` sont toujours
+ écrasés ou supprimés ; vos propres agents ne sont jamais modifiés.
+- Les fichiers sont synchronisés atomiquement par fichier (écriture + renommage).
+- `enabled: false` ou `injectAgents: false` élague toutes les définitions dont la propriété est vérifiée.
+- Les requêtes PUT de l'interface et les changements de liste déclenchent immédiatement une nouvelle synchronisation ; le lanceur et l'environnement système se synchronisent au démarrage.
+
+Utilisation : `subagent_type: "ocx-gpt-5-6-sol"`. Les cibles compatibles avec un contexte de 1M portent automatiquement `[1m]`.
+
+## Élision des compétences intégrées (blockedSkills)
+
+La compétence `claude-api` fournie avec Claude Code injecte environ 840 Ko (~136k jetons) de documentation Anthropic
+et se déclenche automatiquement lorsque des modèles Claude sont mentionnés. Les modèles routés n'ont pas été entraînés sur cet ensemble ;
+par défaut, opencodex remplace donc le contenu de la compétence par un bref contenu de remplacement dans les requêtes **routées**.
+Le transfert Anthropic natif reste intact.
+
+**Deux vecteurs sont pris en charge :**
+
+1. **Résultat d'outil :** pour les appels assistant `Skill(...)`, le corps `tool_result` associé est
+ remplacé par un contenu minimal lorsque l'entrée JSON en minuscules contient un nom bloqué.
+2. **Vecteur de bloc de texte :** un bloc de texte utilisateur d'au moins 10 000 caractères commençant par
+ `Base directory for this skill: ` — est reconnu lorsque le nom de base du répertoire correspond à un nom bloqué
+ (insensible à la casse).
+
+Configurez cette fonction avec `claudeCode.blockedSkills` (`["claude-api"]` par défaut ; `[]` désactive entièrement
+l'élision). Le contenu de remplacement préserve l'association entre l'appel d'outil et son résultat.
+
+## Mappage des modèles (interception)
+
+`claudeCode.modelMap` réécrit les identifiants de modèle Anthropic entrants avant le routage :
+
+```json
+{
+ "claudeCode": {
+ "modelMap": {
+ "claude-sonnet-4-5": "gemini/gemini-3-pro",
+ "claude-haiku-4-5": "gemini/gemini-3-flash"
+ }
+ }
+}
+```
+
+Ordre de recherche : alias de découverte → identifiant exact → identifiant sans le suffixe de date (`-20250514`) → transfert direct.
+
+## Matrice des services auxiliaires : recherche web et compréhension des images
+
+Les modèles routés ne disposent pas tous des mêmes outils hébergés ou de la même prise en charge des images. opencodex comble ces lacunes
+avant que le modèle principal ne réponde :
+
+- Le **service auxiliaire de recherche web** exécute la véritable recherche hébergée, puis fournit au modèle routé la réponse et ses
+ sources sous forme de résultat d'outil.
+- Le **service auxiliaire de vision** décrit une image jointe avant d'appeler un modèle répertorié dans
+ `noVisionModels`, puis remplace l'image par cette description.
+
+Les deux services auxiliaires peuvent utiliser l'un ou l'autre moteur :
+
+| Moteur | Fonctionnement | Prérequis |
+| --- | --- | --- |
+| `openai` | Un petit modèle GPT via le fournisseur ChatGPT `forward` | Une connexion ChatGPT et un fournisseur actif avec `authMode: "forward"` |
+| `anthropic` | Claude au moyen d'identifiants OAuth Anthropic stockés ; la recherche web utilise `web_search_20250305` et le service de vision envoie l'image à Claude pour qu'il la décrive | Un fournisseur actif avec `adapter: "anthropic"` et `authMode: "oauth"`, dont le compte actif stocké n'est pas marqué `needsReauth` |
+
+Une valeur `backend` explicite est toujours prioritaire. Si elle est omise, opencodex sélectionne `anthropic` lorsqu'un
+compte OAuth Anthropic enregistré existe ; sinon, il sélectionne `openai`. Une sélection explicite de
+`anthropic` sans identifiants utilisables **échoue de manière sûre** : opencodex n'emprunte pas silencieusement les
+identifiants ChatGPT et ne change pas de moteur. Le moteur OpenAI reste lui aussi désactivé sans connexion ChatGPT
+et sans fournisseur de transfert.
+
+Les nouvelles tentatives routées issues de Claude joignent la connexion ChatGPT principale à la requête interne ; les services auxiliaires
+OpenAI restent donc accessibles même si la requête entrante de Claude Code ne porte que l'identifiant du proxy.
+Cet identifiant n'est jamais transmis au fournisseur principal routé.
+
+```json
+{
+ "webSearchSidecar": {
+ "backend": "anthropic",
+ "model": "claude-sonnet-5",
+ "maxSearchesPerTurn": 3
+ },
+ "visionSidecar": {
+ "backend": "anthropic",
+ "model": "claude-sonnet-5",
+ "maxDescriptionsPerTurn": 8
+ }
+}
+```
+
+`maxDescriptionsPerTurn` limite le nombre de nouvelles descriptions d'images pendant un tour du modèle principal. Les résultats trouvés dans le cache et
+les descriptions identiques déjà en cours ne consomment pas cette limite. Les descriptions réussies des images `data:`
+sont mises en cache selon le moteur, le modèle, le niveau de détail, les octets de l'image et le contexte de la requête ; une même
+paire image-contexte n'est donc pas décrite de nouveau à chaque tentative. Les images distantes `https:` ne sont jamais
+mises en cache, car leur contenu peut changer.
+
+Consultez la [référence de configuration](/fr/reference/configuration/server/#services-auxiliaires) pour chaque clé.
+La recherche web et la description d'images avec OAuth Anthropic réutilisent les identifiants Claude Code existants du magasin
+d'empreintes précédent. Testez néanmoins ces fonctions avec votre compte et votre charge de travail avant de vous y fier
+pour de longues exécutions sans surveillance.
+
+
+
+## Effort de raisonnement
+
+Le paramètre `/effort` de Claude Code est conservé sur l'ensemble de l'adaptateur :
+
+| Format du protocole | Correspondance |
+| --- | --- |
+| `thinking.type: "adaptive"` + `output_config.effort` | Effort transmis directement (`minimal`\|`low`\|`medium`\|`high`\|`xhigh`\|`max`\|`ultra`) |
+| `thinking.type: "enabled"` + `budget_tokens` | ≤4096→`low`, ≤16384→`medium`, ci-dessus→`high` |
+| `thinking.type: "disabled"` | `reasoning: { effort: "none" }` ; résumé omis |
+
+La valeur résolue apparaît dans la colonne **Effort de raisonnement** du journal des demandes.
+
+## Traduction entrante (Messages → Réponses)
+
+Le proxy traduit chaque requête Anthropic Messages API au format Codex Responses API :
+
+| Entrée Messages | Sortie Responses |
+| --- | --- |
+| Niveau supérieur `system` | `instructions` (blocs de texte joints par `\n\n`) |
+| `messages[].role: "system"` | Également plié en `instructions` |
+| Texte/image utilisateur | `input_text` / `input_image` (base64 → données URL) |
+| Texte assistant | `output_text` |
+| Assistant `tool_use` | `function_call` (`input` → JSON-stringifié `arguments`) |
+| Utilisateur `tool_result` | `function_call_output` (`is_error` → préfixe `[tool error]`) |
+| Relecture de `thinking` / `redacted_thinking` | Ignorée |
+| Outils fonctionnels | `{type: "function"}` (`web_search*` → `{type: "web_search"}`) |
+| `tool_choice` | `auto`→`auto`, `none`→`none`, `any`→`required`, fonction nommée→`{type:"function",name}`, hébergée WebSearch/web_search→`{type:"web_search"}` |
+| `max_tokens` | `max_output_tokens` |
+| `stop_sequences` | `stop` |
+
+**Cas d'erreur (400) :** JSON mal formé ; `model` absent ou vide ; `messages` absent ou vide ; rôle non pris en charge ;
+`tool_result` sans `tool_use_id` ; `tool_use` sans identifiant ni nom ; `tool_choice` nommé sans nom.
+
+## Traduction sortante (Réponses → Messages SSE)
+
+| Événement de réponses | Messages SSE |
+| --- | --- |
+| `response.created` | `message_start` + `ping` |
+| Battement de coeur | `ping` |
+| Deltas de texte | `content_block_start` → `content_block_delta` (texte) → `content_block_stop` |
+| Résumé ou texte de raisonnement | Bloc `thinking` avec signature synthétique |
+| Trames d'appel de fonction | Bloc `tool_use` avec `input_json_delta` |
+| Événement terminal | `message_delta` → `message_stop` |
+| EOF avant la borne | style 502 `api_error` |
+
+**Mappage du motif d'arrêt :** `completed` → `tool_use` (si un outil est appelé) ou `end_turn` ;
+`incomplete/max_output_tokens` → `max_tokens` ; `incomplete/content_filter` → `refusal`.
+
+**Taxonomie des erreurs :** 400 `invalid_request_error`, 401 `authentication_error`,
+402 `billing_error`, 403 `permission_error`, 404 `not_found_error`, 409 `conflict_error`,
+413 `request_too_large`, 429 `rate_limit_error`, 504 `timeout_error`, 529 `overloaded_error`,
+autre 5xx `api_error`. `Retry-After` est conservé.
+
+## Mise en cache des prompts et utilisation des jetons
+
+**Requêtes routées vers Anthropic :** l'adaptateur gère les points de rupture du cache pour les outils, le contenu système
+et l'avant-dernier message utilisateur, ainsi que le champ `cache_control` automatique de premier niveau. Les tours stables
+atteignent généralement un taux d'accès au cache d'environ 99.9 %.
+
+**Routage OpenAI/ChatGPT natif :** produit une valeur `prompt_cache_key` propre à la session, à partir de
+`metadata.user_id` lorsqu'il est présent ou, à défaut, d'un hachage du contenu système, ainsi qu'un en-tête `session_id`
+pour l'affinité du cache. La clé de cache inclut le modèle et l'intégralité des schémas d'outils.
+
+**Calcul des jetons d'entrée :** Anthropic soustrait `cached_tokens` et `cache_write_tokens` de
+`input_tokens`, les exposant comme `cache_read_input_tokens` et `cache_creation_input_tokens`.
+Les journaux de requêtes les intègrent à `inputTokens`, les lectures étant enregistrées dans `cachedInputTokens` et
+`cacheReadInputTokens`, et les écritures dans `cacheCreationInputTokens`. La page Utilisation présente séparément les lectures
+et la création de cache séparément.
+
+**`count_tokens` :** les modèles routés utilisent une approximation fondée sur le système sérialisé, les messages et les outils.
+Les modèles Anthropic natifs accompagnés d'un identifiant `sk-ant-` transmettent la requête au véritable point de terminaison
+Anthropic `/v1/messages/count_tokens`.
+
+## Capture de débogage
+
+`ocx debug claude on|off|status|reset`, `OCX_CLAUDE_DEBUG=1` ou `PUT /api/debug {"claude": true}`
+contrôle la capture entrante. `GET /api/claude/inbound-debug` renvoie `{enabled, entries}` (le plus récent
+premier, anneau de 20).
+
+Chaque entrée enregistre : `at`, `endpoint`, `model`, `resolvedModel`, `stream`, `maxTokens`,
+`thinkingType`, `thinkingBudgetTokens`, `outputConfigEffort`, `metadataKeys`,
+les indicateurs `hasMetadataUserId` et `hasSystem`, la valeur brute `anthropicBeta`, ainsi qu'un HMAC de huit caractères pour
+l'identifiant utilisateur ou système. **Aucun texte d'invite, objet brut ni hachage stable entre les entrées n'est enregistré.** La désactivation
+du débogage Claude efface immédiatement l'anneau.
+
+## Interface graphique (page Claude)
+
+La barre latérale du tableau de bord comporte une page **Claude** dédiée (sous API) et une bascule **Claude ON**
+(étiquette volontairement identique dans toutes les langues). La page affiche :
+
+- Interrupteur général des requêtes entrantes
+- Démarrage rapide (`ocx claude`) et bloc d'environnement manuel
+- Sélecteur de mode rapide (Auto / ON / OFF)
+- Basculement automatique du contexte et liste déroulante du seuil de compactage
+- Bascule d'enregistrement automatique des sous-agents
+- Éditeur d'interception des modèles (modelMap)
+- Aperçu en direct des alias du sélecteur
+
+`GET /api/claude-code` renvoie les valeurs par défaut effectives, la configuration, le registre des fenêtres de contexte, l'environnement effectif,
+les identifiants de route, les alias et le port disponibles. `PUT /api/claude-code` applique une mise à jour partielle et conserve les
+champs omis ; `null` réinitialise les valeurs de contexte, de liste de blocage et de seuil de compactage.
+
+## Dépannage
+
+**Claude Code indique « 0 recherche effectuée »** — Les versions actuelles traduisent les éléments Responses terminés
+`web_search_call` en blocs Anthropic `server_tool_use` et `web_search_tool_result` appariés,
+y compris `usage.server_tool_use.web_search_requests`. Mettez à jour opencodex si une ancienne version terminait
+la recherche alors que Claude Code indiquait toujours zéro.
+
+**Un service auxiliaire ne s'active pas** — Pour `backend: "openai"`, vérifiez que vous êtes connecté à ChatGPT et
+qu'un fournisseur avec `authMode: "forward"` est actif. Pour `backend: "anthropic"`, vérifiez que le compte OAuth Anthropic
+actif et stocké n'est pas marqué `needsReauth`. Une sélection explicite d'Anthropic sans ces identifiants
+échoue volontairement de manière sûre.
+
+**"Les connecteurs claude.ai sont désactivés"** — Un `ANTHROPIC_API_KEY` ou `ANTHROPIC_AUTH_TOKEN` est défini
+dans votre shell. `ocx claude` s'abstient délibérément de définir `ANTHROPIC_API_KEY` ; si vous l'avez exportée,
+supprimez-la de l'environnement. `ocx claude` injecte `ANTHROPIC_BASE_URL`, la découverte, le contexte automatique et les modèles configurés, mais jamais `ANTHROPIC_API_KEY`.
+
+**Les modèles ne s'affichent pas dans le sélecteur de modèles** — Vérifiez que `CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1` est bien
+défini (automatique avec `ocx claude`). Exécutez `ocx claude` pour actualiser le cache des modèles de la passerelle dans
+`~/.claude/cache/gateway-models.json`. Vérifiez que `claudeCode.enabled` n'est pas `false`.
+
+**Environnement obsolète après un changement de port** — Si le port du proxy a changé, les anciens shells peuvent conserver
+une valeur `ANTHROPIC_BASE_URL` obsolète. Ouvrez un nouveau terminal ou réexécutez `ocx claude`.
+
+**Plafond de contexte 200k malgré un grand modèle** — Sélectionnez la variante `[1m]` dans le sélecteur ou activez
+le contexte automatique, activé par défaut. Si le sélecteur n'affiche aucune ligne `[1m]`, la fenêtre de contexte de référence du modèle
+peut être inférieure au seuil de compactage automatique.
+
+**Nombre élevé de jetons provenant du chargement des compétences** — La compétence `claude-api` fournie (~136k jetons) se charge automatiquement
+quand un modèle Claude est mentionné. Ce comportement est normal avec le transfert natif ; pour les modèles routés, opencodex la remplace
+par défaut par un contenu minimal (`blockedSkills: ["claude-api"]`).
+
+**Les sous-agents sont envoyés au mauvais modèle** — Les agents de la liste (`ocx-*`) utilisent les directives
+``, et non l'argument `model` de l'outil Agent. Vérifiez que la directive désigne la route voulue.
+Utilisez `"haiku"` comme valeur de remplacement pour le modèle.
diff --git a/docs-site/src/content/docs/fr/guides/codex-app-models.md b/docs-site/src/content/docs/fr/guides/codex-app-models.md
new file mode 100644
index 0000000000..9bec4a20d8
--- /dev/null
+++ b/docs-site/src/content/docs/fr/guides/codex-app-models.md
@@ -0,0 +1,256 @@
+---
+title: Sélecteur de modèles de Codex App
+description: Comment les modèles opencodex apparaissent dans Codex App, Codex CLI et Codex TUI par l'intermédiaire du catalogue Codex partagé.
+---
+
+opencodex ne modifie pas Codex App. Il écrit la même configuration et le même catalogue de modèles Codex
+que ceux utilisés par Codex CLI et TUI. Le serveur d'application lit cet état partagé, mais certaines versions
+de Codex Desktop appliquent dans le moteur de rendu une seconde liste d'autorisation distante et peuvent
+encore retirer les lignes routées du sélecteur.
+
+Les entrées OpenAI utilisent deux routes d'identification : la connexion Codex native et le transport par
+clé API avec espace de noms `openai-apikey/`. Le simple passage de `codexAccountMode` entre Pool et
+Direct ne change pas les identifiants du sélecteur. Toutefois, lorsque les lignes qualifiées par compte sont
+activées avec `codexAccountPickerEnabled` et que `codexAccountNamespaces` contient des sélecteurs admissibles
+dont les comptes associés existent toujours, opencodex ajoute une ligne
+`/` distincte pour chaque compte associé et masque les lignes natives non
+qualifiées du sélecteur Codex. Les libellés des sélecteurs sont des noms publics choisis par l'utilisateur et
+n'ont aucune signification intégrée quant au rôle du compte. Choisir une ligne qualifiée utilise exclusivement
+le compte associé, ne change pas le compte Pool actif et échoue de façon fermée au lieu de changer de compte
+si la cible n'est pas disponible. Si le catalogue Codex propre à un compte contient un identifiant visible de
+la famille OpenAI, pris en charge par l'API mais absent de l'ensemble statique d'opencodex, cet identifiant
+exact est conservé sous forme de ligne qualifiée pour les sélecteurs admissibles du compte principal. Il
+n'est ni copié vers un compte sans rapport, ni ajouté aux listes de modèles non qualifiés ou accessibles par
+clé API. La ligne est reconnue d'après la structure de champs d'une véritable entrée de catalogue, ce qui
+filtre les entrées mal formées ; cela ne prouve pas que l'identifiant provient d'une réponse en amont, car le
+cache appartient à l'utilisateur. Consultez les
+[sélecteurs exacts de compte Codex](/fr/reference/configuration/routing/#sélecteurs-exacts-de-comptes-codex).
+
+`gpt-daybreak-blue-latest` suit cette règle d'observation uniquement pour les lignes qualifiées par compte et
+n'est pas ajouté à la liste d'autorisation native non qualifiée. Une entrée `customModels` distincte et
+explicite peut exposer le même identifiant transmis comme `openai/gpt-daybreak-blue-latest` par
+l'intermédiaire du fournisseur canonique de transfert de la connexion Codex :
+
+```json
+{
+ "customModels": [
+ {
+ "id": "daybreak-codex-forward",
+ "provider": "openai",
+ "modelId": "gpt-daybreak-blue-latest"
+ }
+ ]
+}
+```
+
+Seuls ce fournisseur, ce point de terminaison et cet identifiant de modèle exacts reçoivent l'instantané de
+capacités Sol épinglé : contexte de 372 000 jetons, compactage automatique à 334 800 jetons, échelle de
+raisonnement native et métadonnées d'outils Codex natives. La requête continue d'envoyer
+`gpt-daybreak-blue-latest` ; opencodex ne le réécrit pas en Sol, ne crée aucune ligne non qualifiée et
+n'accorde aucun droit au compte. La ligne API `openai-apikey/daybreak-blue-latest`, facturée séparément,
+emprunte une autre route, et ses limites de 1 050 000 / 922 000 jetons ne sont jamais copiées dans la ligne
+de connexion Codex.
+
+Lorsque la table `codexAccountNamespaces` est vide, les lignes qualifiées par compte sont désactivées. Si
+`codexAccountPickerEnabled` est omis alors que cette table n'est pas vide, elles sont considérées comme
+activées par compatibilité ascendante. Définissez-le sur `false` pour masquer les lignes qualifiées générées
+et rétablir les lignes natives non qualifiées dans le sélecteur, sans supprimer les associations ni désactiver
+le routage exact `/`.
+
+Les entrées API GPT-5.6 et Daybreak emploient un contexte de 1 050 000 jetons et une entrée maximale de
+922 000 jetons. Les identifiants `*-pro` du sélecteur se résolvent vers le modèle transmis de base avec
+`reasoning.mode: "pro"`, tandis que les **Journaux**, l'**Utilisation** et l'état du sélecteur conservent
+l'identifiant virtuel. Le catalogue API contient exactement dix identifiants : `gpt-5.5`, `gpt-5.6`,
+Sol/Terra/Luna, leurs trois identifiants virtuels Pro, `daybreak-red-latest` et `daybreak-blue-latest` ; il
+n'existe aucun alias générique `gpt-5.6-pro`. Les requêtes de compactage conservent le niveau sélectionné,
+mais envoient le modèle de base sans objet de raisonnement.
+
+Choisissez la route d'identification représentée par l'identifiant du sélecteur. Modifiez Pool/Direct sur la
+page **Fournisseurs** ; `` désigne ci-dessous un libellé public choisi par l'utilisateur et associé
+par `codexAccountNamespaces` :
+
+```text
+gpt-5.6-sol # route de connexion Codex nue via Pool ou Direct
+/gpt-5.6-sol # compte Codex enregistré associé à ce sélecteur
+openai-apikey/gpt-5.6-sol # clé API
+openai/gpt-daybreak-blue-latest # ligne personnalisée explicite relayée vers Codex (372 000)
+/gpt-daybreak-blue-latest # identifiant natif qualifié par compte observé, si disponible
+openai-apikey/daybreak-blue-latest # route à clé API distincte (1 050 000 / 922 000)
+```
+
+Les nouvelles installations et les configurations sans mode enregistré utilisent Pool par défaut. Les
+configurations actuelles emploient le marqueur 2 et enregistrent une copie de sauvegarde unique de la
+configuration v1 livrée dans `~/.opencodex/config.json.pre-openai-tiers-v2.bak`. Restaurez cette copie avec :
+
+```sh
+cp ~/.opencodex/config.json.pre-openai-tiers-v2.bak ~/.opencodex/config.json
+```
+
+Les anciennes configurations v1 à trois fournisseurs migrent automatiquement vers l'unique ligne tenant
+compte de l'option choisie.
+
+## Limitation de la liste d'autorisation distante de Desktop
+
+Si `codex debug models` et `model/list` du serveur d'application contiennent un modèle routé que Desktop
+n'affiche pas, consultez le [ticket Codex nº 19694](https://github.com/openai/codex/issues/19694). Lorsque la
+stratégie distante `use_hidden_models` est active, Desktop peut ne conserver que les identifiants présents
+dans sa liste native `available_models` et peut aussi afficher des lignes natives dont la visibilité du
+catalogue vaut `hide`. L'actualisation du catalogue et le redémarrage du proxy ne peuvent pas, à eux seuls,
+modifier cette stratégie du moteur de rendu.
+
+Pour un modèle routé équivalent, opencodex propose un mode explicite de combinaison avec alias natif,
+désactivé par défaut. Il publie un identifiant non qualifié autorisé avec un libellé d'affichage personnalisé
+fidèle, puis achemine cet identifiant exact vers la combinaison configurée avant le routage OpenAI canonique.
+Il omet aussi du catalogue effectif les lignes natives non qualifiées désactivées tant que des alias de
+compatibilité existent, afin que Desktop ne puisse pas les faire réapparaître en ignorant `visibility`.
+Consultez [Compatibilité avec la liste d'autorisation native de Codex Desktop](/fr/guides/combos/#compatibilité-avec-la-liste-dautorisation-native-de-codex-desktop)
+pour la commande, la sémantique de la clé de désactivation et les contraintes de sécurité.
+
+## Parcours d'intégration
+
+`ocx init`, `ocx start` et `ocx sync` relient au proxy la configuration et le catalogue Codex partagés.
+Consultez [Intégration de Codex](/fr/guides/codex-integration/) pour l'injection de configuration, la
+synchronisation du catalogue, les lanceurs intermédiaires, le repli WebSocket et les mécanismes de restauration.
+
+## Pourquoi les modèles routés apparaissent
+
+Le sélecteur de modèles de Codex attend des entrées ayant la structure de son propre catalogue. opencodex
+crée les entrées routées en clonant un modèle d'entrée Codex natif, puis en remplaçant l'identité du modèle :
+
+```text
+slug = "anthropic/claude-sonnet-..."
+display_name = "anthropic/claude-sonnet-..."
+visibility = "list"
+```
+
+Le clone conserve les champs exigés par l'analyseur strict, notamment les niveaux de raisonnement, le type
+de shell, les indicateurs de prise en charge de l'API et les instructions de base. opencodex retire ensuite
+les capacités exclusivement natives que la route ne peut respecter, dont les métadonnées de niveau de
+service OpenAI.
+
+## Couverture stable actuelle des modèles
+
+L'ensemble natif de secours comprend `gpt-5.5`, `gpt-5.4`, `gpt-5.4-mini`, `gpt-5.3-codex-spark` et GPT-5.6
+Sol/Terra/Luna. Pour la famille GPT-5.5/5.4, opencodex conserve les entrées dynamiques plus riches du
+catalogue Codex installé et ne synthétise qu'une entrée manquante. L'instantané amont fourni n'est employé
+que pour GPT-5.6, auquel il apporte l'identité et les métadonnées réelles de chaque modèle plutôt qu'une
+approximation fondée sur un ancien modèle d'entrée.
+
+| Route | Identifiants du sélecteur et métadonnées du catalogue |
+| --- | --- |
+| Connexion Codex (lignes qualifiées par compte désactivées) | Identifiants natifs non qualifiés comme `gpt-5.6-sol`, `gpt-5.6-terra` et `gpt-5.6-luna` ; Pool ou Direct est choisi avec `codexAccountMode`. Les lignes GPT-5.6 utilisent une fenêtre de catalogue de 372 000 jetons. |
+| Connexion Codex (lignes qualifiées par compte activées avec des sélecteurs admissibles) | Une ligne `/` par sélecteur admissible et modèle natif pris en charge ; chaque ligne utilise exclusivement le compte associé, et les lignes natives non qualifiées sont masquées dans le sélecteur. Les métadonnées natives et les fenêtres de contexte sont préservées. |
+| Connexion Codex (ligne Daybreak transférée explicitement) | `openai/gpt-daybreak-blue-latest` uniquement lorsque l'entrée `customModels` exacte est configurée sur le fournisseur canonique `openai`. Elle conserve l'identifiant Daybreak transmis et utilise l'instantané de capacités Sol épinglé (contexte de 372 000 jetons ; compactage automatique à 334 800 jetons). |
+| OpenAI (clé API) | Exactement dix lignes avec espace de noms : `gpt-5.5`, `gpt-5.6`, Sol/Terra/Luna, les trois identifiants virtuels `*-pro` et les deux alias Daybreak (contexte de 1 050 000 jetons ; entrée maximale de 922 000 jetons pour les dix) |
+| OpenRouter | `openrouter/openai/gpt-5.6-sol`, `openrouter/openai/gpt-5.6-terra`, `openrouter/openai/gpt-5.6-luna` (1 050 000) |
+| Cursor | Le repli statique comprend `cursor/gpt-5.6-sol`, `cursor/gpt-5.6-terra` et `cursor/gpt-5.6-luna` (1 000 000), ainsi que des lignes ordinaires/rapides pour Grok 4.5 et 4.6 (500 000) ; 4.6 ajoute `xhigh`, et la découverte dynamique propre au compte détermine quelles lignes restent visibles. |
+| xAI | La découverte dynamique fait autorité. Le catalogue de secours comprend `xai/grok-4.6` et utilise `xai/grok-4.5` par défaut ; les deux ont une fenêtre de 500 000 jetons. Grok 4.6 propose `low` / `medium` / `high` / `xhigh` (valeur amont par défaut : `high`), tandis que Grok 4.5 s'arrête à `high`. |
+
+Les entrées GPT-5.6 épinglées préservent exactement l'échelle amont. Sol et Terra proposent les niveaux de
+`low` à `ultra` ; Luna s'arrête à `max`. Sol utilise `low` par défaut, contre `medium` pour Terra et Luna.
+La ligne Daybreak Blue explicitement transférée par Codex hérite de l'échelle et de la valeur par défaut de
+Sol sans changer son identité transmise. `ultra` est un choix côté client qui combine un raisonnement maximal
+et une délégation proactive ; il atteint le serveur sous la forme `max`. La présence d'une entrée dans le
+sélecteur signifie seulement que le catalogue est prêt : le compte ou la clé API connectés doivent encore
+autoriser l'utilisation du modèle.
+
+## Activation des modèles natifs et routés
+
+La page **Modèles** du tableau de bord expose des commutateurs `disabledModels` pour les identifiants natifs
+non qualifiés et les identifiants routés `provider/model`. `disabledModels` accepte également les identifiants
+qualifiés par compte `/`, mais le tableau de bord ne répertorie pas ces lignes
+exactes et ne permet pas de les basculer ; ajoutez-les manuellement à la configuration :
+
+- Les identifiants routés possèdent un espace de noms (`provider/model`). En désactiver un l'exclut du catalogue synchronisé et de `/v1/models`.
+- Les identifiants natifs qualifiés par compte emploient `/`. En ajouter un à `disabledModels` ne masque que la ligne de ce sélecteur.
+- Les identifiants GPT natifs sont des identifiants non qualifiés. En désactiver un conserve son entrée exacte dans le catalogue pour une réactivation ultérieure, mais change sa valeur `visibility` en `hide` ; la ligne non qualifiée et tous ses clones qualifiés par sélecteur disparaissent alors de la découverte.
+- Lorsqu'au moins une combinaison avec alias natif est configurée, les lignes natives non qualifiées désactivées sont omises au lieu d'être conservées sous forme masquée, car les versions concernées de Desktop ignorent l'indicateur de masquage. Un identifiant natif non qualifié remplacé par un alias natif est également omis de la page **Modèles** et n'y possède donc aucun commutateur natif ; seules les lignes natives non remplacées peuvent y être activées ou désactivées. Une synchronisation restaure les métadonnées natives intactes lorsqu'une ligne désactivée et non remplacée est réactivée.
+- Les lignes natives non remplacées proviennent de l'ensemble statique pris en charge ; un modèle non remplacé et désactivé reste donc visible dans le tableau de bord et peut être réactivé.
+
+La passe de visibilité s'exécute après les mises à niveau des instantanés. Après l'utilisation d'un
+commutateur, l'API de gestion actualise le catalogue et force l'obsolescence du cache de modèles Codex.
+
+## Mode de surface multi-agent
+
+Le contrôle v1/base/v2 de la page **Modèles** change la surface de collaboration Codex utilisée par chaque
+entrée du sélecteur. Consultez [Surface des sous-agents](/fr/guides/sub-agent-surface/) pour le mode canonique,
+la délégation, l'héritage, le repli et le comportement des tâches chiffrées.
+
+## Niveaux de raisonnement supérieurs
+
+La visibilité des niveaux de raisonnement est indépendante du mode de surface v1/base/v2. Les entrées
+générées capables de raisonner annoncent `max` afin que les remplacements directs de l'effort d'un sous-agent
+soient validés ; les entrées routées générées actuelles et les anciennes entrées GPT natives annoncent aussi
+`ultra`. Les échelles amont exactes de GPT-5.6 sont préservées : Luna possède donc `max`, mais pas `ultra`.
+
+Sur le réseau, les adaptateurs routés convertissent ou plafonnent les niveaux non pris en charge. Pour les
+anciens modèles natifs dont l'échelle réelle s'arrête à `xhigh`, `nativeEffortClamp` convertit une sélection
+directe `max` ou `ultra` en `xhigh` (GPT-5.5, par exemple). Sol, Terra et Luna possèdent un véritable niveau `max`.
+
+## Règles du niveau rapide
+
+Codex enregistre le mode rapide ainsi :
+
+```toml
+service_tier = "fast"
+
+[features]
+fast_mode = true
+```
+
+Toutefois, le catalogue de modèles et l'identifiant du niveau employé dans la requête d'exécution utilisent
+`priority`. opencodex préserve cette distinction. Les modèles OpenAI natifs transférés conservent la prise en
+charge du mode rapide ; les fournisseurs routés sont conditionnés par leurs capacités. `service_tier` n'est
+retiré que si le fournisseur déclare `supportsServiceTier: false` (le registre classe OpenAI canonique comme
+`true`, et DeepSeek ainsi que Volcengine Ark comme `false`). Les passerelles personnalisées non classées
+conservent intactes les valeurs transmises par l'appelant et ne reçoivent jamais d'injection. Une passerelle
+personnalisée peut l’activer globalement avec `supportsServiceTier: true`, ou uniquement pour certains
+modèles avec `modelSupportsServiceTier: { "verified-model": true }`. Une valeur exacte `false` restreint une
+valeur globale `true`, tandis que `supportsServiceTier: false` reste fermé par défaut. La décision finale de
+l’adaptateur et du modèle régit à la fois les métadonnées du catalogue et l’injection à l’exécution ;
+l’option rapide n’est donc jamais annoncée lorsqu’elle ne peut être respectée. Une destination
+`openai-chat` peut autoriser tous les modèles autrement admissibles avec `chatServiceTier: true`, ou
+uniquement des modèles précis avec `modelSupportsServiceTier` ; les routes Responses n’ont pas besoin de
+cette autorisation supplémentaire sur le protocole Chat.
+
+## Sélection des sous-agents
+
+Codex trie les entrées visibles du sélecteur par `priority` croissante et propose les cinq premières comme
+remplacements de modèle pour `spawn_agent`. La page **Sous-agents** du tableau de bord permet de choisir et
+d'enregistrer jusqu'à cinq identifiants natifs non qualifiés ou identifiants routés `provider/model`.
+`subagentModels`, lorsqu'il est configuré manuellement, accepte aussi les identifiants qualifiés par compte
+`/`, mais le tableau de bord ne propose pas ces identifiants exacts ; enregistrer
+la page remplace la liste par les choix visibles dans le tableau de bord. opencodex attribue des priorités de
+catalogue basses dans l'ordre choisi. Lorsque les lignes qualifiées par compte sont activées, les sélections
+natives non qualifiées s'étendent en groupes qualifiés par sélecteur. Les autres modèles restent accessibles
+par leur identifiant exact.
+
+La liste des modèles mis en avant est distincte de la sélection **Délégation de sous-agent** du tableau de
+bord. Elle détermine les remplacements que Codex propose en premier ; elle ne sélectionne aucun modèle et ne
+déclenche aucune délégation à elle seule.
+
+## Serveurs distants de Desktop
+
+Le mode serveur distant de Codex Desktop filtre le sélecteur d'après la propre liste d'autorisation
+`available_models` du client, active lorsque le réglage distant `use_hidden_models` est activé. Les entrées
+routées du catalogue restent chargées et servies — `model/list` les renvoie et la CLI fournie les lit — mais
+le moteur de rendu de Desktop retire avant affichage tout élément absent de cette liste exclusivement native.
+opencodex n'a aucun accès à cette liste ; le défaut amont est suivi dans
+[openai/codex#19694](https://github.com/openai/codex/issues/19694).
+
+Tant que Desktop ne permet pas de contrôler cette liste d'autorisation :
+
+- Définissez directement le modèle dans `~/.codex/config.toml` sur la machine distante, par exemple avec `model = "input/grok-4.5"`. Le sélecteur peut afficher `Custom`, mais les requêtes utilisent toujours le modèle routé configuré.
+- Utilisez Codex CLI ou TUI plutôt que le sélecteur de Desktop ; ces interfaces n'appliquent pas la liste d'autorisation et répertorient normalement les modèles routés.
+
+## Actualisation de l'état des modèles
+
+Si le sélecteur affiche encore des entrées obsolètes, actualisez le catalogue et redémarrez l'interface Codex concernée :
+
+```bash
+ocx sync
+```
+
+opencodex réécrit `models_cache.json` avec une enveloppe de cache volontairement périmée chaque fois que la
+visibilité, la priorité ou les métadonnées du catalogue changent. La prochaine actualisation des modèles
+Codex relit ainsi le nouveau catalogue.
diff --git a/docs-site/src/content/docs/fr/guides/codex-integration.md b/docs-site/src/content/docs/fr/guides/codex-integration.md
new file mode 100644
index 0000000000..ce9778c9b6
--- /dev/null
+++ b/docs-site/src/content/docs/fr/guides/codex-integration.md
@@ -0,0 +1,380 @@
+---
+title: Intégration à Codex
+description: Comment opencodex s'intègre à Codex, synchronise le catalogue de modèles, installe des intercepteurs et restaure proprement la configuration d'origine.
+---
+
+opencodex fait passer Codex par le proxy en modifiant deux éléments lus par Codex : sa configuration
+(`$CODEX_HOME/config.toml`, par défaut `~/.codex/config.toml`) et son catalogue de modèles. Chaque modification
+est idempotente et réversible.
+
+Le proxy expose une route non qualifiée `openai` pour la connexion Codex, avec les modes de compte Pool (par
+défaut) et Direct, ainsi que `openai-apikey/` pour la clé API configurée. Pool comprend le compte
+principal et les comptes ajoutés ; Direct utilise uniquement le jeton Bearer du compte appelant ou principal.
+Ces routes ne se rabattent jamais l'une sur l'autre. Les configurations v1 distribuées migrent vers le marqueur
+2 et conservent `config.json.pre-openai-tiers-v2.bak` pour une restauration manuelle.
+
+## Injection de configuration
+
+`ocx init`, `ocx start` et `ocx sync` appellent l'injecteur. Sur la liaison de bouclage par défaut, il conserve
+l'identifiant du fournisseur `openai` intégré à Codex et fait pointer ce fournisseur vers opencodex :
+
+```toml
+# root keys, before the first table
+model_catalog_json = "/absolute/path/to/opencodex-catalog.json"
+# Auto-injected by opencodex
+openai_base_url = "http://127.0.0.1:10100/v1"
+
+# only when fastMode is set; unset adds no [features] table
+[features]
+fast_mode = true
+```
+
+Le `fast_mode` injecté suit le réglage à trois états `fastMode` : `true` écrit `fast_mode = true`, `false`
+écrit `fast_mode = false`, et une valeur non définie laisse tout `fast_mode` existant intact sans ajouter de
+table `[features]`.
+
+Le proxy écoute sur le port `10100` par défaut et sert `POST /v1/responses`,
+`POST /v1/responses/compact`, `POST /v1/images/generations`, `POST /v1/images/edits`,
+`GET /v1/models`, `GET /healthz` et la surface de gestion `/api/*`.
+
+### Génération d'images intégrée (`image_gen`)
+
+L'outil `image_gen` intégré à Codex ne passe pas par `/v1/responses` : l'extension codex-rs envoie directement
+une requête POST à `{base_url}/images/generations` (ou à `/images/edits` lorsque des images de référence sont
+jointes), avec la même authentification Bearer ChatGPT que pour le chat. Comme le `base_url` injecté pointe vers
+opencodex, le proxy relaie ces appels au service OpenAI en amont.
+
+Ce mécanisme est distinct de l'[Image Bridge](/fr/guides/image-bridge/), qui ne s'active que lorsqu'un tour
+**Responses** déclare l'outil hébergé `image_generation` alors qu'un modèle autre qu'OpenAI est sélectionné.
+Les appels autonomes `/images/generations` n'entrent jamais dans ce pont.
+
+- **Un seul candidat au transfert, selon le mode :** Pool sélectionne un compte principal ou ajouté éligible ;
+ Direct utilise le jeton Bearer OAuth de l'appelant. Le mode configuré s'applique uniformément à la requête d'image.
+- **Fournisseur OpenAI à clé API :** il n'est utilisé que lorsqu'aucun candidat au transfert n'est responsable
+ d'un échec d'authentification. Un identifiant Pool défaillant ou expiré n'est jamais masqué par une utilisation
+ de l'API facturée séparément.
+- **Fournisseur personnalisé explicite :** définissez `images.provider` sur l'identifiant d'un fournisseur
+ `openai-responses` personnalisé à clé API dont le point de terminaison implémente l'API OpenAI Images. Une
+ sélection explicite échoue sans repli et ne se rabat jamais sur un autre service en amont payant. Les
+ identifiants de fournisseur gérés par le registre ne sont pas acceptés ici ; omettez `images.provider` pour
+ utiliser les niveaux OpenAI intégrés.
+- **Repli Google Antigravity (CCA) :** lorsqu'aucun candidat au transfert OpenAI ni fournisseur à clé n'est
+ configuré, `/v1/images/generations` — mais pas `/images/edits` — se rabat sur le point de terminaison
+ Antigravity **Cloud Code Assist** avec le modèle `gemini-3.1-flash-image`. Ce repli se déclenche aussi après
+ un échec de résolution de l'authentification OpenAI, par exemple en cas d'identifiant ChatGPT absent ou expiré,
+ et pas seulement lorsqu'aucun candidat OpenAI n'est configuré. Il nécessite `ocx login google-antigravity` ;
+ le jeton OAuth n'est envoyé qu'à l'hôte de registre CCA épinglé, jamais à une substitution `baseUrl` de la
+ configuration. La réponse conserve la forme `{created, data:[{b64_json}]}` attendue par Codex.
+- **Aucun des deux :** le proxy renvoie une erreur explicite plutôt qu'une erreur 404 générique. Les fournisseurs
+ routés (Cursor, Gemini, Kiro, …) ne peuvent pas assurer le relais de l'outil `image_generation`. Si vous ne
+ souhaitez pas proposer cet outil, désactivez-le dans Codex avec `codex features disable image_generation`
+ (`[features] image_generation = false` dans `config.toml`).
+
+La déclaration de l'outil accompagne toujours la requête Responses du modèle. Pour les fournisseurs Responses à
+clé API, opencodex convertit l'espace de noms privé `image_gen` de Codex en un alias accepté en amont,
+`image_gen__` (par exemple `image_gen__imagegen`). Lorsque cet alias exploitable remplace la
+déclaration du client, opencodex retire toute déclaration hébergée `image_generation` en double. Il remappe
+l'appel de fonction vers l'espace de noms explicite `image_gen` avant que Codex ne le reçoive, puis réencode
+l'appel natif lorsque l'historique est rejoué ultérieurement en amont. La génération d'images côté client reste
+ainsi appelable sur les services compatibles avec l'API publique qui réservent cet espace de noms ou refusent
+les noms de fonction contenant un point. Le mode de transfert ChatGPT reste inchangé et conserve sa forme native
+Responses Lite.
+
+Pour une passerelle personnalisée compatible OpenAI, configurez un fournisseur dédié et sélectionnez-le uniquement
+pour les requêtes Images autonomes :
+
+```json
+{
+ "providers": {
+ "custom-images": {
+ "adapter": "openai-responses",
+ "baseUrl": "https://gateway.example.com/v1",
+ "authMode": "key",
+ "apiKey": "${IMAGE_GATEWAY_API_KEY}"
+ }
+ },
+ "images": {
+ "provider": "custom-images",
+ "timeoutMs": 300000
+ }
+}
+```
+
+Le point de terminaison personnalisé doit accepter `POST /v1/images/generations` et `/v1/images/edits`, puis
+renvoyer la structure de réponse OpenAI Images attendue par Codex. La clé configurée pour le fournisseur remplace
+le jeton Bearer de l'appelant avant l'envoi de la requête en amont.
+
+> **Remarque :** ce passage concerne uniquement l'outil Codex `image_generation` — le relais
+> `/images/generations`. Les modèles Gemini capables de produire des images les génèrent directement dans la
+> réponse au moyen de l'adaptateur `google` (avec `responseModalities: ["TEXT", "IMAGE"]`), indépendamment de
+> ce relais. Consultez la page
+> [Adaptateurs](/fr/reference/adapters/#google).
+
+Lorsque `hostname` ne désigne pas l'interface de bouclage, Codex doit envoyer l'en-tête d'authentification API
+généré. L'injecteur utilise donc un fournisseur dédié :
+
+```toml
+# root keys
+model_provider = "opencodex"
+model_catalog_json = "/absolute/path/to/opencodex-catalog.json"
+
+# appended at the end of the file
+# Auto-injected by opencodex
+[model_providers.opencodex]
+name = "OpenCodex Proxy"
+base_url = "http://your-host:10100/v1"
+wire_api = "responses"
+requires_openai_auth = true
+env_http_headers = { "x-opencodex-api-key" = "OPENCODEX_API_AUTH_TOKEN" }
+# supports_websockets = true # only when config.websockets is true
+```
+
+Lorsque OpenCodex gère le routage, les deux modes écrivent `$CODEX_HOME/opencodex.config.toml` comme
+configuration de référence et de repli. Sur l'interface de bouclage, ce fichier contient les clés racine que
+vous pouvez fusionner manuellement si l'injection automatique a été supprimée ; hors bouclage, il contient la
+forme avec fournisseur dédié. Le mode de fournisseur externe laisse ce profil intact.
+
+:::caution
+Les clés racine telles que `openai_base_url`, `model_provider` et `model_catalog_json` **doivent** précéder le
+premier en-tête `[table]`. L'injecteur garantit ce placement, supprime ses propres copies obsolètes ou en double
+et n'écrase jamais une clé racine `openai_base_url` appartenant à l'utilisateur. Si cette clé existe, la
+synchronisation met le catalogue à jour, mais signale que le routage n'a pas été injecté.
+:::
+
+## Catalogue de modèles partagé
+
+La CLI, la TUI, l'application et le SDK Codex utilisent tous le même répertoire personnel Codex. opencodex le
+détermine à partir de `CODEX_HOME`, avec `~/.codex` comme valeur de repli, et gère les fichiers suivants :
+
+```text
+$CODEX_HOME/config.toml
+$CODEX_HOME/opencodex.config.toml
+$CODEX_HOME/opencodex-catalog.json
+$CODEX_HOME/models_cache.json
+```
+
+Sous WSL, si `CODEX_HOME` n'est pas défini et que `~/.codex/config.toml` n'existe pas côté Linux, opencodex
+recherche également un unique répertoire personnel de Codex Desktop pour Windows à l'emplacement
+`/mnt/c/Users/*/.codex/config.toml`. S'il trouve exactement un candidat, il utilise ce répertoire afin que le
+mode app-server sous WSL et Codex Desktop sous Windows partagent les mêmes fichiers de configuration et
+d'authentification. Définissez explicitement `CODEX_HOME` pour désactiver cette détection.
+
+Codex peut conserver l'état de ses fils dans un répertoire SQLite distinct. Pour les opérations d'historique,
+OpenCodex applique le même ordre de priorité que Codex : la clé racine `sqlite_home` de `config.toml`, puis
+`CODEX_SQLITE_HOME`, puis le répertoire `CODEX_HOME` effectif. Les chemins SQLite relatifs sont résolus depuis
+le répertoire de travail courant. Lorsqu'une valeur explicite de `CODEX_SQLITE_HOME` est présente pendant
+l'installation ou la réparation du service, le lanceur persistant enregistre son chemin absolu au moment de
+l'installation, afin que le proxy d'arrière-plan continue d'utiliser la même base de données. Si `config.toml`
+ou sa clé racine `sqlite_home` est absent, OpenCodex poursuit avec les valeurs de repli de l'environnement et du
+répertoire personnel. Si le fichier est illisible ou impossible à analyser, ou si la clé existe mais est vide ou
+n'est pas une chaîne, la résolution du répertoire SQLite s'arrête afin de ne pas risquer d'effectuer des
+opérations d'historique sur une autre base de données.
+
+Sous Windows, un shell Orca peut définir à la fois `CODEX_HOME` et `ORCA_CODEX_HOME` sur le répertoire personnel
+de l'environnement d'exécution intégré à Orca, alors que l'application ChatGPT/Codex continue de lire
+`%USERPROFILE%\\.codex`. `ocx status` et `ocx doctor` signalent précisément cette divergence et affichent des
+chemins cibles expurgés. Si le service d'arrière-plan a été installé depuis ce shell Orca, désinstallez-le
+d'abord depuis le shell d'origine. Définissez ensuite `CODEX_HOME` sur le répertoire de l'application, supprimez
+`ORCA_CODEX_HOME`, relancez la synchronisation ou la restauration, puis réinstallez le service.
+
+En mode fournisseur dédié, `requires_openai_auth = true` maintient les surfaces de l'application et de la TUI
+Codex soumises à un compte, comme dans Codex natif. opencodex sert également `/v1/responses` par WebSocket. Le
+fournisseur dédié n'annonce `supports_websockets = true` que lorsque `"websockets": true`. Sur l'interface de
+bouclage, le fournisseur intégré de Codex peut tenter WebSocket en premier ; si cette fonction est désactivée,
+le proxy renvoie `426` et Codex se rabat sur HTTP/SSE.
+
+## Identité et historique du fil de discussion
+
+La configuration de bouclage par défaut conserve l'étiquette du fournisseur natif `openai` de Codex sur les
+nouveaux fils ; la reprise normale de l'historique ne nécessite donc aucun remappage. Lors de la première
+synchronisation, elle remplace également par `openai` les étiquettes créées par d'anciennes versions
+d'opencodex. Hors bouclage, le mode fournisseur dédié continue de refléter l'historique sous le fournisseur
+`opencodex` tant qu'il est actif, puis restaure les métadonnées sauvegardées lorsqu'il prend fin. Définissez
+`syncResumeHistory: false` pour ne pas modifier l'historique.
+
+## Synchronisation du catalogue de modèles
+
+Codex affiche les modèles provenant d'un catalogue sur disque — par défaut
+`$CODEX_HOME/opencodex-catalog.json`. Au démarrage et lors de `ocx sync`, opencodex :
+
+1. **Sauvegarde** une fois le catalogue d'origine dans `~/.opencodex/catalog-backup.json`, afin que la mise en
+ avant des modèles soit réversible.
+2. **Récupère** les catalogues en direct des fournisseurs admissibles — mise en cache pendant ~5 min, puis repli sur
+ la dernière liste valide et enfin sur la valeur configurée de `models[]`. L'authentification par transfert ne
+ possède aucun point de terminaison de modèles, et Cursor utilise son appel RPC `GetUsableModels` plutôt que
+ `/models`.
+3. **Fusionne** les modèles routés sous forme d'entrées qualifiées (`provider/model`), clonées depuis un modèle
+ de catalogue Codex natif afin que l'analyseur strict de Codex les accepte.
+4. **Filtre** `config.disabledModels` et la liste d'autorisation `selectedModels` non vide de chaque fournisseur.
+5. **Reclasse** les modèles afin que ceux mis en avant apparaissent en premier — voir ci-dessous — puis réécrit
+ le catalogue fusionné.
+
+L'identité GPT-5 des entrées routées du catalogue est également remplacée par le véritable nom du modèle en
+amont. Les contrôles de raisonnement proviennent des métadonnées du fournisseur et du modèle selon l'échelle
+`low | medium | high | xhigh |
+max | ultra` de Codex ; les valeurs non prises en charge sont converties ou
+plafonnées avant l'envoi de la requête en amont.
+
+### Outils locaux routés
+
+Les lignes non natives du catalogue routé utilisent `tool_mode: "code_mode_only"`. Codex peut ainsi exposer son
+point d'entrée officiel `exec` et les outils MCP imbriqués, notamment Browser et Computer Use, tandis
+qu'opencodex ne route que l'appel de fonction ordinaire du modèle. L'exécution des outils, les autorisations et
+les confirmations restent locales à Codex ; opencodex n'implémente pas un second navigateur ni un second
+exécuteur de contrôle du bureau.
+
+Pour les fournisseurs Responses à clé qui n'acceptent pas la grammaire de l'outil personnalisé `exec` de Codex,
+opencodex encode cette déclaration et son historique sous forme d'outil de fonction en amont, puis restaure le
+cycle de vie diffusé de l'appel de fonction en `custom_tool_call` avant que Codex ne le reçoive. Le routage natif
+par transfert OpenAI et l'outil personnalisé `apply_patch`, qui est pris en charge, restent inchangés.
+
+Le fournisseur sélectionné doit prendre en charge les appels de fonctions ou d'outils. Un fournisseur purement
+textuel dépourvu de cette prise en charge ne peut pas utiliser `exec`, Browser ni Computer Use. Les lignes
+OpenAI natives conservent leur mode d'outil en amont.
+
+Après toute modification de ces métadonnées par `ocx sync`, redémarrez l'application Codex et ouvrez une nouvelle
+tâche. Les processus app-server et les tâches existants peuvent conserver le catalogue et le plan d'outils
+chargés au démarrage.
+
+### Noms d'affichage des modèles personnalisés
+
+Un modèle personnalisé peut posséder un **nom d'affichage** lisible qui remplace le libellé présenté par Codex
+dans son sélecteur de modèles, sans modifier le routage. Ce nom ne renseigne que le champ `display_name` de
+l'entrée du catalogue : l'identifiant de routage (`/`), l'ordre de résolution des collisions
+d'alias, le fournisseur et les noms commerciaux natifs d'OpenAI restent inchangés.
+
+Ajoutez un nom d'affichage depuis la CLI ; si le proxy est actif, il synchronise immédiatement le catalogue :
+
+```bash
+ocx models add deepseek deepseek-v4 --display-name "DeepSeek V4" --context-window 128000
+```
+
+Les clients Codex distants peuvent récupérer le même catalogue généré par l'API de gestion, avec le même jeton
+d'admission que pour les autres routes `/api/*` :
+
+```bash
+dest="${CODEX_HOME:-$HOME/.codex}/opencodex-catalog.json"
+tmp="$(mktemp "${dest}.XXXXXX")"
+curl -fsS -H "x-opencodex-api-key: $OPENCODEX_ADMIN_AUTH_TOKEN" \
+ "https://proxy.example.com/api/catalog" > "$tmp" \
+ && mv "$tmp" "$dest"
+ocx sync-cache
+```
+
+La réponse contient le document `opencodex-catalog.json` brut, sans identifiants de fournisseur. Lorsqu'il est
+disponible, l'en-tête `x-opencodex-codex-version` indique la version de l'environnement d'exécution Codex du
+serveur, afin que les clients puissent détecter un écart de version.
+
+Vous pouvez également définir ou modifier ce nom dans l'API de gestion — `POST /api/custom-models` ou
+`PUT /api/custom-models/` avec une chaîne `displayName` — et dans le tableau de bord web. Le caractère `/`
+est refusé, car il entrerait en collision avec le séparateur des identifiants de routage.
+
+Le nom d'affichage sert **uniquement à l'affichage et reste stable entre les régénérations**. À chaque `ocx sync`
+et à chaque actualisation du catalogue, opencodex reconstruit les entrées routées depuis `config.json`, y compris
+`customModels` ; le nom configuré est donc réappliqué au lieu de revenir à l'identifiant de routage. Un service
+géré tente également cette synchronisation peu après le démarrage du proxy. Si cette tentative au démarrage
+échoue, par exemple lors d'une connexion hors ligne, le catalogue déjà enregistré est conservé et le prochain
+`ocx sync` réussi réapplique le nom configuré. Les véritables noms natifs du service en amont, par exemple
+`gpt-5.6-sol` → "GPT-5.6-Sol", proviennent de l'instantané amont épinglé et ne sont jamais remplacés par un nom
+d'affichage personnalisé.
+
+### Gestionnaires de fournisseurs externes
+
+Si `config.toml` sélectionne déjà un fournisseur autre que `openai` ou `opencodex`, OpenCodex ne modifie pas le
+fichier. Il ignore également l'écriture des profils, l'actualisation du catalogue et du cache, ainsi que la
+migration immédiate ou en arrière-plan de l'historique Codex. Les outils qui gèrent un fournisseur personnalisé
+étiquettent souvent les sessions existantes avec son identifiant ; remplacer l'identifiant actif peut faire
+disparaître ces sessions pourtant intactes de la vue d'historique de Codex. La même protection s'applique à un
+fournisseur externe sélectionné par un ancien profil racine.
+
+Confiez la configuration des fournisseurs Codex à un seul outil. Pour placer OpenCodex derrière un gestionnaire
+de fournisseurs existant, faites pointer ce fournisseur vers `http://127.0.0.1:10100/v1` avec un transfert
+direct Responses — `wire_api = "responses"` dans le TOML Codex — et non avec une traduction Chat Completions.
+Lorsque l'authentification de l'API du proxy est activée, transmettez aussi l'en-tête `x-opencodex-api-key`
+depuis `OPENCODEX_API_AUTH_TOKEN`, comme dans la configuration hors bouclage ci-dessus. Pour autoriser OpenCodex
+à injecter directement le routage, rétablissez d'abord le fournisseur `openai` intégré de Codex, supprimez toute
+clé racine `openai_base_url` appartenant à l'utilisateur, puis relancez `ocx start`.
+
+### Dépannage du catalogue
+
+S'il manque un modèle dans Codex, ou si l'ordre ou la visibilité du catalogue semble incorrect, vérifiez les
+éléments suivants dans l'ordre :
+
+1. **`selectedModels`** sur le fournisseur — une liste d'autorisation non vide n'expose que ces identifiants à
+ Codex ; une liste vide ou absente expose tous les modèles découverts. Un identifiant absent de la liste
+ d'autorisation n'atteint jamais le catalogue.
+2. **`disabledModels`** au niveau supérieur — masque les modèles dans le catalogue comme dans `/v1/models`, et
+ fait passer les identifiants GPT natifs non qualifiés à `visibility: "hide"`.
+3. **`liveModels: false` avec `models` vide** — lorsque la découverte en direct est désactivée et que `models`
+ est vide ou absent, opencodex n'expose aucun modèle routé pour ce fournisseur.
+4. **Cursor `GetUsableModels`** — l'adaptateur Cursor découvre les modèles par son appel RPC protobuf
+ `GetUsableModels`, et non par `/models` ; une modification côté Cursor peut donc changer les identifiants visibles
+ indépendamment des autres fournisseurs.
+5. **Cache et `ocx sync`** — les catalogues en direct sont mis en cache pendant environ cinq minutes (`modelCacheTtlMs`,
+ par défaut `300000`). Exécutez `ocx sync` pour forcer une nouvelle récupération et réécrire le catalogue immédiatement.
+6. **Processus Codex `app-server` actif** — réécrire le catalogue sur disque ne suffit pas tant qu'un processus
+ Codex `app-server` de longue durée — Codex Desktop ou hôte d'arrière-plan de la CLI — conserve l'ancienne
+ liste en mémoire. `ocx sync` et `ocx sync-cache` émettent un avertissement lorsqu'ils détectent ces processus.
+ Redémarrez-les avec `ocx sync --restart-codex`, ou arrêtez vous-même les processus `app-server` concernés,
+ puis laissez Codex les recréer afin que la nouvelle liste apparaisse.
+
+:::caution[Autres processus d'écriture locaux]
+Les écritures du catalogue (`opencodex-catalog.json`, `config.toml`) sont atomiques **au sein** d'opencodex.
+Cette garantie évite les fichiers partiellement écrits lorsque deux processus appartenant à opencodex entrent
+en concurrence ; elle n'empêche **pas** un autre processus local, un observateur de fichiers ou un agent de
+synchronisation de modifier la visibilité ou l'ordre du catalogue après l'écriture d'opencodex. Codex conserve
+un fichier `models_cache.json` distinct et peut l'actualiser indépendamment, ce qui modifie la liste visible sans
+réécrire `opencodex-catalog.json`. Si la visibilité des modèles change de façon inattendue pendant l'exécution du
+proxy, arrêtez ou reconfigurez les autres processus d'écriture, puis exécutez `ocx sync`. Il s'agit d'un risque
+lié à un processus d'écriture externe, et non d'un défaut confirmé d'opencodex.
+:::
+
+## Erreurs de connexion proxy
+
+Si Codex réessaye puis échoue avec une erreur comme
+`stream disconnected before completion: error sending request for url (http://127.0.0.1:10100/v1/responses)`
+— ou si Claude Code signale un échec de connexion comparable — le proxy opencodex n'est pas actif : aucun
+processus n'écoute sur le port configuré, et le client affiche donc lui-même cette erreur de connexion brute.
+Redémarrez le proxy :
+
+```bash
+ocx start # foreground
+ocx service install # persistent: auto-starts on login and respawns on crash
+```
+
+`ocx status` indique si le proxy est actif et affiche la même suggestion de redémarrage lorsqu'il ne l'est pas ;
+`ocx doctor` évalue la sûreté du redémarrage — couverture par le service ou l'intercepteur.
+
+## Le sélecteur de sous-agents
+
+La synchronisation du catalogue rend les modèles de sous-agents sélectionnés disponibles dans Codex. Consultez
+le [sélecteur de modèles de l'application Codex](/fr/guides/codex-app-models/#sélection-des-sous-agents) pour connaître
+l'ordre des modèles, et la [surface des sous-agents](/fr/guides/sub-agent-surface/) pour le comportement de la
+délégation v1/base/v2 et de ses mécanismes de repli.
+
+## Préchauffage des comptes Codex
+
+Lorsqu'un compte ChatGPT est ajouté au groupe de comptes Codex, opencodex le vérifie avant de l'enregistrer
+avec une petite requête en streaming vers le service Codex Responses. La requête utilise un véritable tableau
+d'éléments Responses (`input: [{ type: "message", ... }]`), attend `response.completed` et utilise par défaut
+`gpt-5.4-mini`. Si ce modèle renvoie HTTP 400, opencodex réessaie avec `gpt-5.5` ; les détails structurés de
+l'erreur en amont sont affichés sans exposer le corps brut de la réponse. La revalidation en arrière-plan est
+distincte et désactivée par défaut. Elle ne s'exécute que si Token Guardian est actif, si la stratégie
+d'actualisation `chatgpt` vaut `proactive` et si `tokenGuardian.codexWarmupEnabled` vaut true.
+
+## Restauration de Codex natif
+
+opencodex ne vous enferme jamais dans sa configuration. **`ocx stop` est l'unique commande qui restaure
+entièrement Codex natif** : elle arrête le proxy et le service d'arrière-plan s'il est installé, puis supprime
+toutes les lignes injectées et toutes les entrées routées du catalogue. La commande `codex` fonctionne alors
+exactement comme si opencodex n'avait jamais été installé :
+
+```bash
+ocx stop # stop the proxy + service, restore native Codex
+ocx restore # restore without stopping (alias: ocx eject)
+ocx restore back # point plain Codex at the running proxy again
+```
+
+Lorsque opencodex s'exécute comme [service d'arrière-plan géré](/fr/reference/cli/lifecycle/#ocx-service-installrepairstartstopstatusuninstallremove), il définit
+`OCX_SERVICE=1` afin qu'un redémarrage déclenché par le service ne modifie **pas** sans cesse la configuration
+Codex. Seule l'exécution explicite de `ocx stop` ou `ocx service stop` restaure Codex natif.
diff --git a/docs-site/src/content/docs/fr/guides/combos.md b/docs-site/src/content/docs/fr/guides/combos.md
new file mode 100644
index 0000000000..b8f76fc52f
--- /dev/null
+++ b/docs-site/src/content/docs/fr/guides/combos.md
@@ -0,0 +1,346 @@
+---
+title: "Combos : basculement et équilibrage de charge"
+description: Acheminez un modèle virtuel vers plusieurs fournisseurs pour un basculement ou un équilibrage de charge pondéré.
+---
+
+Un **combo** est un modèle virtuel placé devant une liste ordonnée de cibles fournisseur/modèle réelles. Le client
+demande `combo/` ; opencodex choisit une cible, réécrit la requête vers le sélecteur concret
+`provider/model` et peut essayer une autre cible si la première rencontre un échec autorisant une nouvelle tentative.
+
+Ceci est utile lorsque vous souhaitez :
+
+- **Basculement :** privilégier un modèle tout en gardant des solutions de repli disponibles.
+- **Équilibrage de charge :** répartir les requêtes réussies entre plusieurs modèles ou fournisseurs par lots pondérés.
+
+Les combos interviennent en amont du routage normal des fournisseurs. Consultez d’abord [Routage des modèles](/fr/guides/model-routing/)
+si vous ne connaissez pas encore les sélecteurs `provider/model`.
+
+## Démarrage rapide en 60 secondes
+
+Cet exemple crée `combo/main`, avec Anthropic en premier et OpenAI en second. Les deux fournisseurs doivent
+déjà exister et être activés.
+
+```bash
+ocx combo set main --targets anthropic/claude-opus-4-8,openai/gpt-5.6-sol
+```
+
+La stratégie par défaut est le basculement, donc une requête normale est envoyée à
+`anthropic/claude-opus-4-8`. Si cette tentative rencontre un échec autorisant une nouvelle tentative, opencodex peut basculer vers
+`openai/gpt-5.6-sol`.
+
+Utilisez le modèle virtuel partout où vous fourniriez normalement un identifiant de modèle :
+
+```json
+{
+ "model": "combo/main",
+ "input": "Explain why the sky looks blue."
+}
+```
+
+Confirmez la définition enregistrée :
+
+```bash
+ocx combo show main
+```
+
+:::tip
+Commencez par le basculement avec des pondérations égales. Passez au round-robin uniquement si vous souhaitez réellement
+répartir le trafic, et n’ajoutez des pondérations que si une distribution uniforme ne convient pas.
+:::
+
+## Comment fonctionnent les noms de combos
+
+L'identifiant du combo dans `ocx combo set ` doit commencer par une lettre ou un chiffre. Il peut alors contenir
+lettres, chiffres, `.`, `_` ou `-`, jusqu'à 64 caractères au total. Son identifiant de modèle canonique est toujours
+`combo/` ; par exemple, id `main` devient `combo/main`.
+
+L'espace de noms `combo/` est réservé pendant la configuration des combos. Un fournisseur nommé `combo` ne peut pas
+l'occuper, et un identifiant combo ne peut pas dupliquer un nom de fournisseur configuré.
+
+Un alias facultatif donne au combo un nom de modèle public différent. Un pseudonyme :
+
+- utilise les mêmes caractères qu'un identifiant ;
+- peut être nu, comme `daily-fast`, ou contenir un `/`, comme `team/daily-fast` ;
+- ne peut pas être `combo` ni commencer par `combo/` ;
+- ne peut pas dupliquer un autre alias de combo ; et
+- ne peut normalement pas être un simple nom de famille OpenAI natif commençant par `gpt-`, `o1-`, `o3-`, `o4-`,
+ ou `codex-`. Le mode de compatibilité explicite du bureau ci-dessous est la seule exception.
+
+Même lorsqu'un alias est défini, la forme canonique `combo/` est toujours résolue. Exécutions de recherche canonique
+avant la correspondance d'alias, donc un alias ne peut pas reprendre l'identifiant canonique d'un autre combo.
+
+:::note
+Les alias modifient le nom public demandé par les clients ; ils ne changent ni l’identifiant enregistré du combo ni les
+sélecteurs concrets fournisseur/modèle qui le composent.
+:::
+
+## Compatibilité avec la liste d’autorisation native de Codex Desktop
+
+Certaines versions de Codex Desktop appliquent une liste d’autorisation `available_models` réservée aux modèles natifs après que
+le serveur d’application a déjà chargé `model_catalog_json`. Des identifiants routés normaux tels que
+`Nova1/codex-gpt-5.6-sol` restent alors utilisables dans la CLI, mais sont absents du sélecteur Desktop. Il s’agit du
+[bogue de Codex Desktop](https://github.com/openai/codex/issues/19694) en amont, suivi dans
+[opencodex #241](https://github.com/lidge-jun/opencodex/issues/241).
+
+Lorsque vous contrôlez une cible routée équivalente, un combo peut explicitement reprendre un identifiant natif :
+
+```bash
+ocx combo set nova-sol \
+ --targets Nova1/codex/gpt-5.6-sol \
+ --alias gpt-5.6-sol \
+ --native-alias \
+ --display-name 'Nova1 - codex-gpt-5.6-sol'
+```
+
+Ce mode est délibérément activation explicite et nécessite à la fois `--native-alias` et une étiquette d'affichage non vide.
+L’alias doit correspondre à l’un des identifiants de modèle natifs pris en charge par cette version ; un simple préfixe de
+famille native n’est pas accepté, car la suppression doit pouvoir restaurer des métadonnées faisant autorité.
+Lorsque la réponse de découverte de la cible routée ne fournit qu’un identifiant de modèle, la ligne de compatibilité complète
+les métadonnées manquantes de contexte, de modalité et de raisonnement à partir de l’identifiant natif remplacé. Les limites explicites
+de la cible restent prioritaires : ce mécanisme de repli n’augmente jamais un plafond de contexte et ne remplace aucune capacité déclarée.
+Cela modifie la priorité de routage exacte : les demandes de `gpt-5.6-sol` se résolvent en `combo/nova-sol` avant
+la route canonique de la famille native OpenAI. Le catalogue contient une seule ligne non qualifiée portant le libellé
+d’affichage configuré, et non deux lignes, native et combo. Seul l’identifiant non qualifié `gpt-5.6-sol` est intercepté.
+Lignes qualifiées par le compte telles que `main/gpt-5.6-sol` et lignes qualifiées par le fournisseur telles que
+`openai-apikey/gpt-5.6-sol` restent des itinéraires OpenAI distincts ; l'itinéraire clé API qualifié par le fournisseur
+ne tombe jamais dans l'alias natif.
+
+Les clés de visibilité restent sans ambiguïté :
+
+- `combo/nova-sol` masque le combo de compatibilité de la découverte.
+- L'entrée `gpt-5.6-sol` nue dans `disabledModels` continue de signifier la ligne OpenAI native dormante ;
+ cela ne masque pas le combo qui détient actuellement cet identifiant public.
+- Lorsqu'au moins un alias natif est configuré, les lignes natives nues désactivées sont omises du
+ catalogue Codex effectif au lieu d’être conservées avec `visibility: "hide"`. La liste d’autorisation de
+ Desktop ne peut donc pas faire réapparaître des lignes qui devraient rester masquées. La page **Modèles**
+ continue d’afficher les commutateurs natifs non masqués ; réactiver l’un d’eux restaure ses métadonnées
+ natives préservées ou actuelles.
+
+:::caution
+Un alias natif reprend intentionnellement un identifiant de modèle propriétaire. Utilisez-le uniquement lorsque la cible
+est opérationnellement équivalente et étiquetez honnêtement la ligne du sélecteur. La suppression du combo restaure
+le routage natif et l’identité du catalogue lors de la prochaine synchronisation.
+:::
+
+## Choisissez une stratégie
+
+### Basculement : commande principale et sauvegardes
+
+`failover` sélectionne la première cible éligible dans l’ordre de configuration. Une cible est éligible lorsque son
+fournisseur existe, est activé, n’est pas en période de refroidissement et peut gérer toute contrainte particulière de la demande.
+Les poids et `stickyLimit` n’affectent pas cette stratégie.
+
+Compte tenu de cet ordre :
+
+1. `anthropic/claude-opus-4-8`
+2. `openai/gpt-5.6-sol`
+3. `google/gemini-3-pro`
+
+chaque requête commence par Anthropic. Un échec d’Anthropic autorisant une nouvelle tentative fait basculer la requête vers OpenAI ; un
+échec similaire d’OpenAI peut la faire basculer vers Google. Une erreur terminale interrompt immédiatement le traitement au lieu de
+essayer les cibles restantes.
+
+### Round-robin : lots pondérés lisses
+
+`round-robin` utilise un round-robin pondéré en douceur. Un poids cible plus grand donne à cet objectif un plus grand
+partager au fil du temps sans envoyer la totalité de sa part en un seul long bloc. `stickyLimit` contrôle combien
+les demandes réussies restent sur la cible sélectionnée avant la prochaine sélection pondérée.
+
+Créez un combo 2:1 avec des lots de deux requêtes réussies :
+
+```bash
+ocx combo set balanced \
+ --targets anthropic/claude-opus-4-8:2,openai/gpt-5.6-sol:1 \
+ --strategy round-robin \
+ --sticky 2
+```
+
+Appelant les cibles **A** (poids 2) et **B** (poids 1), les six premières sélections pondérées sont
+`A, B, A, A, B, A`. Parce que `stickyLimit` est 2,, chaque sélection reste active pendant deux
+demandes :
+
+| Demande réussie | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| Cible | A | A | B | B | A | A | A | A | B | B | A | A |
+
+À long terme, la répartition reste de 2:1. Un échec autorisant une nouvelle tentative met fin au lot persistant en cours et place la cible en période de refroidissement.
+cible et sélectionne une autre cible éligible pour la même demande.
+
+:::caution
+Les poids sont relatifs et non en pourcentage. Les poids `2,1` et `200,100` expriment le même rapport. Préférer
+petites valeurs qui communiquent l’intention.
+:::
+
+## Que se passe-t-il lorsqu'une cible échoue
+
+Les échecs d’un combo se répartissent entre ceux qui entraînent un **basculement** et les échecs **terminaux**.
+
+| Résultat | Comportement |
+| --- | --- |
+| HTTP 401, 403, 404, 408, 429, ou n'importe quel 5xx | Refroidissez la cible et passez à la prochaine cible éligible. |
+| Erreur classée comme erreur d’authentification, d’abonnement, de quota, de limitation de débit, de surcharge ou de serveur en amont | Place la cible en période de refroidissement et bascule, même si le statut seul ne suffit pas. |
+| Annulation client (499), `origin_rejected`, refus de cyber-politique, débordement de contexte ou demande invalide | Arrêtez et renvoyez l'erreur ; une autre cible ne rendrait pas la demande valide. |
+| Toute autre erreur non classifiée | Arrêtez et renvoyez l'erreur. |
+
+Une cible sautée entre en temps de recharge pendant 60 secondes par défaut. Si la réponse en amont inclut un
+valeur `Retry-After` valide, opencodex l’utilise à la place. Les secondes numériques et les valeurs de date HTTP sont
+accepté, et chaque temps de recharge est limité à 10 minutes.
+
+La requête actuelle ne réessaye jamais la même cible tentée. Les demandes ultérieures l'ignorent jusqu'à ce qu'il soit
+le temps de recharge expire. S’il ne reste aucune cible éligible, le proxy renvoie HTTP 503 avec
+`error.code = "combo_unavailable"`.
+
+:::note
+Le basculement est intentionnellement limité. Il facilite la disponibilité, l'authentification et l'authentification spécifiques à la cible.
+échecs de quota et de surcharge ; il ne cache pas les erreurs des appelants ni les refus de politique.
+:::
+
+## Effort de raisonnement par défaut
+
+`defaultEffort` fournit `reasoning.effort` uniquement lorsque toutes ces conditions sont vraies :
+
+1. le combo a un défaut non nul ;
+2. l'appelant n'a pas fait d'effort ; et
+3. le catalogue de la cible sélectionnée annonce cet effort précis.
+
+Si la requête n'a pas d'objet `reasoning`, opencodex en crée un. Si `reasoning` existe sans
+`effort`, il préserve les autres champs et ajoute la valeur par défaut. Un effort fourni par l’appelant n’est
+jamais écrasé.
+
+Lorsque la capacité cible est inconnue ou n'inclut pas l'effort configuré, opencodex omet le
+par défaut et laisse le comportement de la cible inchangé. Les valeurs prises en charge sont `low`, `medium`,
+`high`, `xhigh`, `max` et `ultra` ; omettez le champ ou réglez-le sur `null` pour laisser l'effort entièrement à
+l'appelant et la cible.
+
+## Capacité d’entrée d’images / multimodale
+
+Par défaut, une combinaison publie l’**intersection** des modalités d’entrée de ses cibles : les images ne
+sont activées que lorsque toutes les cibles les annoncent. Définissez `imageInput: "disabled"` pour forcer
+le texte seul même si toutes les cibles prennent en charge les images. Le catalogue retire alors `image`
+de `inputModalities`, et les requêtes contenant des images sont rejetées avec le code HTTP 400 avant tout
+appel de cible. La valeur `"auto"`, ou l’absence du champ, conserve l’intersection automatique.
+
+## Tâches du sous-agent v2 chiffrées
+
+Il existe une limitation importante pour les sous-agents Codex v2 ([issue #92](https://github.com/lidge-jun/opencodex/issues/92)).
+Un parent natif peut envoyer la tâche d'un travailleur nouvellement généré uniquement sous forme de texte chiffré créé pour le natif.
+ChatGPT back-end. Un fournisseur externe ne peut pas lire cette charge utile.
+
+Pour une telle requête, un combo filtre ses cibles éligibles sur les routes ChatGPT natives canoniques,
+y compris après un échec autorisant une nouvelle tentative. Si le combo ne comporte aucune cible capable de déchiffrer la tâche, opencodex s’arrête
+avant expédition et retours HTTP 400 :
+
+```json
+{
+ "error": {
+ "type": "invalid_request_error",
+ "code": "unreadable_encrypted_agent_task"
+ }
+}
+```
+
+Cela empêche la tâche d’être envoyée à un fournisseur qui ne recevrait aucune instruction lisible.
+Les tâches en texte clair lisibles utilisent la stratégie combo normale.
+
+Vous disposez de quatre options de récupération :
+
+1. Sélectionnez un modèle ChatGPT natif pour l'enfant.
+2. Ajoutez une cible ChatGPT native canonique au combo.
+3. Utilisez la surface v1 pour la délégation entre différents fournisseurs.
+4. Si vous contrôlez l'appelant, renvoyez la tâche sous forme de contenu en texte brut v2 `agent_message`.
+
+Voir [Surface sous-agent](/fr/guides/sub-agent-surface/) pour les modes v1/base/v2 et le chiffrement complet
+flux de travail des tâches.
+
+## Gérer les combos
+
+### Tableau de bord
+
+Ouvrez le tableau de bord local et choisissez **Modèles → Combos**. L'espace de travail crée, modifie, renomme et supprime
+combos, et son sélecteur de cible exclut les modèles désactivés et les combos imbriqués.
+
+### CLI
+
+Les commandes principales sont :
+
+```bash
+ocx combo list
+ocx combo show
+ocx combo set --targets provider/model[:weight],...
+ocx combo remove --yes
+```
+
+`set` accepte également `--strategy`, `--sticky`, `--effort`, `--alias`, `--native-alias`,
+`--display-name` et `--rename-from`. Utilisez `-` comme valeur de `--effort`, `--alias` ou
+`--display-name` pour effacer ce champ. `--native-alias` exige un alias de modèle natif non qualifié actuellement
+pris en charge et un nom d’affichage non vide. `create` et `update` sont des alias pour `set` ; `delete` est un alias pour
+`remove` ; et les mêmes sous-commandes sont disponibles sous `ocx route combo`.
+
+### Gestion API
+
+Les clients sans interface utilisent `GET`, `PUT` et `DELETE` sur `/api/combos`. `GET` liste les définitions
+normalisées, `PUT` en crée ou en remplace une et peut en renommer une, tandis que `DELETE` utilise le paramètre
+de requête `id`. L’authentification et les détails des requêtes et réponses se trouvent dans la
+[Gestion API référence](/fr/reference/management-api/).
+
+Pour la configuration persistante complète, voir [Configuration](/fr/reference/configuration/).
+
+## Référence de configuration
+
+Les combos sont stockés dans l'objet `combos` de niveau supérieur, saisi par l'identifiant du combo :
+
+```json
+{
+ "combos": {
+ "balanced": {
+ "targets": [
+ { "provider": "anthropic", "model": "claude-opus-4-8", "weight": 2 },
+ { "provider": "openai", "model": "gpt-5.6-sol", "weight": 1 }
+ ],
+ "strategy": "round-robin",
+ "stickyLimit": 2,
+ "defaultEffort": "high",
+ "alias": "team/balanced"
+ }
+ }
+}
+```
+
+| Champ | Obligatoire | Par défaut | Règles |
+| --- | --- | --- | --- |
+| `targets` | Oui | — | Tableau ordonné non vide de `{ provider, model, weight? }` cibles configurées. Les paires provider/model en double sont rejetées. |
+| `targets[].weight` | Non | `1` | Entier de 1 à 10 000. Utilisé en round-robin ; ignoré par le basculement. |
+| `strategy` | Non | `"failover"` | `"failover"` ou `"round-robin"`. |
+| `stickyLimit` | Non | `1` | Nombre entier de 1 à 100 requêtes réussies par sélection à tour de rôle. |
+| `defaultEffort` | Non | `null` | `low`, `medium`, `high`, `xhigh`, `max` ou `ultra` ; appliqué uniquement lorsque l'appelant omet ses efforts et que la cible annonce son soutien. |
+| `imageInput` | Non | `"auto"` | `"auto"` ou `"disabled"`. `"auto"` publie les images uniquement si toutes les cibles les prennent en charge ; `"disabled"` impose le texte seul, retire les images des modalités publiées et rejette les requêtes qui en contiennent avant leur distribution. |
+| `alias` | Non | aucun | Identifiant de modèle public tronqué facultatif ; utilisez les règles d'alias ci-dessus. Une valeur vide est stockée sans alias. |
+| `nativeAlias` | Non | `false` | Autoriser explicitement un `alias` natif nu actuellement pris en charge à avoir la priorité sur le routage et le catalogue. Jamais déduit de l'alias. |
+| `displayName` | Non | aucun | Étiquette de catalogue délimitée en affichage uniquement. Obligatoire et non vide lorsque `nativeAlias` est vrai. |
+
+## Dépannage
+
+### Pourquoi `combo/` renvoie 404 ?
+
+L'identifiant du combo est inconnu. La réponse est HTTP 404 de type `invalid_request_error`. Courir
+`ocx combo list`, vérifiez l'orthographe et la casse, et confirmez que votre commande de gestion a écrit sur le même
+exécution d'une instance opencodex qui reçoit des requêtes de modèle.
+
+### Pourquoi est-ce que je reçois `combo_unavailable` ?
+
+Chaque cible est actuellement inéligible : par exemple, son fournisseur est désactivé, il est en phase de refroidissement,
+elle a déjà été tentée pour cette requête, ou une tâche v2 chiffrée l'exclut. Vérifier la cible
+état du fournisseur et erreurs récentes en amont. Pour les temps de recharge, attendez la valeur par défaut de 60 secondes ou la
+délai indiqué par `Retry-After` en amont (jamais plus de 10 minutes), puis réessayez.
+
+### Pourquoi mon alias a-t-il été rejeté ?
+
+Vérifiez d'abord la grammaire des alias et les noms réservés. Un alias en double ou une forme non valide est rejeté comme
+HTTP 400. Un alias barre oblique dont le premier segment est un espace de noms de compte Codex configuré est rejeté
+comme HTTP 409 ; choisissez un autre espace de noms d’alias. Le CLI et le tableau de bord affichent l'adresse exacte du serveur.
+message de validation.
+
+### Pourquoi le basculement s'est-il arrêté après la première erreur ?
+
+L’erreur était terminale plutôt que spécifique à la cible. Corriger une entrée invalide, réduire un contexte surdimensionné,
+gérer un refus de politique ou corriger l’origine de la demande rejetée. Les combos ne sautent pas dans ces cas-là.
diff --git a/docs-site/src/content/docs/fr/guides/factory-droid.md b/docs-site/src/content/docs/fr/guides/factory-droid.md
new file mode 100644
index 0000000000..515c3ac66b
--- /dev/null
+++ b/docs-site/src/content/docs/fr/guides/factory-droid.md
@@ -0,0 +1,146 @@
+---
+title: Pont Factory Droid
+description: Connectez les modèles Factory Droid à OpenCodex au moyen d’un pont local compatible avec Responses.
+---
+
+Factory Droid est un environnement d’exécution d’agents, et non un point de terminaison d’inférence compatible avec OpenAI et documenté. Si un fournisseur personnalisé qui pointe vers une URL interne de Factory LLM renvoie `403 Forbidden`, modifier uniquement l’adaptateur OpenCodex ou ajouter des en-têtes de fournisseur ne transforme pas cette route privée en API publique prise en charge.
+
+L’intégration fonctionnelle est la suivante :
+
+```text
+Client Responses en texte seul
+ -> OpenCodex (http://127.0.0.1:10100/v1/responses)
+ -> pont Responses local (http://127.0.0.1:11435/v1/responses)
+ -> commande officielle droid exec
+ -> compte Factory et modèle sélectionné
+```
+
+Ainsi, l’identifiant Factory reste dans le client Droid officiel. OpenCodex reçoit un jeton distinct, limité au pont local.
+
+## Échecs possibles et causes
+
+| Symptôme | Cause | Correction |
+| --- | --- | --- |
+| `403 Forbidden` depuis une URL Factory LLM | Cette URL n’est pas un point de terminaison OpenAI général documenté pour les clients tiers | Appelez Factory au moyen du CLI ou du SDK Droid officiel |
+| `404` sur `/models/models` | L’URL de base du fournisseur se terminait déjà par `/models` | Utilisez la racine de l’API comme `baseUrl` ; n’y incluez jamais le chemin de découverte |
+| La recherche de modèles échoue | Le pont n’expose pas de catalogue dynamique complet | Définissez `liveModels: false` et fournissez une liste `models` statique |
+| Le fournisseur local est rejeté | L’accès au réseau privé est refusé par défaut | Définissez `allowPrivateNetwork: true` uniquement pour le pont local |
+| `${DROID_BRIDGE_TOKEN}` n’est pas résolu | La variable est absente de l’environnement du service OpenCodex | Injectez-la dans le processus de service, pas seulement dans un terminal interactif |
+| `OutputTextDelta without active item` | Le pont a émis un delta de texte avant d’ouvrir un élément de sortie et une partie de contenu | Émettez dans l’ordre le cycle de vie SSE Responses complet |
+
+Le même identifiant Factory peut donc fonctionner avec `droid exec` alors qu’une requête directe vers une URL LLM non documentée renvoie toujours `403`. Ces résultats testent des produits différents et ne sont pas contradictoires.
+
+## Prérequis
+
+1. Installez le [CLI Droid](https://docs.factory.ai/droid-cli/quickstart) et connectez-vous.
+2. Vérifiez qu’une requête non interactive et bornée fonctionne :
+
+ ```bash
+ droid exec --model glm-5.2 --output-format json "Reply with DROID_OK only."
+ ```
+
+3. Exécutez un pont local qui appelle `droid exec` (ou le SDK Droid officiel) et expose :
+
+ - `GET /healthz`
+ - `GET /v1/models`
+ - `POST /v1/responses`
+
+Factory présente `droid exec` comme son interface d’automatisation non interactive et recommande la sortie JSON pour les scripts. Pour une intégration de plus longue durée, Factory documente également le flux JSON-RPC ainsi que les SDK TypeScript et Python officiels dans le [guide Droid Exec](https://docs.factory.ai/droid-exec/overview).
+
+## Contrat du pont
+
+Liez le pont à `127.0.0.1`, exigez un jeton porteur généré aléatoirement, limitez la taille des requêtes et autorisez explicitement les identifiants de modèle. Le pont minimal accepte uniquement les formes `input` Responses suivantes :
+
+- une chaîne non vide ; ou
+- un tableau composé uniquement d’éléments `message`. Chaque message doit avoir le rôle `user`, `developer`, `system` ou `assistant`, et contenir soit une chaîne, soit des parties de contenu textuelles (`input_text` pour les rôles d’entrée et `output_text` pour l’historique de l’assistant).
+
+Validez la requête entière avant d’appeler Droid. Si une partie d’entrée est une image ou un fichier, si `tools` contient une définition d’outil, ou si `input` contient un appel ou un résultat d’outil (`function_call`, `function_call_output`, `custom_tool_call` ou `custom_tool_call_output`), renvoyez une réponse HTTP `400` avec une erreur `invalid_request_error` au format Responses. Utilisez un code propre au pont et stable, comme `unsupported_bridge_input`, et indiquez le champ rejeté dans le message. Faites-le avant de démarrer le flux SSE, même lorsque `stream: true` ; n’ignorez, ne sérialisez et n’aplatissez jamais le contenu non pris en charge dans le prompt.
+
+```json
+{
+ "error": {
+ "type": "invalid_request_error",
+ "code": "unsupported_bridge_input",
+ "param": "tools",
+ "message": "The minimal Droid bridge does not accept tool definitions."
+ }
+}
+```
+
+Pour une requête acceptée, le pont doit :
+
+1. convertir l’`input` Responses accepté en prompt ;
+2. appeler `droid exec --model --output-format json ` ;
+3. analyser les valeurs finales `result` et `session_id` ;
+4. renvoyer une enveloppe OpenAI Responses ;
+5. associer `previous_response_id` à l’identifiant de session Droid lorsqu’une continuation est requise.
+
+Pour les réponses diffusées, émettez ce cycle de vie dans l’ordre :
+
+```text
+response.created
+response.output_item.added
+response.content_part.added
+response.output_text.delta
+response.output_text.done
+response.content_part.done
+response.output_item.done
+response.completed
+```
+
+N’exposez pas le pont sur `0.0.0.0` et ne réutilisez pas l’identifiant Factory comme jeton porteur du pont.
+
+## Configuration du fournisseur OpenCodex
+
+Créez le fournisseur personnalisé avec l’identifiant explicite `droid` :
+
+```bash
+ocx provider add droid \
+ --adapter openai-responses \
+ --base-url http://127.0.0.1:11435/v1 \
+ --default-model glm-5.2 \
+ --allow-private-network
+```
+
+Cette commande crée l’entrée de configuration `providers.droid`. Dans le tableau de bord, ouvrez **Fournisseurs → droid → Modifier le JSON** et remplacez la valeur du fournisseur par :
+
+```json
+{
+ "adapter": "openai-responses",
+ "baseUrl": "http://127.0.0.1:11435/v1",
+ "responsesPath": "/responses",
+ "allowPrivateNetwork": true,
+ "authMode": "key",
+ "apiKey": "${DROID_BRIDGE_TOKEN}",
+ "liveModels": false,
+ "models": ["glm-5.2", "glm-5.2-fast", "kimi-k3"],
+ "defaultModel": "glm-5.2"
+}
+```
+
+Les identifiants de modèle ne sont que des exemples. Ne conservez que les modèles utilisables par `droid exec` avec le compte Factory connecté. N’ajoutez pas d’en-têtes d’inférence propres à Factory à ce fournisseur : son service en amont est le pont local, et non un point de terminaison HTTP Factory.
+
+Après avoir enregistré un fournisseur ou modifié son catalogue statique, synchronisez puis redémarrez le serveur d’application Codex afin que les nouvelles sessions lisent le catalogue à jour :
+
+```bash
+ocx sync --restart-codex
+ocx doctor
+```
+
+Le redémarrage des processus du serveur d’application Codex interrompt les travaux Codex actifs. Ne le lancez qu’après avoir terminé ou enregistré ces sessions.
+
+## Vérifier la route complète
+
+Vérifiez chaque frontière séparément :
+
+```bash
+curl -fsS http://127.0.0.1:11435/healthz
+ocx doctor
+ocx access test droid/glm-5.2 --protocol responses
+```
+
+La présence d’une ligne de fournisseur ou d’une entrée dans le sélecteur de modèles prouve uniquement la visibilité dans le catalogue. L’intégration ne fonctionne réellement qu’une fois la sonde Responses revenue par la route `droid/`.
+
+## Limitation actuelle
+
+Le pont minimal décrit ci-dessus traduit le texte et le cycle de vie SSE Responses. Il n’implémente **pas** le protocole bidirectionnel complet des appels de fonctions et d’outils de Codex. Codex App et `codex exec` envoient normalement des définitions d’outils même si le prompt demande de ne pas appeler d’outil, et le CLI Codex actuel ne fournit aucun indicateur général pour les supprimer. Le pont minimal doit rejeter ces requêtes conformément au contrat `400` ci-dessus. Les définitions, appels et résultats d’outils, les autorisations, l’annulation et les événements Droid enrichis nécessitent un pont avec état fondé sur le mode de flux JSON-RPC de Factory ou sur un SDK Droid officiel. Considérez le succès de `ocx access test` comme une validation du chemin textuel, et non du chemin des agents ou des outils Codex.
diff --git a/docs-site/src/content/docs/fr/guides/grok-build.md b/docs-site/src/content/docs/fr/guides/grok-build.md
new file mode 100644
index 0000000000..69f4e056c0
--- /dev/null
+++ b/docs-site/src/content/docs/fr/guides/grok-build.md
@@ -0,0 +1,152 @@
+---
+title: Grok Build
+description: Utilisez n’importe quel modèle routé par opencodex depuis la CLI Grok Build de xAI — les modèles sont automatiquement enregistrés dans ~/.grok/config.toml pendant l’exécution du proxy.
+---
+
+opencodex expose un point de terminaison compatible OpenAI `POST /v1/chat/completions` (ainsi que `/v1/responses`) sur son
+port local, tandis que Grok Build prend en charge les modèles personnalisés hébergés sur des serveurs compatibles OpenAI. Avec
+cette intégration, opencodex enregistre automatiquement l’intégralité de son catalogue visible dans Grok Build :
+aucune modification manuelle de la configuration n’est nécessaire.
+
+## Enregistrement automatique
+
+Lorsque `~/.grok` existe, `ocx start` (et `ocx ensure` / `ocx restart`) écrit un bloc géré
+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"
+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 ...
+# <<< opencodex managed block <<<
+```
+
+- **Additif :** votre propre configuration, en dehors des délimiteurs, n’est jamais modifiée. Avant la première
+ injection dans un fichier existant, une sauvegarde unique est créée dans
+ `~/.grok/config.toml.bak-opencodex`.
+- **Idempotent :** chaque exécution de `ocx start` (ainsi que de `ocx ensure` lorsque le démarrage automatique est activé) remplace
+ le bloc délimité par le catalogue actuel.
+- **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).
+- **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.
+
+Choisissez ensuite un modèle dans Grok Build :
+
+```bash
+grok models # lists ocx-* entries alongside native grok models
+grok -m ocx-anthropic-claude-opus-4-8 -p "hello"
+# or in the TUI: /model ocx-anthropic-claude-opus-4-8
+```
+
+## Effort de raisonnement
+
+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
+(`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.
+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.
+
+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.
+
+## Note d'authentification
+
+Grok Build exige une clé API non vide pour les modèles personnalisés, même sur l’interface de bouclage. Les entrées
+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.
+
+## 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` :
+
+```toml
+[model.ocx-opus]
+model = "anthropic/claude-opus-4-8"
+base_url = "http://127.0.0.1:10100/v1"
+api_backend = "chat_completions"
+api_key = "opencodex-loopback"
+```
+
+Pour un proxy joignable sur le réseau, pointer `base_url` à l'adresse `grok` peut effectivement
+composez et utilisez votre jeton d'entrée :
+
+```toml
+[model.ocx-opus]
+model = "anthropic/claude-opus-4-8"
+base_url = "http://192.168.1.10:10100/v1" # the reachable host, not 127.0.0.1
+api_backend = "chat_completions"
+api_key = "your-OPENCODEX_API_AUTH_TOKEN"
+```
+
+Ne comptez pas sur l'héritage `[model_providers.]` 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.
+
+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
+
+- **Réponses backend et keep-alives:** opencodex émet un `response.heartbeat` keep-alive
+ dans les flux `/v1/responses` pendant les périodes de silence en amont. Le décodeur Responses de Grok Build
+ rejette les types d'événements inconnus, donc un modèle `api_backend = "responses"` configuré manuellement
+ peut échouer à mi-tour sur des amonts lents. Le code PIN des entrées enregistrées automatiquement
+ `api_backend = "chat_completions"`, qui ne fait jamais apparaître les images de battements de cœur bruts.
+- **Installé par le service `ocx restart` :** le proxy en cours d'exécution possède l'autorisation de redémarrage et la vidange
+ coordination, tandis que le gestionnaire de service installé lance le remplacement après l'ancien processus
+ sorties. La supervision du service reste installée. Lors de l'enregistrement automatique en boucle, le bloc géré
+ reste également en place tout au long du transfert ; les déploiements sans bouclage utilisent une gestion manuelle Grok
+ configuration à la place. La commande ne réussit qu'après qu'un processus différent, avec vérification d'identité, ait été effectué.
+ sain sur le même port.
+- **Moment de lecture de la configuration :** démarrez d’abord opencodex, puis lancez `grok` pour obtenir les résultats les plus
+ 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.
+- **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.
diff --git a/docs-site/src/content/docs/fr/guides/image-bridge.md b/docs-site/src/content/docs/fr/guides/image-bridge.md
new file mode 100644
index 0000000000..98b388221a
--- /dev/null
+++ b/docs-site/src/content/docs/fr/guides/image-bridge.md
@@ -0,0 +1,95 @@
+---
+title: Pont de génération d'images
+description: Acheminer les appels à l'outil hébergé image_generation vers xAI Grok Imagine lorsqu'un fournisseur autre qu'OpenAI est utilisé.
+---
+
+## Vue d'ensemble
+
+Lorsque vous acheminez Codex vers un modèle autre qu'OpenAI (Claude, Gemini, Grok, etc.), l'**outil
+hébergé** `image_generation` ne fonctionne normalement pas : il dépend de l'environnement d'exécution
+côté serveur d'OpenAI. Le pont de génération d'images détecte ces appels et les redirige de manière
+transparente vers xAI Grok Imagine, afin que le modèle avec lequel vous échangez puisse tout de même
+générer des images.
+
+## Prérequis
+
+- **Activez le pont** en définissant `images.bridgeEnabled: true` dans votre configuration (il est désactivé
+ par défaut afin d'éviter des frais xAI inattendus — voir [Configuration](#configuration) ci-dessous).
+- Configurez un fournisseur `xai` avec une **clé API**. Le pont envoie systématiquement les requêtes au
+ point de terminaison Images xAI du registre (`https://api.x.ai/v1`) ; tout remplacement de `baseUrl`
+ configuré est ignoré pour les appels d'images. OAuth ou `ocx login xai` seul n'active **pas** le pont
+ (le transport OAuth de la CLI Grok est destiné aux conversations et n'est pas utilisé pour `/images/*`).
+
+ ```json
+ {
+ "providers": {
+ "xai": { "adapter": "openai-chat", "apiKey": "xai-…", "authMode": "key" }
+ }
+ }
+ ```
+
+- Sélectionnez comme fournisseur actif un modèle autre qu'OpenAI. (Lorsque le fournisseur actif est
+ OpenAI, l'outil hébergé natif est utilisé directement et le pont est contourné.)
+
+## Configuration
+
+Les options du pont de génération d'images se trouvent sous `images` dans
+`~/.opencodex/config.json`. Le pont est **facultatif** : vous devez définir `bridgeEnabled: true`
+pour activer la génération payante avec xAI Grok Imagine :
+
+```json
+{
+ "images": {
+ "bridgeEnabled": true,
+ "bridgeModel": "grok-imagine-image-quality",
+ "maxRounds": 3,
+ "timeoutMs": 60000
+ }
+}
+```
+
+| Option | Valeur par défaut | Description |
+| --- | --- | --- |
+| `bridgeEnabled` | `false` | Interrupteur principal. Définissez-le sur `true` pour activer le pont. Il est désactivé par défaut afin d'éviter des frais xAI inattendus. |
+| `bridgeModel` | `grok-imagine-image-quality` | Identifiant du modèle d'image xAI auquel envoyer les invites. |
+| `maxRounds` | `3` | Nombre maximal d'itérations de la boucle de génération d'images par tour. La valeur est ramenée à un entier et limitée à `[0, 10]` ; une valeur non finie est remplacée par `3`. |
+| `timeoutMs` | `60000` | Délai maximal par appel xAI, en millisecondes. Les valeurs positives et finies sont ramenées à un entier, puis transmises à la requête xAI. |
+| `artifactsKeepCount` | `200` | Nombre maximal de fichiers conservés sous `artifacts/`. Lorsque cette limite est dépassée, les fichiers les plus anciens sont supprimés après chaque appel mené à terme. Définissez la valeur sur `0` ou sur un nombre négatif pour désactiver l'élagage. |
+
+## Conservation des artefacts
+
+Les images générées sont enregistrées dans `~/.opencodex/artifacts/`. Pour éviter une croissance illimitée
+du stockage pendant les sessions prolongées, le répertoire est automatiquement élagué après chaque appel
+d'image mené à terme (une fois que tout le lot de cet appel est enregistré sur le disque). Lorsque le nombre
+de fichiers dépasse le maximum configuré (200 par défaut, réglable avec `images.artifactsKeepCount`), les
+plus anciens selon leur date de modification sont supprimés. Seuls les chemins qui subsistent après cet
+élagage sont renvoyés au modèle.
+
+## Fonctionnement
+
+Le pont de génération d'images s'active uniquement pendant les tours **Responses** qui incluent l'outil
+hébergé `image_generation` dans le tableau tools de `/v1/responses`, lorsqu'un modèle **autre qu'OpenAI**
+est sélectionné. Il n'intercepte **pas** l'outil `image_gen` intégré à Codex, lequel envoie directement une
+requête POST à `/v1/images/generations` (ou `/images/edits`) ; ce parcours est traité séparément dans
+[Intégration de Codex](/fr/guides/codex-integration/#génération-dimages-intégrée-image_gen).
+
+1. Lorsqu'une requête Responses répertorie `image_generation` dans `tools`, OpenCodex le détecte pendant le
+ prétraitement de la requête.
+2. L'outil hébergé est remplacé par un **outil de fonction synthétique** que le modèle routé peut appeler
+ normalement : le modèle voit un outil exécutable plutôt qu'un outil hébergé opaque qu'il ne peut exécuter.
+3. Lorsque le modèle appelle cet outil, OpenCodex intercepte l'appel et envoie l'invite à l'API de génération
+ d'images de xAI.
+4. Les images générées sont enregistrées dans `~/.opencodex/artifacts/`, puis leur **chemin de fichier local**
+ est renvoyé au modèle comme résultat de l'outil.
+5. Le modèle poursuit la conversation en connaissant l'image générée et son emplacement.
+
+Du point de vue du modèle, rien n'a changé : il a appelé un outil et obtenu un résultat. Du point de vue de
+l'utilisateur, la génération d'images fonctionne avec n'importe quel fournisseur routé au lieu d'échouer
+silencieusement.
+
+## Limitations
+
+- **Seul xAI Grok Imagine est pris en charge.** DALL-E et d'autres fournisseurs d'images pourront être ajoutés ultérieurement.
+- **La recherche web est prioritaire** sur les adaptateurs qui prennent en charge la boucle du service auxiliaire de recherche web. Si la recherche web et la génération d'images sont toutes deux demandées pendant le même tour, la recherche web est exécutée et la génération d'images est ignorée. Les adaptateurs Cursor/`runTurn` ne peuvent actuellement pas utiliser ce service auxiliaire ; le pont de génération d'images peut donc tout de même s'exécuter pendant ces tours qui demandent les deux outils.
+- **Les tarifs xAI s'appliquent.** La génération d'images par xAI exige un abonnement xAI actif ou des crédits API.
+- **Diffusion en continu uniquement.** Le pont intercepte le flux de réponse SSE ; les requêtes contenant `stream: false` sont rejetées avec une erreur 400.
diff --git a/docs-site/src/content/docs/fr/guides/integrations.md b/docs-site/src/content/docs/fr/guides/integrations.md
new file mode 100644
index 0000000000..269e38e93b
--- /dev/null
+++ b/docs-site/src/content/docs/fr/guides/integrations.md
@@ -0,0 +1,174 @@
+---
+title: Intégrations
+description: Connectez opencodex à OpenCode, Pi, OMP, Hermes, OpenClaw, Kimi Code, Gajae Code, DeepSeek Harness et MiniMax Code depuis le tableau de bord — un commutateur par client, avec une sauvegarde avant chaque écriture.
+---
+
+L'onglet **Intégrations** écrit le bloc fournisseur d'opencodex dans le fichier de configuration du client,
+puis peut le retirer. Neuf clients fonctionnent ainsi, chacun avec son propre commutateur :
+
+| Client | Fichier de configuration | Format | Prise d'effet de la modification | Identifiant |
+|---|---|---|---|---|
+| OpenCode | `~/.config/opencode/opencode.json` | JSON | au prochain lancement direct | `OPENCODEX_OPENCODE_API_KEY` |
+| Pi | `~/.pi/agent/models.json` | JSON | dans les nouvelles sessions | valeur fictive de bouclage |
+| OMP | `~/.omp/agent/models.yml` | YAML | après le redémarrage d'OMP | valeur fictive `opencodex-loopback` |
+| Hermes | `~/.hermes/config.yaml` | YAML | dans les nouvelles sessions | `OPENCODEX_HERMES_API_KEY` |
+| OpenClaw | `~/.openclaw/openclaw.json` | JSON5 | immédiatement, sur une passerelle en cours d'exécution | `OPENCODEX_OPENCLAW_API_KEY` |
+| Kimi Code | `~/.kimi-code/config.toml` | TOML | au redémarrage ou avec `/reload` | valeur fictive de bouclage |
+| Gajae Code | `~/.gjc/agent/models.yml` | YAML | dans les nouvelles sessions ou à l'ouverture de `/model` |`OPENCODEX_GAJAE_API_KEY` |
+| DeepSeek Harness (DSH) | `$DSH_HOME/settings.yaml` (`~/.dsh/settings.yaml` par défaut) | YAML | rechargement à chaud | jeton porteur fictif et non secret pour le bouclage |
+| MiniMax Code | `~/.minimax/config.yaml` | YAML | dans les nouvelles sessions ou après l’ouverture du sélecteur de modèles | valeur fictive de bouclage |
+
+La prise en charge gérée de DSH exige au minimum **DSH 0.1.0-rc.6**. OpenCodex ne possède que le fragment
+`llm-pi-ai.providers.opencodex` : **Appliquer** et **Actualiser** remplacent ce fragment, **Désactiver** ne
+supprime que ce fragment, et **Restaurer** rétablit un instantané enregistré. DSH recharge à chaud les
+modifications de fournisseurs. Ces opérations ne changent ni le modèle par défaut de l'utilisateur ni le
+fournisseur natif `deepseek-official`. L'intégration DSH gérée est actuellement limitée au bouclage et
+n'écrit jamais de véritable identifiant.
+
+MiniMax Code recherche d’abord `MINIMAX_DATA_DIR`, puis `MAVIS_DATA_DIR`, avant de se rabattre sur
+`~/.minimax`. Son bloc géré ne possède que `custom_provider.opencodex`. Il ne modifie ni `defaultModel`, ni
+la source d’identification MiniMax sélectionnée, ni la connexion MiniMax de l’utilisateur. Après l’avoir
+connecté, choisissez dans MCode une entrée `custom_provider:opencodex/`.
+
+Les chemins respectent les variables de remplacement propres à chaque client, lorsqu'elles existent. Pour
+OMP, la présence de `OMP_PROFILE` l'emporte sur `PI_PROFILE`, même si sa valeur est explicitement vide. Un
+profil nommé emploie `PI_CONFIG_DIR` comme nom de répertoire relatif au dossier personnel de l'utilisateur
+et ignore `PI_CODING_AGENT_DIR` ; en l'absence de profil nommé, `PI_CODING_AGENT_DIR` l'emporte. OMP prend
+en charge les en-têtes au niveau du fournisseur, mais cette première intégration est volontairement limitée
+au bouclage ; la configuration distante de `x-opencodex-api-key` est reportée. Les chemins déplacés définis
+par `HERMES_HOME`, `KIMI_CODE_HOME` et `XDG_CONFIG_HOME` sont eux aussi suivis au lieu d'être devinés. Le
+tableau indique la valeur par défaut de chaque client.
+
+Pour les modèles OpenAI natifs, le bloc OMP généré sélectionne leur API Responses au niveau du modèle et
+préserve l'entrée d'images ainsi que les réglages de l'effort de raisonnement. Les modèles routés conservent
+le dialecte Chat Completions de leur fournisseur afin que leurs adaptateurs existants restent compatibles.
+
+OpenClaw possède plusieurs variables, aux rôles différents. `OPENCLAW_CONFIG_PATH` sélectionne le fichier ;
+`OPENCLAW_STATE_DIR`, `OPENCLAW_PROFILE` et `OPENCLAW_HOME` sélectionnent le répertoire d'état, sur lequel
+porte également la détection. Un profil ou un dossier personnel déplacé est donc toujours reconnu comme une
+installation, tandis qu'un remplacement du chemin de configuration ne déplace que le fichier. L'ancienne
+arborescence `.clawdbot` est elle aussi détectée : le répertoire moderne l'emporte lorsqu'il existe, et
+l'ancien n'est utilisé que s'il est le seul présent.
+
+Ces chemins doivent être **absolus** ou commencer par `~`. Un chemin relatif est refusé plutôt que résolu,
+car il désignerait le répertoire depuis lequel chaque processus aurait été lancé. Comme ce chemin est
+enregistré avec la sauvegarde, il doit désigner demain le même fichier qu'aujourd'hui.
+
+opencodex lit ces variables dans son propre environnement. Si votre passerelle utilise un profil ou un
+dossier personnel déplacé, lancez opencodex avec les mêmes variables ; sinon, il suivra correctement une
+autre installation.
+
+## Les quatre autres surfaces ne sont pas des commutateurs
+
+**Clés API** gère les propres identifiants d'opencodex et n'est donc pas un client. **Codex CLI** est relié
+par le service du proxy lui-même : démarrer opencodex applique ce routage et l'arrêter restaure le routage
+natif ; aucun fichier ne doit donc être activé ou désactivé séparément. **Claude** conserve son propre
+indicateur d'activation et le flux **Enregistrer/Appliquer** de Desktop, tandis que **Grok Build** conserve
+sa barrière « sélectionner, puis appliquer » pour les modèles. Ces règles sont antérieures à cette
+fonctionnalité et restent inchangées.
+
+## Restauration
+
+Avant chaque écriture réussie, un instantané de votre fichier est créé ; votre état antérieur reste donc
+toujours récupérable :
+
+- **Annuler** apparaît sur l'opération la plus récente lorsque votre fichier correspond toujours à ce qui a été écrit.
+- **Restaurer ce point…** apparaît sur les opérations plus anciennes, ou lorsque le fichier a changé depuis l'opération. Une restauration malgré une telle modification demande une deuxième confirmation avant de remplacer vos changements récents et les sauvegarde elle aussi, afin que la restauration puisse être annulée.
+- Dix sauvegardes sont conservées par client. Au-delà, les fichiers d'instantanés les plus anciens sont supprimés et leurs lignes d'historique affichent **Sauvegarde expirée**.
+
+La désactivation ne supprime que les entrées enregistrées par opencodex comme lui appartenant. Si votre
+fichier a changé après l'écriture, le comportement dépend de l'intégrité de ces entrées et du format du
+fichier. Pour les configurations JSON strictes (OpenCode et Pi), une modification **à côté** du bloc géré —
+par exemple l'ajout d'un serveur MCP ou de votre propre fournisseur — affiche **Mise à jour nécessaire** :
+l'actualisation fusionne les changements autour de vos entrées et les conserve, même si le formatage peut
+être normalisé. Font exception les valeurs que JSON ne peut pas réécrire exactement : un nombre non fini
+comme `1e999`, un nombre qu'une réécriture arrondirait (un très grand entier ou une valeur si petite qu'elle
+deviendrait zéro), `-0`, une même clé écrite deux fois dans un objet ou une imbrication de plus de 1000
+niveaux. Dans ces cas, le commutateur est verrouillé afin que rien ne soit modifié ou supprimé silencieusement.
+**OMP** n'est pas affecté non plus par les modifications voisines, mais pour une autre raison : son outil
+d'écriture ne modifie, octet par octet, que sa propre plage `providers.opencodex` ; le reste du fichier
+n'est jamais réécrit. Pour les autres formats susceptibles de contenir des commentaires (Hermes, OpenClaw,
+Kimi Code, Gajae Code et MiniMax Code — documents YAML, JSON5 et TOML réécrits en entier), ou lorsque les propres entrées
+d'opencodex ont été modifiées, le commutateur se verrouille et la désactivation est refusée plutôt que de
+deviner quelles modifications vous appartiennent.
+
+## À quoi s'attendre, en toute transparence
+
+**Le formatage n'est généralement pas préservé.** L'application analyse une configuration avant de la
+réécrire ; JSON, JSON5 et TOML peuvent donc être reformatés, et les commentaires JSON5 ou TOML sont perdus.
+OMP et DSH font exception : leurs outils d'écriture YAML ne modifient que `providers.opencodex` et
+`llm-pi-ai.providers.opencodex`, respectivement, tout en préservant octet par octet les commentaires et le
+formatage des fournisseurs sans rapport. Si la plage source exacte ne peut pas être identifiée de manière
+sûre, l'opération est refusée. Pour les autres clients, utilisez **Restaurer** lorsque vous avez besoin des
+octets précédents du fichier : l'instantané en est une copie exacte.
+
+**Si une valeur ne peut pas être réécrite fidèlement, le commutateur refuse l'opération.** L'aller-retour
+couvre les types de valeurs que ces formats emploient en pratique. Lorsqu'il ne le peut pas — par exemple
+pour un fichier TOML utilisant `inf` ou `nan`, que l'analyseur disponible ne peut relire avec exactitude —
+l'application s'arrête et le signale au lieu d'écrire une valeur modifiée en prétendant que l'opération a
+réussi. Le fichier concerné est indiqué et rien n'est déplacé sur le disque. Vous pouvez toujours modifier
+ce fichier manuellement ; seule la réécriture automatique est refusée.
+
+**Pi, Kimi Code, Gajae Code, MiniMax Code et l'intégration DSH gérée fonctionnent uniquement avec une adresse de
+bouclage.** Les quatre premiers n'ont aucun champ de configuration pour l'en-tête `x-opencodex-api-key`
+qu'exige une liaison hors bouclage. DSH possède une table d'en-têtes générique, mais rc.6 ne documente pas
+cet en-tête d'admission dédié comme contrat d'intégration pris en charge ; l'outil d'écriture géré échoue
+donc de façon fermée plutôt que d'improviser. Donnez-leur accès au bouclage par un tunnel SSH ou par un
+relais local qui ajoute l'en-tête.
+
+**L'intégration OMP générée est elle aussi volontairement limitée au bouclage.** OMP prend en charge les
+en-têtes au niveau du fournisseur, mais cette première intégration n'écrit pas les identifiants distants
+`x-opencodex-api-key`. Pour l'instant, la configuration manuelle d'OMP à distance sort du périmètre de
+l'intégration gérée.
+
+**Kimi Code ne peut pas contenir de référence à une variable d'environnement** ; sa configuration reçoit
+donc la valeur fictive `opencodex-loopback` plutôt qu'une clé. Aucun véritable identifiant n'est écrit dans
+une configuration cliente.
+
+**Pour `ocx opencode`, le bloc fournisseur du lanceur l'emporte.** Le lanceur injecte
+`provider.opencodex` par `OPENCODE_CONFIG_CONTENT`, qui est prioritaire sur la même entrée enregistrée sur
+le disque ; le reste de votre configuration opencode continue de s'appliquer normalement. Le commutateur
+décrit ici est celui qui compte lorsque vous lancez directement `opencode`.
+
+## Depuis le terminal
+
+Les mêmes opérations sont disponibles sans interface graphique :
+
+```bash
+ocx integration client status
+ocx integration client enable --client hermes
+ocx integration client disable --client hermes
+ocx integration client history --client hermes
+ocx integration client restore --op [--confirm-drift]
+```
+
+Pour MiniMax Code, connectez une fois le fournisseur puis utilisez l’enveloppe qui vérifie la connexion :
+
+```bash
+ocx integration client enable --client mcode
+ocx mcode
+```
+
+Le CLI distinct de la plateforme MiniMax (`mmx`) n’est pas une intégration à commutateur de fichier. Ses
+commandes textuelles utilisent le point de terminaison compatible avec Anthropic de MiniMax ; OpenCodex
+fournit donc un lanceur isolant les identifiants et limité à l’adresse locale :
+
+```bash
+ocx mmx text chat --model anthropic/claude-opus-5 --message "Hello"
+ocx mmx text repl --model openai/gpt-5.6-sol
+```
+
+Seules les commandes `mmx text chat` et `mmx text repl` passent par le proxy. Utilisez directement `mmx`
+pour les commandes MiniMax natives d’image, de vidéo, de parole, de musique, de vision, de recherche, de
+quota, d’authentification, de configuration, de fichier et de mise à jour. L’enveloppe emploie une
+configuration temporaire qui ne contient qu’une valeur fictive locale et non secrète ; elle ne charge
+jamais les identifiants OAuth ou de clé d’API de `~/.mmx`, et refuse les remplacements `--api-key`,
+`--base-url` et `--region`. Consultez [Clients MiniMax](/fr/guides/minimax/) pour connaître le flux complet
+et ses limites.
+
+`--confirm-drift` n'est jamais présumé. Si le fichier a changé depuis l'opération que vous restaurez, la
+commande refuse et vous l'indique : remplacer vos modifications plus récentes relève de votre décision.
+
+Les détails des clients ont été vérifiés par rapport au format de configuration propre à chaque projet ;
+consultez les notes de recherche dans
+`devlog/_fin/260802_client_toggle_api/002_client_toggle_matrix.md` pour savoir ce qui a été contrôlé et quand.
diff --git a/docs-site/src/content/docs/fr/guides/minimax.md b/docs-site/src/content/docs/fr/guides/minimax.md
new file mode 100644
index 0000000000..22f301d01e
--- /dev/null
+++ b/docs-site/src/content/docs/fr/guides/minimax.md
@@ -0,0 +1,84 @@
+---
+title: Clients MiniMax
+description: Routez les commandes textuelles de MiniMax Code et MiniMax CLI par OpenCodex sans exposer les identifiants MiniMax.
+---
+
+MiniMax publie deux produits distincts en ligne de commande. OpenCodex intègre chacun à la frontière du protocole qu’il expose réellement :
+
+- **MiniMax Code** (`mcode`) est un agent de programmation prenant en charge les fournisseurs Anthropic Messages personnalisés.
+- **MiniMax CLI** (`mmx`) est un CLI de plateforme multimodale. Seule sa ressource `text` utilise l’API compatible avec Anthropic qu’OpenCodex peut router.
+
+## MiniMax Code
+
+Installez MiniMax Code et connectez-vous d’abord en suivant les instructions de MiniMax. Démarrez ensuite OpenCodex et activez l’intégration de fichier réversible :
+
+```bash
+ocx start
+ocx integration client enable --client mcode
+ocx mcode
+```
+
+
+
+L’intégration fusionne un bloc dans `~/.minimax/config.yaml` :
+
+```yaml
+custom_provider:
+ opencodex:
+ name: OpenCodex
+ kind: custom
+ enabled: true
+ api: anthropic-messages
+ options:
+ apiKey: opencodex-loopback
+ baseURL: http://127.0.0.1:10100
+ authMode: api-key
+ models:
+ anthropic/claude-opus-5: {}
+```
+
+La liste de modèles réellement générée provient du catalogue OpenCodex actif. Le bloc n’écrit aucune clé réelle, ne remplace pas `defaultModel` et ne modifie pas votre connexion MiniMax. Dans MCode, choisissez un modèle sous `custom_provider:opencodex/...`.
+
+`ocx mcode` vérifie que ce fournisseur pointe vers le proxy actuellement actif avant de lancer le client. Si le port a changé, actualisez le bloc géré en relançant la commande d’activation. Désactivez-le ou restaurez-le au moyen du même système d’intégration audité :
+
+```bash
+ocx integration client disable --client mcode
+ocx integration client history --client mcode
+ocx integration client restore --op [--confirm-drift]
+```
+
+`MINIMAX_DATA_DIR` et l’ancienne variable `MAVIS_DATA_DIR` sont prises en charge. Les chemins relatifs sont refusés, car OpenCodex et MCode peuvent démarrer depuis des répertoires de travail différents.
+
+## MiniMax CLI (`mmx`)
+
+Installez séparément le CLI officiel :
+
+```bash
+npm install -g mmx-cli
+mmx --version
+```
+
+Routez une commande textuelle par OpenCodex en utilisant l’enveloppe et un identifiant de modèle OpenCodex :
+
+```bash
+ocx mmx text chat \
+ --model anthropic/claude-opus-5 \
+ --message "Explain this function"
+
+ocx mmx --output json text chat \
+ --model openai/gpt-5.6-sol \
+ --message "Return a JSON summary"
+```
+
+MMX ajoute systématiquement `/anthropic/v1/messages` à son URL de base d’API. L’enveloppe démarre un pont local temporaire pendant la durée du processus enfant. Celui-ci accepte uniquement les requêtes POST vers ce chemin Messages et vers `/anthropic/v1/messages/count_tokens`, puis les associe aux plans de données `/v1/messages` et `/v1/messages/count_tokens` existants d’OpenCodex tout en préservant le corps et les paramètres des requêtes. La traduction canonique des requêtes OpenCodex, le suivi de l’utilisation et l’authentification configurée des fournisseurs en aval restent actifs ; les fournisseurs reçoivent `x-api-key` ou un jeton porteur selon leur configuration. La diffusion conserve les événements Anthropic de message et de contenu. Avant le transfert, le pont retire les en-têtes d’identification d’admission entrants et fixe la valeur publique temporaire `opencodex-loopback`. Aucune autre ressource Anthropic n’est transmise et le pont n’est jamais exposé au-delà de l’adresse locale.
+
+L’enveloppe crée également un `MMX_CONFIG_DIR` temporaire qui ne contient que cette valeur publique, puis le supprime à la fermeture de `mmx`. Votre fichier `~/.mmx/config.json`, vos jetons OAuth et votre clé d’API MiniMax ne sont jamais chargés ni copiés.
+
+Les limites suivantes sont intentionnelles :
+
+- Seules les commandes `text chat` et `text repl` sont routées par OpenCodex.
+- L’enveloppe refuse `--api-key`, `--base-url` et `--region` afin que les identifiants ou les destinations fournis par l’appelant n’entrent pas en conflit avec le pont isolé.
+- Le pont est limité à l’adresse locale, car MMX ne peut pas envoyer l’en-tête d’admission dédié `x-opencodex-api-key` d’OpenCodex pour une liaison distante.
+- Utilisez directement `mmx` pour `image`, `video`, `speech`, `music`, `vision`, `search`, `quota`, `auth`, `config`, `file` et `update` ; ces ressources appellent des API propres à MiniMax qu’OpenCodex n’émule pas.
+
+Le modèle textuel par défaut de `mmx` est `MiniMax-M3`. Fournissez `--model ` pour cibler une route OpenCodex précise ; sinon, les règles normales de routage des modèles OpenCodex déterminent si l’identifiant par défaut est disponible.
diff --git a/docs-site/src/content/docs/fr/guides/model-ordering.md b/docs-site/src/content/docs/fr/guides/model-ordering.md
new file mode 100644
index 0000000000..cac2b0667c
--- /dev/null
+++ b/docs-site/src/content/docs/fr/guides/model-ordering.md
@@ -0,0 +1,144 @@
+---
+title: Ordre des modèles
+description: Découvrez comment opencodex détermine l’ordre des modèles dans le sélecteur Codex et les substitutions de modèle de spawn_agent.
+---
+
+Le sélecteur de modèles Codex ne conserve ni l’ordre de déclaration des fournisseurs ni celui des tableaux de modèles dans la
+configuration opencodex. L’ordre final découle des priorités du catalogue ; les modèles routés qui partagent la même priorité
+sont classés selon un ordre alphabétique déterministe.
+
+## La règle Codex s'applique
+
+Le gestionnaire de modèles de Codex trie les entrées de catalogue visibles dans le sélecteur par `priority`, dans l’ordre croissant. Il
+ignore l’ordre du tableau du catalogue : avancer une entrée dans un tableau JSON généré ne la fait donc pas remonter
+dans le sélecteur. L’implémentation consigne cette contrainte directement dans
+`src/codex/catalog/sync.ts`.
+
+opencodex contrôle donc la mise en avant en attribuant des priorités plus faibles, et non en s’appuyant sur la
+position dans le tableau. Sauf indication contraire, les priorités fixes et l’exemple détaillé ci-dessous décrivent un
+catalogue sans sélecteur de compte Codex admissible. Avec `N` sélecteurs admissibles, les priorités mises en avant
+utilisent `N` comme pas : un choix natif non qualifié de rang configuré `i` se décline en lignes de sélecteur aux
+priorités `i * N + j`, où `j` est la position du sélecteur en base zéro ; un choix routé utilise
+`i * N` ; un choix exact qualifié par un sélecteur utilise `i * N + j` pour ce sélecteur. Les lignes routées non sélectionnées
+sont déplacées hors de ces groupes de sélecteurs. Codex continue de n’annoncer que les cinq premières
+lignes visibles dans le sélecteur.
+
+Les priorités sans sélecteur pertinentes sont :
+
+| Entrée du catalogue | Priorité | Source |
+| --- | --- : | --- |
+| `subagentModels[i]` | `i` (`0` à `4`) | La carte de classement présentée dans `src/codex/catalog/sync.ts` |
+| Autres modèles acheminés | `5` | Création d'une entrée routé dans `src/codex/catalog/sync.ts` |
+| Modèles routés non mis en avant et présents dans `modelPickerOrder` | `1000 + i` | Rang d’affichage du sélecteur dans `src/codex/catalog/sync.ts` |
+| Slugs GPT natifs par défaut | `9` | Création d'entrées natives dans `src/codex/catalog/sync.ts` |
+| Modèles natifs non sélectionnés alors qu'une liste sélectionnée existe | Au moins `featured.length + 100` | Fusion du catalogue natif dans `src/codex/catalog/sync.ts` |
+
+La direction API limite `subagentModels` à cinq entrées avec `slice(0, 5)` en
+`src/server/management/agent-settings-routes.ts`. Cela correspond à la surface Codex `spawn_agent`, qui
+annonce uniquement les cinq premiers remplacements de modèle. Les modèles en dehors de ces cinq peuvent toujours rester visibles
+dans le sélecteur principal et appelables par leur identifiant exact.
+
+## Départage des priorités identiques
+
+Tous les modèles routés ordinaires ont la priorité `5` ; il faut donc les départager. Avant la création des entrées du catalogue,
+`gatherRoutedModels()` trie la liste des modèles routés par nom de fournisseur, puis par identifiant de modèle, dans les deux cas
+par ordre alphabétique (`src/codex/catalog/provider-fetch.ts`).
+
+Cela signifie qu'aucun de ces détails de configuration ne modifie l'ordre final :
+
+- l'ordre de déclaration des clés dans l'objet `providers` ;
+- l'ordre des identifiants dans le tableau `models` d'un fournisseur.
+
+`orderForSubagents()` utilise ensuite un tri stable pour placer les choix mis en avant au début de la liste, dans le
+même ordre que `subagentModels`. Les modèles non mis en avant conservent l’ordre relatif alphabétique fournisseur/identifiant
+établi précédemment (`src/codex/catalog/sync.ts`). Le classement présenté est également converti en
+priorités `0` à `4` lorsque les entrées sont construites, donc le tri prioritaire de Codex préserve ce premier
+séquence.
+
+## La visibilité est distincte de l’ordre
+
+`selectedModels` et `disabledModels` déterminent quels modèles routés sont exposés ; ils ne contrôlent pas
+leur ordre. `filterCatalogVisibleModels()` convertit les deux sélections en recherches dans des `Set` et filtre la
+liste recueillie sans utiliser les tableaux comme rangs (`src/codex/catalog/provider-fetch.ts`).
+
+Par conséquent, la réorganisation de `selectedModels` ou `disabledModels` n’a aucun effet sur la position du sélecteur. Cela peut
+change uniquement si un modèle est inclus.
+
+## Ordre effectif du sélecteur
+
+Sans sélecteur de compte éligible et sans liste de sélection non vide, l'ordre résultant est le suivant :
+
+1. Modèles dans l'ordre `subagentModels` configuré exactement, avec des priorités `0` à `4`.
+2. Tous les modèles acheminés restants, classés par ordre alphabétique par fournisseur, puis par identifiant de modèle, en priorité `5`.
+3. Modèles natifs non sélectionnés, poussés sous le bloc sélectionné lors de la fusion du catalogue.
+
+Sans `subagentModels`, les modèles routés restent en priorité `5`, les entrées natives GPT utilisent leur
+priorité (normalement `9` pour les entrées construites par opencodex), et le groupe routé reste provider/id
+alphabétique.
+
+## Exemple
+
+Supposons que `subagentModels` contienne ces cinq identifiants dans cet ordre exact :
+
+```toml
+subagentModels = [
+ "gpt-5.5",
+ "opencode-go/glm-5.2",
+ "anthropic/claude-opus-4-6",
+ "gpt-5.6-sol",
+ "gpt-5.6-terra",
+]
+```
+
+Le sélecteur commence ainsi :
+
+| Position dans le sélecteur | Modèle | Priorité | Motif de cette position |
+| --- : | --- | --- : | --- |
+| 1 | `gpt-5.5` | `0` | Première sélection `subagentModels` |
+| 2 | `opencode-go/glm-5.2` | `1` | Deuxième sélection, même si son fournisseur trie après `anthropic` |
+| 3 | `anthropic/claude-opus-4-6` | `2` | Troisième sélection |
+| 4 | `gpt-5.6-sol` | `3` | Quatrième sélection |
+| 5 | `gpt-5.6-terra` | `4` | Cinquième sélection |
+| 6 | `anthropic/claude-fable-5` | `5` | Premier identifiant routé restant dans l’ordre alphabétique fournisseur/identifiant |
+| 7 en avant | Modèles acheminés restants | `5` | Fournisseur par ordre alphabétique, puis identifiant du modèle par ordre alphabétique |
+| Après les modèles routés | Modèles natifs restants | `featured.length + 100` ou supérieur | Les modèles natifs non sélectionnés sont déplacés sous le bloc mis en avant |
+
+Les cinq premières entrées sont les substitutions annoncées à `spawn_agent` ; les autres suivent l’ordre
+normal du sélecteur. Avec des sélecteurs de compte, la limite de cinq entrées s’applique après que les choix natifs non qualifiés
+ont été déclinés en groupes qualifiés par sélecteur.
+
+## Modification de l'ordre
+
+Utilisez `subagentModels` pour choisir et ordonner les premiers modèles que Codex annonce également à
+`spawn_agent`. La page **Sous-agents** du tableau de bord peut réorganiser les identifiants natifs non
+qualifiés et les identifiants routés. Utilisez `ocx agent subagents set` ou modifiez la configuration
+OpenCodex pour définir des choix exacts de la forme `/` ; le tableau de bord
+ne les répertorie pas et les omet s’il enregistre la liste. Configurez au maximum cinq identifiants. Avec
+des sélecteurs de compte, un choix natif non qualifié peut se décliner en plusieurs lignes de catalogue
+qualifiées par sélecteur ; les choix configurés et les lignes annoncées ne correspondent donc pas
+nécessairement un à un.
+
+Utilisez `modelPickerOrder` pour ordonner uniquement l’affichage des lignes routées `/`
+au-delà de ce bloc mis en avant :
+
+```json
+{
+ "modelPickerOrder": [
+ "tyler/deepseek-v4-pro",
+ "jd-chat/kimi-k3",
+ "jd-chat/glm-5.2"
+ ]
+}
+```
+
+Les lignes routées indiquées apparaissent dans l’ordre configuré. Une ligne absente du tableau conserve sa
+priorité normale et reste donc devant la bande d’affichage de `modelPickerOrder` ; indiquez toutes les
+lignes routées dont vous souhaitez contrôler l’ordre relatif. Une ligne également présente dans
+`subagentModels` conserve sa priorité de mise en avant. `modelPickerOrder` ne réorganise ni les lignes
+natives non qualifiées ni celles qualifiées par un compte ; utilisez `subagentModels` pour celles-ci.
+
+`modelPickerOrder` ne modifie jamais l’ensemble des candidats de `spawn_agent`. Il change uniquement la
+priorité visible par Codex dans le sélecteur, tandis qu’OpenCodex conserve la priorité naturelle de chaque
+ligne déplacée pour la sélection des sous-agents. `disabledModels` et `selectedModels` de chaque fournisseur
+restent des champs de visibilité, pas des contrôles d’ordre. Il n’existe aucun paramètre distinct
+`modelOrder`, `providerOrder` ou de carte de priorité.
diff --git a/docs-site/src/content/docs/fr/guides/model-routing.md b/docs-site/src/content/docs/fr/guides/model-routing.md
new file mode 100644
index 0000000000..927d2ef863
--- /dev/null
+++ b/docs-site/src/content/docs/fr/guides/model-routing.md
@@ -0,0 +1,123 @@
+---
+title: Routage des modèles
+description: Comment opencodex détermine quel fournisseur sert un identifiant de modèle donné.
+---
+
+Lorsque Codex demande un modèle, `router.ts` le résout vers un unique fournisseur configuré. Les règles
+sont évaluées **dans l'ordre** : la première correspondance l'emporte.
+
+Pour OpenAI, un identifiant `/gpt-*` configuré est associé, par l'intermédiaire de
+`codexAccountNamespaces`, à un unique compte Codex enregistré avant l'examen des espaces de noms de
+combinaisons ou de fournisseurs. Les identifiants `gpt-*` non qualifiés sélectionnent plutôt le fournisseur
+canonique `openai`. Son paramètre `codexAccountMode` choisit le mode Pool (par défaut, compte principal et
+comptes ajoutés) ou Direct (jeton du compte appelant/principal actuel), sans modifier l'identifiant du modèle.
+`openai-apikey/` sélectionne explicitement le transport par clé API. Ces routes d'identification ne se
+rabattent jamais les unes sur les autres.
+
+## Ordre de priorité
+
+1. **Sélecteur exact de compte Codex** — si l'identifiant est
+ `/` et que le sélecteur figure dans `codexAccountNamespaces`,
+ la requête utilise exclusivement le compte enregistré correspondant et envoie en amont l'identifiant
+ non qualifié du modèle natif. Si la cible exacte n'est pas disponible, la requête échoue sans tenter le
+ mode Pool, le mode Direct ni le routage par fournisseur.
+
+ ```text
+ side/gpt-5.6-sol → provider "openai", model "gpt-5.6-sol", account selector "side"
+ ```
+
+2. **Identifiant ou alias de combinaison** — tant qu'au moins une combinaison est configurée, un identifiant
+ canonique `combo/` ou un alias de combinaison configuré sélectionne sa cible concrète avant l'examen
+ des espaces de noms de fournisseurs. En l'absence de combinaison configurée, un ancien fournisseur physique
+ nommé littéralement `combo` reste un espace de noms de fournisseur ordinaire. Consultez
+ [Combinaisons](/fr/guides/combos/) pour le choix de la cible et le comportement de basculement.
+
+3. **`provider/model` explicite** — si l'identifiant contient `/` et que sa partie antérieure correspond au
+ nom d'un fournisseur configuré, ce fournisseur est utilisé et l'identifiant est réduit à la partie située
+ après la barre oblique.
+
+ ```text
+ anthropic/claude-opus-5 → provider "anthropic", model "claude-opus-5"
+ ollama-cloud/glm-5.2 → provider "ollama-cloud", model "glm-5.2"
+ openrouter/openai/gpt-5.6-sol → provider "openrouter", model "openai/gpt-5.6-sol"
+ ```
+
+ Il s'agit de la forme explicite pour un fournisseur routé, celle qu'emploie le sélecteur de modèles de
+ Codex. Si le même identifiant public est un alias de combinaison configuré, la règle 2 l'emporte. Si le
+ fournisseur nommé est désactivé, cette forme explicite provoque une erreur au lieu d'être redirigée.
+
+4. **Identifiant non qualifié de la famille OpenAI native** — un identifiant tel que `gpt-*`, `o1-*`, `o3-*`
+ ou `o4-*` utilise le fournisseur canonique `openai` activé et son mode de compte Pool ou Direct configuré.
+
+5. **`defaultModel` d'un fournisseur** — si le champ `defaultModel` d'un fournisseur correspond à
+ l'identifiant, ce fournisseur est utilisé (l'identifiant lui est transmis sans modification).
+
+6. **Motifs de préfixes intégrés** — l'identifiant est comparé aux préfixes connus des familles de modèles,
+ puis acheminé vers un fournisseur configuré portant ce nom (ou ce préfixe de nom) :
+
+ | Préfixes | Fournisseur |
+ | --- | --- |
+ | `claude-`, `claude-sonnet-`, `claude-opus-`, `claude-haiku-` | `anthropic` |
+ | `llama-`, `mixtral-`, `gemma-` | `groq` |
+
+ Cette correspondance repose sur le nom et, contrairement aux recherches dans `defaultModel` et `models[]`,
+ ne filtre actuellement pas un fournisseur correspondant dont l'indicateur `disabled` vaut true.
+
+7. **`models[]` d'un fournisseur** — si aucune règle de préfixe ne s'est appliquée et qu'un fournisseur actif
+ répertorie l'identifiant dans son tableau `models[]`, ce fournisseur est utilisé. La règle 4 a déjà acheminé
+ tout identifiant `gpt-*` non qualifié vers le fournisseur canonique `openai` activé avant qu'il puisse
+ correspondre au tableau `models[]` d'un autre fournisseur.
+
+8. **Fournisseur par défaut** — si aucune règle ne correspond, l'identifiant est transmis sans modification à
+ `config.defaultProvider`. (Si aucun fournisseur par défaut n'est configuré, ou s'il est désactivé, le routage
+ provoque une erreur.)
+
+## Clés API et variables d'environnement
+
+Quelle que soit la route choisie, la valeur `apiKey` du fournisseur est résolue par `resolveEnvValue()` : une
+valeur `${OPENAI_API_KEY}` ou `$OPENAI_API_KEY` est développée depuis l'environnement au moment de la requête,
+de sorte que les secrets n'ont jamais besoin d'être enregistrés dans `config.json`.
+
+## Visibilité dans le catalogue et plafonds de contexte
+
+Le routage et la visibilité dans le catalogue sont deux mécanismes distincts :
+
+- `disabledModels` masque les identifiants routés avec espace de noms dans le catalogue Codex et
+ `/v1/models` ; l'identifiant non qualifié d'un modèle GPT natif reste dans le catalogue avec
+ `visibility: "hide"`. Ce réglage ne rejette **pas** une requête directe adressée à ce modèle.
+- Une liste `selectedModels` non vide sur un fournisseur constitue une autre liste d'autorisation du catalogue.
+ La découverte dynamique et le routage direct continuent de fonctionner ; seules les publications dans le
+ catalogue et `/v1/models` sont restreintes.
+- `provider.disabled: true` retire ce fournisseur de la découverte du catalogue. Les requêtes explicites
+ `provider/model` échouent, et les recherches dans `defaultModel` et `models[]` l'ignorent.
+- `providerContextCaps` applique des plafonds de contexte visibles par Codex, fournisseur par fournisseur.
+ `contextCapValue` est la valeur par défaut du tableau de bord (350 000 par défaut), mais n'a aucun effet à
+ lui seul tant qu'un fournisseur ne figure pas dans `providerContextCaps`. La modification de la valeur dans
+ le tableau de bord réaffecte tous les fournisseurs activés uniquement lorsque l'option « appliquer à tous les
+ fournisseurs routés » est activée ; sinon, chaque fournisseur conserve son propre plafond. Un plafond peut
+ seulement réduire une fenêtre de contexte connue : il ne peut ni l'augmenter ni modifier la limite réelle du
+ modèle en amont.
+
+```json
+{
+ "contextCapValue": 350000,
+ "providerContextCaps": {
+ "anthropic": 350000,
+ "cursor": 350000
+ }
+}
+```
+
+## Conseils
+
+- **Ciblez explicitement un compte Codex** avec `/` (règle 1). Cette route est
+ exacte et échoue de façon fermée ; elle ne bascule jamais silencieusement vers un autre compte.
+- **Soyez explicite pour les modèles routés.** Préférez `provider/model` (règle 3) lorsque cet identifiant public
+ exact n'est pas un alias de combinaison. Il nomme directement le fournisseur et correspond à ce que Codex
+ affiche dans son sélecteur après la synchronisation du catalogue.
+- **Renseignez `models[]` ou `defaultModel`** sur un fournisseur afin que les identifiants courts (règles 5 et 7)
+ soient résolus sans le préfixe `provider/`.
+- **Les motifs de préfixes sont pratiques, mais ne constituent pas une garantie** : ils ne sont résolus que si
+ un fournisseur portant ce nom (par exemple `anthropic` ou `groq`) est effectivement configuré.
+
+Consultez [Configuration](/fr/reference/configuration/) pour connaître les champs de fournisseur lus par ces règles.
diff --git a/docs-site/src/content/docs/fr/guides/opencode.md b/docs-site/src/content/docs/fr/guides/opencode.md
new file mode 100644
index 0000000000..37530f2c96
--- /dev/null
+++ b/docs-site/src/content/docs/fr/guides/opencode.md
@@ -0,0 +1,148 @@
+---
+title: opencode
+description: Utilisez n’importe quel modèle routé depuis opencode — opencodex injecte un bloc de fournisseur à l’exécution sans modifier votre propre configuration opencode.
+---
+
+opencode lit ses fournisseurs dans des couches de configuration JSON fusionnées plutôt que dans des variables
+d’environnement ; il n’existe donc aucun emplacement de type `ANTHROPIC_BASE_URL` dans lequel injecter une valeur. `ocx opencode`
+comble cette lacune : il s’assure que le proxy fonctionne, crée un bloc fournisseur à partir du
+catalogue visible, puis l’injecte au moyen de la couche d’exécution en ligne d’OpenCode
+(`OPENCODE_CONFIG_CONTENT`).
+
+## Démarrage rapide
+
+```bash
+ocx opencode
+```
+
+Cette commande s’assure que le proxy fonctionne et lance opencode en injectant uniquement le bloc
+`provider.opencodex` généré pour ce processus. Les arguments supplémentaires sont transmis tels quels :
+`ocx opencode run "hello"`.
+
+Les modèles acheminés apparaissent dans le sélecteur sous le fournisseur `opencodex` :
+
+```text
+opencodex/kiro/glm-5
+opencodex/gpt-5.6-sol # native slugs stay unprefixed
+```
+
+## Votre propre configuration n'est jamais modifiée
+
+Le lanceur ne copie ni ne réécrit `~/.config/opencode/opencode.json`,
+les fichiers de projet `opencode.json` / `opencode.jsonc`, ni aucune autre couche de configuration sur disque. Il peut
+lire la configuration globale ou celle du projet afin de détecter une redéfinition de `provider.opencodex`, tandis que vos
+fournisseurs, agents, raccourcis clavier, entrées MCP et références relatives `{file:…}` existants
+continuent d’être résolus depuis leurs fichiers d’origine.
+
+Pour ce lancement uniquement, opencodex ajoute le bloc `provider.opencodex` généré via
+la couche d’exécution en ligne d’OpenCode. Cette couche est fusionnée après les configurations globale, personnalisée et de projet,
+et ne remplace que les clés en conflit pour le processus enfant.
+
+| Couche | Comportement avec `ocx opencode` |
+| --- | --- |
+| Configuration globale/personnalisée/de projet | Conservée sur disque exactement telle que vous l’avez écrite |
+| Exécution en ligne (`OPENCODE_CONFIG_CONTENT`) | Reçoit uniquement le bloc `provider.opencodex` généré |
+| Chemins relatifs `{file:…}` | Toujours résolus par rapport au fichier de configuration qui les a définis à l’origine |
+
+Si une configuration globale ou de projet définit également `provider.opencodex`, le lanceur affiche une
+note d’information : la couche d’exécution de `ocx opencode` la remplace pour ce lancement.
+
+## Ajouter le bloc à votre propre configuration
+
+`ocx opencode` injecte le bloc fournisseur pour un seul lancement, ce qui signifie simplement `opencode` toujours
+ne sait rien du proxy. Lorsque vous souhaitez que les modèles acheminés soient disponibles à partir de `opencode` — ou
+depuis une extension d'éditeur qui ne passe jamais par le lanceur — `ocx export` imprime la même chose
+bloc fournisseur à fusionner dans votre propre configuration :
+
+```bash
+ocx export --client opencode
+```
+
+Le proxy doit être en cours d'exécution. La commande imprime la config, la destination canonique
+(`~/.config/opencode/opencode.json`, ou sous `XDG_CONFIG_HOME` lorsque cela est défini), la fusion
+avertissement et la ligne d'exportation env. Il ne touche jamais à ce fichier — la section ci-dessus reste vraie, et
+déplacer le bloc dans votre configuration est votre acte explicite.
+
+:::caution[Fusionnez, ne remplacez jamais]
+Fusionnez le bloc `provider.opencodex` dans votre configuration existante. Remplacer tout le fichier par le
+celui exporté détruit vos autres fournisseurs, agents, raccourcis clavier et entrées MCP. `ocx export --out`
+refuse d'écraser un fichier existant exactement pour cette raison, alors pointez `--out` sur un chemin de travail
+et copiez le bloc sur :
+
+```bash
+ocx export --client opencode --out ~/opencodex-opencode.json
+```
+:::
+
+Contrairement au bloc d'exécution du lanceur, un bloc fusionné est un instantané statique : il ne suit pas votre
+catalogue. Réexécutez `ocx export` après avoir ajouté un fournisseur ou modifié la visibilité du modèle.
+
+Une fois fusionné, exportez la clé d'admission avant de lancer l'opencode — sauf si le proxy est en bouclage,
+là où aucun n'est nécessaire :
+
+```bash
+export OPENCODEX_OPENCODE_API_KEY=
+```
+
+## La clé d’admission n’est pas écrite sur disque
+
+La configuration enregistre la référence `{env:OPENCODEX_OPENCODE_API_KEY}`, jamais le secret lui-même.
+Sur une liaison de bouclage, cette référence est utilisée comme valeur `apiKey`. Sur une liaison hors
+bouclage, OpenCode résout la variable et n’envoie sa valeur que dans `x-opencodex-api-key`, afin que
+l’admission au proxy reste distincte de tout en-tête `Authorization` destiné au fournisseur en amont.
+
+Exemple de bouclage :
+
+```json
+"options": {
+ "baseURL": "http://127.0.0.1:10100/v1",
+ "apiKey": "{env:OPENCODEX_OPENCODE_API_KEY}"
+}
+```
+
+Exemple sans bouclage :
+
+```json
+"options": {
+ "baseURL": "http://192.168.1.10:10100/v1",
+ "headers": {
+ "x-opencodex-api-key": "{env:OPENCODEX_OPENCODE_API_KEY}"
+ }
+}
+```
+
+La valeur réelle est transmise uniquement via l'environnement du processus enfant.
+`OPENCODEX_API_AUTH_TOKEN` est prioritaire, puis le fichier de jeton de service renforcé, puis
+une clé API configurée — ce qui est ce qu'exige une liaison sans bouclage.
+
+Une liaison de bouclage (`127.0.0.1`, la valeur par défaut) n'authentifie rien, donc la référence `{env:…}` est
+inerte et vous pouvez laisser la variable non définie. Cela n'a d'importance que lorsque `hostname` est défini au-delà du bouclage ;
+voir [Accès à distance](/fr/reference/configuration/server/#accès-à-distance). Cette clé d'admission est celle de opencodex
+propre et n'est pas lié aux clés du fournisseur en amont configurées sous
+[Prestataires](/fr/guides/providers/).
+
+## Rétablissement
+
+Rien à annuler — aucun fichier de configuration généré n'est écrit sous `~/.opencodex`. Courez simplement
+`opencode` et il lit votre propre configuration exactement comme avant.
+
+## Limites du modèle
+
+`limit.context` n’est écrit que lorsque le catalogue fournit une fenêtre de contexte faisant autorité. Dans le cas
+contraire, le bloc `limit` entier est omis et opencode conserve ses propres valeurs par défaut.
+
+Le schéma d’opencode rejette un bloc `limit` qui contient `context` sans `output`. Comme le catalogue ne fournit
+aucune limite de sortie faisant autorité par modèle, opencodex émet également un budget `output` de `32000`, limité
+à la fenêtre de contexte afin qu’un modèle à petit contexte ne reçoive jamais `output > context`. Cette valeur sert
+uniquement à satisfaire le schéma ; elle ne prétend pas représenter la véritable limite d’un modèle particulier.
+
+Le bloc fournisseur `opencodex` est régénéré à chaque lancement, donc des ajustements par modèle y sont apportés
+ne survivra pas. Conservez plutôt les entrées personnalisées sous votre propre clé de fournisseur.
+
+## Exigences
+
+opencode doit être installé et sur `PATH` :
+
+```bash
+npm install -g opencode-ai
+```
diff --git a/docs-site/src/content/docs/fr/guides/pi.md b/docs-site/src/content/docs/fr/guides/pi.md
new file mode 100644
index 0000000000..eab8960063
--- /dev/null
+++ b/docs-site/src/content/docs/fr/guides/pi.md
@@ -0,0 +1,140 @@
+---
+title: Pi
+description: Utilisez n’importe quel modèle routé depuis Pi — ocx export produit un bloc de fournisseur personnalisé pour le fichier models.json de Pi, relié au proxy en cours d’exécution.
+---
+
+Pi lit ses fournisseurs dans un fichier JSON global unique plutôt que dans des variables d’environnement ;
+opencodex ne lance donc pas Pi. À la place, `ocx export` sérialise le bloc du fournisseur `opencodex` —
+URL de base, liste des modèles et référence de variable d’environnement interpolée par Pi — que vous fusionnez ensuite dans votre
+propre configuration.
+
+## Démarrage rapide
+
+Démarrez le proxy, puis imprimez la configuration :
+
+```bash
+ocx start
+ocx export --client pi
+```
+
+La sortie commence par le JSON, puis affiche le chemin de destination, l’avertissement de fusion, la ligne
+d’exportation de la variable d’environnement et le nombre de modèles dotés de limites de contexte faisant autorité.
+
+```json
+{
+ "providers": {
+ "opencodex": {
+ "baseUrl": "http://127.0.0.1:10100/v1",
+ "api": "openai-completions",
+ "apiKey": "$OPENCODEX_API_KEY",
+ "models": [
+ {
+ "id": "anthropic/claude-opus-5",
+ "name": "Claude Opus 5 (anthropic)",
+ "input": ["text"],
+ "contextWindow": 200000,
+ "maxTokens": 32000
+ }
+ ]
+ }
+ }
+}
+```
+
+Les identifiants de modèle sont les sélecteurs canoniques du proxy : les modèles routés apparaissent donc sous la forme `provider/model`
+(`anthropic/claude-opus-5`) et les slugs natifs OpenAI restent sans préfixe (`gpt-5.6-sol`). Le `name`
+suffixe — `(anthropic)`, `(native)`, `(routed)` — permet de distinguer, dans le sélecteur de Pi, deux modèles de même nom
+provenant de services en amont différents.
+
+## Où ça va
+
+La configuration globale du modèle Pi est :
+
+```text
+~/.pi/agent/models.json
+```
+
+:::caution[Fusionnez, ne remplacez jamais]
+`ocx export` n’écrit jamais dans ce fichier. Fusionnez-y le bloc `providers.opencodex` : remplacer le
+fichier supprimerait tous les autres fournisseurs que vous y avez configurés. L’option `--out` permet d’utiliser un chemin temporaire
+et refuse d’écraser un fichier existant sans `--force` :
+
+```bash
+ocx export --client pi --out ~/opencodex-pi-models.json
+ocx export --client pi --json > ~/opencodex-pi-models.json # or redirect the byte-exact JSON
+```
+:::
+
+Le bloc exporté est un instantané statique et non une vue en direct. Réexécutez `ocx export` après avoir ajouté un
+fournisseur ou modification de la visibilité du modèle, et fusionnez le nouveau bloc sur l'ancien.
+
+## La clé d'admission
+
+Deux clés différentes sont ici faciles à confondre, et seule la première apparaît dans ce fichier :
+
+| Clé | Qu'est-ce que c'est | Où il vit |
+| --- | --- | --- |
+| Clé d'admission proxy | Les propres informations d'identification de opencodex, générées dans l'onglet **API** du tableau de bord | référencé par `apiKey` comme `$OPENCODEX_API_KEY` ; la valeur reste dans votre environnement |
+| Clé du fournisseur | votre touche Anthropic / OpenAI / OpenRouter | La propre configuration de opencodex, selon [Fournisseurs](/fr/guides/providers/) |
+
+La configuration exportée ne contient que la référence, jamais le secret. Pi interpole une valeur simple de la forme `$NAME` ;
+la variable est :
+
+```bash
+export OPENCODEX_API_KEY=
+```
+
+Ce nom est propre à Pi. opencode utilise une autre variable
+(`OPENCODEX_OPENCODE_API_KEY`, sous la forme `{env:…}`) — voir le [guide opencode](/fr/guides/opencode/).
+
+**Un proxy lié à l’interface de bouclage n’a besoin d’aucune clé.** Par défaut, opencodex se lie à `127.0.0.1` et n’y exige
+aucune authentification ; la référence `$OPENCODEX_API_KEY` est donc inerte et la variable peut rester indéfinie.
+Cela n'a d'importance que lorsque `hostname` est défini au-delà du bouclage, ce qui est également le cas lorsque le proxy
+refuse de démarrer sans jeton — voir [Accès à distance](/fr/reference/configuration/server/#accès-à-distance).
+
+## Métadonnées du modèle
+
+`contextWindow` et `maxTokens` sont émis uniquement lorsque le catalogue fournit une fenêtre de contexte
+faisant autorité. Dans le cas contraire, les deux champs sont omis pour ce modèle et Pi applique ses propres valeurs par défaut ;
+`ocx export` affiche le nombre de lignes concernées.
+
+`maxTokens` est un budget de `32000` destiné à satisfaire le schéma. Il est plafonné à la fenêtre de contexte, de sorte qu’un
+modèle doté d’un petit contexte ne reçoive jamais davantage de sortie que de contexte. Cette valeur ne constitue pas une affirmation sur la
+limite maximale réelle d’un modèle donné.
+
+Le champ `cost` est volontairement absent. Il exige les quatre champs de prix, alors qu’OpenCodex ne possède
+aucune donnée tarifaire pour les modèles routés ; émettre des zéros reviendrait à affirmer que tous les
+modèles sont gratuits.
+
+`reasoning`, autrefois absent, est désormais émis. Pi stocke un booléen tandis que le catalogue possède une
+échelle d’effort ; cette correspondance était auparavant trop incertaine. Puisque l’échelle du catalogue
+indique maintenant si le proxy accepte les paramètres de raisonnement — les adaptateurs respectent
+`reasoning_effort` — une ligne exportée avec une échelle **non vide** reçoit `"reasoning": true`. Une ligne
+sans échelle, ou avec une échelle explicitement vide, reste dépourvue de raisonnement. Pi propose ainsi son
+contrôle de l’effort exactement pour les modèles auxquels OpenCodex permet de l’envoyer. L’export produit
+aussi un `thinkingLevelMap` qui masque avec `null` chaque niveau Pi sans cible déclarée : Pi ne propose ni
+n’envoie donc aucun effort absent de l’échelle. Un repli maintient le modèle utilisable : lorsque `ultra`
+est déclaré sans `max`, le niveau `max` de Pi est associé à `ultra`, qui appartient bien à l’échelle.
+Modifiez ensuite `thinkingLevelMap` manuellement si vous souhaitez une autre correspondance, comme le
+documente Pi.
+
+Considérez `reasoning` comme une métadonnée de l’interface Pi : elle découle de l’échelle du catalogue et ne
+prouve pas que le service en amont accepte nativement un paramètre de raisonnement. Ce que le proxy envoie
+réellement pour une valeur `reasoning_effort` dépend de l’adaptateur et du modèle du fournisseur : il peut
+transmettre la valeur, la traduire au moyen d’alias de protocole, la limiter à l’échelle configurée,
+l’émuler ou l’omettre entièrement, notamment pour `noReasoningModels`. Le booléen détermine seulement si Pi
+propose ce contrôle.
+
+## Statut du schéma
+
+:::note[Non vérifié sur une installation réelle]
+La forme ci-dessus suit la documentation publiée par le fournisseur personnalisé de Pi. Il n'a **pas** été vérifié
+sur un véritable fichier `~/.pi/agent/models.json`, sur une machine où Pi est installé. Si Pi rejette le bloc
+exporté, l’incompatibilité vient de notre côté : veuillez
+[ouvrir un ticket](https://github.com/lidge-jun/opencodex/issues) en indiquant le message renvoyé par Pi.
+:::
+
+## Exigences
+
+Un proxy opencodex en cours d'exécution (`ocx start`) et Pi installés. `ocx export` lit le catalogue en direct
+via la gestion du proxy API, donc une config ne peut jamais être émise avec une liste de modèles vide.
diff --git a/docs-site/src/content/docs/fr/guides/providers.md b/docs-site/src/content/docs/fr/guides/providers.md
new file mode 100644
index 0000000000..787c7c9a25
--- /dev/null
+++ b/docs-site/src/content/docs/fr/guides/providers.md
@@ -0,0 +1,602 @@
+---
+title: Fournisseurs
+description: Toutes les méthodes utilisées par opencodex pour s'authentifier auprès d'un fournisseur de LLM et communiquer avec lui — OAuth, clé API, transfert ChatGPT et exécution locale.
+---
+
+Un **fournisseur** associe un point de terminaison LLM en amont à la façon de l'atteindre : un adaptateur,
+une URL de base, un mode d'authentification et, facultativement, une liste de modèles. Les fournisseurs sont
+définis sous `providers` dans `~/.opencodex/config.json`.
+
+## Modes de compte OpenAI
+
+| Identifiant du fournisseur | Utilisation | Règle relative aux identifiants et aux comptes |
+| --- | --- | --- |
+| `openai` | Connexion Codex | Pool (par défaut) sélectionne le compte principal et les comptes ajoutés ; Direct utilise uniquement la connexion de l'appelant ou du compte principal actuel. |
+| `openai-apikey` | API OpenAI | Utilise exclusivement la clé API ou le pool de clés configuré ; ne lit jamais les comptes Codex. |
+
+Utilisez l'identifiant non qualifié `gpt-5.6-sol` avec l'option Pool/Direct de la page **Fournisseurs**, ou
+`openai-apikey/gpt-5.6-sol` pour l'API. Ces routes d'authentification ne se rabattent jamais l'une sur l'autre.
+La route API publie des métadonnées indiquant un contexte de 1 050 000 jetons et une entrée maximale de
+922 000 jetons. Ses identifiants virtuels `sol-pro`, `terra-pro` et `luna-pro` conservent l'identité publique
+sélectionnée, tandis que la requête transmise emploie le modèle de base avec `reasoning.mode: "pro"`.
+
+Si le fournisseur `openai` intégré est absent ou désactivé, le sélecteur de comptes du tableau de bord et la
+page **Authentification Codex** peuvent le restaurer : une ligne absente est créée depuis le préréglage
+canonique, une ligne canonique désactivée est réactivée sans remplacer le mode ni les réglages de modèle
+enregistrés, et ce parcours de récupération n'est pas proposé aux lignes `openai` non canoniques.
+
+### Aperçu de la capacité du pool des fournisseurs
+
+Pour la connexion Codex en mode Pool, la vue d'ensemble des fournisseurs affiche une estimation pondérée,
+d'après les poids configurés, de la capacité utilisée du pool, au lieu de présenter un compte arbitraire
+comme total du fournisseur. La même ligne indique également le pourcentage brut du quota du compte effectif
+actuel, afin de distinguer l'estimation du pool du compte qu'utiliserait une nouvelle requête.
+
+Lorsque les informations de réinitialisation sont disponibles, la vue d'ensemble indique l'heure de la
+prochaine réinitialisation et la capacité qu'elle devrait restituer sous la forme `+N% pool capacity`.
+**Couverture incomplète** signifie qu'un ou plusieurs comptes du pool ne peuvent pas contribuer de manière
+sûre à l'estimation, par exemple parce que leur forfait ou leur quota est inconnu, que leur mesure est
+périmée, ou que le compte est suspendu ou doit être réauthentifié.
+
+Un avertissement de **couverture partielle des fenêtres** signifie que certains comptes inclus ont signalé
+une fenêtre de quota, mais pas une autre. La vue d'ensemble conserve ces fenêtres séparément et marque comme
+incomplète chaque fenêtre concernée, au lieu d'assimiler la mesure absente à de l'utilisation.
+
+Cette estimation est destinée uniquement à l'affichage. Elle ne change ni la sélection du compte, ni
+l'affinité de session, ni le changement automatique, ni les délais de récupération, ni aucune autre décision de
+routage. Consultez le [groupe de comptes d'authentification Codex](/fr/guides/web-dashboard/#authentification-codex-et-groupes-de-comptes)
+pour l'état de chaque compte et les contrôles de routage.
+
+Les configurations v1 livrées migrent automatiquement vers le marqueur 2 et une ligne tenant compte de
+l'option choisie. La configuration d'origine est conservée une fois dans
+`~/.opencodex/config.json.pre-openai-tiers-v2.bak` ; restaurez-la avec
+`cp ~/.opencodex/config.json.pre-openai-tiers-v2.bak ~/.opencodex/config.json`.
+
+## Modes d'authentification
+
+Les configurations de fournisseurs acceptent trois valeurs `authMode` (`key` est la valeur par défaut). Le
+registre intégré classe séparément les préréglages locaux ; ceux-ci omettent normalement `authMode` et `apiKey`.
+
+| `authMode` | Méthode d'authentification | Utilisé par |
+| --- | --- | --- |
+| `key` | Envoie votre clé API (`Authorization: Bearer …`, ou `x-api-key` / `api-key` par adaptateur). La clé peut être un littéral ou une référence `${ENV_VAR}`. | La plupart des fournisseurs. |
+| `forward` | Transmet **à l'identique vos en-têtes d'authentification Codex entrants** au fournisseur, sans enregistrer de clé. Il s'agit du transfert de la connexion ChatGPT. | OpenAI (adaptateur `openai-responses`). |
+| `oauth` | Résout un jeton d'accès OAuth enregistré — automatiquement actualisé avant son expiration — et l'utilise comme jeton porteur. | xAI, Anthropic, Kimi, Kiro, Google Antigravity, Cursor, Command Code, GitHub Copilot, Nous Portal. |
+
+La relance d'une requête 429 avec la même clé, configurée par
+[`retryOn429`](/fr/reference/configuration/), s'applique uniquement aux fournisseurs à clé API
+(`authMode: "key"`). Les préréglages OAuth, de transfert et locaux sont exclus : leurs identifiants ne doivent
+jamais être réutilisés sur le même jeton, et les environnements locaux ne possèdent aucune clé distante à
+préserver. Cette fonction est facultative : elle est désactivée lorsque l'option est absente ; la présence de
+l'objet l'active, sauf si `enabled: false`.
+
+## 1. Connexion ChatGPT (transfert direct)
+
+Le fournisseur `openai` ne nécessite **aucune clé API**. Direct transfère les identifiants de votre
+`codex login` existant ; Pool résout d'abord un compte Codex principal ou ajouté, puis utilise le même serveur :
+
+```json
+{
+ "openai": {
+ "adapter": "openai-responses",
+ "baseUrl": "https://chatgpt.com/backend-api/codex",
+ "authMode": "forward"
+ }
+}
+```
+
+Seul un ensemble sélectionné d'en-têtes est transmis (`FORWARD_HEADERS` : autorisation, identifiant de
+compte ChatGPT, bêta/originator/session OpenAI — voir [Adaptateurs](/fr/reference/adapters/)). Ce parcours
+alimente aussi les [services auxiliaires de recherche web et de vision](/fr/guides/sidecars/).
+
+Le catalogue du transfert ChatGPT ajoute également les identifiants non qualifiés GPT-5.6 Sol/Terra/Luna
+(`gpt-5.6-sol`, `gpt-5.6-terra`, `gpt-5.6-luna`) pour les comptes qui peuvent les utiliser.
+
+## 2. Connexion au compte (OAuth)
+
+Huit préréglages de fournisseurs utilisent une connexion OAuth. GitHub Copilot s'y ajoute au moyen d'un pont
+expérimental et non officiel reposant sur un flux d'autorisation d'appareil. opencodex enregistre leurs identifiants dans
+`~/.opencodex/auth.json` et les actualise automatiquement. La CLI de connexion accepte également `chatgpt` ;
+elle obtient un identifiant ChatGPT tout en créant une entrée de fournisseur en mode `forward`.
+
+```bash
+ocx login xai # xAI Grok
+ocx login anthropic # Anthropic Claude (Pro/Max)
+ocx login kimi # Moonshot Kimi
+ocx login nous # Nous Portal (device grant; free + paid models)
+ocx login kiro # import kiro-cli credentials (or token fallback)
+ocx login google-antigravity
+ocx login cursor # standalone Cursor PKCE login
+ocx login command-code # Command Code browser OAuth (or import ~/.commandcode/auth.json)
+ocx login github-copilot # GitHub device flow → Copilot token (Copilot Pro/Business)
+ocx login chatgpt # standalone ChatGPT OAuth login
+ocx logout
+```
+
+| Fournisseur | Adaptateur | URL de base | Remarques |
+| --- | --- | --- | --- |
+| `xai` | `openai-chat` | `https://api.x.ai/v1` | Catalogue Grok découvert en direct en priorité ; `grok-4.5` est le modèle de repli par défaut. |
+| `anthropic` | `anthropic` | `https://api.anthropic.com` | Modèles Claude ; liste des modèles récupérée en direct depuis `/v1/models`. |
+| `kimi` | `openai-chat` | `https://api.kimi.com/coding/v1` | Modèles de programmation Kimi K2.7/K2.6/K2.5. |
+| `nous` | `openai-chat` | `https://inference-api.nousresearch.com/v1` | Passerelle d'abonnement Nous Research (le même service en amont que celui utilisé par Hermes Agent). Connexion par autorisation d'appareil auprès de `portal.nousresearch.com` ; le jeton d'accès est le JWT d'inférence envoyé avec chaque requête. Le catalogue mixte de modèles payants et `:free` (`tencent/hy3:free`, `stepfun/step-3.7-flash:free`, ...) est découvert en direct pour le compte connecté. Les jetons d'actualisation sont à usage unique et renouvelés à chaque actualisation. |
+| `kiro` | `kiro` | `https://runtime.us-east-1.kiro.dev` | La connexion initiale importe la session de l'installation locale de `kiro-cli`, déjà authentifiée (sous Unix, installez avec `curl -fsSL https://cli.kiro.dev/install` | `bash`; sous Windows PowerShell, utilisez `irm 'https://cli.kiro.dev/install.ps1'` | `iex`; puis exécutez `kiro-cli login`). **Ajouter un compte** déconnecte `kiro-cli`, lance une nouvelle connexion dans le navigateur qui change le compte utilisé par `kiro-cli`, puis enregistre les métadonnées propres au profil. Les comptes OpenCodex existants sont préservés ; une annulation ou un échec restaure la session `kiro-cli` précédente. |
+| `google-antigravity` | `google` | `https://daily-cloudcode-pa.googleapis.com` | Google OAuth avec le protocole Cloud Code Assist. La découverte en direct utilise le point de terminaison CCA authentifié `v1internal:fetchAvailableModels` et publie les modèles d'agent accessibles au compte connecté ; le catalogue maintenu reste la solution de repli. |
+| `cursor` | `cursor` | `https://api2.cursor.sh` | Connexion PKCE expérimentale, transport HTTP/2 en direct et découverte de modèles filtrés par compte. |
+| `github-copilot` | `openai-chat` | `https://api.githubcopilot.com` | Expérimental. Flux d'appareil GitHub et échange `copilot_internal` (client OAuth de VS Code). Nécessite un abonnement Copilot actif ; il ne s'agit pas d'une API tierce officielle. |
+
+Après un échec définitif d'actualisation de Nous, exécutez `ocx login nous` pour vous réauthentifier.
+
+Pour les préréglages canoniques du forfait Kimi Coding (`kimi` pour la connexion au compte et `kimi-code`
+pour la clé API), opencodex ne transmet à la requête Chat Completions qu'un `prompt_cache_key` stable fourni
+par l'appelant ; il n'en génère jamais. Selon la documentation de Kimi, une clé de session ou de tâche stable
+est nécessaire pour améliorer le taux de succès du cache du Coding Plan ; les requêtes dépourvues de clé le
+restent. Si un service en amont explicitement activé rejette ce champ, opencodex ne le retire pas avant de
+réessayer et ne modifie pas la configuration enregistrée. Tous les autres fournisseurs le refusent par défaut.
+
+Vous pouvez également démarrer OAuth à partir du [tableau de bord Web](/fr/guides/web-dashboard/).
+
+### Plusieurs comptes OAuth
+
+Les fournisseurs OAuth dont les identifiants comportent un identifiant de compte ou une adresse e-mail stable
+peuvent conserver plusieurs connexions. La page **Fournisseurs** affiche ces comptes dans une liste déroulante,
+permet d'en ajouter un autre et de changer de compte actif sans déconnecter les autres. Une connexion ordinaire
+avec un identifiant Kimi qui ne contient aucune information d'identité remplace l'emplacement actif, tandis que l'action explicite **Ajouter un
+compte** préserve cet emplacement et en active un nouveau, distinct. Les comptes Kiro sont indexés par ARN de
+profil. `chatgpt` n'utilise toujours qu'un seul emplacement, car les comptes du pool Codex sont gérés dans un
+registre distinct. Les jetons restent dans `~/.opencodex/auth.json` ; `/api/oauth/accounts` ne renvoie que des
+métadonnées masquées.
+
+### Importation Cockpit Tools Antigravity
+
+Dans la v1, OpenCodex importe uniquement les exportations JSON **Cockpit Tools Antigravity** destinées au
+fournisseur `google-antigravity`. Dans le tableau de bord **Fournisseurs**, sélectionnez le fichier JSON local
+depuis l'onglet **Comptes** de ce fournisseur. Le tableau de bord n'affiche ni le contenu du fichier ni les
+valeurs des identifiants ; il indique uniquement le nombre d'éléments importés, mis à jour, en échec ou non pris
+en charge. Les autres fournisseurs Cockpit sont refusés dans la v1.
+
+La CLI accepte l'exportation uniquement depuis un fichier ou l'entrée standard : ne la collez jamais dans un argument de commande :
+
+```bash
+ocx account import google-antigravity --format cockpit-tools --file [--json]
+cat accounts.json | ocx account import google-antigravity --format cockpit-tools --stdin [--json]
+```
+
+Le JSON en ligne et les arguments positionnels supplémentaires sont refusés. Gardez les fichiers exportés
+confidentiels et supprimez-les ou conservez-les de façon sécurisée après l'importation.
+
+### Fiabilité OAuth
+
+opencodex coordonne l'actualisation des jetons et le routage du pool Codex afin que les requêtes simultanées
+n'entrent pas en concurrence dans le magasin d'identifiants. Il s'agit d'un mécanisme de fiabilité et de
+diagnostic : il ne garantit **aucune** protection contre l'application des règles du fournisseur, les limites
+de débit ou les mesures prises à l'encontre d'un compte.
+
+**Coordination de l'actualisation.** Avant un appel routé, un jeton d'accès expiré est actualisé une fois par
+`(provider, account)` :
+
+1. Appel unique dans le processus : les appelants simultanés partagent la même promesse d'actualisation.
+2. Verrouillage de fichier par compte : les écritures provenant de plusieurs processus sont sérialisées pour un même compte.
+3. CAS de génération : les données ne sont enregistrées que si la génération des identifiants stockés correspond
+ toujours. Une écriture plus récente l'emporte ; le résultat d'une actualisation antérieure ne peut pas l'écraser.
+
+Les échecs définitifs d’actualisation signalent que le compte doit être réauthentifié, au lieu de relancer
+indéfiniment la même opération.
+
+**Délais de récupération du pool Codex.** Une réponse `429` ou un dépassement de quota en amont impose un délai
+de récupération strict, déterminé par `Retry-After`, par les en-têtes `reset` du quota — dans la limite du
+plafond prévu — ou par un bref délai de repli par défaut. Les comptes soumis à un délai `Retry-After` explicite
+ne sont pas sondés avant son expiration. Les délais calculés à partir des informations de réinitialisation
+peuvent bénéficier d'une autorisation de sondage cadencée, afin de détecter la reprise sans submerger le
+fournisseur. Pour les modèles natifs, ces délais préservent également les groupes de quotas indépendants connus :
+`gpt-5.3-codex-spark` n'empêche pas le même compte d'essayer le quota partagé de GPT-5.6 Terra/Luna, tandis
+que les modèles de ce groupe partagé continuent de se protéger mutuellement. Les délais `Retry-After` explicites
+et les délais par défaut s'appliquent toujours à l'ensemble du compte.
+
+**Affinité de session.** L'affinité entre le fil Codex et le compte est locale au processus — uniquement en mémoire et
+non conservée après le redémarrage du proxy. En cas d'échec des identifiants (`401` / `403`), le compte est
+mis en quarantaine dans l'attente d'une réauthentification et ses affinités sont effacées. En cas de `429`, le
+compte entre en délai de récupération, ses affinités sont effacées et la sélection du pool peut changer : les fils
+ne restent pas épinglés après une réponse de limite de débit.
+
+**Métadonnées du client Codex.** Le parcours de transfert ChatGPT laisse passer la liste d'autorisation
+sélectionnée `FORWARD_HEADERS` — autorisation, `chatgpt-account-id`, originator, identifiants de session et de
+fil, ainsi que les en-têtes Codex associés ; voir [Adaptateurs](/fr/reference/adapters/). Le mode Pool ne
+remplace que l'authentification et `chatgpt-account-id` afin qu'ils correspondent à l'identifiant sélectionné.
+opencodex ne fabrique **aucune** identité de client officiel, comme les en-têtes `originator`, de session ou
+de fil, si l'appelant ne les a pas fournis.
+
+**Diagnostics et réauthentification.** La sortie de `ocx status` destinée aux utilisateurs affiche un bloc d'état OAuth —
+identifiants de compte expurgés, aucun jeton. `ocx doctor` ajoute une section sur la fiabilité OAuth, avec des
+contrôles du magasin accessible en écriture et de l'appel unique, ainsi que des lignes WARN qui indiquent une
+action de récupération. Lorsqu'un compte de fournisseur OAuth doit être réauthentifié, exécutez
+`ocx login ` ou utilisez **Réauthentifier** dans le tableau de bord. Les comptes du pool Codex ne
+constituent pas un fournisseur `ocx login` : réauthentifiez-les dans le groupe de comptes Codex du tableau de bord. Consultez
+[`ocx status` / `ocx doctor`](/fr/reference/cli/) dans la référence CLI.
+
+### Importation des identifiants Kiro
+
+La connexion Kiro nécessite la CLI Kiro : sous Unix, installez-la avec `curl -fsSL https://cli.kiro.dev/install | bash` ;
+sous Windows PowerShell, utilisez `irm 'https://cli.kiro.dev/install.ps1' | iex`, puis connectez-vous avec `kiro-cli login`.
+En l'absence de session `kiro-cli`, `ocx login kiro` se rabat sur un jeton d'accès collé ou sur la variable
+d'environnement `KIRO_ACCESS_TOKEN`.
+
+Le parcours d'importation `ocx login kiro` recherche les magasins de la CLI Kiro propres à la plateforme et
+ouvre les bases SQLite en lecture seule. Deux variables d'environnement permettent de sélectionner explicitement
+la source et la ligne du jeton :
+
+- `KIROCLI_DB_PATH` sélectionne une base de données Kiro CLI SQLite non standard. Le chemin doit déjà exister ;
+ pendant ce chemin d'importation, opencodex ne crée ni ne modifie la base de données, ni les fichiers WAL ou SHM.
+- `KIROCLI_TOKEN_KEY` sélectionne la clé de jeton `auth_kv` exacte lorsqu'une base de données contient plusieurs
+ lignes de jeton qui seraient autrement ambiguës. En l'absence de sélection, la connexion échoue au lieu de
+ choisir arbitrairement.
+
+Sous Windows, l'importation recherche `%LOCALAPPDATA%\Kiro-Cli\data.sqlite3`. La connexion forcée ou par
+**Ajouter un compte** nécessite également le binaire local de la CLI : opencodex consulte d'abord `PATH`, puis se rabat sur
+`%LOCALAPPDATA%\Kiro-Cli\kiro-cli.exe` et `C:\Program Files\Kiro-Cli\kiro-cli.exe`.
+
+Après une importation réussie, opencodex conserve les informations d'identification importées dans
+`~/.opencodex/auth.json`.
+Gardez ces variables et la base sélectionnée confidentielles. Ne joignez ni fichier de base de données ni
+diagnostic de connexion brut aux rapports de bogue.
+
+**Ajouter un compte** suit un parcours d'écriture distinct : opencodex crée un instantané de la session en
+cours, déconnecte `kiro-cli`, puis importe la nouvelle connexion effectuée dans le navigateur. Si la connexion
+est annulée ou échoue, y compris pendant l'enregistrement des identifiants par OpenCodex, la restauration remplace
+la base de données de la CLI Kiro et supprime ses fichiers auxiliaires WAL, SHM et journal avant de rétablir
+l'instantané de la session précédente.
+
+Comme cette restauration exige un instantané, **Ajouter un compte** refuse de déconnecter `kiro-cli` lorsqu'un
+magasin de session existe mais ne peut pas être capturé (fichier illisible, schéma incompatible ou sélection de
+jeton ambiguë), lorsque `KIROCLI_DB_PATH` / `KIRO_CLI_DB_FILE` redirigent les lectures d'importation hors du
+magasin actif de la CLI, ou lorsqu'une base principale existante de la CLI ne contient aucune ligne de jeton
+reconnue. Réparez ou supprimez la base illisible dans le chemin de données normal de `kiro-cli`, désactivez ces
+sélecteurs d'importation, puis réessayez. La connexion depuis une machine dépourvue de session `kiro-cli`
+existante n'est pas concernée.
+
+## 3. Catalogue des clés API
+
+opencodex fournit 79 préréglages intégrés : 67 à clé, huit OAuth, trois locaux et un préréglage par défaut de
+transfert ChatGPT. Dans le tableau de bord, le sélecteur **Ajouter un fournisseur** ouvre le tableau de bord du
+fournisseur à clé, valide la clé et l'enregistre ; la validation dépend du fournisseur. Parmi les entrées notables :
+
+**ClinePass** utilise une clé API Cline avec le [catalogue d'abonnement officiel](https://docs.cline.bot/getting-started/clinepass)
+et le [point de terminaison Chat Completions](https://docs.cline.bot/api/chat-completions), exploités par Cline Bot Inc. selon
+les [conditions de Cline](https://cline.bot/tos). Un identifiant routé tel que `cline-pass/cline-pass/kimi-k3`
+est intentionnel : le premier segment sélectionne le fournisseur opencodex, tandis que `cline-pass/kimi-k3`
+est l'identifiant complet du modèle envoyé en amont. Le quota ClinePass est partagé par le compte entre des
+limites glissantes sur 5 heures, hebdomadaires et mensuelles. Une sonde en direct effectuée le 2026-08-13 a
+confirmé que tous les modèles ClinePass statiques acceptent `low`, `medium`, `high`, `xhigh` et `max` à
+l'entrée de la passerelle. opencodex conserve les niveaux demandés ; toute normalisation propre au service en
+amont reste de la responsabilité de ClinePass.
+
+**Cline** utilise la même clé API et le même point de terminaison, avec une facturation à l'usage pour plus de
+100 modèles (identifiants de type OpenRouter, comme `anthropic/claude-sonnet-4-6`). Les modèles gratuits
+promotionnels de Cline ne sont accessibles que dans l'IDE ou la CLI Cline, pas par l'API ;
+`minimax/minimax-m2.5` est le modèle d'expérimentation gratuite documenté pour l'API.
+
+| Fournisseur | URL de base |
+| --- | --- |
+| **OpenAI (clé API)** | `https://api.openai.com/v1` |
+| **Anthropic (clé API)** | `https://api.anthropic.com` |
+| **OpenRouter** | `https://openrouter.ai/api/v1` |
+| **Cline** | `https://api.cline.bot/api/v1` |
+| **ClinePass** | `https://api.cline.bot/api/v1` |
+| **Ollama Cloud** | `https://ollama.com/v1` |
+| Google Gemini · Google Vertex AI | `https://generativelanguage.googleapis.com` · `https://aiplatform.googleapis.com` |
+| Azure OpenAI | `https://{resource}.openai.azure.com/openai` |
+| Umans AI · Neuralwatt | `https://api.code.umans.ai` · `https://api.neuralwatt.com/v1` |
+| Mistral | `https://api.mistral.ai/v1` |
+| MiniMax · MiniMax (CN) | `https://api.minimax.io/v1` · `https://api.minimaxi.com/v1` |
+| DeepSeek | `https://api.deepseek.com` |
+| Cerebras | `https://api.cerebras.ai/v1` |
+| Chutes | `https://llm.chutes.ai/v1` |
+| DeepInfra | `https://api.deepinfra.com/v1/openai` |
+| Hyperbolic | `https://api.hyperbolic.xyz/v1` |
+| Nscale Serverless Inference | `https://inference.api.nscale.com/v1` |
+| Vultr Serverless Inference | `https://api.vultrinference.com/v1` |
+| Baseten Model APIs | `https://inference.baseten.co/v1` |
+| Command Code | `https://api.commandcode.ai/provider/v1` |
+| SambaNova Cloud | `https://api.sambanova.ai/v1` |
+| Nebius Token Factory | `https://api.tokenfactory.nebius.com/v1` |
+| DigitalOcean Serverless Inference | `https://inference.do-ai.run/v1` |
+| Scaleway Generative APIs | `https://api.scaleway.ai/v1` |
+| Featherless AI | `https://api.featherless.ai/v1` |
+| Novita AI | `https://api.novita.ai/openai/v1` |
+| Together | `https://api.together.xyz/v1` |
+| Fireworks | `https://api.fireworks.ai/inference/v1` |
+| Moonshot (Kimi API) · Kimi (coding) | `https://api.moonshot.ai/v1` · `https://api.kimi.com/coding/v1` |
+| Hugging Face | `https://router.huggingface.co/v1` |
+| NVIDIA NIM | `https://integrate.api.nvidia.com/v1` |
+| Z.AI (GLM Coding) | `https://api.z.ai/api/coding/paas/v4` |
+| Zhipu AI (BigModel) | `https://open.bigmodel.cn/api/paas/v4` |
+| Qwen Cloud | Forfait à jetons (par défaut) : `https://token-plan.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1` · Facturation à l'usage : `https://dashscope.aliyuncs.com/compatible-mode/v1` · ou personnalisé |
+| Tencent Cloud Coding Plan | `https://api.lkeap.cloud.tencent.com/coding/v3` |
+| SiliconFlow | `https://api.siliconflow.cn/v1` |
+| Volcengine Ark · Coding Plan · Agent Plan | `https://ark.cn-beijing.volces.com/api/v3` · `https://ark.cn-beijing.volces.com/api/coding/v3` · `https://ark.cn-beijing.volces.com/api/plan/v3` |
+| Xiaomi MiMo | `https://api.xiaomimimo.com/anthropic` |
+| Xiaomi MiMo (OpenAI Chat) | `https://api.xiaomimimo.com/v1` |
+| Kilo | `https://api.kilo.ai/api/gateway` |
+| GitLab Duo | `https://cloud.gitlab.com/ai/v1/proxy/openai/v1` |
+| Cloudflare AI Gateway | `https://gateway.ai.cloudflare.com/v1/{account-id}/{gateway}/anthropic` |
+| …et plus encore | opencode zen, Vercel AI Gateway, Venice, NanoGPT, Synthetic, Qianfan, Alibaba, Parallel, ZenMux, LiteLLM |
+
+**OpenCode Zen** (`opencode-zen`) et le préréglage sans clé **OpenCode Free** utilisent tous deux
+`https://opencode.ai/zen/v1`. Sur cette passerelle, les modèles gratuits atteignent souvent une limite de
+rafale sur une courte fenêtre, d'environ 15 à 20 requêtes par minute (mesure de la communauté ; OpenCode ne publie
+pas de valeur RPM). Zen peut renvoyer des erreurs génériques 429 de limitation de débit sans en-têtes
+`Retry-After` / `X-RateLimit-*`. Cette limite est distincte du quota sans clé pour application de bureau
+annoncé par OpenCode (environ 200 requêtes Big Pickle ou vers des modèles gratuits toutes les 5 heures sur
+`opencode-free`). Lorsque Zen omet `Retry-After` sur une telle réponse 429, opencodex ajoute à l'erreur client
+des indications propres au fournisseur ainsi qu'un `Retry-After` synthétique ; un `Retry-After` reçu en amont
+reste prioritaire. L'attente et la nouvelle tentative avec la même clé restent facultatives et s'activent avec
+[`retryOn429`](/fr/reference/configuration/).
+
+La plupart utilisent l'adaptateur `openai-chat` avec une clé Bearer ; quelques fournisseurs qui n'exposent
+qu'un point de terminaison compatible Anthropic, comme **Xiaomi MiMo**, emploient l'adaptateur `anthropic`
+(`x-api-key`). Volcengine Agent Plan utilise son point de terminaison Responses natif par `openai-responses`.
+Le préréglage DeepSeek intégré route également `deepseek-v4-flash` par son point de terminaison Responses natif
+et conserve le streaming SSE en amont. Si ce modèle termine tous les éléments de sortie mais omet l'événement
+Responses final, opencodex applique une réparation après un délai de grâce de cinq secondes, limitée à ce
+modèle ; les flux mal formés ou partiels sont fermés comme incomplets, et non déclarés réussis.
+
+> **Trois routes de facturation Volcengine :** `volcengine` correspond à l'API Ark facturée à l'usage,
+> `volcengine-coding-plan` consomme le quota Coding Plan et `volcengine-agent-plan` le quota Agent Plan.
+> Utilisez la clé et le point de terminaison fournis pour le même produit ; le point de terminaison `/api/v3`
+> ordinaire peut entraîner une facturation à l'usage même si vous disposez d'un abonnement Plan.
+> Les préréglages emploient des catalogues statiques sélectionnés, car la réponse `/models` d'Ark contient aussi
+> des ressources d'embedding, d'image, de vidéo et de 3D, la passerelle Coding renvoie le même catalogue étendu,
+> et la passerelle Agent Plan ne possède aucune ressource `/models`. Le modèle par défaut de la route facturée à
+> l'usage est `doubao-seed-2-1-pro-260628` ; son catalogue sélectionné comprend également les modèles de texte
+> DeepSeek et GLM actuels. Coding Plan utilise `ark-code-latest` par défaut, et Agent Plan `deepseek-v4-pro`.
+
+> **Restriction d'utilisation des forfaits Volcengine :** selon la documentation de Volcengine, les quotas
+> Coding Plan et Agent Plan ne sont valables que dans les outils de programmation par IA pris en charge. Elle
+> avertit que l'utilisation d'une clé de forfait pour des appels API généraux peut entraîner la suspension de
+> l'abonnement ou le bannissement du compte. Le routage de Codex ou Claude Code par opencodex correspond à
+> l'usage documenté ; l'emploi d'une clé de forfait par une autre automatisation n'en fait pas partie. La route
+> `volcengine` facturée à l'usage n'est pas soumise à cette restriction.
+
+**Découverte Chutes.** Le préréglage `chutes` utilise la passerelle LLM compatible OpenAI, fixe et partagée de
+Chutes. Il lit le catalogue public `/v1/models`, ne conserve que les lignes dont `supported_features` annonce
+`tools`, préserve les identifiants de modèle contenant des barres obliques ainsi que les métadonnées en direct
+sûres, et limite la découverte à 256 KiB et 128 lignes brutes. Comme ce catalogue est public, il ne peut pas
+prouver la validité d'une clé fournie ; les requêtes de chat utilisent néanmoins la clé Bearer configurée. Les
+hôtes Chute personnalisés déployés par l'utilisateur et les API Chutes autres que LLM relèvent toujours d'un
+fournisseur personnalisé. Créez une clé depuis le [tableau de bord Chutes](https://chutes.ai/auth/start).
+
+**Découverte DeepInfra.** Le fournisseur `deepinfra` à clé pour OpenAI Chat Completions utilise l'adaptateur
+`openai-chat` avec une clé API Bearer. L'URL de liste des modèles appartenant au registre ne conserve que les
+lignes étiquetées `chat`, préserve les identifiants natifs contenant des barres obliques et limite la découverte
+en direct à 512 KiB et 512 lignes brutes. Créez des clés dans le
+[tableau de bord DeepInfra](https://deepinfra.com/dash/api_keys).
+
+**Découverte Hyperbolic.** Le préréglage lit `/v1/models` avec la clé Bearer configurée, préserve les
+identifiants natifs contenant des barres obliques et limite la découverte en direct à 256 KiB et 256 lignes
+brutes. Il couvre uniquement le chat sans serveur en texte et en vision-langage ; les points de terminaison
+distincts de Hyperbolic pour les images, l'audio et les GPU sont hors périmètre. Créez des clés sur
+[Hyperbolic](https://app.hyperbolic.ai).
+
+**Découverte Nscale et Vultr.** Les deux préréglages lisent le catalogue `/v1/models` authentifié du fournisseur,
+préservent les identifiants natifs et limitent la découverte à 256 KiB et 256 lignes brutes. Le catalogue de
+Nscale mélange des modèles de chat, d'image et d'embedding sans champ de modalité ; le préréglage n'admet donc
+que `meta-llama/Llama-3.1-8B-Instruct`, modèle employé dans l'exemple officiel d'appel d'outil de l'API Nscale.
+Vultr ne documente actuellement l'appel d'outils que pour `kimi-k2-instruct` ; son préréglage n'expose donc que
+ce modèle. Les autres lignes restent masquées jusqu'à ce que le fournisseur publie des preuves équivalentes de
+prise en charge des outils d'agent. Créez un jeton de service dans la [console Nscale](https://console.nscale.com)
+et copiez la clé d'inférence de Vultr depuis la vue d'ensemble de l'abonnement dans la
+[console Vultr](https://my.vultr.com).
+
+**Découverte Command Code.** Le préréglage lit la liste `/provider/v1/models` de Command Code depuis l'hôte
+fixe de l'API Provider, préserve les identifiants natifs du fournisseur et limite la découverte à 256 KiB et
+256 lignes brutes. `ocx login command-code` prend en charge OAuth par connexion dans le navigateur, avec
+importation facultative des identifiants locaux depuis `~/.commandcode/auth.json` pour les utilisateurs de la
+CLI Command Code. Le catalogue, propre au compte, provient du point de terminaison de découverte authentifié
+après la connexion. Les requêtes de chat utilisent la clé Bearer configurée. Créez des clés dans
+[Command Code Studio](https://commandcode.ai/studio/).
+
+**Découverte SambaNova Cloud.** Le préréglage lit la liste publique `/v1/models` de SambaNova Cloud depuis
+l'hôte API fixe, préserve les identifiants natifs du fournisseur et limite la découverte à 128 KiB et 128
+lignes brutes. Le catalogue n'étant pas authentifié, le parcours de connexion de la CLI signale que la clé ne
+peut pas être vérifiée au lieu de considérer la réponse publique comme une preuve. Les requêtes de chat utilisent
+néanmoins la clé Bearer configurée et désactivent les appels de fonctions parallèles, que SambaNova ne prend pas
+encore en charge. Les points de terminaison de déploiements SambaStudio privés sont hors périmètre. Créez des
+clés dans [SambaNova Cloud](https://cloud.sambanova.ai/apis).
+
+**Découverte Nebius Token Factory.** Le préréglage demande le catalogue détaillé et authentifié des modèles,
+puis ne conserve que les lignes dont l'architecture produit du texte, en excluant les modèles d'embedding et de
+génération d'images. Il préserve les identifiants natifs contenant des barres obliques ainsi que les métadonnées
+de contexte et de modalités d'entrée signalées, et limite la découverte à 512 KiB et 512 lignes brutes. Les
+hôtes de déploiement dédiés sont hors périmètre. Créez des clés dans
+[Nebius Token Factory](https://tokenfactory.nebius.com).
+
+**Découverte DigitalOcean.** Le préréglage utilise une clé d'accès aux modèles avec l'hôte Serverless Inference
+partagé et fixe, puis croise la réponse `/v1/models` authentifiée avec la liste d'autorisation Chat Completions
+étayée par la documentation de DigitalOcean. Les identifiants inconnus, limités à Responses, d'embedding ou de
+génération multimédia sont refusés par défaut. La découverte est limitée à 256 KiB et 256 lignes brutes ; les
+hôtes propres aux agents et les hôtes dédiés sont hors périmètre. Créez une clé dans le
+[panneau de configuration DigitalOcean](https://cloud.digitalocean.com/model-studio/manage-keys).
+
+**Découverte Scaleway.** Le préréglage croise la liste authentifiée des modèles avec la liste d'autorisation
+Serverless Chat Completions documentée par Scaleway. Les identifiants inconnus, limités à Responses,
+d'embedding, de transcription et des autres modèles multimédias sont refusés par défaut ; la découverte est
+limitée à 128 KiB et 128 lignes brutes. Il utilise le point de terminaison partagé du projet par défaut ; les
+URL qualifiées par projet et les déploiements dédiés nécessitent un fournisseur personnalisé. Créez une clé API
+dans la [console Scaleway](https://console.scaleway.com/generative-api).
+
+**Découverte Featherless.** Le préréglage s'authentifie auprès de l'hôte fixe compatible OpenAI et ne demande
+que les 100 premiers modèles populaires, filtrés en amont pour le chat et le forfait actuel. Les règles du
+registre refusent ensuite toute ligne qui ne signale pas indépendamment la disponibilité du forfait, l'absence
+de restriction d'accès Hugging Face et `features.tool_use: true`. La découverte est limitée à 128 KiB et 100
+lignes brutes ; le catalogue de plusieurs dizaines de milliers de modèles du service n'est donc jamais
+téléchargé ni mis en cache en entier. Comme `/v1/models` est documenté comme accessible avec ou sans
+authentification, il ne peut pas prouver la validité d'une clé fournie ; les requêtes de chat utilisent
+néanmoins la clé Bearer configurée. Les conditions de Featherless réservent les forfaits individuels à un usage
+interactif ou de prototypage ; les applications arbitraires nécessitent un forfait Scale. Créez une clé dans le
+[tableau de bord Featherless](https://featherless.ai/account/api-keys).
+
+**Découverte Novita.** Le préréglage à clé utilise l'adaptateur `openai-chat` et n'envoie sa clé Bearer qu'à
+l'hôte fixe compatible OpenAI de Novita. Sa liste publique de modèles est filtrée pour ne conserver que les
+lignes qui signalent à la fois `model_type: chat` et le point de terminaison `chat/completions`, la découverte
+étant limitée à 512 KiB et 256 lignes brutes. Les identifiants de modèle doivent être conservés exactement tels
+que Novita les renvoie, y compris ceux délimités par des barres obliques, sans normalisation ni réécriture avant
+le routage. Le catalogue étant public, la connexion signale que la clé ne peut pas être vérifiée au lieu de
+considérer une réponse de liste réussie comme une preuve. Les capacités variant selon les modèles, le
+préréglage n'annonce ni appels d'outils parallèles à l'échelle du fournisseur ni `reasoning_effort` OpenAI.
+Créez une clé dans le [gestionnaire de clés Novita](https://novita.ai/settings/key-management).
+
+> **Périmètre Baseten :** le préréglage couvre uniquement les [Model APIs](https://docs.baseten.co/inference/model-apis/overview)
+> partagées de Baseten. Utilisez une [clé API](https://docs.baseten.co/organization/api-keys) personnelle pour
+> un usage local, ou une clé d'équipe disposant de l'accès **Call Model APIs** pour un usage partagé ou en
+> production. Les points de terminaison Truss `predict` dédiés utilisent d'autres hôtes et schémas et ne sont pas
+> routés par ce préréglage.
+> Pour ce préréglage, la découverte en direct est limitée à une réponse de 1 MiB et à 256 lignes de modèle brutes.
+
+### Quota de crédits A6API
+
+Un fournisseur `openai-chat` personnalisé qui utilise `authMode: "key"` et l'URL de base canonique
+`https://api.a6api.com` ou `https://api.a6api.com/v1` bénéficie d'un indicateur de crédits A6API dans le tableau
+de bord et dans la sortie de `ocx account refresh `. Le nom du fournisseur est libre ; la détection
+repose sur le point de terminaison HTTPS canonique. L'indicateur convertit les unités de jetons A6API en USD à
+partir de la limite de crédit ferme du compte, puis affiche le pourcentage consommé et le crédit restant.
+L'expiration du jeton n'est pas présentée comme une réinitialisation du quota, car elle n'implique pas le
+renouvellement des crédits.
+
+```json
+{
+ "providers": {
+ "my-a6": {
+ "adapter": "openai-chat",
+ "authMode": "key",
+ "baseUrl": "https://api.a6api.com/v1",
+ "apiKey": "${A6API_API_KEY}"
+ }
+ }
+}
+```
+
+Les sondes de quota n'envoient que la clé active à l'hôte A6API canonique et refusent les redirections. Les
+totaux de facturation mal formés, négatifs ou incohérents ne produisent aucun rapport, afin d'éviter d'afficher
+une barre trompeuse.
+
+> **Restriction d'utilisation de Tencent Cloud Coding Plan :** Tencent réserve cet abonnement aux outils de
+> programmation interactifs. L'automatisation générale par API, les services applicatifs personnalisés et les
+> traitements par lots non interactifs sont interdits et peuvent entraîner la suspension de la clé du forfait.
+
+> **Deux routes GLM :** `zai` correspond à l'abonnement international Z.AI Coding Plan ; `zhipu-bigmodel`
+> correspond au point de terminaison national BigModel de Zhipu, facturé à l'usage. Les hôtes, les clés et la
+> facturation diffèrent : une clé émise pour l'un ne permet pas de s'authentifier auprès de l'autre.
+
+### Plusieurs clés API
+
+Les fournisseurs à clé peuvent eux aussi conserver plusieurs clés. L'ajout d'une clé depuis la page
+**Fournisseurs** l'enregistre sous `provider.apiKeyPool`, l'active et la recopie dans `provider.apiKey`, afin
+que le routage et les adaptateurs continuent de lire le même champ. La même liste déroulante permet de changer
+ou de supprimer une clé ; l'API de gestion est `/api/providers/keys` et ne renvoie que des clés masquées.
+
+### Changer de compte depuis le terminal
+
+Utilisez `ocx account list`, `ocx account current` et `ocx account use` pour consulter ou changer les mêmes
+groupes de comptes Codex, de comptes OAuth et de clés API sans ouvrir le tableau de bord. Consultez la
+[référence de la CLI](/fr/reference/cli/providers-accounts/#ocx-account-subcommand) pour les commandes, la sortie JSON et le
+comportement lors de l'ouverture d'une nouvelle session.
+
+### Routes de préversion GPT-5.6
+
+GPT-5.6 Sol/Terra/Luna sont préchargés dans les listes de repli des fournisseurs afin que `ocx sync` puisse
+maintenir leur visibilité même lorsque les catalogues en direct ne sont pas encore à jour :
+
+| Route Codex | Identifiants de modèle préchargés | Contexte visible dans Codex |
+| --- | --- | --- |
+| Connexion Codex (Pool ou Direct) | `gpt-5.6-*` | 372 000 |
+| OpenAI (clé API) | `openai-apikey/gpt-5.6-*` plus `*-pro` | 1 050 000 (entrée maximale de 922 000) |
+| OpenRouter | `openrouter/openai/gpt-5.6-sol`, `openrouter/openai/gpt-5.6-terra`, `openrouter/openai/gpt-5.6-luna` | 1 050 000 |
+| Cursor | `cursor/gpt-5.6-sol`, `cursor/gpt-5.6-terra`, `cursor/gpt-5.6-luna` | 1 000 000 |
+
+Les entrées natives GPT-5.6 conservent les niveaux de raisonnement fixés en amont — Luna propose par exemple
+`max`, mais pas `ultra`. Les entrées routées utilisent les métadonnées et les correspondances de raisonnement de
+leur fournisseur. Les quatre routes restent soumises aux autorisations du service en amont ; la découverte en direct de Cursor filtre
+également sa liste statique pour ne conserver que les modèles utilisables par le compte connecté.
+
+:::note[Passerelles et proxys d'abonnement]
+Un fournisseur est inclus lorsque opencodex dispose d'un adaptateur de protocole correspondant, **et non** selon
+qu'il s'agit ou non d'un produit « agent ». Les identifiants d'adaptateur actuels sont `openai-chat`, `openai-responses`, `anthropic`, `google`
+(modes AI Studio, Vertex et Antigravity/Cloud Code Assist), `azure` / `azure-openai`, `kiro` et
+`cursor`. Une API propriétaire dépourvue de l'une de ces implémentations, comme l'API native Amazon Bedrock,
+n'est pas prise en charge directement.
+
+**GitHub Copilot** est un fournisseur OAuth (`ocx login github-copilot`) qui échange une connexion GitHub par
+flux d'appareil contre un jeton d'API Copilot de courte durée, et non contre une clé API collée. **GitLab Duo**
+reste une passerelle à clé ou jeton d'abonnement sur son point de terminaison compatible OpenAI.
+**Cloudflare AI Gateway** exige que les identifiants de votre compte et de votre passerelle figurent dans l'URL.
+
+Copilot présente un catalogue qui utilise plusieurs protocoles : sa famille GPT-5 (`gpt-5.3-codex`, `gpt-5.4`,
+`gpt-5.4-mini`, `gpt-5.5`, `gpt-5.6-luna`, `gpt-5.6-sol`, `gpt-5.6-terra`) rejette
+`/chat/completions` pour le trafic d'agent. opencodex route donc ces modèles sur l'API Responses par défaut,
+tandis que tous les autres modèles Copilot restent sur Chat Completions. L'ordre de priorité est le suivant :
+verrouillage explicite du protocole → entrée [`modelAdapters`](/fr/reference/configuration/providers/) définie
+par l'utilisateur → valeur par défaut du registre → adaptateur commun au fournisseur. Pour faire passer par
+Responses un modèle dépourvu de valeur par défaut intégrée, par exemple `gpt-5.4-nano`, définissez
+`"modelAdapters": { "gpt-5.4-nano": "openai-responses" }`.
+
+Cursor est géré séparément comme adaptateur expérimental. `adapter: "cursor"` apparaît dans `ocx init` et dans
+le sélecteur **Ajouter un fournisseur** du tableau de bord comme entrée expérimentale de la configuration locale,
+avec les métadonnées du catalogue statique de repli de Cursor. Lorsqu'un jeton d'accès Cursor est configuré,
+opencodex utilise le transport HTTP/2 direct de Cursor. Sa liste de repli intégrée comprend `gpt-5.6-sol` /
+`terra` / `luna` (contexte de 1M), les variantes ordinaires et Fast de Grok 4.5 et 4.6 (500K), ainsi que
+`kimi-k3` (262K) ; la découverte en direct détermine celles qui restent visibles pour le compte. Grok 4.6 expose
+`low` / `medium` / `high` / `xhigh` sous les deux formes, tandis que 4.5 s'arrête à `high`. Les requêtes Fast
+envoient le modèle Grok de base correspondant avec des paramètres `effort` et `fast=true` `requested_model`
+distincts ; les identifiants aplatis `cursor-grok-{version}-{effort}-fast` servent uniquement à la découverte et
+à la sélection. Cursor ne fournit Kimi K3 qu'avec des identifiants de protocole suffixés par l'effort ;
+`cursor/kimi-k3` expose donc une échelle `low` / `high` / `max` avec `max` par défaut, conformément à la valeur
+par défaut documentée de l'API du modèle. L'exécution native read/write/delete/ls/grep/shell/fetch pilotée par
+le serveur Cursor est désactivée par défaut, car elle contourne le parcours d'approbation et le bac à sable de
+Codex ; définissez
+`unsafeAllowNativeLocalExec: true` sur l'objet `providers.cursor` dans `~/.opencodex/config.json`
+uniquement pour des expériences locales de confiance, ou via **Fournisseurs → Cursor → Modifier le JSON** dans
+le tableau de bord. Consultez la [référence de configuration](/fr/reference/configuration/providers/#fournisseur-cursor-adapter-cursor)
+pour un exemple complet. MCP, l'enregistrement d'écran et l'utilisation de l'ordinateur sont disponibles sous
+forme de points d'intégration pour un exécuteur ; sans exécuteur local configuré, opencodex renvoie des résultats
+typés indiquant son absence au lieu de bloquer la requête par stratégie. OAuth Cursor et la découverte en direct
+des modèles sont activés pour cet adaptateur expérimental ; Cursor ne figure toujours pas dans les listes de
+connexion par clé.
+:::
+
+### Ollama Cloud
+
+Ollama Cloud est une version hébergée — et non locale — d'Ollama, compatible avec OpenAI à l'adresse
+`https://ollama.com/v1` et accessible avec une clé créée sur
+[ollama.com/settings/keys](https://ollama.com/settings/keys). opencodex classe les modèles cloud selon leurs
+capacités visuelles, afin que le [service auxiliaire de vision](/fr/guides/sidecars/) n'intervienne que pour les modèles
+exclusivement textuels. Ces derniers, par exemple `glm-5.2`, `deepseek-v4-pro`, `gpt-oss`, `qwen3-coder`,
+`minimax-m2.x` et `nemotron-3-*`, figurent dans `noVisionModels` ; les modèles à vision native, comme
+`kimi-k2.6`, `minimax-m3`, `gemma4`, `qwen3.5` et `gemini-3-flash-preview`, n'y figurent pas. La correspondance
+tolère les balises `:size` d'Ollama : `gpt-oss` couvre donc `gpt-oss:120b` et `gpt-oss:20b`.
+
+## 4. Fournisseurs locaux
+
+Faites pointer opencodex vers un serveur local compatible OpenAI, généralement avec une clé vide :
+
+| Fournisseur | URL de base |
+| --- | --- |
+| Ollama (local) | `http://localhost:11434/v1` |
+| vLLM | `http://localhost:8000/v1` |
+| LM Studio | `http://localhost:1234/v1` |
+
+## Tout point de terminaison compatible OpenAI
+
+Si un fournisseur prend en charge Chat Completions, l'adaptateur `openai-chat` peut le gérer. Choisissez
+**Personnalisé** dans le tableau de bord ou `custom` dans `ocx init`, puis saisissez l'URL de base. Consultez la
+[référence de configuration](/fr/reference/configuration/) pour tous les champs de fournisseur
+(`headers`, `noReasoningModels`, `noVisionModels`, `models`, …).
+
+## Limites de débit dans la vue d'ensemble des fournisseurs
+
+La section **Limites de débit** de la vue d'ensemble des fournisseurs affiche des barres d'utilisation en direct,
+actualisées depuis le point de terminaison d'usage ou de facturation propre à chaque fournisseur lorsqu'il en
+existe un. Elles indiquent la part déjà consommée d'une fenêtre de 5 heures, hebdomadaire, mensuelle ou propre
+au fournisseur.
+
+Les fournisseurs qui disposent d'une sonde en direct sont OpenAI/Codex, Anthropic, xAI, Cursor, Kimi,
+Google Antigravity, OpenRouter, DeepSeek, ClinePass, Z.AI, MiniMax, Moonshot, Venice, Synthetic, DeepInfra,
+Neuralwatt, ainsi que tout fournisseur personnalisé reposant sur a6api.
diff --git a/docs-site/src/content/docs/fr/guides/routing-profile-editor.md b/docs-site/src/content/docs/fr/guides/routing-profile-editor.md
new file mode 100644
index 0000000000..b437c28b3d
--- /dev/null
+++ b/docs-site/src/content/docs/fr/guides/routing-profile-editor.md
@@ -0,0 +1,76 @@
+---
+title: Éditeur de profils de routage
+description: Créez, modifiez, validez, simulez et supprimez des profils de stratégie de routage depuis le tableau de bord OpenCodex.
+---
+
+L’onglet **Modèles → Routage** du tableau de bord OpenCodex permet de gérer `config.routingProfiles` sans modifier `config.json` manuellement.
+
+## Créer un profil
+
+1. Ouvrez **Routage** dans le tableau de bord.
+2. Sélectionnez **Créer un profil**.
+3. Saisissez un `id`. L’identifiant de modèle canonique est `policy/`.
+4. Ajoutez un ou plusieurs candidats fournisseur/modèle explicites.
+5. Configurez, si nécessaire, les exigences, les pondérations de notation, les plafonds de coût (`maxEstimatedCostUsd` et, facultativement, `onUnknownCost`) ainsi que le traitement des preuves inconnues.
+6. Enregistrez le profil.
+
+Les identifiants de profil sont immuables après leur création. Pour utiliser un autre identifiant, créez un nouveau profil, mettez à jour les appelants, puis supprimez l’ancien profil.
+
+## Validation et persistance
+
+Le tableau de bord envoie à l’API de gestion le même objet de profil que celui utilisé par `config.routingProfiles`. Le serveur valide l’intégralité du profil proposé avant de l’enregistrer :
+
+- les identifiants et les alias doivent respecter les règles de nommage et de collision des profils de routage ;
+- chaque fournisseur candidat doit exister et être activé ;
+- les candidats en double sont rejetés ;
+- les limites et exigences numériques doivent rester dans les plages prises en charge ;
+- au moins une pondération d’optimisation doit être positive.
+
+Une sauvegarde réussie enregistre le profil au moyen du mécanisme habituel d’écriture de la configuration, réconcilie l’état actif et actualise le catalogue de modèles. En cas d’échec de validation, la configuration précédente reste inchangée et l’erreur s’affiche dans l’éditeur.
+
+Lorsque `limits.maxEstimatedCostUsd` est configuré, `limits.onUnknownCost` vaut `"allow"` par défaut : une estimation de coût inconnue n’entraîne aucune exclusion propre au plafond, et les traces de décision de routage, en simulation comme en production, portent
+`cost.capOutcome: "unknown-allowed"` afin d’indiquer aux opérateurs que le respect du plafond n’a pas été démontré. Définissez `"exclude"`
+si le plafond doit être appliqué en mode fermé (`cost-limit-unknown`, avec
+`cost.capOutcome: "unknown-excluded"`). Configurer uniquement `onUnknownCost` est sans effet et ne produit aucun résultat de plafond. Ce réglage est distinct de
+`unknownEvidence.cost`, qui peut toujours exclure ou pénaliser les coûts inconnus indépendamment du
+résultat du plafond.
+
+## Simuler un profil enregistré
+
+Sélectionnez un profil enregistré et utilisez **Évaluation à sec** pour ajouter des éléments propres à la requête, tels que la taille de la fenêtre de contexte, l’utilisation d’outils, l’entrée d’images ou la sortie structurée. La simulation évalue l’admissibilité et la notation, mais n’envoie jamais de requête à un modèle en amont.
+
+Les modifications non enregistrées ne sont pas prises en compte par la simulation. Enregistrez d’abord le profil afin que la révision et l’évaluation affichées correspondent à la même configuration.
+
+## API de gestion
+
+L’éditeur utilise les points de terminaison suivants :
+
+- `GET /api/routing-profiles` répertorie les profils normalisés et les révisions.
+- `PUT /api/routing-profiles` crée ou met à jour un profil. Envoyez `mode: "create"` ou `mode: "update"` ; le mode création refuse d’écraser un identifiant existant.
+- `DELETE /api/routing-profiles?id=` supprime un profil.
+- `POST /api/routing-profiles/dry-run` évalue un profil enregistré sans envoyer de requête en amont.
+
+Exemple de charge utile de sauvegarde :
+
+```json
+{
+ "id": "fast",
+ "mode": "create",
+ "profile": {
+ "alias": "ocx/fast",
+ "candidates": [
+ { "provider": "anthropic", "model": "claude-sonnet-5" },
+ { "provider": "openai", "model": "gpt-5.6" }
+ ],
+ "require": { "tools": true, "minContextWindow": 128000 },
+ "optimize": { "latency": 0.55, "health": 0.25, "cost": 0.1, "quota": 0.1 },
+ "limits": { "maxEstimatedCostUsd": 0.5, "onUnknownCost": "allow" },
+ "unknownEvidence": {
+ "capability": "exclude",
+ "health": "penalize",
+ "quota": "penalize",
+ "cost": "penalize"
+ }
+ }
+}
+```
diff --git a/docs-site/src/content/docs/fr/guides/sidecars.md b/docs-site/src/content/docs/fr/guides/sidecars.md
new file mode 100644
index 0000000000..1bd91c107c
--- /dev/null
+++ b/docs-site/src/content/docs/fr/guides/sidecars.md
@@ -0,0 +1,167 @@
+---
+title: "Services auxiliaires : recherche web et vision"
+description: Dotez les modèles routés d’une véritable recherche web et donnez aux modèles textuels une compréhension des images grâce à des services auxiliaires ChatGPT natifs.
+---
+
+Tous les modèles routés ne proposent pas une **recherche web** hébergée ni une **entrée d’image** native. opencodex complète
+ces capacités au moyen de deux services auxiliaires. Chacun peut s’appuyer sur un fournisseur connecté à ChatGPT (`forward`) ou sur un
+fournisseur Anthropic OAuth enregistré. Les erreurs des services auxiliaires sont converties en résultats d’outil limités ou en marqueurs d’image,
+au lieu de faire échouer l’intégralité du tour.
+
+:::note[Sélection automatique du moteur]
+Une valeur `backend` explicite est prioritaire. Lorsqu'elle est omise, opencodex utilise `anthropic` si un fournisseur OAuth Anthropic actif
+possède un compte actif qui n'est pas marqué `needsReauth` ; sinon, il utilise `openai`. Une sélection explicite de
+`anthropic` sans ces identifiants échoue de manière sûre. `openai` exige à la fois une connexion ChatGPT et un
+fournisseur `forward` actif.
+:::
+
+## Service auxiliaire de recherche web
+
+Lorsque Codex demande un hébergement `web_search` pour un modèle routé sans passage, opencodex :
+
+1. **Supprime** l'outil hébergé `web_search` et expose à sa place un outil de fonction synthétique `web_search(query)`
+ au modèle routé. Les options de l'outil hébergé d'origine sont conservées pour l'appel du service auxiliaire.
+2. Exécute le modèle routé dans une petite **boucle d'agent**. Lorsqu'il appelle `web_search`, opencodex utilise le
+ moteur du service auxiliaire sélectionné : OpenAI exécute l'outil hébergé `web_search` avec `gpt-5.6-luna` par défaut ;
+ Anthropic exécute `web_search_20250305` avec `claude-sonnet-5` par défaut. La réponse en streaming et
+ les citations deviennent le résultat d’un outil.
+3. **Répète la boucle** jusqu'à ce que le modèle réponde ou que le nombre total de recherches réelles atteigne `maxSearchesPerTurn`
+ (par défaut 3), supprime ensuite l'outil de recherche et force une réponse finale. De vrais outils clients tels que
+ `apply_patch` ou le shell mettent fin au tour afin que ces appels parviennent à Codex.
+
+Chaque itération du modèle routé envoie `stream: true` en amont, mais, par défaut, opencodex met entièrement
+en mémoire tampon les événements sémantiques avant de décider s'il faut lancer une recherche ou renvoyer la réponse finale.
+Seuls les en-têtes et le statut du tour final, ainsi que les réponses 429 de la première itération, sont traités immédiatement. Ainsi,
+les appels de recherche synthétiques et les résultats préliminaires ne sont jamais exposés comme sorties du modèle visibles par le client.
+
+L'activation explicite de `webSearchSidecar.streamRoutedModelOutput` (`false` par défaut) diffuse à la place les principaux deltas
+de texte et de raisonnement de chaque itération. Le client voit la sortie dès que le modèle la produit, comme sur le chemin sans service auxiliaire.
+Cette fenêtre de diffusion se ferme définitivement à la limite du premier appel d'outil : la décision d'intercepter `web_search` reste donc
+atomique et aucun contenu n'est livré deux fois, puisque la relecture terminale ignore ce qui a déjà été diffusé. En contrepartie, le texte
+émis par le modèle *avant* sa décision de lancer une recherche — texte que le mode avec tampon supprime silencieusement — devient visible
+et peut être partiellement répété dans la réponse qui suit la recherche. La page Vue d'ensemble du tableau de bord expose ce réglage sous
+**Diffuser les réponses en direct** dans la carte du service auxiliaire de recherche web (`PUT /api/sidecar-settings` avec
+`webSearch.streamRoutedModelOutput`).
+
+Les commentaires Kiro sont indépendants de cette option : en mode avec tampon, le texte de la phase de commentaire est déjà diffusé
+avant l'événement terminal. Ce traitement reste inchangé avec ou sans `streamRoutedModelOutput` ; seuls les événements nécessaires
+à la décision de recherche — les appels d'outils et tout ce qui suit la limite du premier appel — restent dans le tampon afin que la
+décision concernant `web_search` demeure atomique.
+
+Le résultat injecté est enveloppé dans une limite de données non fiables, limité en longueur et dédupliqué par
+URL source. Dans les tours à sortie structurée (`json_schema` / `json_object`), il est fourni sous une forme compacte
+plutôt qu'en prose. Pour les modèles routés limités au texte, le modèle de recherche doit également décrire
+les images pertinentes et inclure leurs URL sources.
+
+```json
+{
+ "webSearchSidecar": {
+ "enabled": true,
+ "backend": "anthropic",
+ "model": "claude-sonnet-5",
+ "reasoning": "low",
+ "maxSearchesPerTurn": 3,
+ "routedModelStallTimeoutMs": 200000,
+ "timeoutMs": 200000,
+ "streamRoutedModelOutput": false
+ }
+}
+```
+
+Le niveau de raisonnement `minimal` n'est pas utilisé, car le moteur hébergé rejette les outils à ce niveau. Une recherche
+échouée est renvoyée au modèle routé sous la forme d'un résultat d'erreur borné, ce qui lui permet de répondre à partir du
+contexte qu’il a déjà.
+
+Quatre délais distincts s'appliquent. `stallTimeoutSec` est le délai de base pour les événements et les blocages du pont.
+`connectTimeoutMs` (`200000` par défaut) couvre uniquement DNS, TCP, TLS et la réception des en-têtes de réponse.
+Le réglage réservé au fichier de configuration `webSearchSidecar.routedModelStallTimeoutMs` (`200000` par défaut, entier
+`1..2147483647`) limite l'inactivité continue des octets de réponse brute pour chaque itération du modèle routé et
+se réinitialise à chaque octet non vide. `webSearchSidecar.timeoutMs` limite séparément une requête de recherche hébergée.
+Le délai de surveillance effectif du pont vaut
+`max(base stall, connect timeout, routed-model stall, sidecar timeout) + 30 seconds`. Le délai d'inactivité du modèle routé
+n'est pas un délai total de génération. Les échecs antérieurs au démarrage du flux SSE renvoient une réponse JSON non-2xx ;
+les échecs de génération postérieurs à l'envoi des en-têtes sont transmis sous la forme d'un événement SSE `response.failed`.
+
+## Service auxiliaire de vision
+
+Lorsque le modèle routé est répertorié dans le `noVisionModels` de son fournisseur et qu'une requête porte une image,
+opencodex décrit chaque image **avant** l'appel principal et la remplace par du texte. Quand
+si `visionSidecar.model` est absent ou vide, le chemin d'exécution OpenAI, le tableau de bord et l'API de gestion
+utilisent le modèle de repli `gpt-5.4-mini`. Au démarrage, une ancienne valeur `gpt-5.4-mini` explicitement enregistrée
+est toujours migrée vers `gpt-5.6-luna` ; cette migration s'applique à une valeur stockée, et non à l'absence du
+champ du modèle.
+
+- Les images peuvent provenir de messages utilisateur, développeur et de résultats d’outils, y compris de `view_image` dans Codex.
+- Sur le chemin OpenAI (ChatGPT-login passthrough), chaque image est envoyée au modèle de vision configuré
+ au point de terminaison Responses avec la valeur `reasoning.effort` sélectionnée (`low` par défaut) ; sa
+ description remplace l'image en ligne. Le chemin Anthropic utilise le point de terminaison Messages avec sa
+ propre correspondance entre réflexion et budget, et ignore ce paramètre propre à OpenAI.
+- Pour les modèles natifs dont les capacités sont connues, un niveau de raisonnement non pris en charge est ramené au
+ niveau pris en charge le plus élevé qui ne dépasse pas la valeur demandée ; s'il n'en existe aucun, le niveau pris en charge le plus bas
+ est utilisé. Les modèles inconnus ou personnalisés restent permissifs en l'absence de métadonnées fiables sur leurs capacités.
+- Les descriptions s'exécutent avec une concurrence limitée (3 à la fois, dans l'ordre des entrées). Le contexte utilisateur envoyé
+ au modèle de description est limité à 800 caractères, et chaque description injectée à 2 000
+ caractères. La requête n'envoie pas `max_output_tokens`, que le moteur ChatGPT rejette.
+- Les URL des images sont validées avant transfert : les URL des données doivent utiliser `png` / `jpeg` / `jpg` / `webp` /
+ `gif` et les données base64 sont limitées à environ 20 Mo. Seuls les schémas `data:` et `https:` sont acceptés ;
+ les images distantes `https` sont récupérées par le moteur OpenAI, et non par le proxy.
+- La correspondance `noVisionModels` ignore un suffixe `:size` de style Ollama, donc une entrée `gpt-oss` couvre également
+ `gpt-oss:120b`.
+- Si la description échoue, le modèle reçoit un bref marqueur d'erreur de traitement. Si aucun service auxiliaire n'est
+ disponible, l'image brute est supprimée plutôt que transmise à un moteur limité au texte.
+- `maxDescriptionsPerTurn` (8 par défaut) limite les nouvelles descriptions par tour du modèle principal. Les résultats du cache et
+ les doublons au même tour ne le consomment pas. Les descriptions d'images `data:` réussies sont mises en cache par
+ moteur, modèle, niveau de détail, octets de l'image et contexte du message — ainsi que l'effort de raisonnement dans les
+ clés OpenAI (les clés Anthropic l'omettent, puisque ce champ y est ignoré) ; les images `https:` modifiables ne sont pas
+ mises en cache.
+
+L'API de gestion et le sélecteur du tableau de bord répertorient désormais les modèles qui peuvent réellement accepter des images.
+Lorsque le moteur correspondant est disponible, `gpt-5.6-luna` (OpenAI) et `claude-haiku-4-5` (Anthropic)
+sont toujours proposés comme options de base. `PUT /api/sidecar-settings` rejette un modèle connu pour être
+texte uniquement, mais accepte toujours un identifiant inconnu afin que les noms personnalisés ou en avance sur le catalogue continuent de fonctionner.
+
+```json
+{
+ "visionSidecar": {
+ "enabled": true,
+ "backend": "openai",
+ "model": "gpt-5.6-luna",
+ "reasoning": "medium",
+ "maxDescriptionsPerTurn": 8,
+ "timeoutMs": 45000
+ }
+}
+```
+
+Un modèle est marqué en texte uniquement par fournisseur :
+
+```json
+{
+ "providers": {
+ "ollama-cloud": {
+ "adapter": "openai-chat",
+ "baseUrl": "https://ollama.com/v1",
+ "noVisionModels": ["glm-5.2", "gpt-oss", "qwen3-coder", "deepseek-v4-pro"]
+ }
+ }
+}
+```
+
+## Contrôles du tableau de bord et désactivation
+
+La carte Vision du tableau de bord permet d'activer ou de désactiver le service auxiliaire, de définir
+`maxDescriptionsPerTurn` et `timeoutMs`, ainsi que de régler le modèle, le moteur
+et le raisonnement. La désactivation du service auxiliaire ne supprime pas ces
+paramètres ; sa réactivation conserve le modèle, le moteur, le niveau de raisonnement,
+le délai d'attente et la limite précédemment choisis.
+
+`PUT /api/sidecar-settings` accepte les mêmes champs. Les mises à jour partielles laissent
+les clés omises inchangées. `timeoutMs` utilise les limites entières de l'environnement d'exécution
+(1–2147483647 ms).
+
+Vous pouvez toujours définir `enabled: false` dans `config.json` si vous préférez modifier le
+fichier directement. La recherche et la description d'images avec OAuth Anthropic réutilisent les identifiants
+Claude Code existants du magasin d'empreintes précédent. Testez néanmoins ce comportement avec le
+compte et la charge de travail prévus.
+
+Consultez la [Référence de configuration](/fr/reference/configuration/server/#services-auxiliaires) pour chaque champ.
diff --git a/docs-site/src/content/docs/fr/guides/sub-agent-surface.md b/docs-site/src/content/docs/fr/guides/sub-agent-surface.md
new file mode 100644
index 0000000000..4fb0ece971
--- /dev/null
+++ b/docs-site/src/content/docs/fr/guides/sub-agent-surface.md
@@ -0,0 +1,274 @@
+---
+title: Interface des sous-agents (v1 / base / v2)
+description: Contrôlez la manière dont Codex génère et gère les sous-agents dans tous les modèles.
+---
+
+## Que sont les sous-agents
+
+Un sous-agent est un travailleur Codex distinct que l'agent principal peut créer pour une tâche ciblée. Il a son
+son propre contexte et ses propres outils, afin que plusieurs tâches indépendantes puissent s'exécuter en parallèle. opencodex contrôle lequel
+La surface de collaboration Codex expose ces travailleurs, quels modèles Codex leur propose et comment un
+un modèle défaillant peut reculer. Il ne décide pas quand votre agent principal doit déléguer.
+
+## Modes
+
+Choisissez le mode pour les **nouvelles sessions**. Les sessions existantes conservent la surface avec laquelle elles ont commencé.
+
+| Mode | Ce que Codex obtient | Qui devrait le choisir |
+| --- | --- | --- |
+| **v1** | Outils classiques avec espace de noms `spawn_agent`, `send_input`, `resume_agent` et `close_agent`. Un spawn peut sélectionner directement un autre modèle. | Les débutants qui ont besoin d'une délégation fiable entre différents fournisseurs, en particulier les enfants natifs vers routés. |
+| **base** (par défaut) | Paramètres de modèle en amont : GPT-5.6 Sol/Terra utilisent la v2, Luna utilise la v1, et les modèles non définis explicitement suivent l’indicateur de fonctionnalité `multi_agent_v2` de Codex. | La plupart des utilisateurs. Ce mode respecte la surface prévue par Codex pour chaque modèle, sans en imposer une globalement. |
+| **v2** | Outils plats `spawn_agent`, `send_message`, `followup_task`, `interrupt_agent` et liste d'agents, avec sessions simultanées. | Utilisateurs souhaitant utiliser le flux de travail simultané le plus récent et comprenant l'héritage de modèle et la limitation des tâches chiffrées ci-dessous. |
+
+:::tip[Pas sûr ?]
+Commencez par **base**. Choisissez **v1** lorsque la délégation entre fournisseurs doit fonctionner de manière prévisible. Forcer **v2**
+uniquement lorsque vous souhaitez spécifiquement son modèle de session le plus récent dans chaque entrée de catalogue.
+:::
+
+## Comment ça marche
+
+Le mode sélectionné contrôle le champ `multi_agent_version` dans chaque entrée de catalogue Codex lit :
+
+- **v1** inscrit `multi_agent_version = "v1"` sur chaque modèle.
+- **base** restaure les paramètres en amont. Les entrées sans valeur explicite suivent l’indicateur de fonctionnalité natif `multi_agent_v2`.
+- **v2** inscrit `multi_agent_version = "v2"` sur chaque modèle.
+
+opencodex applique cela comme passe finale à la fois au catalogue `/v1/models` en direct et au catalogue synchronisé
+sur le disque. C'est pourquoi un changement de mode affecte de manière cohérente les sessions App, CLI et TUI nouvellement créées.
+
+Pour une liste v2, l'éligibilité a trois états : une entrée estampillée `"v2"`, explicitement définie sur `null`, ou
+sans champ `multi_agent_version` est admissible. Une valeur explicite `"v1"` est exclue, car elle indique
+que le modèle appartient à l’autre surface de collaboration.
+
+## Modèle et efforts de délégation
+
+La **délégation de sous-agent** du tableau de bord contrôle trois paramètres associés :
+
+- `injectionModel` est le modèle de travailleur préféré nommé dans le guide opencodex.
+- `injectionEffort` est le `reasoning_effort` optionnel à demander pour ce modèle.
+- `injectionPrompt` remplace le texte d'orientation intégré de la v2.
+
+`multiAgentGuidanceEnabled` est activé par défaut et constitue le réglage principal des directives produites par opencodex
+sur les deux surfaces. Sa désactivation supprime à la fois le bloc de désignation v2 et le texte proactif v1.
+
+Pour les requêtes Responses sans état dont l’entrée est un tableau, opencodex place les instructions générées après les
+premières métadonnées système et développeur, y compris `additional_tools` côté développeur, et avant l’entrée
+conversationnelle. Les continuations avec état utilisant `previous_response_id` ne réutilisent les directives balisées que si elles correspondent au dernier
+élément balisé de leur préfixe de relecture fiable. Les autres directives générées sont réutilisées lorsqu’un élément développeur généré
+à l’identique figure dans ce préfixe. Lorsque les directives changent, le protocole de l’outil principal reste en première position et
+les nouvelles directives sont insérées avant l’entrée conversationnelle actuelle.
+
+Ce sont des instructions destinées à l'agent principal, et non à un routeur de génération côté proxy. Sur la v2, un fork avec historique complet
+hérite du modèle parent et rejette les remplacements de modèle ou d'effort. Le guidage indique donc à Codex de
+utilisez `fork_turns: "none"` (ou un compte de tour partiel positif tel que `"3"`) lorsque vous dépassez `model` ou
+`reasoning_effort`, et de rendre le message de tâche autonome.
+
+Le texte personnalisé de `injectionPrompt` peut utiliser les quatre espaces réservés suivants :
+
+| Espace réservé | Remplacé par |
+| --- | --- |
+| `{{model}}` | Le modèle préféré effectif pour cette requête. Un `injectionModel` natif non qualifié n’est qualifié par un compte que si la requête cible elle-même un sélecteur de compte explicite. Une valeur non qualifiée, non résolue ou ambiguë devient une chaîne vide ; un identifiant explicite qualifié par un compte ou un routage, même non résolu, reste inchangé |
+| `{{effort}}` | Le `injectionEffort` configuré, ou une chaîne vide |
+| `{{roster}}` | La liste résolue, visible par le sélecteur et compatible avec la surface |
+| `{{fallback}}` | Les conseils de repli globaux configurés |
+
+Le guide v2 intégré dispose d’un budget de 700 caractères. S’il devait dépasser ce budget, opencodex réduit
+la liste d'abord plutôt que de tronquer les instructions d'apparition principales. Le guidage intégré déclenche uniquement
+lorsqu'un modèle préféré, une liste éligible ou une chaîne de secours est résolu. Un `injectionModel` configuré
+est suffisant pour afficher une invite personnalisée ; si une valeur non qualifiée ne peut pas être résolue de manière unique, `{{model}}`
+se développe en une chaîne vide.
+
+Sur la v1, opencodex injecte uniquement les conseils de délégation proactive de style amont à `max` ou `ultra`
+effort. Il n’ajoute aucun modèle préféré, aucune liste, aucune chaîne de repli ni aucune invite personnalisée en v1.
+
+L'option `syncCodexSubagentDefaults` désactivée par défaut est distincte du guidage. Quand opencodex possède
+le routage Codex actif, la synchronisation ou le redémarrage peut écrire les valeurs sélectionnées en tant que propriété du marqueur
+entrées `[agents] default_subagent_model` et `default_subagent_reasoning_effort` dans Codex TOML.
+opencodex met à jour ou supprime uniquement les champs portant ses marqueurs. Si l'un des champs cibles appartient à l'utilisateur,
+la paire reste inchangée plutôt que partiellement écrite ; ambigu TOML est rejeté sans un
+écriture. Les gestionnaires de fournisseurs externes et le routage racine appartenant à l’utilisateur conservent également leur autorité.
+
+## Chaînes de repli
+
+Pour un travailleur généré, opencodex construit cet ordre de priorité :
+
+1. Le modèle primaire demandé.
+2. Une chaîne par modèle de `subagentModelFallbackByModel` dans opencodex config, saisie par
+ le modèle primaire demandé.
+3. La liste `subagentModelFallback` globale dans opencodex config.
+
+Les chaînes de secours par rôle appartiennent à opencodex config, pas à
+`$CODEX_HOME/agents/*.toml`. Codex 0.146+ désérialise strictement les fichiers de rôles d'agent et
+rejette `model_fallback` comme champ inconnu, ce qui ignore toute la définition du rôle
+(#1190). opencodex peut toujours lire une ligne `model_fallback` héritée du TOML pour
+compatibilité ascendante, mais `ocx doctor` en avertit et Codex lui-même ignorera
+le rôle concerné.
+
+Les identifiants de modèle en double sont supprimés tout en préservant la première occurrence. Lors de la sélection, opencodex
+ignore les candidats désactivés, non routables, soutenus par un fournisseur désactivé, marqués en mauvais état,
+pendant un temps de recharge, il manque un compte Codex poolé utilisable ou au-delà du seuil de quota configuré.
+Les sondes de disponibilité sont mises en cache pendant `subagentModelFallbackPollMs` (60 secondes par défaut).
+
+La solution de secours ne rend pas lisibles les tâches chiffrées incompatibles. Lorsque la tâche enfant est chiffrée pour
+ChatGPT, la sélection est restreinte aux cibles ChatGPT natives canoniques même si un modèle externe
+apparaît plus tôt dans la chaîne.
+
+## Livraison de tâches v2 cryptées
+
+Codex peut envoyer une tâche enfant v2 native vers routé uniquement sous forme `encrypted_content` chiffrée par le backend. Cela
+la charge utile peut être lue par le backend natif ChatGPT, mais pas par un fournisseur externe. C'est le
+connue [#92 limitation](https://github.com/lidge-jun/opencodex/issues/92).
+
+opencodex échoue en toute sécurité au lieu de transférer une tâche vide ou illisible :
+
+- Une route directe non native renvoie HTTP 400 avec
+ `error.code = "unreadable_encrypted_agent_task"` et ne fait pas écho au texte chiffré.
+- Un combo considère uniquement les cibles ChatGPT natives canoniques pour cette tâche, y compris les tentatives. Si aucun
+ est disponible, il renvoie la même erreur 400.
+- Une tâche lisible en texte clair conserve la route normale et le comportement de repli.
+
+Les options de récupération consistent à sélectionner un enfant ChatGPT natif, à ajouter une cible ChatGPT native au combo, à utiliser
+v1 pour la délégation de fournisseurs hétérogènes, ou renvoyer la tâche en texte brut v2 `agent_message`
+contenu lorsque vous contrôlez l’appelant.
+
+L’option expérimentale `agentTaskRecovery`, désactivée par défaut, peut récupérer cette forme précise de
+tâche native envoyée vers une route externe. Elle utilise un transfert Responses brut vers le point de
+terminaison ChatGPT `/responses` fixe et la forme d’identification entrante du fournisseur canonique
+`openai` configuré avec `authMode: "forward"`.
+
+Cette récupération est disponible uniquement lorsque le proxy écoute sur l’interface de bouclage. Elle ne
+substitue jamais une autre clé API, l’identifiant d’un autre fournisseur ou un autre compte Codex. Seuls les
+en-têtes `authorization`, `chatgpt-account-id` correspondant, `originator`, ainsi que les métadonnées
+facultatives `openai-beta` et `user-agent`, sont transmis. `content-type` et `accept` sont générés localement ;
+aucun autre en-tête de l’appelant ne franchit cette frontière.
+
+Cette opération consomme du quota, ajoute de la latence, conserve brièvement le texte récupéré dans un cache
+mémoire borné et dépend d’un comportement non documenté du service ChatGPT. Comme un modèle renvoie le texte
+récupéré, la fidélité octet par octet n’est pas garantie. Les appelants génériques ou authentifiés par clé API
+sont rejetés, et tout échec conserve l’erreur `unreadable_encrypted_agent_task`. Consultez
+[Configuration de l'agent : récupération de tâche chiffrée v2](/fr/reference/configuration/agents/#récupération-des-tâches-v2-chiffrées)
+pour la limite de confiance complète et la configuration.
+Le routage des combinaisons reste inchangé et continue de considérer uniquement les cibles ChatGPT natives
+canoniques pour les tâches chiffrées.
+
+## Changer le mode
+
+### GUI
+
+- **Tableau de bord** → première cellule statistique : choisissez **v1**, **base** ou **v2**.
+- **Modèles** → contrôle segmenté de la rangée supérieure : choisissez le même mode global.
+- **Tableau de bord** → **Délégation de sous-agent** : définissez les conseils model/effort et l'activation explicite natif par défaut.
+- **Sous-agents** : choisissez et ordonnez la liste, puis configurez la chaîne de repli globale.
+
+### CLI
+
+Utilisez `ocx v2` pour les paramètres de la surface de collaboration et des fonctionnalités natives :
+
+```bash
+ocx v2 status
+ocx v2 mode v1
+ocx v2 mode default
+ocx v2 mode v2
+ocx v2 threads 8
+```
+
+Utilisez `ocx agent` pour les paramètres de délégation, de liste, de plafond d'effort et de secours :
+
+```bash
+ocx agent status
+ocx agent injection set --model anthropic/claude-sonnet-5 --effort xhigh
+ocx agent subagents set gpt-5.6-sol,anthropic/claude-sonnet-5
+ocx agent fallback set gpt-5.4-mini,xai/grok-4.5 --poll-ms 60000
+ocx agent effort set --subagent max
+```
+
+Passez `-` pour effacer une valeur `ocx agent injection` nullable, ou utilisez l'action `clear` appropriée pour un
+liste ou chaîne de repli. Consultez la [référence CLI](/fr/reference/cli/) pour toutes les familles de commandes.
+
+### API
+
+La gestion API expose les points de terminaison correspondants `GET` et `PUT` :
+
+| Point de terminaison | Gère |
+| --- | --- |
+| `/api/v2` | Mode Surface, indicateur de fonctionnalité native et paramètres de thread |
+| `/api/injection-model` | Modèle préféré, effort, invite personnalisée, conseils et synchronisation native par défaut |
+| `/api/effort-caps` | Plafonds d'effort des agents principaux et des sous-agents |
+| `/api/subagent-models` | Liste commandée de cinq modèles maximum |
+| `/api/subagent-model-fallback` | Ordre de repli global et intervalle d'interrogation |
+
+Par exemple :
+
+```bash
+curl -X PUT http://localhost:10100/api/v2 \
+ -H 'Content-Type: application/json' \
+ -d '{"multiAgentMode":"v2"}'
+
+curl -X PUT http://localhost:10100/api/injection-model \
+ -H 'Content-Type: application/json' \
+ -d '{"model":"anthropic/claude-sonnet-5","effort":"xhigh"}'
+```
+
+## FAQ
+
+### Le choix d'un modèle de délégation oblige-t-il Codex à le générer ?
+
+Non. Les directives peuvent recommander un modèle et la synchronisation native des valeurs par défaut peut fournir une valeur par défaut à Codex, mais
+l’agent principal décide toujours s’il doit déléguer.
+
+### Pourquoi mon enfant v2 a-t-il utilisé le modèle parent ?
+
+Un fork v2 à historique complet hérite du modèle parent. Utilisez un spawn qui définit `fork_turns` sur `"none"` ou
+un décompte partiel positif avant de passer un dépassement de modèle ou d'effort.
+
+### Pourquoi un modèle configuré manque-t-il dans la liste v2 ?
+
+Il peut être masqué par le sélecteur, en dehors de la limite d'affichage de cinq modèles, absent du catalogue ou épinglé
+à la v1. Une valeur de surface `"v2"`, `null` ou absente est admissible ; une valeur explicite `"v1"` ne l’est pas.
+
+### Les changements de mode affectent-ils les sessions en cours ?
+
+Non. Démarrez une nouvelle session Codex après avoir changé de mode. Si un hôte App de longue durée affiche toujours des informations obsolètes
+état du catalogue, exécutez `ocx sync` et redémarrez cette surface Codex.
+
+### Que se passe-t-il lorsqu’opencodex ne peut pas considérer le catalogue comme fiable ?
+
+opencodex compare le catalogue de modèles sur disque à l'heure de démarrage de chaque Codex serveur d'applications détenu
+par l'utilisateur actuel, produisant l'un des quatre états suivants :
+
+| État | Signification | conseils v2 |
+|---|---|---|
+| `fresh` | Chaque serveur d'applications a démarré après la rédaction du catalogue | Conseils complets : modèle préféré, liste, solutions de secours |
+| `not_running` | Aucun serveur d'application détecté | Conseils complets |
+| `stale` | Au moins un serveur d'applications est antérieur au catalogue | **Aucune directive sur le modèle rédigé par opencodex** |
+| `unknown` | La comparaison n'a pas pu être faite | **Aucune directive sur le modèle rédigé par opencodex** |
+
+Pour `stale` et `unknown`, opencodex omet ses propres indications dérivées du disque — modèle préféré, liste,
+secours et conseils personnalisés - car le Codex en cours d'exécution peut ne pas être en mesure de générer ce que le disque
+catalogue annonce.
+
+Il ne demande **pas** au modèle d'arrêter le réglage `model` ou `reasoning_effort`. Cette observation est
+global sur chaque serveur d'applications pour l'utilisateur, alors qu'une requête entrante ne porte aucune identité d'expéditeur, donc
+un processus obsolète ne peut pas être attribué à la demande dont nous sommes saisis. Interdire les dérogations à ce sujet
+base bloquerait les options que l'outil actif `spawn_agent` annonce légitimement, pour une session qui
+peut très bien être à jour. Le schéma de l’outil actif reste la référence.
+
+`unknown` n'est pas synonyme de `stale`. Cela signifie que la comparaison elle-même a échoué – un catalogue illisible
+horodatage, une heure de début de processus illisible ou une énumération de processus ayant échoué - et cela est signalé
+séparément par `ocx doctor`. `stale` s'efface uniquement après chaque démarrage du serveur d'applications Codex détecté après
+la rédaction du catalogue final ; cela n'efface pas nécessairement `unknown`.
+
+Seul un vrai changement compte. Une synchronisation dont le résultat est identique en octets au catalogue déjà sur le disque
+laisse le fichier intact, donc le redémarrage du proxy ou la resynchronisation d'un ensemble de modèles inchangé ne le fait pas
+donner un aspect obsolète à un Codex en cours d'exécution.
+
+### Effort de raisonnement
+
+`injectionEffort` affecte uniquement le guidage des travailleurs délégués et, lorsqu'il est explicitement activé, le Codex natif
+valeurs par défaut du sous-agent. Cela ne change pas l'effort de la session parent. `ultra` est un haut orienté client
+niveau que Codex convertit en `max` ; opencodex mappe ou bloque ensuite la valeur du fournisseur sélectionné.
+
+### Limite de contexte
+
+La limite de contexte du modèle est indépendante du mode sous-agent. Configurez-le sur la page Modèles ; natif
+OpenAI les modèles conservent leurs fenêtres de contexte réelles.
diff --git a/docs-site/src/content/docs/fr/guides/video-bridge.md b/docs-site/src/content/docs/fr/guides/video-bridge.md
new file mode 100644
index 0000000000..d82df5e741
--- /dev/null
+++ b/docs-site/src/content/docs/fr/guides/video-bridge.md
@@ -0,0 +1,86 @@
+---
+title: Pont de génération de vidéos
+description: Générer des vidéos avec Grok Imagine Video depuis un modèle autre qu'OpenAI.
+---
+
+## Vue d'ensemble
+
+Le pont de génération de vidéos vous permet d'utiliser la génération Grok Imagine Video de xAI depuis
+n'importe quel modèle autre qu'OpenAI acheminé par opencodex. Lorsqu'il est activé, un outil synthétique
+`video_gen` est injecté dans la conversation. Le modèle l'appelle comme n'importe quel outil de fonction ;
+opencodex intercepte l'appel, soumet une tâche de génération vidéo à xAI, interroge son état jusqu'à son
+achèvement, puis télécharge le résultat.
+
+## Prérequis
+
+- Une entrée de fournisseur `xai` avec une **clé API** (`ocx login xai` seul ne suffit pas : le pont vidéo exige une authentification par clé, et non OAuth)
+- Un modèle autre qu'OpenAI comme fournisseur routé (par exemple Anthropic Claude ou Google Gemini)
+- opencodex configuré pour acheminer les requêtes vers ce fournisseur autre qu'OpenAI
+
+> **⚠ Clé de fournisseur obligatoire :** le pont vidéo ne s'active que si le fournisseur `xai` utilise
+> l'authentification par clé API. Ajoutez ceci à votre configuration :
+>
+> ```json
+> {
+> "providers": {
+> "xai": { "adapter": "openai-chat", "apiKey": "xai-…", "authMode": "key" }
+> }
+> }
+> ```
+>
+> Si vous avez configuré xAI avec `ocx login xai` (OAuth), le fournisseur reste en `authMode: "oauth"`
+> et le pont ne s'activera pas, sans produire d'erreur. Définissez `XAI_API_KEY` dans l'environnement
+> **ou** enregistrez directement la clé comme dans l'exemple ci-dessus.
+
+## Configuration
+
+Ajoutez `videoBridgeEnabled: true` à votre configuration `images` :
+
+```json
+{
+ "images": {
+ "bridgeEnabled": true,
+ "videoBridgeEnabled": true,
+ "videoBridgeModel": "grok-imagine-video",
+ "videoMaxRounds": 2,
+ "videoTimeoutMs": 300000
+ }
+}
+```
+
+| Option | Valeur par défaut | Description |
+|--------|---------|-------------|
+| `videoBridgeEnabled` | `false` | Interrupteur principal. Doit être activé explicitement. |
+| `videoBridgeModel` | `"grok-imagine-video"` | Identifiant du modèle vidéo xAI. |
+| `videoMaxRounds` | `2` | Nombre maximal de tours de génération vidéo avant une réponse finale forcée. |
+| `videoTimeoutMs` | `300000` (5 min) | Délai maximal par vidéo, interrogation comprise. |
+
+## Fonctionnement
+
+1. opencodex détecte qu'un modèle routé autre qu'OpenAI est utilisé avec `videoBridgeEnabled: true`.
+2. Un outil de fonction synthétique `video_gen` est injecté dans la conversation.
+3. Lorsque le modèle appelle `video_gen`, opencodex soumet une tâche à `/videos/generations` chez xAI.
+4. Le pont interroge l'état de la tâche toutes les 5 à 15 secondes et envoie des messages de maintien afin de garder le flux actif.
+5. Une fois la vidéo prête, elle est téléchargée dans le répertoire des artefacts.
+6. Le chemin du fichier local est renvoyé au modèle comme résultat de l'outil.
+
+## Paramètres pris en charge
+
+L'outil `video_gen` accepte les paramètres suivants :
+
+| Paramètre | Type | Plage | Description |
+|-----------|------|-------|-------------|
+| `prompt` | string | required | Invite détaillée de génération vidéo |
+| `duration` | integer | 1-15 | Durée de la vidéo en secondes |
+| `resolution` | string | `"480p"`, `"720p"` | Résolution de la vidéo |
+| `aspect_ratio` | string | 7 ratios | `16:9`, `9:16`, `1:1`, `4:3`, `3:4`, `3:2`, `2:3` |
+
+## Limitations
+
+- **xAI uniquement** : la génération vidéo est disponible exclusivement par l'intermédiaire de l'API Grok Imagine Video de xAI.
+- **Asynchrone** : la génération d'une vidéo prend de 30 à 120 secondes.
+- **Coût** : la génération vidéo est une fonctionnalité xAI payante (environ 0.05 $/s en 480p et 0.07 $/s en 720p).
+- **Une vidéo par appel** : chaque appel à `video_gen` produit une vidéo.
+- **Coexiste avec le pont de génération d'images** : les deux ponts peuvent être activés simultanément.
+- **Priorité à la recherche web** : lorsqu'un service auxiliaire de recherche web est actif pendant un tour (adaptateur autre que `runTurn`), le pont vidéo est ignoré ; les deux ne peuvent pas s'exécuter simultanément. Un `console.warn` est émis afin que vous puissiez le repérer dans les journaux.
+- **Le délai couvre la soumission et l'interrogation** : le budget `videoTimeoutMs` commence avant la soumission de la tâche ; l'appel de soumission (60 s) et les interrogations suivantes partagent donc la même échéance.
diff --git a/docs-site/src/content/docs/fr/guides/web-dashboard.md b/docs-site/src/content/docs/fr/guides/web-dashboard.md
new file mode 100644
index 0000000000..c6343f75b7
--- /dev/null
+++ b/docs-site/src/content/docs/fr/guides/web-dashboard.md
@@ -0,0 +1,183 @@
+---
+title: Tableau de bord web
+description: L'interface graphique d'opencodex pour l'état du proxy, les fournisseurs, les modèles, les consignes de délégation, les groupes d'authentification, l'utilisation et les journaux.
+---
+
+opencodex fournit un tableau de bord web local — une application Vite/React située sous `gui/` — servi par
+le proxy. C'est le moyen le plus direct de gérer les fournisseurs, les comptes Codex/ChatGPT, les modèles du
+catalogue, les services auxiliaires, les réglages des sous-agents et le trafic des requêtes.
+
+## Ouverture
+
+```bash
+ocx gui
+```
+
+Cette commande ouvre `http://localhost:` dans votre navigateur et démarre d'abord automatiquement le
+proxy si nécessaire. En développement, vous pouvez lancer séparément le serveur de développement de
+l'interface contre un proxy déjà actif :
+
+```bash
+ocx start
+bun run dev:gui
+```
+
+## Connexion
+
+Avec la liaison de bouclage par défaut (`localhost` / `127.0.0.1`), le tableau de bord ne demande jamais de
+jeton : le proxy insère dans la page servie des sessions d'interface graphique de courte durée et les
+renouvelle silencieusement à leur expiration ou au redémarrage du proxy. Seul un tableau de bord lié à un
+nom d'hôte hors bouclage exige le jeton administrateur (`OPENCODEX_ADMIN_AUTH_TOKEN`, ou le fichier généré
+automatiquement `~/.opencodex/admin-api-token`).
+
+Lorsqu'un tableau de bord distant exige cet identifiant, il présente un formulaire de mot de passe standard,
+ce qui permet au gestionnaire de mots de passe du navigateur de proposer son enregistrement et son
+remplissage automatique. Le tableau de bord lui-même ne conserve le jeton qu'en mémoire et ne l'écrit ni
+dans `localStorage` ni dans `sessionStorage` ; son enregistrement dépend entièrement du navigateur ou du
+gestionnaire de mots de passe.
+
+## Fonctions disponibles
+
+| Zone | Fonction |
+| --- | --- |
+| **Résumé du tableau de bord** | Mode multi-agent, état en ligne, version, durée de fonctionnement, nombre de fournisseurs, total de jetons sur 30 jours, fournisseurs actifs et modèles natifs/routés disponibles. |
+| **Délégation de sous-agent** | Choisissez un modèle natif ou routé et, facultativement, un effort de raisonnement partagés entre les consignes de délégation OpenCodex et l'option distincte de valeurs par défaut natives. Il ne s'agit pas d'un routeur par création de sous-agent côté proxy ; voir ci-dessous. |
+| **Services auxiliaires** | Choisissez le modèle et l'effort de recherche web, ainsi que le modèle de description visuelle. Les modifications s'appliquent à la requête suivante. |
+| **Maintenance** | Resynchronisez le catalogue de modèles Codex, examinez les avertissements de contournement par une configuration locale au projet, recherchez la dernière version stable ou préliminaire et lancez une mise à jour avec redémarrage facultatif du proxy. |
+| **Sécurité au démarrage** | Vérifiez si le routage Codex injecté résiste à un redémarrage, avec des états distincts pour le service et le lanceur intermédiaire, ainsi que les commandes de réparation exactes. |
+| **Zone de notification Windows** | Installez au niveau de l'utilisateur un contrôleur lancé à la connexion pour démarrer, arrêter ou redémarrer le proxy en un clic, ouvrir le tableau de bord et consulter l'état. Ce contrôleur n'est pas un service de redémarrage du proxy. |
+| **Démarrage automatique de Codex** | Autorisez un lanceur intermédiaire Codex déjà installé à exécuter `ocx ensure`. Ce commutateur n'installe ni lanceur ni service d'arrière-plan. |
+| **Fournisseurs** | Ajoutez, modifiez, activez, désactivez ou supprimez des fournisseurs, définissez le fournisseur par défaut parmi ceux activés et gérez, lorsqu'ils sont pris en charge, les groupes de comptes OAuth et de clés API. Si le fournisseur par défaut actuel est supprimé, le premier fournisseur activé restant prend sa place ; s'il n'en reste aucun, la suppression est refusée et le fournisseur par défaut actuel est conservé. Les réglages d'un fournisseur peuvent désactiver la découverte dynamique pour les points de terminaison dont le catalogue `/models` est absent, lent ou trop volumineux. Pour les groupes OAuth Claude (Anthropic), chaque compte connecté affiche ses propres barres de limites sur 5 heures et une semaine — l'utilisation est propre à chaque identifiant. En cas d'échec d'une sonde, les dernières barres connues sont conservées et marquées indisponibles jusqu'à la prochaine actualisation réussie. |
+| **Ajouter un fournisseur** | Recherchez dans les préréglages du registre une connexion par compte, un service à clé API, un serveur local ou un point de terminaison personnalisé. |
+| **Authentification Codex** | Ajoutez des comptes ChatGPT/Codex au groupe, sélectionnez le compte de la prochaine session, actualisez les quotas sur 5 h, une semaine et 30 jours, activez ou désactivez le changement automatique selon les quotas, réglez son seuil de 1 à 100 % et configurez le basculement en cas de défaillance transitoire. |
+| **Sous-agents** | Mettez en avant jusqu'à cinq modèles natifs non qualifiés ou modèles routés avec espace de noms dans la liste des remplacements de `spawn_agent`. |
+| **Modèles** | Activez ou désactivez les modèles GPT natifs et routés, définissez les listes d'autorisation et les plafonds de contexte des fournisseurs, choisissez v1/base/v2 et configurez la limite de fils v2. Les fournisseurs configurés restent visibles sous forme de groupes sans modèle lorsque la découverte est désactivée ou ne renvoie aucune ligne. |
+| **Journaux** | Actualisez automatiquement les requêtes récentes et consultez les jetons, l'effort demandé et, lorsqu'il est disponible, l'effort sortant effectif, le modèle résolu, le fournisseur, l'état, l'identifiant de requête, la durée et les détails de l'erreur. La vue détaillée inclut le champ exact de raisonnement transmis lorsque l'adaptateur en émet un. Filtrez par identifiant opaque de conversation ou de session — si le client en fournit un — afin d'obtenir le total des jetons et le coût estimé au tarif catalogue pour l'anneau de journaux actuellement chargé. |
+| **Utilisation / Débogage** | Examinez la couverture et les tendances d'utilisation des jetons, ou activez à la demande les diagnostics de transport et d'extraction de l'utilisation propres aux fournisseurs. |
+| **Stockage** | Consultez en lecture seule la répartition du disque de CODEX_HOME — sessions, archives, bases de données et pièces jointes. Pour le nettoyage facultatif des archives, prévisualisez les N % les plus anciennes, puis placez-les en quarantaine dans `CODEX_HOME/.trash` (par défaut) ou supprimez-les définitivement après avoir coché une case explicite. **La stratégie de nettoyage automatique** est facultative et **désactivée par défaut** (`storageCleanupPolicy.enabled`) ; configurez son seuil, sa cible, sa planification et son mode sur la page **Stockage**, ou lancez **Exécuter maintenant**. Les entrées mises en quarantaine peuvent être restaurées depuis cette page (JSONL et fils). Les sessions actives restent en lecture seule. Le nettoyage et la restauration sont refusés tant que Codex verrouille le fichier `state_*.sqlite` le plus récent ou actif. |
+| **Arrêter** | Arrêtez proprement le proxy et le service d'arrière-plan installé, restaurez Codex natif et quittez (`POST /api/stop`). |
+
+### Liens directs vers une section
+
+Il n'existe qu'une seule mise en page, donc aucun commutateur de disposition n'est à configurer. Les sections
+du tableau de bord possèdent plutôt leur propre adresse : `#dashboard` ouvre **Vue d'ensemble**, tandis que
+`#dashboard/providers` et `#dashboard/models` ouvrent les deux autres sections. Le rechargement, les favoris
+et le bouton **Précédent** conservent la section affichée. **Journaux** fonctionne de la même manière avec
+`#logs` et `#logs/debug`. Un ancien favori `#providers/workspace` ouvre désormais `#providers`.
+
+Les coûts affichés dans **Journaux** et **Utilisation** sont des équivalents au tarif catalogue de l'API,
+calculés à partir des jetons signalés. Ils ne constituent ni des reçus de facturation ni la preuve d'une
+dépense réelle ; un abonnement ou des crédits du fournisseur peuvent s'appliquer à la place.
+
+## Visibilité des modèles
+
+Les commutateurs de la page **Modèles** reflètent la visibilité Codex finale : un modèle routé est actif
+uniquement si la liste d'autorisation de son fournisseur l'inclut — ou si aucune liste n'est définie — et
+s'il n'est pas désactivé. Activer un modèle réconcilie atomiquement les deux filtres ; **Tout activer** efface
+la liste d'autorisation du fournisseur afin que les modèles découverts ultérieurement soient eux aussi actifs.
+
+## Sélecteur de délégation et routage des créations de sous-agents
+
+Le sélecteur **Délégation de sous-agent** du tableau de bord enregistre `injectionModel` et, facultativement,
+`injectionEffort`. L'option **Consignes multi-agents OpenCodex** contrôle indépendamment les instructions de
+délégation qui emploient ces valeurs. Pendant les tours v2 admissibles, ces consignes indiquent à l'agent
+parent le modèle exact et l'effort de raisonnement à transmettre à `spawn_agent` ; effacer le modèle efface
+aussi l'effort enregistré.
+
+Le commutateur **Utiliser comme valeurs par défaut des sous-agents Codex natifs**, désactivé par défaut,
+applique la même sélection aux valeurs par défaut `[agents]` natives de Codex lors de la synchronisation ou du
+redémarrage suivant, lorsque OpenCodex gère le routage Codex actif. Les configurations de fournisseurs externes
+gérées par l'utilisateur restent intactes. Ces valeurs par défaut concernent les nouvelles tâches Codex et ne
+provoquent pas à elles seules une délégation. Les valeurs `[agents]` existantes appartenant à l'utilisateur
+sont préservées au lieu d'être remplacées et peuvent donc continuer à primer sur celles demandées.
+
+:::caution
+Aucun de ces contrôles n'est un routeur intermodèle de création de sous-agents côté proxy. Les consignes
+OpenCodex demandent à Codex de transmettre les remplacements à `spawn_agent` ; les valeurs par défaut natives
+`[agents]` ne s'appliquent que lorsque Codex crée une nouvelle tâche après leur synchronisation. Consultez
+[Surface des sous-agents](/fr/guides/sub-agent-surface/) pour le comportement canonique v1/base/v2.
+:::
+
+La garantie de remplacement lors d'une création de sous-agent s'applique au texte de consignes v2 **intégré**.
+Un `injectionPrompt` personnalisé remplace entièrement ce texte et doit contenir les espaces réservés
+`{{model}}` et `{{effort}}` — et facultativement `{{roster}}` — sans quoi ces valeurs n'apparaîtront pas dans
+les consignes injectées.
+
+Le sélecteur propose les modèles natifs et routés activés, ainsi que l'échelle globale d'effort de Codex.
+L'API valide globalement l'effort choisi ; Codex continue de valider l'effort de création d'un sous-agent par
+rapport à l'entrée cible du catalogue.
+
+## Authentification Codex et groupes de comptes
+
+La page **Authentification Codex** gère la route ChatGPT/Codex native.
+
+Le mode Pool sélectionne parmi le compte Codex principal et les comptes ajoutés ; Direct utilise uniquement
+la connexion du compte appelant/principal. Les requêtes en cours conservent les identifiants qu'elles ont
+capturés. Une réauthentification 401/403 ou un temps de recharge 429 peut effacer l'affinité et faire passer
+la route à un autre compte Pool admissible. Ce mécanisme est distinct d'`openai-apikey` et des autres fournisseurs.
+
+- Choisir manuellement un compte s'applique immédiatement : un fil déjà associé y passe à sa prochaine requête, et seules les requêtes déjà en cours conservent le compte capturé. Le choix manuel est aussi épinglé : la fiche affiche le badge **ÉPINGLÉ**, et un ordre de sélection supérieur ne peut pas prendre la priorité sur ce compte avant son épuisement, la sélection d'un autre compte ou la modification de l'ordre de sélection de n'importe quel compte.
+- Chaque fiche de compte possède un contrôle **Ordre de sélection** (**Premier**, **Plus tôt**, **Normal**, **Plus tard**, **Dernier**). Les ordres supérieurs sont utilisés en premier ; le pool ne descend à un ordre inférieur qu'une fois tous les comptes supérieurs épuisés ou indisponibles. Un changement d'ordre s'applique dès la prochaine requête sans association et ne déplace jamais un fil déjà associé. Le compte Codex Desktop principal est ordonné comme les autres : il peut être placé en **Dernier** et conservé comme réserve. Un ordre défini avec `ocx account priority` en dehors de ces cinq préréglages reste visible et sélectionnable sur la fiche.
+- L'affinité des fils évite les changements à chaque requête. Lorsque le changement automatique selon les quotas est activé, un fil de longue durée est réévalué périodiquement et peut être réassocié quand son utilisation pertinente atteint le seuil et qu'il existe un compte admissible dont l'utilisation est strictement inférieure.
+- Les nouvelles sessions peuvent choisir le compte admissible le moins utilisé. Pour les forfaits payants, le score retient la fenêtre connue la plus sollicitée parmi 5 h, une semaine et 30 jours ; les forfaits Go/Free utilisent uniquement la fenêtre de 30 jours.
+- Lorsque WHAM fournit `limit_window_seconds`, **Authentification Codex** classe une fenêtre principale d'au moins 28 jours comme une fenêtre de 30 jours au lieu de supposer que toute fenêtre principale est hebdomadaire. Les réponses sans durée conservent l'ancienne interprétation hebdomadaire.
+- **Actualiser les quotas** relit immédiatement l'utilisation des comptes afin que le routage et les fiches utilisent les mêmes valeurs.
+- Les journaux des requêtes du pool utilisent des libellés opaques comme `p3fa91c`, jamais les adresses courriel des comptes.
+- Chaque fiche affiche aussi ce libellé stable de journal, le total de jetons observé sur 30 jours, un coût approximatif équivalent à l'API selon les tarifs d'affichage actuellement configurés et la proportion de tentatives dont l'utilisation a été mesurée. Les remplacements `modelCosts` actifs de l'utilisateur priment sur le catalogue vérifié fourni et les tarifs de secours ; l'utilisation historique est réestimée d'après les tarifs actifs au moment de la lecture du résumé. Ce coût sert au rapprochement et reste une estimation, pas une facture d'abonnement ChatGPT Plus/Pro. Les anciennes lignes `openai` non qualifiées antérieures à l'attribution explicite restent ambiguës au lieu d'être affectées au compte principal actuel.
+- **Cibler un compte Codex précis depuis le sélecteur de modèles** est une option explicite. Lorsqu'elle est activée, les lignes GPT ordinaires prises en charge sont remplacées par une entrée par sélecteur public de compte. En choisir une verrouille cette conversation sur le compte associé : elle ne change pas de compte, ne se rabat pas et ne modifie pas le compte Pool actif. La connexion intégrée de Codex App possède son propre sélecteur ; les tables générées utilisent normalement `main`, avec un suffixe sans collision comme `main-2` si nécessaire. Les comptes ajoutés reçoivent des libellés stables qui préservent la confidentialité, et les libellés personnalisés existants sont conservés. Les conversations existantes et les sélections de modèles enregistrées continuent d'être routées. Désactiver le réglage masque les entrées générées sans supprimer les comptes, les sélecteurs ni les routes exactes. Les identifiants GPT non qualifiés continuent d'employer le comportement Pool ou Direct configuré.
+- Les changements d'ajout, de suppression et de réglage des sélecteurs de compte sont enregistrés avant l'actualisation du catalogue de modèles. Si cette actualisation limitée dans le temps n'aboutit pas, le tableau de bord affiche un avis orange indiquant la réussite et la procédure de récupération ; exécutez `ocx sync` pour réessayer. Le changement de compte ou de réglage reste enregistré.
+
+La vue d'ensemble des **Fournisseurs** résume séparément l'utilisation du mode Pool sous forme d'une estimation
+pondérée de la capacité destinée uniquement à l'affichage, avec le quota brut du compte effectif et la
+prochaine récupération de capacité. Consultez
+[Capacité du pool dans la vue d'ensemble des fournisseurs](/fr/guides/providers/#aperçu-de-la-capacité-du-pool-des-fournisseurs)
+pour les champs affichés, la signification d'une couverture incomplète et la limite de cette information au routage.
+
+## Mettre le dépôt en vedette relève de votre choix, pas de celui d'un agent
+
+Le bouton étoile de la barre latérale — et la question unique posée par `ocx start` dans un terminal
+interactif — utilise **votre propre connexion `gh`**. opencodex ne détient aucun jeton GitHub et apprend
+uniquement votre réponse affirmative ou négative.
+
+Comme cette action écrit dans votre compte GitHub, les appels pilotés par un agent sont refusés au lieu
+d'être autorisés à répondre à votre place :
+
+- `ocx start` et `ocx service install` **ignorent entièrement la question** lorsqu'ils sont pilotés par un agent ou un environnement CI (`CLAUDECODE`, `CODEX_THREAD_ID`, `CURSOR_TRACE_ID`, `CI` et équivalents). Le marqueur unique n'est pas écrit : la véritable question apparaîtra encore lors de votre prochaine exécution manuelle. L'agent reçoit l'instruction de vous la poser directement, sous la forme d'un choix clair **Oui/Non** exigeant votre réponse, et non d'une remarque discrète qu'il pourrait contourner. Si vous ne répondez pas, il doit vous la poser de nouveau plutôt que d'interpréter votre silence comme un refus.
+- `POST /api/github/star` répond `403` avec `code: "agent_consent_required"` lorsque le proxy s'exécute dans une session d'agent et que la requête ne possède aucune session de navigateur du tableau de bord. Détenir le jeton administrateur ne vaut pas consentement : un agent sur votre machine peut lire ce fichier.
+- Le bouton du tableau de bord continue de fonctionner normalement. Un véritable clic apporte la preuve d'une session de même origine ; il est donc reconnu comme provenant de vous, même si un agent a démarré le proxy.
+- Un refus met fin à la demande. Rien n'est conservé et rien n'est ajouté à une invite de modèle pour vous inciter à accepter plus tard.
+
+## Communication entre le tableau de bord et le proxy
+
+L'interface graphique est un client léger de l'API JSON de gestion du proxy. Parmi les points de terminaison utiles :
+
+| Point de terminaison | Fonction |
+| --- | --- |
+| `GET` / `PUT /api/settings` | Lire les réglages ou modifier le démarrage automatique de Codex, les paramètres de flux et de mémoire, ainsi que la visibilité du sélecteur ciblant les comptes. |
+| `GET` / `POST /api/github/star` | Lire l'état de mise en vedette dérivé de `gh` ou mettre le dépôt en vedette. Le POST est refusé avec `403` et `agent_consent_required` pour les appels pilotés par un agent sans session de tableau de bord. |
+| `GET /api/startup-health` | Lire, sans secrets, les diagnostics de routage, de service, de lanceur intermédiaire et de sécurité au redémarrage. |
+| `POST /api/startup-action` | Installer le service d'arrière-plan ou le lanceur intermédiaire Codex au moyen d'actions fixes et autorisées. |
+| `GET` / `POST /api/windows-tray` | Lire ou modifier l'installation de la zone de notification Windows et l'état du processus visible. POST accepte `install`, `start`, `stop` ou `uninstall`. |
+| `POST /api/sync` | Reconstruire le catalogue de modèles partagé et rendre obsolète le cache de modèles Codex. |
+| `GET /api/update/check` · `POST /api/update/run` · `GET /api/update/status` | Rechercher, exécuter et surveiller les tâches d'auto-mise à jour. Les PID des processus sont conservés pour qu'une tâche interrompue récupère automatiquement ; les anciennes tâches sans PID récupèrent après dix minutes. |
+| `GET` / `PUT /api/sidecar-settings` | Lire ou définir les modèles des services auxiliaires de recherche et de vision. |
+| `GET` / `PUT /api/injection-model` | Lire ou définir le choix partagé du modèle et de l'effort du sous-agent, ainsi que les commutateurs indépendants de consignes et de valeurs par défaut natives. |
+| `GET` / `PUT /api/v2` | Lire ou définir le mode de surface, l'indicateur de fonctionnalité Codex et la limite de fils v2. |
+| `GET /api/providers` · `POST /api/providers` · `PATCH /api/providers?name=...` · `DELETE /api/providers?name=...` | Répertorier, ajouter/remplacer, activer/désactiver, définir par défaut ou supprimer des fournisseurs. `PATCH` emploie seul `{ "setDefault": true }` sur un fournisseur activé ; `POST` peut inclure `setDefault` lors d'une création ou d'un remplacement, également sur un fournisseur activé uniquement. Supprimer le fournisseur par défaut actuel affecte le premier fournisseur activé restant, s'il en existe un ; sinon, l'API renvoie `409` avec `code: "last_provider"` et conserve le fournisseur par défaut actuel. |
+| `GET /api/models` · `PUT /api/disabled-models` | Répertorier les lignes de modèles natifs/routés et mettre à jour l'ensemble partagé des modèles désactivés. |
+| `GET /api/selected-models` · `PUT /api/model-visibility` | Lire les listes d'autorisation des fournisseurs et modifier atomiquement la visibilité finale d'un modèle ou d'un groupe de fournisseurs. |
+| `GET /api/key-providers` · `GET /api/oauth/providers` | Lire les catalogues de fournisseurs à clé API et OAuth. |
+| `POST /api/oauth/login` · `GET /api/oauth/status` | Démarrer le flux OAuth d'un fournisseur et interroger son état jusqu'à son achèvement. |
+| `GET /api/codex-auth/accounts?refresh=1` | Répertorier le compte principal et les comptes du pool, forcer l'actualisation des quotas et signaler les états `hasCredential` du compte principal et `needsReauth` définitif. |
+| `PUT /api/codex-auth/active` · `PUT /api/codex-auth/auto-switch` · `PUT /api/codex-auth/failover` | Sélectionner le compte de la prochaine requête et configurer le routage du pool. |
+| `GET /api/codex-auth/active` · `PUT /api/codex-auth/accounts/priority` | Lire le compte effectif — notamment `pinned` et le compte désigné par `pinnedAccountId` — et définir l'ordre de sélection d'un compte. |
+| `POST /api/codex-auth/login` · `GET /api/codex-auth/login-status` | Ajouter un compte au groupe au moyen d’une connexion dans le navigateur. |
+| `GET /api/logs?tail=50&limit=20&offset=0&provider=...&status=5xx` | Lire les métadonnées des requêtes récentes avec des filtres facultatifs de fin de journal, de fournisseur et d'état exact ou par classe. Avec `limit`/`offset`, la pagination remonte depuis la ligne la plus récente (`offset=0` renvoie la dernière page). Forme de la réponse : `{ timeZone, total, logs }`, où `total` est le nombre de lignes filtrées avant pagination. |
+| `GET` / `PUT /api/subagent-models` | Lire ou définir les cinq modèles de remplacement `spawn_agent` mis en avant. |
+| `POST /api/stop` | Arrêter le proxy et le service, restaurer Codex natif et quitter. |
+
+:::tip
+L'ajout d'**Ollama Cloud** ou d'un autre fournisseur doté d'un catalogue depuis le tableau de bord copie sa
+classification texte/vision dans la configuration enregistrée du fournisseur. Le
+[service auxiliaire de vision](/fr/guides/sidecars/) est ainsi correctement conditionné sans classification manuelle.
+:::
diff --git a/docs-site/src/content/docs/fr/index.mdx b/docs-site/src/content/docs/fr/index.mdx
new file mode 100644
index 0000000000..f482f1fe67
--- /dev/null
+++ b/docs-site/src/content/docs/fr/index.mdx
@@ -0,0 +1,19 @@
+---
+title: "opencodex — Exécutez Codex sur n’importe quel LLM"
+description: Proxy universel de fournisseurs pour OpenAI Codex et Claude Code — utilisez n’importe quel LLM avec Codex CLI, App, SDK et Claude Code.
+template: splash
+head:
+ # La marque d'abord, pas de suffixe « | opencodex » : Google compare le nom du site avec
+ # le titre de la page d'accueil, donc le mot-symbole mène et n'est pas dupliqué.
+ - tag: title
+ content: "opencodex — Exécutez Codex sur n’importe quel LLM"
+ - tag: meta
+ attrs:
+ property: og:locale
+ content: fr_FR
+tableOfContents: false
+---
+
+import Landing from '../../../components/Landing.astro';
+
+;
+ fetchResponse?(request: AdapterRequest, ctx?: AdapterFetchContext): Promise;
+ parseStream(response: Response, budget: TranslatorBudget): AsyncGenerator;
+ parseResponse?(response: Response, budget: TranslatorBudget): Promise;
+ runTurn?(parsed: OcxParsedRequest, incoming: IncomingMeta, emit: (event: AdapterEvent) => void): Promise;
+}
+```
+
+`buildRequest` transforme un `OcxParsedRequest` en requête HTTP en amont ; `parseStream` / `parseResponse` reconvertissent la réponse du fournisseur en événements `AdapterEvent` internes. `fetchResponse` permet à l’adaptateur de gérer lui-même les nouvelles tentatives et les délais d’expiration, tandis que `runTurn` prend en charge les transports qui ne peuvent pas être représentés par une seule requête HTTP suivie d’un flux de réponse. [`bridge.ts`](/fr/reference/architecture/#pont) transforme ensuite ces événements en flux SSE Responses.
+
+`incoming` est un `IncomingMeta` obligatoire qui transporte notamment les en-têtes, le signal d’abandon et le budget de traduction. Le contexte facultatif de `fetchResponse` est un `AdapterFetchContext`. Les méthodes d’analyse reçoivent elles aussi un `TranslatorBudget` obligatoire afin de borner les données traduites.
+
+## `openai-chat`
+
+**Cibles :** l’API **Chat Completions** d’OpenAI (`POST {baseUrl}/chat/completions` ; un suffixe `/chat/completions` ou `/` est d’abord retiré de `baseUrl`) et tous les fournisseurs compatibles — xAI, Kimi, DeepSeek, GLM, Groq, OpenRouter, Ollama (local et cloud), entre autres.
+**Authentification :** `key` (Bearer).
+
+- Convertit les messages internes en rôles OpenAI ; mappe les outils vers `{type:"function", function:{…}}` et `tool_choice` (`auto`/`none`/`required` ou une fonction nommée).
+- **Images renvoyées par un outil :** elles sont placées dans un message utilisateur de vision ultérieur (parties `image_url`), émis à la fin du tour d’outil, car le contenu du rôle `role:"tool"` ne peut être que textuel. Le marqueur `[image]` reste dans le message d’outil comme point d’ancrage.
+- **Réécrit le prompt d’identité GPT-5 de Codex** sous une forme indépendante du modèle afin que les modèles routés ne prétendent pas être OpenAI.
+- **Limite `reasoning_effort`** au sous-ensemble annoncé par le modèle lorsque le niveau exact n’est pas disponible ; `xhigh` et `max` restent des libellés distincts, sauf si un fournisseur configure explicitement un alias. L’adaptateur **omet entièrement ce champ** pour les identifiants figurant dans `provider.noReasoningModels`.
+- Diffuse `delta.content` (texte), `delta.reasoning_content` (raisonnement) et `delta.tool_calls[]`, et recueille `usage`.
+- ClinePass utilise le format de passerelle vérifié en conditions réelles `reasoning: { enabled: true, effort: "low" }` (ou `{ enabled: false }` lorsque le raisonnement est désactivé). Sa documentation publique d’API ne précise pas encore cette forme de requête. L’adaptateur limite les autres niveaux demandés au niveau `low` vérifié, accepte les deltas de raisonnement provenant de `delta.reasoning_content` ou de `delta.reasoning`, demande les données d’utilisation en flux avec `stream_options.include_usage` et lit ces données dans les enveloppes de réponse hors flux.
+
+## `openai-responses`
+
+**Cibles :** l’API **Responses** d’OpenAI. **`passthrough: true`** — transmet tel quel le corps brut de la requête et renvoie le flux de réponse **sans traduction**.
+**Authentification :** `forward` (transmission des en-têtes de l’appelant) ou `key`.
+
+Avec l’authentification `key`, [`retryOn429`](/fr/reference/configuration/) s’applique également : en cas de réponse 429 avant le début du flux, l’adaptateur attend puis rejoue à l’identique la requête avec la même clé avant tout autre traitement, exactement comme sur les chemins traduits `openai-chat` / Anthropic. Les transports `runTurn` personnalisés ne font pas partie de cette boucle de nouvelles tentatives HTTP.
+
+- L’analyseur Responses sans état de DeepSeek reçoit une normalisation de l’historique propre au fournisseur : le contexte injecté par un hook est déplacé après un lot non ambigu d’appels d’outils et de résultats. Les appels parallèles restent regroupés avant les sorties correspondantes, de sorte que chaque appel demeure dans le tour assistant qui porte le raisonnement. Pour les fournisseurs tolérants, ainsi que lorsque des identifiants d’appel sont dupliqués, manquants, ambigus ou désordonnés, l’ordre d’entrée d’origine est conservé.
+- URL en mode `forward` → `{baseUrl}/responses`. Un fournisseur `key` utilise par défaut l’ancienne construction `{baseUrl}/v1/responses`.
+- Un fournisseur `key` peut définir un chemin relatif validé dans `responsesPath` ; l’adaptateur retire une barre oblique finale de `baseUrl` et envoie la requête vers `{trimmedBaseUrl}{responsesPath}`. Pour Ark Agent Plan, utilisez `baseUrl: "https://ark.cn-beijing.volces.com/api/plan/v3"` avec `responsesPath: "/responses"`.
+- En mode `forward`, seule une liste sûre d’en-têtes autorisés (`FORWARD_HEADERS`) est transmise : l’autorisation, l’identifiant de compte ChatGPT et les en-têtes OpenAI beta/originator/session. C’est le chemin de connexion ChatGPT également utilisé par les [services auxiliaires](/fr/guides/sidecars/).
+
+## `anthropic`
+
+**Cibles :** l’API **Messages** d’Anthropic (`/v1/messages`).
+**Authentification :** `key` (`x-api-key` par défaut, ou `Authorization: Bearer` avec `apiKeyTransport: "bearer"`) ou `oauth` (Bearer + `anthropic-beta`, pour Claude Pro/Max).
+
+- Convertit les messages en blocs de contenu Anthropic (texte, image base64, `tool_use`, `thinking`).
+- **Calcul du raisonnement étendu :** Anthropic exige `max_tokens > thinking.budget_tokens`. L’adaptateur associe l’effort de raisonnement à un budget (minimal 1024 … max 32000), calcule ensuite une valeur sûre de `max_tokens` avec une marge pour la sortie et **supprime `temperature`/`top_p`** lorsque le raisonnement est activé, car Anthropic les interdit dans ce cas.
+- **Sortie structurée :** les requêtes Responses `text.format` et Chat Completions `response_format` dont le type est `type: "json_schema"` deviennent `output_config.format` dans Anthropic. Le format est fusionné avec une configuration de sortie de raisonnement adaptatif existante, tout en préservant un `output_config.effort` compatible. Les requêtes Anthropic Messages routées conservent ce même format lors de la traduction OAuth stockée. L’adaptateur reproduit le sous-ensemble de JSON Schema pris en charge par le SDK TypeScript d’Anthropic : les contraintes non prises en charge sont déplacées dans `description` à titre d’instructions pour le modèle, `oneOf` devient `anyOf` et les schémas d’objet reçoivent `additionalProperties: false`. Une racine `$ref` conserve le `$defs` adjacent afin que la référence locale reste résoluble. Les champs d’enveloppe OpenAI tels que le `name` du schéma, la `description` de l’enveloppe et `strict` ne font pas partie du protocole Anthropic. Le mode objet JSON sans schéma n’a pas d’équivalent Anthropic et n’est pas traduit.
+- Envoie toujours `anthropic-version: 2023-06-01`. Diffuse `content_block_delta` (`text_delta`, `thinking_delta`, le compatible `reasoning_delta`, `input_json_delta`). Le décodeur SSE conserve l’état des événements d’un fragment reçu à l’autre et accepte un événement terminal `message_stop` sans saut de ligne final.
+- Pour les tours Responses routés vers Anthropic avec des outils clients, une garde terminale bornée détecte le cas hautement probable où l’utilisateur a demandé une action, mais où Claude termine en affirmant l’avoir exécutée sans appeler d’outil. Elle effectue au plus une continuation interne ; les réponses normales, les demandes de précision, les tours qui utilisent un outil et les réponses incomplètes au niveau du transport ne sont pas relancés automatiquement.
+
+## `google`
+
+**Cibles :** **Gemini** de Google, **Vertex AI** et **Cloud Code Assist** d’Antigravity. AI Studio utilise `/v1beta/models/{model}:streamGenerateContent` ; les autres modes utilisent leurs points de terminaison Google natifs.
+**Authentification :** clé d’API, ADC Vertex ou OAuth Google Antigravity, selon `googleMode`.
+
+- Prompt système → `systemInstruction` ; messages → `contents[]` (assistant → `model`) ; outils → `functionDeclarations`. Images sous forme d’URL de données → `inline_data`.
+- Les identifiants d’appel d’outil sont générés lorsque Gemini les omet. Vertex et Antigravity conservent et rejouent les valeurs opaques `thoughtSignature` afin que les continuations après résultat d’outil préservent la continuité du raisonnement Gemini. Le cache des signatures est enregistré dans le répertoire de configuration ; les continuations survivent donc également aux redémarrages du proxy.
+- **Sortie d’image intégrée :** lorsque le modèle correspond à l’un des identifiants de chat explicitement capables de produire des images (`gemini-3.1-flash-image`, `gemini-2.0-flash-preview-image-generation` ou `gemini-3-pro-image-preview`), l’adaptateur envoie `responseModalities: ["TEXT", "IMAGE"]`. Les identifiants dédiés à la génération de médias, tels que `gemini-3-pro-image`, ne sont pas inclus. Les parties `inlineData` renvoyées sont matérialisées dans le répertoire `artifacts/` d’OpenCodex configuré et exposées sous forme de liens d’image Markdown vers la route opaque authentifiée `/v1/opencodex/artifacts/` (et non sous forme d’URI `file:` ou de chemins du système de fichiers hôte). Chaque image est limitée à 50 MB et chaque réponse à 100 MB de données décodées ; les charges utiles base64 mal formées sont rejetées. Les artefacts sont automatiquement élagués lorsque leur nombre dépasse 200 fichiers.
+
+## `kiro`
+
+**Cibles :** le service Amazon CodeWhisperer Streaming `GenerateAssistantResponse` utilisé par Kiro (`https://runtime.{region}.kiro.dev/`).
+**Authentification :** jeton d’accès OAuth Kiro en Bearer, accompagné des métadonnées region/profile issues de l’identifiant Kiro.
+
+- Construit le `conversationState` de Kiro, mappe les outils Codex et leurs résultats, puis envoie les blocs d’image pris en charge par le protocole Kiro.
+- Décode `application/vnd.amazon.eventstream`, reconstruit les événements de texte, de raisonnement et d’outil, détecte les données JSON d’outil tronquées et estime l’utilisation, car le service en amont ne renvoie aucun nombre de jetons.
+- Utilise à l’identique le `baseUrl` configuré lorsqu’il est personnalisé. Une URL canonique `runtime.{region}.kiro.dev` suit la région d’API de l’identifiant importé ; seule cette forme canonique peut faire l’objet d’un unique repli borné vers `q.{region}.amazonaws.com` après un échec de point de terminaison, de signature, de DNS ou de connexion.
+- Gère la récupération après réinitialisation de connexion lorsqu’un rejeu est sûr, cet unique repli de point de terminaison admissible, une actualisation OAuth suivie d’un rejeu après une réponse HTTP 401, ainsi qu’une récupération bornée pour les réponses Kiro 429 transitoires. Un délai de récupération partagé et une seule sonde après ce délai empêchent les requêtes concurrentes d’épuiser des budgets de nouvelle tentative indépendants ; les dépassements fermes de quota et les erreurs de service ordinaires ne sont pas rejoués.
+- Son analyseur hors flux consomme le même flux d’événements pour la boucle de recherche Web.
+
+### Sémantique d’achèvement
+
+Le texte de l’assistant Kiro ne comporte pas, à lui seul, de phase fiable indiquant la fin du tour. Son événement terminal `metadataEvent` peut contenir un `stopReason` natif, mais Kiro peut étiqueter comme `END_TURN` un texte qui ne décrit que la progression. Lors des tours avec outils, `END_TURN` et `STOP_SEQUENCE` prouvent donc uniquement que l’inférence s’est arrêtée ; le texte ordinaire reste un commentaire et passe par l’unique validation d’achèvement bornée.
+
+`END_TURN`, `STOP_SEQUENCE` ou l’absence de motif d’arrêt peuvent emprunter le chemin de compatibilité. Les autres motifs explicites ont déjà interrompu l’inférence en amont ; l’adaptateur les signale donc au lieu de consommer une nouvelle requête au modèle. Une limite de jetons de sortie est présentée comme une sortie incomplète que le client peut poursuivre, tandis qu’un épuisement de la fenêtre de contexte devient une erreur de longueur de contexte non renouvelable plutôt qu’une sortie tronquée. Les arrêts dus au filtrage et aux garde-fous sont présentés comme des sorties filtrées incomplètes. Un arrêt `TOOL_USE` sans appel d’outil réel est signalé comme une contradiction, et non comme une progression.
+
+Lorsqu’un outil client ordinaire est disponible, opencodex ajoute un outil privé `codex_kiro_final_answer` à la requête en amont. Le texte de progression est diffusé comme commentaire et ne peut pas clore le tour. L’adaptateur consomme l’appel privé, émet sa réponse comme texte final et n’expose jamais cet outil privé à Codex ou Claude Code. Le motif d’arrêt n’arrivant qu’à la fin du flux, le texte de l’assistant est retenu pendant un tour avec outils jusqu’au début d’un véritable appel d’outil ou jusqu’à la fin du flux. Il est alors libéré comme commentaire, sauf si l’outil privé a fourni la réponse finale. Lorsque le service auxiliaire de recherche Web est actif, les commentaires libérés continuent d’être diffusés avant l’événement terminal ; seuls les événements nécessaires pour déterminer si le modèle a demandé une recherche synthétique restent en mémoire tampon.
+
+Si Kiro s’arrête sans appeler l’outil d’achèvement, l’adaptateur effectue une continuation. Les nouvelles tentatives ne contenant que du raisonnement conservent le tour utilisateur/résultat d’outil valide d’origine au lieu de fabriquer un message assistant vide ; la progression visible est rejouée avec une instruction non vide appartenant à l’adaptateur. Avant le transport, la conversation générée est contrôlée afin de vérifier l’alternance des rôles, l’absence de tours structurels vides et la correspondance des identifiants d’utilisation et de résultat d’outil. Une sortie d’outil vide reçoit un texte de remplacement neutre et non vide. La nouvelle tentative ne peut pas se répéter récursivement : si elle est vide ou ne contient que du raisonnement, elle est renvoyée comme incomplète mais renouvelable ; un véritable appel d’outil client maintient le tour ouvert. Une réponse de l’outil d’achèvement est toujours émise comme `final_answer`, même si elle répète exactement un commentaire antérieur, car l’exactitude de la phase prime sur la déduplication esthétique. Les requêtes sans outil conservent le comportement normal d’achèvement textuel.
+
+### Effort de raisonnement
+
+`gpt-5.6-sol` et `claude-opus-5` prennent en charge nativement un niveau d’effort vérifié, mais chaque famille de modèles nomme différemment le champ de la requête. La valeur sélectionnée `low`, `medium`, `high`, `xhigh` ou `max` est envoyée dans `additionalModelRequestFields.reasoning.effort` pour `gpt-5.6-sol`, et dans `additionalModelRequestFields.output_config.effort` pour `claude-opus-5`. Les autres modèles Kiro utilisent actuellement un raisonnement émulé : opencodex convertit le niveau choisi en instructions de réflexion bornées dans le contenu utilisateur, car leur champ d’effort natif n’a pas été vérifié. La présence d’un contrôle d’effort annoncé sur ces modèles ne prouve donc pas la prise en charge native du raisonnement en amont.
+
+## `cursor`
+
+**Cibles :** `agent.v1.AgentService/Run` de Cursor, en flux HTTP/2 Connect sur `api2.cursor.sh`.
+**Authentification :** jeton OAuth/d’accès Cursor provenant de `provider.apiKey` ou de l’en-tête d’autorisation transmis.
+
+- Utilise `runTurn` plutôt que le chemin habituel fetch/parse. Les requêtes, événements serveur, arguments d’outil, points de contrôle de l’utilisation et réponses du client sont encodés avec les schémas `@bufbuild/protobuf` de `cursor/gen/agent_pb.ts`, puis encadrés comme messages Connect.
+- Rejoue l’état de la conversation au moyen de blobs adressés par leur contenu, remappe les appels d’outils du serveur vers Codex, découvre les modèles Cursor disponibles en direct au moyen de l’appel RPC protobuf `GetUsableModels` et ne relance une opération qu’avant que la requête d’exécution ait été écrite sur le transport.
+- Expose Cursor Router sous `cursor/auto`, ainsi que les entrées explicites `cursor/auto-cost`, `cursor/auto-balance` et `cursor/auto-intelligence`. Les niveaux explicites sont encodés dans `requested_model.parameters`, tandis que l’ancienne entrée `cursor/auto` conserve la valeur par défaut du compte ou de l’équipe.
+- Envoie les niveaux ordinaires de `cursor/grok-4.5` avec les identifiants de protocole exacts issus de la découverte en direct de Cursor (`cursor-grok-4.5-low`, `-medium` ou `-high`). `cursor/grok-4.5-fast` reste sélectionnable, mais le modèle canonique `grok-4.5` est envoyé avec des paramètres distincts `effort` et `fast=true`.
+- L’exécution locale native de commandes sur le système de fichiers, le shell ou le réseau par Cursor est refusée par défaut. Les intégrations explicites `mcpServers` et `desktopExecutor` disposent d’activations distinctes ; `nativeLocalExec: "on"` active l’exécuteur intégré plus large et contourne la sémantique d’approbation et de bac à sable de Codex. L’ancien réglage `unsafeAllowNativeLocalExec: true` reste équivalent uniquement lorsque `nativeLocalExec` n’est pas défini.
+
+## `azure-openai` (alias : `azure`)
+
+**Cibles :** **Azure OpenAI**. Encapsule `openai-responses` (et utilise donc également `passthrough: true`).
+**Authentification :** `key` au moyen de l’en-tête `api-key` (et non Bearer).
+
+- Délègue la construction de la requête au relais Responses, vérifie que `baseUrl` ne contient aucun espace réservé de modèle non résolu et remplace `Authorization` par `api-key`. L’URL configurée cible directement l’API Responses v1 d’Azure ; l’adaptateur n’ajoute donc pas `api-version`.
+
+## Utilitaires d’image (`image.ts`)
+
+Fonctions partagées par les adaptateurs qui prennent en charge la vision :
+
+- `parseDataUrl(url)` — sépare une URL `data:;base64,` en `{ mediaType, base64 }` pour les blocs d’image Anthropic/Google.
+- `contentPartsToText(content)` — aplatit les parties de contenu en texte pour les messages d’outil purement textuels (une image sans description devient un court marqueur `[image]`, jamais un blob base64 qui consommerait énormément de jetons).
diff --git a/docs-site/src/content/docs/fr/reference/architecture.md b/docs-site/src/content/docs/fr/reference/architecture.md
new file mode 100644
index 0000000000..e57f2dc76a
--- /dev/null
+++ b/docs-site/src/content/docs/fr/reference/architecture.md
@@ -0,0 +1,112 @@
+---
+title: Architecture
+description: Composants internes d’opencodex — carte des modules, pont AdapterEvent, analyseur de requêtes et mise en cache.
+---
+
+opencodex s’exécute dans un seul processus Bun. Une requête arrive au format OpenAI Responses, est normalisée dans un modèle interne, routée, envoyée au fournisseur par un adaptateur, puis reconvertie en flux SSE Responses. Consultez [Fonctionnement](/fr/getting-started/how-it-works/) pour suivre le flux de bout en bout.
+
+## Carte des modules
+
+```text
+src/
+├── cli/ # ocx command dispatch, init, status, provider commands
+├── server/ # Bun.serve, /v1/* proxy, /api/* management API, WS bridge
+├── codex/ # Codex config injection, catalog sync, auth/account integration
+├── providers/ # provider metadata, API-key pool, quota and labels
+├── adapters/ # seven wire adapters, shared guards/utilities, Cursor protobuf transport
+├── oauth/ # OAuth providers, API-key catalog, token store/refresh
+├── usage/ # request usage extraction, JSONL logs, summaries, totals
+├── lib/ # runtime, process, retry, privacy, token estimate helpers
+├── web-search/ # service auxiliaire de recherche web (outil synthétique, boucle, exécuteur, analyseur)
+├── vision/ # service auxiliaire de vision (description et planification)
+├── config.ts # ~/.opencodex/config.json, defaults, PID, env resolution
+├── router.ts # model id → provider + adapter
+├── bridge.ts # AdapterEvent stream → Responses SSE / JSON
+├── reasoning-effort.ts # reasoning-effort translation, clamping, and catalog levels
+├── responses/
+│ ├── parser.ts # Responses request → OcxParsedRequest
+│ ├── schema.ts # Zod validation
+│ └── compaction.ts # remote compaction prompts, envelopes, compact history
+├── service.ts # launchd / systemd / Task Scheduler background service
+├── types.ts # core interfaces + helpers (modelInList, namespacedToolName)
+└── index.ts # public entry
+```
+
+Trois anciens points d’entrée volumineux préservent désormais la compatibilité sous forme de façades : `codex/catalog.ts` exporte les sept modules spécialisés `codex/catalog/*.ts`, `server/management-api.ts` répartit les requêtes entre les neuf modules `server/management/*.ts`, et `server/responses.ts` exporte les cinq modules `server/responses/*.ts`.
+
+## Flux d’une requête
+
+`server/index.ts` gère la frontière HTTP et délègue le plan de données Responses à la façade `server/responses.ts` et à ses modules `server/responses/*.ts` :
+
+1. `server/index.ts` applique CORS et l’authentification d’API, refuse les nouvelles tâches pendant le drainage et enregistre les métadonnées du cycle de vie de la requête. Il sert `GET /v1/models`, `POST /v1/responses`, `POST /v1/responses/compact`, `POST /v1/images/generations` / `POST /v1/images/edits` (relayés vers une famille OpenAI en amont par `server/images.ts` pour l’outil `image_gen` intégré à Codex), `POST /v1/live` / `POST /v1/realtime/calls` (création des appels vocaux ChatGPT / Codex App et OpenAI Realtime, relayée par `server/live.ts`), les connexions WebSocket sideband sur `/v1/live/{callId}` (et `/v1/realtime?call_id=`), ainsi que la mise à niveau WebSocket facultative sur `/v1/responses`.
+2. `server/responses/core.ts` décompresse et analyse le JSON, développe les entrées de mémoire locale `previous_response_id` lorsqu’elles sont disponibles, puis appelle `responses/parser.ts`.
+3. `router.ts` résout un identifiant simple ou `provider/model`. Le serveur détermine ensuite l’affinité du compte Codex, actualise l’authentification OAuth du fournisseur si nécessaire et applique à la route les identifiants sélectionnés.
+4. Avant l’appel principal, `vision/` décrit les images pour les modèles figurant dans `noVisionModels`. En l’absence de service auxiliaire sûr, les images sont supprimées plutôt qu’envoyées à un service en amont purement textuel.
+5. `server/adapter-resolve.ts` applique toute substitution de protocole propre au modèle et construit l’un des sept adaptateurs. L’adaptateur Responses relaie le corps natif, Cursor exécute son transport bidirectionnel `runTurn`, et les adaptateurs traduits construisent, envoient et analysent une requête en amont.
+6. Pour les modèles routés avec un outil hébergé `web_search`, `web-search/` expose une fonction synthétique, exécute la recherche réelle avec le backend configuré — le service auxiliaire OpenAI/ChatGPT ou le backend Anthropic —, renvoie les résultats au modèle routé et recommence dans la limite de boucle configurée. Cette boucle ne prend en charge que le chemin HTTP classique ; les adaptateurs qui implémentent `runTurn`, comme Cursor, la contournent et poursuivent leur propre transport.
+7. `bridge.ts` produit un flux SSE Responses ou une réponse JSON. `server/request-log.ts` et `usage/` recueillent de manière bornée l’état, la latence, les libellés de fournisseur/modèle et l’utilisation estimée des jetons, sans modifier la réponse.
+
+## Analyseur
+
+`responses/parser.ts` valide la requête entrante avec `responses/schema.ts` (Zod), puis construit un `OcxParsedRequest` :
+
+- **Messages** — les éléments `input` deviennent un tableau normalisé `OcxMessage[]` : utilisateur / développeur / assistant / résultat d’outil. Les éléments `reasoning` deviennent des blocs de réflexion ; les éléments `function_call`, `custom_tool_call` et `tool_search_call` deviennent des appels d’outils ; les éléments `*_output` correspondants deviennent des résultats d’outils.
+- **Outils** — les outils de fonction sont transmis tels quels ; **les outils avec espace de noms (MCP) sont aplatis** sous la forme `namespace__name` (puis restaurés au retour) ; les outils **libres** (par exemple `apply_patch`) et les outils de découverte **tool_search** sont signalés ; les **outils hébergés** (`web_search`, génération d’images, etc.) sont retirés et réinjectés par un service auxiliaire uniquement si celui-ci peut les traiter.
+- **Images** — elles sont conservées comme de véritables parties de contenu (URL de données ou URL https distante), jamais intégrées sous forme de texte.
+- **Indicateurs de fonctionnalité** — `_webSearch` (recherche Web hébergée demandée), `_structuredOutput` (`text.format` est json_schema/json_object) et `_compactionRequest` (compactage distant v2).
+
+## Pont
+
+`bridge.ts` transforme le flux interne `AdapterEvent` de l’adaptateur en événements SSE Responses compris par Codex :
+
+| AdapterEvent | Événements SSE Responses émis |
+| --- | --- |
+| `text_delta` | `response.output_text.delta` → `…done`, `response.content_part.done`, `response.output_item.done` |
+| `thinking_delta` | `response.reasoning_summary_text.delta` → `…done`, fermeture de l’élément |
+| `reasoning_raw_delta` | Élément `reasoning_text` brut (ou enveloppe aller-retour masquée) |
+| `thinking_signature` / `redacted_thinking` | Conservé dans une enveloppe de raisonnement `encrypted_content` |
+| `tool_call_start` | `response.output_item.added` (type : `function_call` / `custom_tool_call` / `tool_search_call`) |
+| `tool_call_delta` | `response.function_call_arguments.delta` (ignoré pour les outils libres / tool_search) |
+| `tool_call_end` | `response.function_call_arguments.done` → `response.output_item.done` |
+| `web_search_call_begin` / `web_search_call_end` | Élément actif `web_search_call` accompagné de citations d’URL |
+| `heartbeat` | Signale une activité en amont ; aucun élément de sortie visible par l’utilisateur |
+| `done` | `response.completed` (avec l’utilisation) |
+| `error` | `response.failed` (avec `last_error`) |
+
+Le pont émet également un **signal de maintien en vie** (RC3) : lorsque le service en amont reste silencieux, il envoie toutes les 2 secondes un événement SSE `response.heartbeat`, ignoré par l’analyseur, afin de réarmer la minuterie d’inactivité de Codex. Le **délai maximal de blocage** est de 300 secondes par défaut (`stallTimeoutSec`). Une fois ce délai atteint, le service en amont est interrompu et `response.incomplete` est émis avec le motif `upstream_stall_timeout`, ce qui empêche une connexion bloquée d’immobiliser Codex indéfiniment.
+
+Les appels d’outils sont répartis entre trois types d’éléments Responses à l’aide de la table des espaces de noms, de l’ensemble des outils libres et de l’ensemble des outils de recherche capturés par l’analyseur. Les espaces de noms MCP, les outils libres tels que `apply_patch` et les appels `tool_search` exécutés par le client peuvent ainsi effectuer un aller-retour complet. Une variante `buildResponseJSON()` produit à partir des mêmes événements un objet de réponse unique hors flux.
+
+## API de gestion, OAuth et utilisation
+
+`server/management-api.ts` alimente le tableau de bord et répartit les requêtes entre des groupes de routes spécialisés dans `server/management/*.ts`. Ses routes `/api/*` couvrent la configuration et les paramètres sûrs, les opérations CRUD sur les fournisseurs et les groupes de clés, la sélection des modèles, les limites de contexte et les contrôles v2, la synchronisation du catalogue, les diagnostics et journaux de débogage, l’utilisation et les quotas, les paramètres des services auxiliaires, les mises à jour, les clés d’API clientes générées, la connexion/l’état/la déconnexion OAuth et la sélection du compte, la gestion des comptes Codex et l’arrêt progressif. Pour une liaison hors bouclage, `server/auth-cors.ts` protège le plan de données `/v1/*` avec `OPENCODEX_API_AUTH_TOKEN` ou une entrée `apiKeys` configurée. Les routes de gestion `/api/*` emploient un identifiant administrateur distinct, décrit dans la [référence de l’API de gestion](/fr/reference/management-api/), qui doit différer des identifiants du plan de données. Les entrées `corsAllowOrigins` configurées étendent la liste locale des origines autorisées.
+
+Les implémentations OAuth se trouvent dans `oauth/`. Les jetons d’accès sont chargés ou actualisés immédiatement avant un appel routé, tandis que `oauth/token-guardian.ts` ne peut les actualiser de manière proactive que pour les fournisseurs dont la politique l’autorise. L’actualisation est coordonnée par une opération unique en cours de processus, un verrou de fichier par compte et un CAS de génération, afin que des écritures concurrentes ne puissent pas écraser un identifiant plus récent. Une projection partagée de l’état de santé (`oauth/health.ts`) alimente `ocx status`, `ocx doctor`, l’API de gestion et le tableau de bord. Les identifiants des pools Codex/ChatGPT et l’affinité des fils propre au processus se trouvent dans `codex/` et ne figurent pas dans les réponses de gestion. L’affinité est supprimée en cas de `401` / `403` / `429` (elle n’est pas conservée au-delà des limites de débit) et ne persiste pas après un redémarrage. L’utilisation des requêtes est normalisée en `OcxUsage`, exposée dans les événements terminaux Responses et agrégée par `usage/` pour le tableau de bord et les diagnostics JSONL facultatifs.
+
+## Transport et compactage
+
+Par défaut, `server/index.ts` sert HTTP/SSE sur `/v1/responses`. Si Codex tente une mise à niveau WebSocket de Responses alors que `websockets` vaut `false`, opencodex renvoie `426 upgrade_required` ; Codex revient alors à HTTP pour cette session. Lorsque `"websockets": true` est défini, le même point de terminaison accepte la mise à niveau et utilise le pont WebSocket.
+
+Indépendamment de ce réglage côté client, les requêtes canoniques transmises à ChatGPT avec `stream: true` à la racine peuvent utiliser le transport WebSocket en amont de Codex avec une version stable de Bun 1.4.0 ou ultérieure. La version intégrée Bun 1.3.14, les préversions et les identités de runtime impossibles à vérifier utilisent HTTP/SSE. Les réponses WS en amont qui réussissent conservent le contrat SSE en aval et contournent `tee()` au moyen d’un relais borné à lecteur unique et avide (4 MiB par trame brute/enveloppée et une file de production de 8 MiB). Le dépassement de la file ferme la connexion en amont et émet en aval un événement terminal `response.failed`, suivi de `[DONE]`.
+
+Le compactage du contexte Codex fonctionne avec les modèles routés. `server/responses/compact.ts` traite `POST /v1/responses/compact` en exécutant un tour interne de synthèse routé et en renvoyant un historique compacté, tandis que `responses/parser.ts` et `bridge.ts` traitent les tours de compactage distant v2 `compaction_trigger` en émettant exactement un élément de sortie synthétique `compaction`.
+
+## Mise en cache et catalogue
+
+- `codex/model-cache.ts` conserve en mémoire, par fournisseur, un cache TTL des résultats actifs de `/models` (5 min par défaut, comme le propre cache de Codex), avec repli sur une version périmée en cas d’échec de récupération.
+- `codex/catalog/sync.ts`, exporté par la façade `codex/catalog.ts`, fusionne les modèles routés dans le catalogue de Codex sous forme d’entrées avec espace de noms, place en premier les [modèles de sous-agents](/fr/guides/codex-integration/#le-sélecteur-de-sous-agents) mis en avant, filtre `disabledModels` et peut restaurer intégralement le catalogue d’origine à partir d’une sauvegarde créée une seule fois.
+
+## Effort de raisonnement
+
+`reasoning-effort.ts` traduit les libellés de raisonnement de Codex dans les valeurs de protocole propres à chaque fournisseur. Le catalogue Codex annonce les libellés acceptés par Codex (`low` / `medium` / `high` / `xhigh` / `max` / `ultra`), mais les fournisseurs en amont peuvent ne prendre en charge qu’un sous-ensemble plus restreint ou exiger un véritable alias. Le module :
+
+- définit les `CODEX_REASONING_LEVELS` canoniques et leur ordre de tri ;
+- ramène un effort demandé au niveau pris en charge le plus proche lorsque le niveau exact n’est pas disponible ;
+- résout les substitutions `reasoningEffortMap` par modèle et par fournisseur pour les correspondances de protocole personnalisées ;
+- omet entièrement l’effort pour les modèles répertoriés dans `noReasoningModels`.
+
+Qwen3.8-Max constitue une exception explicite d’effort direct par rapport à l’ancien contrat de budget Qwen3.x. Alibaba Token Plan enregistre les niveaux pris en charge en amont `low`, `medium` et `xhigh` (valeur par défaut), puis envoie la valeur effective dans `reasoning_effort`. Les niveaux de compatibilité propres à Codex qui les dépassent sont limités à `xhigh` sur le protocole. L’enrichissement du registre à l’exécution corrige les anciennes métadonnées de préréglage persistantes qui classent encore ce modèle comme un modèle `thinking_budget`.
+
+## Types fondamentaux
+
+Le modèle interne se trouve dans `types.ts` : `OcxParsedRequest`, `OcxContext`, l’union `OcxMessage`, `OcxContentPart` (texte / image), `OcxToolCall`, `OcxTool`, `AdapterEvent` et les types de configuration (`OcxConfig`, `OcxProviderConfig`). Deux fonctions utilitaires sont largement utilisées : `namespacedToolName()` et `modelInList()` (correspondance tolérante des suffixes `:size` pour `noVisionModels` / `noReasoningModels`).
diff --git a/docs-site/src/content/docs/fr/reference/cli.md b/docs-site/src/content/docs/fr/reference/cli.md
new file mode 100644
index 0000000000..d8db4b15d3
--- /dev/null
+++ b/docs-site/src/content/docs/fr/reference/cli.md
@@ -0,0 +1,32 @@
+---
+title: Référence de la CLI
+description: Répartition des commandes, codes de sortie et liens vers toutes les familles de commandes ocx.
+---
+
+L’interface en ligne de commande d’opencodex est `ocx`. La première commande détermine l’opération à exécuter. Les alias documentés, tels que `setup`/`init`, `restore`/`eject` et `models`/`model`, déclenchent la même opération. Une commande inconnue ou une syntaxe de commande non valide produit une erreur.
+
+Exécutez `ocx help` (ou `ocx --help` / `ocx -h`) pour afficher l’aide générale. Pour une commande enregistrée dans la table d’aide, exécutez `ocx help `, `ocx --help` ou `ocx -h`. Les commandes d’aide et de version sont en lecture seule : elles ne démarrent, n’arrêtent, n’installent, ne désinstallent ni ne réécrivent l’état de Codex ou d’opencodex.
+
+## Familles de commandes
+
+- [Cycle de vie](/fr/reference/cli/lifecycle/) — configuration initiale, cycle de vie du proxy et du service, état de santé, diagnostics, synchronisation du catalogue, tableau de bord et mises à jour.
+- [Fournisseurs, comptes et modèles](/fr/reference/cli/providers-accounts/) — configuration des fournisseurs, authentification, pools d’identifiants, quotas, modèles personnalisés, visibilité, modèles sélectionnés et limites de contexte.
+- [Agents, routage et intégrations](/fr/reference/cli/agents/) — contrôles multi-agents, combinaisons, observabilité, clés d’admission, intégrations clientes, paramètres d’exécution et configuration validée.
+
+## Fonctionnement sans interface interactive
+
+Les commandes de gestion communiquent avec l’API de gestion du proxy actif. Elles s’appuient sur le port d’exécution enregistré et sur des contrôles d’identité, plutôt que sur un second chemin de configuration. Un proxy arrêté ou inaccessible est représenté par une réponse HTTP 503 et entraîne un code de sortie CLI non nul. Les commandes explicitement documentées comme des opérations de configuration hors ligne peuvent, quant à elles, valider et modifier le fichier de configuration sans proxy actif.
+
+L’affichage d’une liste ou d’un état est l’action par défaut lorsqu’il n’y a aucune ambiguïté. Utilisez `--json` pour obtenir des instantanés structurés et `ocx observe logs --follow --jsonl` pour suivre un flux de journaux de requêtes. Le thème, la langue, la navigation et les autres états purement visuels du navigateur n’ont pas d’équivalent dans la CLI. La configuration de Cloudflare Tunnel ne fait pas partie de cet ensemble de commandes.
+
+## Codes de sortie et confirmation
+
+Une commande réussie renvoie le code 0. Une syntaxe non valide, une commande ou une ressource inconnue, l’échec d’une opération d’API ou l’indisponibilité d’un service requis produit un code non nul. Plus précisément, `ocx health` renvoie 0 uniquement lorsque le proxy est sain, et 1 dans le cas contraire ; cette commande peut donc servir de sonde de service. Les scripts doivent tester le code de sortie plutôt que d’analyser le texte destiné aux utilisateurs.
+
+Les opérations de suppression destructive, d’importation, de consommation de crédits et de mise à jour qui annoncent une confirmation exigent `--yes` en mode non interactif. Ce drapeau constitue un consentement explicite : son absence ne doit jamais confirmer silencieusement l’opération.
+
+## Version et cibles de répartition internes
+
+`ocx --version`, `ocx -v` et `ocx version` affichent une seule ligne de version exploitable par un script, puis se terminent.
+
+Deux cibles de répartition sont volontairement absentes de l’aide habituelle : `__refresh-version [preview]` actualise le cache des notifications de mise à jour dans un processus détaché, tandis que `__gui-update-worker [latest|preview] [restart]` exécute une tâche de mise à jour du tableau de bord. Il s’agit de détails d’implémentation, et non de commandes publiques stables. Le tableau de bord enregistre le PID du processus de travail, récupère une tâche active dont le processus est mort, considère comme obsolètes après dix minutes les anciens enregistrements actifs sans PID et protège un processus vivant contre les mises à jour concurrentes.
diff --git a/docs-site/src/content/docs/fr/reference/cli/agents.md b/docs-site/src/content/docs/fr/reference/cli/agents.md
new file mode 100644
index 0000000000..6e8fca4411
--- /dev/null
+++ b/docs-site/src/content/docs/fr/reference/cli/agents.md
@@ -0,0 +1,250 @@
+---
+title: CLI Agents, routage et intégrations
+description: Commandes multi-agents, combo, observabilité, accès, intégration, système et configuration.
+---
+
+Ces commandes contrôlent la politique et le routage de l'agent, inspectent le proxy actif et connectent les clients pris en charge à opencodex.
+
+## Politique des agents
+
+### `ocx agent ...`
+
+Gérez la liste multi-agents sans tête, les plafonds d’effort, l’injection rapide, les paramètres de secours et ceux des services auxiliaires.
+Utilisez `status` pour la stratégie actuelle. Voir [Surfaces de sous-agent](/fr/guides/sub-agent-surface/) pour savoir comment
+les modes de surface, la délégation, l'effort et le comportement de repli s'emboîtent.
+
+```bash
+ocx agent subagents set ark/model-a,openai/gpt-5.5
+```
+
+### `ocx v2 |threads |mode-hint >`
+
+Gérez l'indicateur de fonctionnalité Codex `multi_agent_v2` et le mode surface multi-agents à trois états.
+
+| Sous-commande | Actions |
+| --- | --- |
+| `status` (par défaut) | Signalez l’indicateur v2 actuel, le mode multi-agent et la concurrence des threads. |
+| `on` | Activez la fonctionnalité `multi_agent_v2` et resynchronisez le catalogue. |
+| `off` | Désactivez la fonctionnalité `multi_agent_v2` et resynchronisez le catalogue. |
+| `mode v1` | Forcez tous les modèles à v1, désactivez la v2 native et préservez la limite de threads actifs. |
+| `mode default` | Respecter les axes de surface du modèle en amont. |
+| `mode v2` | Forcez tous les modèles à v2, activez la v2 native et préservez la limite de threads actifs. |
+| `threads ` | Définissez la limite de thread v1/v2 active sur un nombre entier d'au moins 1. |
+| `mode-hint ` | Définissez l’indice de délégation proactive (mode Ultra) pour chaque modèle et effort. |
+| `mode-hint --clear` | Supprimez l'indice pour que la politique dérivée de l'effort (ultra = proactive) reprenne. |
+
+```bash
+ocx v2 status
+ocx v2 mode v1
+ocx v2 mode default
+ocx v2 on
+ocx v2 threads 16
+ocx v2 mode-hint "Proactive multi-agent delegation is active."
+ocx v2 mode-hint --clear
+```
+
+La sous-commande `mode` écrit `multiAgentMode` dans la configuration opencodex et resynchronise le catalogue Codex.
+Les changements de mode et d’indicateur déplacent la limite numérique actuelle de fils entre les clés v1/v2 Codex valides ;
+une transition ratée restaure le `config.toml` original. Les modifications s'appliquent aux nouvelles sessions Codex, tandis que
+les sessions de course conservent leur surface épinglée.
+
+`mode-hint` écrit `features.multi_agent_v2.multi_agent_mode_hint_text` en Codex
+`$CODEX_HOME/config.toml` même si `multi_agent_v2` est actuellement désactivé. Le
+la commande ne conserve que le remplacement ; il n'active ni ne désactive la fonctionnalité, donc
+l'indice prend effet lorsqu'une surface Codex correspondante est active. L'indice remplace
+la politique multi-agents dérivée de l'effort du codex-rs, donc tout modèle et tout effort de raisonnement
+reçoit l’invite de délégation proactive. Cela ne change **pas** l'effort de raisonnement
+lui-même. Un argument manquant ou une valeur contenant uniquement des espaces est rejeté ; seulement `--clear`
+supprime l'indice. La bascule **on** du mode Ultra du tableau de bord Sous-agents a une
+gate : il nécessite que la fonctionnalité native soit activée avec une surface v2 explicite
+(`ocx v2 mode v2`); `ocx v2 on` à lui seul ne satisfait pas à cette porte du tableau de bord.
+
+## Routage combiné
+
+### `ocx combo ...` · `ocx route combo ...`
+
+Gérez les modèles virtuels de basculement combiné et de round robin. `ocx route combo` est l'alias hiérarchique ;
+combo est actuellement la ressource de routage prise en charge. Utilisation des cibles
+`provider/model[:weight],provider/model[:weight]`.
+
+```bash
+ocx combo list
+ocx route combo set reliable --targets ark/model-a:2,openai/gpt-5.5
+```
+
+`set` accepte `--strategy`, `--sticky`, `--effort`, `--alias`, `--rename-from`, `--native-alias` et
+`--display-name ` (`-` efface l’étiquette). Un alias natif n'en capture qu'un seul actuellement pris en charge,
+identifiant de modèle OpenAI nu non qualifié. Les alias natifs `gpt-5.6-*` nus utilisent Codex Pool/Direct informations d'identification.
+Les itinéraires OpenAI qualifiés par le compte restent distincts, tandis que les itinéraires qualifiés par le fournisseur tels que
+`openai-apikey/gpt-5.6-*` utilisez leur clé API configurée et ne passez jamais à l'alias natif.
+Lisez le contrat de sécurité et de visibilité dans le guide avant d'activer le couple de compatibilité.
+
+Voir [Combos](/fr/guides/combos/) pour le comportement de routage et les conseils de configuration.
+
+## Observabilité et débogage
+
+### `ocx observe ...`
+
+Inspectez les requêtes de proxy, l’utilisation, le stockage, la mémoire et les données de débogage. Les alias directs sont :
+
+| Alias | Ressource équivalente |
+| --- | --- |
+| `ocx logs [filters] [--follow] [--json\|--jsonl]` | `ocx observe logs` |
+| `ocx usage [--range <7d\|30d\|all>] [--surface ] [--json]` | `ocx observe usage` |
+| `ocx storage [--json]` | `ocx observe storage` |
+| `ocx memory [--json]` | `ocx observe memory` |
+
+```bash
+ocx observe usage --range 30d --json
+```
+
+### `ocx debug `
+
+Lisez ou modifiez les remplacements de débogage d'exécution via la gestion du proxy en cours d'exécution API.
+
+```bash
+ocx debug provider on|off|status|reset
+ocx debug provider logs [-f|--follow]
+ocx debug usage on|off|status|reset
+ocx debug usage logs [-f|--follow]
+```
+
+Sans portée, `ocx debug` imprime l'utilisation et, lorsque le proxy est arrêté, l'environnement de prochain démarrage
+valeurs par défaut. Les valeurs par défaut du débogage du fournisseur sont `OCX_DEBUG=1` (l'héritage `OCX_DEBUG_FRAMES=1` fonctionne également) ; utilisation
+les valeurs par défaut du débogage sont `OPENCODEX_USAGE_DEBUG=1`.
+
+## Accès à l’API
+
+### `ocx access ...`
+
+Gérez les clés d'admission OpenCodex et examinez les points de terminaison et les modèles externes. `ocx api-key
+ ...` est un alias de `ocx access key`.
+
+```bash
+ocx access key create deployment
+```
+
+## Intégrations client
+
+### `ocx integration ...`
+
+Gérez les intégrations Claude et Grok prises en charge. Les familles de commandes directes ci-dessous exposent leurs
+contrôles spécifiques au client.
+
+### `ocx claude [claude args...]`
+
+Assurez-vous que le proxy est en cours d'exécution, puis lancez Claude Code avec `ANTHROPIC_BASE_URL`,
+`ANTHROPIC_AUTH_TOKEN`, `CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1` et emplacements de modèle de
+`config.claudeCode`. Les modèles routés apparaissent dans le sélecteur `/model` natif via des alias d'emplacement stables
+avec Claude Code 2.1.129 ou plus récent. Sur les anciennes versions, sélectionnez avec `ANTHROPIC_MODEL` ou `/model `.
+Les variables `ANTHROPIC_*` exportées par l'utilisateur sont toujours prioritaires.
+
+Claude Les commandes du profil de bureau sont :
+
+```text
+ocx claude desktop [apply] Save and apply the four-family profile
+ocx claude desktop show [--json] Show routes, families, and defaults
+ocx claude desktop move [--default]
+ocx claude desktop default
+ocx claude desktop export Export versioned JSON (`-` = stdout)
+ocx claude desktop import [--apply] Validate and import JSON
+```
+
+Les familles sont `opus`, `fable`, `sonnet` et `haiku` ; les nouveaux itinéraires commencent en `opus`. `none` est valide
+seulement quand cette famille est vide. Les anciens indicateurs d'application `--static`, `--hybrid` et `--discovery-only`
+restent soutenus. Utilisez `ocx claude config ...` pour les réglages Claude Code.
+
+### `ocx opencode [opencode args...]`
+
+Vérifiez que le proxy est actif, puis lancez opencode avec un bloc `provider.opencodex` généré dans la couche d’exécution intégrée d’OpenCode (`OPENCODE_CONFIG_CONTENT`). La configuration intégrée existante est préservée et seul `provider.opencodex` est remplacé pour ce lancement. Les fichiers `opencode.json` globaux ou propres au projet peuvent être lus afin de signaler une substitution existante, mais les fichiers sur disque ne sont jamais modifiés. Les modèles routés apparaissent sous la forme `opencodex//`. Un lancement ultérieur de `opencode` sans intermédiaire se comporte exactement comme auparavant.
+
+### `ocx grok ...`
+
+Gérez et appliquez la clôture du modèle Grok Build.
+
+## Exportation de la configuration client
+
+### `ocx export --client `
+
+Imprimez une configuration client connectée au proxy en cours d'exécution. La commande sérialise le
+bloc fournisseur `opencodex` — URL de base, liste de modèles et référence d’identifiant du client
+espace réservé de référence ou de bouclage — dans le format natif du client sélectionné.
+
+Le proxy doit être en cours d'exécution ; la commande résout son port en direct, lit `/api/models` et émet uniquement
+les modèles Codex peuvent actuellement voir.
+
+| Option | Actions |
+| --- | --- |
+| `--client ` | Requis. Sélectionne le dialecte de configuration client. |
+| `--json` | Imprimez le document généré en tant que JSON sur la sortie standard pour les scripts. Il s'agit de JSON même lorsque le format natif du client sélectionné est YAML, TOML ou JSON5. |
+| `--out ` | Écrivez le format de configuration natif du client dans ``. Refuse de remplacer un fichier existant. |
+| `--force` | Autoriser `--out` à remplacer un fichier existant. |
+
+```bash
+ocx export --client opencode # config plus destination, merge warning, and counts
+ocx export --client pi --json > pi-models.json # JSON document for a pipe or a diff
+ocx export --client omp --out ./omp-models.yml # native OMP YAML
+ocx export --client opencode --out ~/opencodex-opencode.json
+```
+
+Sans `--json`, la configuration générée est affichée en premier. Elle est suivie du chemin de destination canonique,
+de l’avertissement de fusion, de la ligne `export` de la variable d’environnement lorsque le client en utilise une,
+puis du nombre de modèles et du nombre de lignes sans limite de contexte faisant autorité. Le client applique ses
+propres valeurs par défaut à ces lignes.
+
+| Client | Destination canonique | Télécharger le nom du fichier | Var.environnement |
+| --- | --- | --- | --- |
+| `opencode` | `~/.config/opencode/opencode.json` (`XDG_CONFIG_HOME` gagne une fois défini) | `opencode.json` | `OPENCODEX_OPENCODE_API_KEY` |
+| `pi` | `~/.pi/agent/models.json` | `pi-models.json` | none — le bloc porte le littéral `opencodex-loopback` |
+| `omp` | `~/.omp/agent/models.yml` (`OMP_PROFILE` l'emporte sur `PI_PROFILE`, même lorsqu'il est vide ; les profils nommés utilisent le nom du répertoire `PI_CONFIG_DIR` relatif à la maison et ignorent `PI_CODING_AGENT_DIR`, tandis que le profil par défaut laisse `PI_CODING_AGENT_DIR` gagner) | `omp-models.yaml` | aucun — espace réservé de bouclage |
+| `hermes` | `~/.hermes/config.yaml` | `hermes-config.yaml` | `OPENCODEX_HERMES_API_KEY` |
+| `openclaw` | `~/.openclaw/openclaw.json` | `openclaw.json5` | `OPENCODEX_OPENCLAW_API_KEY` |
+| `kimi` | `~/.kimi-code/config.toml` | `kimi-config.toml` | aucun — espace réservé de bouclage |
+| `gajae` | `~/.gjc/agent/models.yml` | `gajae-models.yaml` | `OPENCODEX_GAJAE_API_KEY` |
+| `dsh` | `$DSH_HOME/settings.yaml` (`~/.dsh/settings.yaml` par défaut) | `settings.yaml` | none — espace réservé pour le porteur de bouclage non secret |
+
+L'exportation DSH gérée nécessite DSH 0.1.0-rc.6 ou plus récent et ne possède que
+`llm-pi-ai.providers.opencodex`. DSH recharge à chaud ce fournisseur ; le modèle par défaut de l'utilisateur et
+`deepseek-official` restent intacts. Cette exportation s'effectue uniquement en boucle et ne comporte aucune véritable information d'identification.
+
+opencode interpole `{env:OPENCODEX_OPENCODE_API_KEY}`. Les exports Pi et OMP générés font
+ne nécessitent pas de variable d’environnement : chacune porte l’espace réservé littéral `opencodex-loopback`.
+Ceci est porteur car les deux clients résolvent `apiKey` lors de la construction de leurs listes de modèles et
+masquer l'intégralité du fournisseur lorsqu'une configuration existante contient une référence d'environnement non définie. Le proxy n'a jamais
+vérifie l'espace réservé généré lors du bouclage. OMP prend en charge les en-têtes au niveau du fournisseur, mais cette première
+l'intégration reste délibérément un bouclage uniquement ; le câblage à distance `x-opencodex-api-key` est différé.
+
+:::caution[Fusionner, ne jamais remplacer]
+`ocx export` n'écrit jamais votre vraie configuration client. La destination est imprimée pour que vous puissiez la fusionner
+main, et `--out` refuse d'écraser un fichier existant sans `--force`, car le remplacement d'un
+config détruit les autres fournisseurs, agents et entrées MCP déjà présents.
+:::
+
+Aucune clé n'est jamais sérialisée. Les configurations portent soit une référence d'environnement documentée, soit un
+Espace réservé de bouclage non secret. Un proxy de bouclage (`127.0.0.1`, la valeur par défaut) ne nécessite aucun
+clé d'admission du tout. Définissez une variable référencée uniquement lorsque le schéma client la prend en charge et
+le proxy se lie au-delà du bouclage ; voir
+[Accès à distance](/fr/reference/configuration/server/#accès-à-distance) pour savoir comment les clés d'admission sont délivrées. Clés pour
+les fournisseurs en amont eux-mêmes sont une chose entièrement distincte, configurée par
+[Fournisseurs](/fr/guides/providers/).
+Gajae est l'exception : `OPENCODEX_GAJAE_API_KEY` remplit ses informations d'identification de fournisseur à partir du
+environnement, mais son schéma ne peut pas envoyer l'en-tête d'admission à distance, donc le Gajae généré
+l'intégration reste uniquement en boucle.
+
+La même charge utile est servie par `GET /api/client-config` et rendue sur l'onglet API du tableau de bord, donc
+le CLI, l’API, et le GUI utilisent les mêmes octets.
+
+## Exécution et configuration
+
+### `ocx system ...`
+
+Gérez les paramètres d'exécution sans tête, le démarrage, la synchronisation, les diagnostics et les mises à jour.
+
+```bash
+ocx system settings --stream-mode eager-relay
+```
+
+### `ocx config ...`
+
+Inspectez et modifiez en toute sécurité la configuration OpenCodex validée. `show` et `get` masquent les secrets. Importer
+valide avant d'écrire et nécessite `--yes`.
diff --git a/docs-site/src/content/docs/fr/reference/cli/lifecycle.md b/docs-site/src/content/docs/fr/reference/cli/lifecycle.md
new file mode 100644
index 0000000000..f677871a28
--- /dev/null
+++ b/docs-site/src/content/docs/fr/reference/cli/lifecycle.md
@@ -0,0 +1,272 @@
+---
+title: Cycle de vie de la CLI
+description: Commandes de configuration initiale, de démarrage, d’arrêt, de service, de diagnostic, de synchronisation et de mise à jour.
+---
+
+Ces commandes permettent d’installer, d’exécuter, d’examiner, de réparer et de mettre à jour le proxy opencodex local ainsi que son intégration à Codex.
+
+## Configuration initiale
+
+### `ocx init` · `ocx setup`
+
+Assistant de configuration interactif (`setup` est un alias de `init`). Il demande un fournisseur (prédéfini ou personnalisé), une clé d’API (valeur littérale ou `${ENV}`), un modèle par défaut et le port du proxy, puis enregistre le tout dans `~/.opencodex/config.json`. Il peut également injecter le proxy dans `$CODEX_HOME/config.toml` (par défaut `~/.codex/config.toml`) et installer le shim de démarrage automatique de Codex.
+
+## Cycle de vie du proxy
+
+### `ocx start [--port ]`
+
+Démarre le serveur proxy, de préférence sur le port `10100`. Si ce port est occupé, opencodex en choisit un autre qui est disponible et l’enregistre. La commande écrit l’état du PID et du port d’exécution, et refuse de démarrer une deuxième instance active. Au démarrage, elle synchronise dans le catalogue Codex les modèles de chaque fournisseur. À l’arrêt, elle rétablit le fonctionnement natif de Codex, sauf si le proxy a été lancé comme service géré (`OCX_SERVICE=1`).
+
+```bash
+ocx start
+ocx start --port 8080
+```
+
+### `ocx stop`
+
+Arrête le proxy actif à partir de son PID, supprime le fichier de PID et rétablit le fonctionnement natif de Codex. Si un service d’arrière-plan géré est installé, `ocx stop` l’arrête d’abord afin qu’il ne puisse pas relancer le proxy. La même opération est disponible avec le bouton **Stop** du tableau de bord Web (`POST /api/stop`).
+
+### `ocx restart`
+
+Lorsqu’un proxy est actif, demande précisément au PID et au port dont l’identité a été vérifiée de redémarrer sur place, attend la fin du drainage normal, puis vérifie qu’un autre PID d’exécution écoute sur le même port. Le routage géré et la supervision du service restent installés pendant toute l’opération. Une requête dont l’état est incertain est observée, et non rejouée comme lors d’une séquence distincte d’arrêt et de démarrage.
+
+Si aucun proxy n’est actif, la commande revient au démarrage normal avec `ensure`. Si l’identité d’un processus à l’écoute ne peut pas être rattachée à un PID d’exécution — notamment avec un proxy antérieur à une mise à jour — le redémarrage échoue de manière sûre, sans repli sur `ensure` ni sur une séquence arrêt/démarrage. Après avoir confirmé que le processus vous appartient, utilisez `ocx stop` puis `ocx start` pour un proxy autonome. Pour un proxy géré par un service, utilisez `ocx stop` puis `ocx service start` afin de rétablir la supervision.
+
+### `ocx ensure`
+
+Vérifie de manière idempotente qu’un proxy d’arrière-plan est actif, puis synchronise son catalogue de modèles en direct. Si `codexAutoStart` vaut `false`, la commande indique que le démarrage automatique est désactivé et n’effectue aucune opération.
+
+### `ocx restore [back]` · `ocx eject [back]`
+
+Rétablit le fonctionnement natif de Codex **sans arrêter** le proxy : les lignes de configuration injectées et les entrées routées du catalogue sont supprimées, de sorte qu’une invocation simple de `codex` utilise de nouveau Codex directement. `eject` est un alias de `restore`.
+
+Ajoutez `back` à l’une ou l’autre forme pour rediriger une invocation simple de `codex` vers un proxy déjà actif, sans modifier le cycle de vie du proxy :
+
+```bash
+ocx restore back
+ocx eject back
+```
+
+### `ocx recover-history --legacy-openai`
+
+Récupération explicite destinée aux anciennes versions de développement qui remappaient l’historique de Codex App avant l’ajout des sauvegardes réversibles. Fermez d’abord Codex si sa base de données d’historique est verrouillée.
+
+### `ocx uninstall` · `ocx remove`
+
+Arrête le service et le proxy, supprime le service et le shim Codex, rétablit le fonctionnement natif de Codex, puis supprime la configuration locale d’opencodex uniquement si toutes les étapes de restauration ont réussi. `remove` est un alias de `uninstall`. Le nettoyage de la configuration exige les métadonnées de propriété créées par une installation récente ; les répertoires anciens ou partagés sont conservés.
+
+## État et santé
+
+### `ocx status [--json]`
+
+Affiche un résumé de diagnostic en lecture seule : PID du proxy, accessibilité de `/healthz`, URL du tableau de bord, chemin de configuration, fournisseur par défaut, réglage du démarrage automatique de Codex, état du service, état du shim et répertoire Codex effectif expurgé. Seule la signature explicite et hautement fiable du répertoire d’exécution Windows Orca ajoute un avertissement exploitable lorsqu’il diffère du répertoire de Codex App ; la commande ne modifie jamais `CODEX_HOME` automatiquement.
+
+Après le résumé des connexions OAuth, la sortie destinée aux utilisateurs comprend aussi un bloc **OAuth health** : `OAuth health:
+ok` lorsque tous les comptes connus sont sains, ou `OAuth health: warning` accompagné d’une ligne expurgée pour chaque compte en anomalie (fournisseur, identifiant de compte masqué, état tel qu’une réauthentification requise, une limitation de débit ou de quota, ou un conflit d’actualisation), ainsi que d’une indication facultative `Action:`. Les identifiants de compte sont masqués ; les jetons et adresses électroniques ne sont jamais affichés. Le contrat `--json` n’inclut pas encore ce bloc de santé.
+
+```bash
+ocx status
+ocx status --json
+```
+
+Exemple de structure abrégée :
+
+```json
+{
+ "schemaVersion": 1,
+ "proxy": {
+ "running": false,
+ "pid": null,
+ "health": {
+ "ok": false,
+ "url": "http://127.0.0.1:10100/healthz",
+ "message": "unreachable"
+ }
+ },
+ "dashboard": {
+ "url": "http://localhost:10100/"
+ },
+ "paths": {
+ "config": "/Users/example/.opencodex/config.json",
+ "pid": "/Users/example/.opencodex/ocx.pid",
+ "runtime": "/path/to/bun"
+ },
+ "runtime": {
+ "source": "bundled"
+ },
+ "codexHome": {
+ "effectiveCodexHome": "C:\\Users\\[USER]\\.codex",
+ "appCodexHome": "C:\\Users\\[USER]\\.codex",
+ "mismatch": false,
+ "warning": null,
+ "action": null
+ },
+ "codexAutostart": true,
+ "defaultProvider": "openai",
+ "service": {
+ "summary": "not installed (logs: /Users/example/.opencodex/service.log)"
+ },
+ "codexShim": {
+ "summary": "Codex autostart shim: not installed"
+ }
+}
+```
+
+L’objet réel comprend également `listen` (port, nom d’hôte, source du runtime et de la configuration), les diagnostics de chargement de la configuration et les diagnostics du plug-in Codex intégré. Le schéma JSON est uniquement extensible : de futures versions peuvent ajouter des champs, mais les champs existants doivent rester stables. Les clés d’API, jetons OAuth, en-têtes d’autorisation, contenus de requêtes, adresses électroniques et identités de compte en sont volontairement exclus.
+
+### `ocx health [--json]`
+
+Vérifie l’identité du proxy actif. La sortie destinée aux utilisateurs indique le PID et le port ; `--json` produit `{ok, pid, port}`. La commande renvoie 0 uniquement lorsque le proxy est sain, et 1 dans le cas contraire, ce qui permet de l’utiliser comme sonde de service.
+
+### `ocx ready [--json] [--wait [--timeout ]]`
+
+Vérifie l’état de préparation après synchronisation au moyen du point de terminaison non authentifié `GET /readyz`. Il renvoie `200` lorsque le service est prêt, ou `503` avec `Retry-After: 1` pour les états `pending` et terminal `failed`. Son identité HTTP expurgée est `{service, version, uptime, pid, port, status}`. Les anciens proxys dépourvus de `/readyz` échouent de manière sûre avec l’état `unreachable` ; `/healthz` mesure la disponibilité du processus, et non son état de préparation.
+
+Par défaut, la commande effectue une seule sonde. Avec `--wait`, elle interroge le service jusqu’à ce qu’il soit prêt ou jusqu’à l’expiration du délai, mais s’arrête immédiatement si elle observe l’état terminal `failed`. Le délai par défaut est de 45 secondes. `--timeout ` exige `--wait` et accepte un entier positif compris entre 1 et 300. La sortie JSON de la CLI est `{ready, status, pid, port}`, où `status` vaut `ready`, `pending`, `failed` ou `unreachable`. Les codes de sortie sont 0 si le service est prêt ; 1 s’il n’est pas prêt, reste en attente, échoue, dépasse le délai ou est inaccessible ; et 64 si les arguments sont invalides.
+
+### `ocx doctor`
+
+Exécute des diagnostics en lecture seule sur l’environnement et la connectivité : chemins d’état et type de système de fichiers, installations doubles sous WSL, environnement et configuration du proxy, accessibilité de ChatGPT, avertissements liés au plug-in Codex et à la configuration du projet, ainsi que migration d’historique en attente. La section consacrée au répertoire de Codex App détecte également le cas précis où le répertoire d’exécution Windows Orca ne correspond pas et, le cas échéant, explique la migration du service. Les chemins affichés masquent le nom d’utilisateur du système d’exploitation. La commande doctor propose des réparations, mais ne les applique pas.
+
+La section **OAuth reliability** indique si le stockage des identifiants est accessible en écriture, si les fichiers d’opération unique et de verrouillage nécessaires à l’actualisation peuvent être créés sous `OPENCODEX_HOME`, et quels comptes OAuth ou du pool Codex sont en anomalie, avec des identifiants expurgés et une action de récupération `Action:`. Elle confirme également de manière statique que le chemin de transmission Codex ne fabrique pas de métadonnées de client officiel. La commande doctor ne modifie jamais les identifiants et n’applique aucune réparation.
+
+## Synchronisation du catalogue
+
+### `ocx sync [--restart-codex]`
+
+Récupère la liste active des modèles de chaque fournisseur configuré et réinjecte le catalogue fusionné dans Codex. Exécutez cette commande après l’ajout d’un fournisseur ou pour actualiser les modèles disponibles.
+
+Avant la découverte des fournisseurs ou le remplacement du catalogue et du cache, `ocx sync` vérifie que la configuration Codex gérée peut recevoir l’injection. Si cette validation refuse la configuration, la commande renvoie un code non nul, affiche la cause précise sur stderr et laisse le catalogue ainsi que le cache existants inchangés. `ocx restore back` effectue la même vérification préalable sans écriture avant de réactiver le routage.
+
+Si des processus Codex `app-server` de longue durée sont encore actifs, `ocx sync` avertit qu’ils peuvent continuer à servir l’ancienne liste de modèles conservée en mémoire, même après la mise à jour de `opencodex-catalog.json` / `models_cache.json`. Ajoutez `--restart-codex` pour envoyer `SIGTERM` uniquement aux processus `codex … app-server` et `codex-code-mode-host` correspondants qui appartiennent à l’utilisateur actuel ; les tours actifs peuvent être interrompus. La recherche générale `pkill -f codex` est volontairement évitée.
+
+### `ocx sync-cache [--restart-codex]`
+
+Invalide le cache local du sélecteur de modèles de Codex afin qu’il soit reconstruit à partir du catalogue opencodex actif. Le même avertissement concernant un `app-server` obsolète et le même comportement facultatif `--restart-codex` que pour `ocx sync` s’appliquent.
+
+## Service d’arrière-plan
+
+### `ocx service [install|repair|start|stop|status|uninstall|remove]`
+
+Exécute opencodex comme service d’arrière-plan géré à l’ouverture de session — **launchd** sous macOS, **unité utilisateur systemd** sous Linux et **Task Scheduler** sous Windows — qui démarre automatiquement à la connexion et redémarre après un plantage. Les services définissent `OCX_SERVICE=1` afin qu’un redémarrage ne réécrive pas inutilement la configuration Codex.
+
+| Sous-commande | Action |
+| --- | --- |
+| aucune | Crée ou met à jour le service, puis le démarre. |
+| `install` | Crée et démarre le service. L’enregistrement exige une élévation sous Windows. |
+| `repair` | Actualise sur place un service installé et le redémarre, sans le réenregistrer. |
+| `start` | Démarre un service installé. |
+| `stop` | Arrête le service et rétablit le fonctionnement natif de Codex. |
+| `status` | Affiche les diagnostics du service et du proxy, ainsi que les chemins des journaux. |
+| `uninstall` | Supprime le service et rétablit le fonctionnement natif de Codex. |
+| `remove` | Alias de `uninstall`. |
+
+```bash
+ocx service
+ocx service install
+ocx service repair
+ocx service status
+ocx service uninstall
+```
+
+Avant de signaler une réussite, `install`, `start` et `repair` vérifient, sur les trois plateformes, qu’un proxy répond effectivement sur le port inscrit dans le service installé. Elles attendent jusqu’à 20 secondes, puis affichent le port utilisé :
+
+```text
+✅ opencodex service installed and serving on port 10100.
+```
+
+Si aucun processus ne répond, elles affichent un avertissement et **renvoient un code non nul** :
+
+```text
+⚠️ Service installed, but no proxy answered on port 10100 within 20s.
+ The manager registered the job; that is not the same as serving.
+ Log: ~/.opencodex/service.log
+ Meanwhile: ocx start (serves in the foreground)
+```
+
+Dans ce cas, un code non nul signifie *enregistré, mais non opérationnel*, et non *non installé*. Le gestionnaire de services a accepté la tâche, mais le proxy n’a jamais ouvert le port. Consultez le journal indiqué et utilisez `ocx start` pour servir temporairement au premier plan.
+
+`ocx service status` distingue les trois mêmes états au lieu d’afficher la sortie brute du gestionnaire :
+
+```text
+✅ installed and loaded (launchd; logs: …)
+ Serving on port 10100.
+```
+
+```text
+⚠️ installed and loaded (launchd; logs: …)
+ Registered, but no proxy is answering on port 10100.
+ launchd is running an OLDER plist than the one on disk.
+ Fix: launchctl bootout gui/$(id -u)/com.opencodex.proxy && ocx service repair
+ Log: ~/.opencodex/service.log
+ Repair: ocx service repair
+ Meanwhile: ocx start (serves in the foreground)
+```
+
+La commande n’affiche plus la ligne brute `launchctl list` / `systemctl status`, qui présentait une tâche enregistrée de la même manière qu’elle serve effectivement, n’écoute sur aucun port ou utilise une ancienne définition. La ligne `Diagnostics:` contient toujours le chemin du journal et toute détection de chemin périmé inscrit dans le service.
+
+Sous Windows, le moteur du planificateur conserve sa sortie d’état plus détaillée, qui distinguait déjà l’enregistrement dans Task Scheduler de l’accessibilité du proxy.
+
+Sous macOS, cette vérification couvre aussi un échec plus subtil : `launchctl load` peut signaler une erreur sur stderr tout en renvoyant 0. Auparavant, un chargement manqué pouvait donc laisser launchd exécuter une **ancienne** version de la définition du service alors que la commande affichait une coche. `install` échoue désormais explicitement dans ce cas et indique la commande `launchctl bootout` qui supprime la tâche obsolète.
+
+Sous Windows, `ocx service status` distingue l’enregistrement dans Task Scheduler de l’accessibilité du proxy OpenCodex dont l’identité a été vérifiée. Il n’affiche pas le tableau localisé de `schtasks`, afin que le résumé reste lisible quelle que soit la page de codes Windows.
+
+Sous Windows, la création de l’entrée Task Scheduler exige une élévation. Lorsqu’un texte localisé de refus d’accès est reconnu, les consignes existantes sont conservées. Si ce texte est illisible, le mécanisme de repli exige la forme de commande détenue `/create /tn opencodex-proxy /xml /f`, le code d’état 1 et la confirmation que le jeton n’est pas élevé ; l’action Startup Safety du tableau de bord peut alors demander automatiquement l’autorisation UAC. Si le mécanisme ne peut pas déterminer l’état du jeton, l’erreur d’origine du planificateur est conservée. Une tâche étrangère ou une autre opération ne peut jamais émettre le marqueur d’élévation automatique. Acceptez la demande UAC du tableau de bord ou réexécutez `ocx service install` dans une fenêtre PowerShell élevée.
+
+Lors d’une nouvelle installation où l’absence de la tâche OpenCodex dans le planificateur est confirmée, l’autorisation UAC est désormais demandée avant l’arrêt d’un proxy existant. Le fichier XML d’enregistrement unique est préparé dans un répertoire privé aux ACL renforcées, en dehors de la racine de configuration OpenCodex, puis la tâche est enregistrée sans être exécutée. Ce n’est qu’après la réussite de cet enregistrement qu’OpenCodex supprime le fichier XML, exige des métadonnées de propriété pour une racine de configuration réellement nouvelle, arrête l’ancien processus à l’écoute, supprime et revérifie de manière bornée toute inscription WinSW native, publie les artefacts du service et démarre la tâche planifiée.
+
+Ainsi, l’annulation ou le refus de l’UAC, comme l’impossibilité de revendiquer une nouvelle racine en toute sécurité, laisse en place le proxy fonctionnel et son routage Codex. Les inscriptions existantes ou conflictuelles continuent d’échouer de manière sûre au lieu d’être supprimées dans le cadre d’une annulation approximative.
+
+### `ocx codex-shim `
+
+Entoure un lanceur `codex` basé sur un script et présent dans PATH avec un script léger de démarrage automatique. Les cibles réelles `codex.exe` restent intactes afin de ne pas casser les appels qui visent précisément cet exécutable.
+
+Avant de valider une installation ou une réparation, OpenCodex exécute le lanceur enregistré avec `--version` en désactivant le démarrage du service. La modification est refusée et annulée si le lanceur résout `codex` vers le shim lui-même, renvoie un code non nul, dépasse cinq secondes, laisse des processus descendants actifs, ou ne peut pas être validé et nettoyé en toute sécurité. `codex-shim install` n’est donc pas inconditionnel. En cas de refus, réinstallez Codex afin que l’entrée PATH désigne un exécutable ou un lanceur concret, puis recommencez. Utilisez plutôt `ocx service install` lorsqu’un lanceur dynamique fourni par un gestionnaire de commandes ne peut pas satisfaire ces contrôles.
+
+Pendant une mise à niveau, un shim Unix installé qui ne contient pas la garde de validation actuelle est régénéré et testé. Si son lanceur enregistré n’est pas sûr, OpenCodex supprime le shim obsolète et rétablit le lanceur d’origine au lieu de conserver l’enveloppe dangereuse.
+
+L’installation du lanceur ne prouve pas à elle seule que les requêtes Codex passeront par OpenCodex. Après une installation saine, la commande examine le routage Codex actuel et affiche un avertissement plutôt qu’un résultat positif lorsque le routage est externe, appartient à l’utilisateur ou ne peut pas être vérifié. Elle avertit aussi lorsque des variables de proxy sortant n’existent que dans le processus actuel alors que `config.proxy` est absent ou non résolu, car les lanceurs Codex et les services d’arrière-plan peuvent ne pas hériter de cet environnement. Ces contrôles sont en lecture seule et n’affichent jamais la valeur du proxy. Corrigez le transfert signalé et exécutez `ocx doctor` avant de compter sur le démarrage automatique.
+
+Si une mise à jour externe achevée de Codex remplace un shim installé, la prochaine commande `ocx` ordinaire sauvegarde le nouveau lanceur stable et rétablit le shim avant de répartir la commande. Un lanceur encore en cours de modification reste intact et sera réexaminé plus tard. Un échec de réparation produit un avertissement sans faire échouer la commande demandée. Repli manuel : `ocx codex-shim install`. Définissez `codexShimAutoRestore` sur `false`, ou `OPENCODEX_CODEX_SHIM_AUTO_RESTORE=0` pour désactiver ce comportement au niveau du processus.
+
+| Sous-commande | Action |
+| --- | --- |
+| `install` | Installe le shim, ou le répare s’il est obsolète. |
+| `uninstall` | Supprime le shim et rétablit le binaire Codex d’origine. |
+| `remove` | Alias de `uninstall`. |
+| `status` | Indique si le shim est installé, obsolète ou absent. |
+
+```bash
+ocx codex-shim install
+ocx codex-shim status
+ocx codex-shim uninstall
+```
+
+:::tip[Service ou shim]
+Utilisez `ocx service` pour maintenir un proxy d’arrière-plan toujours actif, ce qui est recommandé. Utilisez `ocx codex-shim` pour un démarrage léger à la demande, sans démon : le proxy ne démarre que lorsque `codex` est lancé.
+:::
+
+### `ocx tray [--json] [--no-start]`
+
+Installe et contrôle l’icône OpenCodex dans la zone de notification Windows. Elle démarre à l’ouverture de session et fournit des commandes du proxy accessibles en un clic. `start` et `stop` contrôlent uniquement l’icône ; utilisez son menu pour contrôler le proxy. `--no-start` s’applique à `install` et installe l’icône sans la lancer immédiatement.
+
+## Tableau de bord
+
+### `ocx gui`
+
+Ouvre le [tableau de bord Web](/fr/guides/web-dashboard/) à l’adresse `http://localhost:` et démarre automatiquement le proxy s’il n’est pas actif.
+
+## Mise à jour
+
+### `ocx update [--tag latest|preview]`
+
+Met à jour opencodex depuis npm. Les installations stables utilisent `@latest` ; les préversions restent sur `@preview`, sauf si vous indiquez `--tag latest|preview`. La commande détecte un dépôt de sources et vous invite alors à exécuter `git pull && bun install`. Elle ne fait rien si la version la plus récente correspondant à cette balise est déjà installée.
+
+Avant tout arrêt, les installations npm effectuent sous Unix un contrôle borné de la propriété et de l’accès au cache. Les liens symboliques imbriqués sont examinés avec `lstat`, sans être suivis ; Windows ignore explicitement ce contrôle propre à Unix. En cas d’échec, l’opération s’interrompt tandis que l’icône et le proxy fonctionnent encore. Le proxy actif est ensuite arrêté avant le remplacement des fichiers. Un service installé est reconstruit et redémarré automatiquement ; pour une installation au premier plan, la commande indique `ocx start` comme étape suivante. Avant leur conservation, les enregistrements de mise à jour du tableau de bord masquent les chemins de profil et de cache ainsi que les valeurs UID/GID.
+
+```bash
+ocx update
+ocx update --tag preview
+```
+
+Les nouvelles versions deviennent disponibles lorsque le [workflow de publication](https://github.com/lidge-jun/opencodex/actions/workflows/release.yml) les publie sur npm.
diff --git a/docs-site/src/content/docs/fr/reference/cli/providers-accounts.md b/docs-site/src/content/docs/fr/reference/cli/providers-accounts.md
new file mode 100644
index 0000000000..4b9a4b710f
--- /dev/null
+++ b/docs-site/src/content/docs/fr/reference/cli/providers-accounts.md
@@ -0,0 +1,386 @@
+---
+title: CLI Fournisseurs, comptes et modèles
+description: Commandes de configuration du fournisseur, d'informations d'identification, de quota et de catalogue de modèles.
+---
+
+Ces commandes configurent les fournisseurs en amont, authentifient les comptes, gèrent les pools d'informations d'identification et contrôlent le catalogue de modèles exposé à Codex.
+
+## Fournisseurs
+
+### `ocx provider `
+
+Gestion des fournisseurs non interactive. Les entrées de registre sont classées par nom ; un nom personnalisé nécessite
+à la fois `--adapter` et `--base-url`.
+
+| Sous-commande | Drapeaux pris en charge | Actions |
+| --- | --- | --- |
+| `list` | `--json` | Répertoriez les fournisseurs configurés et les entrées de registre restantes. |
+| `add ` | `--adapter `, `--base-url `, `--api-key `, `--default-model `, `--set-default`, `--force`, `--json`, `--sync` | Ajoutez un fournisseur registry/custom. `--force` écrase ; `--sync` actualise un proxy en cours d'exécution en mode sortie humaine. |
+| `edit ` | indicateurs de champ du fournisseur, `--headers `, `--json` | Modifiez les champs de fournisseur en direct validés sans remplacer les pools de clés. `--headers` fusionne les en-têtes de requête personnalisés ; passez `{}` ou `-` pour les effacer. |
+| `test ` | `--json` | Sondez le véritable point de terminaison du modèle en amont. |
+| `show ` | `--json` | Afficher la configuration avec les clés API masquées. |
+| `remove ` | `--json` | Supprimer un fournisseur autre que celui par défaut ; le dernier fournisseur ne peut pas être supprimé. |
+| `set-default ` | `--json` | Sélectionnez un fournisseur existant par défaut. |
+| `selected ` | `--set `, `--clear`, `--json` | Lisez ou mettez à jour la liste autorisée du modèle de fournisseur. |
+| `quota` | `--refresh`, `--json` | Lire les rapports sur les quotas des fournisseurs. |
+| `presets` | `--json` | Répertoriez les préréglages du fournisseur de tableau de bord. |
+| `account-mode` | `pool`, `direct`, `--json` | Sélectionnez le routage de compte mutualisé ou direct Codex. |
+
+```bash
+ocx provider list --json
+ocx provider test ark
+ocx provider add anthropic --api-key sk-ant-... --set-default --sync
+ocx provider add local-dev --adapter openai-chat --base-url http://localhost:11434/v1
+ocx provider show anthropic --json
+ocx models --provider anthropic --json
+ocx models live --provider ark --json
+```
+
+:::caution[Les en-têtes personnalisés ne sont pas un canal d'identification]
+`--headers` est destiné aux métadonnées de requête non secrètes : conseils de routage, locataire ou
+sélecteurs de projets, identifiants de traçage. Ce n'est **pas** un endroit pour mettre l'authentification
+matériel, et le validateur rejette les noms d'en-tête d'identification standard
+(`Authorization`, `X-Api-Key`, `Cookie` et le reste) avec un pointeur vers
+`apiKey` / `authMode`.
+
+Le validateur ne peut pas reconnaître un nom arbitraire tel que `X-My-Token`, donc le
+la frontière est à vous de la respecter. Deux raisons pour lesquelles c'est important :
+
+- Le JSON est un argument de ligne de commande, donc un secret qu'il contient atterrit dans l'historique du shell
+ et dans la liste des processus, où tout autre processus sur la machine peut le lire
+ avant que le CLI ne rédige quoi que ce soit.
+- Les valeurs d'en-tête sont conservées dans `config.json` en texte clair, contrairement aux clés API,
+ qui ont leur propre chemin de stockage et de masquage.
+
+Utilisez `--api-key` ou un identifiant OAuth pour tout ce qui est secret.
+:::
+
+## Authentification
+
+### `ocx login `
+
+Démarrez le flux de connexion enregistré du fournisseur. Les fournisseurs OAuth ouvrent un navigateur et stockent
+sous `~/.opencodex/` des informations d’identification actualisées automatiquement. Les fournisseurs à clé API
+ouvrent leur tableau de bord de clés, demandent la clé, la valident lorsque c’est possible, puis enregistrent la
+configuration de fournisseur obtenue. Lorsque le nom est absent ou inconnu, la commande affiche les identifiants
+de fournisseurs OAuth et à clé API actuellement acceptés.
+
+Utilisez la même commande pour **réauthentifier** après `ocx status` / `ocx doctor` rapports
+réauthentification requise ou échec de l'actualisation du terminal (ou utilisez Réauthentifier dans le tableau de bord).
+Les comptes du groupe Codex ne constituent pas un fournisseur public pour `ocx login` : réauthentifiez-vous
+plutôt depuis le groupe de comptes Codex du tableau de bord (**Réauthentifier**) ou avec le flux non
+interactif `ocx account reauth`.
+
+```bash
+ocx login xai
+ocx login anthropic
+```
+
+Un proxy déjà en cours d'exécution récupère le nouvel identifiant sans redémarrage : le CLI lui demande de
+rechargez ce fournisseur à partir du disque et la demande ne contient aucune information d'identification propre. Si le
+le proxy en cours d'exécution ne peut pas accepter cette demande - le plus souvent parce qu'il a démarré à partir d'une version antérieure
+rechargement attesté : la connexion réussit toujours et les informations d'identification sont toujours écrites sur le disque, mais le
+le processus live continue de servir le précédent. Le CLI le dit et vous demande de redémarrer :
+
+```text
+⚠️ A proxy is running but could not reload this provider (unattested-target).
+ The credential is saved to disk; the running proxy keeps using the previous one.
+ Restart it to pick this up: ocx restart
+```
+
+### `ocx logout `
+
+Supprimez les informations d'identification OAuth stockées pour un fournisseur.
+
+## Comptes et pools de clés
+
+### `ocx account `
+
+Répertoriez et changez de compte de fournisseur et de pools de clés API via le proxy en cours d'exécution. L'aide expédiée
+la surface est :
+
+```text
+Usage: ocx account ...
+
+list [provider] Codex account pool, OAuth accounts and API keys (identifiers shown masked as the API returns them).
+current Show the active account or key.
+use Switch the active credential; 'main' selects the Codex App login.
+refresh Force-refresh Codex or provider quota reports.
+auto-switch Control the Codex pool threshold.
+priority [first|earlier|normal|later|last|-100..100|reset] Selection order; omit the value to read it.
+remove --yes Remove a stored account or key after an existence check.
+add-key [--label