LM Studio Connection Errors in Cline, Continue.dev, and Aider: Every Fix for ECONNREFUSED, 404, and 'No Models Loaded' in 2026

By AICoderScope Team · 12 min read
lm-studioclinecontinue-devaiderlocal-llmerror-fix

TL;DR: LM Studio’s chat tab works, but Cline, Continue.dev, or Aider throws ECONNREFUSED 127.0.0.1:1234, a 404, or No models loaded. The three causes that cover nearly every case: the server was never started (the chat UI doesn’t start it), the client resolved localhost to IPv6 while the server listens on IPv4, or no model is loaded and just-in-time loading is off. One curl tells you which one you have.

After this guide you’ll be able to:

  • Diagnose any LM Studio connection failure in under a minute with two curl commands
  • Fix the exact error string each tool shows — Cline, Continue.dev, and Aider fail differently against the same server
  • Stop the two silent traps: LM Studio returning HTTP 200 for wrong endpoints, and JIT auto-unload evicting your model mid-session

Honest take: Don’t touch your editor config until curl http://127.0.0.1:1234/v1/models returns JSON in the same environment your editor runs in. If that curl fails, no amount of Cline or Continue settings will save you — the problem is on the LM Studio side, and it’s almost always “the server isn’t actually running.”

This is the LM Studio companion to our Ollama connection troubleshooter. Same clients, different server, different failure modes. Tested against LM Studio 0.4.20 (released July 22, 2026), Cline 3.86, Continue.dev 1.3, and Aider 0.86.2 on August 1, 2026.

The 60-second diagnosis

Run this in a terminal — on the same machine, in the same environment (WSL vs Windows matters, more below) as the tool that’s failing:

$ curl http://127.0.0.1:1234/v1/models
{
  "data": [
    {
      "id": "qwen2.5-coder-32b-instruct",
      "object": "model",
      "owned_by": "organization_owner"
    }
  ],
  "object": "list"
}

Three outcomes, three branches:

What curl returnsWhat it meansJump to
Connection refusedServer not running, or wrong port/addressFix #1
JSON with an empty data: [] listServer up, no model loaded, JIT offFix #4
JSON with your model listedServer and model are fine — the bug is in the client configFixes #2, #3, #5

And the error-string map, since each tool reports the same failure differently:

Error you seeToolCauseFix
ECONNREFUSED 127.0.0.1:1234 / fetch failedCline, Continue.devServer not started, or IPv6 mismatch#1, #2
Unexpected endpoint or method. (...) Returning 200 anywayanyMissing or doubled /v1 in the base URL#3
No models loaded. Please load a model in the developer page or use the lms load command.anyNothing in memory, JIT off or broken#4
model_not_found / 500 on /v1/chat/completionsCline, AiderModel ID doesn’t exactly match#5
”You may need to load the model with a larger context length”ClineModel loaded with too-small context#6
Works on the host, fails in WSL/Docker/another machineanyNetwork boundary — loopback doesn’t cross it#7

Fix #1: the server isn’t actually running

The most common cause, and the least obvious to anyone coming from Ollama: having LM Studio open is not the same as having its server running. Ollama’s daemon listens on port 11434 the moment it starts. LM Studio’s OpenAI-compatible server is off until you switch it on — chatting with a model in the LM Studio window proves nothing about port 1234.

Open the Developer tab (Ctrl+Shift+D on Windows/Linux — visible once Developer Mode is enabled in settings) and flip Start Server. The log pane should print:

Server started on port 1234
Listening: http://localhost:1234

Or skip the GUI and use the lms CLI that ships with 0.4.x:

$ lms server start
Starting server...
Success! Server is now running on port 1234
$ lms server status
The server is running on port 1234.

The server does not survive quitting the app unless you run headless via lms server start. If your connection “randomly stopped working since yesterday,” check whether LM Studio was restarted and the server toggle reset — this exact sequence generates a steady stream of duplicate bug reports on the LM Studio bug tracker.

If the server claims it’s running but curl still refuses: check the port. The Developer panel lets you change it, and a previous session’s custom port (say, 1235 to dodge a conflict) persists. Your client config must match whatever the panel shows.

Fix #2: swap localhost for 127.0.0.1

Cline and Continue.dev are Node/Electron applications. On dual-stack machines, Node’s resolver frequently returns the IPv6 address ::1 for localhost before the IPv4 127.0.0.1 — and if the server is listening on IPv4 only, the client dials a port where nothing answers and reports ECONNREFUSED or a bare fetch failed. We documented the same mechanism against Ollama; the clients are identical, so the fix transfers unchanged.

In every tool config, prefer the explicit IPv4 loopback:

  • Not http://localhost:1234/v1
  • Use http://127.0.0.1:1234/v1

Cline’s own provider documentation defaults to http://127.0.0.1:1234 for exactly this reason. It’s a ten-second change and it’s the first thing to try when curl succeeds but the editor doesn’t.

Fix #3: the /v1 path — and the 200-that-should-be-a-404 trap

LM Studio’s OpenAI-compatible endpoints all live under /v1:

GET  /v1/models
POST /v1/chat/completions
POST /v1/completions
POST /v1/embeddings

Hit anything else and LM Studio logs Unexpected endpoint or method. (GET /models). Returning 200 anyway — and that last clause is the trap. Instead of a 404 status, the server returns HTTP 200 with an error body (tracked as bug-tracker #1323). Clients that check status codes think the request succeeded, then choke parsing the error text. In practice this surfaces as Continue.dev showing an empty response, or Aider printing a JSON decode error instead of a clean “wrong URL” message.

Two ways to get here:

Missing /v1. Aider’s OPENAI_API_BASE and Continue’s apiBase both need the full http://127.0.0.1:1234/v1. Cline’s LM Studio provider wants the bare http://127.0.0.1:1234 — it appends the path itself. Yes, that’s inconsistent across tools; it’s the single most copy-paste-hostile detail in this stack.

Doubled /v1. Continue.dev’s lmstudio provider has historically appended /v1 to some configured bases, producing requests to /v1/v1/chat/completions. If your LM Studio server log shows a doubled path, trim your apiBase and reload.

When in doubt, watch the server log pane in the Developer tab while the tool makes one request. The log prints the exact method and path received — it settles any URL debate in one line.

Fix #4: “No models loaded” and the JIT auto-unload trap

The full error text:

No models loaded. Please load a model in the developer page or use the `lms load` command.

The server is healthy; its memory is empty. Load something:

$ lms ls          # what's downloaded
$ lms ps          # what's actually in memory right now
$ lms load qwen2.5-coder-32b-instruct --context-length 32768 --gpu max

Whether a request can trigger loading automatically depends on the just-in-time model loading toggle in the server settings:

  • JIT on (default for fresh installs): /v1/models lists every downloaded model, and a chat request for an unloaded one loads it on demand. First request after a cold start takes 15–60 seconds while the GGUF streams into VRAM — Cline’s request timeout can fire first and print fetch failed even though nothing is wrong. Pre-warm with lms load or one chat message in the GUI.
  • JIT off: /v1/models lists only what’s in memory, and requests for anything else fail. If your tool’s model dropdown shows a model that then errors on use, this discrepancy is usually why.

The companion trap is auto unload: LM Studio can evict JIT-loaded models after idle time to reclaim VRAM. Step away for lunch mid-session and your next Cline request pays the full reload delay — or times out. For a dedicated coding box, load the model explicitly with lms load (explicit loads aren’t auto-evicted the way JIT loads are) or disable auto-unload in server settings.

If the model itself fails to load — process crashes, exit codes, out-of-memory — that’s a different article: our sister site covers it in LM Studio “Failed to Load Model”: decode the exit code, then fix it.

Fix #5: model ID mismatches — three tools, three behaviors

Same server, three different client behaviors when the model field doesn’t match:

Cline matches strictly. If the model string in Cline’s LM Studio provider settings doesn’t exactly equal an ID from /v1/models, the request 500s. Don’t type it — copy it: curl -s http://127.0.0.1:1234/v1/models | grep '"id"' and paste the exact value.

Continue.dev is forgiving to the point of being misleading: with the lmstudio provider, LM Studio routes the request to whatever model is currently loaded, largely regardless of the name in config.yaml. Convenient — until you’re benchmarking what you think is a 32B model while a 7B is actually loaded. Check lms ps before you trust any output quality judgment.

Aider goes through the openai/ prefix and needs both environment variables set — the key just has to be non-empty:

export OPENAI_API_BASE=http://127.0.0.1:1234/v1
export OPENAI_API_KEY=lm-studio   # any non-empty string; LM Studio ignores it locally
aider --model "openai/qwen2.5-coder-32b-instruct"

Leave OPENAI_API_KEY unset and litellm raises an authentication error before a single packet reaches LM Studio — a “connection” failure with nothing wrong on the wire. Full setup, including the model-metadata warnings, is in our Aider + LM Studio guide.

Fix #6: Cline’s context-length complaint

Cline’s system prompt is large. Load a model with a small context window and Cline refuses up front:

You may need to load the model with a larger context length to work with Cline’s prompts.

This is cline/cline#10351 territory, and it’s a configuration error, not a bug: the context length is fixed at load time in LM Studio, not negotiated per request. Reload with an explicit value — lms load <model> --context-length 32768 or the slider in the model load dialog — and set Cline’s context-window field to match. 32,768 is the practical floor for agentic use; details and the 32.8k Cline cap are in our Cline + LM Studio setup guide.

Fix #7: WSL, Docker, and other machines

Loopback doesn’t cross network namespaces. LM Studio on Windows with Aider in WSL, or Continue.dev inside a devcontainer, will never reach the server at 127.0.0.1 — that address points at the wrong “machine.”

First, flip Serve on Local Network in the server settings. That rebinds the server from loopback-only to all interfaces, and the log will confirm it’s now listening on 0.0.0.0:1234 instead of localhost.

Then point the client at the host’s reachable address:

  • WSL: the Windows host IP from cat /etc/resolv.conf (nameserver line), or 127.0.0.1 works as-is if you’ve enabled WSL mirrored networking — see our WSL 3 GPU guide for that setup
  • Docker: http://host.docker.internal:1234/v1
  • Another machine on your LAN: http://<host-LAN-IP>:1234/v1, firewall permitting

For fully remote access — laptop in a café, GPU desktop at home — LM Studio 0.4.15 (May 29, 2026) added LM Link, end-to-end encrypted tunneling over Tailscale. Substitute the LM Link address for localhost:1234 in any of the three tools and the rest of the config is unchanged.

The Enable CORS setting, one toggle over, matters only for browser-based clients (web UIs, some IDE webviews). Cline, Continue.dev, and Aider all speak to the server from Node or Python processes where CORS never applies — turning it on won’t fix a refused connection, so don’t burn time there.

The checklist, in order

  1. curl http://127.0.0.1:1234/v1/models from the tool’s environment — refused? Start the server (Fix #1).
  2. Empty data: []? Load a model with lms load, check the JIT toggle (Fix #4).
  3. Curl fine but the editor fails? Swap localhost → 127.0.0.1 (Fix #2), then verify the /v1 path per tool (Fix #3).
  4. 500s or wrong-model behavior? Copy the exact ID from /v1/models, confirm with lms ps (Fix #5).
  5. Cline complains about context? Reload the model at 32k+ (Fix #6).
  6. WSL/Docker/remote? Serve on Local Network + the host’s real address (Fix #7).

FAQ

Does the LM Studio server keep running when I close the app? Not by default. Quit the app and port 1234 goes dark. Run lms server start for a headless server that outlives the GUI, and add it to your login items or a systemd user unit if you want it always-on.

Cline worked yesterday and today it’s fetch failed. Nothing changed. Something changed: either LM Studio restarted (server toggle reset — Fix #1) or the JIT auto-unload evicted your model and the reload is timing out (Fix #4). lms ps answers it in two seconds.

Continue.dev is still maintained after the Cursor acquisition? The repo went read-only on July 15, 2026, but the published extension keeps working against LM Studio’s stable OpenAI-compatible API. What still works and where to migrate is covered in our Continue.dev acquisition breakdown.

Can two tools share one LM Studio server? Yes. LM Studio 0.4.x processes requests in parallel, so Cline and Continue.dev can hit the same loaded model concurrently. The bottleneck is VRAM and tokens/second, not connections.

Is this the same problem as Ollama’s connection-refused errors? Same client-side mechanics (IPv6 resolution, network namespaces), different server-side behavior. Ollama’s daemon is always listening but on port 11434 with its own env-var binding rules; LM Studio’s server is opt-in on 1234 with GUI toggles. The Ollama version of this article covers that side.

Sources

Last updated August 1, 2026. Verified against LM Studio 0.4.20, Cline 3.86, Continue.dev 1.3, and Aider 0.86.2. LM Studio’s settings move between versions; check the Developer tab in your build.

Was this article helpful?