lmstudio: migrate old custom provider setup to new integrated support, or not? | Friends of the Crustacean 🦞🤝 | Page 1

dark canopy Apr 23, 2026, 7:46 AM

#

if I have been using lmstudio before the official integration, is there any point in doing the new onboarding? i occasionally manually edit the openclaw.json and agents/main/models.json files when I add new models, does that get easier with the official integration? i don't want all my lmstudio models in openclaw

i have different agents set up to use different models by default, ther are models assigned for specific cron jobs, and I have fallback models defined for each agent.

foggy bridgeBOT Apr 23, 2026, 7:46 AM

#

covert grailBOT Apr 23, 2026, 7:46 AM

#

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

foggy bridgeBOT Apr 23, 2026, 7:46 AM

#

past depotBOT Apr 23, 2026, 7:50 AM

#

Short version: no, you do not need to re-onboard just because LM Studio got official support.

If your old setup already works, I’d only switch if you want the specific LM Studio-native benefits:

native model discovery + auto-load (/api/v1/models and /api/v1/models/load)
less fragile than treating LM Studio as a generic custom OpenAI endpoint
easier adding of individual models with /models add lmstudio <modelId> instead of hand-editing both config files
better LM Studio-specific auth/base URL handling

But there is an important catch for your case:

the official LM Studio onboarding discovers the models LM Studio exposes and saves them into config
so if you do not want all LM Studio models showing up in OpenClaw, onboarding is probably not the best fit as-is

Given your setup, my recommendation would be:

If everything works now, keep it

#

If you want the new LM Studio-native behavior, migrate manually to the lmstudio provider instead of running onboarding, and only keep the specific model entries you want
Then use /models add lmstudio ... for one-offs going forward

Also, re-running onboarding does not wipe everything unless you choose reset, but it can rewrite the global default model/provider bits, so I would not run it casually when you already have per-agent defaults, cron models, and fallback chains tuned.

So, bluntly: for your setup, the official integration is useful, but the onboarding wizard is optional and maybe slightly annoying.

Docs:

If you want, I can help sketch the clean manual migration path from old custom provider → official lmstudio provider without importing all models.

dark canopy Apr 23, 2026, 8:42 AM

#

model auto-loading has been working since before the official provider, what is the benefit of the official provider for that?

and when exactly does:

native model discovery + auto-load (/api/v1/models and /api/v1/models/load)
become active? ie at what moments does this take place?

past depotBOT Apr 23, 2026, 8:44 AM

#

Yeah, if LM Studio auto-loading was already working for you, then the benefit is not “it can finally auto-load”.

The official provider mainly gives you provider-aware behavior, not just generic OpenAI-compatible behavior:

OpenClaw can check LM Studio’s actual load state via /api/v1/models
it can request a load with a target context_length via /api/v1/models/load
it can do the same kind of warmup for embeddings, not just chat
it gets LM Studio-native discovery/metadata, so /models add lmstudio ... and model detection are cleaner

So the real upgrade is more like:
“OpenClaw understands LM Studio specifically”, not just “OpenClaw can send requests to a local endpoint”.

When does it become active?

There are basically 2 separate things:

1. Discovery, `/api/v1/models`

#

This gets used when OpenClaw wants to inspect LM Studio’s model list / load state, for example:

onboarding / LM Studio setup
/models add lmstudio ...
dynamic LM Studio model resolution/catalog refresh
before LM Studio inference preload, to see whether the target model is already loaded and with what context length

2. Auto-load, `/api/v1/models/load`

This gets used right before an LM Studio request, but only if the preflight says:

the model is not loaded, or
it is loaded with less context than OpenClaw wants

If the model is already loaded at a sufficient context length, OpenClaw skips /load.

Important nuance

#

For chat/inference, the official LM Studio provider does a best-effort preload before the stream starts.

So in practice, on an LM Studio-backed chat request:

OpenClaw checks /api/v1/models
if needed, it calls /api/v1/models/load
then it sends the actual inference request to /v1/chat/completions

If preload fails, it logs a warning and still continues with inference, so it is intentionally not fatal.

So, blunt version:

if your old setup already loads models fine, the official provider won’t feel magical
the main value is cleaner LM Studio-specific control and metadata
if you do not want all LM Studio models imported, I still think manual migration to the lmstudio provider is better than full onboarding for your setup

Docs: https://docs.openclaw.ai/providers/lmstudio

#

If you want, I can outline the minimal manual migration that keeps your curated model list and existing agent/cron setup intact.

dark canopy Apr 23, 2026, 8:53 AM

#

hmm, currently the relevant section of my openclaw.json looks like

 "models": {
    "mode": "merge",
    "providers": {
      "lmstudio": {
        "baseUrl": "https://[redacted]:1234/v1",
        "apiKey": {
          "source": "file",
          "provider": "default",
          "id": "/lmstudio/apiKey"
        },
        "api": "anthropic-messages",
        "models": [
          {
            "id": "qwen/qwen3.5-35b-a3b",
          [etc]

this looks a lot like that section in the official docs.

what would I actually need to change?

past depotBOT Apr 23, 2026, 8:54 AM

#

Honestly, very little.

That config is already the big clue: because your provider id is already lmstudio, you are basically already on the official provider path. The LM Studio plugin behavior is keyed off the provider id, not “whether onboarding was used”.

So onboarding would mostly just write a similar block for you.

What I’d actually change

If you want to match the docs more closely, the main thing is:

api: "openai-completions"

instead of:

#

api: "anthropic-messages"

That is the main canonical LM Studio transport in the docs.

What I would not change

your curated models list, keep that if you do not want every LM Studio model exposed
your per-agent defaults
your cron-specific model assignments
your fallback chains

So the practical answer is

If your current setup works, you probably do not need onboarding at all.

#

You are already pretty close to the official shape:

provider: lmstudio ✅
baseUrl ✅
secret-backed apiKey ✅
explicit curated models ✅

My recommendation

If anthropic-messages is working well for you, I would not change it just to be “more official”
If you want to align with the built-in LM Studio docs/assumptions, test switching only:
- api: "anthropic-messages" → api: "openai-completions"

That is the one change that actually matters.

So, bluntly: you are not missing some magical onboarding-only migration step. You mostly already did it.

Docs:

#

If you want, I can also give you a “leave everything else alone, only change the minimum” version of that provider block.

dark canopy Apr 23, 2026, 8:58 AM

#

i accidentally wrote my config in a way that was future proof? amazing, well done past me!

past depotBOT Apr 23, 2026, 8:58 AM

#

Yeah, pretty much 😄

Past you absolutely did Future You a favor here. You were already using the right provider shape, so the official integration mostly just grew into what you had.

Tiny support crustacean verdict: past you cooked 🦐

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
That helps Answer Overflow index it for the next person.

#lmstudio: migrate old custom provider setup to new integrated support, or not?