Correct the Headroom finding: LiteLLM does not know the router's models; install headroom-ai on all three machines

docs/NEXT.md

@@ -113,6 +113,15 @@ The one place it would earn its keep here: a failed run in `Agents>agents` offer
 asks "what does this failure need" with four options and records the answer, the confidence and
 the options on the task. A person still decides, and it never decides a merge.
 
+## Headroom: measured facts
+
+- The **tool** path works: `headroom-ai` is now installed for Pi on `.13`, `.27` and `.51`, and
+  `compress()` answers from `http://192.168.20.13:8787` (measured: 2809 tokens before and after
+  for a single long user message, which headroom protects from compression).
+- The **provider** path fails, and not for the reason first given: `docker logs headroom` shows
+  LiteLLM rejecting the router's model ids, so a completion returns 502. The router answers the
+  same request in 1.1 s. Fixing it means teaching headroom's LiteLLM the router's models.
+
 ## Headroom: a tool, not a provider
 
 The `headroom-bridge` extension gives an agent two tools (`compress_for_agent`,

docs/PLAN-INTERFACE.md

@@ -640,29 +640,28 @@ without the provider.
 to the company, not to a project. The finest granularity is one agent, which is what the
 `Agents>settings` model field already gives.
 
-### Measured afterwards: it does not work yet, and why
+### Measured: what actually fails, and why
 
-A provider entry was added and removed again after testing, because requests fail:
+The earlier claim that "headroom needs an Anthropic key" was wrong. Here is what the tests show.
+
+Headroom runs as a container from `ghcr.io/chopratejas/headroom:latest` with
+`--port 8787 --no-telemetry`, and it is built on **LiteLLM**. Its `/v1/models` lists the same 486
+models as the router, and `/v1/compress` works. What fails is a completion through it:
 
 ```
-POST http://192.168.20.13:8787/v1/chat/completions   → 502 {"code":"proxy_error"}
-POST http://192.168.20.13:8787/v1/messages           → 401 "invalid x-api-key" (Anthropic shape)
-POST http://192.168.20.13:20129/v1/chat/completions  → 400 (the router's own model naming)
+router  POST /v1/chat/completions  deepseek/deepseek-v4-flash  → 200, SSE stream, "ok" in 1.1 s
+headroom POST /v1/chat/completions  deepseek/deepseek-v4-flash  → 502 {"code":"proxy_error"}
 ```
 
-Headroom's backend is `anthropic`: it speaks the Anthropic Messages API and authenticates with
-an Anthropic key, which this machine does not have. The omni router uses an OpenAI-shaped API
-with its own key. So headroom cannot be put in front of the agents as things stand.
+`docker logs headroom` shows LiteLLM repeating *"Provider List: https://docs.litellm.ai/docs/providers"*
+— LiteLLM does not recognise our router's model ids (`deepseek/deepseek-v4-flash`,
+`auto/best-fast`), so it never makes the call. The same body sent to the router directly succeeds,
+so the key, the model and the request shape are all fine.
 
-To use it, one of these is needed:
-
-1. an Anthropic-compatible credential in headroom, and agents moved to an Anthropic-shaped
-   provider;
-2. or headroom configured to accept the omni router's OpenAI API and key;
-3. or nothing — the omni router already does model routing, and headroom's only addition would be
-   prompt compression.
-
-The provider entry was removed so no agent can be pointed at a failing endpoint by accident.
+**So headroom is not blocked by Anthropic, and not by a key.** It is blocked by LiteLLM not
+knowing the router's models. To use it as a provider, headroom's own model list has to define
+them, for example `openai/deepseek-v4-flash` with `api_base: http://192.168.20.13:20129/v1` and
+our key — a change to headroom's configuration inside that container, not to our software.
 
 ### The path that does work: headroom as a tool