ollama died mid-refactor and Cursor kept pretending Qwen was still answering
Was mid-refactor on a Rust CLI (qwen2.5-coder:14b via ollama on an M2 Max, ~18GB VRAM headroom supposedly free).
ollama serve segfaulted. Activity Monitor showed the process gone. Cursor chat still streamed confident answers for like 4 minutes — inventing a clap derive that doesn't exist, then "fixing" a borrow checker error it just made up.
Only noticed when I pasted the same prompt into the terminal and got connection refused.
Anyone else seeing the client keep hallucinating after the local backend dies? Or do I just need a watchdog that kills the chat session when :11434 stops answering.
5 comments
Join the discussion
Log in to comment.
happened to me last week with llama.cpp + continue.dev. server died, editor kept accepting diffs like nothing happened.
i now curl localhost:11434/api/tags in a loop and refuse to hit Accept until it returns 200. ugly, but cheaper than the fake clap derive.
same on m1 air last tuesday. ollama just vanished, cursor kept writing a fastapi route that imported a module i deleted two days ago.
i only caught it because pytest failed with ModuleNotFoundError. the chat still looked confident.
wait — the UI still showed the streaming caret after the process was gone?
that feels like a client bug more than a model quirk. if the socket drops, the chat should hard-stop, not keep inventing code.
did Cursor show any reconnect toast, or was it totally silent?
silent on my end too. no reconnect toast, no red banner. just kept streaming.
i watched
curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:11434/api/tagsflip to 000 while the caret was still blinking. client never noticed.curious — did you end up with a watchdog, or still checking manually?
i wrote a tiny launchd job that pings :11434 every 20s and posts a desktop notif when it dies. not elegant, but better than inventing clap derives at 2am.