fix(app): fetch live LM Studio models instead of static catalog#2367
fix(app): fetch live LM Studio models instead of static catalog#2367smundhra-git wants to merge 1 commit into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
@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. |
|
@smundhra-git I tried to verify this locally using a fake LM Studio-compatible server on I confirmed the PR build is running locally and includes the new 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
left a comment
There was a problem hiding this comment.
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.
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/modelsendpoint on older buildsLMSTUDIO_PROVIDER_CONFIGconstant inopenai-image-extension.tsextensions.ts(settings-panel +provider-connectedenablement)settings-route.tsxext-lmstudio.svgiconThe selected live model is written into
opencode.jsoncvia the existing genericinstallLocalProviderflow.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
ollama-config.tsxstructure/imports