[rwkeyes]

Problem and result

Section 6 left one lead: a start-up --prompt-cache 0 measured 58 ms cheaper per request than the router's
cache-off path at 75 tokens, suggesting a one-shot deployment profile. The rerun does not support it, and the profile is
not offerable anyway.

real tokens	deployed	0 slots	difference
126	546.1 ms (cache on, 102 ms park)	350.0 ms	−196.1 ms
456	537.3 ms (cache off)	539.7 ms	+2.4 ms
1,608	1,463.3 ms (cache off)	1,471.3 ms	+8.0 ms

Retraction: the 58 ms was an artefact. The 382 ms figure it was compared against was a median that included the
reference arm's first samples while the cache was still on (the batch_after hysteresis), so it measured the cache-on
state. At sizes where both arms serve cache-off they are equal within noise.

And 0 slots cannot serve chat. The router's cache_on comes from the start-up arguments, so a server started at 0
has no value to switch back to: C2 2.482 s, C3 2.390 s, R2 2.111 s — every turn and repeat re-reads its context,
against 0.587 / 0.549 / 2.330 deployed.

That closes the last non-engine lead. The remaining ~165 ms inside prefill needs a phase timer in the request path,
which means a build.

Related discussion

• [Docs] File the performance inventory and close the PLE read-path knobs #14 — the fixed-cost split, whose fourth finding this corrects
• [Docs] Mixed traffic: keep batch_after at 4 (1 costs 1.9 s per conversation) #17 — mixed traffic, which fixed the reference frame for a profile question

Approach

1. Two windows, one variable: the deployed config and the same config with --prompt-cache 0 in the engine's
   argument list, three samples at 126 / 456 / 1,608 real tokens plus the mixed traffic shape.
2. The three sizes are the point: three samples per size means the first size lands inside the router's cache-on
   hysteresis, which is exactly how the earlier artefact was produced — here that is visible and labelled instead of
   being averaged away.
3. The page gains section 8 (table, three findings, and the statement that nothing non-engine is left), section 6's
   fourth finding is retracted in place with a pointer to the rerun, and the ranked item closes.

Validation

Passed:

• The matched-size rows are the test: 456 and 1,608 tokens differ by 2.4 ms and 8.0 ms — no slot cost — while the
  126-token row differs by 196 ms with a 102 ms park recorded in the same request, which accounts for half of it and is
  the cache-on state, not the slots.
• The chat result is unambiguous: three steps that reuse on the deployed config (0.587, 0.549, 2.330) all re-prefill
  at 2.4 / 2.4 / 2.1 s with 0 slots — a mechanism (cache_on read from start-up args), not a timing wobble.
• Every window restored production: :8095 http=200, engine 0.1.58, after both.
• Rendering: seven tables, no broken relative link.

Failed:

• The first attempt at the 0-slot window never started: I passed --prompt-cache 0 through SRV_ARGS, which
  reaches serve/server.py, and the server rejected an engine argument (argparse error, no engine line in the log). The
  retry rewrote the config's args list instead; the failed log is shipped beside the good one.

Limits

• Three samples per size and one mixed run per arm; the equal-at-matched-size result rests on two sizes, which is enough
  to kill a 58 ms claim but not to measure a 5 ms one.
• The 126-token row inherits the hysteresis by construction — it is evidence about the cache-on state, not about slots.