> ## Documentation Index > Fetch the complete documentation index at: https://docs.aihubmix.com/llms.txt > Use this file to discover all available pages before exploring further. # Tutoriel : connecter AIHubMix dans Codex CLI > Connectez AIHubMix dans Codex CLI : avec une seule clé API, changez librement de modèle (GLM, Claude, Gemini, DeepSeek...) depuis la liste /model. Inclut la config config.toml, un script de génération du catalogue model_catalog_json et un dépannage FAQ. [Codex CLI](https://openai.com/codex/) est l'outil de programmation en terminal officiel d'OpenAI. Après connexion à AIHubMix, une seule clé API suffit pour appeler et changer librement entre les modèles GLM, Claude, Gemini, DeepSeek et d'autres, sans dépendre d'un seul fournisseur. Ce guide couvre deux approches : l'**approche de base** (profile + un modèle fixe, la plus rapide) et l'**approche modèles personnalisés** (un fichier catalogue `model_catalog_json` pour changer à tout moment depuis la liste `/model`). ## Installation ### Téléchargement officiel (version macOS) [https://openai.com/en/codex/](https://openai.com/en/codex/) ### Installation via la ligne de commande ```bash theme={null} npm install -g @openai/codex ``` ## Configuration des variables d'environnement ### Configurer à l'aide des fichiers de configuration 1. Modifiez le fichier de configuration `~/.codex/config.toml` en ajoutant les paramètres suivants : ```toml theme={null} profile = "aihubmix" [model_providers.aihubmix] name = "aihubmix" base_url = "https://aihubmix.com/v1" personality = "pragmatic" wire_api = "responses" [profiles.aihubmix] model = "gpt-5.2" model_provider = "aihubmix" model_reasoning_effort = "high" ``` 2. Modifiez le fichier de configuration `~/.codex/auth.json` pour modifier les paramètres suivants : ```json theme={null} { "OPENAI_API_KEY": "AIHUBMIX_API_KEY" } ``` ### Configurer via cc-switch 1. Lancez CC-Switch et ajoutez le fournisseur. Écran d'ajout de fournisseur dans CC-Switch 2. Sélectionnez « AiHubMix » dans la liste prédéfinie. Sélection d'AiHubMix dans la liste de préréglages CC-Switch 3. Saisissez votre clé dans le champ « API Key » et cliquez sur « Add » pour enregistrer les paramètres. Saisie de la clé API et enregistrement dans CC-Switch 4. Revenez à la page d'accueil, sélectionnez « AiHubMix » dans la liste des fournisseurs et cliquez sur « Enable » pour commencer à l'utiliser. Activation du fournisseur AiHubMix dans CC-Switch ## Utilisation de Codex ### Utilisation dans le terminal 1. Ouvrez le terminal, accédez au répertoire de votre projet et exécutez la commande `codex`. ```bash theme={null} cd /your/project/path codex ``` 2. Définissez les autorisations selon vos besoins. Définition des autorisations au démarrage de Codex 3. Sélectionnez le modèle dont vous avez besoin en fonction de vos exigences. Choix du modèle à utiliser dans Codex 4. Saisissez du langage naturel ; si vous recevez une réponse normale, la configuration est réussie. Saisie en langage naturel dans le terminal Codex avec réponse normale ### Utilisation dans l'application de bureau Codex 1. Ouvrez l'application de bureau Codex et sélectionnez le répertoire de travail. 2. Saisissez la tâche dans la zone de saisie ; si vous recevez une réponse normale, la configuration est réussie. Saisie d'une tâche dans Codex bureau avec réponse normale ## Références de commandes utiles ### Commande d'aide ```bash theme={null} codex -h ``` ### Options de commande complètes ```bash theme={null} Usage $ codex [options] Options -h, --help Show help information and exit -m, --model Specify the model to use (default: codex-mini-latest) -i, --image Path to the file containing image input -v, --view View previously saved session records -q, --quiet Non-interactive mode, only prints the final output of the assistant -a, --approval-mode Override approval policy: 'suggest', 'auto-edit', or 'full-auto' --auto-edit Automatically approve file edits; will still prompt for command confirmation --full-auto Automatically approve edits and commands in sandbox environment --no-project-doc Do not automatically include 'codex.md' file from the repository --project-doc Include specified Markdown file as context --full-stdout Do not truncate stdout/stderr of command output Dangerous Options --dangerously-auto-approve-everything Skip all confirmation prompts and execute commands directly (no sandbox protection) For use only in temporary local testing environments Experimental Options -f, --full-context Start in "full context" mode, loading the entire repository into context and applying bulk edits in a single operation Only compatible with --model parameter Examples $ codex "Write and run a Python program that prints ASCII art" $ codex -q "Fix build issues" ```

Utiliser des modèles personnalisés dans Codex

Par défaut, Codex n'affiche que les modèles officiels d'OpenAI dans la liste `/model`. Si vous souhaitez sélectionner directement n'importe quel modèle disponible sur AIHubMix (GLM, Claude, Gemini, DeepSeek, Kimi, Qwen, etc.) depuis cette liste, vous pouvez utiliser le mécanisme officiel de « modèles personnalisés » : déclarez les modèles disponibles via un fichier JSON local (`model_catalog_json`), puis dirigez les requêtes vers AIHubMix à l'aide de `[model_providers.aihubmix]`. > Documentation officielle : [Advanced Configuration · OSS mode / local providers](https://developers.openai.com/codex/config-advanced) ### Deux méthodes d'intégration La section « Configuration des variables d'environnement » plus haut sur cette page décrit la **méthode de base**, tandis que cette section décrit la **méthode des modèles personnalisés**. Voici les différences, à choisir selon vos besoins : | | Méthode de base (profil + modèle unique) | Méthode des modèles personnalisés (cette section) | | --------------------------- | ------------------------------------------------------ | ---------------------------------------------------------------------- | | Contenu de la configuration | Un seul `model = "xxx"` codé en dur dans `config.toml` | Maintien d'un fichier de catalogue `model_catalog_json` supplémentaire | | Changement de modèle | Modifier le fichier de configuration puis redémarrer | Sélection directe dans la liste `/model`, à tout moment | | Cas d'usage adapté | Utilisation fixe d'un seul modèle sur le long terme | Comparaison / changement fréquent entre plusieurs modèles | | Complexité | Faible | Moyenne | Le processus complet ne comporte que 4 étapes : **générer le fichier de catalogue → modifier `config.toml` → définir la variable d'environnement → redémarrer et choisir le modèle**. ### Étape 1 : générer le fichier de catalogue de modèles Le fichier de catalogue est une structure `{ "models": [ ... ] }` ; chaque élément du tableau décrit un modèle sélectionnable dans `/model`. Nous expliquons d'abord les champs avec **un modèle fixe**, puis nous fournissons un script pour **générer en masse les 30 premiers modèles**. #### 1.1 Comprendre d'abord le format : un modèle fixe Voici un catalogue minimal complet **dont la prise en charge par Codex a été vérifiée** (ne contenant que le modèle `glm-5.2`). Enregistrez-le simplement sous `~/.codex/model-catalogs/custom-models.json` pour l'utiliser ; pour ajouter d'autres modèles, continuez d'ajouter des entrées de même structure au tableau `models`. ```json theme={null} { "models": [ { "slug": "glm-5.2", "display_name": "GLM 5.2", "description": "GLM 5.2 (via AIHubMix)", "context_window": 1000000, "max_context_window": 1000000, "supported_reasoning_levels": [ { "effort": "low", "description": "Fast responses" }, { "effort": "medium", "description": "Balanced" }, { "effort": "high", "description": "Deeper reasoning" } ], "shell_type": "shell_command", "visibility": "list", "supported_in_api": true, "priority": 0, "availability_nux": null, "upgrade": null, "base_instructions": "You are Codex, a coding agent.", "supports_reasoning_summaries": true, "support_verbosity": false, "default_verbosity": null, "apply_patch_tool_type": null, "truncation_policy": { "mode": "tokens", "limit": 10000 }, "supports_parallel_tool_calls": true, "experimental_supported_tools": [] } ] } ``` Description des champs (ceux que vous modifierez généralement) : | Champ | Rôle | Issu de l'API | | --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | `slug` | ID du modèle, utilisé par Codex pour initier les requêtes ; doit être identique au `model_id` renvoyé par l'API | `model_id` | | `display_name` | Nom affiché dans la liste `/model` | `model_name` | | `context_window` / `max_context_window` | Fenêtre de contexte. **Si vous l'omettez, Codex revient à une valeur par défaut très petite et conservatrice** ; il est recommandé de renseigner la valeur réelle de l'API | `context_length` | | `supported_reasoning_levels` | Niveaux de raisonnement ; après avoir changé de modèle, vous pouvez encore choisir l'effort via `/model` | — | | `visibility` | Doit être défini sur `list` pour apparaître dans le sélecteur | — | | `priority` | Ordre de tri dans la liste ; plus le nombre est petit, plus l'entrée est en haut | — | **Les autres champs sont obligatoires et leurs valeurs sont fixes** : `base_instructions`, `availability_nux`, `upgrade`, `supports_reasoning_summaries`, `support_verbosity`, `default_verbosity`, `apply_patch_tool_type`, `truncation_policy`, `supports_parallel_tool_calls`, `experimental_supported_tools`. Les versions récentes de Codex (vérifié sur `codex-cli 0.130.0`) appliquent une analyse stricte : **s'il manque ne serait-ce qu'un seul champ, l'intégralité du catalogue est ignorée** et Codex revient au catalogue intégré, avec une erreur du type `missing field base_instructions`, qui se traduit par « aucun modèle personnalisé visible dans `/model` ». Vous ne pouvez donc plus supprimer de champ de l'exemple ci-dessus. À propos de `base_instructions` : il s'agit du **prompt système** de ce modèle. L'exemple utilise une simple phrase comme valeur de remplacement, et le modèle fonctionne normalement ; pour obtenir un comportement de codage au plus proche du Codex natif, remplacez-la par les `base_instructions` complètes de l'un des modèles intégrés listés par `codex debug models --bundled` (c'est exactement ce que fait le script de génération en masse de la section suivante). Le catalogue officiel utilise des champs en **snake\_case** (`display_name`, `supported_in_api`, `visibility`). Deux types d'erreurs font ignorer l'intégralité du catalogue, et les modèles n'apparaissent pas dans `/model` : l'absence d'un champ obligatoire provoque `missing field ...` ; l'usage d'un ancien format camelCase comme `displayName`, `hidden`, ou d'une valeur non reconnue, provoque `unknown variant ...`. Suivez le jeu de champs présenté dans cet article pour éviter ces écueils. #### 1.2 Générer en masse les 30 premiers modèles Saisir plusieurs entrées à la main expose à des oublis de champs. Pour écrire en une seule fois dans le catalogue les 30 premiers LLM de l'[API de liste des modèles AIHubMix](https://aihubmix.com/api/v1/models?type=llm), utilisez le script ci-dessous — il **clone un modèle intégré comme modèle de référence**, si bien que les champs obligatoires (y compris les `base_instructions` correctes) sont par nature complets, quelle que soit la version de Codex. Nécessite `curl`, `python3` et la CLI `codex` déjà installée : ```bash theme={null} mkdir -p ~/.codex/model-catalogs # 1) Utiliser un modèle intégré comme modèle de référence : il contient déjà base_instructions et tous les champs obligatoires codex debug models --bundled > /tmp/_tpl.json # 2) Récupérer la liste des modèles AIHubMix curl -s "https://aihubmix.com/api/v1/models?type=llm" > /tmp/_aihubmix.json # 3) Cloner le modèle de référence pour chaque modèle, en ne remplaçant que les champs propres à chacun python3 - <<'PY' > ~/.codex/model-catalogs/custom-models.json import json, sys tpl = json.load(open("/tmp/_tpl.json"))["models"][0] # n'importe quel modèle intégré comme modèle de référence api = json.load(open("/tmp/_aihubmix.json"))["data"] # ignorer les modèles de génération d'images (types contenant image_generation), puis prendre les 30 premiers api = [m for m in api if "image_generation" not in (m.get("types") or "")][:30] out = [] for i, m in enumerate(api): e = dict(tpl) # cloner tous les champs du modèle de référence ctx = m.get("context_length") or 200000 e["slug"] = m["model_id"] # doit être identique au model_id de l'API e["display_name"] = m.get("model_name") or m["model_id"] e["description"] = (m.get("model_name") or m["model_id"]) + " (via AIHubMix)" e["context_window"] = ctx e["max_context_window"] = ctx e["visibility"] = "list" e["supported_in_api"] = True e["priority"] = i e["availability_nux"] = None e["upgrade"] = None out.append(e) json.dump({"models": out}, sys.stdout, ensure_ascii=False, indent=2) PY ``` Le script ne remplace que les champs propres à chaque modèle (`slug`, `display_name`, `description`, `context_window`, etc.) ; tous les autres champs obligatoires sont clonés depuis le modèle intégré — il s'agit précisément du jeu de champs de la section 1.1, à ceci près que `base_instructions` utilise le prompt officiel complet. > Le fichier généré est volumineux (chaque entrée contient les `base_instructions` complètes, soit environ 1 à 2 Mo), ce qui est normal. Après l'exécution, vérifiez avec `codex debug models` qu'il est correctement analysé (voir l'étape 5). > La ligne de filtrage `image_generation` du script est intentionnellement conservée : parmi les résultats de `type=llm`, quelques rares modèles portent aussi le label `image_generation` (par exemple `gpt-image-2`), qui ne conviennent pas au dialogue ; le script les ignore automatiquement avant de prendre les 30 premiers. ### Étape 2 : modifier `config.toml` Éditez `~/.codex/config.toml`, ajoutez `model_catalog_json` au **niveau racine** et définissez le fournisseur `aihubmix` : ```toml theme={null} # ⚠️ model_catalog_json doit être au niveau racine, pas dans [model_providers.*] model_provider = "aihubmix" model_catalog_json = "~/.codex/model-catalogs/custom-models.json" [model_providers.aihubmix] name = "Aihubmix" base_url = "https://aihubmix.com/v1" wire_api = "responses" env_key = "AIHUBMIX_API_KEY" ``` `wire_api = "responses"` est essentiel : **l'omettre ou écrire `chat` empêche toute connexion**. Les versions récentes de Codex n'utilisent que l'API Responses d'OpenAI (`/v1/responses`) ; AIHubMix étant nativement compatible avec l'API Responses, il suffit de pointer directement vers `https://aihubmix.com/v1`, sans avoir à mettre en place votre propre proxy de conversion. Si vous souhaitez par la même occasion définir un **modèle par défaut** et un **niveau de raisonnement par défaut** (utilisés directement au démarrage, sans sélection manuelle à chaque fois), vous pouvez utiliser cette configuration plus complète : ```toml theme={null} model = "glm-5.2" # modèle par défaut au démarrage ; doit exister dans le fichier de catalogue model_provider = "aihubmix" model_catalog_json = "~/.codex/model-catalogs/custom-models.json" model_reasoning_effort = "high" # niveau de raisonnement par défaut : minimal / low / medium / high [model_providers.aihubmix] name = "Aihubmix" base_url = "https://aihubmix.com/v1" wire_api = "responses" env_key = "AIHUBMIX_API_KEY" ``` Une fois configuré, votre `config.toml` ressemblera à ceci (les cadres rouges indiquent les éléments clés de cette étape : `model` / `model_provider` / `model_catalog_json` au niveau racine, ainsi que la section `[model_providers.aihubmix]`) : Config model_catalog_json et fournisseur aihubmix dans config.toml ### Étape 3 : définir la variable d'environnement Configurez la variable d'environnement spécifiée par `env_key` ci-dessus (attention à ne pas mettre d'espaces de part et d'autre du `=`) : ```bash theme={null} export AIHUBMIX_API_KEY=sk-xxx ``` Il est recommandé de l'ajouter à `~/.zshrc` / `~/.bashrc` pour la rendre persistante. Récupérez votre clé dans la [console AIHubMix](https://aihubmix.com/token). ### Étape 4 : redémarrer et choisir le modèle Redémarrez l'application / le TUI Codex pour que le fichier de catalogue prenne effet, puis : ```bash theme={null} codex # saisissez /model dans l'interface interactive pour voir les 30 modèles déclarés à l'étape précédente et en changer ``` Après avoir saisi `/model`, tous les modèles déclarés dans le catalogue s'affichent ; sélectionnez avec les flèches et confirmez avec Entrée : Sélecteur /model de Codex affichant la liste des modèles personnalisés AIHubMix Une fois le modèle sélectionné, `/model` vous permet aussi de choisir le niveau de raisonnement (effort) ; choisissez `low` / `medium` / `high` selon vos besoins. ### Étape 5 : vérifier la prise en compte 1. Une fois dans Codex, saisissez `/model`, vérifiez que vous voyez bien les modèles déclarés dans le catalogue et basculez sur l'un d'eux (par exemple `glm-5.2`). 2. Posez une question quelconque pour vérifier que la chaîne fonctionne. Attention : **ne vous fiez pas à la question « quel modèle es-tu ? »** — `base_instructions` indique « You are Codex... based on GPT-5 », si bien que tous les modèles se présenteront comme GPT-5 ; la question ne permet pas de distinguer le modèle réel. Pour confirmer le modèle réellement appelé, connectez-vous à la [console AIHubMix](https://aihubmix.com/token), ouvrez la page « Journaux » et consultez le `model_id` de cette requête : c'est cela qui fait foi. Une fois le changement réussi, un message `Model changed to ...` s'affiche en haut, et la barre d'état en bas indique le modèle courant ainsi que la fenêtre de contexte (sur l'image ci-dessous, le modèle a été basculé sur `glm-5.2`, avec une fenêtre de 258K) : Session Codex et barre d'état après passage à glm-5.2 ## Questions fréquentes sur les modèles personnalisés * **Vous ne voyez pas les modèles personnalisés dans `/model` ?** Vérifiez dans l'ordre suivant : 1. **Exécutez d'abord `codex debug models`**. S'il signale `missing field ...` (le plus fréquent, champ obligatoire manquant) ou `unknown variant ...` (nom de champ / valeur incorrect), c'est que l'intégralité du catalogue a échoué à l'analyse et a été ignorée — régénérez-le avec le script « cloner le modèle intégré » de l'étape 1. 2. Vérifiez que `model_catalog_json` est bien au **niveau racine** de `config.toml`, et non dans une section `[model_providers.*]` ; 3. Vérifiez que le JSON utilise les champs officiels en snake\_case et que `visibility` vaut `list` ; 4. Si `codex debug models` affiche déjà tous les modèles mais que, **dans l'application de bureau (Desktop App)**, il n'en reste qu'un ou deux et que le modèle courant s'affiche comme « personnalisé », il s'agit d'un bug connu de l'application de bureau : elle superpose, au-dessus du catalogue local, un filtre par liste blanche de slugs officiels, qui supprime du sélecteur les modèles non officiels (voir les GitHub Issues [#19694](https://github.com/openai/codex/issues/19694) et [#15138](https://github.com/openai/codex/issues/15138)). Dans ce cas, le modèle est en réalité toujours appelé conformément au `model = "..."` de `config.toml` (les journaux AIHubMix le confirment) ; seul son nom ne s'affiche pas. **Pour un affichage correct, utilisez la CLI `codex` / le TUI dans le terminal** ; sur l'application de bureau, vous ne pouvez que coder en dur `model = "le modèle souhaité"` dans `config.toml`, en attendant un correctif officiel. * **Le catalogue « remplace », il ne « fusionne » pas.** `model_catalog_json` **remplace** l'intégralité de la liste de modèles au lieu d'y ajouter des entrées (vérifié : avec seulement 2 modèles dans le catalogue, `codex debug models` n'en montre plus que 2, tous les `gpt-5.x` intégrés ayant disparu). Si vous voulez les deux types, écrivez-les ensemble dans votre catalogue personnalisé. * **La requête signale une erreur de protocole / impossible de se connecter.** C'est le plus souvent que le `base_url` ou le `wire_api` du fournisseur n'est pas correctement apparié. Pour AIHubMix, il faut impérativement `wire_api = "responses"` + `base_url = "https://aihubmix.com/v1"`. Si vous intégrez un tiers ne prenant en charge que Chat Completions, un proxy de conversion local est nécessaire ; les utilisateurs d'AIHubMix n'ont pas besoin de cette étape. * **Reconnexions « Reconnecting » fréquentes.** Dans certains environnements réseau / proxy, le WebSocket (WSS) ne passe pas ; vous pouvez ajouter `supports_websockets = false` dans la section du fournisseur pour forcer l'usage de HTTP. * **L'analyse signale `missing field ...` (par exemple `missing field base_instructions`).** Une entrée n'a pas de champ obligatoire. Les versions récentes de Codex appliquent une analyse stricte : `base_instructions`, `availability_nux`, `upgrade`, `supports_reasoning_summaries`, `support_verbosity`, `default_verbosity`, `apply_patch_tool_type`, `truncation_policy`, `supports_parallel_tool_calls`, `experimental_supported_tools`, etc., doivent tous être présents. Le script « cloner le modèle intégré » de l'étape 1 permet de tout compléter en une fois. * **L'analyse signale `unknown variant`.** Le JSON du catalogue contient un nom de champ ou une valeur que Codex ne reconnaît pas (souvent des anciens formats camelCase comme `displayName` / `hidden`). Passez au jeu de champs snake\_case présenté dans cet article. ## Articles de référence * Documentation officielle : [Advanced Configuration](https://developers.openai.com/codex/config-advanced) ｜ [Configuration Reference](https://developers.openai.com/codex/config-reference) * Format de référence du catalogue officiel intégré : [codex-rs/models-manager/models.json](https://github.com/openai/codex/blob/main/codex-rs/models-manager/models.json) * Guide communautaire : [Codex config.toml : intégrer n'importe quel fournisseur personnalisé en 6 lignes](https://www.morphllm.com/codex-provider-configuration) *** Dernière mise à jour : 2026-06-25