lmstudio no longer works after update from 4.23 to 5.12

[vast solar]

lmstudio requests simply timeout after updating from 4.23 to 5.12, didn't notice at first as it was falling back to sonnet.

[clear turret]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[snow fulcrum]

First thing: can you paste openclaw --version? Version skew around provider/config migrations is a common cause here.

For LM Studio specifically, I’d check these in order:

openclaw status
openclaw models status
curl http://127.0.0.1:1234/v1/models
curl http://127.0.0.1:1234/v1/chat/completions \
  -H 'content-type: application/json' \
  -d '{"model":"<lmstudio-model-id>","messages":[{"role":"user","content":"hi"}],"stream":false}'
openclaw infer model run --model lmstudio/<lmstudio-model-id> --prompt "hi" --json
openclaw logs --follow

A few likely culprits after the update:

[snow fulcrum]

• LM Studio server/JIT: make sure the server is actually running, the model is loaded or JIT is enabled, and the model id matches what LM Studio exposes.
• Auth token: OpenClaw requires a non-empty LM Studio token value. If LM Studio auth is disabled, a placeholder token is fine.
• API adapter mismatch: current docs recommend LM Studio via api: "openai-responses" for local models; older setups may still be on openai-completions.
• Backend compatibility: if tiny direct curl works but OpenClaw times out/fails on full agent turns, try lowering prompt pressure and/or setting model compat flags like compat.supportsTools: false or compat.requiresStringContent: true if logs point that way.

Docs:
https://docs.openclaw.ai/providers/lmstudio
https://docs.openclaw.ai/gateway/local-models
https://docs.openclaw.ai/gateway/troubleshooting#local-openai-compatible-backend-passes-direct-probes-but-agent-runs-fail

The key thing I’d want next is the version plus the first failing log lines from openclaw logs --follow, especially whether it’s timing out before reaching LM Studio or LM Studio is accepting the request and then hanging.

[vast solar]

worked in 4.23

stopped working as soon as I updated to 5.12

I can confirm that it's running and I can use it outside openclaw

[snow fulcrum]

Yep, that version jump matters. I checked the 2026.5.12 installed docs, and there are a couple LM Studio behaviors/configs that can explain “worked on 4.23, now times out”.

The first thing I’d try is disabling OpenClaw’s LM Studio preload step. 5.12 docs say OpenClaw preloads LM Studio models through LM Studio’s native load endpoint by default; if that path is hanging after the upgrade, regular requests can look like timeouts.

In your models.providers.lmstudio config, try:

{
  models: {
    providers: {
      lmstudio: {
        baseUrl: "http://localhost:1234/v1",
        api: "openai-completions",
        params: { preload: false }
      }
    }

[snow fulcrum]

  }
}

Then restart the gateway and test:

openclaw gateway restart
openclaw infer model run --local --model lmstudio/<your-model-id> --prompt "Reply with exactly: pong" --json
openclaw infer model run --gateway --model lmstudio/<your-model-id> --prompt "Reply with exactly: pong" --json

If LM Studio is just slow/cold-loading, also add a provider timeout before raising the whole agent timeout:

[snow fulcrum]

models: {
  providers: {
    lmstudio: {
      timeoutSeconds: 300
    }
  }
}

Also worth checking after the update:

curl http://127.0.0.1:1234/v1/models
openclaw config get models.providers.lmstudio
openclaw logs --follow

[snow fulcrum]

If the curl works but openclaw infer ... --local times out, that points at OpenClaw↔LM Studio request shaping/preload/auth. If --local works but --gateway or real agent turns time out, try agents.defaults.experimental.localModelLean: true or temporarily compat.supportsTools: false on that LM Studio model entry.

Docs I’m reading from:
https://docs.openclaw.ai/providers/lmstudio
https://docs.openclaw.ai/gateway/local-models

[snow fulcrum]

Good, that narrows it: LM Studio is healthy, so this is probably OpenClaw’s provider path, saved config, or the heavier agent request shape.

Can you run these two probes with the exact model ref OpenClaw is using?

openclaw models status
openclaw config get models.providers.lmstudio
openclaw infer model run --local --model lmstudio/<your-model-id> --prompt "Reply with exactly: pong" --json
openclaw infer model run --gateway --model lmstudio/<your-model-id> --prompt "Reply with exactly: pong" --json

How to read it:

• --local fails/timeouts: likely LM Studio provider config/auth/preload/request adapter. Try params: { preload: false }, confirm baseUrl ends in /v1, and confirm the model id is the bare LM Studio id in the provider config.
• --local works but --gateway fails: gateway routing/session/auth/config issue. Logs should show it.
• both probes work but real chat times out: the full agent prompt/tools are too heavy or triggering LM Studio weirdness. Try agents.defaults.experimental.localModelLean: true, then if needed set compat.supportsTools: false on that model entry.

[snow fulcrum]

Also please paste the relevant few lines from:

openclaw logs --follow

Specifically around the timeout. The difference between “OpenClaw never reaches LM Studio” and “LM Studio accepts the request then hangs” matters here.

[vast solar]

I'm setting up lmstudio via the native connector instead of the custom one now. When I set it up I actually get a list of models, then when I select the model and open the tui it doesn't work, even confirming the correct one is selected and the gateway has been restarted.

[snow fulcrum]

That detail is important: model listing uses LM Studio’s discovery endpoint, while the TUI turn uses the inference path. So discovery working doesn’t prove the actual chat request is healthy.

Given 5.12, I’d test the preload path first. There’s a 5.12 changelog entry specifically around LM Studio native preload behavior, and the docs now expose a bypass for it.

Try adding this to the native lmstudio provider:

{
  models: {
    providers: {
      lmstudio: {
        params: { preload: false },
        timeoutSeconds: 300
      }
    }
  }

[snow fulcrum]

}

Keep your existing baseUrl, api, models, etc. Then restart:

openclaw gateway restart

Then run this outside the TUI:

openclaw infer model run --gateway --model lmstudio/<selected-model-id> --prompt "Reply with exactly: pong" --json

If that hangs too, it’s not TUI-specific. Please grab the matching openclaw logs --follow lines. I’d look for one of these:

[snow fulcrum]

• preload/load call hanging or failing
• model_not_found despite discovery listing it
• messages/content validation errors
• empty/incomplete turn warnings
• timeout after LM Studio accepted the request

If the gateway probe works but the TUI still doesn’t, then the next suspect is full agent context/tools. In that case try:

{
  agents: {
    defaults: {
      experimental: { localModelLean: true }
    }
  }
}

[snow fulcrum]

Docs for the two relevant bits:
https://docs.openclaw.ai/providers/lmstudio
https://docs.openclaw.ai/gateway/local-models

[vast solar]

sonnet works when it falls back to sonnet...

[snow fulcrum]

Right, that confirms the TUI/gateway/session path is basically alive. The failing piece is specifically the lmstudio model call, and fallback is masking the actual error.

For debugging, temporarily remove/disable the Sonnet fallback or run the model directly so the LM Studio failure is exposed:

openclaw infer model run --gateway --model lmstudio/<selected-model-id> --prompt "Reply with exactly: pong" --json
openclaw logs --follow

If you want to force chat to show the LM Studio failure instead of silently recovering, temporarily set the primary to only the LM Studio model and no fallbacks, then restart the gateway. But the direct infer model run --gateway probe is cleaner.

Given what you’ve said, I’d still try this first on the native provider:

params: { preload: false },
timeoutSeconds: 300

[snow fulcrum]

If that doesn’t change it, the logs from the direct probe are the next useful thing. We need to see whether OpenClaw is timing out on preload, auth/request shaping, or LM Studio accepting the full request and then never producing a usable final response.

[vast solar]

seeing a lot of:
17:12:16+00:00 warn security {"subsystem":"security"} blocked URL fetch (url-fetch) targetOrigin=http://192.168.1.220:1234 reason=Blocked hostname or private/internal/special-use IP address

[snow fulcrum]

That’s the smoking claw. OpenClaw is blocking the LM Studio URL before inference because 192.168.1.220 is a private LAN address.

Set the provider request guard to explicitly allow that private endpoint. For native LM Studio:

{
  models: {
    providers: {
      lmstudio: {
        baseUrl: "http://192.168.1.220:1234/v1",
        request: {
          allowPrivateNetwork: true
        }
      }
    }
  }

[snow fulcrum]

}

Then restart:

openclaw gateway restart

If you’re still using a custom provider id anywhere, use that id instead of lmstudio:

models.providers.<provider-id>.request.allowPrivateNetwork: true

Also confirm the configured URL includes /v1:

[snow fulcrum]

openclaw config get models.providers.lmstudio

The docs say the native lmstudio provider should trust configured local/private endpoints, so if this is happening after native setup, that may be a 5.12 regression or migration edge case. The explicit request.allowPrivateNetwork: true is the right workaround; if it fixes it, this is probably worth filing as a GitHub issue with that log line and your provider config shape: https://github.com/openclaw/openclaw/issues

[vast solar]

yup that's all it was. thanks Krill!