Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On 2026.5.3-1, the implicit session.model field cached on a per-channel session entry persists across /new and across hot-reload of agents.defaults.model.primary. The agent therefore runs with the stale cached model. This is NOT the modelOverride or providerOverride code path addressed by issue #69301 and PR #69419: the affected sessions never had /model invoked and have no modelOverride field; they only have the plain model field that is captured at session creation and never refreshed.

Steps to reproduce

1. Confirm a telegram or discord direct session exists in ~/.openclaw/agents/main/sessions/sessions.json with model: <X> and no modelOverride field. Confirm agents.defaults.model.primary is currently <X>.
2. Without invoking /model on any client, change the configured default by running openclaw config set agents.defaults.model.primary <Y>.
3. Confirm hot-reload applies. Gateway log shows [reload] config hot reload applied (agents.defaults.model.primary).
4. From the same channel user, send any plain DM to the bot.
5. Inspect <sessionId>.trajectory.jsonl for that session. The latest model.completed event has model: <X>. The reply was generated by the cached model, not by the new default <Y>.
6. Send /new to the bot in the same channel. Bot replies with the standard "New session started" acknowledgement and a new sessionId is recorded in sessions.json.
7. Inspect the new entry in sessions.json. Its model field is still <X>, not <Y>. There is no modelOverride field, before or after.
8. Send another plain DM.
9. Trajectory.jsonl for the new session also shows model.completed model: <X>. Bot self-report confirms it is <X>.

Expected behavior

After /new the new session entry should reflect the current agents.defaults.model.primary. Equivalently, when the new session starts, model resolution should read the live default rather than copy the previous session entry's cached model value. This expectation matches the closed feature requests #64475, #65200, #67573, the closed bug #21725, and aligns with the direction of the #69301 fix, which addressed the related modelOverride field but did not cover this implicit cache path.

Actual behavior

The new session entry is created with model: <X> even though agents.defaults.model.primary is now <Y>. The agent run uses <X>. Concrete trace from today's retest on 2026.5.3-1, with timestamps in London BST:

Before retest:
agents.defaults.model.primary = "deepseek/deepseek-v4-pro"
sessions.json entry agent:main:telegram:direct::
sessionId:
model: deepseek-v4-pro
modelProvider: deepseek
authProfileOverride: deepseek:default
authProfileOverrideSource: auto
modelOverride:
providerOverride:

Step: openclaw config set agents.defaults.model.primary deepseek/deepseek-v4-flash
Gateway log:
2026-05-04T13:29:32.813+01:00 [reload] config change detected; evaluating reload (meta.lastTouchedAt, agents.defaults.model.primary)
2026-05-04T13:29:32.916+01:00 [reload] config hot reload applied (agents.defaults.model.primary)

Step: user sends a DM via Telegram.
Trajectory excerpt for the pre-new session:
type=model.completed model='deepseek-v4-pro' ts=2026-05-04T13:30:48.642+01:00
type=trace.artifacts model='deepseek-v4-pro'
type=session.ended model='deepseek-v4-pro' ts=2026-05-04T13:30:48.643+01:00

session.json after this message:
agent:main:telegram:direct::
sessionId: , unchanged from prior entry
model: deepseek-v4-pro
updatedAt: 2026-05-04T13:30:48.898+01:00, incremented
status: done

Step: user sends /new via Telegram. Bot replies with "✅ New session started.".
session.json after /new:
agent:main:telegram:direct::
sessionId: , a new sessionId
model: deepseek-v4-pro, still the cached value rather than deepseek-v4-flash
modelOverride:
providerOverride:

Step: user sends another DM.
Trajectory excerpt for the post-new session:
type=session.started model='deepseek-v4-pro' ts=2026-05-04T13:33:45.255+01:00
type=prompt.submitted model='deepseek-v4-pro' ts=2026-05-04T13:33:45.260+01:00
type=model.completed model='deepseek-v4-pro' ts=2026-05-04T13:33:47.920+01:00
type=session.ended model='deepseek-v4-pro' ts=2026-05-04T13:33:47.921+01:00

Bot self-report in the reply: "I'm running DeepSeek V4 Pro (deepseek/deepseek-v4-pro)."

The behavior is deterministic across both runs and across /new. No modelOverride or providerOverride field is ever present in the session entry.

OpenClaw version

2026.5.3-1. The same behavior was observed earlier this week on 2026.4.24 during interactive use. PR #69419, referenced from closed issue #69301, explicitly targeted the modelOverride and providerOverride fields and was released before 2026.5.3, but the implicit session.model cache path described here was not part of that fix scope.

Operating system

macOS 26.4.1 on arm64

Install method

npm global via fnm-managed Node 25.6.0

Model

deepseek/deepseek-v4-pro was the cached value on the session entries at the start of the retest. deepseek/deepseek-v4-flash was the new value of agents.defaults.model.primary that the agent runs failed to honor.

Provider / routing chain

Not in the failure path. The bug is in session model selection at agent run time, before any provider routing decision is made.

Additional provider/model setup details

agents.defaults.model in openclaw.json before retest:
{
"primary": "deepseek/deepseek-v4-pro",
"fallbacks": ["google/gemini-3-flash-preview"]
}

agents.defaults.models alias map:
{
"google/gemini-3-flash-preview": {"alias": "gemini"},
"deepseek/deepseek-v4-pro": {"alias": "deepseek"},
"deepseek/deepseek-v4-flash": {"alias": "deepseek-flash"}
}

models.json declares both deepseek-v4-pro and deepseek-v4-flash as configured under provider deepseek.

The user has never invoked /model on any client. Session entries before the retest contain authProfileOverride: deepseek:default with authProfileOverrideSource: auto, but no modelOverride and no providerOverride.

Logs, screenshots, and evidence

Hot-reload event in London BST, showing agents.defaults.model.primary did update in the live runtime:
2026-05-04T13:29:32.813+01:00 [reload] config change detected; evaluating reload (meta.lastTouchedAt, agents.defaults.model.primary)
2026-05-04T13:29:32.916+01:00 [reload] config hot reload applied (agents.defaults.model.primary)

Verification that the live config picked up the change:
$ openclaw config get agents.defaults.model.primary
deepseek/deepseek-v4-flash

Telegram session trajectory after the new default was active. The first run is the plain DM sent after the default change. The second run is the message sent after /new. Timestamps in London BST:
type=model.completed   model='deepseek-v4-pro' ts=2026-05-04T13:30:48.642+01:00
type=session.ended     model='deepseek-v4-pro' ts=2026-05-04T13:30:48.643+01:00
type=session.started   model='deepseek-v4-pro' ts=2026-05-04T13:33:45.255+01:00
type=prompt.submitted  model='deepseek-v4-pro' ts=2026-05-04T13:33:45.260+01:00
type=model.completed   model='deepseek-v4-pro' ts=2026-05-04T13:33:47.920+01:00
type=session.ended     model='deepseek-v4-pro' ts=2026-05-04T13:33:47.921+01:00

User-visible bot reply text confirming the cached model was used:
"I'm running DeepSeek V4 Pro (deepseek/deepseek-v4-pro)."

After restoring agents.defaults.model.primary to deepseek/deepseek-v4-pro, behavior is unchanged because the cached value happens to match the new default again. The session.json entries are not modified by the restore. No state was lost during the retest.

Impact and severity

Affected: any user who changes agents.defaults.model.primary while a per-channel session entry exists. This includes the upcoming and unavoidable migration window for users on the deepseek-chat and deepseek-reasoner family, which the provider has scheduled for retirement on 2026-07-24.
Severity: High. The user-visible failure path is misleading, because the conventional first action /new does not resolve the issue and the bot continues to use the stale model without any error.
Frequency: Always. Reproduced today on 2026.5.3-1 across two cycles within the same retest, both with and without /new in between.
Consequence: The agent silently uses an obsolete model selection. For deprecated models this means failed API calls; for non-deprecated models it means the user does not get the model they configured.

Additional information

Related issues, all describing variants of the same behavior class:
#69301 closed, fixed by PR #69419. Addressed modelOverride and providerOverride field clearing. Did not cover the implicit session.model cache path described here.
#21725 closed as not planned, marked stale.
#27058 closed as not planned, marked stale.
#29105 closed as not planned, marked stale.
#64475 closed as duplicate.
#65200 closed as not planned.
#67078 closed.
#67573 closed as duplicate, with labels close:duplicate and dedupe:child.

The pattern of stale-closures suggests this bug class has been reported multiple times without converging on a fix that covers the implicit cache. PR #69419 fixed the user-explicit override variant. The variant in this report is the implicit cache variant that survives even when no /model command was ever issued.

Workaround: manually delete the affected entries from sessions.json and the corresponding .jsonl files to force a fresh first-message session creation, which will pick up the current default.

Suggested fix direction: on /new and ideally also on hot-reload of agents.defaults.model.primary, write the session entry's model and modelProvider fields from the current agents.defaults.model.primary rather than carrying them forward from the prior entry. Equivalently, do not persist model on session entries at all; resolve at run time from the active runtime snapshot's defaults whenever no explicit modelOverride is present. The audit pass that emits REF_SHADOWED already encodes the precedence of agent-level configuration; session.model selection should follow the same precedence.

Drafted with AI assistance from Claude. The hot-reload event line, the agents.defaults.model.primary value transition, the trajectory.jsonl excerpts, the session.json before/after shapes, and the bot's own self-report were captured on the author's own machine on 2026.5.3-1 build 2eae30e today during a controlled retest. The retest did not modify any session content beyond what the channel inbound and reply paths normally write, and the configured default was restored to its prior value at the end. Code comprehension claims are limited to user-observable behavior, the trajectory event types, and the documented behavior of the closed issues referenced above.