Issue draft — paste into https://github.com/Niko1221/Strata/issues/new

Title: --spec 5 measured +6.1% decode on RTX 5060 Ti / 128 GB, but it cannot be persisted: tune_knobs safe range is [3, 4]

What I am asking for

Allow --spec 5 for the flash-next family, or at least let a power user pin it durably.
I am not asking to change the default — my machine's own autotune correctly picked 4 and I
respect that. I am asking that 5 be a value a user is allowed to keep.

Environment

Measurement

Same engine build, same model, same machine, same prompts, greedy decoding, batch 1, one run per
prompt. --spec 5 was measured with a second, independent engine instance on a separate port
(18501) while the main instance ran --spec 4, then the numbers were compared. Metric is the
engine's own decode figure (generated tokens ÷ generation time, from the GEN lines), plus the
engine's own draft-acceptance counters. Client-side medians are reported too.

Per prompt (engine decode tok/s):

What the guard's rationale predicts is that a wider window costs more than it pays. On this box it
did not: acceptance falls exactly as expected (70.9% → 67.2%) and the window is still net positive,
concentrated in code generation. RAM footprint is identical (the 63.28 GiB expert arena does not
depend on the window) and the VRAM cost is one small buffer:

strata verify: window up to 7 tokens, ~90 MiB of device buffers      # --spec 5
strata verify: window up to 6 tokens, 77.1 MiB of device buffers      # --spec 4

The engine starts and serves --spec 5 with no problem at all — I ran it for hours, including as
the assistant serving this very session. This is purely a policy question, not a capability one.

Why I cannot keep it (three separate walls)

1. strata_control/tune_knobs.py — the tuner exposes "--spec": {"choices": (3, 4)}, and the
   safety text says wider windows (>= 6) were "4% to 16% slower". 5 is not rejected by that rule;
   it is rejected by the range. In-process check:

   --spec = 4   -> []                                          (passes)
   --spec = 5   -> ['--spec 5: outside the safe values [3, 4]']
   --spec = 6   -> ['--spec 6: wider speculative windows were 4% to 16% slower',
                    '--spec 6: outside the safe values [3, 4]']
   

2. presets.overlay() — the layer documented as "applying the active preset at every start"
   deliberately drops out-of-range settings ("A setting that is outside the safe rules is left out,
   never applied"), so a preset carrying --spec 5 is skipped entirely:

   applied=False  why_not='not applied: --spec 5: outside the safe values [3, 4]'  state='fresh'
   

   With only that one range relaxed in memory (no file touched), the very same preset applies
   cleanly through the official mechanism:

   applied=True  state='fresh'  resulting argv: --spec 5
   

   So the persistence machinery already works; the range is the only thing in the way.
3. Hand-editing the model settings file does not survive a load. strata-nvfp4-nvfp4.json
   holds "--spec", "5" → the UI's native-settings JSON shows 5 → the user presses unload/load →
   the freshly derived native-instances\<uuid>.json comes out with --spec 4 and the settings
   file is rewritten back to 4 (mtime moves to the load timestamp). This is the part I found
   surprising: the UI displays an args array that a user may edit and that validateNativeSettings()
   explicitly accepts, but the value it shows is regenerated over at load, so editing it silently
   does nothing. If that is intentional, the UI should say so; if not, it is a small bug.

Suggested fixes, in order of preference

1. Widen the safe range for flash-next to [3, 5] (or gate it: allow 5 when vram >= 16 GB and
   ram >= 64 GB, where the window buffer is free and acceptance stays high).
2. Add a draft-depth field to NATIVE_FIELDS (native settings → "GPU & memory" or a new
   "Speculation" group) so the value is a first-class, user-owned setting that goes through
   save() and is not regenerated at load.
3. Independent of the above: if args edits in the model settings file are going to be regenerated
   at load, surface that in the native-settings JSON tab instead of accepting them.

Caveats I want to be upfront about

• One run per prompt, three prompts. The aggregate +6.1% comes mostly from the code prompt; the
  other two are flat. I have not run a repeated-measures median. I would not call this a settled
  benchmark — I am reporting a directional result on one specific GPU/RAM/model/quant combination.
• Client-side medians were flat (45.1 → 44.8), so the engine-side gain did not reach wall-clock for
  single short requests. For long generations it should.
• Measured on 0.1.47; the engine has since auto-updated to 0.1.48. I will re-run on 0.1.48 and
  post the numbers here before this is acted on. If it does not reproduce, I will say so.
• Autotune on this machine picked the default and reported default_confirmed with settings.args = {},
  so 5 was never a candidate it could have found. The candidate set is the reason this is invisible
  to the tuner, not a measurement disagreement.

Repro

# baseline is whatever the app launches; then start a second instance with one flag changed
strata.exe --serve --pack <pack> --native <gguf> ... --spec 5 --port 18501
# engine log: "strata verify: window up to 7 tokens"  (spec 4 reports 6)

Guard / persistence checks (read-only, run against the installed Control):

from strata_control import tune_knobs as k, presets as P
ctx = k.Context(context_tokens=204800, family="flash-next")
k.check_setting({"--spec": 5}, {}, ctx)   # ['--spec 5: outside the safe values [3, 4]']

Artifacts

Verbatim from the engine log — the --spec 5 start (trimmed) and the cache line, which is identical
for both runs, so the comparison is apples to apples:

[strata] 2026-10-22 01:21:41 engine started: ...\components\engine\0.1.47-windows-x86_64-cuda-cuda13\strata.exe
         --serve --pack ...\pack --native ...\qwen-nvfp4-gptq-dense.gguf ... --spec 5 ...
strata generate: expert cache auto: 8.01 GiB free, 2048 MiB reserved (+281 MiB for the draft head) -> 2226 slots
strata generate: expert cache 2226 slots, 5.73 GiB of VRAM