PicoClaw modello non trovato 404: id dei modelli e protocolli Anthropic

In PicoClaw, "model not found" e un 404 sono quattro errori diversi, e solo uno di essi avviene fuori dalla tua macchina. Tre sono locali — un alias che non viene risolto, il backend web di PicoClaw che risponde 404 e una stringa di protocollo sconosciuta — mentre il quarto è un 404 upstream il cui corpo indica se la route era errata o se lo era l'id del modello. Leggere prima il testo dell'errore impedisce di cambiare protocollo per correggere un refuso.

Questa pagina presuppone che tu disponga già di una voce model_list funzionante e di una chiave; la configurazione in sé e i costi di PicoClaw sono trattati in Prezzi e configurazione dell'API di PicoClaw. Tutto ciò che segue è stato letto al tag rilasciato v0.3.1, che l'API delle release ha confermato come più recente il 21 settembre 2026, pubblicato il 3 luglio 2026. L'ultimo push al repository risaliva al 17 settembre 2026, quindi main è più avanti del tag — quando è rilevante, viene indicato. Il 1° ottobre 2026 v0.3.1 era ancora la release più recente, e il suo binario di release è stato eseguito contro un endpoint locale di registrazione e, con una chiave deliberatamente non valida, contro Kunavo; ciò che ha mostrato è riportato di seguito.

Quattro errori, un'unica espressione

Stabilire se la richiesta ha lasciato la tua macchina è quindi la prima cosa da fare, e la sola stringa lo determina. Una mancata corrispondenza dell'alias è un caso documentato, non ipotetico: il problema PicoClaw #958 segnala error creating provider: model "llama3.2" not found in model_list mentre picoclaw status mostrava che l'endpoint Ollama era raggiungibile e che il modello era presente come llama3.2:latest. È stato chiuso il 25 marzo 2026 dal bot del repository che chiude i problemi obsoleti. Nota che in questo repository un problema chiuso contrassegnato come completed non significa che sia stato corretto — lo stesso bot ha chiuso #1624 con la stessa formulazione.

Il testo dell'involucro identifica il protocollo effettivamente eseguito

Poiché anthropic con una chiave API e anthropic-messages costruiscono provider diversi, i loro involucri 404 differiscono — rendendo la stringa dell'errore uno strumento diagnostico gratuito.

Perché i suggerimenti 404 di PicoClaw possono indirizzarti nella direzione sbagliata

La guida ai provider di PicoClaw consiglia di passare a anthropic-messages quando "Il protocollo anthropic esistente restituisce errori 404 (a indicare che l'endpoint non supporta il formato compatibile con OpenAI)", e aggiunge la nota che chiarisce la denominazione: "Il protocollo anthropic usa il formato compatibile con OpenAI (/v1/chat/completions), mentre anthropic-messages usa il formato nativo di Anthropic (/v1/messages)." Entrambe le citazioni sono state rilette in v0.3.1 il 21 settembre 2026.

Quel suggerimento è corretto per un 404 della route e sbagliato per un 404 del modello. Inoltre si trova 294 righe sotto una tabella nello stesso file, la cui colonna Protocol riporta Anthropic per la riga anthropic, affermando il contrario. Il codice risolve la contraddizione in modo poco evidente: anthropic è costituito da due protocolli a seconda di auth_method. Con oauth o token costruisce il provider SDK Anthropic nativo e la tabella è corretta; con una chiave API ricade nello stesso provider compatibile con OpenAI usato da openai e da tutta la sua famiglia, e la nota è corretta.

Ne derivano direttamente due conseguenze. Nella famiglia openai, scrivere https://api.kunavo.com invece di https://api.kunavo.com/v1 assembla https://api.kunavo.com/chat/completions — un 404 della route causato dalla tua stessa configurazione, e quello più comune. In entrambi i protocolli Anthropic questo errore è impossibile, perché /v1 è forzato in ogni caso; tuttavia lo stesso forzamento significa che un gateway il cui percorso non deve terminare in /v1 non può essere espresso tramite essi e deve passare invece dal protocollo openai. La documentazione di PicoClaw usa questa via di fuga per un vendor la cui base termina in un diverso segmento di versione.

Un'affermazione da considerare non risolta. L'unico commento sul problema PicoClaw #269 sostiene che l'invio a /v1/chat/completions restituisca 404 su Anthropic perché l'endpoint corretto è /v1/messages. La documentazione di Anthropic lo contraddice: pubblica un livello di compatibilità con l'SDK OpenAI con base_url https://api.anthropic.com/v1/ e contrassegna l'header authorization come "Fully supported" (verificato il 21 settembre 2026), avvertendo però nella stessa pagina che il livello "non è considerato una soluzione a lungo termine o pronta per la produzione per la maggior parte dei casi d'uso". Il problema #269 è stato chiuso il 13 marzo 2026 senza commento di chiusura — l'API dei problemi mostra un solo commento, l'analisi sopra, proveniente da un account senza associazione al repository — quindi non è noto cosa lo abbia effettivamente risolto. Fidati del corpo del tuo 404 più che di uno dei due account.

Quando il 404 riguarda l'id del modello

Il problema PicoClaw #1624 — aperto il 16 marzo 2026, chiuso il 31 marzo 2026 — registra il corpo esatto per un id Claude con i punti configurato come "model": "anthropic/claude-sonnet-4.6": Status: 404 con {"error":{"code":"not_found_error","message":"model: claude-sonnet-4.6 was not found. Did you mean claude-sonnet-4-6?"…. Il titolo e il suo unico commento sono stati riletti dall'API dei problemi il 21 settembre 2026: il commento proviene dal bot degli elementi obsoleti, quindi il problema è chiuso ma non vi è alcuna prova di una correzione.

Un suggerimento "did you mean" è rivelatore. Torna solo da un endpoint che ha analizzato la richiesta, quindi la route ha funzionato e nessun cambio di protocollo sarà utile. Il motivo per cui PicoClaw non corregge la grafia al posto tuo è circoscritto e verificabile: strings.ReplaceAll(model, ".", "-") compare una volta nel repository, in pkg/providers/anthropic/provider.go alla riga 219 — il provider SDK usato nei percorsi OAuth e token. Né anthropic_messages/provider.go né openai_compat/provider.go lo contiene. Entrambe le affermazioni sono state ricontrollate in v0.3.1 il 21 settembre 2026, e la ricerca che ha preceduto questa pagina ha recuperato nuovamente gli stessi file da main lo stesso giorno con lo stesso risultato. L'esecuzione del binario v0.3.1 il 1° ottobre 2026 lo ha confermato su entrambi i percorsi con chiave API: l'id con i punti ha raggiunto l'endpoint esattamente come scritto ed è tornato come il 404 dell'endpoint stesso (vedi ciò che ha mostrato l'esecuzione di v0.3.1). Il percorso OAuth e token, l'unico con la riscrittura, non è stato eseguito.

Anche i file propri di PicoClaw non concordano sulla grafia: provider_metadata.go elenca id con i trattini per entrambe le voci Anthropic, l'esempio anthropic della guida ai provider usa un id con i punti e anthropic-messages restituisce un valore predefinito con i punti da GetDefaultModel — la stessa grafia che #1624 mostra essere rifiutata. Ogni id dell'API Claude mostrato nella panoramica dei modelli di Anthropic usa i trattini, e quella pagina elenca Claude Sonnet 4.6 e Claude Opus 4.6 sotto "Legacy models (still available)" — quindi il ritiro non è il motivo per cui un id 4.6 oggi restituirebbe 404 su Anthropic. Questo esclude una causa, non tutte: un id con i trattini può ancora essere rifiutato da un gateway che non dispone del modello. Copia l'id dall'endpoint che stai chiamando, non da un README.

Scrivi esplicitamente entrambe le voci e mantieni l'id con i trattini. Le chiavi non appartengono a questo file — PicoClaw le legge da ~/.picoclaw/.security.yml, come illustrato nella guida alla configurazione.

{
  "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 prima voce fornisce da sola /v1 perché la famiglia compatibile con OpenAI concatena /chat/completions a api_base alla lettera. La seconda lo omette deliberatamente, per mostrare che su anthropic-messages entrambe le grafie vengono normalizzate alla stessa base. L'URL di base pubblicato da Kunavo è https://api.kunavo.com/v1 per i completamenti chat e https://api.kunavo.com/v1/messages per la route Messages. Il fatto che i due insiemi di aritmetica degli URL coincidano è aritmetica su due insiemi di documentazione — e il 1° ottobre 2026 entrambe le voci sono state eseguite da v0.3.1 contro Kunavo con una chiave deliberatamente non valida: la voce openai ha raggiunto /v1/chat/completions e la voce anthropic-messages ha raggiunto /v1/messages, e ciascuna ha ricevuto il 401 di Kunavo. Questo dimostra gli URL, non una richiesta completata: nulla in questa pagina afferma di aver testato un'integrazione. Per la forma generale della domanda sull'URL di base, consulta la documentazione sull'URL di base Anthropic.

Un gateway può anche rispondere 404 intenzionalmente, e questo non è un bug di PicoClaw. Kunavo restituisce 404 per un modello temporaneamente sospeso, con un corpo che indica il modello e la sostituzione da usare, e omette i modelli sospesi da /v1/models; segui la struttura di quel messaggio anziché un nome specifico, perché i modelli sospesi cambiano. Kunavo inoltre non offre alcun modello di embedding, sintesi vocale o trascrizione vocale, quindi una voce model_list che ne nomini uno restituirà 404 indipendentemente dal protocollo scelto — indirizza quelle voci a un altro provider e mantieni su una chiave Kunavo solo le voci chat.

Cosa ha mostrato l'esecuzione di v0.3.1

Il 1° ottobre 2026 il binario della release v0.3.1, verificato tramite checksum rispetto al file dei checksum della release stessa, è stato eseguito in un container usa e getta con una voce model_list alla volta e picoclaw agent -m. L'endpoint era un server locale di registrazione che all'epoca si comportava come il routing di Kunavo — /v1/* è l'API, qualsiasi altro percorso restituiva una pagina HTML 404 (ora Kunavo risponde a quei percorsi con un 404 JSON che indica la correzione; vedi le righe Kunavo) — e conosce claude-sonnet-5 e claude-sonnet-4-6 ma non l'id con i punti; le ultime tre righe hanno usato il vero api.kunavo.com con una chiave deliberatamente non valida, quindi nulla è stato addebitato.

Questa esecuzione chiarisce due aspetti che la sola lettura del codice poteva soltanto prevedere. L'involucro dell'errore indica davvero il provider eseguito, quindi è sicuro dedurre il protocollo da esso; inoltre un id con i punti viene inviato invariato su entrambi i percorsi con chiave API, quindi un "model not found" che cita un id con i punti si risolve riscrivendo l'id, non cambiando protocollo. Ciò che non copre: i percorsi OAuth e token, l'interfaccia web del launcher, lo streaming e qualsiasi richiesta completata tramite Kunavo — le righe Kunavo hanno usato intenzionalmente una chiave non valida.

L'ordine di verifica più breve

1. Qualcosa ha lasciato la macchina? Un errore del terminale contenente not found in model_list senza stato HTTP è locale. Rendi agents.defaults.model_name uguale a una voce model_name e fermati lì.
2. Proviene da localhost? Un 404 nel browser mentre selezioni un modello predefinito nell'interfaccia web di PicoClaw è la stessa mancata corrispondenza, servita dal backend di PicoClaw stesso. Non è stata coinvolta alcuna API di modelli.
3. Quale provider è stato eseguito? Confronta il testo dell'involucro con la tabella sopra. Se l'involucro non corrisponde al protocollo che pensi di aver configurato, il campo provider o il prefisso del modello non sono ciò che pensi.
4. 404 della route o 404 del modello? Un corpo che indica il tuo modello — soprattutto con un suggerimento did you mean — è un 404 del modello: correggi l'id. Una pagina HTML, un corpo vuoto o un not-found generico è un 404 della route: ricalcola l'URL assemblato dalla tabella prima di toccare qualsiasi altra cosa.
5. Chiedi all'endpoint cosa offre. PicoClaw non può farlo con nessuno dei due protocolli Anthropic, perché nessuna delle due voci di catalogo imposta il flag fetch. Usa curl contro la /v1/models del gateway stesso, oppure indirizza temporaneamente lo stesso gateway al protocollo openai. Model not found across providers illustra questo metodo, mentre Anthropic 404 model not found tratta i casi in cui il problema è l'id stesso.
6. Cambia protocollo solo ora, e solo se il passaggio 4 ha indicato un 404 della route. Se il blocco è l'header di autenticazione anziché il formato wire, auth token versus api key spiega la differenza.
7. Verifica nuovamente con un ciclo di strumenti, non con un semplice turno di chat. Una configurazione che risponde a un messaggio semplice può comunque fallire alla prima chiamata dello strumento, quindi il task delimitato che usi per confermare la correzione dovrebbe includerne una.

Il costo della scelta del protocollo

La conseguenza di costo maggiore riguarda il caching dei prompt, ed è strutturale, non un'impostazione. In PicoClaw v0.3.1 l'unico codice che emette un punto di interruzione della cache si trova in pkg/providers/anthropic/provider.go, raggiunto solo nei percorsi OAuth e token. Con una chiave API — il normale caso di utilizzo della propria chiave — nessuno dei due protocolli Anthropic invia cache_control. Rispetto al livello di compatibilità di Anthropic, questo si somma al fatto che la relativa documentazione dichiara chiaramente: "Prompt caching is not supported, but it is supported in the Anthropic SDKs". Rispetto a un gateway che inserisce punti di interruzione per i chiamanti in formato OpenAI, il risparmio viene invece recuperato dal gateway; la documentazione sul caching di Kunavo afferma che lo fa e ne delimita precisamente l'ambito: modelli Claude raggiunti tramite /v1/chat/completions o /v1/responses. La stessa pagina afferma che cache_control passa senza traduzione sulla route Messages nativa — quindi la voce anthropic-messages non riceve punti di interruzione da nessuno dei due lati, e la seconda colonna qui sotto descrive solo la voce con protocollo openai. Non è stato verificato se altri gateway inseriscano punti di interruzione, e nulla di tutto questo è stato osservato dall'interno di PicoClaw.

Il valore indicato è un calcolo illustrativo dei token, non un costo misurato dell'attività né un limite massimo di fatturazione. Supponiamo un turno dell'agente di 10 round di strumenti, in cui ogni round reinvia lo stesso prefisso di 20.000 token (prompt di sistema, schemi degli strumenti, trascrizione fino a quel momento), aggiunge 1.000 nuovi token di input e restituisce 600 token di output. Questi rapporti sono ipotesi a scopo illustrativo. La prima colonna fattura l'input di ogni round alla tariffa completa; la seconda fattura il prefisso ripetuto alla tariffa di lettura dalla cache a partire dal secondo round. Le tariffe sono i prezzi aggiornati del catalogo Kunavo per milione di token.

In base a queste ipotesi, Claude Sonnet 4.6 passa da $0,504 a $0,164 per lo stesso lavoro. Considera la seconda colonna ottimistica: le scritture nella cache vengono fatturate alla propria tariffa e non sono modellate in nessuna delle due direzioni, mentre un prefisso che cambia a ogni round non diventa mai un riscontro nella cache. Moltiplica per i turni giornalieri prima di considerare uno di questi valori come un budget.

Nel frattempo, tieni separate le due fatture. PicoClaw è gratuito — il repository è distribuito con licenza MIT e nessun protocollo, inclusi entrambi quelli di Anthropic, è soggetto all'acquisto di alcunché. Il costo ricorrente riguarda i token del modello, alla tariffa del tuo provider. L'importo del catalogo Kunavo è un minimo di fatturazione, non un tetto massimo: quando il fornitore upstream segnala il proprio addebito, la fattura è il maggiore tra il costo del catalogo e il costo upstream moltiplicato per il markup applicabile. La ricarica minima è $10 di credito prepagato, un minimo di finanziamento e non una tariffa per attività o un abbonamento — consulta i dettagli sulla fatturazione.

Provider diretto, gateway, abbonamento o locale

Stai scegliendo il runtime anziché il percorso? PicoClaw vs OpenClaw confronta i due per modalità di distribuzione. Se approdi a un gateway e vuoi finanziare una chiave, crea un account Kunavo, quindi invia un'attività circoscritta che includa una chiamata a uno strumento e leggi l'addebito effettivamente registrato dal tuo account.

Domande frequenti

Verificato il 21 settembre 2026. Riverificato in questa attività al tag v0.3.1: la nota sul protocollo e la riga del provider Anthropic nella guida dei provider, il ramo anthropic e il ramo predefinito di factory_provider.go, NormalizeBaseURL, l'URL anthropic-messages, gli header e la stringa 404, la concatenazione dell'URL e l'header Bearer di openai_compat, le tre stringhe "not found in model_list" precedenti all'HTTP, il 404 del backend web, l'unica occorrenza della sostituzione da punto a trattino, la colonna SupportsFetch della tabella delle opzioni dei provider e l'esempio OpenRouter in docs/operations/troubleshooting.md; oltre all'API delle release (v0.3.1, pubblicata il 3 luglio 2026) e ai titoli, stati, date e commenti delle issue #1624, #958 e #269. La pagina sulla compatibilità con OpenAI SDK di Anthropic è stata letta lo stesso giorno. Eseguito il 1° ottobre 2026: il binario della release v0.3.1 in un container contro un endpoint di registrazione locale e, con una chiave non valida, contro Kunavo — ogni riga della tabella sopra. Non verificato: qualsiasi elemento di main oltre ai file esaminati dal diff della ricerca, cosa abbia chiuso la issue #269, i percorsi OAuth e token e qualsiasi richiesta completata tramite Kunavo. Le tariffe dei token Kunavo provengono dal catalogo aggiornato e ogni cifra in dollari qui riportata è un calcolo illustrativo dei token.