#1930 parallel:1 / 0.1.42 -- whole prompt re-read 22x in one session; any total-length change kills the prefix

Description

## Summary

Windows, 2x RTX 3080 20 GB layer split, engine 0.1.42, "parallel": 1 (single-slot path), Qwen3.8-Flash-Next GSQ-RCO IQ3_XXS + MTP, --ple-io ram, STRATA_ROUTE_TAIL_SKIP=0. One real agent conversation grew from ~122K to ~192K tokens over one session.

The whole prompt is re-read from token 0 on almost every turn. In one session the engine logged 22 full re-reads (each "reading the prompt" sequence starting at 8,192 and climbing to the full length), i.e. a ~190K-token context re-computed 22 times. At ~195 s per full read that is ~71 minutes of pure reading in one session.

Two things make this worth a look:

1. "expert cache hit" does not describe the KV prefix. Every turn -- full re-read or not -- reports "expert cache 92-96% hit", i.e. the same number. A turn that re-read 190K tokens took 216 s; a turn that read 5 tokens took 20 s; both say ~93% hit. So the one "cache" number the log shows is the MoE expert-weight hit rate, not the prompt prefix. It cannot be used to tell whether a re-read happened.

2. The 0.1.42 single-slot log line dropped the "reused N" field. In the parallel:2 reports (#1906) the line read "prompt 54301 tokens = 0 reused + 54301 read in 38786 ms" -- you could see a full re-read at a glance. In 0.1.42 / parallel:1 it is only "reading the prompt: 8,192 of 190,854 tokens, 5 s so far", with no reuse count. Whether the prefix matched is not observable from the log.

## Rig, config

- Windows 11 / WDDM, 2x RTX 3080 20 GB, layer split auto
- Xeon E5-2696 v3 (18C/36T), no AVX-512, 128 GB RAM
- engine 0.1.42 (strata.exe 165,004,288 B)
- "parallel": 1, --ple-io ram, STRATA_ROUTE_TAIL_SKIP=0, --kv int8
- client: agent conversation on a LAN machine, one conversation, one turn at a time

## Evidence 1 -- full re-reads vs incremental turns, same session, same config

Both kinds of turn are in the same log. The only visible difference is the read duration:

| line | generated | duration | result line |
| --- | --- | --- | --- |
| 2512 | 889 tok | 20 s | done, expert cache 92.9% hit |
| 2490 | 860 tok | 216 s | done, expert cache 92.7% hit |
| 2446 | 471 tok | 207 s | done, expert cache 96.5% hit |
| 2407 | 840 tok | 216 s | done, expert cache 95.3% hit |
| 2689 | 841 tok | 19 s | done, expert cache 95.9% hit |
| 2612 | 821 tok | 27 s | done, expert cache 93.0% hit |

The 20 s turns read only a handful of new tokens (their "reading the prompt" line is "194,856 of 194,861", i.e. +5 tokens). The 216 s turns re-read the whole ~190K. Same expert cache hit rate, 10x duration difference.

## Evidence 2 -- every re-read is preceded by a change in prompt total length

In time order, the prompt total at each of the 22 re-reads:

```
122,816
130,768   +7,952
128,402   -2,366
136,553   +8,151
135,085   -1,468
139,867   +4,782
136,923   -2,944
139,947   +3,024
160,756  +20,809
154,359   -6,397
155,831   +1,472
161,849   +6,018
175,449  +13,600
172,197   -3,252
176,032   +3,835
189,935  +13,903
188,227   -1,708
193,093   +4,866
189,470   -3,623
193,967   +4,497
190,854   -3,113
192,401   +1,547
```

Every total differs from the previous one (up or down), and every one triggers a full read. There is no case of "same length, still re-read" nor "length changed, still reused". The prefix cache is only kept alive when the length happens to be identical and the prefix tokens are unchanged -- which for this agent is almost never.

The agent appends tool results (up) and trims/compacts old context (down) every turn, and on hand-off re-concatenates the message list, so the prompt head is not stable turn to turn.

## Evidence 3 -- 22 re-read start lines (all at 8,192)

Log line numbers of every "reading the prompt: 8,192 of ...":

```
28, 113, 268, 413, 460, 486, 532, 855, 1044, 1212, 1322,
1428, 1592, 1959, 2054, 2255, 2324, 2366, 2413, 2448, 2693, 2736
```

Each is followed by a contiguous rising sequence (8,192 -> 16,384 -> 24,576 -> ...) with no return to 0, i.e. a single read of the entire prompt, not a loop. 22 such sequences = 22 whole-prompt recomputes.

## Suggestion

1. Log: print the KV-prefix reuse count ("N reused + M read") on the single-slot path as well, and rename the expert number so it is not confused with the prompt cache. Right now "expert cache 93% hit" next to a 216 s turn reads like "the cache worked" -- it did not.

2. Engine: when the new prompt differs from the previous only near the tail, try to reuse the longest common token prefix instead of discarding the whole context on any length change. If the client's prompt is only appended to, this alone would cut the ~195 s reads to near zero.

3. This is distinct from the #1906 report (parallel:2, "reused 0" on hand-off). Here it is parallel:1 and the trigger is any total-length change, not concurrency.

## Raw evidence

- Log: E:\Strata\server-console.log, lines 28-2737
- Engine: Strata v0.1.42