v0.11.0 — the harness runs your model server, and counts every token exactly

LocalHarness can now manage the model server itself on all four supported runtimes — and its token counting is exact everywhere, verified against each server's own numbers.

Harness-managed server lifecycle (vLLM · llama.cpp · Ollama · LM Studio)

A pluggable lifecycle layer (design spec) lets the harness start, stop, and swap servers instead of asking you to:

• vLLM — docker (stop polls until the container is truly gone and fails loud) or binary
• llama.cpp — the harness spawns llama-server itself
• Ollama — the harness spawns and owns ollama serve; stop kills the whole daemon (SIGTERM→SIGKILL) so no runner child keeps the GPU
• LM Studio — the harness drives headless lms; stop is lms daemon down and is re-verified (a bare server stop leaves the model resident)

Cross-framework heavy swap with a GPU lock: /model can stop the GPU incumbent (say, your vLLM docker) and launch a cold llama.cpp peer from config, then swap back — with restore-on-failure. Live-proven on a DGX Spark in an attended run (35B on vLLM ⇄ llama.cpp).

Exact token counting on every runtime

• Ollama & LM Studio serve no tokenize endpoint, so the harness loads the served model's own GGUF vocab + chat template in-process (optional exact-tokenizer extra) and counts to the token — verified equal to each server's own count.
• vLLM & llama.cpp are now message-level exact: the server renders its own chat template (vLLM /tokenize messages-mode; llama.cpp /apply-template), tools block included, verified equal to the real call's usage.prompt_tokens — with opt-in live certification tests.

Also: an honest per-runtime support matrix in the README, setup pages for llama.cpp, Ollama, and LM Studio, and doctor now reports each runtime's counting capability and why.

Named limitations (so you don't find them the hard way)

• ~ is not expanded in configured binary:/model: paths — use absolute paths.
• Launchable peers must be GPU peers; CPU peers attach to an already-running server.
• The GGUF counting path (Ollama/LM Studio) does not count the rendered tools block; vLLM/llama.cpp do. Its server-parity was verified live once, manually; the automated live parity certification covers vLLM/llama.cpp.
• SIGKILL-based stops (binary vLLM, spawned llama.cpp, Ollama daemon) do not re-poll for death after the kill signal; docker-mode vLLM and LM Studio stops do, and fail loud.

Full details in the CHANGELOG.

🤖 Generated with Claude Code