openclaw - ✅(Solved) Fix [Bug]: Incorrect handling on LM Studio model names with "@‘ [4 pull requests, 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#71474Fetched 2026-04-26 05:12:28
View on GitHub
Comments
0
Participants
1
Timeline
14
Reactions
0
Author
Participants
Timeline (top)
referenced ×8cross-referenced ×4closed ×1labeled ×1

LM Studio use "@" in model name when there are multiple quants for the same model, and openclaw failed to handle such cases.

Error Message

/model lmstudio/qwen3.6-27b@iq3_xxs Failed to set model: GatewayRequestError: model not allowed: lmstudio/qwen3.6-27b

Root Cause

LM Studio use "@" in model name when there are multiple quants for the same model, and openclaw failed to handle such cases.

Fix Action

Fixed

PR fix notes

PR #71486: fix(model): preserve LM Studio "@" quant suffixes in model name resolution

Description (problem / solution / changelog)

Summary

Fixes #71474 — LM Studio model names containing @ for quantization variants (e.g. qwen3.6-27b@iq3_xxs) were incorrectly truncated during model resolution.

Problem

stripModelProfileSuffix() in providers.ts naively stripped everything after the first @, discarding quant tags that LM Studio uses to distinguish quantization levels:

lmstudio/qwen3.6-27b@iq3_xxs  →  lmstudio/qwen3.6-27b  (❌ model not found)

This caused:

  1. /model lmstudio/qwen3.6-27b@iq3_xxsmodel not allowed: lmstudio/qwen3.6-27b
  2. API requests sent truncated model name → LM Studio picked a random quant instead of the configured one

Fix

providers.ts: Replace the naive indexOf("@") strip with splitTrailingAuthProfile(), which already has quant-aware logic (preserves @q8_0, @4bit, etc. while still allowing @profile auth suffixes).

model-ref-profile.ts: Extend the quant-suffix regex from q\d+ to i?q\d+ to also match importance-quantization tags (iq3_xxs, iq4_xs) used by llama.cpp / LM Studio.

Changes

FileChange
src/plugins/providers.tsImport + use splitTrailingAuthProfile instead of naive strip
src/agents/model-ref-profile.tsRegex q\d+i?q\d+ to match iq* quant tags
src/agents/model-ref-profile.test.ts3 new test cases for @iq* suffixes

Testing

All 15 model-ref-profile tests pass, including 3 new ones:

  • @iq3_xxs preserved in model id ✅
  • @iq4_xs preserved in model id ✅
  • @iq3_xxs@work correctly splits quant from auth profile ✅

Minimal, surgical change — only touches the model name parsing path.

Changed files

  • CHANGELOG.md (modified, +3/-0)
  • src/agents/model-ref-profile.test.ts (modified, +16/-0)
  • src/agents/model-ref-profile.ts (modified, +5/-2)
  • src/agents/model-selection.test.ts (modified, +24/-0)
  • src/auto-reply/model.test.ts (modified, +14/-0)
  • src/plugins/providers.test.ts (modified, +46/-0)
  • src/plugins/providers.ts (modified, +2/-3)

PR #71488: fix(agents): preserve LM Studio IQ quant model refs

Description (problem / solution / changelog)

Summary

  • Problem: LM Studio model ids such as qwen3.6-27b@iq3_xxs were parsed as qwen3.6-27b plus an auth profile suffix.
  • Why it matters: /model lmstudio/...@iq* could fail allowlist validation, and configured LM Studio IQ quant variants could lose the exact quant id before inference.
  • What changed: Treat @iq* local quant suffixes like the existing @q* / @4bit suffixes and keep them in the model id. Added regression coverage for direct profile splitting and model selection resolution.
  • What did NOT change (scope boundary): No LM Studio runtime transport, preload, auth-profile, or catalog discovery behavior changed.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #71474
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: splitTrailingAuthProfile already protected common local quant suffixes like @q8_0 and @4bit, but did not include LM Studio IQ quant suffixes such as @iq3_xxs.
  • Missing detection / guardrail: Existing tests covered @q* and bit-depth suffixes, but not @iq* model ids from LM Studio.
  • Contributing context (if known): LM Studio can expose multiple quants for the same base model by adding IQ suffixes to the model key.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: src/agents/model-ref-profile.test.ts, src/agents/model-selection.test.ts
  • Scenario the test should lock in: lmstudio/qwen3.6-27b@iq3_xxs resolves to provider lmstudio and model qwen3.6-27b@iq3_xxs, not a truncated model plus profile suffix.
  • Why this is the smallest reliable guardrail: The truncation happens in the shared model-ref/profile parser before LM Studio runtime code sees the selected model.
  • Existing test that already covers this (if any): Existing tests covered @q8_0, @4bit, and profile suffixes but not @iq*.
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

LM Studio users can select and run IQ quant model ids containing @iq*, for example lmstudio/qwen3.6-27b@iq3_xxs, without the quant suffix being stripped as an auth profile.

Diagram (if applicable)

Before:
/model lmstudio/qwen3.6-27b@iq3_xxs -> lmstudio/qwen3.6-27b + profile iq3_xxs -> model not allowed

After:
/model lmstudio/qwen3.6-27b@iq3_xxs -> lmstudio/qwen3.6-27b@iq3_xxs -> exact configured model

Security Impact (required)

  • New permissions/capabilities? (Yes/No) No
  • Secrets/tokens handling changed? (Yes/No) No
  • New/changed network calls? (Yes/No) No
  • Command/tool execution surface changed? (Yes/No) No
  • Data access scope changed? (Yes/No) No
  • If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

  • OS: Windows 11 local checkout
  • Runtime/container: Node test runner through repo scripts
  • Model/provider: LM Studio model refs with @iq* suffixes
  • Integration/channel (if any): /model / shared agent model selection
  • Relevant config (redacted): N/A

Steps

  1. Parse lmstudio/qwen3.6-27b@iq3_xxs through shared model selection.
  2. Parse lmstudio/qwen3.6-27b@iq4_xs@work through auth-profile splitting.
  3. Verify the first @iq* suffix stays in the model id and a second suffix can still be used as an auth profile.

Expected

  • @iq3_xxs and @iq4_xs remain part of the LM Studio model id.
  • A second suffix such as @work still resolves as the auth profile override.

Actual

  • Covered by the new regression tests.

Evidence

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)
pnpm test src/agents/model-ref-profile.test.ts src/agents/model-selection.test.ts
# Test Files  1 passed (1), Tests 13 passed (13)
# Test Files  1 passed (1), Tests 90 passed (90)

pnpm exec oxfmt --check --threads=1 src/agents/model-ref-profile.ts src/agents/model-ref-profile.test.ts src/agents/model-selection.test.ts
# All matched files use the correct format.

pnpm check:changed
# exit 0

Human Verification (required)

  • Verified scenarios: Shared parser preserves @iq3_xxs; shared model selection resolves lmstudio/qwen3.6-27b@iq3_xxs to the exact model id; second suffix auth profile still works after @iq4_xs.
  • Edge cases checked: Existing @q8_0, @4bit, @8bit, dated suffix, and profile suffix tests still pass.
  • What you did not verify: I did not run a live LM Studio server.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? (Yes/No) Yes
  • Config/env changes? (Yes/No) No
  • Migration needed? (Yes/No) No
  • If yes, exact upgrade steps: N/A

Risks and Mitigations

  • Risk: A user could previously intend @iq3_xxs as an auth profile name.
    • Mitigation: This matches the existing local-quant handling for @q*; users can still specify auth profiles as a second suffix, for example lmstudio/model@iq3_xxs@work.

Changed files

  • src/agents/model-ref-profile.test.ts (modified, +7/-0)
  • src/agents/model-ref-profile.ts (modified, +4/-3)
  • src/agents/model-selection.test.ts (modified, +11/-0)

PR #71490: fix(agents): preserve LM Studio @iq* quant suffixes in model refs

Description (problem / solution / changelog)

Fixes #71474

Problem

LM Studio names imatrix-quant variants like qwen3.6-27b@iq3_xxs (note: iq prefix, not q). splitTrailingAuthProfile only special-cased @q* / <n>bit suffixes, so:

/model lmstudio/qwen3.6-27b@iq3_xxs

was parsed as model="lmstudio/qwen3.6-27b" + profile="iq3_xxs", producing GatewayRequestError: model not allowed: lmstudio/qwen3.6-27b and (when it didn't fail) sending the truncated id to LM Studio, which then picked an arbitrary quant.

Fix

Extend the protected quant pattern to allow an optional i prefix:

- /^(?:q\d+(?:_[a-z0-9]+)*|\d+bit)(?:@|$)/i
+ /^(?:(?:i?q)\d+(?:_[a-z0-9]+)*|\d+bit)(?:@|$)/i

This keeps @iq3_xxs, @iq4_xs, etc. as part of the model id while still allowing an explicit auth profile via a second @ suffix (e.g. lmstudio/foo@iq3_xxs@work).

Tests

Added regression cases in:

  • src/agents/model-ref-profile.test.ts
  • src/agents/model-selection.test.ts
  • src/auto-reply/model.test.ts

Verified the splitter against representative inputs:

inputmodelprofile
lmstudio/qwen3.6-27b@iq3_xxslmstudio/qwen3.6-27b@iq3_xxs
lmstudio-mb-pro/gemma-4-31b-it@q8_0@q8_0
lmstudio/qwen3.6-27b@iq3_xxs@work@iq3_xxswork
openai/gpt-5@workopenai/gpt-5work
openai/@cf/openai/gpt-oss-20b@cf:defaultopenai/@cf/openai/gpt-oss-20bcf:default

Changed files

  • src/agents/model-ref-profile.test.ts (modified, +9/-2)
  • src/agents/model-ref-profile.ts (modified, +5/-3)
  • src/agents/model-selection.test.ts (modified, +22/-0)
  • src/auto-reply/model.test.ts (modified, +14/-0)

PR #71635: fix(agents): handle iq* quant suffixes in splitTrailingAuthProfile

Description (problem / solution / changelog)

Fixes openclaw/openclaw#71474

Problem

LM Studio uses '@' in model names to denote quant variants (e.g. qwen3.6-27b@iq3_xxs, qwen3.6-27b@iq4_xs). OpenClaw's splitTrailingAuthProfile function incorrectly treats iq* suffixes as auth profile delimiters, truncating the model name at '@'.

Result:

  • /model lmstudio/qwen3.6-27b@iq3_xxs → error "model not allowed: lmstudio/qwen3.6-27b"
  • LM Studio receives truncated name qwen3.6-27b and picks a random quant

Root cause

The quant-suffix regex only covered q* (e.g. q8_0, q4_k_xl) and *bit patterns, but not i* prefixed quants like iq3_xxs, iq4_xs that LM Studio uses.

Fix

Extend the quant-suffix regex in splitTrailingAuthProfile to also match i-prefixed quant suffixes:

- if (/^(?:q\d+(?:_[a-z0-9]+)*|\d+bit)(?:@|$)/i.test(...))
+ if (/^(?:q\d+(?:_[a-z0-9]+)*|i(?:q\d+(?:_[a-z0-9]+)*)?|\d+bit)(?:@|$)/i.test(...))

The i branch handles both standalone i* and iq* quant formats. Auth profiles can still be appended as a second @ suffix (e.g. ...@iq3_xxs@work).

Test additions

  • Covers iq3_xxs and iq4_xs LM Studio quant suffixes
  • Covers auth profile after @iq* suffix

Changed files

  • src/agents/model-ref-profile.test.ts (modified, +16/-0)
  • src/agents/model-ref-profile.ts (modified, +4/-3)

Code Example

> /model lmstudio/qwen3.6-27b@iq3_xxs
> Failed to set model: GatewayRequestError: model not allowed: lmstudio/qwen3.6-27b

---
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

LM Studio use "@" in model name when there are multiple quants for the same model, and openclaw failed to handle such cases.

Steps to reproduce

LM Studio loads 3 quants of the same models like below:

  • lmstudio/qwen3.6-27b@iq3_xxs
  • lmstudio/qwen3.6-27b@iq4_xs
  • lmstudio/qwen3.6-27b@q4_k_xl

These models are correctly configed in Openclaw and thse models can be selected in webui for agent. However, due "@" in the model name, openclaw can't handle it well.

  1. Can't use /model lmstudio/qwen3.6-27b@iq3_xxs to switch model, as openclaw would trunct it to lmstudio/qwen3.6-27b which is not configed.
> /model lmstudio/qwen3.6-27b@iq3_xxs
> Failed to set model: GatewayRequestError: model not allowed: lmstudio/qwen3.6-27b
  1. When sending query to LM Studio, the request set model name to qwen3.6-27b which cause LM Studio pick a "random" qwen3.6-27b quant instead of the one configed.

Expected behavior

  1. /model lmstudio/qwen3.6-27b@iq3_xxs should success switch model for a session.

  2. Should send "model": "qwen3.6-27b@iq4_xs" in request to LM studio, instead of truncated "qwen3.6-27b"

Actual behavior

1, Error message: Failed to set model: GatewayRequestError: model not allowed: lmstudio/qwen3.6-27b

  1. LM Studio received partical model name and randomly pick a quant to use.

OpenClaw version

2026.4.22

Operating system

Windows 11

Install method

WSL 2.0: install.sh

Model

qwen3.6-27b@quants

Provider / routing chain

openclaw -> LM Studio (v0.4.12)

Additional provider/model setup details

One interesting findings is that, sometimes openclaw can handle "@" correctly in the model name. However, I haven't figured out how to reliably to repro it. Otherwise I probably will live with such trick.

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The issue can be fixed by properly handling the "@" character in model names within OpenClaw to correctly identify and switch between different quants of the same model.

Guidance

  • Verify Model Configuration: Ensure that all models, including those with "@" in their names, are correctly configured in OpenClaw.
  • Handle "@" Character: Modify OpenClaw to properly parse and handle the "@" character in model names to prevent truncation and incorrect model selection.
  • Test Model Switching: After modifications, test switching between models using the full model name, including the "@" character, to ensure it works as expected.
  • Validate Requests: Verify that requests sent to LM Studio include the full model name, including the "@" character, to ensure the correct quant is selected.

Example

No specific code example can be provided without knowing the exact implementation details of OpenClaw and how it handles model names. However, the solution likely involves updating the model name parsing logic to correctly interpret the "@" character.

Notes

The inconsistent behavior of OpenClaw handling the "@" character sometimes may indicate a bug or an edge case that needs to be addressed. Understanding and reproducing this behavior could provide valuable insights into fixing the issue.

Recommendation

Apply a workaround by modifying OpenClaw to correctly handle the "@" character in model names, as upgrading to a fixed version is not mentioned as an option in the provided issue. This approach directly addresses the root cause of the problem.

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…

FAQ

Expected behavior

  1. /model lmstudio/qwen3.6-27b@iq3_xxs should success switch model for a session.

  2. Should send "model": "qwen3.6-27b@iq4_xs" in request to LM studio, instead of truncated "qwen3.6-27b"

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Incorrect handling on LM Studio model names with "@‘ [4 pull requests, 1 participants]