You set a model override, via /model, via the config, or via a session spawn, and the agent is still responding on the wrong model. This is one of the most confusing behaviors in OpenClaw because the system accepts the command without error and then does nothing with it. This article walks through every place an override can be set, every place it can be silently ignored, and the exact sequence to get your agent on the model you specified.
Before You Start
- Your OpenClaw agent is running and reachable
- You have attempted to set a model override and the agent appears to be on a different model
- You want to confirm which model is active and why the override did not take effect
TL;DR
If your OpenClaw model override not working situation has one of four root causes: the override was set in the wrong place for the scope you are in, the session cached the original model at startup and the override requires a new session, the config change was not written to disk correctly, or a higher-priority override is superseding it. Check which model is active right now, then work through the scope hierarchy to find where the conflict is.
Estimated time: 10 minutes
Jump to the cause
- Not sure what model is active? Confirm which model you are actually on
- Set via /model command? Session-scope overrides and why they expire
- Set in openclaw.json? Config overrides and the /new requirement
- Set at session spawn? Session spawn model overrides
- Override being beaten by something else? The override priority hierarchy
- Override accepted but no effect? When the system accepts the override and ignores it anyway
First: confirm which model is actually active
Before diagnosing an OpenClaw model override problem, you need to rule out the possibility that no override was set at all and the agent is simply running its config default.
Before diagnosing why the override failed, you need to confirm the agent is actually on the wrong model. The agent can tell you directly.
What model are you currently using for this conversation? What is the default model in my openclaw.json? Is there any active model override for this session? Show me all three values.
Diagnosing OpenClaw wrong model selected: the agent’s response will show you three things: the runtime model (what is actually running), the config default (what openclaw.json says), and any session-level override. The gap between these tells you exactly where the conflict is.
What the three values mean
- Runtime model = config default, no session override: the
/modelcommand either was not applied to this session or expired when the session ended. The config is controlling model selection. - Runtime model = session override, not what you wanted: a different override is active: a cron job, a subagent spawn, or a previous
/modelcommand from this session that you forgot about. - Runtime model = config default, but you changed the config: the config change was written but the session is caching the old value. You need a new session with
/newfor the config change to take effect. - Runtime model = what you set, but quality is wrong: the override worked. The quality issue is something else. The model you overrode to has different defaults or capabilities than you expected.
OpenClaw /model not working: session-scope overrides
The /model command sets a model override for the current session only. It applies immediately to the next response in that session. When the session ends, the override expires. The next session starts on whatever model the config default says.
This is the most common source of confusion: the /model command worked, the session responded correctly on the new model, and then you opened a new session and it was back on the original model. The override did not fail. It worked exactly as designed. Session-scope overrides do not persist.
Check the current session for any active model override. Was a
/modelcommand used in this session? If so, what model was set and when? Is that override still active or did it expire?
How to make a session override persist
If you want the same model in every session without setting it manually each time, change the default model in your config. That is the only way to make a model selection permanent.
Show me the current value of
agents.defaults.modelin my openclaw.json. What command would I use to change it to[model name]? Show me the exact config change and tell me whether it requires a new session to take effect.
Config changes require /new
Changing agents.defaults.model in openclaw.json does not update your current session. The session caches the model at startup. Start a new session with /new after any config change to model settings. The new session will pick up the updated default.
OpenClaw model not changing after config update
OpenClaw caches certain config values when a session starts. The model is one of them. If you change the default model in openclaw.json while a session is open, that session will continue on the old model until you start a new one. This is not a bug; it is how session isolation works. But it is the single most common reason operators report that their config change “did not work.”
The symptom: you changed the model in config, the gateway restarted, and the agent is still on the old model. You check the config and the new model is correctly written. Everything looks right but the behavior did not change.
The fix is always /new. No amount of gateway restarts, config re-reads, or agent prompting will change the model in a running session. New session, new model.
Read my openclaw.json and tell me the current value of the default model. Then tell me what model this session started on. Are they the same? If not, the config was changed after this session started. I need to start a new session to pick up the change.
Verifying that the config change was written correctly
Before starting a new session, confirm the config change actually landed on disk. Config patches applied through the gateway API occasionally fail silently if the file was locked or the write was interrupted.
Read my openclaw.json directly from disk and show me the exact value of
agents.defaults.model. Do not read from memory or the gateway API. Read the file. Then confirm that the gateway config and the on-disk file agree.
Manual verification (SSH)
SSH into the server and run:
cat ~/.openclaw/openclaw.json | python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('agents',{}).get('defaults',{}).get('model','not set'))"
This bypasses the gateway entirely and reads from disk. If the output matches what you wanted, the config write succeeded. If not, the write failed and you need to apply it again.
When the config change writes correctly but /new still shows the old model
If the file shows the new model, the session starts fresh with /new, and the agent still reports the old model, the config structure is wrong. The model field may be nested in the wrong place or the gateway is reading from a different config file than the one you edited.
Run
/statusand tell me the exact path to the config file the gateway loaded on startup. Then read that file and show me the fullagentssection. Also check whether there is more than one openclaw.json on this server. A system install and a user install can have separate configs and the gateway may be loading the one you did not edit.
Session spawn model overrides
When sessions are spawned by cron jobs, subagents, or the sessions_spawn tool, they can specify a model at spawn time. That model becomes the session’s starting model, overriding the config default for that session only. If a cron job or scheduled task is spawning sessions on the wrong model, every session it creates will use that model regardless of what your config default says.
List all active cron jobs and subagent configurations. For any that spawn sessions, show me what model is specified at spawn time. Are any of them overriding the session model to something different from my config default?
How spawn-time overrides interact with /model
A spawn-time model override and a /model command in the same session interact predictably: whichever was set last wins. If a cron job spawns a session on model A, and then the session prompt includes a /model B instruction, the session runs on model B. If the cron job’s prompt does not include a /model command, the session runs on the spawn-time model A for its entire lifetime.
The issue: if you changed your config default from model A to model B, any cron jobs that specify model A at spawn time will still create sessions on model A. The config default only applies to sessions that do not have a spawn-time override. Check your cron job configs after any model change.
After I change my default model in config, which cron jobs and session spawn configs also need to be updated to use the new model? Show me every place in my config where a model is hard-coded at spawn time rather than inherited from the default.
The override priority hierarchy
OpenClaw resolves model selection through a priority hierarchy. Higher-priority settings override lower-priority ones. Understanding the hierarchy tells you exactly why your override is being ignored.
Model selection priority (highest to lowest)
- Per-request model override: specified in the API call itself. Beats everything else. Used by some plugins and tools to force a specific model for a specific request.
- Session-level override: set via
/modelcommand or spawn-time model parameter. Applies for the duration of the session. Beats config defaults. - Agent-level config:
agents.defaults.modelin openclaw.json. The default for all sessions that do not have a higher-priority override. - Fallback chain:
agents.defaults.fallbackModels. Only applies when the primary model is unavailable. Not an override; a fallback.
If your override is at level 3 (config default) but something at level 1 or 2 is active, your config change will have no visible effect. You are setting a value at a lower priority than what is already there.
Walk through the model selection priority hierarchy for my current session. At each level (per-request, session-level, config default), tell me what value is set and whether it is the one controlling the current model selection. Identify which level is winning and why.
Per-request overrides from plugins
Some plugins, especially memory plugins, compaction handlers, and tool execution wrappers, specify a model at the per-request level. These are the highest-priority overrides and they are invisible unless you know to look for them. A plugin that hardcodes a model at per-request level will use that model for every request it handles, regardless of your session model, config default, or any /model command you issue.
List all installed plugins. For any plugin that makes its own API calls or specifies a model for its operations, tell me what model it is using. Is any plugin overriding the model at the per-request level for any of my interactions?
OpenClaw model override ignored: accepted but not applied
When OpenClaw ignores a model override after acknowledging it, the issue is almost always one of three things. The most frustrating version: you issue a /model command, the agent acknowledges it (“Switching to deepseek/deepseek-chat”), and then the next response comes back on the original model anyway. No error. No explanation. Just the wrong model.
This happens in three situations:
The model is not in your config. If you specify a model that is not configured in your models.providers list, OpenClaw accepts the command, attempts to use the model, fails silently on the first request, and falls back to the next available model. The override did not stick because the model you specified does not exist in your setup.
List every model configured in my openclaw.json under
models.providers. For each one, show me the exact model identifier string. Then tell me whether the model I am trying to override to is in this list. If it is not, that is why the override is failing.
The model identifier is wrong. Model identifiers in OpenClaw are exact strings: deepseek/deepseek-chat is different from deepseek-chat is different from openrouter/deepseek/deepseek-chat. A single character wrong in the identifier makes the override fail without an error message.
Run
openclaw models listand show me the exact identifier string for each available model. I want the string I need to use in a/modelcommand, the full provider/model format, not the alias.
The API key for that provider is missing or invalid. If the model exists in config but the provider’s API key is missing or expired, the override is accepted, the first request fails with an auth error, and OpenClaw falls back to the next available model. From your perspective the override was ignored. What actually happened was the override worked but the model was immediately unavailable.
Check the API key for
[provider name]. Is it set in my config? Run a minimal test call against that provider to confirm the key is valid. If the key is missing or the call fails, that is why my model override is not sticking.
Full diagnosis sequence
If the above sections have not identified the cause, run this complete sequence. Paste each prompt into your agent in order and work through the results.
Step-by-step override diagnosis
Step 1: Confirm what model is running
What model are you running on right now? What was the model when this session started? Has any
/modelcommand been issued this session? Show me the full model selection state.
Step 2: Check the config default
Read openclaw.json from disk. Show me
agents.defaults.modelandagents.defaults.fallbackModels. Is the model I want configured as either the default or the fallback?
Step 3: Check whether the model exists
Run
openclaw models listand show me every available model with its exact identifier string. Confirm that the model I am trying to use appears in this list exactly as I am specifying it.
Step 4: Validate the API key
Test the API key for the provider I am trying to use. Make a minimal test call and report the result. If the call fails, tell me the exact error.
Step 5: Check for higher-priority overrides
List every active model override: session-level, cron job spawn-time, plugin per-request. Is anything at a higher priority than my config default currently active? If so, what is it and where does it come from?
How to correctly apply a model change that sticks
Once you have identified where the override needs to go, here is the correct sequence for each scope:
Permanent change (all future sessions): change agents.defaults.model in openclaw.json, then start a new session with /new. Verify with /status that the new session shows the correct model.
Change my default model to
[model identifier]. Show me the exact config change. After the change is applied, tell me to start a new session with/newto activate it. Do not declare the change done until I have verified it with/statusin the new session.
Current session only: use the /model [identifier] command in the current session. Takes effect on the next response. Expires when the session ends.
Specific cron job or subagent: set the model in the cron job config or the sessions_spawn call directly. Does not affect other sessions.
For each cron job in my config, show me the current model setting. For any that should be using
[model identifier]instead of the current setting, show me the config change. Do not apply anything yet.
Confirming the change is live: after any model change, verify it actually took effect before declaring it done.
After the model change and a new session: run
/statusand show me the current model, the config default, and confirm they match. If they do not match, tell me what is still overriding the config default and why.
The five most common override mistakes
Most model override failures come down to one of five mistakes. They all look different on the surface but each has a specific, fast fix.
Mistake 1: Using an alias instead of the full identifier
OpenClaw supports model aliases (like sonnet, ds-v3, local-fast) in SOUL.md and AGENTS.md routing instructions. These aliases are documentation conventions, not valid model identifiers in /model commands or config fields. If you type /model sonnet, OpenClaw looks for a model with the identifier string sonnet in your models.providers list. It will not find it. The command appears to succeed and then falls back to whatever is next in the chain.
The fix: always use the full provider/model identifier. For sonnet, the correct string is anthropic/claude-sonnet-4-6. Run openclaw models list and copy the exact string from the output.
Run
openclaw models listand show me every model with its exact full identifier string. I want to find the correct string to use in a/modelcommand for[the model I want].
Mistake 2: Changing the model during a task that has already started
If you issue a /model command in the middle of a multi-step task, the model changes for the next request. But the current task may already have sub-calls in flight on the old model. You will see a response that switches model mid-task: the first half produced by the old model, the second half by the new one. The result is inconsistent and looks like the override did not take effect at all.
The fix: issue model overrides before starting a task, not during one. If you need to change models for a long task, start a fresh session with /new, set the model with /model, then run the task.
Mistake 3: Changing the config without a /new
This is the most frequently reported override failure. The config change was written correctly. The gateway is using the new config. But the current session started before the change was made, so it is still running on the cached model. Every subsequent conversation in this session uses the old model no matter how many times you read the config and confirm it is correct.
The fix: /new. Always. After any model config change. Before verifying that the change worked. If you verify in the same session that was open when you made the change, you will see the old model and think the change failed. Verify in the new session.
Mistake 4: Changing agents.defaults.model but not the per-agent config
OpenClaw supports per-agent model configurations. If you have configured specific agents with their own model settings, those settings override the global agents.defaults.model. Changing the default does not affect agents that have their own model setting. The main session agent is often configured separately from the defaults.
Check my openclaw.json for per-agent model configurations. Are there any agent entries under
agentsthat have their ownmodelfield separate fromagents.defaults.model? If so, show me each one. Changingagents.defaults.modeldoes not affect these.
Mistake 5: Setting the model in AGENTS.md instead of config
AGENTS.md and SOUL.md are instruction files, not config files. Writing “use deepseek/deepseek-chat for all tasks” in AGENTS.md adds a routing instruction to the agent’s system prompt. The agent will try to follow this instruction. But it is not a config-level override. If the agent hits a rate limit and the fallback chain fires, the AGENTS.md instruction does not prevent the fallback. If a plugin issues a per-request override, the AGENTS.md instruction does not beat it. Instructions in workspace files are suggestions that the agent tries to honor; they are not hard model selections.
For a model selection that actually holds at the infrastructure level, it must be in openclaw.json. AGENTS.md routing rules are best-effort guidance, not enforcement.
Check my AGENTS.md and SOUL.md for model routing instructions. For each one, tell me: is this instruction enforced at the infrastructure level or is it guidance the agent tries to follow? Which of these instructions require a matching config setting in openclaw.json to be fully effective?
Multiple config files: the silent override
If you installed OpenClaw as a system-wide package and also have a user-level install, there are two openclaw.json files. The gateway loads one of them at startup. You edit the other. The change never takes effect because you are editing the wrong file.
This also happens on servers that have gone through multiple install methods, or where a Docker container has a different config path than the host install. The symptom is: the config file you can see and edit shows the correct model, but the agent uses a different one. No amount of config changes to the file you are looking at will change the agent’s behavior.
Run
find / -name "openclaw.json" 2>/dev/nulland show me every openclaw.json on this server. Then tell me which one the running gateway process loaded. If there are multiple files, show me the model setting in each one.
How to find the loaded config (SSH)
ps aux | grep openclaw shows the running process with its arguments. The --config argument (if present) tells you which file was loaded. If no --config argument is present, OpenClaw used its default search path: ~/.openclaw/openclaw.json first, then system paths. The gateway startup log also records the config file path at boot.
If you have two configs and the gateway is loading the wrong one, there are two clean fixes: delete or rename the config you do not want the gateway to load, or restart the gateway with an explicit --config /path/to/correct/openclaw.json argument pointing to the right file. Do not try to keep both files in sync manually.
Quick-reference: which symptom matches which cause
Use this table to map what you observed to the most likely cause before running the full diagnosis sequence.
| What you observed | Most likely cause | Where to look |
|---|---|---|
| Override worked in one session, gone in the next | Session-scope override expired (expected behavior) | Session-scope overrides |
| Config shows new model but agent still on old one | Session cached old model at startup, needs /new | Config overrides and /new |
| Agent acknowledged the /model command, then ignored it | Wrong model identifier, bad API key, or per-request plugin override | Override accepted and ignored |
| Cron jobs still on old model after config change | Cron job spawn configs hard-code the old model | Spawn-time overrides |
| Override works in chat but fails in subagent tasks | Subagent spawn specifies its own model | Spawn-time overrides |
| Config on disk looks correct but override still fails | Multiple openclaw.json files, gateway loading wrong one | Multiple config files |
| Override fails only on specific types of requests | Plugin issuing per-request model override for those requests | Override priority hierarchy |
| Changed agents.defaults.model but main agent unchanged | Per-agent model config overriding the default | Mistake 4: Per-agent config |
Stop guessing which model is running.
Cheap Claw: $17
The complete model routing and cost control guide for OpenClaw operators. Covers the full override priority hierarchy, config structure for permanent model changes, per-session and per-cron routing, fallback chain design, and rate limit management. Everything as paste-ready agent prompts.
Questions people actually ask about this
OpenClaw /model command not working: agent acknowledged it but next response was on the wrong model. What happened?
One of three things: the model identifier was wrong (one character off from the exact string in your config), the API key for that provider is invalid so the first request failed and triggered a fallback, or a plugin is issuing per-request model overrides that beat your session override. Run Step 3 and Step 4 from the diagnosis sequence above to narrow it down.
Do I need to restart the gateway after changing the model in config?
No. The gateway does not need to restart for a model config change. What you do need is a new session. The gateway restarts with the new config immediately, but existing sessions cached the old model at startup and will not update. Start a new session with /new.
I changed the model, started /new, and /status still shows the old model. What is wrong?
The most likely cause is that the config write did not complete correctly. Read openclaw.json directly from disk and check the value of agents.defaults.model. If it still shows the old model, the config patch failed silently. Apply the change again and verify the file on disk before starting a new session. The second most likely cause is multiple openclaw.json files. A system install and a user install. The gateway loads one; you edited the other.
My model override works in conversation but cron jobs still use the old model. Why?
Cron jobs that specify a model at spawn time use that model regardless of your config default. Changing the default in config does not update hard-coded model values in cron job configs. After changing your default model, review every cron job that spawns sessions and update the model parameter in each one manually.
How do I override the model for just one cron job without changing anything else?
Set the model in the cron job’s payload directly. An agentTurn payload can include a model field specifying the exact model identifier. That cron job will use the specified model regardless of the global default. Other cron jobs and regular sessions are unaffected.
Can a plugin permanently override my model choice?
For its own requests, yes. A plugin that specifies a model at the per-request level will use that model for every request it makes, regardless of your session model or config default. To change this, you need to update the plugin’s config (if it exposes a model setting) or contact the plugin author. You cannot override a plugin’s per-request model selection from the agent side.
I want different models for different task types. How do I set that up?
OpenClaw does not natively route different task types to different models within a single session. The workaround is to set up separate cron jobs or session spawns for each task type, each with its own model specified at spawn time. For ad hoc tasks in conversation, use /model to switch before the task and switch back after.