PicoClaw model not found 404 : identifiants de modèles et protocoles Anthropic

Dans PicoClaw, « model not found » et un 404 correspondent à quatre échecs différents, et un seul se produit en dehors de votre machine. Trois sont locaux — un alias qui ne se résout pas, le backend web de PicoClaw qui répond 404 et une chaîne de protocole inconnue — tandis que le quatrième est un 404 en amont dont le corps indique si la route ou l’identifiant du modèle est incorrect. Lire d’abord le texte de l’erreur vous évite de changer de protocole pour corriger une faute de frappe.

Cette page suppose que vous disposez déjà d’une entrée model_list fonctionnelle et d’une clé ; la configuration elle-même, ainsi que le coût de PicoClaw, sont présentés dans Tarification et configuration de l’API PicoClaw. Tout ce qui suit a été lu au tag publié v0.3.1, que l’API des versions a confirmé comme étant le plus récent le 21 septembre 2026, publié le 3 juillet 2026. Le dépôt a reçu son dernier push le 17 septembre 2026, de sorte que main est en avance sur le tag — lorsque cela a une incidence, c’est précisé. Le 1er octobre 2026, v0.3.1 était toujours la dernière version ; son binaire de publication a alors été exécuté contre un endpoint d’enregistrement local et, avec une clé volontairement invalide, contre Kunavo ; ce que cela a montré est consigné ci-dessous.

Quatre échecs, une seule expression

Il faut donc d’abord déterminer si la requête a quitté votre machine ; la chaîne seule permet de le savoir. Une incompatibilité d’alias est un cas documenté, et non une hypothèse : le problème PicoClaw #958 signale error creating provider: model "llama3.2" not found in model_list, tandis que picoclaw status montrait que l’endpoint Ollama était accessible et que le modèle était présent sous la forme llama3.2:latest. Il a été fermé le 25 mars 2026 par le bot du dépôt chargé des problèmes obsolètes. Notez que, dans ce dépôt, un problème fermé marqué completed ne signifie pas qu’il a été corrigé — le même bot a fermé #1624 avec la même formulation.

Le texte d’enveloppe indique le protocole qui a réellement été exécuté

Comme anthropic avec une clé API et anthropic-messages construisent des fournisseurs différents, leurs enveloppes 404 diffèrent — ce qui fait du message d’erreur un outil de diagnostic gratuit.

Pourquoi les conseils 404 de PicoClaw peuvent vous orienter dans la mauvaise direction

Le guide des fournisseurs de PicoClaw vous indique de passer à anthropic-messages lorsque « Le protocole anthropic existant renvoie des erreurs 404 (ce qui indique que l’endpoint ne prend pas en charge le format compatible OpenAI) », et ajoute la note qui tranche la question des noms : « Le protocole anthropic utilise le format compatible OpenAI (/v1/chat/completions), tandis que anthropic-messages utilise le format natif d’Anthropic (/v1/messages). » Les deux citations ont été relues dans v0.3.1 le 21 septembre 2026.

Ce conseil est correct pour un 404 de route et incorrect pour un 404 de modèle. Il se trouve aussi 294 lignes sous une table du même fichier dont la colonne Protocol indique Anthropic pour la ligne anthropic, ce qui dit l’inverse. Le code résout cette contradiction d’une manière peu évidente : anthropic correspond à deux protocoles selon auth_method. Avec oauth ou token, il construit le fournisseur SDK Anthropic natif et la table est correcte ; avec une clé API, il bascule vers le même fournisseur compatible OpenAI qu’utilise openai et toute sa famille, et la note est correcte.

Deux conséquences en découlent directement. Pour la famille openai, écrire https://api.kunavo.com au lieu de https://api.kunavo.com/v1 assemble https://api.kunavo.com/chat/completions — un 404 de route causé par votre propre configuration, et le cas le plus fréquent. Sur les deux protocoles Anthropic, cette erreur est impossible, car le /v1 est forcé dans les deux cas ; mais ce forçage signifie aussi qu’une passerelle dont le chemin ne doit pas se terminer par /v1 ne peut pas être exprimée avec ces protocoles et doit passer par le protocole openai. La propre documentation de PicoClaw utilise cette solution de repli pour un fournisseur dont la base se termine par un autre segment de version.

Une affirmation à considérer comme non établie. L’unique commentaire sur le problème PicoClaw #269 affirme qu’une requête vers /v1/chat/completions renvoie 404 chez Anthropic, car l’endpoint correct serait /v1/messages. La documentation d’Anthropic elle-même le contredit : elle publie une couche de compatibilité avec le SDK OpenAI avec base_url https://api.anthropic.com/v1/ et marque l’en-tête authorization comme « Fully supported » (vérifié le 21 septembre 2026), tout en précisant sur la même page que la couche « n’est pas considérée comme une solution durable ou prête pour la production dans la plupart des cas d’utilisation ». Le problème #269 a été fermé le 13 mars 2026 sans commentaire de clôture — l’API des problèmes n’y montre qu’un commentaire, l’analyse ci-dessus, provenant d’un compte sans association au dépôt — ; la manière dont il a réellement été résolu est donc inconnue. Fiez-vous à votre propre corps 404 plutôt qu’à l’un ou l’autre compte.

Lorsque le 404 concerne l’identifiant du modèle

Le problème PicoClaw #1624 — ouvert le 16 mars 2026 et fermé le 31 mars 2026 — consigne le corps exact pour un identifiant Claude avec points configuré comme "model": "anthropic/claude-sonnet-4.6" : Status: 404 avec {"error":{"code":"not_found_error","message":"model: claude-sonnet-4.6 was not found. Did you mean claude-sonnet-4-6?"…. Son titre et son unique commentaire ont été relus dans l’API des problèmes le 21 septembre 2026 : le commentaire provient du bot chargé des problèmes obsolètes ; le problème est donc fermé, mais rien ne prouve qu’il ait été corrigé.

L’indication « did you mean » est révélatrice. Elle ne revient que d’un endpoint qui a analysé la requête ; la route a donc fonctionné et aucun changement de protocole n’aidera. La raison pour laquelle PicoClaw ne corrige pas l’écriture à votre place est précise et vérifiable : strings.ReplaceAll(model, ".", "-") n’apparaît qu’une seule fois dans le dépôt, dans pkg/providers/anthropic/provider.go à la ligne 219 — le fournisseur SDK utilisé pour les chemins OAuth et par jeton. Ni anthropic_messages/provider.go ni openai_compat/provider.go ne le contient. Les deux affirmations ont été revérifiées dans v0.3.1 le 21 septembre 2026, et la recherche préalable à cette page a récupéré de nouveau les mêmes fichiers depuis main le même jour, avec le même résultat. L’exécution du binaire v0.3.1 le 1er octobre 2026 l’a confirmé sur les deux chemins avec clé API : l’identifiant avec points a atteint l’endpoint exactement tel qu’il était écrit et a renvoyé le propre 404 de l’endpoint (voir ce que l’exécution de v0.3.1 a montré). Le chemin OAuth et par jeton, le seul avec la réécriture, n’a pas été exécuté.

Les propres fichiers de PicoClaw ne s’accordent pas non plus sur l’écriture : provider_metadata.go répertorie des identifiants avec tirets pour les deux entrées Anthropic, l’exemple anthropic du guide des fournisseurs en utilise un avec points, et anthropic-messages renvoie une valeur par défaut avec points depuis GetDefaultModel — la même écriture que #1624 montre comme rejetée. Tous les identifiants d’API Claude affichés dans la vue d’ensemble des modèles d’Anthropic utilisent des tirets, et cette page répertorie Claude Sonnet 4.6 et Claude Opus 4.6 sous « Legacy models (still available) » — ce n’est donc pas un retrait qui expliquerait aujourd’hui un 404 pour un identifiant 4.6 chez Anthropic. Cela écarte une cause, mais pas toutes : un identifiant avec tirets peut encore être rejeté par une passerelle qui ne propose pas le modèle. Copiez l’identifiant depuis l’endpoint que vous appelez, et non depuis un README.

Écrivez explicitement les deux entrées et conservez l’identifiant avec tirets. Les clés n’ont pas leur place dans ce fichier — PicoClaw les lit depuis ~/.picoclaw/.security.yml, ce qui est couvert dans le guide de configuration.

{
  "agents": {
    "defaults": {
      "model_name": "kunavo-sonnet"
    }
  },
  "model_list": [
    {
      "model_name": "kunavo-sonnet",
      "provider": "openai",
      "model": "claude-sonnet-4-6",
      "api_base": "https://api.kunavo.com/v1"
    },
    {
      "model_name": "kunavo-sonnet-native",
      "provider": "anthropic-messages",
      "model": "claude-sonnet-4-6",
      "api_base": "https://api.kunavo.com"
    }
  ]
}

La première entrée fournit elle-même /v1, car la famille compatible OpenAI concatène /chat/completions à api_base textuellement. La seconde l’omet délibérément, pour montrer que, avec anthropic-messages, les deux écritures se normalisent vers la même base. L’URL de base publiée par Kunavo est https://api.kunavo.com/v1 pour les complétions de chat et https://api.kunavo.com/v1/messages pour la route Messages. Le fait que les deux calculs d’URL aboutissent au même point relève de l’arithmétique entre deux ensembles de documentation — et, le 1er octobre 2026, les deux entrées ont été exécutées depuis v0.3.1 contre Kunavo avec une clé volontairement invalide : l’entrée openai a atteint /v1/chat/completions et l’entrée anthropic-messages a atteint /v1/messages, chacune recevant le 401 de Kunavo. Cela prouve les URL, et non une requête aboutie : cette page ne prétend pas qu’une intégration a été testée. Pour la forme générale de la question sur l’URL de base, consultez la documentation de l’URL de base Anthropic.

Une passerelle peut également répondre 404 volontairement, et ce n’est pas un bug de PicoClaw. Kunavo renvoie 404 pour un modèle temporairement suspendu, avec un corps qui nomme le modèle et le remplacement à utiliser, et omet les modèles suspendus de /v1/models ; faites correspondre la structure de ce message plutôt qu’un nom précis, car les modèles suspendus changent. Kunavo ne propose pas non plus de modèle d’embeddings, de synthèse vocale ou de reconnaissance vocale ; une entrée model_list qui en nomme un renverra donc 404 quel que soit le protocole choisi — dirigez ces entrées vers un autre fournisseur et conservez uniquement les entrées de chat avec une clé Kunavo.

Ce que l’exécution de v0.3.1 a montré

Le 1er octobre 2026, le binaire de publication v0.3.1, dont la somme de contrôle a été vérifiée par rapport au propre fichier de sommes de contrôle de la version, a été exécuté dans un conteneur temporaire avec une seule entrée model_list à la fois et picoclaw agent -m. L’endpoint était un serveur d’enregistrement local qui se comportait comme le routage de Kunavo à ce moment-là — /v1/* correspond à l’API, tout autre chemin renvoyait une page 404 HTML (Kunavo répond désormais à ces chemins par un 404 JSON qui indique la correction ; voir les lignes Kunavo) — et connaissait claude-sonnet-5 et claude-sonnet-4-6, mais pas l’identifiant avec points ; les trois dernières lignes utilisaient le véritable api.kunavo.com avec une clé volontairement invalide, de sorte que rien n’a été facturé.

Cette exécution permet d’établir deux points que la lecture du code ne pouvait que prédire. L’enveloppe d’erreur nomme bien le fournisseur exécuté, ce qui permet de déduire le protocole en toute sécurité ; et un identifiant avec points est envoyé sans modification sur les deux chemins avec clé API, de sorte qu’un « model not found » qui cite un identifiant avec points se corrige en réécrivant l’identifiant, et non en changeant de protocole. Ce que cela ne couvre pas : les chemins OAuth et par jeton, l’interface web du lanceur, le streaming et toute requête qui aurait abouti via Kunavo — les lignes Kunavo utilisaient volontairement une clé invalide.

L’ordre de vérification le plus court

1. Quelque chose a-t-il quitté la machine ? Une erreur de terminal contenant not found in model_list sans statut HTTP est locale. Faites correspondre agents.defaults.model_name à une entrée model_name et arrêtez-vous là.
2. Est-ce venu de localhost ? Un 404 dans le navigateur lors de la sélection d’un modèle par défaut dans l’interface web de PicoClaw correspond à la même incompatibilité, servie par le propre backend de PicoClaw. Aucune API de modèle n’est intervenue.
3. Quel fournisseur s’est exécuté ? Faites correspondre le texte de l’enveloppe à la table ci-dessus. Si l’enveloppe ne correspond pas au protocole que vous pensez avoir configuré, le champ provider ou le préfixe du modèle ne correspond pas à ce que vous croyez.
4. 404 de route ou 404 de modèle ? Un corps qui nomme votre modèle — en particulier avec une indication did you mean — correspond à un 404 de modèle : corrigez l’identifiant. Une page HTML, un corps vide ou un message générique de ressource introuvable correspond à un 404 de route : reconstituez l’URL assemblée à partir de la table avant toute autre intervention.
5. Demandez à l’endpoint ce qu’il propose. PicoClaw ne peut pas le faire avec l’un ou l’autre protocole Anthropic, car aucune des deux entrées du catalogue ne définit l’indicateur de récupération. Utilisez curl contre la propre route /v1/models de la passerelle, ou pointez temporairement la même passerelle vers le protocole openai. Modèle introuvable chez plusieurs fournisseurs couvre cette méthode, et Modèle Anthropic introuvable avec un 404 couvre les cas où l’identifiant lui-même pose problème.
6. Ne changez de protocole qu’à présent, et uniquement si l’étape 4 a indiqué un 404 de route. Si l’en-tête d’authentification est le problème plutôt que le format des échanges, jeton d’authentification contre clé API explique la différence.
7. Revérifiez avec un tour d’outil, et non avec un simple tour de chat. Une configuration qui répond à un message simple peut encore échouer au premier appel d’outil ; la tâche limitée utilisée pour confirmer la correction doit donc en inclure un.

Ce que le choix du protocole vous coûte

La principale conséquence en matière de coût concerne la mise en cache des prompts, et elle est structurelle plutôt que liée à un paramètre. Dans PicoClaw v0.3.1, le seul code qui émet un point d’arrêt de cache se trouve dans pkg/providers/anthropic/provider.go, atteint uniquement sur les chemins OAuth et par jeton. Avec une clé API — le cas courant où vous fournissez votre propre clé — aucun des deux protocoles Anthropic n’envoie cache_control. Avec la propre couche de compatibilité d’Anthropic, cela se cumule, car sa documentation indique clairement que « Prompt caching is not supported, but it is supported in the Anthropic SDKs ». Avec une passerelle qui insère des points d’arrêt pour les appelants au format OpenAI, l’économie est récupérée au niveau de la passerelle ; la documentation de mise en cache de Kunavo indique qu’elle le fait et définit précisément le périmètre : les modèles Claude atteints via /v1/chat/completions ou /v1/responses. La même page indique que cache_control est transmis sans traduction sur la route Messages native — l’entrée anthropic-messages n’obtient donc de points d’arrêt d’aucun côté, et la deuxième colonne ci-dessous décrit uniquement l’entrée utilisant le protocole openai. Il n’a pas été vérifié si d’autres passerelles insèrent des points d’arrêt, et rien de tout cela n’a été observé depuis l’intérieur de PicoClaw.

Cela correspond à un calcul illustratif sur les tokens, et non à un coût mesuré pour une tâche ni à un plafond de facturation. Supposons un tour d’agent comprenant 10 cycles d’appels d’outils, où chaque cycle renvoie le même préfixe de 20,000 tokens (prompt système, schémas des outils, historique de la conversation jusqu’à ce point), ajoute 1,000 nouveaux tokens d’entrée et renvoie 600 tokens de sortie. Ces proportions sont des hypothèses à titre d’illustration. La première colonne facture les tokens d’entrée de chaque cycle au plein tarif ; la seconde facture le préfixe répété au tarif de lecture du cache à partir du deuxième cycle. Les tarifs sont les prix actuels du catalogue Kunavo par million de tokens.

Avec ces hypothèses, Claude Sonnet 4.6 passe de $0.504 à $0.164 pour le même travail. Considérez la deuxième colonne comme optimiste : les écritures du cache sont facturées à leur propre tarif et ne sont modélisées dans aucun des deux cas, et un préfixe qui change à chaque cycle ne devient jamais un accès au cache. Multipliez par le nombre de tours par jour avant de considérer quoi que ce soit comme un budget.

Séparez les deux factures pendant que vous y êtes. PicoClaw lui-même est gratuit — le dépôt est sous licence MIT, et aucun protocole, y compris les deux protocoles Anthropic, n’est soumis à l’achat de quoi que ce soit. Le coût récurrent correspond aux tokens du modèle, au tarif de votre fournisseur. Le montant du catalogue Kunavo constitue un plancher de facturation, et non un plafond : lorsque l’amont communique son coût, la facture correspond au montant le plus élevé entre le coût du catalogue et le coût amont multiplié par la majoration applicable. Le rechargement minimum est de $10 de crédit prépayé, un minimum de financement et non des frais de tâche ou un abonnement — voir les détails de facturation.

Fournisseur direct, passerelle, abonnement ou local

Vous choisissez le runtime plutôt que la route ? PicoClaw vs OpenClaw compare les deux selon leur mode de déploiement. Si vous optez pour une passerelle et souhaitez créditer une clé, créez un compte Kunavo, puis envoyez une tâche limitée contenant un appel d’outil et consultez le montant effectivement enregistré par votre compte.

Questions fréquentes

Vérifié le 21 septembre 2026. Revérifié dans le cadre de cette tâche sur le tag v0.3.1 : la note de protocole et la ligne du fournisseur Anthropic du guide des fournisseurs, la branche anthropic et le cas par défaut de factory_provider.go, NormalizeBaseURL, l’URL anthropic-messages, les en-têtes et la chaîne 404, la concaténation d’URL et l’en-tête Bearer de openai_compat, les trois chaînes « not found in model_list » antérieures à HTTP, la réponse 404 du backend web, l’unique occurrence du remplacement point-vers-tiret, la colonne SupportsFetch du tableau des options de fournisseur et l’exemple OpenRouter dans docs/operations/troubleshooting.md ; ainsi que l’API des versions (v0.3.1, publiée le 3 juillet 2026) et les titres, états, dates et commentaires des problèmes #1624, #958 et #269. La page de compatibilité Anthropic OpenAI-SDK a été consultée le même jour. Exécuté le 1er octobre 2026 : le binaire de la version v0.3.1 dans un conteneur contre un endpoint d’enregistrement local et, avec une clé invalide, contre Kunavo — chaque ligne du tableau ci-dessus. Non vérifié : tout ce qui concerne main au-delà des fichiers comparés par la recherche, ce qui a clôturé le problème #269, les chemins OAuth et tokens, et toute requête terminée via Kunavo. Les tarifs des tokens Kunavo proviennent du catalogue actuel, et chaque montant en dollars présenté ici correspond à un calcul illustratif de tokens.