Les identifiants de modèles ne sont pas portables : api.anthropic.com attend des identifiants datés, Gemini ses propres chaînes de version et chaque passerelle définit ses slugs. Un 404 signifie ici « cet hôte ne possède aucun modèle correspondant exactement à cette chaîne » ; la correction consiste toujours à demander au point de terminaison ce qu’il propose.
L’erreur
{
"error": {
"type": "model_not_found",
"message": "The model 'claude-sonnet' does not exist or you do not have access to it.",
"code": "model_not_found"
}
}Causes et solutions en bref
| Cause | Solution |
|---|---|
| Identifiant de modèle provenant d’un autre hôte | Chaque API possède son propre espace de noms : copiez les identifiants depuis la liste de modèles du point de terminaison, et non depuis des articles de blog. |
| Version obsolète ou renommée | Les fournisseurs retirent les instantanés datés ; utilisez un identifiant actuel et abonnez-vous aux avis d’obsolescence. |
| Slug comportant une faute ou tronqué | claude-sonnet n’est le nom d’aucun modèle ; les chaînes exactes sont importantes. |
| Le modèle existe, mais est désactivé pour votre clé ou votre forfait | Certains hôtes limitent les modèles selon le forfait ; le point de terminaison de liste indique ce que VOTRE clé peut appeler. |
Répertoriez les modèles depuis le point de terminaison appelé
GET /v1/models est la source de vérité sur tout hôte compatible OpenAI : il renvoie exactement les identifiants que votre clé peut utiliser :
curl -s https://api.kunavo.com/v1/models \
-H "Authorization: Bearer $KUNAVO_API_KEY" \
| python3 -c "import json,sys; print('\n'.join(m['id'] for m in json.load(sys.stdin)['data']))"Résolvez les modèles à l’exécution, plutôt que de les coder en dur
Les catalogues évoluent (nouveaux instantanés, retraits). Résolvez la liste des modèles au démarrage, donnez la préférence aux slugs configurés avec une solution de repli et alertez-vous lorsqu’un slug configuré disparaît de /v1/models, au lieu de provoquer un 404 en production.
Si vous appelez via Kunavo
Kunavo utilise des slugs stables et lisibles par les humains (claude-sonnet-5, gpt-5-6-terra, claude-fable-5), répertoriés via GET /v1/models avec des métadonnées par modèle. Les slugs retirés redirigent avec le statut 301 vers leurs successeurs sur les pages de modèles du site, afin que les liens ne deviennent pas obsolètes. Le point de terminaison de liste fait autorité ; llms.txt indique la même chose à tout agent qui le lit.
Questions fréquentes
Pourquoi le même identifiant de modèle fonctionne-t-il sur une API et renvoie-t-il 404 sur une autre ?
Parce que les identifiants sont propres à chaque hôte : les identifiants datés d’Anthropic, les noms versionnés de Gemini et les slugs de chaque passerelle sont des chaînes différentes pour des modèles apparentés. Copiez toujours les identifiants depuis la liste de modèles du point de terminaison cible.
Comment se prémunir contre le retrait des modèles ?
Résolvez /v1/models au démarrage, gardez l’identifiant du modèle dans la configuration (pas dans le code), définissez une chaîne de repli et déclenchez une alerte lorsqu’un identifiant configuré disparaît : un 404 de production devient ainsi une simple modification de configuration.
Guides associés
La sémantique détaillée des erreurs est disponible dans référence des erreurs ; obtenir une clé prend une minute via inscription et la guide d’authentification.