fix(app): fetch live LM Studio models instead of static catalog

[smundhra-git]

Summary

Connecting LM Studio surfaced three hardcoded models from the models.dev catalog (gpt-oss-20b, qwen3-30b, qwen3-coder-30b) regardless of what the user actually had downloaded.

This mirrors the existing Ollama integration so LM Studio gets a dedicated settings panel that queries the running local server (http://127.0.0.1:1234) and lists the user's real models.

Changes

• lmstudio-config.tsx — settings panel fetching /api/v0/models (rich metadata: type, state, context length), falling back to the OpenAI-compatible /v1/models endpoint on older builds
• LMSTUDIO_PROVIDER_CONFIG constant in openai-image-extension.ts
• registered the panel as a built-in extension in extensions.ts (settings-panel + provider-connected enablement)
• side-effect import wired in settings-route.tsx
• ext-lmstudio.svg icon

The selected live model is written into opencode.jsonc via the existing generic installLocalProvider flow.

Root cause

Ollama is absent from the models.dev catalog, so OpenWork already ships a live-fetch panel for it. LM Studio is in the catalog with static models and had no equivalent panel — so the catalog's fixed list was shown instead of the running server's models.

Testing

• Verified the new panel mirrors the known-good ollama-config.tsx structure/imports
• No tests assert on the built-in extension list

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openwork-landing	Ready	Preview, Comment, Open in v0	Jun 25, 2026 12:27am

[vercel]

@smundhra-git is attempting to deploy a commit to the Different AI Team on Vercel.

A member of the Team first needs to authorize it.

[cubic-dev-ai]

No issues found across 5 files

_{Re-trigger cubic}

[Iflaqbhat]

@smundhra-git I tried to verify this locally using a fake LM Studio-compatible server on 127.0.0.1:1234 returning iflaq-test-model-a from /api/v0/models.

I confirmed the PR build is running locally and includes the new lmstudio built-in extension, but I could not reach the new LM Studio panel from the normal signed-out local flow. In Settings > Extensions > My Extensions, searching lm returns no results because the quick-connect list filters out inactive built-in OpenWork extensions. Add Custom App only opens the MCP custom-app modal, so it does not help with LM Studio provider setup. The Marketplace view also appears gated behind Cloud sign-in / active org state.

That makes this hard to verify from the original bug flow: the issue reports “Go to model → Connect to LM Studio”, but this PR adds a new built-in extension panel that a local signed-out user may not naturally discover.

Could we either surface LM Studio in the normal local Extensions available-apps list, or update the existing provider/model connection flow so the reported LM Studio path fetches live local models too?

[Pablosinyores]

Nice fix — pulling the live list from /api/v0/models with the /v1/models fallback is the right call, and filtering embeddings out of the selectable list on the native endpoint is a good touch.

One real edge worth handling: the selected-model state can go stale across a refresh. The effect only seeds selectedModel when it is empty:

if (!selectedModel && models[0]) setSelectedModel(models[0].id);

After a Refresh where the previously selected model is no longer loaded (user unloaded/removed it in LM Studio), selectedModel keeps the old id. It is no longer in models, but it is non-empty, so the effect will not reseed it and the Add button stays enabled (it only guards on !selectedModel). You would then install a model id LM Studio no longer lists. Reconciling on each refresh fixes it, e.g.:

if (selectedModel && !models.some(m => m.id === selectedModel)) {
  setSelectedModel(models[0]?.id ?? "");
}

Smaller note: the /v1/models fallback branch does not carry type, so embeddings models will not be filtered there the way they are on /api/v0/models. Probably fine to leave on older builds, just flagging the asymmetry.

[Pablosinyores]

Clean mirror of the Ollama integration — native /api/v0/models first (with a 3s AbortSignal.timeout and richer metadata), OpenAI-compatible /v1/models fallback, and the not-ok-native → fallback path is handled correctly (no throw needed to fall through). Two small things:

1. Embeddings only filtered on the native path. The native branch drops type === "embeddings", but the /v1/models fallback has no type to filter on, so on older LM Studio builds embedding models will appear in the selectable list. Minor, but a user could pick one and get a provider that can't chat.

2. selectedModel isn't revalidated after a refetch. The useEffect only auto-selects when !selectedModel. If the chosen model disappears from a later refetch (unloaded/removed), selectedModel stays pointing at the now-absent id and Install would write a model that isn't there. Resetting when selectedModel is not in models would harden it.

Optional: the host is hardcoded to http://127.0.0.1:1234 (matches the Ollama pattern), so a non-default LM Studio port isn't reachable — fine as a follow-up.

Otherwise LGTM — the live-fetch replacing the three hardcoded catalog entries is the right fix.