hi @dakain98
thanks for the extra detail! And this is a really useful detail - you are on Windows.
You already have the server. Let me untagle the three misunderstandings one by one.
Btw, as of today there’s also 0.32.7.
- the zip does include the server part - ollama.exe is the server
you start the server with ollama.exe serve
then in a second terminal use the client ollama.exe run ..., ollama.exe pull ... or just un your python script against http://localhost:11434
So what is "could not locate ollama app"? It’s not about a missing server. When you run a client command and no server is listening on port 11434, the Windows CLI tries to auto-start the desktop tray app - literally a file named ollama app.exe. You can see this in the source, cmd/start_windows.go → startApp(): it looks for ollama app.exe (1) next to ollama.exe, (2) in %LOCALAPPDATA%\Ollama, (3) on PATH - and if it’s nowhere, it returns exactly could not locate ollama app. The standalone zip deliberately ships without the GUI app - the official Windows docs describe it as “containing only the Ollama CLI and GPU library dependencies”, intended for “embedding Ollama in existing applications, or running it as a system service via ollama serve” (e.g. with NSSM). One extra gotcha from the same docs: if you have an AMD GPU, you also need to extract ollama-windows-amd64-rocm.zip into the same directory.
So the 0.32.5 zip you downloaded was already complete- it just wanted ollama serve in a separate window instead of relying on the tray-app auto-start.
- “I completely uninstalled 0.32.6 but the problem persists”
Two different symptoms may be mixed up here:
- If what persists is
could not locate ollama app from the zip → that’s expected and harmless; see point 1, run ollama serve.
- If what persists is the original
--load-mode error → then a 0.32.6 server is still alive or still on disk somewhere, and that leftover is almost certainly also the original cause of your problem. The Windows uninstaller doesn’t necessarily catch a manually extracted zip folder, stale PATH entries, or a still-running process.
Quick audit (each answers one question):
curl.exe http://localhost:11434/api/version # is any server still running, and which version?
where.exe ollama # how many ollama.exe's are on PATH? (should be exactly one)
ollama -v # prints client version AND warns if the server version differs
Also check Task Manager for ollama.exe / ollama app.exe processes, and look in %LOCALAPPDATA%\Ollama\server.log - per the troubleshooting docs that’s where the server logs live, and the log contains the exact command line used to spawn llama-server, including which binary path it picked and the --load-mode flag. That one log line is the definitive proof of the mismatch: a 0.32.6 daemon path spawning a llama-server.exe from an older directory.
This mixed state is also the most plausible story for why the full 0.32.6 package “had not worked” the first time: an installer-based app in %LOCALAPPDATA%\Programs\Ollama plus an extracted zip elsewhere on PATH (or a partially-applied auto-update where a running/locked llama-server.exe didn’t get replaced). The docs even warn for the standalone zip: “If you are upgrading from a prior version, you should remove the old directories first.”
- “Where do I download the complete server for 0.32.5?”
You have three options, best first:
- don’t pin 0.32.5 at all. 0.32.6’s
--load-mode isn’t a bug - it only crashes when the daemon and runner binaries are from different versions. A clean install of the current release (v0.32.7, released today) gives you a matched set and full forward compatibility. Downgrading was only ever a stop-gap.
- If you really want a full 0.32.5 desktop install: every GitHub release page ships the complete installer.
OllamaSetup.exe under the v0.32.5 release assets contains app + server + CLI in one matched bundle. Be aware the installer-based app keeps itself updated (the docs say the installer “will help you keep up to date”), so it may not stay pinned at 0.32.5 for long.
- If you want a pinned, server-only 0.32.5: the zip you already have +
ollama serve (optionally installed as a Windows service with NSSM) is precisely the supported way to do that.
- “If I switch to the latest full package, will client and server be fully compatible?”
Yes - the installer ships client, tray app, daemon and the llama-server runner as one matched bundle; version-mismatch errors like yours only arise when two installations coexist or an upgrade half-applies. Do it as a genuinely clean slate, in this order:
- Stop everything: quit the tray app; in Task Manager kill any remaining
ollama.exe / ollama app.exe.
- Uninstall “Ollama” via Settings → Apps (the registered uninstaller, per the docs).
- Delete leftovers by hand:
%LOCALAPPDATA%\Programs\Ollama (binaries), %LOCALAPPDATA%\Ollama (logs/updates), every folder where you extracted a zip, and any ollama* folders in %TEMP%. You can keep %HOMEPATH%\.ollama - that’s just your downloaded models and config; model blobs are version-independent, so nomic-embed-text won’t need re-downloading.
- Clean PATH: open a new terminal, run
where.exe ollama - it should now find nothing. If it still finds something, remove that entry in Environment Variables.
- Install fresh: download
OllamaSetup.exe from Download Ollama on Linux (currently 0.32.7) and install.
- Verify the pair matches:
ollama -v must show one version with no server-mismatch warning; curl.exe http://localhost:11434/api/version must agree.
- Test the failing path without LangChain first:
curl.exe http://localhost:11434/api/embed -d "{\"model\":\"nomic-embed-text\",\"input\":\"hello\"}"
If that returns embeddings, your original repro is fixed.
- Then run your
OllamaEmbeddings script unchanged - langchain-ollama 1.1.0 stays as-is; nothing on the Python side ever needed to change.
If - and only if - the --load-mode error survives this exact procedure, that would mean a genuinely broken 0.32.7 bundle on your hardware. In that case grab the spawn line from %LOCALAPPDATA%\Ollama\server.log (it shows the full llama-server path + arguments) and open an issue at github.com/ollama/ollama/issues - that log line plus ollama -v output is everything they need. But I’d bet on the cleanup solving it.