FAQ

Problem 1: Stream-Abbruch / Timeout

Fehlermeldung:

stream disconnected before completion: error sending request for url
(https://api.lmuai.com/responses)

Ursache: ein klassischer Stream-Abbruch, meist durch:

• ein instabiles lokales Netzwerk (häufiges Wechseln zwischen Wi-Fi / Mobilfunk, schwaches Signal, Paketverlust)
• ein aktives VPN / Proxy / Systemproxy: der Proxy wechselt die Ausgangs-IP und bricht die Verbindung ab

Lösung:

1. Schalte jedes VPN / Proxy / Systemproxy ab und versuche es erneut — LMU AI ist eine direkte Inlandsverbindung und benötigt kein VPN
2. Prüfe, ob dein lokales Netzwerk stabil ist; wechsle bei Bedarf zu einem zuverlässigeren Netzwerk

Problem 2: 429 Retry-Fehler

Fehlermeldung:

exceeded retry limit, last status: 429 Too Many Requests

Ursache: dein Tageskontingent ist aufgebraucht.

Lösung:

1. Öffne Mein Abonnement und prüfe, ob das Tageskontingent erschöpft ist
2. Wenn du mehr brauchst, kaufe einen Plan einer anderen Stufe und wechsle dann in der Konsole unter API-Schlüssel zur Gruppe des neuen Plans

Problem 3: 401 Incorrect API key

Fehlermeldung:

unexpected status 401 Unauthorized: Incorrect API key provided

Ursache: die Anfrage ging weiterhin an den offiziellen Endpunkt von OpenAI und nicht an unser Relay.

Lösung:

1. Prüfe, ob config.toml gemäß Anleitung korrekt erstellt oder ersetzt wurde
2. Starte die IDE (VS Code / Cursor usw.) neu, damit die Konfigurationsdateien neu geladen werden
3. Wenn du dich vorher mit einem offiziellen Konto oder dem Konto eines anderen Anbieters angemeldet hast, melde dich zuerst ab und konfiguriere dann neu

Problem 4: Skripte sind deaktiviert (Windows)

Fehlermeldung:

codex: cannot be loaded because running scripts is disabled on this system.

Lösung: führe Folgendes im Terminal aus und öffne dann ein neues Terminal:

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

Problem 5: Node.js nicht gefunden (Windows)

Fehlermeldung: CODEX wird nicht als Cmdlet erkannt, oder ähnlich

Ursache: Node.js ist nicht installiert oder der PATH ist fehlerhaft.

Lösung: installiere Node.js 20+ erneut und öffne dann ein neues Terminal.

Problem 6: 503 No available accounts (Umgebungsvariablen überschreiben den Schlüssel)

Fehlermeldung:

Error code: 503 - {'error': {'message': 'No available accounts: no available accounts', 'type': 'api_error'}}

Ursache: in deiner ~/.zshrc (oder ~/.bashrc) sind ANTHROPIC_AUTH_TOKEN / ANTHROPIC_BASE_URL / ANTHROPIC_MODEL gesetzt. Sobald die Shell startet, wirken diese Variablen global und überschreiben den in deiner IDE (Cursor, VS Code usw.) konfigurierten API-Schlüssel, sodass die Anfrage den falschen Schlüssel verwendet.

Lösung (eine auswählen):

Option A: die Variablen aus .zshrc entfernen

Öffne ~/.zshrc und lösche diese Zeilen:

export ANTHROPIC_AUTH_TOKEN="..."
export ANTHROPIC_BASE_URL="..."
export ANTHROPIC_MODEL="..."

Führe dann source ~/.zshrc aus, um es anzuwenden, und starte die IDE neu.

Option B: die Variablen in eine separate Datei verschieben, die nur für die Claude Code CLI geladen wird

1. Erstelle ~/.claude_env mit den drei Zeilen:

export ANTHROPIC_AUTH_TOKEN="sk-your-lmu-ai-api-key"
export ANTHROPIC_BASE_URL="https://api.lmuai.com"
export ANTHROPIC_MODEL="the-model-you-use"

2. Lösche diese drei Zeilen aus ~/.zshrc.

3. Lade sie manuell beim Start von Claude Code:

source ~/.claude_env && claude

So verwendet die IDE den Schlüssel aus ihrer Konfigurationsdatei und die Claude Code CLI die Umgebungsvariablen, ohne sich gegenseitig zu stören.

Problem 7: 400 Invalid signature in thinking block (Modellwechsel über Gruppen hinweg)

Fehlermeldung:

upstream error: 400 messages.<index>.content.<index>:
Invalid `signature` in `thinking` block

Ursache: wenn das Extended Thinking von Claude einen thinking-Block erzeugt, hängt es eine verschlüsselte Signatur an, die eng an das konkrete Upstream-Konto gebunden ist, das ihn erzeugt hat. Wenn du innerhalb einer Konversation Modelle über Gruppen hinweg wechselst (z. B. von claude-sonnet-5 in einer Gruppe „Claude-Pro direkt“ zu claude-fable-5 in einer Gruppe „Claude-MAX mit hohem Multiplikator“), sendet der Client den vorherigen Verlauf (einschließlich des signierten thinking-Blocks) an das Upstream-Konto der neuen Gruppe. Verschiedene Gruppen nutzen verschiedene Upstreams und können eine von einem anderen ausgestellte Signatur nicht verifizieren, daher kommt 400 zurück.

Typische Auslöser:

• Der Client unterstützt einen Modellwechsel mitten in der Konversation und überträgt den vollständigen vorherigen Verlauf
• Die Gruppen vor und nach dem Wechsel stammen von verschiedenen Upstream-Konten (z. B. „Direkt-Gruppe“ ↔ „Relay- / MAX-Gruppe mit hohem Multiplikator“)

Lösung (eine davon):

1. Starte beim Gruppenwechsel eine neue Konversation — keinen alten Verlauf mitzunehmen ist die einfachste und zuverlässigste Lösung.
2. Bleibe pro Konversation bei einer Gruppe — wenn du Zusammenarbeit mehrerer Modelle brauchst, wechsle innerhalb derselben Gruppe (gleicher Upstream).
3. Entferne die thinking-Blöcke aus dem Verlauf — wenn der Client das Bearbeiten des Verlaufs unterstützt, entferne die thinking-Blöcke vor dem Gruppenwechsel.

Problem 8: 400 Unknown parameter: 'tools[0].n' (tools an einen Bild-Endpunkt gesendet)

Fehlermeldung:

400 - {'error': {'code': 'unknown_parameter', 'message': "Unknown parameter: 'tools[0].n'.", 'param': 'tools[0].n', 'type': 'invalid_request_error'}}

Betroffene Endpunkte: /v1/images/generations, /v1/images/edits (Bilderzeugung / -bearbeitung).

Ursache: der Client hat ein tools-Array in den Body der Bildanfrage gelegt, mit einem n-Feld innerhalb von tools[0]. Die Bild-Endpunkte von OpenAI akzeptieren kein tools (Tool-Aufrufe gehören zu den Chat- / Responses-Endpunkten; Bild-Endpunkte kennen dieses Konzept nicht), daher lehnt der Upstream die Anfrage mit 400 ab.

Das kommt meist von einem fehlerhaften Client- / SDK-Wrapper, der die „Anzahl der Bilder n“ an der falschen Stelle ablegt — verschachtelt in tools[0].n oder aus einer Chat-Anfragevorlage kopiert.

Lösung:

1. Entferne das tools-Feld aus dem Anfrage-Body — generations / edits für Bilder unterstützen keine Tool-Aufrufe; lass das Feld vollständig weg.
2. Um mehrere Bilder zu erzeugen, gib die Anzahl im übergeordneten n an — nur /v1/images/generations unterstützt n (mehrere pro Aufruf); /v1/images/edits nicht, lass n dort also weg.
3. Prüfe die Version des Client-SDK — wenn ein Wrapper die Parameter automatisch zusammenbaut, aktualisiere oder ersetze ihn, damit er keine Chat-Vorlage auf Bild-Endpunkte anwendet.

Problem 9: Brauche ich ein VPN?

Nein. Das LMU AI Gateway wird im chinesischen Festland gehostet, und api.lmuai.com kann aus einem inländischen Netzwerk direkt aufgerufen werden — ohne VPN, Proxy oder Umwege.

Umgekehrt führt ein VPN oder Proxy, der die Ausgangs-IP wechselt, eher zu Stream-Abbrüchen (siehe Problem 1). Eine direkte Inlandsverbindung liefert die schnellsten, stabilsten Ergebnisse.

Problem 10: 401 API_KEY_REQUIRED (Codex sendet keinen Schlüssel)

Fehlermeldung:

unexpected status 401 Unauthorized: {"code":"API_KEY_REQUIRED","message":"API key is required in Authorization header (Bearer scheme), x-api-key header, or x-goog-api-key header"}, url: https://api.lmuai.com/responses, request id: ...

Ursache: neuere Codex-Versionen haben die Authentifizierung geändert — Zugangsdaten werden nun möglicherweise im System-Keyring gespeichert, statt aus auth.json gelesen zu werden. Mit der Einrichtung der alten Anleitung (auth.json + requires_openai_auth = true) enthält die von Codex gesendete Anfrage dann überhaupt keinen API-Schlüssel (weder Authorization noch x-api-key noch x-goog-api-key wird gesendet), sodass das Gateway keinen Schlüssel findet und 401 API_KEY_REQUIRED zurückgibt.

Beachte, dass dies anders ist als das Incorrect API key provided in Problem 3: dort wird ein falscher Schlüssel gesendet (meist weil die Anfrage an den offiziellen Endpunkt von OpenAI statt an das LMU AI Relay ging), hier wird gar kein Schlüssel gesendet.

Lösung: lege den Schlüssel direkt in einen Request-Header. Öffne ~/.codex/config.toml (unter Windows C:\users\your-username\.codex\config.toml), suche den Abschnitt deines Model Providers [model_providers.<ID>] (meist [model_providers.codex], wenn du der Anleitung dieser Seite gefolgt bist), lösche darin die Zeile requires_openai_auth = true und füge die passende http_headers-Untertabelle ganz am Ende der Datei hinzu:

[model_providers.codex]
name = "codex"
base_url = "https://api.lmuai.com"
wire_api = "responses"

[model_providers.codex.http_headers]
Authorization = "Bearer your sk- key generated in the console"

Speichere, öffne das Terminal neu und starte Codex neu.

Alle Codex-Anleitungen auf dieser Seite (Mac / Windows / Server / Codex App / VS Code-Erweiterung) wurden auf die oben beschriebene Einrichtung aktualisiert.

Immer noch nicht gelöst?

Wenn eine besondere Umgebung dich bei der Installation oder Einrichtung weiterhin blockiert, kontaktiere den Support:

• Support auf WeChat hinzufügen
• Support über Xianyu (闲鱼) erreichen

Zeiten für Fernunterstützung: ab 14 Uhr (die Vormittage werden für die Fernlösung komplexer Umgebungseinrichtungen genutzt).

Wenn du Fernhilfe brauchst, lade zuerst NetEase UU Remote herunter und sende es an den Support; technische Beratung und Fernunterstützung finden nachmittags ab 14 Uhr statt.

Zuletzt aktualisiert: 2026-10-08

京ICP备2020034311号-7