Skip to content

fix: tolerate unknown LM Studio reasoning levels - #48

Open
dgnsrekt wants to merge 1 commit into
agustif:mainfrom
dgnsrekt:fix/tolerate-unknown-reasoning-levels
Open

fix: tolerate unknown LM Studio reasoning levels#48
dgnsrekt wants to merge 1 commit into
agustif:mainfrom
dgnsrekt:fix/tolerate-unknown-reasoning-levels

Conversation

@dgnsrekt

Copy link
Copy Markdown

Problem

rc.2 discovers no models at all against current LM Studio builds.

LMStudioCapabilitiesSchema pins reasoning values to off|on|low|medium|high. LM Studio now publishes an xhigh level:

"reasoning": {
  "allowed_options": ["off", "low", "medium", "xhigh", "on"],
  "default": "xhigh"
}

Because the enum sits inside LMStudioModelsResponseSchema, one model carrying xhigh fails safeParse for the whole payload:

models.0.capabilities.reasoning.allowed_options.3 | Invalid option: expected one of "off"|"on"|"low"|"medium"|"high"
models.0.capabilities.reasoning.default           | Invalid option: expected one of "off"|"on"|"low"|"medium"|"high"

discoverModels throws unsupported response, so the config hook logs LM Studio model discovery unavailable and contributes nothing. The provider then falls back to models.dev's built-in lmstudio catalog, offering models the user has never downloaded.

On my instance 2 of 37 records report xhigh, and discovery returned 0 models.

Fix

Accept any string for allowed_options and default.

This block is parsed but never mapped — per the v1 contract, OpenCode's reasoning flag is deliberately left unset "until the two projects publish an interoperable mapping." Validating the values strictly gains nothing today and costs total discovery every time LM Studio adds a level. The known levels stay as an exported KNOWN_REASONING_LEVELS constant for documentation.

I went with permissive rather than adding xhigh to the enum so the next new level can't reproduce this.

Verification

Regression test added — it fails on main with LMStudioAPIError: LM Studio models API returned an unsupported response and passes with the fix.

npm run validate clean (lint, typecheck, 28 tests, build).

End-to-end against LM Studio 0.4.x with 37 records, via opencode models lmstudio:

before after
models discovered 0 (3 models.dev phantoms) 29

Notes

Related to #34. This is a prerequisite for a follow-up PR I'd like to send adding an opt-in onlyLoaded option (#17) — that one can't be exercised at all until discovery works.

🤖 Generated with Claude Code

https://claude.ai/code/session_01S7Wjrr4wy4Eiig1PqtHfpD

`capabilities.reasoning` pinned `allowed_options` and `default` to
`off|on|low|medium|high`. LM Studio now publishes an `xhigh` level, and
because the enum sits inside the response schema a single model carrying
it fails `LMStudioModelsResponseSchema.safeParse` for the entire payload.
`discoverModels` then throws `unsupported response`, so discovery yields
no models at all and the provider falls back to models.dev entries the
user has not downloaded.

The reasoning block is parsed but never mapped: the v1 contract leaves
OpenCode's `reasoning` flag unset until both projects publish an
interoperable mapping. Validating these values strictly gains nothing and
costs total discovery whenever LM Studio adds a level.

Accept any string and keep the known levels as an exported constant for
documentation, so a future level cannot break discovery the same way.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S7Wjrr4wy4Eiig1PqtHfpD
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants