clm-0019

MEASURED HERE, controlled, same session, same model file, same server binary, only the slot count varying: | server flags | needle before concurrency | after | |---|---|---| | `-c 65536 --parallel 4` (cache-idle-slots default) | 0/3 | 0/5 | | `-c 65536 --parallel 4 --no-cache-idle-slots` | 0/3 | 0/5 | | `-c 16384 --parallel 1` | **3/3** | **5/5** | Probe: a needle at position 0 ("The maintenance codeword is chartreuse-viper-88."), ~5,368 prompt tokens of whole-sentence filler, question at the end, `temperature 0`, thinking disabled. Failure mode is not garbage — the model answers coherently *from the filler* ("The maintenance codeword is: **routine**") or echoes the instruction ("codeword"). It behaves exactly as if the first part of its context is absent. WHY IT MATTERS MORE THAN IT LOOKS: · **Throughput is unaffected and silent.** decode/prefill numbers at `--parallel 4` look entirely normal. A sweep-only benchmark would have published them. · **It is a `hazard`-class lever behaving exactly as protocol §1a predicts** — a performance setting silently corrupting correctness. This is the first time our own guard framework has caught a real one, and it is the whole argument for the guard tier existing. · **It threatens the multi-slot plans directly** — the second-lane idea, the council architecture, and any use of parallel slots for concurrent agents. ⚠ DISTINCT FROM llama.cpp #25992. That issue is cross-request *leakage* between concurrent requests. We tested for it explicitly — four concurrent requests with disjoint markers — and found **no contamination**, repeatedly. This is a different failure: single sequential requests on a multi-slot server lose their own early context. HONEST ABOUT THE MESSY PATH: earlier ad-hoc observations in the same session were inconsistent (the same prompt passed 10/10 on one server instance and failed 6/6 on another with the same flags), and I twice attributed failures to my own harness before running a controlled comparison. The three-way matrix above is the only evidence that should be relied on; the earlier anecdotes are recorded here only so nobody re-derives them and thinks they contradict this. NOT YET ESTABLISHED — the open questions that would make this reportable upstream: · Does it depend on slot COUNT (2? 8?) or merely on >1? · Does it depend on `n_ctx_slot`, or on depth relative to it? Our failures were at ~5.4k tokens against a 16,384-token slot, so it is not a simple overflow. · Does it reproduce on CPU or Vulkan, or is it HIP/gfx1151-specific? · Does it reproduce on a stock upstream build on other hardware? If yes, this is an upstream bug worth filing; if no, it is a gfx1151 backend issue. IMMEDIATE OPERATIONAL CONSEQUENCE: **run `--parallel 1` for anything that depends on long-context recall** until the above is answered. That is what production already did (`cfg-0002` used `--parallel 1`), so nothing shipped is affected — but the plan to use multiple slots for a second lane is on hold pending this.