Local model in Continue refusing connections or crawling? A focused fix guide for connection-refused errors and slow performance when running Continue with Ollama.
You configured Continue to use a local model through Ollama, and it either refuses to connect or responds painfully slowly. Chat may hang, or autocomplete may never appear.
These are two distinct problems with different fixes. Connection refused is a wiring issue, while slowness is usually a hardware or model-size issue.
This guide separates the two. Diagnose which one you have first, then jump to the matching checks.
As always with Continue, none of this affects how you ship. Xcode and the Apple Developer Program still build and submit your app regardless of your local model setup.
A connection-refused error almost always means nothing is listening at the address Continue is calling. The first thing to verify is that Ollama is actually running.
Start the Ollama service and confirm it is up. On many systems it runs as a background service, but it can be stopped or fail to start after a reboot.
Confirm you have pulled the model you referenced in Continue. Pointing at a model that was never downloaded will fail even if the service is up.
Restart the runner if in doubt, then retry in Continue. A fresh start clears a surprising number of local connection problems.
Continue reaches your local model at a specific address and port. If that does not match where Ollama actually listens, you get connection refused.
Check the endpoint in your Continue configuration against Ollama's default local address. A mismatched host or port is the single most common cause of this error.
Make sure you used the local loopback address that the runner serves on, not a remote or mistyped host. Small typos here fail silently as refused connections.
Align the two, save, and reload Continue. Consult Continue's docs for the exact local-provider configuration fields if you are unsure.
Even with the service up and the endpoint correct, a wrong model name will fail. Continue must reference a model that Ollama has installed.
List your installed models and copy the exact name into Continue's configuration. Names are precise, and a near-miss will not resolve.
If you recently changed models, update every place Continue references the old name, including separate autocomplete and chat assignments.
After correcting the name, reload and test with a short chat prompt. A simple request is the fastest way to confirm the wiring end to end.
If the model connects but crawls, the usual cause is that the model is too large for your hardware. Local inference is bound by memory and compute.
Switch to a smaller model and compare. Smaller models respond much faster and are often good enough for autocomplete and routine questions.
Close memory-hungry applications while running local models. Freeing RAM can meaningfully improve responsiveness, especially on laptops.
Assign your smallest capable model to autocomplete, where speed matters most, and reserve a larger model for occasional deep chat. Matching model size to the task is the core tuning move.
Local models load into memory, and an undersized machine will swap, stall, or fail. Watch your system's memory pressure while a model runs.
If you see heavy swapping, the model is too big for your available RAM. Drop to a smaller model rather than fighting the constraint.
Avoid running multiple large models at once. Keeping one model loaded at a time keeps performance predictable.
Remember that building in Xcode and running simulators also consume significant resources. On a single Mac, budget headroom for both your local model and your Apple toolchain.
If local performance never reaches a comfortable level, a hybrid approach is a pragmatic answer. You do not have to choose all-local or all-cloud.
Keep a fast local model for autocomplete to preserve privacy and speed on routine typing. Route heavier chat and reasoning to a hosted model when the code is not sensitive.
Continue supports assigning different models to different roles, which makes this split straightforward. Configure each role to the backend that serves it best.
This balances confidentiality, cost, and responsiveness. You keep the local benefits where they matter and lean on the cloud only when you need more power.
A specific slow-response case deserves its own note, because it is easy to misdiagnose. The very first request to a freshly started local model is often much slower than later ones, since the model has to load into memory before it can respond.
Do not judge performance by that first cold request. Send a couple of warm-up prompts and measure the steady-state speed, which is what your day-to-day experience will actually feel like.
If even warm requests stay slow, the model is genuinely too large for your hardware and you should drop to a smaller one. If only the first request lags, the model is simply loading, and that is expected behavior.
Keeping a small model resident for autocomplete sidesteps most of this. A lighter model loads quickly and stays responsive, which is exactly what inline completion needs.
The most useful first move with a local model is deciding which of two very different problems you have. A connection-refused error is binary: the request either reaches the runner or it does not.
Slowness is a different animal entirely. Here the connection succeeds, so the wiring is fine, and the bottleneck is your hardware relative to the model's size.
Confusing the two wastes time. Tuning model size will never fix a wrong endpoint, and re-checking the port will never speed up a model that is simply too big for your RAM.
So triage first. If you see connection refused, work the wiring checks; if responses arrive but crawl, work the performance checks, and you will reach the fix far faster than treating every symptom the same way.
If problems persist, isolate whether the fault is Ollama or Continue. Test the local model outside Continue first, directly through the runner.
If the model responds fine on its own but not through Continue, the issue is the Continue configuration — endpoint, port, or model name. If it fails standalone too, the issue is the runner or the model.
Read Continue's output logs for the precise error, and check Ollama's own logs in parallel. Two logs usually pinpoint the failing layer quickly.
For stubborn cases, search Continue's and Ollama's GitHub issues, or open a report with your config and logs. Both projects are open source, and that is where real fixes surface.
Connection refused means nothing is listening where Continue is calling. Confirm the Ollama service is running and that the endpoint and port in Continue's config match where Ollama actually listens.
Local inference is limited by your hardware. A model too large for your RAM and compute will crawl. Switch to a smaller model, free up memory, and use the smallest capable model for autocomplete.
Test the model directly through Ollama outside Continue. If it works standalone but not in Continue, the issue is the Continue config. If it fails standalone too, the runner or model is the problem.
Yes. Continue lets you assign models per role, so you can keep fast local autocomplete and route heavier chat to a hosted model when the code is not sensitive.
Only in that both consume system resources on the same Mac. The local model does not change how Xcode builds, signs, or ships — that path is unchanged and still required.