Pointez Continue vers un endpoint compatible OpenAI personnalisé.

Réponse rapide : un bloc de modèle avec provider openai et apiBase.

Le fournisseur openai de Continue accepte une surcharge apiBase, qui est le chemin documenté pour tout serveur compatible OpenAI. Ajoutez un bloc de modèle à config.yaml avec provider réglé sur openai, apiBase réglé sur https://api.apisrouter.com/v1, l'id exact du modèle, et votre clé. Le modèle apparaît dans le sélecteur de modèle de Continue, et chaque requête qu'il fait part vers la passerelle via /v1/chat/completions standard. Le même mécanisme couvre autant de modèles que vous voulez : un bloc par id, tous partageant la même apiBase et la même clé. Comme Continue traite le champ model comme une simple chaîne, des id de fournisseurs différents, Claude à côté de GPT à côté de DeepSeek, se retrouvent côte à côte dans un seul fichier de config.

models:
  - name: Claude Sonnet 4.6
    provider: openai
    model: claude-sonnet-4-6
    apiBase: https://api.apisrouter.com/v1
    apiKey: sk-APIsRouter-...
    roles:
      - chat
      - edit
      - apply

Comment Continue assigne le travail aux modèles : les rôles.

Continue (continuedev sur GitHub, environ 34 000 étoiles) est un agent IDE pour VS Code et JetBrains, et son idée de configuration déterminante, ce sont les rôles. Chaque bloc de modèle porte une liste roles, et Continue route chaque type de travail vers un modèle détenant ce rôle : chat pour le panneau de conversation et le travail d'agent, edit pour les transformations de code en ligne, apply pour fusionner les changements proposés dans les fichiers, plus autocomplete, embed et rerank pour leurs sous-systèmes respectifs. C'est le levier qui rend un endpoint multi-fournisseurs intéressant dans Continue spécifiquement. chat veut le modèle le plus puissant que vous puissiez justifier ; edit et apply sont des appels plus courts et plus mécaniques où un id rapide de milieu de gamme fait l'affaire. Avec une seule apiBase servant tous les fournisseurs, cette division est du pur YAML : un id Claude détenant chat, un id rapide détenant edit et apply, une seule clé pour tous. Une limite honnête : autocomplete est une charge de travail fill-in-the-middle, et le rôle autocomplete de Continue est construit autour de modèles entraînés pour ce format de complétion plutôt que pour le chat. Une passerelle chat-completions est le bon foyer pour le trafic chat, edit et apply ; gardez autocomplete sur la configuration compatible FIM que vous utilisez aujourd'hui plutôt que d'assigner ce rôle à un modèle de chat en espérant de bonnes suggestions.

Configuration complète : plusieurs modèles, rôles répartis, contexte déclaré.

Le fichier de config vit à ~/.continue/config.yaml. Le name de chaque bloc est le libellé affiché dans le sélecteur ; model est l'id exact que sert la passerelle. defaultCompletionOptions.contextLength déclare la fenêtre de contexte du modèle, et Continue l'utilise pour décider combien de contexte de conversation et de fichiers empaqueter dans une requête, donc le laisser à une valeur par défaut prudente sur un modèle à long contexte tronque plus tôt qu'il ne le devrait. Les capacités sont généralement détectées automatiquement, mais pour les id que Continue ne reconnaît pas, vous pouvez les énoncer explicitement : capabilities: [tool_use] indique au mode agent qu'il peut piloter des outils avec ce modèle. Côté clés : le YAML accepte une apiKey littérale, ce qui convient pour un fichier local qui ne quitte jamais votre machine. Continue prend aussi en charge une syntaxe de template de secrets de la forme ${{ secrets.APISROUTER_API_KEY }} pour les configs gérées via son hub, ce qui garde la valeur littérale hors des fichiers partagés. Utilisez la forme qui correspond à l'endroit où vit votre config.

models:
  - name: Claude Sonnet 4.6
    provider: openai
    model: claude-sonnet-4-6
    apiBase: https://api.apisrouter.com/v1
    apiKey: ${{ secrets.APISROUTER_API_KEY }}
    roles: [chat, edit]
    capabilities: [tool_use]
    defaultCompletionOptions:
      contextLength: 200000

  - name: Claude Haiku 4.5
    provider: openai
    model: claude-haiku-4-5-20251001
    apiBase: https://api.apisrouter.com/v1
    apiKey: ${{ secrets.APISROUTER_API_KEY }}
    roles: [edit, apply]

  - name: GPT-5.5
    provider: openai
    model: gpt-5.5
    apiBase: https://api.apisrouter.com/v1
    apiKey: ${{ secrets.APISROUTER_API_KEY }}
    roles: [chat]

Choisir des modèles par rôle.

L'assignation de rôle est aussi le mécanisme de comparaison. Gardez edit et apply fixes, échangez le bloc chat entre deux id candidats pendant une semaine chacun, et laissez la vue d'usage par clé chiffrer la différence sur votre charge de travail réelle. Chaque candidat représente trois lignes de YAML contre le même endpoint.

• chat porte la boucle de l'agent et les longues conversations : lire les fichiers, planifier les éditions, répondre à des questions sur du contexte réel. Un modèle frontier (claude-sonnet-4-6, gpt-5.5) a sa place ici, et c'est là que vont la plupart de vos tokens.
• edit gère les transformations de code surligné. Les appels sont plus courts et plus mécaniques que chat, donc un id rapide comme claude-haiku-4-5-20251001 ou gpt-5.4-mini garde la boucle d'édition serrée sans dégrader les résultats.
• apply fusionne les changements proposés dans les fichiers. C'est le rôle le plus mécanique des trois et le candidat le plus évident pour le modèle capable le moins cher, deepseek-v4-flash inclus.
• embed et rerank alimentent la recherche dans la base de code et sont des sous-systèmes séparés avec leurs propres formes de modèles ; déplacer le trafic chat vers une passerelle ne nécessite pas d'y toucher.

Paiement à l'usage · en dessous du tarif officiel

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Les modes d'échec spécifiques à Continue.

apiBase sans /v1. Continue ajoute des chemins de route comme /chat/completions à la base que vous lui donnez, donc https://api.apisrouter.com/v1 est correct et l'hôte nu ne l'est pas. Une erreur de forme 404 à la première utilisation vient presque toujours de là. L'indentation YAML remodèle silencieusement la config. models est une liste de blocs, et une apiBase mal indentée s'attache à la mauvaise entrée ou à rien du tout. Quand un modèle fonctionne et que son voisin ne peut pas s'authentifier, comparez leur indentation avant de soupçonner la passerelle. L'interrupteur des completions legacy. Le fournisseur openai utilise par défaut /chat/completions, ce que sert la passerelle. useLegacyCompletionsEndpoint: true redirige un bloc vers la route /completions historique ; si un bloc l'a activé, les requêtes de forme chat cessent de fonctionner pour ce modèle. Attentes de l'API responses sur les id de la série GPT. Certains chemins de Continue peuvent tenter le protocole responses plus récent d'OpenAI pour certains noms de modèles OpenAI. Une passerelle chat-completions ne sert pas ce protocole ; si un bloc de la série GPT échoue avec une erreur de forme route, réglez useResponsesApi: false sur ce bloc pour qu'il reste sur /chat/completions. contextLength obsolète. Continue empaquette le contexte selon defaultCompletionOptions.contextLength, pas selon ce que le modèle pourrait accepter. Déclarer 32k sur un modèle de 200k ne casse rien visiblement ; cela jette silencieusement du contexte que vous avez payé. Déclarez ce que le modèle prend réellement en charge.

Qui route Continue via une passerelle.

• Les développeurs IDE-first qui veulent Claude, GPT et DeepSeek sélectionnables dans VS Code ou JetBrains sans maintenir un jeu d'identifiants par fournisseur.
• Les équipes qui répartissent les rôles par profil de coût : chat frontier, edit et apply rapides, chaque rôle détenant l'id qui lui convient, le tout facturé sur une seule surface.
• Les ingénieurs qui comparent des modèles de chat sur du vrai travail. Chaque candidat n'est qu'un bloc YAML contre la même apiBase, pas une nouvelle intégration de fournisseur.
• Les responsables d'équipe qui standardisent l'onboarding : un seul template config.yaml plus un seul APISROUTER_API_KEY remplace une checklist de clés par fournisseur, et l'usage par clé montre ce que dépense chaque poste.
• Les développeurs sans accès à la facturation d'un fournisseur donné. Un accès basé sur la recharge, sans exigence de carte, supprime la dépendance à une inscription par fournisseur.

Vérifiez l'endpoint et déboguez la première requête.

Listez ce que sert la passerelle avant d'éditer le YAML ; les id renvoyés par /v1/models sont exactement les chaînes que vos champs model doivent correspondre. Les échecs de première requête suivent un schéma. Un 401 signifie que la clé de ce bloc spécifique est incorrecte, ou qu'une référence de secrets ne s'est pas résolue ; vérifiez le bloc qui a échoué plutôt que le fichier en général, car des clés par bloc signifient des échecs par bloc. Une erreur de modèle introuvable est une faute de frappe dans l'id, suffixe de version inclus. Une erreur de forme route sur un id de la série GPT pointe vers l'interrupteur de l'API responses couvert plus haut. Et si l'extension ne montre aucun modèle personnalisé du tout, le YAML ne s'est pas analysé ; validez d'abord la structure du fichier. Une fois que les requêtes circulent, la console APIsRouter affiche le modèle par requête, le nombre de tokens et la dépense. Comme Continue répartit le travail entre les rôles, la vue d'usage est aussi le premier endroit où vous voyez le ratio de trafic chat/edit sur votre charge de travail réelle, le chiffre qui vous indique où le choix de modèle compte réellement.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

Questions fréquentes