Model Not Found : diagnostiquer et corriger l'erreur API

Ce qu'il faut enregistrer avant de modifier la configuration

Créez d'abord une petite fiche de diagnostic :

time: 2026-08-03T12:00:00Z
client: your-client-and-version
protocol: openai-compatible | anthropic-compatible
base_url: https://example.com/v1
model: MODEL_ID_FROM_CONFIG
http_status: 404
provider_code: model_not_found
request_id: req_...

API Key, prompt complet et réponse ne doivent pas figurer dans cette fiche. Si l'erreur est survenue dans l'IDE ou un outil Agent, notez séparément le nom du fichier de configuration et la présence de variables d'environnement. Cela permet de savoir quelle valeur a réellement été envoyée au serveur.

Vous voulez refaire le diagnostic avec le catalogue actuel ? Vous pouvez créer votre compte BetterToken et API Key, vérifier endpoint et Model ID avec la référence API, puis lancer une requête minimale. Pour BetterToken, type d'endpoint, Base URL, groupe de Key et Model ID actuel doivent correspondre. Prenez le nom actuel dans la documentation ou la page modèles et prix, puis vérifiez le résultat dans le Dashboard.

Étape 1 : vérifier Base URL et chemin

Examinez l'URL finale de la requête, pas seulement la ligne des paramètres. Le SDK peut ajouter lui-même /v1, /models, /chat/completions, /responses ou /messages.

Erreurs typiques :

• la Base URL contient déjà le chemin de ressource et le SDK l'ajoute une seconde fois;
• /v1 est absent ou dupliqué;
• le client OpenAI envoie vers une adresse Anthropic-compatible;
• une variable d'environnement remplace la Base URL du fichier de configuration;
• l'application utilise un autre profil ou workspace.

Pour BetterToken OpenAI-compatible, les outils utilisent une Base URL avec /v1; Anthropic SDK et Claude Code utilisent une adresse sans /v1, le chemin Messages complet étant ajouté séparément. Avant correction, consultez la page actuelle de l'outil concerné.

Étape 2 : vérifier quelle API Key est réellement utilisée

La même interface peut stocker plusieurs credentials. Une erreur de modèle masque parfois l'absence d'accès de la Key sélectionnée.

Vérifiez :

1. le credential ou la variable d'environnement dont le client lit la Key;
2. l'absence d'espaces ou retours ligne supplémentaires;
3. la correspondance de la Key avec protocole et groupe de modèles;
4. si la configuration de projet remplace le réglage global;
5. si la Key a expiré ou été révoquée.

N'affichez pas la clé avec echo, un log de débogage ou une capture. Pour comparer des credentials, un nom de profil sûr ou les derniers caractères d'empreinte suffisent si l'interface les montre elle-même.

Étape 3 : obtenir le Model ID actuel

Un endpoint OpenAI-compatible a souvent une liste de modèles. Une requête de diagnostic sûre ressemble à ceci :

curl "$OPENAI_BASE_URL/models" \
  -H "Authorization: Bearer $OPENAI_API_KEY"

La commande utilise des variables d'environnement et ne contient pas la vraie clé. Elle n'est appropriée que lorsque la documentation de l'endpoint confirme /models.

Avec un autre protocole ou client, utilisez le répertoire officiel du provider. Copiez le champ id sans changer casse, espaces ni suffixes. Nom marketing et API Model ID peuvent différer.

Si la liste s'ouvre mais que le modèle voulu n'y apparaît pas, contrôlez Key et catalogue. Si /models retourne déjà une erreur, réparez d'abord endpoint ou autorisation.

Étape 4 : trouver alias et réglage hérité

Le Model ID peut venir de plusieurs sources :

• configuration du projet;
• configuration globale du client;
• variable d'environnement;
• profil UI;
• option de ligne de commande;
• session enregistrée;
• passerelle de routage ou de mapping de modèles.

La recherche dans le dépôt aide à trouver la valeur ancienne :

rg -n --hidden --glob '!node_modules' --glob '!.git' \
  'OLD_MODEL_ID|model[[:space:]]*=' .

La recherche peut aussi trouver des fichiers contenant des secrets. Ne publiez pas la sortie complète. Corrigez uniquement la source lue par le client.

Les outils AI donnent souvent priorité à la configuration projet sur la configuration globale. Après la modification, redémarrez le client ou ouvrez une session neuve s'il met en cache les réglages du provider.

Étape 5 : distinguer erreur de modèle et erreur d'accès

Les codes HTTP des API compatibles ne sont pas forcément identiques; consultez donc aussi le corps d'erreur.

• 401 : vérifiez d'abord credential et format d'autorisation.
• 403 : le modèle peut exister mais la Key actuelle n'y a pas accès.
• 404 : chemin, endpoint ou Model ID possible.
• 400 : le serveur a peut-être rejeté model ou un autre paramètre.
• 429 / 5xx : c'est généralement une autre catégorie; ne changez pas Model ID sans signal supplémentaire.

La formule model not found dans l'UI peut être une paraphrase du client. Trouvez le statut HTTP, le code provider et la request ID originaux.

Retest minimal

Après correction, envoyez une requête courte sans streaming ni outils. Pour Chat Completions OpenAI-compatible, le schéma peut ressembler à ceci :

curl "$OPENAI_BASE_URL/chat/completions" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MODEL_ID_FROM_CURRENT_CATALOG",
    "messages": [{"role": "user", "content": "Reply with OK"}],
    "max_tokens": 8
  }'

Les champs et l'endpoint doivent correspondre à la documentation du provider. Ne transférez pas cet exemple à Anthropic Messages sans adaptation.

Un contrôle réussi réunit quatre correspondances :

• statut HTTP de succès;
• réponse indiquant le Model ID attendu ou sa version documentée;
• requête présente dans le Dashboard;
• heure, statut et usage correspondant au test.

Si la requête courte fonctionne mais que l'IDE montre encore model not found, la configuration serveur est déjà corrigée. Cherchez alors un override ou cache dans le client.

Liste courte de contrôle

• Statut, code provider et request ID enregistrés.
• URL finale vérifiée, sans double /v1 ni chemin de ressource.
• Le client utilise le credential attendu.
• Model ID pris dans le catalogue actuel.
• Overrides projet, globaux et d'environnement vérifiés.
• Une requête minimale sans outils ni stream exécutée.
• Requête reliée au Dashboard.

Pour BetterToken, vérifiez la référence API et le catalogue de modèles actuel avant de remplacer une Model ID. C'est plus rapide et sûr que de chercher des noms similaires.

FAQ

Pourquoi le modèle est visible sur le site, mais l'API retourne model not found ?

Il peut s'agir d'un autre protocole, groupe de Key, d'une session obsolète ou d'une différence entre nom marketing et API ID. Consultez la liste de modèles pour le credential actuel.

Répéter la requête peut-il aider ?

Pas en cas de faute de frappe ou de mauvais endpoint. Corrigez d'abord la configuration. Un retry n'est approprié que pour une erreur temporaire quand statut et code provider le confirment.

Puis-je enregistrer la liste de modèles dans la configuration pour toujours ?

Enregistrez l'ID choisi comme réglage géré et comparez-le régulièrement avec le catalogue actuel. Disponibilité et alias peuvent changer.

Pourquoi curl fonctionne mais pas l'application ?

L'application peut lire une autre Base URL, un autre credential ou un autre Model ID. Comparez la requête finale et vérifiez override de projet, variables d'environnement et profil enregistré.

Sources

• OpenAI Models API reference — consultée le 22 août 2026
• Anthropic API errors — consultée le 22 août 2026
• BetterToken API reference