PicoClaw model not found 404: Modell-IDs und Anthropic-Protokolle

In PicoClaw sind „model not found“ und ein 404 vier verschiedene Fehler, und nur einer davon tritt außerhalb Ihres Rechners auf. Drei sind lokal — ein nicht aufgelöster Alias, eine 404-Antwort von PicoClaws eigenem Web-Backend und eine unbekannte Protokollzeichenfolge —, der vierte ist ein Upstream-404, dessen Body Ihnen mitteilt, ob die Route falsch war oder die Modell-ID. Wenn Sie zuerst den Fehlertext lesen, tauschen Sie nicht die Protokolle aus, um einen Tippfehler zu beheben.

Diese Seite setzt voraus, dass Sie bereits einen funktionierenden model_list-Eintrag und einen Schlüssel haben; die Einrichtung selbst und die Kosten von PicoClaw werden unter PicoClaw-Preise und API-Einrichtung behandelt. Alles Folgende wurde am veröffentlichten Tag v0.3.1 gelesen, den die Releases-API am 21. September 2026 als aktuellsten bestätigte, veröffentlicht am 3. Juli 2026. Das Repository wurde zuletzt am 17. September 2026 gepusht, daher ist main weiter als der Tag — wo das relevant ist, wird es erwähnt. Am 1. Oktober 2026 war v0.3.1 weiterhin das neueste Release; anschließend wurde dessen Release-Binärdatei gegen einen lokalen Aufzeichnungs-Endpunkt und mit einem absichtlich ungültigen Schlüssel gegen Kunavo ausgeführt. Was dabei gezeigt wurde, ist unten festgehalten.

Vier Fehler, eine Formulierung

Ob die Anfrage Ihr Gerät verlassen hat, muss daher als Erstes geklärt werden, und allein die Zeichenfolge entscheidet darüber. Eine Alias-Abweichung ist ein dokumentierter Fall, keine Hypothese: Das PicoClaw-Issue #958 meldet error creating provider: model "llama3.2" not found in model_list, während picoclaw status den Ollama-Endpunkt als erreichbar und das Modell als llama3.2:latest vorhanden ausweist. Es wurde am 25. März 2026 vom Bot des Repositorys für veraltete Issues geschlossen. Beachten Sie, dass ein geschlossenes Issue mit der Markierung completed in diesem Repository nicht bedeutet, dass der Fehler behoben ist — derselbe Bot schloss #1624 mit derselben Formulierung.

Der Wrapper-Text nennt das tatsächlich verwendete Protokoll

Da anthropic mit einem API-Schlüssel und anthropic-messages unterschiedliche Provider erstellen, unterscheiden sich ihre 404-Wrapper — dadurch wird die Fehlermeldung zu einer kostenlosen Diagnosehilfe.

Warum PicoClaws eigener 404-Hinweis Sie in die falsche Richtung schicken kann

PicoClaws Provider-Leitfaden weist Sie an, zu anthropic-messages zu wechseln, wenn „das bestehende anthropic-Protokoll 404-Fehler zurückgibt (was bedeutet, dass der Endpunkt das OpenAI-kompatible Format nicht unterstützt)“, und ergänzt den Hinweis, der die Benennung klärt: „Das anthropic-Protokoll verwendet das OpenAI-kompatible Format (/v1/chat/completions), während anthropic-messages das native Format von Anthropic verwendet (/v1/messages).“ Beide Zitate wurden am 21. September 2026 unter v0.3.1 erneut gelesen.

Dieser Hinweis ist bei einem 404 der Route richtig und bei einem 404 des Modells falsch. Außerdem steht er in derselben Datei 294 Zeilen unterhalb einer Tabelle, deren Spalte Protocol für die Zeile anthropic den Wert Anthropic enthält, also das Gegenteil aussagt. Der Code löst den Widerspruch auf unerwartete Weise: anthropic ist abhängig von auth_method zwei Protokolle. Mit oauth oder token erstellt er den nativen Anthropic-SDK-Provider, und die Tabelle ist richtig; mit einem API-Schlüssel fällt er auf denselben OpenAI-kompatiblen Provider zurück, den openai und die gesamte zugehörige Familie verwenden, und der Hinweis ist richtig.

Daraus folgen unmittelbar zwei Konsequenzen. Bei der openai-Familie führt das Schreiben von https://api.kunavo.com statt https://api.kunavo.com/v1 zu https://api.kunavo.com/chat/completions — einem durch die eigene Konfiguration verursachten Routen-404, dem häufigsten Fall. Bei beiden Anthropic-Protokollen ist dieser Fehler unmöglich, weil /v1 in jedem Fall erzwungen wird; dieselbe Erzwingung bedeutet jedoch, dass ein Gateway, dessen Pfad nicht mit /v1 enden darf, darüber überhaupt nicht ausgedrückt werden kann und stattdessen das openai-Protokoll verwenden muss. PicoClaws eigene Dokumentation nutzt diesen Ausweg für einen Anbieter, dessen Basis mit einem anderen Versionssegment endet.

Eine Aussage ist als ungeklärt zu behandeln. Der einzige Kommentar zum PicoClaw-Issue #269 behauptet, dass ein POST an /v1/chat/completions bei Anthropic 404 zurückgibt, weil der korrekte Endpunkt /v1/messages sei. Anthropic widerspricht dem in der eigenen Dokumentation: Dort wird eine Kompatibilitätsschicht für das OpenAI-SDK mit base_url https://api.anthropic.com/v1/ veröffentlicht, und der Header authorization als „Fully supported“ gekennzeichnet (geprüft am 21. September 2026); zugleich wird auf derselben Seite darauf hingewiesen, dass die Schicht „für die meisten Anwendungsfälle nicht als langfristig oder produktionsbereit gilt“. Issue #269 wurde am 13. März 2026 ohne abschließenden Kommentar geschlossen — die Issues-API zeigt einen Kommentar, die obige Analyse, von einem Konto ohne Repository-Zuordnung — daher ist unbekannt, was es tatsächlich gelöst hat. Vertrauen Sie auf den eigenen 404-Body statt auf eines der beiden Konten.

Wenn der 404 die Modell-ID betrifft

Das PicoClaw-Issue #1624 — eröffnet am 16. März 2026, geschlossen am 31. März 2026 — dokumentiert den exakten Body für eine punktierte Claude-ID, die als "model": "anthropic/claude-sonnet-4.6" konfiguriert ist: Status: 404 mit {"error":{"code":"not_found_error","message":"model: claude-sonnet-4.6 was not found. Did you mean claude-sonnet-4-6?"…. Titel und einziger Kommentar wurden am 21. September 2026 erneut aus der Issues-API gelesen: Der Kommentar stammt vom Bot für veraltete Issues, daher ist das Issue geschlossen, aber es gibt keinen Beleg für eine Fehlerbehebung.

Ein Hinweis „did you mean“ ist aufschlussreich. Er kommt nur von einem Endpunkt zurück, der die Anfrage geparst hat; die Route funktioniert also, und ein Protokollwechsel hilft nicht. Der Grund, warum PicoClaw die Schreibweise nicht für Sie korrigiert, ist eng begrenzt und überprüfbar: strings.ReplaceAll(model, ".", "-") kommt im Repository einmal vor, in pkg/providers/anthropic/provider.go in Zeile 219 — dem SDK-Provider, der auf den OAuth- und Token-Pfaden verwendet wird. Weder anthropic_messages/provider.go noch openai_compat/provider.go enthält es. Beide Aussagen wurden am 21. September 2026 unter v0.3.1 erneut geprüft, und die dieser Seite vorausgegangene Recherche lud am selben Tag dieselben Dateien erneut von main herunter, mit demselben Ergebnis. Die Ausführung der v0.3.1-Binärdatei am 1. Oktober 2026 bestätigte dies auf beiden API-Schlüssel-Pfaden: Die punktierte ID erreichte den Endpunkt exakt wie geschrieben und kam als eigener 404 des Endpunkts zurück (siehe was die Ausführung von v0.3.1 zeigte). Der OAuth- und Token-Pfad, der einzige mit der Umschreibung, wurde nicht ausgeführt.

PicoClaws eigene Dateien widersprechen sich ebenfalls bei der Schreibweise: provider_metadata.go führt für beide Anthropic-Einträge IDs mit Bindestrichen auf, das Beispiel anthropic im Provider-Leitfaden verwendet eine punktierte ID, und anthropic-messages liefert aus GetDefaultModel einen punktierten Standardwert — dieselbe Schreibweise, die #1624 als abgelehnt zeigt. Jede auf der Anthropic-Modellübersicht ausgegebene Claude-API-ID verwendet Bindestriche, und die Seite führt Claude Sonnet 4.6 und Claude Opus 4.6 unter „Legacy models (still available)“ auf — eine Ausmusterung ist daher nicht der Grund, aus dem eine 4.6-ID heute bei Anthropic einen 404 liefern würde. Das schließt eine Ursache aus, nicht alle: Eine ID mit Bindestrichen kann weiterhin von einem Gateway abgelehnt werden, das das Modell nicht führt. Kopieren Sie die ID von dem Endpunkt, den Sie aufrufen, nicht aus einer README-Datei.

Schreiben Sie beide Einträge ausdrücklich und behalten Sie die ID mit Bindestrichen bei. Schlüssel gehören nicht in diese Datei — PicoClaw liest sie aus ~/.picoclaw/.security.yml, das im Einrichtungsleitfaden behandelt wird.

{
  "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"
    }
  ]
}

Der erste Eintrag liefert /v1 selbst, weil die OpenAI-kompatible Familie /chat/completions wörtlich an api_base anhängt. Der zweite lässt es absichtlich weg, um zu zeigen, dass bei anthropic-messages beide Schreibweisen zur selben Basis normalisiert werden. Kunavos veröffentlichte Basis-URL ist https://api.kunavo.com/v1 für Chat-Completions und https://api.kunavo.com/v1/messages für die Messages-Route. Dass die beiden Mengen von URL-Berechnungen zusammenpassen, ist eine arithmetische Übereinstimmung zweier Dokumentationsmengen — und am 1. Oktober 2026 wurden beide Einträge unter v0.3.1 mit einem absichtlich ungültigen Schlüssel gegen Kunavo ausgeführt: Der Eintrag openai erreichte /v1/chat/completions und der Eintrag anthropic-messages erreichte /v1/messages, worauf beide Kunavos 401 zurückgaben. Das beweist die URLs, keine abgeschlossene Anfrage: Nirgends auf dieser Seite wird eine getestete Integration behauptet. Zur allgemeinen Form der Frage nach der Basis-URL siehe die Dokumentation zur Anthropic-Basis-URL.

Ein Gateway kann absichtlich ebenfalls 404 zurückgeben, und das ist kein PicoClaw-Fehler. Kunavo gibt für ein vorübergehend pausiertes Modell 404 zurück, mit einem Body, der das Modell und den stattdessen zu verwendenden Ersatz nennt, und lässt pausierte Modelle aus /v1/models weg; orientieren Sie sich an der Struktur dieser Nachricht statt an einem bestimmten Namen, da sich die pausierten Modelle ändern. Kunavo stellt außerdem kein Embedding-, Text-to-Speech- oder Speech-to-Text-Modell bereit; daher liefert ein model_list-Eintrag, der eines davon nennt, unabhängig vom gewählten Protokoll 404 — verweisen Sie diese Einträge auf einen anderen Provider und belassen Sie auf einem Kunavo-Schlüssel nur Chat-Einträge.

Was die Ausführung von v0.3.1 zeigte

Am 1. Oktober 2026 wurde die Release-Binärdatei v0.3.1, deren Prüfsumme anhand der eigenen Prüfsummendatei des Releases verifiziert worden war, in einem Wegwerf-Container ausgeführt, jeweils mit einem model_list-Eintrag und picoclaw agent -m. Der Endpunkt war ein lokaler Aufzeichnungsserver, der sich zu diesem Zeitpunkt wie Kunavos Routing verhielt — /v1/* ist die API, jeder andere Pfad gab eine HTML-404-Seite zurück (Kunavo beantwortet diese Pfade inzwischen mit einem JSON-404, der die Korrektur nennt; siehe die Kunavo-Zeilen) — und claude-sonnet-5 sowie claude-sonnet-4-6 kannte, aber nicht die punktierte ID; die letzten drei Zeilen verwendeten das echte api.kunavo.com mit einem absichtlich ungültigen Schlüssel, sodass dort nichts abgerechnet wurde.

Diese Ausführung klärt zwei Dinge, die die Quellcodelektüre nur vorhersagen konnte. Der Fehler-Wrapper nennt tatsächlich den verwendeten Provider, daher kann man das Protokoll sicher daraus ablesen; außerdem wird eine punktierte ID auf beiden API-Schlüssel-Pfaden unverändert gesendet, sodass ein „model not found“, das eine punktierte ID zitiert, durch eine andere Schreibweise der ID behoben wird, nicht durch einen Protokollwechsel. Nicht abgedeckt sind: die OAuth- und Token-Pfade, die Weboberfläche des Launchers, Streaming und jede über Kunavo abgeschlossene Anfrage — die Kunavo-Zeilen verwendeten absichtlich einen ungültigen Schlüssel.

Die kürzeste Prüfungsreihenfolge

1. Hat irgendetwas das Gerät verlassen? Ein Terminalfehler mit not found in model_list ohne HTTP-Status ist lokal. Setzen Sie agents.defaults.model_name auf denselben Wert wie einen model_name-Eintrag und beenden Sie die Prüfung dort.
2. Kam es von localhost? Ein 404 im Browser beim Auswählen eines Standardmodells in PicoClaws Weboberfläche ist dieselbe Abweichung, ausgeliefert von PicoClaws eigenem Backend. Keine Modell-API war beteiligt.
3. Welcher Provider wurde ausgeführt? Vergleichen Sie den Wrapper-Text mit der obigen Tabelle. Wenn der Wrapper nicht zu dem Protokoll passt, das Sie konfiguriert zu haben glauben, entspricht das Feld provider oder das Modellpräfix nicht Ihrer Annahme.
4. Routen-404 oder Modell-404? Ein Body, der Ihr Modell nennt — insbesondere mit einem did you mean-Hinweis — ist ein Modell-404: Korrigieren Sie die ID. Eine HTML-Seite, ein leerer Body oder ein allgemeiner „not found“-Fehler ist ein Routen-404: Leiten Sie die zusammengesetzte URL anhand der Tabelle erneut her, bevor Sie etwas anderes ändern.
5. Fragen Sie den Endpunkt, was er bereitstellt. PicoClaw kann dies bei keinem der beiden Anthropic-Protokolle tun, weil kein Katalogeintrag das Abruf-Flag setzt. Verwenden Sie curl gegen den eigenen /v1/models des Gateways oder richten Sie dasselbe Gateway vorübergehend auf das openai-Protokoll. Model not found across providers behandelt diese Methode, und Anthropic 404 model not found behandelt die Fälle, in denen die ID selbst das Problem ist.
6. Wechseln Sie erst jetzt das Protokoll, und nur wenn Schritt 4 einen Routen-404 ergeben hat. Wenn der Authentifizierungs-Header statt des Übertragungsformats das Hindernis ist, erklärt Authentifizierungstoken im Vergleich zum API-Schlüssel die Unterscheidung.
7. Überprüfen Sie erneut mit einer Tool-Runde, nicht mit einer einfachen Chat-Runde. Eine Konfiguration, die auf eine bloße Nachricht antwortet, kann beim ersten Tool-Aufruf weiterhin scheitern; die begrenzte Aufgabe zur Bestätigung der Korrektur sollte daher einen solchen Aufruf enthalten.

Was die Wahl des Protokolls kostet

Die größte Kostenfolge betrifft Prompt-Caching und ist struktureller Natur, keine Einstellung. In PicoClaw v0.3.1 befindet sich der einzige Code, der einen Cache-Breakpoint ausgibt, in pkg/providers/anthropic/provider.go und wird nur auf den OAuth- und Token-Pfaden erreicht. Mit einem API-Schlüssel — dem gewöhnlichen Fall, bei dem Sie Ihren eigenen Schlüssel verwenden — sendet keines der beiden Anthropic-Protokolle cache_control. Gegen Anthronics eigene Kompatibilitätsschicht verstärkt sich das, denn deren Dokumentation erklärt ausdrücklich: „Prompt caching is not supported, but it is supported in the Anthropic SDKs“. Gegen ein Gateway, das Breakpoints für Aufrufer im OpenAI-Format einfügt, wird die Einsparung stattdessen am Gateway wiederhergestellt; Kunavos Caching-Dokumentation sagt, dass dies geschieht, und grenzt es genau ein: Claude-Modelle, die über /v1/chat/completions oder /v1/responses erreicht werden. Auf derselben Seite steht, dass cache_control auf der nativen Messages-Route unverändert durchgereicht wird — daher erhält der anthropic-messages-Eintrag von keiner Seite Breakpoints, und die zweite Spalte unten beschreibt ausschließlich den openai-Protokolleintrag. Ob andere Gateways Breakpoints einfügen, wurde nicht geprüft, und nichts davon wurde innerhalb von PicoClaw beobachtet.

Der Wert ist eine illustrative Token-Arithmetik, keine gemessene Aufgabenkosten und keine Abrechnungsobergrenze. Nehmen wir eine Agentenrunde mit 10 Tool-Runden an, wobei jede Runde dasselbe 20,000-Token-Präfix erneut sendet (System-Prompt, Tool-Schemas, bisheriges Transkript), 1,000 neue Eingabe-Tokens hinzufügt und 600 Ausgabe-Tokens zurückgibt. Diese Verhältnisse sind Annahmen zur Veranschaulichung. Die erste Spalte berechnet die Eingabe jeder Runde zum vollen Satz; die zweite berechnet das wiederholte Präfix ab Runde zwei zum Cache-Lese-Satz. Die Sätze sind aktuelle Preise des Kunavo-Katalogs pro Million Tokens.

Unter diesen Annahmen sinkt Claude Sonnet 4.6 für dieselbe Arbeit von $0.504 auf $0.164. Lesen Sie die zweite Spalte als optimistisch: Cache-Schreibvorgänge werden zu ihrem eigenen Satz abgerechnet und in keiner Richtung modelliert; ein Präfix, das sich in jeder Runde ändert, wird überhaupt nie zu einem Cache-Treffer. Skalieren Sie nach den Runden pro Tag, bevor Sie daraus irgendein Budget ableiten.

Trennen Sie dabei die beiden Abrechnungen. PicoClaw selbst ist kostenlos — das Repository steht unter der MIT-Lizenz, und kein Protokoll, auch keines der beiden Anthropic-Protokolle, ist an einen Kauf gebunden. Die wiederkehrenden Kosten sind Modell-Tokens zum Satz Ihres Providers. Kunavos Katalogbetrag ist eine Abrechnungsuntergrenze, keine Obergrenze: Wenn der Upstream seine Kosten meldet, ist die Abrechnung der höhere Wert aus den Katalogkosten und den Upstream-Kosten multipliziert mit dem anwendbaren Aufschlag. Die minimale Aufladung beträgt $10 als Prepaid-Guthaben, eine Mindestfinanzierung und weder eine Aufgaben- noch eine Abonnementgebühr — siehe Abrechnungsdetails.

Direkter Anbieter, Gateway, Abonnement oder lokal

Wählen Sie die Laufzeit statt der Route? PicoClaw vs OpenClaw vergleicht beide hinsichtlich ihrer Bereitstellungsform. Wenn Sie bei einem Gateway landen und einen Schlüssel finanzieren möchten, erstellen Sie ein Kunavo-Konto, senden Sie anschließend eine begrenzte Aufgabe mit einem Tool-Aufruf und lesen Sie die tatsächlich von Ihrem Konto aufgezeichnete Belastung ab.

Häufig gestellte Fragen

Geprüft am 21. September 2026. In dieser Aufgabe unter Tag v0.3.1 erneut verifiziert: der Protokollhinweis und die Anthropic-Anbieterzeile im Provider-Leitfaden, der Zweig anthropic und der Standardzweig von factory_provider.go, NormalizeBaseURL, die anthropic-messages-URL, Header und 404-Zeichenfolge, die URL-Verkettung und der Bearer-Header von openai_compat, die drei „not found in model_list“-Zeichenfolgen vor HTTP, der 404 des Web-Backends, das einzige Vorkommen der Punkt-zu-Bindestrich-Ersetzung, die Spalte SupportsFetch der Provider-Optionstabelle und das OpenRouter-Beispiel in docs/operations/troubleshooting.md; außerdem die Releases-API (v0.3.1, veröffentlicht am 3. Juli 2026) sowie Titel, Status, Daten und Kommentare der Issues #1624, #958 und #269. Anthronics OpenAI-SDK-Kompatibilitätsseite wurde am selben Tag gelesen. Ausgeführt am 1. Oktober 2026: die v0.3.1-Release-Binärdatei in einem Container gegen einen lokalen Aufzeichnungsendpunkt und mit einem ungültigen Schlüssel gegen Kunavo — jede Zeile der obigen Tabelle. Nicht verifiziert: irgendetwas auf main über die von der Recherche verglichenen Dateien hinaus, was Issue #269 geschlossen hat, die OAuth- und Token-Pfade sowie jede über Kunavo abgeschlossene Anfrage. Kunavos Token-Sätze stammen aus dem aktuellen Katalog, und jeder Dollarbetrag hier ist illustrative Token-Arithmetik.