Changing my agent's default model did not change its existing sessions

A model setting on disk can be correct without describing the model an existing conversation will use.

I hit that distinction while repairing a local OpenClaw installation in September. This is a historical debugging note about that installation, initially running version 2026.4.1, rather than a guide to the current release's storage format.

The visible symptom was an empty assistant reply. One configured NVIDIA endpoint returned 410 with a message saying the model had reached its end of life on July 27. My catalogue check at the time found all eight configured models gone, and the diagnostic state showed fallbackConfigured: false.

That explained why the old model could not answer. It did not explain why changing a default was insufficient.

The default was only one copy

My setup had model settings in several places:

• ~/.openclaw/openclaw.json, under agents.defaults.model.primary.
• Agent-specific entries in agents.list[], whose model value was a string in that version.
• Persisted state under ~/.openclaw/agents/<id>/sessions/sessions.json and the agent model store, agents/models.json.

The persisted session copies overrode the settings above them in this installation. Editing only the main configuration left existing sessions using their saved values.

The useful distinction was between choosing a default and changing an already-created conversation. I had been treating those as the same operation. The application had stored enough state to make them different operations.

Search for the value you are trying to remove

Reading the new default back proves that one setting changed. It does not establish that every consumer uses it.

For this kind of failure, I would start by backing up the configuration directory, then search the relevant configuration and session stores for the old model identifier. Inspect which agent and session each match belongs to before changing anything. A historical transcript mentioning a model is different from a field selecting it.

Then compare an existing session with a newly created one and inspect the model actually selected for a request. That comparison is a diagnostic I recommend; I do not have a recorded old-versus-new session experiment from this incident to present as a result.

If the two differ, the next question becomes concrete: which saved selection does the existing session retain, and what supported operation updates it? Repeating an edit to the default cannot answer that question.

Do not turn a storage detail into a permanent recipe

During a later upgrade of the same installation to 2026.8.1, the configuration schema and session storage changed again. The old session JSON stores became migration blockers, and new SQLite stores were created after the legacy files were moved aside. That procedure lost the old chat history; the entire configuration directory had been backed up first.

That is why I would not prescribe deleting a session file as the general fix for a stale model selection. The file layout belongs to a particular version, and recovery can have a history cost.

The lasting debugging check is smaller: when a default changes but an existing conversation behaves the same way, inspect the conversation's saved selection as well as the default. A valid configuration value is evidence about that value. The dispatched request is evidence about what the agent actually used.