Serve a machine's models from one shared llama-server

A llama.cpp session had its own `llama-server`: two sessions on one model
held two copies of it in memory, a model change bought a load only that
session benefited from, and the process was a session's to end. A machine's
models are now served by one `llama-server` in **router mode** -- no `-m`,
a preset file naming models and their flags, a child server per model asked
for, and each request routed by its `model` field. So one server per model
with that model's own settings is what a machine runs, while this backend
has one process, one port and one record per machine to keep track of.

The record is the mechanism every other driver already uses, so a restart
adopts it; a session records the same pid in its own directory as
`Detail::Shared`, and `process::signal` refuses to signal one of those --
which is what keeps stopping, deleting or cleaning up after one session
from unloading a model every other session is using. Nothing stops a router
on its own. That is deliberate (a loaded model is minutes of disk) and it is
why the machines tab now has a card per provider that opens its own screen:
how each model is loaded, how many stay in memory, Unload, and Stop.

How a model is *loaded* therefore belongs to the model on its machine rather
than to a session -- context size, GPU layers, threads, slots, speculative
decoding -- written into the preset as llama-server's own argument names.
Saving them re-reads that file, which unloads the model; that is the change
taking effect, and the dialog says so before you save. What stays a
session's is everything that rides on a request, including which tools it
offers: the router hosts one set for the machine and the choice is a filter
applied here, so it costs no reload (2,181 tokens of prompt with all seven,
698 with none).

Verified end to end against the scratch backend and the emulator: two
sessions sharing one loaded model with one child process, a second session
joining it with a 26ms prefill, a backend restart adopting the router and
answering with the prompt cache intact, the same over ssh to this VM, a
model's settings reaching the running server, Unload, and Stop leaving every
session `exited` with no error line.

AGENTS.md

@@ -34,6 +34,24 @@ Module-by-module intent is in PLAN.md's "Backend layout".
 
 - `server/` — the Rust backend (`ai-server`). `routes.rs`'s module doc
   comment is the HTTP table and the surface's source of truth.
+  **A machine's models are served by one shared `llama-server`** (2026-09-19,
+  `session/llama/router.rs`): started with no `-m`, which makes it a
+  **router** — it reads a preset file naming models and their flags, starts a
+  child server per model asked for, and routes by the `model` field in each
+  request. So a session has no process of its own, two sessions on one model
+  share one copy of it in memory, and a backend restart adopts one process
+  rather than one per session. Four things fall out of it and are easy to get
+  wrong again — a session records the router's pid in its own directory as
+  `process::Detail::Shared`, and `process::stop` refuses to signal a `Shared`
+  record, which is what keeps one session ending from unloading everybody's
+  model; **nothing stops a router on its own**, and the only thing that does
+  is the machine's provider view (`POST /machines/{id}/providers/{p}/stop`);
+  how a model is *loaded* is per model on its machine
+  (`ProviderConfig::model_settings`, `LLAMA_MODEL_PARAMS`) rather than per
+  session, and saving those settings rewrites the preset, which **unloads**
+  that model; and the preset is read back before every edit, because a router
+  adopted from an earlier run is serving sections this process has never seen
+  and rewriting without them unloads those.
   **A llama.cpp session runs on its configured machine** (built
   2026-09-04, the last of phase 5): `Transport::reserve_port` returns the
   port the server binds *there* and the port that reaches it *here*, and
@@ -48,20 +66,23 @@ Module-by-module intent is in PLAN.md's "Backend layout".
   will not load exits in a second and was being reported as "gave up after
   300s". See PLAN.md's "Transport" and "llama-server management".
   **A llama session has tools and runs the loop itself** (2026-09-19):
-  `--tools all` gives it `llama-server`'s built-in set, which that server also
+  `--tools all` gives the router `llama-server`'s built-in set, which it also
   *runs* (`GET /tools` for the definitions, `POST /tools` to call one), while
   web search comes from an MCP server this backend connects to directly
   (`session/llama/mcp.rs`, Exa preset in a discovered provider's
   `mcpServers`). Driving the loop is what makes the permission gate ours:
   `manual` asks before every call and remembers a tool you answer
   "Always allow …" to, `bypassPermissions` never asks, and the allowances are
-  folded back out of the transcript. Three more things fall out of it and are
-  easy to get wrong again — a model change **reloads the server** rather than
-  being refused, since the conversation lives in the transcript rather than in
-  `llama-server`; `-np 1` is always passed, and it is what decides whether the
-  MTP draft head is a 50% speed-up or a 33% loss; and `--spec-type draft-mtp`
-  is conditional on the file actually having a head, because asking for one
-  that is not there makes `llama-server` **exit**.
+  folded back out of the transcript. Which tools a *session* offers is a
+  filter applied to those definitions here, not a flag over there: one shared
+  server has one set, and the filter costs no reload (2,181 tokens of prompt
+  with all seven, 698 with none). Three more things fall out of it and are
+  easy to get wrong again — a model change **asks for another model** and
+  stops nothing, since the one being left may be another session's;
+  `parallel = 1` unless that model's settings say otherwise, and it is what
+  decides whether the MTP draft head is a 50% speed-up or a 33% loss; and
+  `spec-type = draft-mtp` is conditional on the file actually having a head,
+  because asking for one that is not there makes `llama-server` **exit**.
   **A llama session's thinking is drawn** (2026-09-19): `reasoning_content`
   becomes `Event::Thinking` deltas closed by an `Event::ThinkingDone` carrying
   the span the *driver* measured, and the phone draws a card that spins while
@@ -92,10 +113,12 @@ Module-by-module intent is in PLAN.md's "Backend layout".
   and whether a change waits for a restart — and the phone renders whatever
   arrives, on the spawn form and in the session settings dialog. Adding a
   setting to a driver is one entry in that table and no app change. `tools`
-  is in there too, because the seven built-in definitions are ~1,300 tokens
-  of every prompt (2,191 against 887 with none), which on a small window is
-  the difference between a usable session and one that overruns; `"none"`
-  omits the flag, since `--tools none` is a server that exits.
+  is in there too, because the seven built-in definitions are ~1,500 tokens
+  of every prompt, which on a small window is the difference between a usable
+  session and one that overruns. `DriverKind::model_params` is the same table
+  for a provider's **models**, drawn in the machines tab's provider view —
+  the settings that decide how a model is loaded, which belong to the machine
+  because one loaded copy answers every session using it.
   Codex is one persistent `codex app-server --stdio` process per session; its
   driver uses native turn steering and interruption, persists the protocol
   state and thread id, and reads subscription limits through the same CLI
@@ -257,6 +280,11 @@ day to day:
   keep what a development server spawns. The flag decides only what **new**
   sessions are marked as; what happens on the way out is decided by the
   **mark**.
+- **A llama.cpp router is not cleaned up by any of that**, throwaway sessions
+  included: it belongs to the machine rather than to a session, and a
+  development server that has loaded a model leaves it loaded — gigabytes of
+  VRAM — after `pkill ai-server`. Stop it from the machines tab's provider
+  view, or `pkill -f "[l]lama-server"` when testing.
 - Each session directory holds `process.json`, `stdin.fifo`, `stdout.log` and
   `stderr.log`. `stdout.log` is the driver's input, read from the byte offset
   in `process.json`; removing either by hand while the session is live loses
@@ -362,7 +390,21 @@ written, and the fold uses that same predicate to decide a reply is settled.
 - **A server started with no `--tools` answers 403 at `GET /tools`, not an
   empty list.** The route is off rather than empty, so reading that as a
   failure made "no tools" — the one setting whose entire purpose is to have
-  none — a session that never started.
+  none — a session that never started. The router is always given
+  `--tools all` now and the choice is a filter here, so this is a trap for
+  whoever next changes how the server is started.
+
+- **`POST /models/load` answers 400 for a model that is already loaded**, and
+  that is the *ordinary* case once one server is shared: a second session
+  naming a model somebody else loaded. The router driver asks what is loaded
+  first and treats "it is there" as the answer whatever the request said.
+
+- **Starting a process from a blocking thread needs the runtime.** Loading a
+  model is minutes of disk, so it runs on a `std::thread` — and tokio's
+  `Command::spawn` registers the child with the reactor, so calling it with no
+  runtime context panics. The panic kills only that thread: the session said
+  `loading` for ever and nothing appeared in the log. `Routers` holds a
+  `tokio::runtime::Handle` and enters it around the spawn.
 
 - **A llama session reports `loading`, and a message sent into it waits.**
   Before 2026-09-19 the session showed `running` from the moment the process