From 4d162331e3c70e83bb953802070c3f5d980be72d Mon Sep 17 00:00:00 2001 From: iris <2+iris@noreply.localhost> Date: Fri, 28 Aug 2026 13:38:54 -0400 Subject: [PATCH] Say that llama.cpp reaches the phone now The status section still said "server side" and "no app screen yet", both of which stopped being true today. Also records the discovery trade that would otherwise be rediscovered: command -v follows a non-interactive ssh PATH, so llama.cpp unpacked into ~/.local/opt is invisible until it is symlinked onto PATH. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_017xn8nHw1tw1R6PtiY1eEtw --- AGENTS.md | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 983c67f..8c53483 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -69,7 +69,7 @@ crash recovery, images both ways), and the usage screen. names a host, `session::transport` turns that into an `ssh host …` invocation, and the driver never learns which it got. -**Phase 4 (llama.cpp) works on the server side** (2026-08-28). Models are +**Phase 4 (llama.cpp) works end to end, phone included** (2026-08-28). Models are browsed and downloaded from HuggingFace (`models.rs`, resumable and verified), and `session::llama` runs one through `llama-server`, talking to its OpenAI-compatible streaming endpoint. Two things about it are @@ -77,10 +77,23 @@ deliberate and easy to undo by accident: the conversation is rebuilt from the **transcript** rather than kept in the driver, because driver memory is invisible to a second device; and a llama session is refused on an ssh host, because the model is reached over HTTP and forwarding that port is -not built. No app screen yet — models are driven through the routes. +not built. -What is left is the models UI, and real-phone/WireGuard bring-up, which is -operational rather than code. +Models are browsed, downloaded and deleted from the app, and a llama +session picks one of them plus a context size and temperature. Setups — +machines, each carrying what it can run — are added, renamed, re-probed +and removed from the app too; providers are **discovered by asking the +machine**, never typed, so the enrolled token cannot introduce a command. + +What is left is real-phone/WireGuard bring-up, which is operational rather +than code. + +**`command -v` follows PATH under a non-interactive ssh session**, which is +not the PATH a login shell shows, so a binary somewhere unusual is +invisible to discovery — llama.cpp unpacked into `~/.local/opt` needs a +symlink into `~/.local/bin` before a setup finds it. The escape hatch for +anything odder is editing `config.ron` on the backend, which is +deliberately the one authority the phone does not have. **Testing llama.cpp here:** the prebuilt CPU build lives outside the repo at `~/.local/opt/llama.cpp` (the 15 MB `ubuntu-x64` release asset — no