Continue est un assistant de programmation IA open source disponible en extension VS Code, plugin JetBrains et CLI ; il peut se connecter à une API auto-hébergée ou tierce via le protocole compatible OpenAI. Après configuration d'une passerelle, une erreur dès la première requête est fréquente : les causes se concentrent sur cinq couches — identifiants, adresse, identifiant de modèle, quota et réseau. Le bon ordre consiste à regarder le code de statut, reproduire avec une requête minimale, puis seulement toucher au modèle et au contexte. Cet article fournit une base config.yaml à copier et une liste de diagnostic.

État du projet : en 2026, Continue a été racheté par Cursor ; le dépôt officiel est passé en lecture seule et n'est plus activement maintenu. Les installations existantes et les branches communautaires restent utilisables, mais le comportement des versions peut s'être figé avant le rachat. Cet article s'appuie sur la méthode de configuration config.yaml encore courante en octobre 2026 ; la démarche de diagnostic vaut aussi pour les anciennes versions.

1. Situer la couche de l'erreur

Ne changez pas de modèle dès qu'une erreur apparaît : classez d'abord par code de statut.

Statut / symptôme Signification fréquente À vérifier d'abord Réessayer ?
401 Clé absente, erronée, expirée ou sans droit Clé, champs d'authentification, état du compte Non
403 Clé sans droit sur ce modèle ou bloquée par une politique Droits du modèle, réglages d'équipe Non
404 Chemin erroné ou modèle inexistant apiBase, identifiant de modèle Non
400/413 Format de requête erroné ou contexte trop long Contexte, paramètres, max_tokens Après correction
429 Fréquence, concurrence ou quota de tokens dépassé Usage, clé partagée, stratégie de retry Oui, avec backoff
5xx Erreur serveur ou passerelle surchargée État du service, identifiant de requête Oui, avec backoff
Délai / connexion échouée DNS, TLS, proxy, pare-feu ou flux Réseau et proxy Après correction

Pendant le diagnostic, gardez la même clé, la même adresse et le même identifiant de modèle, et ne changez qu'un élément à la fois ; si vous modifiez trois choses et que cela remarche, vous ne saurez pas pourquoi.

2. Base de configuration : trois éléments à changer dans config.yaml

Le répertoire de configuration global de Continue est ~/.continue (macOS/Linux) ou %USERPROFILE%\.continue (Windows). Si config.yaml existe, il est chargé en priorité sur l'ancien config.json ; les deux formats ne se mélangent pas. Voici une configuration compatible OpenAI fonctionnelle :

name: zsqh-gateway
version: 0.0.1
schema: v1

models:
  - name: modèle de chat d'équipe
    provider: openai
    model: <identifiant copié depuis la liste des modèles>
    apiBase: https://api.zhongshangqihang.com/v1
    apiKey: <votre clé API>
    roles:
      - chat
      - edit
      - apply
    capabilities:
      - tool_use

Quelques points sources d'erreur :

  • Les champs de premier niveau name, version et schema: v1 sont obligatoires ; models est une liste, une indentation incorrecte provoque un échec de parsing.
  • Pour une passerelle compatible, choisissez provider: openai ; apiBase s'arrête généralement à /v1, sans ajouter /chat/completions.
  • model doit correspondre exactement à l'identifiant de la liste de la passerelle, casse, tirets et numéro de version compris.
  • roles détermine si le modèle sert au chat, à l'édition ou à l'application de patches ; la complétion (autocomplete) exige des capacités d'interface différentes, et un modèle de chat standard ne la prend pas forcément en charge.
  • Pour appeler des outils en mode Agent, ajoutez capabilities: [tool_use] ; sinon, le chat peut fonctionner mais les outils échouer. Si la configuration ne prend pas effet après sauvegarde, rechargez la fenêtre de l'IDE et consultez les journaux.

3. 401 : vérifier la clé, puis les champs d'authentification

Un 401 signifie que l'identité n'est pas validée ; cela n'a rien à voir avec les capacités du modèle ou le contexte. Procédez dans l'ordre :

  1. La clé est-elle copiée en entier, sans espace, retour à la ligne ou guillemet autour ? Copier depuis une fenêtre de chat introduit facilement des caractères invisibles.
  2. La clé est-elle dans le champ apiKey, en cohérence avec l'en-tête d'authentification de requestOptions.headers, sans doublon ni conflit ?
  3. La clé a-t-elle été supprimée, désactivée ou expirée ? Le compte a-t-il un solde disponible ? Certaines passerelles renvoient 401 ou 403 en cas de solde insuffisant ; le corps de la réponse fait foi.
  4. apiBase pointe-t-il vers l'environnement auquel appartient la clé ? Une clé de test sur une adresse de production produit généralement un 401.
  5. Le fichier de configuration est-il réellement chargé ? Si vous modifiez config.json alors que c'est config.yaml qui est chargé, « rien ne change » quoi que vous fassiez.

Validez d'abord l'adresse et la clé avec une requête minimale, pour écarter le client Continue :

export API_KEY="sk-votre-clé"

curl -sS -o /tmp/continue_resp.json -w "%{http_code}\n" \
  "https://api.zhongshangqihang.com/v1/chat/completions" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"<ID du modèle>","messages":[{"role":"user","content":"ping"}],"max_tokens":16}'

cat /tmp/continue_resp.json

Un 200 indique que la clé, l'adresse et le modèle sont globalement utilisables ; un 401 impose de réessayer via l'entrée de test de la console de la passerelle, sans retry automatique.

4. 404 : Base URL et identifiant de modèle à parts égales

Un 404 ne signifie pas forcément que le modèle est retiré ; le plus fréquent est un chemin mal composé :

  • apiBase sans /v1 : la requête atteint une route web du site et renvoie du HTML ou un 404.
  • apiBase avec /v1/chat/completions : le client ajoute une nouvelle fois le chemin, qui devient dupliqué.
  • Adresse de console prise pour l'adresse API, domaine mal orthographié, ou chemin /v1/messages d'Anthropic saisi dans un champ compatible OpenAI.

L'identifiant de modèle peut aussi produire un 404 ou model_not_found :

  • La casse, les tirets et le numéro de version doivent correspondre exactement à la liste des modèles.
  • Le modèle peut ne pas être ouvert au compte ou à l'offre actuelle, ou porter un identifiant différent selon le protocole.
  • Le fait que l'interface de configuration accepte la valeur ne prouve pas que la passerelle reconnaît l'identifiant : envoyez une vraie requête pour confirmer.

Pendant le diagnostic, appelez d'abord /v1/models (si la passerelle l'expose) et copiez l'identifiant depuis la liste renvoyée, sans le saisir à la main.

5. 429 : une limitation n'est pas un solde insuffisant

Un 429 signifie que la requête dépasse une limite de fréquence, de concurrence ou de quota de tokens. Scénarios courants :

  • nombre de requêtes par minute, tokens par minute ou connexions simultanées dépassé ;
  • plusieurs personnes partagent une clé, ou l'agent lit des fichiers et exécute des commandes en continu, générant un afflux de requêtes ;
  • la complétion se déclenche trop souvent, une requête à chaque quelques caractères ;
  • les retries sans backoff échouent de plus en plus et forment une tempête ; les requêtes à contexte long occupent aussi de la concurrence.

Regardez d'abord les en-têtes et le corps d'erreur, sans doubler aveuglément les retries. Si Retry-After existe, attendez la durée indiquée ; sinon, appliquez un backoff exponentiel avec gigue. Ne réessayez pas 401, 403 et 404. Si une clé sert à plusieurs services, séparez les clés par projet ; pour une boucle d'agent, fixez un nombre maximal de tours et un plafond de quota.

6. Délais, flux interrompus et proxy

Un délai ne renvoie généralement pas de statut HTTP : il se manifeste par une requête sans réponse, fetch failed, ECONNRESET ou une réponse qui s'arrête à mi-chemin. Ordre de diagnostic :

  1. Envoyez d'abord une requête non streaming à contexte court. Si elle passe, le problème vient du flux ou d'un proxy intermédiaire.
  2. Testez en direct avec curl -N pour écarter le client Continue ; vérifiez aussi si le proxy met en tampon les réponses SSE.
  3. Vérifiez la chaîne de certificats. Avec une inspection TLS d'entreprise, indiquez l'autorité via requestOptions.caBundlePath ; verifySsl: false ne convient qu'au débogage temporaire.
  4. Vérifiez l'heure système : un écart important fait échouer la validation des certificats.
  5. Pour les tâches longues, fixez un délai et un nombre maximal de tours ; l'agent enchaîne les requêtes et une connexion bloquée donne l'impression d'un « chargement infini ». Le champ de délai varie selon les versions.

N'utilisez pas ping pour juger de la disponibilité de l'API : il prouve seulement que l'hôte est joignable, pas que TLS et le chemin sont corrects.

7. Dépassement de contexte et corps de requête trop volumineux

Un dépassement de contexte renvoie généralement 400 ou 413, avec des mentions context_length_exceeded, maximum context length, etc. Continue envoie ensemble les fichiers ouverts, les extraits de recherche, les références et l'historique : le contexte réel est souvent plus long qu'il n'y paraît.

Traitement :

  • Utilisez .continueignore ou les réglages d'exclusion d'index pour écarter les artefacts de build, journaux et dossiers de dépendances.
  • Fermez les onglets sans rapport, résumez les longs documents, ouvrez une nouvelle session pour les longues conversations.
  • Réduisez max_tokens par requête, validez d'abord la chaîne avec une requête courte, puis allongez progressivement.
  • Si l'échec ne survient que dans un grand dépôt, soupçonnez d'abord la recherche qui injecte trop d'extraits.

8. Conserver des journaux IDE utiles au diagnostic

Dans VS Code, ouvrez la palette de commandes et choisissez « Developer: Toggle Developer Tools » pour voir la console ; pour des journaux détaillés, activez « Continue: Enable Console » et rechargez la fenêtre. Dans JetBrains, consultez ~/.continue/logs/core.log ; les journaux de l'IDE se trouvent dans « Help > Show Log ».

Un journal doit au minimum contenir : heure, statut, code d'erreur, identifiant de modèle, hôte apiBase, identifiant de requête, durée et nombre de retries. L'identifiant de requête est souvent dans les en-têtes, sous un nom comme request-id, x-request-id ou x-oneapi-request-id, selon ce que renvoie la passerelle. Ne journalisez jamais la clé complète, les prompts ni le code utilisateur ; ne gardez que les quatre premiers et quatre derniers caractères de la clé.

Un journal utile ressemble à ceci :

2026-10-19T10:12:33+08:00 status=429 code=rate_limit_exceeded model=<ID du modèle> host=api.zhongshangqihang.com request_id=... latency_ms=1840 retry=2

9. Liste de diagnostic

  1. Notez le message d'erreur exact, le statut, l'heure et l'identifiant de requête.
  2. Reproduisez avec la commande curl de cet article pour vérifier si le problème ne concerne que Continue.
  3. Vérifiez si c'est config.yaml ou config.json qui est chargé, et si l'indentation YAML est correcte.
  4. Vérifiez que apiBase s'arrête à /v1 et copiez l'identifiant de modèle depuis la liste.
  5. Testez avec une nouvelle clé pour écarter une clé expirée, un quota ou une politique d'équipe.
  6. Commencez par une requête non streaming à contexte court, puis réintroduisez le flux et le contexte long ; changez de réseau ou de proxy si nécessaire.
  7. Si tout est validé, transmettez les journaux et les étapes de reproduction au support de la passerelle ou du plugin.

10. Questions fréquentes

La clé fonctionne ailleurs mais Continue renvoie 401 ?

Vérifiez d'abord si le champ est correct, puis si config.yaml est réellement chargé. Quand l'ancien config.json et le nouveau config.yaml coexistent, il est facile de modifier le mauvais fichier ; si l'équipe interdit les clés tierces, une configuration locale correcte échouera quand même.

Un 404 signifie-t-il toujours que le modèle est retiré ?

Non. Le plus souvent, apiBase a un /v1 en trop ou en moins, ou l'identifiant de modèle est mal orthographié. Consultez la liste des modèles, puis copiez l'identifiant pour tester.

Un 429 est-il un solde insuffisant ?

Pas nécessairement. Un 429 indique un dépassement de fréquence ou de quota ; un solde insuffisant peut renvoyer 401, 402 ou 403. Le corps d'erreur et la page de facturation font foi.

Pourquoi seule la complétion ou le streaming échoue-t-il ?

Soupçonnez d'abord la mise en tampon du proxy, le délai d'inactivité et les différences de capacités d'interface. Pour le streaming, comparez avec une requête non streaming ; pour la complétion, vérifiez si le modèle et l'interface prennent en charge la complétion ou le FIM, et n'affectez pas directement un modèle de chat à autocomplete.

Continue n'étant plus maintenu, cela vaut-il la peine de le configurer ?

Les installations existantes et les branches communautaires fonctionnent encore, et la sémantique des erreurs reste celle des interfaces compatibles OpenAI. Pour un nouveau projet à maintenir longtemps, évaluez des outils encore activement développés ; pour réutiliser un environnement existant, la démarche de cet article suffit.

Étape suivante

Créez une clé de test sur la passerelle ZSQH AI, passez en revue l'authentification, le modèle et le streaming avec la commande curl de cet article, puis remplissez config.yaml. Modèles et prix font foi sur la page tarifs des modèles et évoluent selon les fournisseurs ; pendant le diagnostic, fixez d'abord les variables, puis remplacez-les une par une.

Lecture associée :

Marques : Continue est une marque de Continue Dev, Inc. ; Cursor, Anysphere, OpenAI, Anthropic, Claude et les autres noms sont des marques de leurs titulaires respectifs. Cet article n'a qu'une visée de diagnostic technique et n'implique aucune affiliation ni coopération avec ces sociétés. L'état des produits, les messages d'erreur et le comportement des interfaces peuvent évoluer : référez-vous à la documentation officielle et aux réponses réelles.