Skip to main content

Apportez votre propre clé (BYOK)

Utilisez SDK Copilot avec vos propres clés API provenant de différents fournisseurs de modèles, en contournant l’authentification GitHub Copilot.

Qui peut utiliser cette fonctionnalité ?

Kit de développement logiciel (SDK) GitHub Copilot est disponible dans tous les forfaits Copilot.

Remarque

SDK Copilot est actuellement en préversion publique. Les fonctionnalités et la disponibilité sont susceptibles de changer.

Le principe Bring Your Own Key (BYOK) vous permet d’utiliserSDK Copilotavec vos propres clés API provenant de fournisseurs de modèles, contournant ainsi l’authentificationGitHub Copilot. Cela est utile pour les déploiements d’entreprise, l’hébergement de modèles personnalisés ou lorsque vous souhaitez une facturation directe avec votre fournisseur de modèles.

Fournisseurs pris en charge

FournisseurValeur du typeRemarques
OpenAI"openai"API OpenAI et points de terminaison compatibles OpenAI
Azure OpenAI / Azure AI Foundry
          `"azure"` ou `"openai"` | Modèles hébergés par Azure (voir [types de points de terminaison Azure](#azure-endpoint-type-confusion)) |

| Anthropic | "anthropic" | Modèles Claude | | Ollama | "openai" | Modèles locaux via l’API compatible OpenAI | | Microsoft Foundry Local | "openai" | Exécuter des modèles IA localement sur votre appareil via l’API compatible OpenAI | | Autres compatibles avec OpenAI | "openai" | vLLM, LiteLLM et similaires |

Démarrage rapide : Azure AI Foundry

Azure AI Foundry (anciennement Azure OpenAI) est une cible de déploiement BYOK commune pour les entreprises. L’exemple suivant montre une configuration complète Node.js/TypeScript :

  1. Créez une session avec votre point de terminaison Azure AI Foundry et votre clé API :

    TypeScript
    import { CopilotClient } from "@github/copilot-sdk";
    
    const client = new CopilotClient();
    const session = await client.createSession({
        model: "YOUR-DEPLOYMENT-NAME",
        provider: {
            type: "openai",
            baseUrl: "https://YOUR-RESOURCE.openai.azure.com/openai/v1/",
            wireApi: "responses",  // Use "completions" for older models
            apiKey: process.env.FOUNDRY_API_KEY,
        },
    });
    
    session.on("assistant.message", (event) => {
        console.log(event.data.content);
    });
    
    await session.sendAndWait({ prompt: "What is 2+2?" });
    await client.stop();
    

Remplacez YOUR-RESOURCE par votre nom de ressource Azure et YOUR-DEPLOYMENT-NAME par votre nom de déploiement de modèle. Définissez la variable d’environnement FOUNDRY_API_KEY sur votre clé API Azure.

Pour obtenir des exemples dans Python, Go et .NET, consultez BYOK dans le github/copilot-sdk référentiel. Pour Java, consultez le github/copilot-sdk-java référentiel.

Informations de référence sur la configuration du fournisseur

Les champs "ProviderConfig"

ChampTypeDescription
type
          `"openai"`
          \|
          `"azure"`
          \|
          `"anthropic"`
         | Type de fournisseur. La valeur par défaut est `"openai"`. |

| baseUrl | ficelle | Obligatoire. URL du point de terminaison d’API. | | apiKey | ficelle | Clé API. Facultatif pour les fournisseurs locaux comme Ollama. | | bearerToken | ficelle | Authentification par jeton Bearer. Prend la priorité sur apiKey. | | wireApi | "completions" | "responses" | Format d’API. La valeur par défaut est "completions". | | azure.apiVersion | ficelle | Version de l’API Azure. La valeur par défaut est "2024-10-21". |

Format de l’API Wire

Le wireApi paramètre détermine le format d’API OpenAI à utiliser :


          `"completions"`
          ** (par défaut) : API de complétion de conversation (`/chat/completions`). À utiliser pour la plupart des modèles.

          `"responses"`
          **: API Réponses. À utiliser pour les modèles de série GPT-5 qui prennent en charge le format de réponses plus récent.

Notes spécifiques au type

          **OpenAI (`type: "openai"`)**
  • Fonctionne avec l’API OpenAI et tout point de terminaison compatible OpenAI.

  • baseUrl doit inclure le chemin d’accès complet, par exemple https://api.openai.com/v1.

            **Azure (`type: "azure"`)**
    
  • Utilisez pour les points de terminaison natifs d'Azure OpenAI.

  • baseUrl doit être juste l’hôte, par exemple https://YOUR-RESOURCE.openai.azure.com.

  • N’incluez /openai/v1 pas dans l’URL : le SDK gère la construction du chemin d’accès.

            **Anthropic (`type: "anthropic"`)**
    
  • Pour l’accès direct à l’API Anthropic.

  • Utilise le format d’API spécifique à Claude.

Exemples de configurations

OpenAI direct

TypeScript
provider: {
    type: "openai",
    baseUrl: "https://api.openai.com/v1",
    apiKey: process.env.OPENAI_API_KEY,
}

Azure OpenAI (point de terminaison Azure natif)

Utiliser type: "azure" pour les points de terminaison à l’adresse *.openai.azure.com:

TypeScript
provider: {
    type: "azure",
    baseUrl: "https://YOUR-RESOURCE.openai.azure.com",  // Just the host
    apiKey: process.env.AZURE_OPENAI_KEY,
    azure: {
        apiVersion: "2024-10-21",
    },
}

Remplacez par YOUR-RESOURCE le nom de votre ressource Azure.

Azure AI Foundry (point de terminaison compatible OpenAI)

Pour les déploiements Azure AI Foundry avec des points de terminaison /openai/v1/ utilisez type: "openai" :

TypeScript
provider: {
    type: "openai",
    baseUrl: "https://YOUR-RESOURCE.openai.azure.com/openai/v1/",
    apiKey: process.env.FOUNDRY_API_KEY,
    wireApi: "responses",  // For GPT-5 series models
}

Ollama (local)

TypeScript
provider: {
    type: "openai",
    baseUrl: "http://localhost:11434/v1",
    // No apiKey needed for local Ollama
}

Microsoft Foundry Local

          [Microsoft Foundry Local](https://foundrylocal.ai) vous permet d’exécuter des modèles IA localement avec une API compatible OpenAI. Installez-le via l’interface CLI locale Foundry, puis pointez le SDK sur votre point de terminaison local :
TypeScript
provider: {
    type: "openai",
    baseUrl: "http://localhost:YOUR-PORT/v1",
    // No apiKey needed for local Foundry Local
}

Remarque

Foundry Local démarre sur un port dynamique qui n’est pas fixe. Exécutez foundry service status pour confirmer le port sur lequel le service écoute actuellement, puis utilisez ce port dans votre baseUrl.

Pour bien démarrer avec Foundry Local :

Bash
# Windows: Install Foundry Local CLI (requires winget)
winget install Microsoft.FoundryLocal

# List available models
foundry model list

# Run a model (starts the local server automatically)
foundry model run phi-4-mini

# Check the port the service is running on
foundry service status

Pour l’installation de macOS/Linux, consultez foundrylocal.ai.

Anthropic

TypeScript
provider: {
    type: "anthropic",
    baseUrl: "https://api.anthropic.com",
    apiKey: process.env.ANTHROPIC_API_KEY,
}

Authentification par jeton porteur

Certains fournisseurs nécessitent l’authentification par jeton du porteur au lieu de clés API :

TypeScript
provider: {
    type: "openai",
    baseUrl: "https://YOUR-CUSTOM-ENDPOINT.example.com/v1",
    bearerToken: process.env.MY_BEARER_TOKEN,  // Sets Authorization header
}

Remarque

L’option bearerToken accepte uniquement une chaîne de jeton statique. Le Kit de développement logiciel (SDK) n’actualise pas automatiquement ce jeton. Si votre jeton expire, les demandes échouent et vous devez créer une session avec un nouveau jeton.

Liste de modèles personnalisées

Lorsque vous utilisez BYOK, le serveur CLI peut ne pas connaître les modèles pris en charge par votre fournisseur. Vous pouvez fournir un gestionnaire personnalisé onListModels au niveau du client afin de renvoyer client.listModels() les modèles de votre fournisseur au format standard ModelInfo :

TypeScript
import { CopilotClient } from "@github/copilot-sdk";
import type { ModelInfo } from "@github/copilot-sdk";

const client = new CopilotClient({
    onListModels: () => [
        {
            id: "my-custom-model",
            name: "My Custom Model",
            capabilities: {
                supports: { vision: false, reasoningEffort: false },
                limits: { max_context_window_tokens: 128000 },
            },
        },
    ],
});

Les résultats sont mis en cache après le premier appel. Le gestionnaire remplace complètement le RPC de l’interface en ligne de commande (CLI), sans recours au serveur.

Pour obtenir des exemples dans Python, Go et .NET, consultez BYOK dans le github/copilot-sdk référentiel. Pour Java, consultez le github/copilot-sdk-java référentiel.

Limites

Limitations de l’identité

L’authentification BYOK utilise uniquement les informations d’identification statiques. Les fournisseurs d’identité suivants ne sont pas pris en charge :

  • Microsoft Entra ID (Azure AD) — pas de support pour les identités gérées Entra ou les principals de service.
  • Fournisseurs d’identité tiers : aucune identité OIDC, SAML ou autre identité fédérée.
  • Identités managées : l’identité managée Azure n’est pas prise en charge.

Vous devez utiliser une clé API ou un jeton de porteur statique que vous gérez vous-même.

Remarque

Alors que l’ID Entra émet des jetons porteurs, ces jetons sont de courte durée (généralement une heure) et nécessitent une actualisation automatique via le Kit de développement logiciel (SDK) Azure Identity. L’option bearerToken accepte uniquement une chaîne statique : il n’existe aucun mécanisme de rappel pour que le KIT de développement logiciel (SDK) demande de nouveaux jetons. Pour les charges de travail longues nécessitant l’authentification Entra, vous devez implémenter votre propre logique d’actualisation de jeton et créer de nouvelles sessions avec des jetons mis à jour.

Limitations des fonctionnalités

Certaines Copilot fonctionnalités peuvent se comporter différemment avec BYOK :

  • Disponibilité des modèles : seuls les modèles pris en charge par votre fournisseur sont disponibles.
  • Limitation du débit : soumis aux limites de débit de votre fournisseur, et non Copilotà celles de votre fournisseur.
  • Suivi de l’utilisation : l’utilisation est suivie par votre fournisseur, et non GitHub.
  • Demandes Premium : ne comptez pas sur les Copilot quotas de demandes Premium.

Limitations spécifiques au fournisseur

FournisseurLimites
Azure AI FoundryPas d’authentification Entra ID ; utilisation des clés API obligatoire.
OllamaAucune clé API ; local uniquement ; la prise en charge du modèle varie.
Microsoft Foundry LocalLocal uniquement ; la disponibilité du modèle dépend du matériel de l’appareil ; aucune clé API requise.
OpenAISoumis aux limitations de débit et quotas OpenAI.

Résolution des problèmes

Erreur « Modèle non spécifié »

Lorsque vous utilisez BYOK, le model paramètre est requis :

// Error: model required with custom provider
const session = await client.createSession({
    provider: { type: "openai", baseUrl: "..." },
});

// Correct: model specified
const session = await client.createSession({
    model: "gpt-4",
    provider: { type: "openai", baseUrl: "..." },
});

Confusion du type de point de terminaison Azure

Pour les points de terminaison Azure OpenAI (*.openai.azure.com), veillez à utiliser le type de fournisseur approprié :

// Wrong: using "openai" type with native Azure endpoint
provider: {
    type: "openai",
    baseUrl: "https://YOUR-RESOURCE.openai.azure.com",
}

// Correct: using "azure" type
provider: {
    type: "azure",
    baseUrl: "https://YOUR-RESOURCE.openai.azure.com",
}

Si votre déploiement Azure AI Foundry fournit un chemin de point de terminaison compatible OpenAI (par exemple, /openai/v1/), utilisez type: "openai" à la place :

// Correct: OpenAI-compatible Azure AI Foundry endpoint
provider: {
    type: "openai",
    baseUrl: "https://YOUR-RESOURCE.openai.azure.com/openai/v1/",
}

Connexion refusée (Ollama)

Vérifiez que Ollama est en cours d’exécution et accessible :

Bash
# Check Ollama is running
curl http://localhost:11434/v1/models

# Start Ollama if not running
ollama serve

Connexion refusée (Foundry Local)

Foundry Local utilise un port dynamique qui peut changer entre les redémarrages. Confirmez le port actif :

Bash
foundry service status

Mettez à jour votre baseUrl pour qu’il corresponde au port affiché dans le résultat. Si le service n’est pas en cours d’exécution, démarrez un modèle pour le lancer :

Bash
foundry model run phi-4-mini

Échec de l’authentification

  1. Vérifiez que votre clé API est correcte et non expirée.
  2. Vérifiez que le baseUrl correspond au format attendu par votre fournisseur.
  3. Pour les jetons porteurs, assurez-vous que le jeton complet est fourni, pas seulement un préfixe.