LM Studio: Run a Model and Verify Your First API Call

Make the first experiment deliberately small

LM Studio is easiest to understand when your first goal is concrete: load one local model, ask it one question, and reproduce that exchange through an HTTP request. You do not need a document index, an agent framework, or a custom chat interface to prove that the basic setup works. Those additions can wait until you can distinguish a model problem from a connection problem.

Imagine building a small script that rewrites a release note. If the script returns nothing, several things might be wrong: the server might be stopped, the model identifier might be incorrect, the input might be malformed, or the model might have failed to load. Starting with a large workflow makes those possibilities difficult to separate. A short test gives you a reference point that remains useful when the application becomes more ambitious.

This guide follows that smaller path. You will prepare a model, establish a known working chat, start a local endpoint, send a minimal request, and keep enough evidence to diagnose the next failure. The examples use the chat-completions interface offered by LM Studio. They are an instructional workflow, not a benchmark of a particular machine or a promise that every model supports the same features.

Decide what success looks like

Use a prompt whose answer you can judge without specialist knowledge. For example: “Rewrite this sentence more clearly: The update improves the way settings are saved.” A reasonable first result is a short, relevant rewrite. A perfect tone match is unnecessary; the immediate question is whether the request reaches a loaded model and produces a response that your script can read.

Write down three acceptance checks before installing anything: the model responds in the application, the HTTP endpoint returns a successful response, and a second request also completes. That last check matters because a one-off response does not establish that a repeated workflow is stable.

Keep this exercise separate from confidential documents and automated actions. A harmless sample makes it easier to share a reproduction if you need help. With the target clear, you can choose a model for the exercise rather than choosing the exercise around the largest model available.

Prepare a model in LM Studio and record its configuration

Install the application from its official distribution and review the requirements for your operating system. Avoid copying a memory requirement from someone else's screenshot: the model, its quantization, context allocation, inference runtime, and other applications all affect what your machine can accommodate. A downloadable file fitting on disk is not evidence that the intended configuration will run comfortably.

For the first exercise, prefer a chat-oriented model that the application identifies as appropriate for your hardware. Read its model card and license before using it for a real project. Record the full model name and file variant. “An eight-billion-parameter model” is not a reproducible description when several quantizations and publishers are available.

Separate the model file from a running model

Think of the model file as a program on disk and the loaded model as an active working session. Having downloaded the file does not mean it is currently ready to answer an API request. Conversely, a working server process does not prove that the model you intended to use is loaded.

The official LM Studio CLI reference documents commands for these separate states: lms ls lists downloaded models, lms ps shows loaded models, and lms load loads a model. The CLI ships with the application; the documentation says to run LM Studio at least once before using it. You can inspect the installed command's help rather than assuming that every screenshot matches your version.

# Inspect the CLI and distinguish downloaded models from loaded models.
lms --help
lms ls
lms ps

Do not paste a model name from this article into a load command without checking what you downloaded. Use the identifier shown by your installation, and keep it with your notes. If the application allows you to assign a stable identifier, choose something that describes the local test instead of pretending that it represents a different model family.

Establish a working chat first

Load the selected model in the application and submit the release-note prompt. If loading fails, solve that problem before introducing HTTP. Reduce the configuration conservatively, consult the runtime's messages, and change one setting at a time. Record the original setting so that you can undo an unsuccessful experiment.

Once a short chat succeeds, save the prompt and response alongside the model identifier. That gives you a baseline for the next stage: the same input should now travel through a different interface.

Start the server and verify the route you are calling

For a first local test, keep the client and model server on the same machine. This removes network routing and another device's firewall from the list of possible causes. In a container or virtual machine, however, “the same machine” needs more care: localhost refers to the environment where the client process runs, not automatically to the host desktop.

The server-start documentation provides the port and bind options. The following example explicitly chooses loopback and port 1234 so the intended address is visible in the command. If that port is already used, select another port and update every example consistently.

# Start a server reachable from this machine's loopback interface.
lms server start --bind 127.0.0.1 --port 1234

You can also use the application's developer controls. The important point is to know which server is running, on which port, and with which model. Do not accidentally compare one terminal's model state with another application's endpoint.

An API address is not a chat webpage

Opening the server root in a browser is an ambiguous test. A browser requests a webpage and may also request a favicon. That does not exercise a chat-completions route with the required method and JSON body. If the browser produces an endpoint warning, inspect what it requested before concluding that the model is broken.

Treat the address like a street address with a specific office inside it. Reaching the building is different from delivering the right form to the right desk. A server can be reachable while the route, method, or payload is wrong.

Check authentication intentionally

LM Studio's authentication documentation explains that token authentication requires LM Studio 0.4.0 or newer and is disabled by default. Open the Developers page, go to Server Settings, and enable Require Authentication. Use Manage Tokens to create a named token with the permissions your test needs. For this exercise, enable authentication, create an appropriately scoped token, and supply it through an environment variable in your terminal. Use your actual token; a sample string in an older tutorial is not a universal credential.

Keep the token out of source files and copied troubleshooting logs. If a request receives an authentication error, check whether the client environment contains the variable and whether the token has the necessary permission. Do not disable authentication merely to hide the symptom. Once the route and credentials are explicit, keep the request small.

Check the model identifier through the API

Before generating text, query the same server's model listing. The List Models reference documents a GET request to /v1/models. Include your token because this exercise enables authentication. Copy the identifier from your server rather than assuming a downloaded filename is the API identifier.

curl --include --fail-with-body http://127.0.0.1:1234/v1/models \
  -H "Authorization: Bearer $LM_API_TOKEN"

The listing shows models visible to the server. With just-in-time loading enabled, it can include downloaded models that are not currently loaded. Compare the result with lms ps before diagnosing a loading problem. A successful listing confirms that this particular route and authentication worked; it does not test text generation or establish that the selected model fits in memory.

If the list request succeeds but the chat request fails, preserve both results. Check the model value and request body before reinstalling the application. If both requests fail in the same way, inspect the shared address and token first. This gives you a smaller set of differences to investigate.

Send a minimal request and inspect the whole response

The first request should contain only what is necessary for a basic text response. Leave tools, retrieval, image input, streaming, and structured-output requirements out of this test. Each feature adds another contract between the client, server, runtime, and model; there is no benefit in testing all those contracts simultaneously.

The LM Studio chat-completions reference documents the messages-based interface. In the example below, replace your-loaded-model-id with the identifier from your installation. The output limit is deliberately modest because the task is a short rewrite, not a long generation.

# Send a small text-only request and show the HTTP response headers.
curl --include --fail-with-body http://127.0.0.1:1234/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $LM_API_TOKEN" \
  -d '{
    "model": "your-loaded-model-id",
    "messages": [
      {"role": "user", "content": "Rewrite clearly: The update improves the way settings are saved."}
    ],
    "temperature": 0.2,
    "max_tokens": 120,
    "stream": false
  }'

This command assumes a shell that supports the displayed quoting. In another shell, adapt the quoting or put the JSON in a file and pass that file to curl. If the shell splits the payload incorrectly, the server receives a different request from the one you think you wrote.

Read transport success and task success separately

For a non-streaming chat completion, inspect the first choice's message object, as shown in the linked reference. Keep the full JSON while developing your parser instead of discarding everything except the displayed sentence. Handle an empty list or missing message as a response your application cannot use, and save a redacted diagnostic rather than silently returning an empty rewrite.

Check the release-note example against its source: a response that claims settings now synchronize across devices adds a feature that the input never mentioned. Reject it even if the HTTP request succeeded. A shorter sentence that preserves only the original claim is a better result for this task.

First inspect the HTTP status and whether the body is valid JSON. Then inspect the returned message and completion information. A successful HTTP exchange proves that a request completed at the protocol level; it does not prove that the rewrite is accurate, useful, or suitable for automatic publication.

For this exercise, ask three questions about the text: did it preserve the original meaning, did it avoid inventing a feature, and can your application locate the intended response field? A sentence that sounds polished but adds an unsupported capability should fail the task check.

Run the same request again before making it more complex. If the second call fails, preserve both responses and compare server logs around the transition. You now have a much better report than “the API sometimes doesn't work.” Once repetition succeeds, you can add a system instruction or integrate a client library without losing the reference request.

Diagnose failures by the layer that produced them

Troubleshooting becomes slower when every failure is described as a model error. Start with the earliest point that can be verified, and move forward. Changing the prompt will not repair a stopped listener; changing the port will not repair a malformed JSON document.

Use the table as a diagnostic order, not a guarantee that one symptom has only one possible cause.

Avoid changing unrelated settings together

Suppose generation begins and then stops. Save the current configuration, try a smaller output budget or a less demanding model configuration, and repeat the same input. If the result changes, you have narrowed the problem. If you simultaneously switch model, runtime, prompt, context, and client library, you cannot tell which change mattered.

The server-settings reference also distinguishes just-in-time loading and unloading options. Those settings are worth inspecting when the loaded-model state changes between requests. They are not proof that every unexpected unload is normal behavior; a runtime crash or another failure can require a different explanation.

When reporting an issue, provide the application version, runtime, model variant, relevant settings, and a minimal request. Include the first meaningful error rather than only the final message. Later errors may simply describe the consequences of an earlier failure.

Know what you have actually tested

This guide does not claim to have benchmarked your hardware or reproduced a particular runtime defect. A successful local run establishes a narrow result: this model, configuration, and request worked in your environment. That is valuable evidence, but it should remain narrow until you test a larger workload. The next step is to turn that working configuration into a routine you can repeat.

Keep a reproducible local workflow

Create a short run note for the experiment. Include the model identifier, file variant, runtime, selected context setting, server address, authentication requirement, and the exact harmless prompt. Store the response with a date so that a future change has something concrete to compare against.

You might use a small acceptance set with three examples: a clear release note, an ambiguous sentence that needs clarification, and an input asking for a claim the source text does not support. Judge the responses against your requirements rather than against whichever answer happens to sound most confident. For a rewriting tool, preserving meaning can matter more than producing a lively tone.

Verify the local boundary instead of assuming it

The offline-operation documentation distinguishes local inference from operations such as downloading models and runtimes. Prepare the required files before testing without connectivity. Also inspect any optional services or integrations you enable: a locally running model does not make an external web tool or cloud feature local.

For a practical check, restart the application under the conditions you expect to use, repeat your small prompt, and repeat the API call. Record any dependency that prevents the test from completing. If offline operation is a requirement, make that a specific acceptance check rather than a reassuring label in the project description.

Expand one capability at a time

After the text-only baseline is reliable, add the feature your application actually needs next. That might be streaming for a chat interface, structured output for a parser, or a document workflow. Keep the original request unchanged so that you can still isolate the core service if the new feature fails.

Choose a stopping point as well. For the release-note example, a useful first milestone is a script that returns a candidate rewrite and leaves approval to the person reviewing the source. There is no need to add autonomous publication to demonstrate that the local model is useful.

Keep the working request with your model and runtime notes. When you change the setup, repeat that request before adding another feature. You will have a concrete comparison when a model update, server setting, or client change affects the result.