frank-dragoon: lower the context to 200704 (ctx and pool together)

Frank's call the same evening as the native-payload cutover: HALOGEN_CTX and
HALOGEN_KV_POOL_POSITIONS both 262144 -> 200704 (a multiple of 4096, the rung
frank-zealot already runs). The checkpoint's native window is 262,144 and the
engine serves anything below it, so this is a RAM decision, not a capability
limit: the KV reservation drops 7.2 GiB -> ~5.4 (the 2026-10-06 pool measured
14.6), and by the FLAGS.md law -- RAM the pool takes is RAM that n-gram table
loses -- the freed positions become page cache for the 47.68 GiB table that
long prompts read. Engine-side total ~74 GiB instead of 75.8.

The 400-zone law is invariant to the value, so the harness moves WITH the
ceiling: models.yml contextWindow 217088 -> 155648 = ceiling - 45056, keeping
the gap that absorbs the chars/4 under-count (worst-case request ~156.2k vs
the 200,704 ceiling, ~44k margin). Compaction now fires at 85% = 132,300 est
(~136k measured); the 180k target of the 262,144 era is unreachable because
the window itself is 155,648. maxTokens 45056 and the coupled
cap/timeout 65536/7200 are untouched.

Cost stated plainly: with pool == ctx, ONE maximum-length request fills the
pool, so two long conversations never coexist (two of <=100k do). Acceptable
because frank-dragoon carries only the slow role and the security-reviewer
subagent, not the interactive workhorse.

Seam re-keyed: the fit-law test now proves the invariant at the new pair, and
the pool law (ctx <= pool <= slots * ctx) still holds with pool == ctx.

scripts/deploy-remote.sh

@@ -1097,9 +1097,9 @@ deploy_anubis() {
 # conversion (2026-10-11) of the abliterated Qwen3.8-Flash-Next —
 # qwen38-flash-next-v2-abliterated.hgn (66,687,678,432 B, ~62 GiB resident)
 # + the REQUIRED n-gram lookup table + the vision tower — MTP spec decode
-# (HALOGEN_SPEC_ADAPT=0), 2 slots over ONE 262,144-position KV pool, image
-# input — on the Strix Halo iGPU. It stays a ROOT unit because the serve
-# script drives `podman run` directly (the frank-archon pattern):
+# (HALOGEN_SPEC_ADAPT=0), 2 slots over ONE 200,704-position KV pool at the
+# matching ctx 200704 ceiling, image input — on the Strix Halo iGPU. It stays a
+# ROOT unit because the serve script drives `podman run` directly (the frank-archon pattern):
 # relink_unit points /etc/systemd/system/frank-dragoon.service at the repo
 # file, boot persistence is that unit's [Install], and LimitMEMLOCK=infinity
 # is fleet parity. 2026-10-17 cutover from the Swift1.5-finetune shape —

scripts/frank-dragoon.env

@@ -20,6 +20,10 @@
 # thinking tokens 1,476 vs 784 mean — the finetune compressed reasoning, the
 # base thinks ~1.9x longer per answer.
 #
+# The A/B ran at the card's ctx/pool of 262,144. Afterwards Frank lowered both
+# to 200,704 (RAM + the harness's compaction budget); the rates above are the
+# ceiling-262,144 record and the production ledger is the 200,704 one.
+#
 # WHY THE RUNTIME MOVED WITH THE MODEL: the payload is .hgn — per its own
 # card it "will not load in transformers, vLLM, or llama.cpp" — and the v2
 # .hgn loads ONLY in the flash-server line (the old halogen engine is for
@@ -29,50 +33,54 @@
 # the censored 27B (905 mean), the ABLITERATED base (refusals should NOT
 # return), IMAGE INPUT (the v2 vision tower loads beside the checkpoint —
 # red-PNG probe verified on the card; the 27B engine ignored its encoder),
-# tool calls verified, and the native 262,144 context.
+# tool calls verified, and the native 262,144 context — served at 200,704 by
+# choice from 2026-10-17 (see SHAPE: the ceiling is a RAM decision, not a
+# capability limit).
 #
 # SHAPE — the knobs that are NOT free, with the arithmetic:
-#   HALOGEN_CTX=262144 is the PER-SLOT window and the per-conversation hard
-#   ceiling — a prompt over it is a 400 naming the limit, never a silent
-#   truncation. RAISED from 200192 on 2026-10-07: the harness clamps
-#   max_tokens to contextWindow − est − 4096, its chars/4 est UNDER-counts
-#   the rendered prompt by ~3 % on code/agent traffic, and compaction only
-#   fires at 85 % — so with window == engine ceiling, every request over
-#   ~146k est (65-85 % of the window) was a guaranteed 400. Measured
-#   2026-10-07: est 152,938, server 157,388, request 43,158 vs room 42,804
-#   — over by 354, margin 4,096 < the 4,450 under-count.
-#   Harness contract (models.yml): contextWindow 217088, maxTokens 45056.
-#   Compaction fires at 85 % = 184,524 est ≈ 190k measured (Frank's 180k
-#   target). Worst-case request: prompt + budget <= 217088 − 4096 + 3 %
-#   est-error ≈ 219k <= 262144 — the 45k gap between harness window and
-#   engine ceiling absorbs the estimate error with ~7x margin (robust to a
-#   10 % under-count). Compaction rides on frank-zealot: input ≈
-#   threshold − keepRecent(20k) ≈ 170k measured, inside its 200,704 slot.
-#   HALOGEN_KV_POOL_POSITIONS=262144 is the card's recommended pool and the
-#   memory saving of this swap. One budget behind HALOGEN_KV_SLOTS=2 (boot
-#   ledger: "2 slots over ONE 262144-position KV pool, each request up to
-#   262144"), so the per-request ceiling stays HALOGEN_CTX while two
-#   MAXIMUM-length conversations can no longer coexist — two moderate ones
-#   can. ~28 KiB/position (FLAGS.md) => 7.2 GiB, and the ledger said exactly
-#   that: "reserving the KV pool, 262144 positions (about 7.2 GiB)". The
-#   2026-10-06 shape's 524,288 cost 14.6 GiB; FLAGS.md law — "RAM the pool
-#   takes is RAM that table loses" — makes the 7.4 GiB handed back page
-#   cache for the 47.7 GiB n-gram table, which is what long prompts read.
+#   HALOGEN_CTX=200704 is the PER-REQUEST ceiling and the per-conversation
+#   hard limit — a prompt over it is a 400 naming the limit, never a silent
+#   truncation. LOWERED from 262,144 on 2026-10-17 at Frank's direction (the
+#   checkpoint's native window is 262,144 and the engine serves anything
+#   below it): every position costs KV pool RAM and shrinks the prompt-cache
+#   entry (111 MiB at 262,144, ~85 MiB here). The 400-zone law is INVARIANT
+#   to the value — it says the harness window must sit ~45k UNDER the engine
+#   ceiling, because the harness clamps max_tokens to contextWindow − est −
+#   4096, its chars/4 est UNDER-counts the rendered prompt by ~3 % on
+#   code/agent traffic, and compaction only fires at 85 % (measured 2026-10-07
+#   at the old 200,192 ceiling: est 152,938, server 157,388, over by 354).
+#   Harness contract (models.yml): contextWindow 155648 (= ceiling − 45056,
+#   the gap that absorbs the estimate error), maxTokens 45056.
+#   Compaction fires at 85 % = 132,301 est ≈ 136k measured — the 180k target
+#   of the 262,144 era is unreachable at this ceiling: the window itself is
+#   155,648. Worst-case request: prompt + budget <= 155648 − 4096 + 3 %
+#   est-error ≈ 156.2k <= 200,704 — ~9.5× the 3 % error of margin (robust to a
+#   ~25 % under-count). Compaction rides on frank-zealot: input ≈ threshold −
+#   keepRecent(20k) ≈ 112k, inside its 200,704 slot.
+#   HALOGEN_KV_POOL_POSITIONS=200704 — ONE pool behind HALOGEN_KV_SLOTS=2
+#   (ledger form: "2 slots over ONE <pool>-position KV pool, each request up to
+#   HALOGEN_CTX"). With pool == ctx a single MAXIMUM-length request fills the
+#   whole pool. ~28 KiB/position (FLAGS.md) ⇒ ~5.4 GiB, where 262144 cost 7.2
+#   and the 2026-10-06 shape's 524,288 measured 14.6. The engine's own preflight
+#   formula bills a little more than the reservation because it adds block
+#   scratch and ~115 MiB/slot of O(1) state — quote the RESERVATION for the RAM
+#   ledger. FLAGS.md law: "RAM the pool takes is RAM that table loses", so every
+#   position cut is page cache for the 47.68 GiB n-gram table long prompts read.
 #   HALOGEN_KV_SLOTS=2 restores the w4b-era shape on this box: the MTP
 #   drafter is NOT slot-locked on this engine (batching and speculation
 #   coexist — DFlash-era slots>1 law does NOT carry over; the card's own
 #   quickstart ships 2 slots WITH the head), so the second slot is
 #   concurrent capacity, not a speculation tax.
 #   Memory ledger against the box's 121.2 GiB unified (the n-gram table is
-#   mmap'd page cache beside the checkpoint, not a pinned charge — the
-#   card's own quickstart arithmetic does not bill it, and the boot ledger
-#   agrees: "mapped 51.2 GB, NOT pinned (Pin::None)"):
-#     weights ~62 GiB resident + KV 7.2 + arena (HALOGEN_MAX_TOK=8192 =>
-#     ~8 GiB per FLAGS.md arena formula 3.8+8.4*(MT/16384)) + vision ~2
-#     = ~79 GiB engine-side; HALOGEN_HOST_RESERVE_GIB=20 keeps the host
+#   mmap'd page cache beside the checkpoint, not a pinned charge — the boot
+#   ledger agrees: "mapped 51.2 GB, NOT pinned (Pin::None)"):
+#     weights ~62.9 GiB locked (0.8 of them the vision tower) + KV ~5.4 +
+#     working ~5.7 (HALOGEN_MAX_TOK=8192) ≈ 74 GiB engine-side, with the
+#     prompt cache (~1.0 at this ctx; 1.3 was measured at 262144) booked
+#     separately by the ledger; HALOGEN_HOST_RESERVE_GIB=20 keeps the host
 #     honest; baseline co-tenancy (frank-zealot, ComfyUI, Caddy/observ)
-#     ~10-15. ~25 GiB margin. The boot ledger is the referee — read it
-#     after deploy and re-size if the engine prints a clamp.
+#     ~10-15. ~30 GiB margin. The boot ledger is the referee — read it after
+#     deploy and re-size if the engine prints a clamp.
 #   HALOGEN_SPEC_ADAPT=0 is MANDATORY (card): the default adaptive policy
 #   turns the MTP head off for whole requests after low acceptance and
 #   HALVES decode as a result. Frank accepted the head always-on trade
@@ -99,11 +107,11 @@
 #     so the models.yml fold (high->xhigh) still applies.
 #   * Vision: OpenAI image_url content parts only (the fleet's standard
 #     contract). >=256 px probe images or the model answers "video".
-#   * TWO maximum-length conversations no longer share the endpoint: the KV
-#     pool is one 262,144-position budget behind 2 slots. The PER-REQUEST
-#     ceiling is unchanged (HALOGEN_CTX), so the harness contract below
-#     (contextWindow 217088) does not move; only concurrency at full depth
-#     does, and this endpoint carries the slow + security-reviewer roles.
+#   * Concurrency at depth is tight now: the KV pool is ONE 200,704-position
+#     budget behind 2 slots — exactly one maximum-length request fills it. Two
+#     conversations coexist only while they stay under ~100k each. The
+#     PER-REQUEST ceiling moved WITH the pool (262144 -> 200704), so the harness
+#     contract moves too: contextWindow 155648 = ceiling − 45k, never higher.
 #   * response_format json_object/json_schema unsupported in this line
 #     (no constrained decoding) — unchanged from the 27B engine.
 #   * The engine's token protocol has no auth and binds loopback INSIDE
@@ -165,8 +173,8 @@ FRANK_DRAGOON_TOKENIZER_FILES="tokenizer.json chat_template.jinja tokenizer_conf
 # scripts and this file keep the frank-dragoon name. OpenWebUI api_configs
 # model_ids for the :7770 backend MUST name this value.
 HALOGEN_MODEL_ID=frank-dragoon
-HALOGEN_CTX=262144
-HALOGEN_KV_POOL_POSITIONS=262144
+HALOGEN_CTX=200704
+HALOGEN_KV_POOL_POSITIONS=200704
 HALOGEN_KV_SLOTS=2
 HALOGEN_HOST_RESERVE_GIB=20
 # Spec decode: MTP head is INSIDE the checkpoint (do NOT set HALOGEN_MTP_HEAD);

scripts/frank-dragoon.service

@@ -1,5 +1,5 @@
 [Unit]
-Description=halogen-flash-server container (Quat3rnion NATIVE v2 abliterated Qwen3.8-Flash-Next, MTP spec decode, 2 slots over ONE 262144-position pool, vision ON), root systemd unit (dankclaw, frank-dragoon, Strix Halo iGPU)
+Description=halogen-flash-server container (Quat3rnion NATIVE v2 abliterated Qwen3.8-Flash-Next, MTP spec decode, 2 slots over ONE 200704-position pool at ctx 200704, vision ON), root systemd unit (dankclaw, frank-dragoon, Strix Halo iGPU)
 After=network-online.target
 Wants=network-online.target