[Bug]: Main session stays on transient override model with no reliable agent-accessible reset path

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

After a complex-task task-pack finalization temporarily uses a stronger override model, the main Jarvis session can remain on that override model instead of returning to its configured default model, and the agent has no reliable session-level reset path exposed in its current tool surface.

Steps to reproduce

1. Configure the main/default model as minimax-portal/MiniMax-M2.7-highspeed, with evolink-openai/gpt-5.2 available as a fallback/override.
2. In the same long-lived Jarvis main session, prepare a complex task pack that explicitly requires final pack finalization on evolink-openai/gpt-5.2.
3. Let the task pack complete and confirm the task pack metadata/status file records model_for_final_pack: evolink-openai/gpt-5.2.
4. Ask Jarvis for:
   • the main session default model
   • the current main session runtime model
   • the current session status model
5. Observe that the main session runtime/status model remains evolink-openai/gpt-5.2 instead of returning to the configured default minimax-portal/MiniMax-M2.7-highspeed.
6. Ask Jarvis to reset back to the default model at session scope. In this environment, Jarvis reports that no agent-accessible session-level reset path is available.

Expected behavior

If a stronger model override is used only for transient task-pack finalization, the main session should reliably return to its configured default model after the finalization step completes, or the agent should have an explicit supported session-level reset action it can invoke to clear the override.

Actual behavior

The main session continues to report evolink-openai/gpt-5.2 as the runtime/status model after task-pack finalization. The task pack correctly records model_for_final_pack: evolink-openai/gpt-5.2, but the main session does not appear to revert to its configured default model. In the observed environment, Jarvis can explain the mismatch but cannot complete a reliable session-level reset itself.

OpenClaw version

2026.4.5 (3e72c03)

Operating system

macOS 26.3.1 (25D771280a)

Install method

Local CLI install / local workspace setup

Model

Default main-session model: minimax-portal/MiniMax-M2.7-highspeed
Transient finalization override: evolink-openai/gpt-5.2

Provider / routing chain

openclaw -> minimax-portal (default main-session route)
openclaw -> evolink-openai/gpt-5.2 (transient finalization override)

Additional provider/model setup details

The local config sets the main/default agent model to:

{
  "primary": "minimax-portal/MiniMax-M2.7-highspeed",
  "fallbacks": [
    "evolink-openai/gpt-5.2",
    "evolink-google/gemini-2.5-flash"
  ]
}

The workflow intentionally uses evolink-openai/gpt-5.2 only for complex task-pack finalization, not as the normal main-session model.

Logs, screenshots, and evidence

Observed task-pack metadata:

task_id: task-20260408-001-pkb-llm-wiki-system
final_owner: Jarvis
model_for_final_pack: evolink-openai/gpt-5.2

Observed status file:

{
  "taskId": "task-20260408-001-pkb-llm-wiki-system",
  "status": "ready",
  "model_for_final_pack": "evolink-openai/gpt-5.2"
}

Observed Jarvis answers in the same session:

1. 当前主会话默认模型：minimax-portal/MiniMax-M2.7-highspeed
2. 当前主会话运行时模型：evolink-openai/gpt-5.2
...
- 当前 session status 里的 model：evolink-openai/gpt-5.2
结论：未成功恢复到默认主模型（异常：缺少可用的 session reset 接口）

Relevant upstream evidence from the codebase:

• sessions.patch supports clearing a model override with model: null and marks it as a pending live model switch.
• Tests cover marks model reset patches as pending live model switches.

This suggests a model-reset mechanism exists in the product, but it does not appear to be reliably reachable or applied in this observed task-pack-finalization workflow.

Impact and severity

Affected: long-lived main Jarvis sessions that temporarily use a stronger model for task-pack finalization
Severity: Medium to High (causes model-state pollution and unexpected cost/behavior drift in later ordinary conversation)
Frequency: Observed in the tested session after task-pack finalization
Consequence: the main session stays on the stronger override model instead of the configured default, and agent logic cannot reliably restore the default through its exposed tool surface

Additional information

This report is grounded in observed task-pack files, status files, and same-session model/status answers. The issue may be either:

1. a runtime behavior bug where a transient override persists on the main session, or
2. a product/API gap where model reset exists internally (sessions.patch model: null) but is not reliably exposed/usable from the agent workflow that initiated the transient override.

Either way, the current behavior makes “temporary strong-model finalization” unsafe for long-lived main sessions.