#change from anthropic to z-ai

1 messages · Page 1 of 1 (latest)

trim zephyrBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

bright coyoteBOT
#

That error just means: your default model is set to an Anthropic model, but the Gateway can’t find any Anthropic credentials in the agent’s auth store (~/.openclaw/agents/main/agent/auth-profiles.json). Since you don’t want Anthropic, the fix is to switch the default model away from Anthropic and add creds for the provider you do want (Z.AI).

1) Quick sanity checks (paste output if it still fails)

openclaw --version
openclaw models status

2) Easiest fix: rerun onboarding and choose Z.AI

This will set up the Z.AI key and update your default model config:

openclaw onboard --auth-choice zai-api-key
# or non-interactive:
openclaw onboard --zai-api-key "$ZAI_API_KEY"

3) Manual fix (if you prefer)

#
  1. Put your Z.AI key somewhere the Gateway service will actually read it (systemd often won’t inherit your shell env):
  • add it to ~/.openclaw/.env on the gateway host, e.g.
ZAI_API_KEY=sk-...
  1. Set your default model to a Z.AI model:
openclaw models set zai/glm-5
  1. Restart:
openclaw gateway restart

4) If it still tries Anthropic

#

Check that you don’t have Anthropic in agents.defaults.model.primary or in agents.defaults.model.fallbacks. openclaw models status will show what it’s actually resolving to.

Docs that match your exact goal:

If you paste openclaw models status output, I can tell you exactly why it’s still selecting anthropic/* (primary vs fallback vs alias).

#

If you’re not sure, pick Global (api.z.ai).

Here’s how to choose:

  • Global (Z.AI Global / api.z.ai) → best default for most people (outside mainland China).
  • CN → only if you’re in mainland China (or your key/account is region-locked to CN).
  • Coding-Plan-Global / Coding-Plan-CN → only if your Z.AI account/key is specifically for the GLM “Coding Plan” endpoints. If you don’t know what that is, you probably don’t want these.

If you pick the “wrong” one, you’ll usually see auth/region errors quickly, and you can just rerun onboarding and choose a different endpoint.

Docs reference (mentions these exact choices): https://docs.openclaw.ai/cli/onboard (and provider overview: https://docs.openclaw.ai/providers/zai)

If you tell me (1) what country your VPS is in and (2) where you are, I’ll tell you the best pick.

#

Global is the right pick for AWS + Germany (api.z.ai).

On the new thing: that TUI screen isn’t necessarily an error — connected | idle + an empty chat log usually just means the agent hasn’t run yet (no message sent/received in that session).

Quick checks in the TUI

  1. Type hello and press Enter (seriously).
  2. Run:
  • /status (shows what the Gateway thinks is going on)
  • /help (sanity check the UI is responsive)

If you’re expecting replies to go out to a real chat channel (Discord/Telegram/etc), note that TUI delivery is off by default:

  • /deliver on

If you did send a message and still get no reply

On the gateway host, run these and paste the output (they’re safe; don’t paste your API key):

# 
openclaw status
openclaw models status
openclaw logs --follow

Most common cause after onboarding: the Gateway is running as a service and doesn’t have ZAI_API_KEY available (shell env ≠ systemd env). openclaw models status will show “Missing auth” if that’s the case.

Tell me: are you trying to chat inside the TUI, or are you expecting your bot to reply in Discord? That changes what we check next.

#

That exact string (401 token expired or incorrect) is usually coming from Z.AI, meaning the ZAI_API_KEY the Gateway is using is invalid or it’s valid but for a different Z.AI endpoint (e.g. Coding-Plan vs Global).

Quick clarifier: do you see the 401…

  1. when connecting the TUI / dashboard (before you even send a message), or
  2. after you send a message (model call happens, then it errors)?

If it happens after you send a message (most likely)

On the AWS box:

  1. Check what the gateway thinks about models/auth:
openclaw models status
openclaw logs --follow
  1. Make sure the key is set in a place the service actually reads (don’t paste it here):
  • Put it in ~/.openclaw/.env on the gateway host:
# 
ZAI_API_KEY=sk-...

then:

openclaw gateway restart
  1. If you suspect you picked the wrong Z.AI endpoint in onboarding: rerun onboarding and let it auto-pick the best endpoint for your key:
openclaw onboard --auth-choice zai-api-key

(If your key is for “Coding Plan”, choose Coding-Plan-Global instead.)

If it happens when connecting the TUI/dashboard

Then it’s the Gateway token (not Z.AI). Grab it on the gateway host:

# 
openclaw config get gateway.auth.token

…and use that token in the TUI (--token …) / Control UI settings. Don’t share it in Discord.

If you paste the couple log lines around the 401 from openclaw logs --follow (it’ll show whether it’s provider=zai or gateway auth), I can tell you which branch you’re on immediately.

#

Pick Telegram (Bot API) if you want to talk to your OpenClaw from your phone.

That line:

  • configured = it already found your Telegram bot config/token (or you entered it earlier)
  • plugin disabled = the Telegram connector isn’t currently turned on, so you won’t receive/send Telegram messages until it’s enabled (the QuickStart flow should enable it when you select it)

After you finish the wizard, do a quick end-to-end test on the AWS box:

openclaw channels status --probe
openclaw logs --follow

Then DM your Telegram bot. If DM pairing is on (default), approve it:

# 
openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

Don’t paste your bot token / API keys into Discord.

#

That 401 is coming from the model provider call (Z.AI), not from the TUI connection. In practice it means one of these:

  1. Your ZAI key isn’t actually being picked up by the running Gateway (common when the Gateway runs as a systemd service and your key is only in your shell), or
  2. You picked the wrong Z.AI endpoint for the kind of key you have (Coding-Plan key vs “normal” Global key), or
  3. The key is just invalid/expired.

Do this on the AWS host (don’t paste secrets):

1) Check whether OpenClaw thinks Z.AI auth is present

openclaw models status

Look for a “Missing auth” section (or anything saying ZAI creds missing).

2) Tail logs while you send “hey” again in the TUI

# 
openclaw logs --follow

We want the few lines around the 401 — it will usually say which provider/endpoint it tried.

3) The most common fix: put the key in ~/.openclaw/.env (service-safe)

Edit/create ~/.openclaw/.env on the gateway host and add:

ZAI_API_KEY=sk-...

Then:

openclaw gateway restart

4) If your key is a “Coding Plan” key

Rerun onboarding and choose Coding-Plan-Global instead of Global:

# 
openclaw onboard --auth-choice zai-coding-global

If you paste the output of openclaw models status (with keys redacted automatically) + the 2–5 log lines around the 401, I can tell you immediately which of the above it is.

#

Nice — openclaw models status shows OpenClaw is finding a Z.AI profile (api_key=1). So this is no longer “missing auth”… it’s Z.AI rejecting the key (or the endpoint/key type combo).

Next step is to confirm it with a live probe (this makes a tiny real request):

openclaw models status --probe-provider zai
  • If that probe returns 401 too: the key is invalid for that endpoint (most common causes: pasted the wrong thing, included "Bearer " prefix, key was revoked/expired, or you picked Global vs Coding-Plan-Global wrong for your account).
  • Fix: generate a fresh key in the Z.AI console and re-run onboarding:
openclaw onboard --auth-choice zai-api-key

If your account is specifically the GLM “Coding Plan”, choose:

openclaw onboard --auth-choice zai-coding-global
#
  • If the probe is OK but chats still 401: paste the few log lines around the failure from:
openclaw logs --follow

(redact secrets) — then we’ll see which Z.AI base URL/endpoint it’s hitting.

One quick gotcha: when it asks for the Z.AI key, paste only the raw sk-... value (no Bearer , no quotes, no extra whitespace).

#

Yes — that makes a big difference.

Right now you configured the direct Z.AI provider (zai/glm-5). That provider expects a Z.AI key in ZAI_API_KEY. If you paste an OpenRouter key there, Z.AI will 401 with “token expired or incorrect” (because it’s simply the wrong credential for that API).

If you want Z.AI models via OpenRouter, you must switch to:

  • Provider: openrouter
  • Env var: OPENROUTER_API_KEY
  • Model ref format: openrouter/<provider>/<model> (whatever OpenRouter calls the Z.AI/GLM model)

What to do

  1. Put your OpenRouter key where the gateway service can read it (recommended):
    ~/.openclaw/.env
OPENROUTER_API_KEY=sk-or-...
#
  1. Re-run onboarding (easiest) and choose OpenRouter:
openclaw onboard

(or the non-interactive CLI from the docs:)

openclaw onboard --auth-choice apiKey --token-provider openrouter --token "$OPENROUTER_API_KEY"

Source: https://docs.openclaw.ai/providers/openrouter

  1. Change your default model away from zai/... to an OpenRouter model, e.g.:
openclaw models set openrouter/<openrouter-model-slug>

(Grab the exact slug from OpenRouter’s model page/list; OpenClaw expects the exact OpenRouter ID.)

  1. Verify:
# 
openclaw models status --probe-provider openrouter

Once you switch the default model to openrouter/..., the Z.AI endpoint picker you saw earlier no longer matters (that picker is for the direct zai provider).

bright coyoteBOT
#

That bash error is because you literally typed the placeholder with angle brackets. In shells, <...> is input redirection, so bash chokes before openclaw even runs.

Use a real OpenRouter model id without < > (and I recommend quoting it):

openclaw models set "openrouter/<provider>/<model>"

Since your key is from OpenRouter

You must configure the openrouter provider (not zai). A direct zai/* model will always 401 with an OpenRouter key.

Easiest way (stores the key in the auth store correctly):

openclaw onboard --auth-choice apiKey --token-provider openrouter --token "$OPENROUTER_API_KEY"

Finding the exact OpenRouter model slug for Z.AI/GLM

#

Either copy it from the OpenRouter model page (it shows the model id), or use the CLI to search:

openclaw models list --all --provider openrouter --plain | rg -i "glm|zai|z-ai|z\\.ai" | head

Then set it, e.g.:

openclaw models set "openrouter/…/…"

Finally, sanity check:

openclaw models status --probe-provider openrouter

If after setting it you get “Model … is not allowed”, tell me that exact line — it means your config has an allowlist (agents.defaults.models) that needs to include the new openrouter/... model id.

#

That 402 is OpenRouter telling you you’re calling a paid model with an account that has $0 credits.

OpenRouter isn’t “free” in general — it has some free model variants, but:

  • Z.AI/GLM via OpenRouter is not free (so you need OpenRouter credits), and
  • OpenRouter’s actually-free models are typically the ones whose model id ends with :free (OpenRouter docs call this out).

What you can do:

Option A (what you want: Z.AI via OpenRouter)

You need to add credits to your OpenRouter account: https://openrouter.ai/settings/credits
Then retry. (Your API key is fine; the account balance isn’t.)

Option B (stay on OpenRouter, but use truly free models)

Pick a model that ends in :free and set that as default.

To discover them from the gateway box (no model-name guessing):

# 
openclaw models list --all --provider openrouter --plain | rg ':free' | head

Then:

openclaw models set "openrouter/…:free"

Or use the built-in “free catalog” helper:

openclaw models scan --no-probe --provider openrouter

Option C (use GLM without OpenRouter credits)

Use direct Z.AI instead (requires a real Z.AI key in ZAI_API_KEY, not an OpenRouter key).

#

Yep — rg is just ripgrep, not required. Use grep instead:

openclaw models list --all --provider openrouter --plain | grep ':free' | head

If you want a wider search (glm/zai keywords + free):

openclaw models list --all --provider openrouter --plain | grep -iE 'glm|zai|z\.ai|:free' | head -n 50

Then set one of the returned model IDs (quote it):

openclaw models set "openrouter/<exact-id-from-the-list>"
#

If grep ':free' prints nothing, it just means OpenClaw’s catalog output isn’t including the free variants in that view — in that case try the built-in scanner:

openclaw models scan --no-probe --provider openrouter

(That one is meant specifically to surface OpenRouter’s free catalog.)

#

Perfect — that means the config change stuck, and you’re now on an actual OpenRouter free-tier model ID:

openrouter/z-ai/glm-4.5-air:free

Next steps to make sure it’s actually working:

  1. Verify auth + do a tiny live probe:
openclaw models status --probe-provider openrouter
  1. If your Gateway is running as a service, restart it so everything reloads cleanly:
openclaw gateway restart
  1. In the TUI, start a fresh session (so it stops clinging to the old failed run state) and try again:
#
  • /new
  • type hey and press Enter

If you still hit limits/errors: OpenRouter “free” still has quotas (and if you’ve never bought credits, the daily :free cap is lower). Their limits doc explains it: https://openrouter.ai/docs/api/reference/limits

#

This looks basically correct now: your default model is OpenRouter (openrouter/z-ai/glm-4.5-air:free) and OpenClaw sees an OpenRouter API key in the auth store.

1) Confirm OpenRouter auth actually works (live probe)

On the AWS box:

openclaw models status --probe-provider openrouter

If that succeeds, the model should answer in the TUI.

2) Fix one foot-gun in your config: GLM -> zai/glm-5

Right now your alias GLM still points to direct Z.AI (zai/glm-5). If you ever type /model GLM, you’ll switch back to the direct Z.AI provider (and that will 401 if you don’t have a real Z.AI key).

If you want “GLM” to mean the OpenRouter one, do:

openclaw models aliases remove GLM
openclaw models aliases add GLM openrouter/z-ai/glm-4.5-air:free
#

3) Ignore/cleanup the accidental placeholder model

openrouter/<provider>/<model> showing up under “Configured models” is just from the earlier placeholder attempt. It won’t be used unless you select it, but you can remove it later if you want a clean allowlist.

4) If TUI still shows “(no output)”

Run:

openclaw logs --follow

then send hey again in the TUI. The log will show whether it’s still an OpenRouter 402/429, a routing/allowlist issue, or something else.

If you paste the probe output (and/or the few log lines around the error), I can tell you exactly what’s left.

#

error code: 520 is an upstream/provider failure (Cloudflare-style “something went wrong”), so at this point OpenClaw is talking to OpenRouter, but OpenRouter (or the routed backend for that model) is returning a bad response. It’s usually transient or model-specific.

Do this to narrow it down:

1) Capture the real error details from logs

On the AWS box:

openclaw logs --follow

Then send hey again in the TUI. Paste the few lines around the failure (it should show the provider/model and sometimes the OpenRouter response body). No secrets needed.

2) Try a live probe (fast signal)

openclaw models status --probe-provider openrouter
  • If this also 520s: OpenRouter/API path is having trouble right now (or your key is hitting a weird edge).
  • If probe succeeds but chat 520s: it’s likely that specific model route choking (payload size, temporary model outage, etc.).
#

3) Switch to a different :free model (most effective workaround)

Free routes can be flaky. Pick another :free entry and set it:

openclaw models list --all --provider openrouter --plain | grep ':free' | head -n 30
openclaw models set "openrouter/<copy-exact-id-from-the-list>"
openclaw gateway restart

4) Optional: reduce variables

In the TUI, try:

  • /new (fresh session)
  • /think off (some providers/models get weird with “thinking” style payloads)

If you paste the log snippet around the 520, I can tell you whether it’s OpenRouter itself vs the routed Z.AI backend vs a payload/parameter issue.

#

Your config/auth looks fine now — the 520 isn’t “you configured it wrong”, it’s OpenRouter (or the routed backend for that specific model) returning a bad gateway-style error.

With OpenRouter, 520 is usually model/route instability (especially on :free variants). Best next move is to switch to a different free model (or add a fallback), and/or retry later.

1) Confirm OpenRouter in general is OK (live probe)

openclaw models status --probe-provider openrouter

If this fails, it’s broader than the model.

2) Try a different z-ai free model

List OpenRouter free models that look like Z.AI/GLM (no rg needed):

openclaw models list --all --provider openrouter --plain | grep -i ':free' | grep -iE 'z-ai|z\.ai|glm' | head -n 30

Pick one exact line from that output and set it (quote it):

# 
openclaw models set "openrouter/<exact-model-id-you-copied>"
openclaw gateway restart

3) Add a fallback so you don’t brick the bot when one free route flakes

After you pick a second :free model:

openclaw models fallbacks add "openrouter/<second-free-model-id>"

4) Reduce variables in the TUI (optional but helps)

In the TUI:

  • /new
  • /think off
  • send hey again
#

If you paste the few log lines around the 520 from openclaw logs --follow (redact secrets), I can tell you whether it’s specifically that glm-4.5-air:free route dying, or something like request formatting/limits.

bright coyoteBOT
#

If you’re SSH’d into your AWS box, you can run the TUI right in that SSH terminal.

If you’re on the AWS box (SSH session)

  1. Make sure the Gateway is running (as a service or foreground):
openclaw gateway status
  1. Start the TUI:
openclaw tui

That should auto-connect to the local gateway (default ws://127.0.0.1:18789).

If the Gateway is on AWS but you want the TUI on your laptop

Run the TUI locally and point it at the AWS gateway URL + token.

#

Option A: SSH tunnel (recommended)
On your laptop:

ssh -L 18789:127.0.0.1:18789 ubuntu@<your-aws-ip>
openclaw tui --url ws://127.0.0.1:18789 --token "$(openclaw config get gateway.auth.token)"

If that token command is running on your laptop (not the AWS box), just copy the token from AWS:

# run on AWS:
openclaw config get gateway.auth.token

…and paste it into the TUI command on your laptop.

Option B: run TUI on AWS inside tmux
Handy so it stays open if your SSH drops:

# 
tmux new -s claw
openclaw tui

If you tell me whether your Gateway is bound to localhost only (common) or exposed via a public URL/Tailscale, I can give you the cleanest “TUI from laptop” command.

#

That message means the TUI can’t keep a WebSocket connection to the Gateway (either the Gateway isn’t running/reachable, or auth/url is wrong).

Run these on the AWS box and paste the output (safe to share; don’t paste tokens):

openclaw gateway status
openclaw status

Common fixes (pick the one that matches what you see)

A) Gateway isn’t running (or RPC probe failed)

If openclaw gateway status shows stopped / RPC probe: failed:

openclaw gateway restart
# 
# then
openclaw logs --follow

B) Gateway is running, but TUI is connecting to the wrong URL / missing token

Force TUI to use localhost explicitly:

  1. Get the token (do NOT paste it here):
openclaw config get gateway.auth.token
  1. Connect TUI with explicit url+token:
openclaw tui --url ws://127.0.0.1:18789 --token "<PASTE_TOKEN>"