Connecter des modèles externes à Codex est une opération complexe. Ce guide utilise Kimi API comme exemple pratique pour vous accompagner pas à pas dans la configuration complète de l'API Codex sur macOS et Windows.
Qu'est-ce que Codex ?
Codex est l'agent de codage d'OpenAI conçu pour le travail sur les dépôts et le terminal. Il peut :
Écrire du code : créer des fonctions, des tests, des scripts et des fonctionnalités ciblées.
Comprendre des bases de code inconnues : rechercher dans les fichiers, suivre les appels et expliquer les composants.
Réviser du code : identifier les défauts probables, les hypothèses risquées, les tests manquants et les problèmes de sécurité.
Déboguer et corriger des problèmes : reproduire des erreurs, proposer des modifications et exécuter des vérifications.
Automatiser les tâches routinières : mettre à jour des fichiers et exécuter des flux de travail documentés, avec votre approbation.
Installer Codex et se connecter
Partie 1 : Installer Codex CLI
Ouvrez Terminal sur macOS ou PowerShell sur Windows.
Exécutez la commande correspondant à votre système d'exploitation :
macOS :
curl -fsSL https://chatgpt.com/codex/install.sh | shWindows :
powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"Attendez la fin de l'installation, puis fermez et rouvrez Terminal ou PowerShell.
Exécutez :
codexSélectionnez Se connecter avec ChatGPT, effectuez la connexion dans le navigateur, puis revenez à Terminal ou PowerShell.
Partie 2 : Installer l'application de bureau Codex
Consultez la page officielle de l'application de bureau Codex.
Téléchargez l'application de bureau ChatGPT pour macOS ou Windows.
Installez et ouvrez l'application, puis connectez-vous avec votre compte ChatGPT.
Créez une tâche ou ouvrez un projet, puis sélectionnez Codex comme mode de travail.
Saisissez
Say hello in one sentence.et envoyez le message.
Modèles d'IA intégrés ou API LLM externes
Après avoir installé Codex, vous pouvez utiliser ses modèles d'IA intégrés ou connecter une API LLM externe compatible. Le meilleur choix dépend du niveau de configuration, de flexibilité et de gestion de compte que vous souhaitez.
Utiliser les modèles intégrés de Codex
Les modèles intégrés offrent l'expérience la plus simple. Vous pouvez sélectionner un modèle disponible et commencer à coder sans lancer un autre service ni configurer une clé API distincte.
Avantages :
Configuration rapide, sans étape supplémentaire.
Intégration directe avec les outils et fonctionnalités de Codex
Moins de services et d'identifiants à gérer
Limites :
Vous ne pouvez choisir que parmi les modèles disponibles sur votre compte
Moins de flexibilité si vous souhaitez utiliser un modèle d'un autre fournisseur
Nécessite un abonnement GPT, et le coût d'utilisation est relativement élevé.
Utiliser une API LLM externe
Une API externe vous offre un plus grand choix de modèles et vous permet d'utiliser un compte existant chez un autre fournisseur. Cependant, certains modèles nécessitent une configuration supplémentaire ou un outil de compatibilité local avant que Codex puisse les utiliser.
Avantages :
Accès aux modèles d'autres fournisseurs
Plus de flexibilité pour différentes tâches de codage
Contrôle séparé du compte API externe et de son utilisation
Aucun abonnement GPT requis. Idéal pour les scénarios sensibles au coût.
Limites :
Nécessite une clé API et une configuration supplémentaire
Peut nécessiter un routeur local qui doit rester en cours d'exécution
La facturation, la compatibilité, la confidentialité et le dépannage dépendent du fournisseur externe
Si vous voulez la configuration la plus rapide, commencez avec un modèle intégré. Si vous avez déjà un compte API externe ou souhaitez un plus large choix de modèles, poursuivez avec le guide suivant. Il utilise Kimi API comme exemple concret pour connecter un modèle externe à Codex.
Comment connecter une API LLM externe à Codex : exemple avec Kimi
Configuration sous macOS
Étape 1 : ouvrir le Terminal A et vérifier Node.js et npm
Où : appuyez sur Command+Space, tapez Terminal, puis appuyez sur Entrée. Considérez cette première fenêtre comme le Terminal A.
Exécutez :
node --version
npm --versionRésultat attendu : chaque commande affiche une version. Les sorties telles que v22.x.x pour Node.js et 10.x.x pour npm ne sont que des exemples, pas des exigences minimales.
Si une commande n'est pas trouvée : ouvrez un navigateur, allez sur https://nodejs.org/en/download, téléchargez le .pkg macOS LTS, ouvrez le dossier Téléchargements dans Finder, double-cliquez sur le paquet et acceptez les options par défaut de l'installateur. Fermez le Terminal avec Command+Q, rouvrez le Terminal A, puis relancez les deux commandes de vérification de version. Ne continuez pas tant que les deux commandes ne renvoient pas de version.
Étape 2 : créer une clé API Kimi
Ouvrez la plateforme API Kimi. Créez une clé API depuis la console, puis stockez-la dans un gestionnaire de mots de passe ou de secrets. Si votre console n'affiche la clé complète qu'une seule fois, copiez-la avant de quitter la page.
Étape 3 : définir MOONSHOT_API_KEY dans le Terminal A
Où : revenez au Terminal A.
Exécutez :
export MOONSHOT_API_KEY="YOUR_KIMI_API_KEY"Remplacez uniquement YOUR_KIMI_API_KEY par votre véritable clé Kimi. Conservez les guillemets et le nom de la variable MOONSHOT_API_KEY inchangés.
Résultat attendu : la commande export n'affiche rien. Vérifiez qu'une valeur existe sans l'afficher :
test -n "$MOONSHOT_API_KEY" && echo "Kimi key is set"Le Terminal doit afficher Kimi key is set.
Étape 4 : tester Kimi directement depuis le Terminal A
Où : continuez d'utiliser le Terminal A, où MOONSHOT_API_KEY est défini.
Exécutez :
curl --silent --show-error https://api.moonshot.ai/v1/chat/completions \
-H "Authorization: Bearer $MOONSHOT_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"kimi-k2.7-code","messages":[{"role":"user","content":"Say hello in one sentence."}],"stream":false}'Résultat attendu : une réponse JSON apparaît et contient le texte généré sous choices[0].message.content.
Étape 5 : ouvrir le Terminal B et démarrer le routeur dans le Terminal A
Où : avec le Terminal A actif, appuyez sur Command+N pour ouvrir une deuxième fenêtre. Nommez la nouvelle fenêtre Terminal B. Revenez au Terminal A avant d'exécuter la commande du routeur.
Exécuter dans le Terminal A :
npx @codeproxy/cli --base-url https://api.moonshot.ai/v1 --model kimi-k2.7-code --apikey "$MOONSHOT_API_KEY"Ne remplacez pas l'URL de base ni le modèle. $MOONSHOT_API_KEY doit rester une référence de variable, et non une seconde copie collée de la clé.
Invite possible au premier lancement : npx peut afficher Need to install ... Ok to proceed? (y). Vérifiez d'abord le nom du package et la source tierce associée. Tapez y et appuyez sur Enter uniquement si vous acceptez ce package. Aucune version exacte de package n'est ici présentée comme testée.
Résultat attendu : le processus reste actif et indique qu'il écoute sur 127.0.0.1:8787. Laissez le Terminal A ouvert.
En cas d'échec : si npm ne parvient pas à télécharger le package, vérifiez l'accès à Internet et relancez node --version et npm --version. Si le port 8787 est déjà utilisé, arrêtez l'autre processus local utilisant ce port, ou revenez à son terminal et appuyez sur Ctrl+C, puis relancez la commande du routeur.
Étape 6 : tester localhost depuis le Terminal B
Où : cliquez sur le Terminal B.
Exécuter :
curl --no-buffer --show-error http://127.0.0.1:8787/v1/responses \
-H "Content-Type: application/json" \
-d '{"model":"kimi-k2.7-code","input":"Say hello in one sentence.","stream":true}'Résultat attendu : le Terminal B affiche des événements de streaming de type Responses ou une sortie contenant une salutation d'une phrase. La séquence exacte des événements peut varier selon la version du routeur.
Si vous voyez Connection refused: regardez le Terminal A. Si le routeur s'est arrêté, relancez la commande de l'étape 5 et laissez-la active. Si le Terminal A affiche une erreur 401 en amont, réinitialisez MOONSHOT_API_KEY à cet endroit et redémarrez le routeur.
Étape 7 : créer et modifier la configuration Codex sur macOS
Où : continuez à utiliser le Terminal B.
Exécuter :
mkdir -p "$HOME/.codex"
if [ -f "$HOME/.codex/config.toml" ]; then cp "$HOME/.codex/config.toml" "$HOME/.codex/config.toml.backup-$(date +%Y%m%d-%H%M%S)"; fi
touch "$HOME/.codex/config.toml"
open -e "$HOME/.codex/config.toml"Ces commandes créent le fichier de configuration au niveau utilisateur si nécessaire, sauvegardent un fichier existant et ouvrent ~/.codex/config.toml dans TextEdit.
Si le fichier est vide
Collez la configuration complète suivante :
model = "kimi-k2.7-code"
model_provider = "kimi-proxy"
model_context_window = 256000
model_supports_reasoning_summaries = false
[model_providers.kimi-proxy]
name = "Kimi via local proxy"
base_url = "http://127.0.0.1:8787/v1"
wire_api = "responses"
stream_idle_timeout_ms = 600000Si le fichier contient déjà des paramètres
Ne collez pas la configuration complète par-dessus le fichier existant. Conservez les paramètres non liés et mettez à jour les lignes requises individuellement.
Trouvez la ligne commençant par
model =et remplacez la ligne entière par :
model = "kimi-k2.7-code"Trouvez la ligne commençant par
model_provider =et remplacez la ligne entière par :
model_provider = "kimi-proxy"Trouvez la ligne commençant par
model_context_window =et remplacez la ligne entière par :
model_context_window = 256000Trouvez la ligne commençant par
model_supports_reasoning_summaries =et remplacez la ligne entière par :
model_supports_reasoning_summaries = falseSi l'un de ces quatre paramètres n'existe pas déjà, ajoutez la ligne manquante près du début du fichier.
Trouvez et supprimez toute ligne entière commençant par :
model_catalog_json =Trouvez également et supprimez toute ligne entière commençant par :
service_tier =Ajoutez la section ci-dessous :
[model_providers.kimi-proxy]
name = "Kimi via local proxy"
base_url = "http://127.0.0.1:8787/v1"
wire_api = "responses"
stream_idle_timeout_ms = 600000Ne supprimez pas les autres sections de fournisseur, comme [model_providers.openai].
Conservez les paramètres existants non liés, y compris les préférences notify, d'approbation, de sandbox, de projet et d'interface. Ne copiez pas la ligne notify d'un autre utilisateur, car elle peut contenir un chemin absolu spécifique à un ordinateur.
Appuyez sur Command+S pour enregistrer le fichier, puis fermez TextEdit.
Étape 8 : redémarrer Codex et effectuer le test complet sur macOS
Où : laissez le routeur s'exécuter dans le Terminal A. Dans le Terminal B, fermez toute session Codex existante avec Ctrl+C, puis préparez un dossier jetable.
Exécuter dans le Terminal B :
mkdir -p "$HOME/codex-kimi-test"
cd "$HOME/codex-kimi-test"
codexTest : tapez hello. et appuyez sur Enter. Une réponse d'une phrase confirme le bon fonctionnement d'une requête de base.
Configuration Windows
Utilisez deux fenêtres PowerShell indépendantes. PowerShell A stocke la clé Kimi de la session en cours et exécute le routeur. PowerShell B teste localhost, modifie la configuration et démarre Codex. La variable utilisateur persistante prend en charge les futures fenêtres ; l'affectation de session en cours rend la clé immédiatement disponible dans PowerShell A.
Étape 1 : ouvrez PowerShell A et vérifiez Node.js et npm
Où : appuyez sur la touche Windows, tapez PowerShell, puis ouvrez Windows PowerShell. Nommez cette fenêtre PowerShell A.
Exécutez :
node --version
npm --versionRésultat attendu : les deux commandes affichent des numéros de version. Des valeurs comme v22.x.x et 10.x.x ne sont que des exemples, pas des exigences minimales.
Si une commande n'est pas reconnue : ouvrez un navigateur et rendez-vous sur https://nodejs.org/en/download. Téléchargez le .msi Windows LTS, ouvrez Téléchargements dans l'Explorateur de fichiers, double-cliquez sur l'installeur, acceptez les options par défaut et assurez-vous que l'installeur conserve l'option qui ajoute Node.js au PATH. Fermez toutes les fenêtres PowerShell, rouvrez PowerShell A et relancez les deux commandes.
Étape 2 : créez une clé API Kimi
Ouvrez la plateforme Kimi API. Créez une clé API depuis la console, puis stockez-la dans un gestionnaire de mots de passe ou de secrets. Si votre console n'affiche la clé complète qu'une seule fois, copiez-la avant de quitter la page.
Étape 3 : définissez les variables persistantes et de session en cours dans PowerShell A
Où : retournez dans PowerShell A.
Exécutez :
[Environment]::SetEnvironmentVariable("MOONSHOT_API_KEY", "YOUR_KIMI_API_KEY", "User")
$env:MOONSHOT_API_KEY = "YOUR_KIMI_API_KEY"Remplacez uniquement YOUR_KIMI_API_KEY dans les deux lignes par la même clé Kimi. Laissez MOONSHOT_API_KEY, User, les guillemets et la ponctuation inchangés. La première ligne stocke la valeur pour les processus futurs. La seconde la rend immédiatement disponible dans PowerShell A.
Résultat attendu : les deux commandes ne renvoient aucune sortie. Vérifiez sa présence sans afficher la clé :
$null -ne $env:MOONSHOT_API_KEYPowerShell doit afficher True.
Si l'affichage est False : relancez l'affectation de session en cours avec des guillemets droits. Si l'écriture au niveau User a été bloquée par une stratégie, poursuivez ce guide avec la valeur de session en cours et demandez à votre administrateur comment stocker les variables d'environnement utilisateur. Révoquez toute clé exposée dans des journaux ou du texte partagé.
Étape 4 : testez Kimi directement depuis PowerShell A
Les références de l'API peuvent afficher POST URL, mais ne saisissez jamais POST https://... seul dans PowerShell. Utilisez Invoke-RestMethod -Method Post comme indiqué ici.
Où : restez dans PowerShell A, où $env:MOONSHOT_API_KEY est défini.
Exécutez :
$headers = @{ Authorization = "Bearer $env:MOONSHOT_API_KEY" }
$body = @{ model = "kimi-k2.7-code"; messages = @(@{ role = "user"; content = "Say hello in one sentence." }); stream = $false } | ConvertTo-Json -Depth 5
$response = Invoke-RestMethod -Method Post -Uri "https://api.moonshot.ai/v1/chat/completions" -Headers $headers -ContentType "application/json" -Body $body
$response.choices[0].message.contentNe remplacez pas le point de terminaison, le modèle ou le nom de la variable. PowerShell lit la clé depuis $env:MOONSHOT_API_KEY.
Résultat attendu : la dernière ligne affiche une salutation d'une phrase issue de choices[0].message.content.
Si vous recevez 401 : vérifiez que la clé provient bien de la console globale .ai, révoquez-la et recréez-en une si nécessaire, relancez les deux affectations de l'étape 3, puis réessayez. Si le modèle est rejeté, vérifiez que l'identifiant est exactement kimi-k2.7-code et contrôlez l'accès au modèle dans la console Kimi.
Étape 5 : ouvrez PowerShell B et démarrez le routeur dans PowerShell A
Où : appuyez à nouveau sur la touche Windows, tapez PowerShell, puis ouvrez une seconde fenêtre Windows PowerShell. Nommez-la PowerShell B. Retournez dans PowerShell A pour la commande du routeur.
Exécutez dans PowerShell A :
npx @codeproxy/cli --base-url https://api.moonshot.ai/v1 --model kimi-k2.7-code --apikey $env:MOONSHOT_API_KEYLaissez $env:MOONSHOT_API_KEY inchangé ; ne collez pas la clé directement dans la commande.
Invite possible au premier lancement : npx peut afficher Need to install ... Ok to proceed? (y). Vérifiez le paquet et la source tierce. Tapez y puis appuyez sur Entrée uniquement si vous l'acceptez. Aucune version exacte du paquet n'est présentée comme testée.
Résultat attendu : le processus reste ouvert et indique qu'il écoute sur 127.0.0.1:8787. Gardez PowerShell A ouvert.
En cas d'échec : exécutez node --version et npm --version dans PowerShell A. Si l'une échoue, reprenez l'étape 1. Si le port 8787 est occupé, arrêtez l'autre routeur avec Ctrl+C dans sa fenêtre, puis relancez la commande.
Étape 6 : testez localhost depuis PowerShell B
Où : cliquez sur PowerShell B. N'arrêtez pas le routeur dans PowerShell A.
Exécutez :
$localBody = @{ model = "kimi-k2.7-code"; input = "Say hello in one sentence."; stream = $false } | ConvertTo-Json
Invoke-RestMethod -Method Post -Uri "http://127.0.0.1:8787/v1/responses" -ContentType "application/json" -Body $localBodyNe remplacez pas l'URL localhost. Elle pointe vers le routeur dans PowerShell A.
Résultat attendu : PowerShell renvoie un objet de type Responses ou une sortie contenant la salutation. Les champs exacts peuvent varier selon la version du routeur.
Si la connexion est refusée : vérifiez PowerShell A et relancez la commande de l'étape 5 si le routeur s'est arrêté. Si PowerShell A affiche une erreur d'authentification amont, appuyez sur Ctrl+C, réinitialisez $env:MOONSHOT_API_KEY, puis redémarrez le routeur. N'ajoutez pas d'en-tête d'autorisation local pour le démarrage rapide par défaut de @codeproxy/cli.
Étape 7 : créez et modifiez la configuration Codex sous Windows
Où : continuez à utiliser PowerShell B. La configuration du fournisseur doit se trouver dans $HOME\.codex\config.toml, pas dans un dossier de projet.
Exécutez :
New-Item -ItemType Directory -Force -Path "$HOME\.codex" | Out-Null
$configPath = "$HOME\.codex\config.toml"
if (Test-Path $configPath) { Copy-Item $configPath "$configPath.backup-$(Get-Date -Format 'yyyyMMdd-HHmmss')" }
if (-not (Test-Path $configPath)) { New-Item -ItemType File -Path $configPath | Out-Null }
notepad "$HOME\.codex\config.toml"Ces commandes créent le répertoire utilisateur, sauvegardent une configuration existante, créent le fichier s'il est absent, et l'ouvrent dans le Bloc-notes.
Dans le Bloc-notes : collez cette configuration par défaut complète, en supprimant les clés de modèle ou de fournisseur en double si le fichier en contient déjà :
model_provider = "kimi-proxy"
model = "kimi-k2.7-code"
model_context_window = 256000
model_supports_reasoning_summaries = false
[model_providers.kimi-proxy]
name = "Kimi via local proxy"
base_url = "http://127.0.0.1:8787/v1"
wire_api = "responses"
stream_idle_timeout_ms = 600000Ne remplacez pas kimi-proxy, l'URL localhost, ni responses. Appuyez sur Ctrl+S et fermez le Bloc-notes.
Vérifiez le nom du fichier : Exécutez :
Get-Item "$HOME\.codex\config.toml" | Select-Object FullName, Name, LengthRésultat attendu : Name est exactement config.toml, et non config.toml.txt, et Length est supérieur à zéro.
Si le Bloc-notes a ajouté .txt : Dans le Bloc-notes, choisissez Fichier → Enregistrer sous, définissez Type sur Tous les fichiers, saisissez config.toml, puis enregistrez-le dans $HOME\.codex. Réexécutez Get-Item. Si Codex ignore le fournisseur, vérifiez que vous avez bien modifié le chemin au niveau utilisateur et supprimez les clés TOML en double.
Étape 8 : redémarrez Codex et effectuez le test Windows complet
Où : Laissez PowerShell A et son routeur en cours d'exécution. Fermez complètement toute application ou session Codex. Fermez PowerShell B, rouvrez-le via la touche Windows → tapez PowerShell → ouvrez Windows PowerShell, puis créez un dossier temporaire.
Exécutez dans le PowerShell B rouvert :
New-Item -ItemType Directory -Force -Path "$HOME\codex-kimi-test" | Out-Null
Set-Location "$HOME\codex-kimi-test"
codexTest : Tapez hello. puis appuyez sur Entrée. Une réponse d'une phrase confirme un chemin de requête de base.
Utiliser Kimi dans l'application de bureau Codex
Avant de continuer, effectuez les étapes 1 à 7 de la configuration macOS ou Windows pour le routeur local et config.toml. Vous n'êtes pas obligé de terminer d'abord le test CLI, mais le routeur doit rester en cours d'exécution pendant que vous utilisez Kimi dans l'application de bureau.
Étape 1 : laissez le routeur local en cours d'exécution
Laissez le Terminal A ou PowerShell A ouvert avec @codeproxy/cli en cours d'exécution sur :
http://127.0.0.1:8787Étape 2 : vérifiez la configuration du fournisseur
Ouvrez le fichier de configuration Codex au niveau utilisateur.
Sur macOS, exécutez :
open -e "$HOME/.codex/config.toml"Sur Windows, exécutez :
notepad "$HOME\.codex\config.toml"Vérifiez que le fichier contient ces paramètres de premier niveau :
model = "kimi-k2.7-code"
model_provider = "kimi-proxy"
model_context_window = 256000
model_supports_reasoning_summaries = false
[model_providers.kimi-proxy]
name = "Kimi via local proxy"
base_url = "http://127.0.0.1:8787/v1"
wire_api = "responses"
stream_idle_timeout_ms = 600000Étape 3 : redémarrez complètement l'application de bureau
Sur macOS, appuyez sur Command+Q pour quitter complètement l'application de bureau. Fermer seulement la fenêtre ne suffit pas.
Sur Windows, fermez toutes les fenêtres de l'application de bureau et vérifiez que l'application ne tourne plus dans la barre d'état système.
Rouvrez l'application de bureau et ouvrez un dossier de projet.
Étape 4 : gardez le modèle personnalisé sélectionné
Le sélecteur de modèle de l'application de bureau peut afficher Custom au lieu de Kimi K2.7 Code. C'est normal.
Les fournisseurs personnalisés définis dans config.toml ne sont pas toujours affichés par leur nom dans la liste des modèles de l'application de bureau. Ne sélectionnez pas un modèle OpenAI tel que GPT-5.6 Sol si vous souhaitez utiliser le fournisseur Kimi. Gardez Custom sélectionné.
Il se peut également que vous voyiez cet avertissement :
Model metadata for `kimi-k2.7-code` not found.
Defaulting to fallback metadata.Il s'agit d'un avertissement, pas d'un échec de connexion. Les paramètres suivants fournissent déjà les informations de modèle importantes nécessaires pour une utilisation normale :
model_context_window = 256000
model_supports_reasoning_summaries = falseÉtape 5 : vérifiez le chemin de requête de l'application de bureau
Envoyez ce prompt dans l'application de bureau :
Observez le Terminal A ou PowerShell A pendant que l'application de bureau répond. Si la fenêtre du Terminal A reçoit une nouvelle requête et que l'application de bureau renvoie une réponse, cela signifie que l'application de bureau utilise la route Kimi locale.
Résolution des erreurs d'intégration courantes
zsh: command not found: POST
POST URL est une notation de documentation d'API, pas une commande. Sur macOS, copiez l'exemple curl complet. Sur Windows, copiez l'exemple Invoke-RestMethod -Method Post complet.
Connexion refusée sur le port 8787
Retournez au Terminal A ou à PowerShell A. Si aucun processus de routeur n'est en cours d'exécution, définissez la variable Kimi de la session actuelle et réexécutez la commande documentée npx @codeproxy/cli .... Laissez cette fenêtre ouverte, puis répétez le test localhost dans la fenêtre B.
Une réponse 401
Lisez la fenêtre du routeur pour identifier le saut défaillant. Un 401 en amont provenant de Kimi signifie généralement que MOONSHOT_API_KEY est invalide, révoquée, ou provient d'un mauvais compte régional. Révoquez la clé dans la console .ai globale, créez-en une nouvelle, réinitialisez la variable de la session actuelle, puis redémarrez le routeur. Le chemin par défaut du routeur ne comporte aucune vérification de jeton entrant. Un 401 local avec un autre adaptateur peut signifier que sa CODEX_KIMI_PROXY_KEY optionnelle est manquante ou invalide.
Erreurs de paramètre ou d'outil non pris en charge
Le routeur transmet peut-être un champ que Kimi n'accepte pas. Les champs d'échantillonnage doivent rester non définis ; s'ils sont émis, ils doivent utiliser les valeurs fixes acceptées. Vérifiez que tool_choice vaut auto ou none et que l'adaptateur préserve reasoning_content. Si le test à plusieurs étapes échoue toujours, cessez d'utiliser cette version du routeur et choisissez-en ou mettez-en à jour une avec une prise en charge explicite de Kimi.
Codex ignore le fournisseur
Ouvrez directement le fichier utilisateur : exécutez open -e "$HOME/.codex/config.toml" sur macOS ou notepad "$HOME\.codex\config.toml" sur Windows. Vérifiez qu'il n'y a qu'un seul model_provider = "kimi-proxy" au niveau supérieur, une seule table de fournisseur, l'URL de base localhost, et wire_api = "responses". Enregistrez, quittez complètement Codex, puis relancez-le. Ne placez pas la sélection du fournisseur uniquement dans un .codex/config.toml de projet.
npx ne parvient pas à démarrer le routeur
Exécutez node --version et npm --version dans la fenêtre A du routeur. Si l'une de ces commandes échoue, installez le paquet Node.js LTS depuis nodejs.org/download, fermez puis rouvrez le terminal, et réessayez. Si npx demande l'autorisation de télécharger le paquet, examinez le paquet et sa source avant de saisir y.
Avantages de l'utilisation de l'API Kimi
Utiliser Kimi dans les workflows de Cursor API peut améliorer les tâches de codage, de débogage et de développement. Ses capacités avancées aident à générer des réponses précises, à traiter des instructions complexes et à accélérer la résolution des problèmes. Voici les principaux avantages de l'utilisation de Kimi dans les workflows Cursor pour renforcer la productivité et l'efficacité.
Compréhension du code sur de longs contextes
Kimi peut traiter de grandes quantités de code et d'informations en une seule fois. Il identifie plus efficacement les relations entre différents fichiers et sections d'un projet. Résultat : travailler avec des bases de code volumineuses ou complexes devient beaucoup plus simple.
Meilleure analyse de la documentation et des dépôts
Les documents de projet, notes techniques et dépôts peuvent être examinés rapidement avec Kimi. Il devient plus facile de repérer les détails importants sans parcourir chaque fichier manuellement. Les développeurs peuvent ainsi obtenir une compréhension plus claire de l'ensemble du projet en moins de temps.
Développement IA économique
Kimi offre une option pratique et abordable pour gérer de nombreuses tâches de développement. Un support IA puissant est disponible sans dépendre entièrement de modèles plus coûteux. Les équipes peuvent améliorer leur productivité globale tout en maîtrisant mieux les dépenses.
Recherche d'informations plus rapide
Les informations utiles peuvent être localisées rapidement dans de grandes bases de code, jeux de données et fichiers de projet. Moins de temps est passé à fouiller les ressources pour trouver des réponses ou des références. Davantage d'attention peut être consacrée au codage, aux tests et à l'amélioration du projet.
Automatisation améliorée des workflows
Les tâches de développement répétitives deviennent plus faciles à gérer et à accomplir avec Kimi. Il peut aider à la génération de code, à la relecture de contenu et aux activités courantes du projet. Les workflows quotidiens restent organisés, efficaces et de plus en plus productifs.
Comment Codex améliore le workflow de développement
Un workflow Codex CLI API configuré réunit l'inspection du dépôt, l'édition, les commandes et la revue dans un seul contexte. Codex peut créer des fichiers, expliquer des modules inconnus, reproduire des échecs, proposer des tests et exécuter des vérifications approuvées. La prise en charge de fournisseurs externes ajoute un choix de modèle, mais ne dispense pas de la responsabilité de la revue.
Commencez chaque tâche avec un objectif restreint. Demandez à Codex d'inspecter avant de modifier, examinez ses changements proposés, n'approuvez que les commandes que vous comprenez, exécutez les tests du dépôt, et inspectez le diff final. Traitez le code généré comme une contribution non fiable tant qu'il n'a pas passé la revue et la vérification.
Conclusion
Un usage fiable de l'API Codex passe par le test de chaque couche dans l'ordre : authentifier Codex, appeler Kimi directement, démarrer et tester localhost, enregistrer la configuration du fournisseur au niveau utilisateur, exécuter un prompt en lecture seule, et mener à bien une tâche impliquant fichiers et outils. Conservez la vraie clé Kimi avec le routeur, gardez les secrets hors des fichiers partagés, et arrêtez le routeur une fois terminé.