In this article
LM Studio desktop chat proves one generation path; the editor still needs an available serving process and its own correct model selection.
If LM Studio chat works but an editor cannot use it, first inspect the local server and the editor’s own selection. Desktop generation and external-client serving are separate paths, so the working chat narrows the problem without configuring the editor.
The concrete application boundary
The desktop conversation proves that a particular model can answer through that application at that moment. It does not prove that the HTTP server is running, that the editor uses its actual address, or that the editor requests the same model. LM Studio also separates the graphical application, llmster daemon, and lms controller. Identify which runtime is intended to own the editor connection. Avoid starting an extra runtime immediately: two independent processes can make it harder to determine which model a caller reached. Preserve the working conversation and inspect the external path one boundary at a time, without changing the model file or tuning GPU parameters (LM Studio application guide) (LM Studio, llmster, and lms).
A practical route
Open LM Studio’s developer/server surface and confirm the serving state and displayed address. Inspect available and loaded models; lms ls concerns files while loading and server startup are separate operations. In the editor’s provider settings compare the chosen integration type, address, and requested model with that current server. Begin with a read-only request containing pasted source text rather than a tool-driven repository task. Once an answer appears, ask the editor to explain an explicitly selected file and inspect whether its supplied context changed (LM Studio developer documentation).
A worked example
A user can discuss a formatter in LM Studio but the editor reports an unavailable model. The editor still points to a model entry from an earlier session. Correct that client selection while leaving the successful desktop model unchanged. Then ask about the same pasted function. If the pasted example works but the selected-file task does not, investigate editor context rather than treating both failures as the same model outage.
| Check | Record |
|---|---|
| Desktop baseline | The model that answered in the current application conversation. |
| Serving baseline | The runtime process and displayed local server address. |
| Editor baseline | The client’s actual provider choice, requested model, and supplied source. |
Reading the failure correctly
A server can be reachable while a caller requests a model that is not available under that identity. A file can also be visible in the editor without being included in model context. Tool execution adds another layer after text generation. Keep these observations separate so a successful correction does not accidentally conceal a second independent problem.
What completes the check
The repair is complete when the editor reaches the intended local model and explains the supplied source. Retain the original desktop baseline; it remains useful evidence if another client later fails.
Related background: llama.cpp server: a local API from a GGUF model, VRAM for LLMs: why model size is only part of the calculation.