adrianbonpin/lam-agent-vicinae
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: unload a loaded model from the models list

Browse Source
This commit is contained in:
adrianbonpin
2026-10-05 17:41:33 +08:00
parent 41d9ec5068
commit e9386b3d46
5 changed files with 291 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+9
View File
@@ -144,10 +144,19 @@ vicinae 'vicinae://launch/lam-agent/chat?fallbackText=summarise%20this'
| Action | Notes |
| --- | --- |
| **Use This Model** | The primary action. Immediate, and survives restarts. |
| **Unload Model** | Only on a row that is loaded. No confirmation, because nothing is deleted. |
| **Copy Model Name** | For pasting into the `Model` preference. |
| **Delete Model** | Confirmed first. A server you run only. |
| **Pull a Model…** | Confirmed by the download itself. A server you run only. |
### Loaded models
Installed and loaded are different states, and the list shows both. `GET /api/ps` reports what is holding memory right now, and those rows get a green `loaded` tag, so "why is my GPU busy" has an answer in the same place as "what do I have".
**Unload** frees the memory without deleting anything, which is why it needs no confirmation: the worst case is that the next question pays to load the model again. It is `POST /api/generate` with `keep_alive: 0` and no prompt, which is how Ollama expresses "release this now", and what its own `ollama stop` does. The reply reports `done_reason: "unload"`, and the toast says how much was freed.
A host that does not serve `/api/ps` (older builds answer 404) simply shows no loaded tags. That check resolving to nothing is not an error, and it must not take the model list down with it.
### Why a pick is not written to the preference
It cannot be. `@vicinae/api` exposes `getPreferenceValues` and nothing that sets one, so the only way to change the preference would be to write Vicinae's own config file. That does not work: preferences are read once at startup and held in memory, so an edit to `~/.config/vicinae/settings.json` is invisible until Vicinae restarts. This was measured rather than assumed. Pointing `ollamaHost` at a local listener that logged every request, then launching a command, showed the requests still going to the old host.