sam/paperclip-harness
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Sam
2026-11-11 19:19:43 +11:00
parent 00abedb66b
commit df861563cf
9 changed files with 683 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
docs/PLAN-INTERFACE.md
View File

@@ -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