TL;DR
Configurez une seule fois CometAPI dans OpenCode, puis choisissez Claude, GPT ou DeepSeek pour votre tâche de programmation. Ce guide développe le guide d’intégration officiel de CometAPI à OpenCode en une configuration de projet complète : une clé API CometAPI, un fichier de configuration avec trois exemples de modèles, des commandes de bascule entre modèles et une petite tâche JavaScript avec une vérification reproductible.
Points clés
- La configuration d’OpenCode avec CometAPI requiert un ID de fournisseur, une URL de base d’API, des identifiants et un ID de modèle.
- Utilisez {env:COMETAPI_KEY} pour éviter d’inclure la clé API dans opencode.json.
- Enregistrez des exemples Claude, GPT et DeepSeek dans un seul opencode.json ; les trois entrées utilisent la même clé CometAPI et la même passerelle.
- Basculez le fournisseur/modèle sélectionné dans OpenCode sans obtenir de clés Anthropic, OpenAI ou DeepSeek distinctes.
- Surveillez les variables d’environnement manquantes, les routes d’API non correspondantes et les invites d’approbation qui peuvent donner l’impression de requêtes bloquées.
Qu’est-ce qu’OpenCode et pourquoi l’utiliser avec CometAPI ?
OpenCode est un agent de codage IA open source avec une interface terminal, une application de bureau et une extension IDE. Dans un projet, il peut expliquer du code existant, planifier un changement, modifier des fichiers et exécuter des commandes sous des permissions configurées. Ce tutoriel utilise le flux terminal : donnez à l’agent une petite tâche de programmation, examinez ses actions proposées et vérifiez les fichiers résultants avec un test local. Consultez la documentation officielle d’OpenCode pour l’installation et l’utilisation.
CometAPI fournit la couche d’accès aux modèles. Un flux de travail multi-modèles implique sinon la gestion des identifiants, de la facturation et des paramètres de connexion chez plusieurs fournisseurs. Le routage des modèles pris en charge via un seul compte CometAPI donne à ce projet une clé et une URL de base communes, tandis qu’OpenCode conserve le dépôt et les instructions de tâche. Ceci est utile pour comparer des modèles sur la même tâche ou changer de modèle sans réorganiser le projet. Une passerelle d’agrégation est facultative : un accès direct au fournisseur peut convenir à un flux de travail mono-fournisseur ou à des exigences contractuelles spécifiques. L’avantage ici est un accès multi-fournisseurs simplifié ; les formats d’API, le comportement des modèles et la compatibilité des outils nécessitent toujours des validations distinctes.
CometAPI prend en charge les Chat Completions compatibles OpenAI et expose également d’autres formats d’API. L’intégration officielle sélectionne un adaptateur pour chaque format. Ici, Claude Sonnet 5 utilise Messages, GPT-6.1 Sol utilise Responses et DeepSeek V4.1 Flash utilise Chat Completions, conformément aux exemples liés ci-dessous. Toutes les requêtes sont néanmoins envoyées à CometAPI avec la même clé. Un nom de fournisseur et un format d’API décrivent des choses différentes ; il ne faut pas supposer qu’un seul modèle accepte tous les formats.
| Configuration | API Claude Sonnet 5 dans CometAPI | API GPT-6.1 Sol dans CometAPI | API DeepSeek V4.1 Flash dans CometAPI |
|---|---|---|---|
| Fournisseur du modèle | Anthropic | OpenAI | DeepSeek |
| ID du modèle | claude-sonnet-5 | gpt-6.1-sol | deepseek-v4.1-flash |
| ID fournisseur OpenCode | cometapi-messages | cometapi-responses | cometapi-chat |
| Format d’API utilisé ici | Messages | Responses/ chat | Chat Completions |
| Adaptateur | @ai-sdk/anthropic | @ai-sdk/openai | @ai-sdk/openai-compatible |
Que faut-il avant de configurer CometAPI dans OpenCode ?
Utilisez un terminal, Node.js avec npm, un compte CometAPI avec accès API et un solde disponible, et un répertoire de projet jetable. Les exemples Bash s’appliquent à macOS, Linux ou WSL ; les exemples PowerShell étiquetés utilisent la syntaxe Windows. Node.js doit également être disponible dans la même session pour la vérification JavaScript plus loin dans ce guide.
Cette procédure utilise le style de configuration OpenCode 1. La documentation officielle distingue OpenCode 1 d’OpenCode 2 ; les deux utilisent la commande opencode. Relevez opencode --version avant de commencer et utilisez la documentation de configuration correspondant à cette version majeure. Le flux à trois modèles ci-dessous est une procédure d’intégration avec résultats attendus, et non une affirmation de test de bout en bout réussi.
Consignez votre CLI, Node.js, npm, système d’exploitation et date de test lors de l’exécution des exemples. L’utilisation de l’API est facturée à votre compte CometAPI. Les commandes ci-dessous constituent une procédure pratique avec des résultats attendus ; aucune sortie générée par modèle ni exécution d’intégration à trois modèles réussie n’est revendiquée.
node --versionnpm --versionopencode --version
Comment configurer CometAPI dans OpenCode pas à pas ?
Étape 1 : Installer OpenCode
Installez le package npm officiel si OpenCode n’est pas déjà disponible. L’installation non figée suit la version de package actuelle ; relevez la version installée avant d’utiliser la configuration. Si vous devez reproduire l’environnement du guide source, sa version CLI indiquée est 1.18.16.
Installez la CLI OpenCode et affichez sa version.
npm install -g opencode-aiopencode --version
Ouvrez un nouveau terminal si l’exécutable n’est pas trouvé après l’installation. Continuez dans un répertoire de projet jetable afin que la première tâche de l’agent ait une frontière claire.
Créez et entrez dans un répertoire de projet.
mkdir cometapi-opencode-democd cometapi-opencode-demo
Étape 2 : Créer une clé API CometAPI
Générez une clé API depuis votre compte CometAPI et définissez-la dans le même terminal que celui utilisé pour démarrer OpenCode. Remplacez l’espace réservé localement. Ne validez pas la clé, ne la collez pas dans des invites et ne l’incluez pas dans des journaux partagés.
La variable s’applique à la session en cours et aux processus lancés depuis celle-ci. Ne capturez pas un jeton réel en capture d’écran. Les vérifications suivantes indiquent si la variable existe sans imprimer sa valeur.
Définissez la clé CometAPI pour la session Bash en cours.
export COMETAPI_KEY="YOUR_COMETAPI_KEY"
Définissez la clé CometAPI pour la session PowerShell en cours.
$env:COMETAPI_KEY = "YOUR_COMETAPI_KEY"test -n "$COMETAPI_KEY" && printf "COMETAPI_KEY is set\n" || printf "COMETAPI_KEY is missing\n"if ([string]::IsNullOrWhiteSpace($env:COMETAPI_KEY)) { "COMETAPI_KEY is missing"} else { "COMETAPI_KEY is set"}
Étape 3 : Créer opencode.json
Créez opencode.json à la racine du projet, ou utilisez ~/.config/opencode/opencode.json pour rendre les entrées disponibles entre projets. Le fichier de projet garde ce tutoriel autonome. Utilisez un seul objet provider contenant les trois entrées ci-dessous ; si un objet provider existe déjà, fusionnez ses entrées au lieu de créer une clé JSON dupliquée.
En cas de champs en conflit, la configuration de projet a priorité sur la configuration globale ; les champs non conflictuels sont conservés. Le fichier OPENCODE_CONFIG personnalisé est chargé entre la configuration globale et la configuration de projet. Vérifiez la chaîne de priorité documentée si des paramètres gérés ou en ligne sont également présents.
Enregistrez la configuration complète suivante sous opencode.json. Chaque fournisseur lit COMETAPI_KEY depuis l’environnement. Le modèle par défaut est délibérément omis afin que vous puissiez choisir explicitement l’un des trois exemples.
La variante Flash explicite l’exemple DeepSeek V4.1 demandé. Conservez GPT sur l’adaptateur Responses pour l’utilisation des outils ; le guide DeepSeek de CometAPI documente la route Chat Completions utilisée ici. Revérifiez la disponibilité du modèle et les permissions dans votre compte avant d’exécuter les exemples.
{ "$schema": "https://opencode.ai/config.json", "provider": { "cometapi-messages": { "npm": "@ai-sdk/anthropic", "name": "CometAPI Claude", "options": { "baseURL": "https://api.cometapi.com/v1", "apiKey": "{env:COMETAPI_KEY}" }, "models": { "claude-sonnet-5": { "name": "Claude Sonnet 5" } } }, "cometapi-responses": { "npm": "@ai-sdk/openai", "name": "CometAPI GPT", "options": { "baseURL": "https://api.cometapi.com/v1", "apiKey": "{env:COMETAPI_KEY}" }, "models": { "gpt-6.1-sol": { "name": "GPT-6.1 Sol" } } }, "cometapi-chat": { "npm": "@ai-sdk/openai-compatible", "name": "CometAPI DeepSeek", "options": { "baseURL": "https://api.cometapi.com/v1", "apiKey": "{env:COMETAPI_KEY}" }, "models": { "deepseek-v4.1-flash": { "name": "DeepSeek V4.1 Flash" } } } }, "permission": { "edit": "ask", "shell": "ask" }}
baseURL correcte : https://api.cometapi.com/v1. baseURL incorrecte : https://api.cometapi.com/v1/chat/completions. L’adaptateur ajoute le chemin d’endpoint. Fusionnez l’exemple dans un opencode.json existant sans supprimer des paramètres non liés.
Les paramètres edit et shell demandent une approbation pour les modifications de fichiers et commandes selon les règles de permissions actuelles d’OpenCode. Exécutez les exemples de codage de manière interactive et inspectez ces demandes. OpenCode hérite également des accès système du processus qui le lance ; utilisez un répertoire jetable pour cet exercice.
Étape 4 : Vérifier la connexion à la passerelle
Une configuration et une vérification facultatives de Gemini sont fournies après les contrôles de connexion des trois modèles ci-dessous.
L’exemple HTTP ci-dessous vérifie directement l’entrée DeepSeek Chat Completions. C’est un moyen utile d’isoler la connexion à la passerelle d’OpenCode. Claude et GPT utilisent leurs routes d’adaptateur sélectionnées à l’étape suivante ; changer l’ID de modèle dans cette requête HTTP ne change pas automatiquement son protocole.
Envoyez une requête minimale Chat Completions depuis Bash.
curl --silent --show-error \ --output response.json \ --write-out "HTTP %{http_code}\n" \ https://api.cometapi.com/v1/chat/completions \ -H "Authorization: Bearer $COMETAPI_KEY" \ -H "Content-Type: application/json" \ -d '{"model":"deepseek-v4.1-flash","messages":[{"role":"user","content":"Reply with a short greeting."}]}'
Cette commande utilise les options write-out et output de curl pour séparer le statut HTTP de response.json. Un transfert réussi peut toujours contenir une erreur HTTP, donc inspectez le statut imprimé et le corps JSON. Cela évite de dépendre de --fail-with-body, qui nécessite curl 7.76.0 ou version ultérieure.
Envoyez la même requête depuis PowerShell sans guillemets JSON spécifiques au shell.
$body = @{ model = "deepseek-v4.1-flash" messages = @(@{ role = "user"; content = "Reply with a short greeting." })} | ConvertTo-Json -Depth 4$response = Invoke-WebRequest -UseBasicParsing -Method Post ` -Uri "https://api.cometapi.com/v1/chat/completions" ` -Headers @{ Authorization = "Bearer $env:COMETAPI_KEY" } ` -ContentType "application/json" ` -Body $body$response.Content | Set-Content -Encoding UTF8 response.json"HTTP $($response.StatusCode)"
En cas d’erreur HTTP, PowerShell peut lever une exception avant l’exécution des deux dernières lignes. Capturez le statut et les détails d’erreur caviardés issus de cet échec ; ne l’enregistrez pas comme une réponse réussie.
Résultat attendu pour la requête DeepSeek : HTTP 200 et un texte non vide dans choices[0].message.content. Inspectez le response.json enregistré plutôt que d’accepter le seul HTTP 200. Les ajouts suivants montrent la forme de réponse et comment vérifier les trois routes configurées. Les exemples sont illustratifs ; cette révision ne revendique pas de résultats de test CometAPI en direct. Une requête texte seule ne valide pas le streaming ni les appels d’outils.
Forme de réponse illustratrice DeepSeek : la salutation, les valeurs d’usage et d’autres champs dépendent de la requête réelle. Le JSON suivant est un exemple volontairement raccourci, pas une réponse d’API capturée.
{"choices":[{"message":{"role":"assistant","content":"Hello!"}}]}
Après une véritable requête HTTP réussie, la ligne de statut devrait indiquer HTTP 200 et response.json devrait contenir un texte assistant non vide. Conservez le statut et le corps réels de votre exécution ; ne copiez pas l’exemple comme preuve de test.
Étape 5 : Basculer entre Claude, GPT et DeepSeek
Les commandes de cette étape devraient renvoyer les marqueurs d’assistant demandés. Texte illustratif de l’assistant, bannières de terminal, chronométrage et métadonnées omis :
Claude: CLAUDE_READYGPT: GPT_READYDeepSeek: DEEPSEEK_READY
Ces lignes montrent uniquement le contenu attendu. Ce ne sont pas des transcriptions de terminal. Relevez la sortie réelle et le code de sortie du processus pour chaque fournisseur ; un marqueur manquant ou une requête échouée nécessite une investigation.
Commencez dans le répertoire contenant opencode.json. Listez les modèles pour chaque fournisseur configuré, puis faites une courte requête texte à chaque entrée. Ces commandes changent le modèle et l’adaptateur sélectionnés ; la clé CometAPI et l’URL de base restent identiques.
Utilisez ces commandes pour vérifier que les trois entrées sont visibles et peuvent renvoyer du texte.
opencode models cometapi-messagesopencode models cometapi-responsesopencode models cometapi-chatopencode run --model cometapi-messages/claude-sonnet-5 "Reply exactly with: CLAUDE_READY"opencode run --model cometapi-responses/gpt-6.1-sol "Reply exactly with: GPT_READY"opencode run --model cometapi-chat/deepseek-v4.1-flash "Reply exactly with: DEEPSEEK_READY"
Pour un basculement interactif, lancez opencode, entrez /models et sélectionnez CometAPI Claude, CometAPI GPT ou CometAPI DeepSeek. OpenCode utilise la paire fournisseur/modèle de cette entrée. Vous n’avez pas besoin de trois comptes fournisseurs ni de trois clés API. Avec cette configuration basée sur l’environnement, n’utilisez pas /connect pour fournir un deuxième identifiant ; une variable COMETAPI_KEY manquante doit être corrigée dans le shell de lancement.
Résultat attendu : chaque courte requête renvoie le marqueur demandé. Enregistrez le résultat réel pour chaque modèle. Une entrée de modèle visible confirme l’enregistrement ; une réponse texte réussie confirme ce chemin de requête. Ni l’un ni l’autre ne prouve que les outils de fichiers fonctionnent.
Gemini utilise un fournisseur et un protocole distincts. Conservez les entrées Claude, GPT et DeepSeek ci-dessus ; fusionnez l’entrée suivante dans l’objet provider existant. L’URL de base ci-dessous suit la configuration CometAPI fournie par le relecteur. Confirmez sa route actuelle et l’accès au modèle dans votre compte CometAPI avant usage.
L’adaptateur Google prend en charge une baseURL personnalisée et envoie apiKey via x-goog-api-key. Voir la référence officielle du fournisseur Google de l’AI SDK. Cela confirme les paramètres de l’adaptateur ; cela ne prouve pas qu’un modèle Gemini particulier est activé sur la passerelle CometAPI.
{ "provider": { "cometapi-gemini": { "npm": "@ai-sdk/google", "name": "CometAPI Gemini", "options": { "baseURL": "https://api.cometapi.com/v1beta", "apiKey": "{env:COMETAPI_KEY}" }, "models": { "YOUR_GEMINI_MODEL_ID": { "name": "CometAPI Gemini (account-selected model)" } } } }}
Remplacez YOUR_GEMINI_MODEL_ID à la fois dans la clé JSON et dans la commande ci-dessous par l’ID exact du modèle Gemini activé pour votre compte CometAPI. Il s’agit d’un espace réservé, pas d’un ID réel. Fusionnez cette entrée de fournisseur sans dupliquer la clé provider de niveau supérieur, et démarrez OpenCode depuis le même shell où COMETAPI_KEY est défini.
opencode models cometapi-geminiopencode run --model cometapi-gemini/YOUR_GEMINI_MODEL_ID "Reply exactly with: GEMINI_READY"
Texte attendu de l’assistant : GEMINI_READY. Un modèle listé confirme l’enregistrement local ; recevoir le marqueur confirme la requête texte. Enregistrez la réponse réelle et le code de sortie. Pour valider les outils de codage, lancez opencode --model cometapi-gemini/YOUR_GEMINI_MODEL_ID dans un nouveau répertoire jetable et répétez la tâche greet.cjs/check.cjs ci-dessous. Le succès texte seul ne vérifie pas le streaming, l’édition ou les appels d’outils.
Comment exécuter une tâche de codage avec Claude, GPT et DeepSeek ?
Utilisez la même petite tâche pour chaque modèle : créer une fonction de salutation, ajouter une assertion et l’exécuter. Conservez trois répertoires vierges pour que le second modèle ne puisse pas simplement réutiliser les fichiers créés par le premier. Cela vérifie le flux d’intégration sans transformer l’article en classement de performances.
Enregistrez prepare-runs.cjs à côté de opencode.json et exécutez-le une fois. Il crée trois nouveaux répertoires et ne copie que la configuration partagée. Il s’arrête si un répertoire cible existe déjà, de sorte que le travail précédent n’est pas écrasé.
const fs = require("node:fs");const path = require("node:path");const root = __dirname;const names = ["claude-demo", "gpt-demo", "deepseek-demo"];const config = path.join(root, "opencode.json");if (!fs.existsSync(config)) throw new Error("Missing opencode.json");for (const name of names) { if (fs.existsSync(path.join(root, name))) { throw new Error(`Directory already exists: ${name}`); }}for (const name of names) { const dir = path.join(root, name); fs.mkdirSync(dir); fs.copyFileSync(config, path.join(dir, "opencode.json"));}node prepare-runs.cjscd claude-demoopencode --model cometapi-messages/claude-sonnet-5# After exiting OpenCode:cd ..cd gpt-demoopencode --model cometapi-responses/gpt-6.1-sol# After exiting OpenCode:cd ..cd deepseek-demoopencode --model cometapi-chat/deepseek-v4.1-flash# After exiting OpenCode:cd ..
Exécutez l’une des sessions suivantes à la fois, en partant du répertoire parent du projet. Quittez la session avant de passer à l’exemple suivant. Dans chaque session, soumettez la même tâche ci-dessous et examinez les modifications et commandes proposées. Node.js doit être disponible pour le processus qui lance OpenCode.
Demandez à l’agent de créer et vérifier une petite fonction JavaScript.
Create greet.cjs in this directory.Export a function named greet(name) that returns "Hello, " + name + "!".Create check.cjs using node:assert/strict.Assert that greet("Ada") equals "Hello, Ada!".Run node check.cjs and report its actual exit status.Do not modify opencode.json or unrelated files.
Résultat attendu : l’agent demande les approbations configurées, crée les deux fichiers et exécute node check.cjs avec le code de sortie 0. Notez ce qui s’est réellement passé. Inspectez les fichiers et relancez la vérification vous-même ; une affirmation textuelle de réussite ne suffit pas. Si un appel d’outil est rejeté ou mal formé, examinez la compatibilité de la route séparément d’une approbation en attente.
Fichiers de référence et vérification locale
Les fichiers suivants sont une implémentation de référence de la tâche demandée. Ils ont été écrits directement pour ce guide ; ils ne sont pas présentés comme des artefacts générés par un modèle. Faire correspondre leur comportement observable est la condition d’acceptation de votre exécution d’agent.
function greet(name) { return "Hello, " + name + "!";}module.exports = { greet };const assert = require("node:assert/strict");const { greet } = require("./greet.cjs");assert.equal(greet("Ada"), "Hello, Ada!");node check.cjsprintf "exit=%s\n" "$?"node check.cjs"exit=$LASTEXITCODE"
Vérification de référence locale : Windows, Node.js v24.19.0, 22 octobre 2026 ; node check.cjs a renvoyé le code de sortie 0 sans sortie standard. Cela vérifie uniquement les deux fichiers de référence. Cela ne valide pas l’installation d’OpenCode, l’accès CometAPI, les invites d’approbation ou les appels d’outils du modèle.
| Exécution | Entrée de modèle sélectionnée | Ce qu’il faut relever |
|---|---|---|
| Claude | cometapi-messages/claude-sonnet-5 | Réponse, fichiers générés, approbations, code de test |
| GPT | cometapi-responses/gpt-6.1-sol | Réponse, fichiers générés, approbations, code de test |
| DeepSeek | cometapi-chat/deepseek-v4.1-flash | Réponse, fichiers générés, approbations, code de test |
Conservez un enregistrement de résultat par modèle : fournisseur/modèle sélectionné, réception d’une réponse, création de greet.cjs et check.cjs, apparitions d’approbations et code de sortie de node check.cjs. Enregistrez les échecs comme des échecs ; n’inférez pas une réussite à partir de l’implémentation de référence.
Protéger les identifiants et vérifier la fiabilité
Stockez COMETAPI_KEY dans une variable d’environnement plutôt que dans des fichiers de configuration ou des journaux partagés. Conservez les approbations d’édition de fichiers et d’exécution de commandes activées, et testez les nouvelles configurations dans un projet jetable.
Vérifiez séparément la requête API directe, la réponse OpenCode et le flux d’édition de fichiers. Enregistrez les erreurs et les résultats de test, ne réessayez que les échecs transitoires et inspectez l’espace de travail avant de répéter des tâches interrompues.
CometAPI simplifie la bascule entre les modèles, mais OpenCode n’offre pas automatiquement de bascule inter-modèles via cette configuration. Si un modèle devient indisponible, sélectionnez manuellement un autre modèle vérifié et répétez la vérification d’acceptation.
Combien coûte l’utilisation d’OpenCode avec CometAPI ?
Tarifs de CometAPI et structure de facturation
CometAPI propose une tarification à l’usage sans frais d’abonnement mensuels, ne facturant que l’utilisation réelle de l’API. Ses tarifs pour les modèles officiels sont généralement 20 % inférieurs aux prix standards des fournisseurs, avec des remises de volume supplémentaires disponibles. Les développeurs peuvent accéder à Claude, GPT, DeepSeek et d’autres modèles via un seul compte, en payant selon la consommation de jetons du modèle sélectionné. Consultez la page de tarification CometAPI pour les tarifs actuels.
Pour les requêtes sans mise en cache ni frais additionnels :
Coût = (Jetons d’entrée × Tarif d’entrée + Jetons de sortie × Tarif de sortie) / 1 000 000
Par exemple, à des tarifs hypothétiques de 1 $/M de jetons d’entrée et 4 $/M de jetons de sortie, utiliser 20 000 jetons d’entrée et 2 000 jetons de sortie coûte 0,028 $. Ce sont des tarifs illustratifs, pas des prix réels de modèles.
Relevez l’utilisation de jetons, le total facturé par l’API, le temps d’exécution et les résultats des tests pour chaque tâche. Pour réduire les coûts, limitez le contexte inutile, utilisez des invites concises, évitez les requêtes échouées répétées et choisissez des modèles moins coûteux lorsqu’ils répondent aux mêmes exigences de qualité.
Stratégies d’optimisation des coûts API avec OpenCode
Pour réduire les coûts OpenCode sans compromettre la qualité du code, concentrez-vous sur la sélection du modèle, l’efficacité des jetons et les requêtes API inutiles.
- Choisir le bon modèle : utilisez des modèles moins coûteux comme DeepSeek pour les tâches de codage courantes, en réservant Claude ou GPT pour le débogage, le refactoring et le raisonnement complexes.
- Réduire la consommation de jetons : gardez les invites concises, fournissez uniquement les fichiers pertinents du projet et évitez d’envoyer à répétition de grands volumes de contexte du dépôt.
- Utiliser la mise en cache des invites : profitez des fonctionnalités de cache prises en charge pour le contexte répété, comme les instructions de projet et les références de code, afin de réduire les coûts d’entrée.
- Éviter les tentatives inutiles : corrigez les erreurs de configuration et d’authentification avant de réessayer, et examinez les sorties précédentes pour éviter le travail en double.
- Surveiller les dépenses réelles : suivez l’utilisation des jetons, les frais API et l’achèvement des tâches via CometAPI. Comparez le coût par tâche réussie plutôt que les prix des jetons seuls.
Combinées à la tarification à l’usage et remisée de CometAPI, ces pratiques aident les développeurs à maîtriser les dépenses tout en maintenant des performances fiables dans OpenCode.
Comment étendre la configuration CometAPI ?
Pour ajouter un autre modèle, placez son ID sous le fournisseur dont il prend en charge le format d’API, ou ajoutez une nouvelle entrée de fournisseur avec l’adaptateur requis. Sélectionnez ensuite ce couple fournisseur/modèle via /models. Conservez les identifiants dans COMETAPI_KEY et gardez les entrées existantes pour que le changement reste une simple sélection.
Le guide officiel couvre quatre formats d’API, y compris Gemini. Cet article utilise les trois entrées nécessaires pour Claude, GPT et DeepSeek. Si plusieurs modèles sélectionnés prennent en charge Chat Completions, ils peuvent partager une même map models cometapi-chat. Ne déplacez pas une route réservée à Responses ou Messages dans cette map simplement pour réduire le nombre d’entrées.
Choisissez l’adaptateur en fonction de la route que vous comptez appeler, et le modèle en fonction de la tâche de programmation. Un changement de fournisseur ne nécessite pas une nouvelle clé CometAPI ; un changement de format d’API exige l’adaptateur correspondant.
Comment dépanner CometAPI dans OpenCode ?
Suivez la première étape qui échoue : requête HTTP → fournisseur OpenCode → outils de fichiers. Si HTTP échoue, inspectez les identifiants, l’accès au modèle et les détails d’endpoint. Si HTTP fonctionne mais qu’OpenCode échoue, inspectez la configuration et l’environnement de lancement. Si les vérifications texte fonctionnent mais que les actions sur fichiers échouent, inspectez les permissions et la compatibilité des appels d’outils.
| Symptôme | Première vérification | Action suivante | Commande / preuve de diagnostic |
|---|---|---|---|
| Réponse 401 | Valeur de clé et en-tête Authorization | Définissez la clé dans le terminal actuel ; vérifiez l’absence d’espaces involontaires. | Vérifiez la présence de la variable sans imprimer la clé ; conservez le statut HTTP et l’erreur caviardée. |
| 403 ou restriction de compte | Corps d’erreur et permissions de compte | Confirmez l’accès au modèle et l’état du compte dans CometAPI. | Enregistrez l’erreur caviardée de la réponse et confirmez l’accès au compte. |
| Réponse 404 | Hôte, chemin d’endpoint et ID de modèle | Comparez la requête avec la documentation de l’API du modèle sélectionné. | Comparez response.json avec le modèle et l’endpoint demandés. |
| Modèle absent dans OpenCode | Répertoire de projet et configuration provider | Vérifiez un JSON valide et des noms provider/modèle concordants ; redémarrez après édition. | Exécutez opencode models cometapi-chat, opencode models cometapi-messages et opencode models cometapi-responses ; enregistrez opencode --version. |
| Le texte fonctionne, pas les outils | Réponse d’appel d’outil et compatibilité d’adaptateur | Vérifiez le support de la route ; distinguez un appel d’outil rejeté d’une demande d’approbation. | Comparez la courte requête texte avec l’action d’outil échouée ; conservez l’erreur. |
| Commande en attente d’approbation | Session interactive et paramètres de permission | Examinez et approuvez l’action prévue ; ne considérez pas une demande en attente comme une panne d’API. | Utilisez la session interactive ; relevez l’action demandée et l’issue de l’approbation. |
| 429 ou erreur serveur transitoire | Détails d’erreur et limites d’usage | Réduisez la concurrence des requêtes ; suivez toute recommandation de retry au lieu de réessayer en boucle. | Conservez le statut HTTP et les recommandations de retry ; réduisez la concurrence. |
Lors du partage d’un problème, incluez la version d’OpenCode, le système d’exploitation, l’ID de modèle, le chemin d’endpoint et le texte d’erreur caviardé. Excluez les clés API et le contenu privé du dépôt. Conservez la plus petite requête qui reproduit l’échec pour que les pannes de configuration et d’outils puissent être examinées séparément.
FAQ
Pourquoi OpenCode perd-il ma clé CometAPI dans un nouveau terminal ?
Les commandes d’export et PowerShell ci-dessus définissent une variable d’environnement pour la session en cours et ses processus enfants. Un terminal ouvert séparément ou un éditeur déjà en cours d’exécution peut ne pas l’hériter. Définissez la clé dans l’environnement qui lance OpenCode et redémarrez ce processus. Pour une configuration persistante, utilisez la gestion des identifiants de votre environnement plutôt que d’intégrer le secret dans un fichier du dépôt.
OpenCode charge-t-il automatiquement COMETAPI_KEY depuis un fichier .env ?
L’expression {env:COMETAPI_KEY} lit l’environnement du processus. Créer un fichier .env ne suffit pas à garantir que la variable a été chargée. Utilisez votre shell ou un chargeur d’environnement configuré explicitement avant de démarrer OpenCode. Diagnostiquez une valeur vide au niveau du processus de lancement au lieu de supposer que le fournisseur est indisponible.
Une configuration OpenCode globale peut-elle modifier cette configuration de projet ?
OpenCode fusionne la configuration plutôt que de remplacer chaque fichier antérieur. Le fichier de projet remplace les champs qui se chevauchent dans le fichier global, tandis que les paramètres globaux non liés restent. Un fichier OPENCODE_CONFIG personnalisé est chargé entre les deux. Si le comportement diffère entre dépôts, comparez ces sources et tout paramètre géré ou en ligne au lieu de supposer que le fichier local est l’unique entrée.
Actualiser la liste des modèles active-t-il l’accès CometAPI ?
Non. L’option d’actualisation des modèles met à jour le cache models.dev ; elle n’accorde pas l’accès au compte et ne prouve pas qu’un endpoint accepte un ID de modèle. Une entrée configurée manuellement peut être visible avant toute requête réussie. Utilisez une requête réelle pour vérifier la route et consultez les paramètres de compte CometAPI pour les restrictions d’accès.
Pourquoi curl fonctionne-t-il alors qu’OpenCode ne peut pas appeler CometAPI ?
Les deux processus peuvent charger des identifiants différents, utiliser des IDs de modèles différents ou envoyer des formes de requêtes différentes. Réexécutez d’abord la courte invite texte depuis le même terminal que la requête HTTP réussie. Comparez ensuite l’URL de base du fournisseur, l’adaptateur et le modèle sélectionné. Si le texte simple fonctionne mais qu’une tâche d’agent échoue, conservez séparément l’erreur liée aux outils ; la connectivité HTTP seule ne démontre pas la compatibilité des outils.
Conclusion
Vous disposez désormais d’un opencode.json avec des exemples Claude, GPT et DeepSeek, d’un identifiant CometAPI partagé et de commandes pour basculer le modèle actif. Utilisez les courtes requêtes texte pour vérifier l’accès, puis exécutez la même tâche de création de fichiers dans des répertoires distincts pour valider le flux de codage. Conservez les résultats observés avec les détails de votre environnement avant d’appliquer cette configuration à un dépôt plus vaste.
