Model Not Found: API-Fehler diagnostizieren und beheben

Was vor einer Konfigurationsänderung gespeichert werden sollte

Erstellen Sie zuerst eine kleine Diagnosekarte:

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, vollständiger Prompt und Antwort gehören nicht in diese Karte. Trat der Fehler in IDE oder Agent-Tool auf, notieren Sie außerdem Konfigurationsdatei und vorhandene Umgebungsvariablen. So erkennen Sie, welcher Wert tatsächlich an den Server ging.

Möchten Sie die Diagnose mit dem aktuellen Modellkatalog wiederholen? Erstellen Sie Ihr eigenes BetterToken-Konto und einen API Key, prüfen Sie Endpoint und Model ID anhand der API-Referenz, und führen Sie dann eine minimale Anfrage aus. Bei BetterToken müssen Endpoint-Typ, Base URL, Key-Gruppe und aktuelle Model ID zusammenpassen. Den aktuellen Namen entnehmen Sie der Dokumentation oder der Seite für Modelle und Preise; das Ergebnis prüfen Sie im Dashboard.

Schritt 1: Base URL und Pfad prüfen

Prüfen Sie die endgültige Request-URL, nicht nur die Zeile in den Einstellungen. Das SDK kann selbstständig /v1, /models, /chat/completions, /responses oder /messages ergänzen.

Typische Fehler:

• Die Base URL enthält bereits den Ressourcenpfad und das SDK hängt ihn ein zweites Mal an.
• /v1 fehlt oder ist doppelt vorhanden.
• Ein OpenAI-Client sendet an eine Anthropic-kompatible Adresse.
• Eine Umgebungsvariable überschreibt die Base URL aus der Konfiguration.
• Die Anwendung verwendet ein anderes Profil oder Workspace.

Für BetterToken OpenAI-compatible verwenden Tools eine Base URL mit /v1; Anthropic SDK und Claude Code verwenden eine Adresse ohne /v1, der vollständige Messages-Pfad entsteht getrennt. Prüfen Sie vor der Korrektur die aktuelle Seite des jeweiligen Tools.

Schritt 2: Prüfen, welcher API Key tatsächlich verwendet wird

Dieselbe Oberfläche kann mehrere Credentials speichern. Ein Modellfehler verdeckt manchmal fehlenden Zugriff des ausgewählten Key.

Prüfen Sie:

1. Credential oder Umgebungsvariable, aus der der Client den Key liest.
2. Keine zusätzlichen Leerzeichen oder Zeilenumbrüche.
3. Zuordnung des Key zu Protokoll und Modellgruppe.
4. Ob Projektkonfiguration die globale Einstellung überschreibt.
5. Ob der Key abgelaufen oder widerrufen wurde.

Geben Sie den Key nicht mit echo, Debug-Log oder Screenshot aus. Zum Vergleichen reichen ein sicherer Profilname oder die letzten Zeichen eines Fingerprints, sofern die Oberfläche sie selbst anzeigt.

Schritt 3: Aktuelle Model ID ermitteln

Ein OpenAI-kompatibler Endpoint hat oft eine Modellliste. Eine sichere Diagnoseanfrage sieht so aus:

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

Der Befehl verwendet Umgebungsvariablen und enthält keinen echten Key im Text. Er ist nur geeignet, wenn die Endpoint-Dokumentation /models bestätigt.

Nutzen Sie bei anderem Protokoll oder Client das offizielle Verzeichnis des Providers. Kopieren Sie das Feld id, ohne Groß-/Kleinschreibung, Leerzeichen oder Suffixe zu verändern. Marketing-Modellname und API Model ID können unterschiedlich sein.

Öffnet sich die Liste, das gewünschte Modell fehlt aber, prüfen Sie Key und Katalog. Gibt schon /models einen Fehler zurück, beheben Sie zuerst Endpoint oder Autorisierung.

Schritt 4: Alias und Legacy-Einstellung finden

Die Model ID kann aus mehreren Quellen stammen:

• Projektkonfiguration;
• globale Client-Konfiguration;
• Umgebungsvariable;
• UI-Profil;
• Kommandozeilen-Flag;
• gespeicherte Sitzung;
• Routing- oder Model-Mapping-Gateway.

Die Repository-Suche findet den alten Wert:

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

Die Suche kann auch Konfigurationsdateien mit Secrets finden. Veröffentlichen Sie nicht die vollständige Ausgabe. Korrigieren Sie nur die Quelle, die der Client liest.

Die Konfigurationspriorität hängt vom Client ab. Prüfen Sie in der aktuellen Dokumentation dieses Tools die Reihenfolge von Projekt-, globaler, Umgebungs- und CLI-Konfiguration. Starten Sie danach den Client neu oder öffnen Sie eine neue Sitzung, wenn Provider-Einstellungen gecacht werden.

Schritt 5: Modellfehler vom Zugriffsfehler trennen

HTTP-Codes kompatibler APIs müssen nicht identisch sein; prüfen Sie daher auch den Error Body.

• 401: zuerst Credential und Autorisierungsformat prüfen.
• 403: Das Modell kann existieren, aber der aktuelle Key hat keinen Zugriff.
• 404: möglicher Pfad-, Endpoint- oder Model-ID-Fehler.
• 400: Der Server könnte das Feld model oder einen anderen Request-Parameter abgelehnt haben.
• 429 / 5xx: meist eine andere Kategorie; ändern Sie die Model ID nicht ohne zusätzliches Signal.

Die UI-Formulierung model not found kann eine Umschreibung des Clients sein. Suchen Sie den ursprünglichen HTTP-Status, Provider-Code und Request ID.

Minimaler Retest

Senden Sie nach der Korrektur eine kurze Anfrage ohne Streaming und Tools. Für OpenAI-compatible Chat Completions kann das Schema so aussehen:

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
  }'

Felder und Endpoint müssen zur Provider-Dokumentation passen. Übertragen Sie dieses Beispiel nicht ohne Anpassung auf Anthropic Messages.

Ein erfolgreicher Test besteht aus vier Übereinstimmungen:

• HTTP-Status bedeutet Erfolg;
• die Antwort zeigt die erwartete Model ID oder ihre dokumentierte Version;
• die Anfrage erschien im Dashboard;
• Zeit, Status und Nutzung passen zum Test.

Funktioniert die kurze Anfrage, während die IDE weiter model not found meldet, ist die Serverkonfiguration bereits korrigiert. Suchen Sie dann im Client nach Override oder Cache.

Kurze Checkliste

• Status, Provider-Code und Request ID gespeichert.
• Endgültige URL ohne doppeltes /v1 und Ressourcenpfad geprüft.
• Client verwendet das erwartete Credential.
• Model ID aus aktuellem Katalog übernommen.
• Projekt-, globale und Umgebungs-Overrides geprüft.
• Eine minimale Anfrage ohne Tools und Stream ausgeführt.
• Anfrage dem Dashboard zugeordnet.

Prüfen Sie bei BetterToken vor dem Ersetzen einer Model ID die API-Referenz und den aktuellen Modellkatalog. Das ist schneller und sicherer als die Suche nach ähnlichen Namen.

FAQ

Warum ist das Modell auf der Website sichtbar, aber die API meldet model not found?

Es kann ein anderes Protokoll, eine andere Key-Gruppe, eine veraltete Sitzung oder ein Unterschied zwischen Marketingname und API ID vorliegen. Prüfen Sie die Modellliste gezielt für das aktuelle Credential.

Hilft es, die Anfrage zu wiederholen?

Bei Tippfehler oder falschem Endpoint nicht. Korrigieren Sie zuerst die Konfiguration. Ein Retry ist nur bei einem temporären Fehler passend, wenn Status und Provider-Code ihn bestätigen.

Kann ich die Modellliste dauerhaft in der Konfiguration speichern?

Speichern Sie die gewählte ID als verwaltete Einstellung und vergleichen Sie sie von Zeit zu Zeit mit dem aktuellen Katalog. Verfügbarkeit und Aliasse können sich ändern.

Warum funktioniert curl, aber die Anwendung nicht?

Die Anwendung kann eine andere Base URL, ein anderes Credential oder eine andere Model ID lesen. Vergleichen Sie die endgültige Anfrage und prüfen Sie Projekt-Override, Umgebungsvariablen und gespeichertes Profil.

Quellen

• OpenAI Models API reference — geprüft am 22. August 2026
• Anthropic API errors — geprüft am 22. August 2026
• BetterToken API reference