TL;DR — connection refused against a local model endpoint means nothing is listening where you pointed. In order of likelihood: the server isn't running, you used the wrong base-URL shape (Ollama's OpenAI-compatible path is http://localhost:11434/v1, not the bare host), the port is wrong (Ollama 11434, LM Studio 1234), the server is bound to loopback while the client is in a container or VM, or — the one that no configuration fixes — the request is being made from a cloud service that cannot reach your machine at all.
The error
Depending on the client, the same condition surfaces as:
Error: connect ECONNREFUSED 127.0.0.1:11434
curl: (7) Failed to connect to localhost port 11434: Connection refused
…or, in an IDE, as a request that simply hangs or returns a generic "model unavailable."
Check the server first (10 seconds)
# Is anything listening?
curl -s http://localhost:11434/api/tags # Ollama
curl -s http://localhost:1234/v1/models # LM Studio
Empty output or a refusal means the server is not up — start it before touching any IDE settings. A JSON list means the server is fine and the problem is on the client side.
The five causes
1. The server isn't actually running. Installing Ollama does not mean the daemon is up in this session. Start it (ollama serve, or launch the desktop app) and confirm with the curl above. In LM Studio, the local server is a toggle you have to switch on — a loaded model is not the same as a served model.
2. Wrong base-URL shape. This is the most common configuration mistake. For OpenAI-compatible clients, Ollama serves at http://localhost:11434/v1 — the /v1 suffix is required. Pointing at http://localhost:11434 alone reaches the daemon but not the compatibility API. LM Studio's equivalent is http://localhost:1234/v1. Exactness matters here for the same reason it does with Gemini's /v1beta/openai/ path.
3. Wrong port. Ollama defaults to 11434, LM Studio to 1234, llama.cpp's server to 8080. Copying a config for one tool while running another produces a refusal that looks like a deeper problem.
4. Bound to loopback, called from elsewhere. localhost inside a container, a VM, or WSL is that environment's loopback — not your host. From Docker, use host.docker.internal instead of localhost; to accept connections from another machine, bind the server to 0.0.0.0 (and understand you are exposing it). A model server bound to 127.0.0.1 is invisible to everything but the host itself.
5. The request isn't coming from your machine. The cause no setting fixes: some IDE features run server-side, so the request originates in the vendor's cloud, where localhost is their loopback. Local endpoints work for features that call from the editor process and fail for features that call from the cloud — which is why a local model can work in one part of an IDE and not another. If a tunnel is the only way to expose it, that is the signal you're in this case. Cursor's related model-visibility behavior is covered in overriding the OpenAI base URL in Cursor and keeping Claude available after the override.
Also worth knowing
- The model name must exist locally. Once the connection succeeds, asking for a model you never pulled returns a not-found error rather than a refusal — see model_not_found.
- A dummy API key is usually required. Local servers ignore the value, but OpenAI-compatible clients often refuse to send a request with an empty key field; put any placeholder there.
- First response can be slow, not broken. Loading a large model into memory on the first request can look like a hang. That is a timeout question, not a connection one.
Prevention
- Verify with
curlbefore configuring the IDE — it separates "server down" from "client misconfigured" in one step. - Keep the full base URL (including
/v1) in your notes per tool; the suffix is the single most repeated mistake. - If reliability matters more than running locally, a hosted endpoint removes this whole class of failure — what a router API should handle for you.
Part of the LLM API Error Reference — errors indexed by their exact strings.