# Use the LM Studio local API from an editor

Connect an editor to the LM Studio local server, verify the selected model, and test explanation before allowing file edits.

Author: Retrivium team
Updated: 2026-11-03
Canonical URL: https://retrivium.ai/journal/lm-studio-local-api-app-onboarding/
Language: en

To use the LM Studio local API from an editor, establish the server independently of the desktop chat, then verify the editor’s selected model and first operation. A working conversation window is useful evidence, but it does not configure a second application.

## The concrete application boundary

There are two independent handoffs in an editor integration. The runtime exposes a serving interface, and the editor constructs requests to that interface using its selected provider and model. A downloaded file in LM Studio does not fill the editor’s provider configuration. Likewise, changing a chat title does not change the model identifier expected by the server. The developer documentation offers native and compatible integration surfaces; choose the one the editor actually supports. For a local exercise, keep both applications on the same computer and use the server address displayed in the current session. This avoids mixing application onboarding with an unrelated network arrangement ([LM Studio application guide](https://lmstudio.ai/docs/app)) ([LM Studio, llmster, and lms](https://lmstudio.ai/docs/app/basics/lmstudio-vs-llmster-vs-lms)).

## A practical route

In LM Studio identify the model intended for the editor and start the local serving interface. Copy the displayed address rather than guessing a value from an old screenshot. In the editor choose the compatible connection type, enter the actual model identity, and begin with an explanation request that cannot change files ([LM Studio developer documentation](https://lmstudio.ai/docs/developer)).

## A worked example

Open a small function that trims an input string. Ask the editor to explain its behavior for an empty value and include the selected file as context. Compare the answer with the desktop baseline. Next request a proposed test, reviewing the diff before accepting it. This checks application handoff without giving the assistant a broad repository task.

| Check | Record |
| --- | --- |
| Runtime record | The selected model and the local server address shown by LM Studio. |
| Caller record | The editor connection name, requested model, and supplied source selection. |
| Review record | The explanation and proposed test, with the visible diff kept separately. |

## Reading the failure correctly

If the editor cannot connect, distinguish an unavailable server from a model selection problem. If it answers about another file, inspect editor context rather than restarting the runtime. If it asks for tools, identify which client will execute them before enabling anything: generation and file operations have different owners.

## What completes the check

Repeat the explanation after reopening the editor. Success means the intended client reaches the intended model and provides the intended source text. A saved editor profile alone does not demonstrate that the local server remains available or that a file edit was reviewed.

Related background: [llama.cpp server: a local API from a GGUF model](/journal/llama-cpp-server-launch/), [VRAM for LLMs: why model size is only part of the calculation](/journal/vram-and-models/).