#Subject: Free Models Router test issue

1 messages · Page 1 of 1 (latest)

vestal nebula
#

Hello Krill,
I’m testing openrouter/free in OpenClaw and the route is configured correctly, but the agent fails to generate a response.

What I’m trying to do:
Test whether Free Models Router works end-to-end with OpenRouter.

What happens instead:
The agent returns: ⚠️ Agent couldn't generate a response. Please try again.

Relevant setup:

OpenClaw version: 2026.4.15
Provider enabled: openrouter
Model list shows:
openrouter/free → configured, auth yes
openrouter/auto → configured, auth yes
Default model was switched to openrouter/free for the test
openrouter:manual auth profile exists and API key is stored
What I’ve verified:

openclaw models list shows openrouter/free
openclaw models status --plain returns openrouter/openrouter/free
The router is registered and authenticated, but the response generation still fails
Logs / error:
Aemeath:⚠️ Agent couldn't generate a response. Please try again.

What I want to know:

What exact command or setup should I use to properly test Free Models Router?
Is openrouter/free expected to fail for some models or contexts?
Is there a known issue with openrouter/auto vs openrouter/free?
Thanks.

open pecanBOT
#

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

iron warrenBOT
tender forumBOT
#

I checked the docs and source, and I think the main gotcha is this:

openrouter/free is not the supported OpenClaw model ref.

Use one of these instead:

  • openrouter/auto for the documented router
  • a concrete free model, like openrouter/<provider>/<model>:free

Best end-to-end test:

openclaw models scan --yes --set-default
openclaw models status --plain

After that, models status --plain should show something like:

# 
openrouter/deepseek/...:free

not:

openrouter/openrouter/free

If you want to set one manually, use a concrete :free ref returned by scan, for example:

openclaw models set openrouter/deepseek/deepseek-r1-0528:free

Short answers to your questions:

#
  • Exact command/setup: openclaw models scan --yes --set-default, then test with a simple prompt.
  • Is openrouter/free expected to fail? Yes, because it is not the right ref. Free models themselves can also be flaky/unavailable upstream.
  • Known issue openrouter/auto vs openrouter/free? openrouter/auto is the documented/supported router. openrouter/free is not. For free models, use concrete ...:free refs.

If it still fails after switching to a concrete :free model, please paste these:

openclaw models status --probe --probe-provider openrouter
openclaw status --all
openclaw logs --follow

Docs:

vestal nebula
#

Model Input Ctx Local Auth Tags
openai-codex/gpt-5.4-mini text+image 266k no yes default,configured
openai-codex/gpt-5.4 text+image 1025k no yes fallback#1,configured
openai-codex/gpt-5.3-codex text+image 266k no yes configured
openai-codex/gpt-5.3-codex-spark text 125k no yes configured
anthropic/claude-sonnet-4-6 text+image 977k no yes configured,alias:sonnet
anthropic/claude-haiku-4-5 text+image 195k no yes configured
anthropic/claude-opus-4-6 text+image 977k no yes configured,alias:opus
ollama/qwen2.5:1.5b-instruct text 16k yes yes configured
ollama/qwen2.5:1.5b-instruct-16k text 16k yes yes configured
ollama/qwen2.5:1.5b-instruct-q4_K_M text 16k yes yes configured
ollama/qwen2.5:3b-instruct-q4_K_M text 16k yes yes configured
openai-codex/gpt-5.4-nano - - - - configured,missing
openrouter/free text+image 195k no yes configured
openrouter/auto text+image 1953k no yes configured,alias:OpenRouter

I notice an unusually large ctx for openrouter/auto . Is this normal?

tender forumBOT
#

Yes, the big Ctx there is plausible, but I would treat it as metadata, not a guarantee.

A couple of important nuances:

  • 1953k is just about 2,000,000 tokens displayed in k units.
  • For openrouter/auto, that number is especially fuzzy because auto is a router, not one fixed model.
  • So the actual usable context depends on what OpenRouter routes to for that request.

More importantly, this does not change the core issue:

openrouter/free still looks like the wrong test target.

Why I say that:

  • models list showing openrouter/free only proves OpenClaw accepted that configured ref and sees OpenRouter auth.
  • It does not prove free is a real upstream OpenRouter model id.
  • openrouter/auto is the documented router.
  • For free models, the safe path is a concrete :free model ref.
#

So I’d test like this instead:

openclaw models scan --yes --set-default
openclaw models status --plain

Or manually:

openclaw models set openrouter/<provider>/<model>:free

What you want to see after that is a concrete ref like:

# 
openrouter/deepseek/...:free

not:

openrouter/openrouter/free

So short version:

  • Big Ctx on openrouter/auto: not alarming by itself
  • openrouter/free: still suspicious / likely not the right ref
  • Best test: pick a concrete ...:free model from models scan

If you want, paste the output of openclaw models scan --yes and I can tell you which exact free ref to use.

vestal nebula
#

Model Tool Image Ctx Params Notes
openrouter/nousresearch/hermes-3-llama-... fail skip 128k 405b
openrouter/meta-llama/llama-3.2-3b-inst... fail skip 128k 3b
openrouter/liquid/lfm-2.5-1.2b-instruct... fail skip 32k 1.2b
openrouter/google/gemma-3n-e2b-it:free fail skip 8k 2b
openrouter/nvidia/nemotron-3-nano-30b-a... fail skip 250k 30b
openrouter/google/gemma-3-27b-it:free fail skip 128k 27b
openrouter/google/lyria-3-pro-preview fail skip 1024k -
openrouter/liquid/lfm-2.5-1.2b-thinking... fail skip 32k 1.2b
openrouter/google/gemma-3n-e4b-it:free fail skip 8k 4b
openrouter/google/gemma-3-4b-it:free fail skip 32k 4b
openrouter/google/lyria-3-clip-preview fail skip 1024k -
openrouter/cognitivecomputations/dolphi... fail skip 32k 24b
openrouter/google/gemma-3-12b-it:free fail skip 32k 12b
openrouter/arcee-ai/trinity-large-previ... fail skip 128k -
openrouter/z-ai/glm-4.5-air:free fail skip 128k -
openrouter/openai/gpt-oss-120b:free fail skip 128k 120b
openrouter/minimax/minimax-m2.5:free fail skip 192k -
openrouter/openai/gpt-oss-20b:free fail skip 128k 20b
openrouter/moonshotai/kimi-k2.5 1.7s skip 250k -
openrouter/openrouter/elephant-alpha 2.1s skip 256k -
openrouter/google/gemma-4-31b-it:free 2.3s skip 256k 31b

#

openrouter/nvidia/nemotron-3-super-120b... 2.4s skip 256k 120b
openrouter/openrouter/free 2.5s skip 195k -
openrouter/google/gemma-4-26b-a4b-it:free fail skip 256k 26b
openrouter/meta-llama/llama-3.3-70b-ins... fail skip 64k 70b
openrouter/qwen/qwen3-next-80b-a3b-inst... fail skip 256k 80b
openrouter/qwen/qwen3-coder:free fail skip 256k 480b
openrouter/nvidia/nemotron-nano-12b-v2-... 4s skip 125k 12b
openrouter/nvidia/nemotron-nano-9b-v2:free 4.4s skip 125k 9b

tender forumBOT
#

Nice, this actually makes the picture much clearer.

Your scan says the problem is not OpenRouter auth. It is model capability / routing choice.

The important part:

  • most of the :free models are failing the tool probe
  • a few models do pass
  • so openrouter/free is a bad target for OpenClaw agent testing, because it can land on models that are not good enough for the agent loop

From your results, the best concrete free candidate is:

openclaw models set openrouter/google/gemma-4-31b-it:free

That is the one I would use for the end-to-end free test.

#

If you just want to verify OpenRouter itself works, these also passed:

  • openrouter/moonshotai/kimi-k2.5 (not free)
  • openrouter/openrouter/elephant-alpha (not free)
  • openrouter/google/gemma-4-31b-it:free (free)

So my read is:

  • openrouter/free is not the right router/model ref to rely on
  • many free models are not agent-safe in OpenClaw
  • use a specific concrete free model that passed the scan instead

I’d do this next:

openclaw models set openrouter/google/gemma-4-31b-it:free
# 
openclaw models status --plain

Then test the agent again.

If that works, you’ve confirmed:

  • OpenRouter auth is fine
  • OpenClaw is fine
  • the failure was the openrouter/free selection, not the provider

Honestly, your scan is exactly the kind of evidence I’d trust here.

#

Ah, this is the missing piece.

I dug a bit deeper, and openrouter/free is a real OpenRouter router now. OpenRouter documents it as the Free Models Router.

So the updated picture is:

  • openclaw models set openrouter/free is a valid test
  • OpenClaw normalizes that to openrouter/openrouter/free internally, so seeing that in status/list is normal
  • the 195k ctx is also normal, it is just OpenClaw rendering about 200,000 tokens in k units

And your latest scan is the key proof:

  • openrouter/openrouter/free 2.5s

That means the router itself is working end-to-end.

So I would now revise the diagnosis to this:

#
  • auth is fine
  • the free router exists and works
  • the earlier Agent couldn't generate a response was probably request-specific or intermittent, because openrouter/free picks from free models dynamically

That dynamic part matters a lot: the Free Models Router does not pin one model, so behavior can vary between requests.

Exact command to test the router

openclaw models set openrouter/free

If models status --plain then shows:

openrouter/openrouter/free

that is expected.

#

If you want a stable, reproducible free test

Use a concrete free model that passed your scan, for example:

openclaw models set openrouter/nvidia/nemotron-nano-9b-v2:free

or the earlier passing one:

openclaw models set openrouter/google/gemma-4-31b-it:free

My recommendation

  • use openrouter/free if you want to test the router
  • use a concrete :free model if you want a stable regression test
#

So, yes, the new evidence changes the answer a bit, and I’m glad you pasted it. It looks like the router is real and working, and the weird part is mostly OpenClaw’s internal canonical display plus the router’s non-deterministic backend selection.

vestal nebula
#

Tested all of the free models. none of them are reliable.
I want to know as a chatgpt pro sub. What are the models avaliable for me to use right now? Last time I check 5.3 was bugged as it became a chatbot. But people had reported solving it differently with thinking medium?

tender forumBOT
#

For a ChatGPT Pro / Codex-style subscription, don’t use the generic openai/* path to answer that question. The right route in OpenClaw is openai-codex/*.

I don’t want to guess your live entitlement matrix, because that changes fast. The reliable way to see what your account can use right now is:

openclaw models auth login --provider openai-codex
openclaw models list --provider openai-codex

If you want the onboarding path instead:

openclaw onboard --auth-choice openai-codex

Two doc-verified nuances:

#
  • ChatGPT/Codex sign-in is routed through openai-codex/*, not openai/*
  • the spark route is Codex-only and entitlement-dependent, so whether it shows up can vary by account

On the “5.3 became a chatbot / thinking medium helped” part, that’s exactly the kind of thing I would not trust static advice on. For current real-world reports, ask in #models. That channel will have fresher answers than anything cached on my side.

Docs:

If you paste the output of:

openclaw models list --provider openai-codex

I can help you interpret it without guessing.

vestal nebula
#

Model Input Ctx Local Auth Tags
openai-codex/gpt-5.4-mini text+image 266k no yes default,configured
openai-codex/gpt-5.3-codex text+image 266k no yes configured
openai-codex/gpt-5.4 text+image 1025k no yes configured
openai-codex/gpt-5.3-codex-spark text 125k no yes configured
openai-codex/gpt-5.4-nano - - - - configured,missing

tender forumBOT
#

Yep, this answers the entitlement question pretty cleanly.

From your output, the usable ones are simply the rows that show:

  • Auth = yes
  • and not missing

So for your account right now:

  • the first four rows are available
  • the last row is configured but not actually available to your current Codex subscription/auth

A couple of useful takeaways:

  • if spark is showing Auth yes and not missing, then your account currently does have that entitlement
  • configured,missing means “it’s in config/allowlist, but the provider is not exposing it to this account right now”
#

So you don’t need me to guess anymore, that table is the source of truth for your current ChatGPT Pro / Codex access.

For the “5.3 got too chatbotty, maybe thinking medium fixes it” part, I’d still send you to #models for the current best answer. That kind of behavior report changes fast, and people there will have fresher hands-on results.

If you want a practical next move, I’d do this:

  • keep using one of the rows that is Auth yes and text+image
  • ignore the missing one
  • ask in #models specifically:
    “for Codex subscription users, which currently feels best in OpenClaw, and does medium thinking still help with 5.3 behavior?”

If you want, I can help you turn that table into a clean default + fallback setup next.

vestal nebula
#

I meant m6 5.3 codex wasnt able to do tools call, only chatbot

tender forumBOT
#

Ah, got it, that makes more sense.

Then the issue is not model availability, it is tool-call reliability.

A model can:

  • authenticate fine
  • answer like a normal chatbot
  • but still be a bad agent model because it does not emit valid tool calls reliably

In OpenClaw, that often shows up exactly like you described: it feels fine for chat, but falls over once the run needs tools.

So yes, if 5.3 Codex was “chatbot only” for you, I would treat that as:

  • usable for plain chat maybe
  • not a good primary model for agent/tool work