The driver worked and the models could be downloaded, but the spawn screen
had no idea llama.cpp existed: the model field and every extra setting were
gated behind `isClaude`, so a llama provider offered nothing, `model`
arrived null, and the driver refused with "a llama.cpp session needs a
model". The feature was reachable only by curl, which is not what was asked
for.
A llama provider now gets the models this backend has downloaded, as a
picker rather than free text -- there is nothing sensible to type, and a
name that is not on disk is a session that cannot start. Context size and
temperature are there too, blank meaning llama.cpp's own default rather
than a zero. Spawn stays disabled until a model is chosen, because without
one the button could only fail.
**Two bugs that only appeared by pressing the button**, both mine, both
from changing the server without re-driving the app:
- The app sent the setup's *label* where the server had started resolving
by *id*. The failure was almost self-diagnosing -- `no setup named "this
machine" -- configured: this machine` -- and that message now says "no
setup with id" and lists ids, since listing labels was what made it read
as a contradiction.
- The session header showed `on local`, the id, because the app read
`setup` where the server had begun sending both `setup` (id) and
`setupName` (label). The app now carries only the label: nothing in it
addresses a setup, and holding both is what let it show the wrong one.
Verified by doing it: rediscovered the local machine from the phone so
`local-llama` appeared, spawned a session on Qwen3-0.6B-Q8_0 with a 4096
context, sent "Reply with exactly one word: ready", and it replied "ready"
with 125 tokens counted.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017xn8nHw1tw1R6PtiY1eEtw
irisandClaude Opus 5
6187958de3