Fournisseurs OpenCode : 7 contrôles pour modèles, clés et configuration

La recherche fournisseurs OpenCode peut viser le choix d’un service, l’ajout d’un fournisseur tiers, la compatibilité OpenAI ou un modèle absent. Une simple liste de marques vieillit vite avec les prix, les IDs et l’authentification. Un ordre de décision indépendant d’un vendeur reste plus utile.

La documentation officielle OpenCode rassemble Credentials, Config, OpenCode Zen, OpenCode Go et un annuaire. Cette page ajoute la méthode: identifier le niveau, choisir la connexion minimale, confirmer l’ID du modèle, puis conserver la preuve avant les tâches qui écrivent des fichiers ou des services externes.

Le fournisseur est la route vers un service de modèles. Le modèle est la capacité précise exposée par ce service et les identifiants prouvent que la requête est autorisée. Les confondre produit des symptômes trompeurs: une clé valide ne corrige pas un mauvais ID et un modèle visible ne prouve pas que l’accès est encore valide.

Le périmètre de configuration est un quatrième sujet. Un fournisseur peut fonctionner dans le fichier du projet mais pas dans le fichier global; un réglage géré peut aussi remplacer votre modification. Notez le fichier, le périmètre, le nom du fournisseur, l’ID du modèle et la date de vérification au lieu de partager tout le fichier.

Quatre voies sont fréquentes. OpenCode Go et OpenCode Zen sont des services de première partie avec leurs propres forfaits. Un fournisseur tiers hébergé convient si l’équipe possède déjà la facturation, les contrôles régionaux ou un catalogue. Un endpoint compatible OpenAI ou local est flexible, mais vous assumez davantage l’URL, la découverte, le runtime et le diagnostic.

Ne choisissez pas d’après le nom d’un annuaire. Décidez d’abord si la contrainte est le coût mensuel, le paiement à l’usage, la localisation des données, le mode hors ligne, la qualité, la latence ou un service déjà exploité. Un fournisseur peu cher reste un mauvais choix si sa liste de modèles est instable ou si l’environnement ne peut pas vérifier l’endpoint.

La structure officielle place les fournisseurs personnalisés sous provider. L’adaptateur npm, les options, la variable d’authentification et la carte des modèles dépendent du service. Lisez la documentation du propriétaire, ne copiez que les champs compris et notez la raison du choix de l’endpoint et de l’adaptateur.

Gardez le secret hors du dépôt: OAuth, variable d’environnement ou coffre de la plateforme. Ne collez pas une clé active dans opencode.json, une capture, l’historique du shell ou une session partagée. Si elle apparaît dans un log, faites-la tourner avant de poursuivre.

Ajoutez un seul fournisseur à la fois. Une modification minimale sépare schema, panne de service et rollback; retirez le bloc, restaurez le modèle connu et refaites le test.

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "my-provider": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "provider-demo",
      "options": { "baseURL": "https://api.provider.test/v1" },
      "models": { "model-id": { "name": "Model name" } }
    }
  }
}

Une entrée n’est terminée que lorsqu’OpenCode découvre un modèle réel et réussit une petite requête. Vérifiez l’ID et l’authentification dans la documentation actuelle, puis utilisez /models. S’il existe plusieurs variantes, commencez par celle qui correspond au contexte, aux outils, à la latence et au coût du travail.

La première requête doit être lisible et comparable: expliquer un petit fichier local ou proposer la prochaine commande sans l’exécuter. Notez la complétude, les outils, le délai et le modèle utilisé. Testez les écritures seulement après cette preuve.

1. Vérifier le périmètreConfirmez global, projet, chemin personnalisé ou gestion centralisée.
2. Protéger la cléUtilisez OAuth, une variable d’environnement ou le coffre du fournisseur.
3. Confirmer le fournisseurVérifiez ID, adaptateur, endpoint et source officielle.
4. Confirmer le modèleUtilisez l’ID exact, pas seulement le nom affiché.
5. Lister les modèlesOuvrez le sélecteur ou suivez le flux `/models`.
6. Tester en lectureUtilisez un petit prompt et comparez avec une attente connue.
7. Noter le retour arrièreConservez la configuration, le résultat et la petite réversion.

Les erreurs sont plus simples quand l’authentification, la découverte, le modèle et le transport restent séparés. Un 401 ou une boucle OAuth indique les identifiants ou les scopes. Un fournisseur absent indique le périmètre, le schema ou le chargement. Un modèle absent indique le catalogue ou l’ID. Un délai d’attente après découverte indique réseau, proxy, région ou santé du service.

Modifiez une seule variable par test. Vérifiez l’endpoint selon la source officielle, puis le fichier lu par OpenCode, la liste de modèles et enfin le prompt. Ajouter des fournisseurs pour en diagnostiquer un seul rend le catalogue et les logs moins lisibles.

OpenCode Go convient à un abonnement et une allocation prévisibles; Zen à un catalogue sélectionné et au paiement à l’usage. Un tiers hébergé est pertinent pour la facturation, la conformité, la région ou un modèle précis. Un endpoint local ou compatible OpenAI convient si vous acceptez de maintenir le runtime et le service. Ce sont des choix d’adéquation, pas un classement permanent.

Le fournisseur modifie aussi les hypothèses de confidentialité. Le CLI peut être local alors que les requêtes partent vers le service choisi. Lisez la politique, n’envoyez ni secrets ni données client inutiles et testez dans un dépôt non productif. Les guides Models, JSONC, Ollama et Go vs Zen couvrent les sujets voisins; cette page les relie sans les recopier.

Pour fournisseurs OpenCode, la bonne sortie est une connexion reproductible, pas une liste figée de gagnants. Annuaire, modèles, prix, quotas et login changent: vérifiez la source officielle le jour du réglage et notez la date.