FAQ

Issue 1: Stream disconnected / timeout

Error message:

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

Cause: a classic stream disconnect, usually from:

• an unstable local network (frequent Wi-Fi / cellular switching, weak signal, packet loss)
• a VPN / proxy / system proxy is on: the proxy rotates the exit IP and breaks the connection

Solution:

1. Turn off any VPN / proxy / system proxy and retry — LMU AI is a direct domestic connection and needs no VPN
2. Check that your local network is stable; switch to a more reliable network if needed

Issue 2: 429 retry error

Error message:

exceeded retry limit, last status: 429 Too Many Requests

Cause: your daily quota is used up.

Solution:

1. Open My Subscription and confirm whether the daily quota is exhausted
2. If you need more, buy a plan of a different tier, then switch to the new plan's group under API Keys in the console

Issue 3: 401 Incorrect API key

Error message:

unexpected status 401 Unauthorized: Incorrect API key provided

Cause: the request still went to OpenAI's official endpoint instead of our relay.

Solution:

1. Confirm both config.toml and auth.json were created or replaced correctly
2. Restart the IDE (VS Code / Cursor, etc.) to reload the config files
3. If you previously signed in with an official or another provider's account, sign out first, then reconfigure

Issue 4: Scripts are disabled (Windows)

Error message:

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

Solution: run the following in the terminal, then open a new terminal:

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

Issue 5: Node.js not found (Windows)

Error message: CODEX is not recognized as a cmdlet, or similar

Cause: Node.js is not installed or its PATH is broken.

Solution: reinstall Node.js 20+, then open a new terminal.

Issue 6: 503 No available accounts (env vars override the key)

Error message:

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

Cause: your ~/.zshrc (or ~/.bashrc) sets ANTHROPIC_AUTH_TOKEN / ANTHROPIC_BASE_URL / ANTHROPIC_MODEL. Once the shell starts, these variables take effect globally and override the API key configured in your IDE (Cursor, VS Code, etc.), so the request uses the wrong key.

Solution (pick one):

Option A: remove the variables from .zshrc

Open ~/.zshrc and delete these lines:

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

Then run source ~/.zshrc to apply, and restart the IDE.

Option B: move the variables to a separate file, loaded only for the Claude Code CLI

1. Create ~/.claude_env with the three lines:

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. Delete those three lines from ~/.zshrc.

3. Load them manually when starting Claude Code:

source ~/.claude_env && claude

This way the IDE uses the key from its config file and the Claude Code CLI uses the environment variables, without interfering with each other.

Issue 7: 400 Invalid signature in thinking block (switching models across groups)

Error message:

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

Cause: when Claude's Extended Thinking generates a thinking block, it attaches an encrypted signature that is tightly bound to the specific upstream account that produced it. If you switch models across groups within one conversation (e.g. from claude-sonnet-5 in a "Claude-Pro direct" group to claude-fable-5 in a "Claude-MAX high-multiplier" group), the client sends the previous history (including the signed thinking block) to the new group's upstream account. Different groups use different upstreams and cannot verify a signature issued by another, so it returns 400.

Typical triggers:

• The client supports switching models mid-conversation and carries the full prior history
• The groups before and after the switch come from different upstream accounts (e.g. "direct group" ↔ "relay / MAX high-multiplier group")

Solution (any one):

1. Start a new conversation when switching groups — carrying no old history is the simplest, most reliable fix.
2. Keep one group per conversation — if you need multi-model collaboration, switch within the same group (same upstream).
3. Strip the thinking blocks from history — if the client supports editing history, remove the thinking blocks before switching groups.

Issue 8: 400 Unknown parameter: 'tools[0].n' (tools sent to an image endpoint)

Error message:

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

Endpoints affected: /v1/images/generations, /v1/images/edits (image generation / editing).

Cause: the client put a tools array into the image request body, with an n field inside tools[0]. OpenAI's image endpoints do not accept tools (tool calls belong to the Chat / Responses endpoints; image endpoints have no such concept), so the upstream rejects it with 400.

This usually comes from a buggy client / SDK wrapper that puts the "number of images n" in the wrong place — nested into tools[0].n, or copied from a Chat request template.

Solution:

1. Remove the tools field from the request body — image generations / edits do not support tool calls; drop the field entirely.
2. To generate multiple images, put the count in the top-level n — only /v1/images/generations supports n (multiple per call); /v1/images/edits does not, so drop n there.
3. Check the client SDK version — if a wrapper builds the parameters automatically, upgrade or replace it so it does not apply a Chat template to image endpoints.

Issue 9: Do I need a VPN?

No. The LMU AI gateway is hosted inside mainland China, and api.lmuai.com can be called directly from a domestic network with no VPN, proxy, or workaround.

Conversely, a VPN or proxy that rotates the exit IP tends to cause stream disconnects (see Issue 1). A direct domestic connection gives the fastest, most stable results.

Issue 10: 401 API_KEY_REQUIRED (Codex sends no key)

Error message:

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: ...

Cause: a Codex bug — when a custom model provider uses wire_api = "responses", the request Codex sends carries no API key at all (none of Authorization, x-api-key, x-goog-api-key is sent), so the gateway finds no key and returns 401 API_KEY_REQUIRED.

Note this is different from the Incorrect API key provided in Issue 3: that one sends a key that is wrong (usually because the request went to OpenAI's official endpoint instead of the LMU AI relay), whereas this one sends no key at all.

Solution: open ~/.codex/config.toml, find your model provider section [model_providers.<ID>] (usually [model_providers.codex] if you followed this site's guide), and add requires_openai_auth = true inside it:

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

Save, reopen the terminal, and restart Codex.

Still stuck?

If a special environment still blocks you during install or setup, contact support:

• Add support on WeChat
• Reach support on Xianyu (闲鱼)

Remote-assist hours: after 2 p.m. (mornings are spent resolving complex environment setups remotely).

If you need remote help, download NetEase UU Remote first and send it to support; technical guidance and remote assistance run in the afternoon after 2 p.m.

Last updated: 2026-08-26