Every local model was declared at 32768 (16384 for the OMO local aliases)
regardless of what llama-swap is configured to serve. gpt-oss-20b runs with
`-c 65536`, so opencode was compacting at half the real window -- and
local/librarian and local/explore, which both route to gpt-oss-20b, at a
quarter of it.
Compaction is not free and it is not neutral. Measured on mainframe
2026-09-21, one agent session against a model told it had 32k when it had
131k: four cache-cold prefills, and 780 seconds spent after a working fix
re-reading the same forty lines, because each compaction discarded the memory
of having already verified it. Reasoning spend per step went from 2-5 tokens
to 1739. The model was not confused; it had been made to forget.
Values are llama-swap's own `-c`:
gpt-oss-20b 65536 (was 32768)
local/librarian 65536 (was 16384 / 32768)
local/explore 65536 (was 16384 / 32768)
qwen3-coder-30b 32768 unchanged, already correct
gemma3-12b 32768 unchanged, already correct
The hosted entries were already right and are untouched.
⚠ These are hand-maintained and llama-swap's config is the source of truth.
If a `-c` changes there, change it here. llmbench now derives the same
numbers by parsing that file, and raises rather than guessing when an alias
is unknown -- a wrong context limit produces plausible numbers instead of an
error, which is how this went unnoticed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E9UH1zGZZtA9yhohmQrcT6
connorandClaude Opus 5
f9cfab6221