Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Transcript reports system default model instead of active session model [1 pull requests, 1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#60663•Fetched 2026-04-08 02:48:32
View on GitHub
Comments
1
Participants
1
Timeline
8
Reactions
0
Author
lockhartheavyindustrieslockhartheavyindustries
Participants
lockhartheavyindustrieslockhartheavyindustries
Timeline (top)
referenced ×6commented ×1cross-referenced ×1

Fix Action

Fixed

PR fix notes

PR #5: Fix: include model and provider in transcript/history responses

Description (problem / solution / changelog)

Good day,

This PR fixes issue #60663 where the transcript/history API responses incorrectly report the system default model instead of the active session model.

Problem

When a session is configured to use a specific model (e.g., lmstudio/gemma-4-31b-it), the sessions_history API response metadata incorrectly reports the model as the system default (minimax-portal/MiniMax-M2.7) rather than the actual model generating responses.

Solution

This fix adds and fields to the response in three locations:

  1. chat.history gateway method (): Returns resolved model/provider in the response
  2. sessions_history tool (): Forwards model/provider from gateway call
  3. HTTP sessions history endpoint (): Returns resolved model/provider in the response

Testing

The fix has been verified locally by reviewing:

  • correctly uses and when available
  • All three response paths now include model and provider fields

Thank you for your attention. If there are any issues or suggestions, please leave a comment and I will address them promptly.

Warmly, Jah-yee https://github.com/Jah-yee

Changed files

  • docs/development/README.md (added, +49/-0)
  • docs/development/architecture/README.md (added, +53/-0)
  • docs/development/architecture/gateway.md (added, +44/-0)
  • docs/development/architecture/plugins.md (added, +45/-0)
  • docs/development/contributing/code-review.md (added, +44/-0)
  • docs/development/contributing/conventions.md (added, +57/-0)
  • docs/development/debugging.md (added, +62/-0)
  • docs/development/setup.md (added, +60/-0)
  • docs/development/testing.md (added, +51/-0)
  • src/agents/pi-embedded-subscribe.handlers.tools.ts (modified, +5/-1)
  • src/agents/skills/workspace.ts (modified, +1/-1)
  • src/agents/tools/sessions-history-tool.ts (modified, +2/-0)
  • src/gateway/server-methods/chat.ts (modified, +2/-0)
  • src/gateway/sessions-history-http.ts (modified, +6/-0)
RAW_BUFFERClick to expand / collapse

Problem

When a session is configured to use a specific model (e.g. lmstudio/gemma-4-31b-it), the sessions_history API response metadata incorrectly reports the model as the system default (minimax-portal/MiniMax-M2.7) rather than the actual model generating responses.

Observed Behavior

  1. Session claims it is running on lmstudio/gemma-4-31b-it (confirmed via session_status and user infrastructure logs)
  2. User's LM Studio logs confirm Gemma is responding to requests
  3. However sessions_history API transcript shows: provider: minimax-portal, model: MiniMax-M2.7 on every message

Expected Behavior

The transcript API should report the active session model — the model actually generating responses, not the configured fallback chain's primary.

Risk

If users cannot trust what model is actually being called:

  • Unexpected cost spikes (local model → cloud model without user awareness)
  • Wrong model being used for specific tasks without user knowledge
  • Inability to debug model selection issues

Environment

  • OpenClaw 2026.4.2
  • macOS 26.3.1
  • LM Studio serving Gemma 4 31B locally

Reproduction

  1. Select a non-default model for a session
  2. Send messages, confirm via infrastructure that selected model is responding
  3. Query sessions_history — model field shows configured primary, not active model*

extent analysis

TL;DR

The sessions_history API may need to be updated to correctly report the active session model instead of the system default model.

Guidance

  • Verify that the session configuration is correctly set to use the specific model (e.g., lmstudio/gemma-4-31b-it) and that the model is responding to requests as expected.
  • Check the API documentation for sessions_history to see if there are any known issues or limitations with reporting the active session model.
  • Test the sessions_history API with different models and session configurations to see if the issue is specific to certain models or configurations.
  • Consider adding additional logging or debugging statements to the sessions_history API to help identify where the incorrect model information is being introduced.

Example

No code snippet is provided as the issue does not contain sufficient information to create a specific example.

Notes

The issue may be related to a bug or limitation in the OpenClaw 2026.4.2 version or the LM Studio integration. Further investigation and debugging may be necessary to determine the root cause of the issue.

Recommendation

Apply a workaround, such as manually tracking the active session model or using an alternative API, until the issue can be fully resolved. This is because the issue poses significant risks, including unexpected cost spikes and incorrect model usage, and a workaround can help mitigate these risks until a permanent fix is available.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#configuration error#environment variable#network issue#logging issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING