cant use claude-cli models | Friends of the Crustacean 🦞🤝 | Page 1

wary jewelBOT Apr 4, 2026, 8:53 PM

#

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

untold sierraBOT Apr 4, 2026, 8:54 PM

#

Yep — this error is from the model ID string itself.

claude-cli/sonnet-4-6 is not a recognized key, so OpenClaw throws Unknown model.

For Claude CLI, use one of these formats instead:

claude-cli/sonnet
claude-cli/sonnet-4.6
claude-cli/claude-sonnet-4-6

Can you paste this first (version mismatch matters a lot here):

pnpm openclaw --version

Then run:

#

pnpm openclaw models list | rg claude-cli
pnpm openclaw models set claude-cli/claude-sonnet-4-6
pnpm openclaw gateway restart
pnpm openclaw models status

If you use an allowlist (agents.defaults.models), make sure that exact claude-cli/... model is included there too.

Docs:

flat geyser Apr 5, 2026, 10:12 AM

#

Same issue here — investigated root cause on OpenClaw 2026.4.2 (Docker container, Debian bookworm).

Root cause: initialization order bug.

Gateway log shows warmup runs BEFORE acpx plugin initializes:

10:05:21 warmup failed: Unknown model claude-cli/claude-opus-4-6
10:05:21 acpx runtime backend registered  ← after warmup
10:05:23 acpx runtime backend ready

claude-cli provider is registered by acpx plugin at runtime, but the static model warmup check runs before acpx is initialized → permanent "missing" state.

What we tried (all failed):

openclaw models auth login --provider anthropic --method cli --set-default ✅ config written correctly
claude auth status → loggedIn: true, oauth
claude --print "hello" → works fine standalone (sonnet-4-6, subscription auth)
cliBackends config with command path ✅
Clearing ANTHROPIC_API_KEY env
Multiple gateway restarts
auth-profile anthropic:claude-cli addition

All config is correct — the problem is purely warmup → acpx initialization order.

Env: OpenClaw 2026.4.2 (d74a122), Docker, node v22.22.2

Is there a way to make warmup fail-open and defer to runtime resolution? Or is this fixed in 4.3?

wise tartan Apr 5, 2026, 10:14 AM

#

Guys is there a way around Anthropic subscription models ban to use with openclaw ?

untold sierraBOT Apr 5, 2026, 10:17 AM

#

Nice investigation — and you’re asking the right question.

Short answer:

Warmup is already fail-open in 2026.4.2 (it warns, but should not block startup).
The acpx runtime backend registered line is not the gate for claude-cli/... model routing.
So your log ordering is real, but that sequence alone shouldn’t create a permanent failure state.

What is likely happening is runtime model resolution still missing claude-cli/... in the active catalog path on first runs (separate from warmup).

What I’d do right now

Upgrade off 2026.4.2 to latest available (or current main/nightly if you can).
As a temporary workaround, try the short CLI refs:

claude-cli/sonnet or claude-cli/opus
(and include the exact ref in agents.defaults.models too).

Re-test with:

#

pnpm openclaw models status
pnpm openclaw models list

If it still reproduces

Please file it as a GitHub issue with:

full startup logs from process start to first failing turn
pnpm openclaw --version
pnpm openclaw models status --json
sanitized agents.defaults.model + agents.defaults.models block

Issue tracker: https://github.com/openclaw/openclaw/issues
Docs: https://docs.openclaw.ai/gateway/cli-backends and https://docs.openclaw.ai/providers/anthropic

If you paste models status --json here, I can help pinpoint whether it’s catalog loading vs allowlist/model-ref normalization.

#

Short answer: no — there’s no legit/supported “workaround” to bypass Anthropic subscription restrictions in OpenClaw.

OpenClaw follows Anthropic’s policy/billing path:

use Anthropic API key auth, or
use Claude CLI with Extra Usage enabled (since the subscription-only path no longer covers OpenClaw traffic).

If you don’t want Anthropic billing, switch your default provider to another supported provider instead.

Docs:

flat geyser Apr 5, 2026, 10:21 AM

#

wise tartan Guys is there a way around Anthropic subscription models ban to use with opencla...

Me too . SO I am looking for this.

untold sierraBOT Apr 5, 2026, 10:21 AM

#

Yeah, same answer for you too: there’s no supported bypass for that.

Legit paths are:

Claude CLI + Extra Usage enabled on Anthropic
Anthropic API key auth in OpenClaw
Switch to another provider as default model provider

Quick setup path:

pnpm openclaw configure
# or
pnpm openclaw models auth add

Refs:

https://docs.openclaw.ai/providers/anthropic

#

https://docs.openclaw.ai/concepts/models

If you want current community recommendations for non-Anthropic setups, ask in #models (that changes fast).

wise tartan Apr 5, 2026, 10:26 AM

#

@flat geyser apparently its difficult to do but a workaround is to use ACP

untold sierraBOT Apr 5, 2026, 10:27 AM

#

Small correction: ACP is not a bypass/workaround for Anthropic subscription restrictions.

ACP and claude-cli/... are different runtimes, but neither can bypass Anthropic policy/billing.
If Anthropic is the backend, you still need a valid paid/auth path (API key or CLI with Extra Usage).

So the real options stay:

Anthropic via supported billing/auth, or
use another provider.

Refs:

wise tartan Apr 5, 2026, 10:28 AM

#

@untold sierra did you test it ? how can you be sure that ACP does not pass trough sub model and not extra usage ?

untold sierraBOT Apr 5, 2026, 10:28 AM

#

Fair question.

I didn’t test your specific Anthropic account from here.
What I’m basing this on is:

OpenClaw docs: ACP Claude and claude-cli/... are different runtimes, but both are still Claude-side runtimes (not a “free proxy” layer).
Anthropic note in OpenClaw docs: OpenClaw Claude CLI/harness usage is treated as third-party harness traffic with Extra Usage billing requirements.

So ACP can change runtime behavior, but it’s not a guaranteed billing bypass.

If you want hard proof for your account, do a quick A/B test:

run 1 tiny ACP prompt
check Anthropic usage/billing dashboard immediately after

If it works without extra charges for your account, that’s account entitlement behavior — not an OpenClaw bypass mechanism.

Refs:

#

flat geyser Apr 5, 2026, 11:06 AM

#

Update: partial progress.

Non-root gateway fixed the missing tag — missingProvidersInUse: [] now. However, at runtime claude-cli is still skipped and falls back to cliproxy.

defaultModel: claude-cli/opus
missingProvidersInUse: []
providersWithOAuth: ["anthropic (4)"]
Gateway process: running as non-root user "openclaw"
Runtime log: requested=cliproxy/claude-opus-4-6 (claude-cli skipped)

openclaw models status --json shows everything healthy, but the Gateway runtime never actually routes to claude-cli — it skips straight to the CLIProxy fallback.

Anyone know why the Gateway would skip a healthy claude-cli provider at runtime? Is there an additional config needed beyond agents.defaults.model.primary + cliBackends + agents.defaults.models entries?

untold sierraBOT Apr 5, 2026, 11:11 AM

#

Great datapoint — and your log snippet is actually the key:

If runtime says requested=cliproxy/..., then this turn is no longer starting from claude-cli default; it’s using a persisted session override/fallback selection.

So likely flow is:

claude-cli/... failed earlier for that session
fallback selected cliproxy/...
session kept that active model

What to do

In the same thread/session, force it back:

/model claude-cli/claude-opus-4-6 (or the exact claude-cli ref you want)

Or clear session state with /reset (or start a fresh /new session).
Re-test and capture the first fallback decision line for the claude-cli candidate (that line includes reason=...).

Also verify (common gotchas)

agents.defaults.models includes the exact claude-cli/... ref you use (allowlist mismatch can trigger fallback).

#

openclaw models status --json → check auth.unusableProfiles (cooldown/disabled reason).
For service user context, confirm Claude CLI works under the same runtime user.

Docs:

https://docs.openclaw.ai/gateway/cli-backends
https://docs.openclaw.ai/providers/anthropic (see auth cooldown/unusable profiles notes)

If you paste one model fallback decision line with reason=..., I can tell you exactly why claude-cli got skipped.

flat geyser Apr 5, 2026, 11:54 AM

#

Final update — we got it working.

Actual root cause was 3 separate issues:

Claude CLI rejects the Gateway path when running as root in Docker
agents/main/agent/models.json did not have the claude-cli provider registered at all
main agent / existing session override was still pinned to cliproxy/claude-opus-4-6

What fixed it:

Run Gateway as non-root (gosu openclaw ...)
Manually add claude-cli provider + model defs to /root/.openclaw/agents/main/agent/models.json
Change both agents.defaults.model.primary and main agent override to claude-cli/claude-opus-4-6
Start a new session (old session kept the old model override)

After that the new session switched to claude-cli/claude-opus-4-6 and subscription usage works again (no extra usage draw).

So in our case it was not only the warmup/acpx init order — that was part of the symptom, but the runtime blocker was also the missing provider registration in the per-agent models.json + root execution.

If anyone else hits this in Docker, check the per-agent files under:
~/.openclaw/agents/main/agent/
not just openclaw.json.

untold sierraBOT Apr 5, 2026, 11:54 AM

#

This is a great root-cause writeup — thank you for posting the full breakdown 🙌

Your 3-factor diagnosis (root user + missing per-agent model provider + sticky session override) is super useful for others.

One durability note: manual edits to agents/*/agent/models.json can be regenerated/overwritten later, so the persistent setup should still live in config/auth flow (agents.defaults.model, agents.defaults.models, and models auth).

If you can, please open a GitHub issue with this exact Docker repro/fix so maintainers can harden it:
https://github.com/openclaw/openclaw/issues

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

loud fiber Apr 5, 2026, 6:25 PM

#

@flat geyser Can you paste your config for the claude-cli provider? I can't find an example - I only have cliBackends for "claude-cli"

untold sierraBOT Apr 5, 2026, 6:25 PM

#

Yep — for claude-cli you usually don’t need a separate models.providers["claude-cli"] block.

cliBackends.claude-cli + model selection is enough.

{
agents: {
defaults: {
model: {
primary: "claude-cli/claude-sonnet-4-6",
// optional:
// fallbacks: ["claude-cli/claude-opus-4-6"]
},
models: {
"claude-cli/claude-sonnet-4-6": {},
// optional:

#

// "claude-cli/claude-opus-4-6": {}
},
cliBackends: {
"claude-cli": {
// optional if `claude` is already on PATH
// command: "/opt/homebrew/bin/claude"
},
},
},
},
}

Two key points:

If you use agents.defaults.models allowlist, include the exact claude-cli/... refs there.
No manual models.json editing needed in normal setup.

#

Docs with examples:

loud fiber Apr 5, 2026, 6:27 PM

#

But thor said they had to "Manually add claude-cli provider + model defs to /root/.openclaw/agents/main/agent/models.json"

untold sierraBOT Apr 5, 2026, 6:27 PM

#

Yep — that was a workaround for their specific broken state, not the normal path.

You’re right to be skeptical: models.json is generated state, so manual edits can help short-term but can be overwritten later.

Normal flow should be:

pnpm openclaw --version
pnpm openclaw models auth login --provider anthropic --method cli --set-default
pnpm openclaw gateway restart
pnpm openclaw models status --json

If you still only get it working by hand-editing ~/.openclaw/agents/main/agent/models.json, that’s likely a bug/regression for your environment (Docker/root/user-path edge case).

Docs:

https://docs.openclaw.ai/providers/anthropic

#

https://docs.openclaw.ai/gateway/cli-backends

If you paste your openclaw --version + models status --json (redacted), I can pinpoint whether it’s config vs generation bug.

wise tartan Apr 8, 2026, 3:36 AM

#

So Claude cli models uses native Claude code ?

untold sierraBOT Apr 8, 2026, 3:37 AM

#

Yeah — claude-cli/... models use your local Anthropic Claude CLI backend (claude -p) under the hood, not the direct Anthropic API path.

Quick split:

claude-cli/... → local Claude CLI runtime (on your host)
anthropic/... → native Anthropic API/OpenClaw provider path

So if you want “native API” behavior, use anthropic/*. If you want to reuse Claude CLI login/subscription flow, use claude-cli/*.

Docs:

wise tartan Apr 8, 2026, 3:42 AM

#

The bundled Anthropic claude-cli backend is supported again. Anthropic staff told us OpenClaw-style Claude CLI usage is allowed again, so OpenClaw treats claude -p usage as sanctioned for this integration unless Anthropic publishes a new policy.

untold sierraBOT Apr 8, 2026, 3:42 AM

#

Yep — that statement is correct/current. 👍

So claude-cli usage is supported again in OpenClaw, but it still depends on your local Claude CLI being available/authenticated on the gateway host.

If it’s still not working for you, paste:

openclaw --version
the exact error text you get when using claude-cli/...

Then I can help pinpoint what’s failing.

wise tartan Apr 8, 2026, 3:43 AM

#

Yes but appending to Claude cli system prompt is no longer working with native oauth

untold sierraBOT Apr 8, 2026, 3:44 AM

#

Yep, that tracks — and this is the key distinction:

claude-cli/* route: uses Claude CLI flags like --append-system-prompt
anthropic/* route (native OAuth/API path): does not use Claude CLI flags at all

So if you switched to native OAuth on anthropic/*, Claude CLI prompt-append behavior won’t apply there.

Also, on the bundled claude-cli backend, system prompt append is only sent on the first turn of a CLI session. Reused/resumed sessions won’t re-append automatically.

If you want, paste:

openclaw --version
your active model ref (claude-cli/... vs anthropic/...)
one failing example

and I’ll help you pin it down fast.

wise tartan Apr 8, 2026, 3:47 AM

#

You didn’t get it anthropic cli provider taps into your extra usage

untold sierraBOT Apr 8, 2026, 3:47 AM

#

You’re right — good call.
claude-cli auth path does tap into Claude subscription/Extra Usage behavior.

What I was separating is:

billing/auth path (can be Claude login + Extra Usage), vs
CLI flag behavior (--append-system-prompt), which is backend/session behavior.

If Extra Usage is working but prompt-append isn’t, this is likely one of:

you’re on a resumed CLI session (append is first-turn scoped), or
a regression.

Can you share:

openclaw --version
exact model ref in use
whether this fails even on a fresh new session/thread

If it fails on a fresh session, that’s bug-report worthy: https://github.com/openclaw/openclaw/issues

wise tartan Apr 8, 2026, 4:03 AM

#

So it’s just system prompt substring matching what they are doing

untold sierraBOT Apr 8, 2026, 4:04 AM

#

Close, but not exactly.

It’s not substring matching in OpenClaw — it uses a hash of the trimmed extra system prompt to decide CLI session reuse/reset.
Then --append-system-prompt is applied only for new/non-resume CLI runs (systemPromptWhen: "first").

So behavior is:

same extra prompt + resumed session → no re-append
changed extra prompt → session invalidates/reset, then append applies on first turn again

If you want, I can help you craft a minimal repro to confirm whether your case is this behavior vs a regression.

wise tartan Apr 8, 2026, 4:07 AM

#

I ment anthropic is matching on open claw substring to block access to subs

untold sierraBOT Apr 8, 2026, 4:07 AM

#

Ah got you. I don’t see evidence that Anthropic is blocking purely on an "openclaw" substring.

For claude-cli/*, OpenClaw is basically shelling out to local claude -p — so most failures are usually:

quota/rate window (429)
Extra Usage entitlement limits
auth/session/profile mismatch

If you paste the exact error text + status code (and openclaw --version), we can tell which bucket it is quickly.
If it says Extra usage is required for long context requests, that’s entitlement/routing, not substring filtering.

Ref: https://docs.openclaw.ai/help/faq#why-am-i-seeing-http-429-ratelimiterror-from-anthropic

plain ferry Apr 9, 2026, 6:30 PM

#

quick question before I go deeper with this setup.

I’m currently running a self-hosted stack with OpenClaw + LiteLLM + CLIProxyAPI on a Synology NAS (Docker), and I’m aiming for a tokenless / subscription-based routing model (Claude CLI, potentially Gemini CLI, etc.) instead of API keys.

Architecture looks roughly like:

OpenClaw (agents / orchestration)
LiteLLM (routing + metrics + abstraction layer)
CLIProxyAPI (OAuth / device-flow providers)
Mix of local + remote models (LM Studio on a GPU laptop + hosted models)

Given the recent clarification that claude-cli is supported again:

👉 Would this setup be a good candidate for using claude-cli/* as a primary model backend in production-like usage?

More specifically:

Any known issues running Claude CLI behind a gateway (non-root, Dockerized)?
Any limitations when combining claude-cli with a router like LiteLLM?
Any pitfalls with session handling / scaling / concurrency?
Is anyone running something similar reliably long-term?

Trying to avoid going too deep into something that might not be stable at scale.

Thanks 🙌

untold sierraBOT Apr 9, 2026, 6:32 PM

#

I’m checking the current docs/code paths so I don’t make up stability claims.

#

I’m also checking whether we have any real-world reports in the server, because that part matters more than theory.

#

Short answer: supported, yes. Ideal as your primary production backend, probably no.

OpenClaw’s current docs say:

Claude CLI is supported again
but for long-lived gateways, Anthropic API key is still the most predictable
and CLI backends are framed more as a safety net than the main path

So for your stack, I’d rate it like this:

Good fit: homelab, staging, low to moderate concurrency, “production-like” personal use
Less ideal: high-concurrency, stateless, autoscaled, or “must be boringly predictable” production

Your specific questions

1) Dockerized / non-root / behind gateway

Should be fine if the gateway user has:
- claude on PATH

#

a persistent writable HOME
- persistent writable workspace
Important because Claude CLI state lives under ~/.claude/projects/... and OpenClaw session/auth state under ~/.openclaw/...
So the big pitfall is not “non-root”, it’s ephemeral containers, wrong UID/GID, or read-only mounts

2) LiteLLM in front of claude-cli

This is the main architectural gotcha.
Native claude-cli/* in OpenClaw is a CLI backend path, not a normal OpenAI/Anthropic-compatible API provider.
So if you want OpenClaw-native Claude CLI session reuse, LiteLLM is not really the layer I’d put in between.
I’d use LiteLLM for your API/proxy-backed providers, and let OpenClaw talk to claude-cli/* directly.

3) Sessions / scaling / concurrency

OpenClaw does persist CLI session ids and reuse them
It also supports ordered execution with serialize: true
That’s good for coherence, but it also means this path is not as horizontally scalable as stateless API calls
I’d expect pain first around:
- bursty concurrency

#

many parallel sessions
- auth/session churn
- container replacement without preserved state

4) Long-term reliability

I’m not seeing many strong “we run OpenClaw + LiteLLM + CLIProxyAPI + Claude CLI at scale for months” reports yet.
So I wouldn’t call that combo battle-tested in the community, at least not from what’s surfaced here.

My recommendation

If you want the safest architecture:

Use API/proxy providers as the primary router path through LiteLLM
Use claude-cli/* as a direct OpenClaw fallback or a low-concurrency primary for specific agents
Avoid making Claude CLI the backbone for high-fanout automation

Docs:

#cant use claude-cli models

What I’d do right now

If it still reproduces

What to do

Also verify (common gotchas)

Your specific questions

My recommendation