Documentation

Documentation

GitHub Copilot CLI

La méthode BYOK de Copilot CLI repose sur quatre variables d’environnement et, selon la documentation de GitHub, ne nécessite aucune connexion à GitHub. Dirigez-le vers Kunavo et l’agent utilise un solde prépayé au lieu des crédits IA, tandis que /delegate, le serveur MCP GitHub et GitHub Code Search restent associés à cette connexion.

Quatre variables d’environnement — COPILOT_PROVIDER_BASE_URL, COPILOT_PROVIDER_TYPE, COPILOT_PROVIDER_API_KEY et COPILOT_MODEL — font passer Copilot CLI à votre propre endpoint ; GitHub précise que le BYOK ne nécessite aucune connexion GitHub.

le shell depuis lequel vous démarrez copilot
# Set before you start Copilot CLI. Variable names and order are GitHub's;
# COPILOT_PROVIDER_BASE_URL and COPILOT_MODEL are the two marked Required.
export COPILOT_PROVIDER_BASE_URL=https://api.kunavo.com/v1   # see the note below
export COPILOT_PROVIDER_TYPE=openai                          # the default, shown for clarity
export COPILOT_PROVIDER_API_KEY=sk-kn-...
export COPILOT_MODEL=claude-sonnet-5

copilot
GitHub ne précise pas quel chemin Copilot CLI ajoute ; le /v1 ci-dessus est donc un exemple concret, et non une règle. La page BYOK définit le champ uniquement comme « l’URL de base du point de terminaison API de votre fournisseur de modèles », et ses propres exemples vont dans les deux sens : l’exemple distant compatible avec OpenAI utilise https://api.openai.com/v1, tandis que ceux d’Ollama et d’Anthropic utilisent des origines sans suffixe. Cette page utilise la forme distante compatible avec OpenAI, car c’est le cas de Kunavo. Si les requêtes renvoient 404, le suffixe est doublé : supprimez-le et utilisez https://api.kunavo.com. Une erreur 401 indique un problème de clé, et non d’URL ; le test curl ci-dessous permet de distinguer les deux avant de déboguer le CLI.
Un fichier ~/.copilot/providers.json résiduel prend silencieusement le dessus sur ces variables exportées. La référence de GitHub sur le répertoire de configuration indique que si ce fichier déclare un fournisseur ou un modèle, il prévaut sur les variables COPILOT_PROVIDER_*, qualifiées d’anciennes. Le guide pratique BYOK ne mentionne jamais ce fichier. Si le CLI ignore l’URL de base que vous venez d’exporter, vérifiez-le d’abord. La même référence décrit uniquement le fichier comme un objet JSON comportant les clés providers et models, sans publier de schéma ; aucun exemple n’est donc fourni ici. GitHub renvoie vers copilot help providers pour en savoir plus.
Cette configuration a été relevée dans la documentation de GitHub à la date indiquée ci-dessous. Kunavo n’a pas exécuté Copilot CLI avec son point de terminaison : ni session, ni tour diffusé en continu, ni aller-retour avec un outil. Il en va de même pour tous les autres clients de cette famille. Une page de configuration publiée ne constitue pas un test. GitHub exige que les modèles BYOK prennent en charge l’appel d’outils et le streaming, faute de quoi une erreur est renvoyée. La première tâche que vous lui confiez devrait donc modifier un fichier plutôt que se limiter à un bonjour.
Kunavo ne propose aucun modèle d’intégration, de synthèse vocale ou de transcription vocale ; ce point de terminaison répond donc uniquement aux échanges de chat. GitHub Code Search, le serveur MCP GitHub et /delegate sont des fonctionnalités côté GitHub qu’un fournisseur BYOK ne remplace pas. GitHub indique qu’elles ne sont pas disponibles sans connexion ; vous pouvez les conserver en vous connectant tout en configurant un fournisseur.
Pas encore de clé ? Créez un compte Kunavo, créez une clé (elle commence par sk-kn-) et ajoutez un crédit à partir de 10 $ — les appels sont payés sur ce solde et les appels échoués ne sont pas facturés. Le tableau de bord s’ouvre ensuite sur la configuration GitHub Copilot CLI.

Étape par étape

  1. Créez une clé sur /app/keys et copiez-la — elle n’est affichée qu’une seule fois.
  2. Vérifiez la présence d’un ancien ~/.copilot/providers.json (ou du fichier indiqué par COPILOT_PROVIDERS_CONFIG). S’il déclare un fournisseur ou un modèle, il l’emporte sur tout ce qui figure à l’étape 3.
  3. Exportez COPILOT_PROVIDER_BASE_URL, COPILOT_PROVIDER_API_KEY et COPILOT_MODEL comme ci-dessus. COPILOT_PROVIDER_TYPE prend par défaut la valeur openai, que GitHub décrit comme couvrant « tout autre point de terminaison compatible avec l’API OpenAI Chat Completions ».
  4. Lancez copilot depuis ce même shell : les valeurs sont lues au démarrage, donc un terminal ouvert auparavant conserve les anciennes.
  5. Confiez-lui une tâche qui lit et modifie un fichier. Copilot CLI a besoin que le modèle prenne en charge l’appel d’outils et le streaming ; une première exécution qui utilise les deux vous en apprendra plus qu’une simple salutation. --model remplace COPILOT_MODEL pour une exécution si vous souhaitez comparer deux identifiants.

Vérifié avec La documentation de GitHub « Using your own LLM models in GitHub Copilot CLI » le 21 septembre 2026. Les paramètres tiers évoluent ; si le nom d’un champ ne correspond plus à ce que vous voyez ici, cette page fait autorité, pas celle-ci.

Voici la version courte. Le guide complet — choix du modèle, coût d’une session réelle et modes d’échec — se trouve dans Copilot CLI et Claude Code — la limite de BYOK et les deux factures.

Vérifiez avant de déboguer le client

Une requête suffit à déterminer si l’échec vient de l’endpoint, de la clé ou du fichier de configuration. Si cette requête renvoie du JSON, la même URL de base et la même clé fonctionnent dans GitHub Copilot CLI.

# Settles whether a failure is the endpoint, the key, or the client.
curl -sS https://api.kunavo.com/v1/models \
  -H "Authorization: Bearer sk-kn-..."

Quel identifiant de modèle saisir dans le champ

Tous les modèles textuels sont accessibles sous forme d’identifiant de modèle — la liste à jour se trouve sur GET /v1/models, et le catalogue avec les prix sur la page des modèles. Les tarifs sont en USD par million de tokens, entrée / sortie.

Identifiant du modèleEntrée / sortie sur KunavoOù cela s’intègre dans GitHub Copilot CLI
claude-sonnet-5$1.40 / $7.00le modèle de travail par défaut pour les sessions qui modifient des fichiers
claude-opus-5$3.50 / $17.50planifier une modification dont une erreur coûterait cher
claude-haiku-4-5$0.70 / $3.50requêtes économiques — triage, résumés, boucle qui tourne toute la journée
gpt-5-6-sol$2.00 / $12.00un second avis d’une autre famille, avec la même clé et la même URL de base
La facturation se fait au token à partir d’un solde prépayé, sans frais mensuels — consultez la facturation. Avec un contexte répété — ce qu’envoient la plupart des éditeurs et clients de chat — la mise en cache des prompts influe davantage sur la facture que le choix du modèle.

L’autre option : COPILOT_PROVIDER_TYPE=anthropic

GitHub documente trois types de fournisseurs, et Kunavo prend en charge deux des formats filaires correspondants : /v1/chat/completions pour openai et /v1/messages pour anthropic. L’exemple Anthropic de la page de GitHub utilise quatre variables exportées et une URL de base correspondant à l’origine seule, https://api.anthropic.com :

  1. COPILOT_PROVIDER_TYPE=anthropic
  2. COPILOT_PROVIDER_BASE_URL — d’après la forme de l’exemple de GitHub, https://api.kunavo.com sans suffixe, puisque la route propre à Anthropic se trouve sous cette origine, à /v1/messages, et que Kunavo la reproduit. La même réserve que précédemment s’applique : GitHub donne un exemple, pas une règle.
  3. COPILOT_PROVIDER_API_KEY — votre clé sk-kn-. La surface Messages de Kunavo l’accepte sous la forme x-api-key ou Authorization: Bearer ; l’en-tête choisi ici par le CLI sera donc reconnu.
  4. COPILOT_MODEL — l’identifiant attendu par votre fournisseur. L’exemple de GitHub utilise une graphie Anthropic avec des tirets, tandis que sa propre liste des modèles pris en charge écrit les mêmes familles avec des points. Avec BYOK, l’identifiant est transmis à votre point de terminaison : utilisez donc la graphie indiquée dans le tableau ci-dessus.

Pourquoi cette page privilégie-t-elle malgré tout le type openai ? La documentation de GitHub ne précise pas si le chemin BYOK Anthropic transmet cache_control, anthropic-beta ou un anthropic-version particulier. Cela influe sur la facture lorsque le contexte se répète — voir la mise en cache des invites — et cette page ne veut pas faire d’hypothèse sur un point non documenté. Le type openai ne soulève pas cette question ; c’est donc celui pour lequel un bloc de configuration complet est fourni.

Questions fréquentes

Comment diriger GitHub Copilot CLI vers un point de terminaison API personnalisé ?

Définissez les variables d’environnement avant de lancer le CLI. La page BYOK de GitHub en indique deux comme obligatoires : COPILOT_PROVIDER_BASE_URL et COPILOT_MODEL. Elle ajoute COPILOT_PROVIDER_API_KEY pour tout point de terminaison nécessitant une authentification. COPILOT_PROVIDER_TYPE prend par défaut la valeur openai, qui, selon GitHub, couvre OpenAI, Ollama, vLLM, Foundry Local et tout autre point de terminaison compatible avec l’API OpenAI Chat Completions ; les autres valeurs sont azure et anthropic. GitHub signale un piège dans une autre page : si ~/.copilot/providers.json déclare un fournisseur ou un modèle, il prévaut sur toutes ces variables.

L’URL de base de Copilot CLI doit-elle se terminer par /v1 ?

La documentation de GitHub ne tranche pas la question. Le champ est défini uniquement comme « l’URL de base du point de terminaison API de votre fournisseur de modèles », et les exemples de la page vont dans les deux sens : l’exemple distant compatible avec OpenAI est https://api.openai.com/v1, tandis que ceux d’Ollama et d’Anthropic utilisent des origines seules. Pour un point de terminaison compatible avec OpenAI, commencez par la forme montrée par GitHub pour ce cas — https://api.kunavo.com/v1 — et si les requêtes échouent avec une erreur 404 plutôt qu’une erreur 401, c’est que le suffixe est doublé : supprimez-le. Une erreur 404 indique un problème d’URL ; une erreur 401, un problème de clé. Un simple appel curl vers la même URL de base permet de distinguer les deux avant de déboguer le CLI.

BYOK dans GitHub Copilot CLI nécessite-t-il un compte GitHub ?

Non. La documentation d’authentification de GitHub indique que lorsque Copilot CLI est configuré avec votre propre clé API de fournisseur de LLM, l’authentification GitHub n’est pas requise et le CLI se connecte directement au fournisseur configuré. Trois fonctionnalités ne sont alors pas disponibles : /delegate, le serveur MCP GitHub et GitHub Code Search. Vous pouvez également vous connecter et configurer un fournisseur simultanément pour conserver les deux. GitHub documente aussi COPILOT_OFFLINE=true pour les environnements où le CLI ne doit pas contacter du tout les serveurs GitHub. Cela n’isole le réseau que si le fournisseur est local, car une URL de base distante reçoit toujours vos invites et le contexte de votre code.

Kunavo a-t-il testé GitHub Copilot CLI avec son point de terminaison ?

Non. La configuration de cette page est tirée de la documentation BYOK de GitHub à la date indiquée ; aucun élément n’est le résultat d’une exécution : ni session, ni tour diffusé en continu, ni aller-retour avec un outil. Il en va de même pour tous les autres clients présentés ici. GitHub exige que les modèles BYOK prennent en charge l’appel d’outils et le streaming et renvoie une erreur dans le cas contraire. Le premier contrôle honnête vous revient donc : exécutez une tâche qui lit et modifie un fichier, et prenez la facturation enregistrée ainsi que le comportement du CLI comme preuves, plutôt que cette page.