frank-dragoon gets a 200,000-token harness context window instead of 155,648. To do that lawfully, the engine's per-request ceiling moves from 200,704 to the checkpoint's native 262,144. No RAM moves: the KV pool stays 401,408 (it is what the boot ledger bills, 11.0 GiB) and the band ctx ≤ pool ≤ slots × ctx still holds.
Why the same 400s keep coming back
Three contracts, never enforced in one place:
The harness clamps max_tokens to window − est − 4096, and its chars/4 estunder-counts code/agent traffic ~3 % (measured 2026-10-07: est 152,938 vs server 157,388 — a 400 by 354 tokens).
config.yml compacts at 95 % of the window while every comment/runbook designed around 85 % — the disagreement the vault flagged open on 2026-10-18.
The 2026-10-17 swap cut the ceiling to 200,704, so the fit law (window ~45k under ceiling) forced contextWindow down to 155,648. Any pair that drifts back toward the ceiling puts every long session in the 400 zone — invisibly, since the refusal only appears when est overshoots.
Unit description + deployer comment: shape text follows.
Fit-law seam hardened (tests/frank_dragoon_unit.bats): it now reads the declared harness window from the vault page (the one owner), pins the ceiling, and re-runs the fit arithmetic at the live 95 % trigger (stronger than the old 85 % check). A ceiling/window pair that drifts back together fails ./tests/run.sh, not a live session.
Docs: endpoint page (shape, harness contract, 400-zone law rewritten with the 95 % cause), AGENTS.md, OMP Harness worked example recomputed to the live pair.
Compaction ride on frank-zealot: 190,000 − 20,000 keepRecent ≈ 175k measured ≤ its 200,704 slot.
Concurrency trade: two literal ceiling-length (262k) requests would queue (pool 401,408 < 524,288); two maximum harness-length (200k) conversations stay resident as before. Widening that is a pool raise, and RAM the pool takes is RAM the n-gram table's page cache loses.
Verification / deploy order
./tests/run.sh: 490/490 green.
After merge: ./scripts/deploy.sh dankclaw --service frank-dragoon, then gate = boot ledger (pool line, no clamp line — HALOGEN_KV_POOL_FIT only prints when it clamps) + /health + tool call + red-PNG probe.
Then ~/.omp/agent/models.ymlcontextWindow: 200000 (harness config, no repo copy) — deliberately after the ceiling is live: 200,000 under the old 200,704 ceiling is exactly the old bug.
Rollback: revert 56503db + redeploy (window back to 155,648 in models.yml).
## What
frank-dragoon gets a **200,000-token harness context window** instead of 155,648. To do that lawfully, the engine's per-request ceiling moves from 200,704 to the checkpoint's **native 262,144**. No RAM moves: the KV pool stays 401,408 (it is what the boot ledger bills, 11.0 GiB) and the band `ctx ≤ pool ≤ slots × ctx` still holds.
## Why the same 400s keep coming back
Three contracts, never enforced in one place:
1. The harness clamps `max_tokens` to `window − est − 4096`, and its chars/4 `est` **under-counts** code/agent traffic ~3 % (measured 2026-10-07: est 152,938 vs server 157,388 — a 400 by 354 tokens).
2. `config.yml` compacts at **95 %** of the window while every comment/runbook designed around **85 %** — the disagreement the vault flagged open on 2026-10-18.
3. The 2026-10-17 swap cut the ceiling to 200,704, so the fit law (window ~45k under ceiling) forced `contextWindow` down to 155,648. Any pair that drifts back toward the ceiling puts every long session in the 400 zone — invisibly, since the refusal only appears when est overshoots.
## The change
- `scripts/frank-dragoon.env`: `HALOGEN_CTX=262144` (native; YARN beyond native stays off-plan). Pool/slots untouched.
- Unit description + deployer comment: shape text follows.
- **Fit-law seam hardened** (`tests/frank_dragoon_unit.bats`): it now reads the declared harness window from the vault page (the one owner), pins the ceiling, and re-runs the fit arithmetic at the **live 95 % trigger** (stronger than the old 85 % check). A ceiling/window pair that drifts back together fails `./tests/run.sh`, not a live session.
- Docs: endpoint page (shape, harness contract, 400-zone law rewritten with the 95 % cause), AGENTS.md, OMP Harness worked example recomputed to the live pair.
## Arithmetic after the change
- Worst-case ordinary request: `200,000 − 4,096` est ×1.03 ≈ **201.8k** ≤ 262,144.
- Trigger point: `190,000 × 1.03 + 45,056 ≈ 240.7k` ≤ 262,144.
- Compaction ride on frank-zealot: `190,000 − 20,000 keepRecent ≈ 175k` measured ≤ its 200,704 slot.
- Concurrency trade: two literal ceiling-length (262k) requests would queue (pool 401,408 < 524,288); two maximum **harness-length** (200k) conversations stay resident as before. Widening that is a pool raise, and RAM the pool takes is RAM the n-gram table's page cache loses.
## Verification / deploy order
- `./tests/run.sh`: 490/490 green.
- After merge: `./scripts/deploy.sh dankclaw --service frank-dragoon`, then gate = boot ledger (pool line, **no clamp line** — `HALOGEN_KV_POOL_FIT` only prints when it clamps) + `/health` + tool call + red-PNG probe.
- Then `~/.omp/agent/models.yml` `contextWindow: 200000` (harness config, no repo copy) — deliberately **after** the ceiling is live: 200,000 under the old 200,704 ceiling is exactly the old bug.
Rollback: revert `56503db` + redeploy (window back to 155,648 in models.yml).
---
cwd: /home/blank/.omp/wt/wt-20261020-125416-6d1fc1f · session: 01a15d93-efb8-7108-b94d-4fabb14597ef
The 200,704 ceiling squeezed the harness contextWindow down to 155,648
(the 400-zone fit law needs ~45k of gap under the ceiling), which is why
long dragoon sessions kept hitting the 400 zone: the harness clamps
max_tokens to window - est - 4096, its chars/4 est under-counts ~3 %,
and config.yml compacts at 95 % while the pair was designed for 85 %.
Ceiling -> checkpoint's native 262,144 (no RAM move: the KV pool stays
401,408 and is what the ledger bills; the band ctx <= pool <= slots*ctx
still holds). The harness window becomes 200,000 with a 62,144 gap.
The fit-law seam now reads the declared window from the vault page (the
one owner) and checks the arithmetic at the live 95 % trigger, so a
ceiling/window pair that drifts back together fails tests/run.sh
instead of a live session.
Shape + harness contract on the endpoint page, AGENTS.md, and the OMP
Harness worked example recomputed to the live pair; the 400-zone law now
names the 85 %-comments vs 95 %-config disagreement as the recurring
cause and points at the seam that enforces the arithmetic.
dank
merged commit 9eb53ef937 into main2026-10-21 01:40:40 -07:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What
frank-dragoon gets a 200,000-token harness context window instead of 155,648. To do that lawfully, the engine's per-request ceiling moves from 200,704 to the checkpoint's native 262,144. No RAM moves: the KV pool stays 401,408 (it is what the boot ledger bills, 11.0 GiB) and the band
ctx ≤ pool ≤ slots × ctxstill holds.Why the same 400s keep coming back
Three contracts, never enforced in one place:
max_tokenstowindow − est − 4096, and its chars/4estunder-counts code/agent traffic ~3 % (measured 2026-10-07: est 152,938 vs server 157,388 — a 400 by 354 tokens).config.ymlcompacts at 95 % of the window while every comment/runbook designed around 85 % — the disagreement the vault flagged open on 2026-10-18.contextWindowdown to 155,648. Any pair that drifts back toward the ceiling puts every long session in the 400 zone — invisibly, since the refusal only appears when est overshoots.The change
scripts/frank-dragoon.env:HALOGEN_CTX=262144(native; YARN beyond native stays off-plan). Pool/slots untouched.tests/frank_dragoon_unit.bats): it now reads the declared harness window from the vault page (the one owner), pins the ceiling, and re-runs the fit arithmetic at the live 95 % trigger (stronger than the old 85 % check). A ceiling/window pair that drifts back together fails./tests/run.sh, not a live session.Arithmetic after the change
200,000 − 4,096est ×1.03 ≈ 201.8k ≤ 262,144.190,000 × 1.03 + 45,056 ≈ 240.7k≤ 262,144.190,000 − 20,000 keepRecent ≈ 175kmeasured ≤ its 200,704 slot.Verification / deploy order
./tests/run.sh: 490/490 green../scripts/deploy.sh dankclaw --service frank-dragoon, then gate = boot ledger (pool line, no clamp line —HALOGEN_KV_POOL_FITonly prints when it clamps) +/health+ tool call + red-PNG probe.~/.omp/agent/models.ymlcontextWindow: 200000(harness config, no repo copy) — deliberately after the ceiling is live: 200,000 under the old 200,704 ceiling is exactly the old bug.Rollback: revert
56503db+ redeploy (window back to 155,648 in models.yml).cwd: /home/blank/.omp/wt/wt-20261020-125416-6d1fc1f · session: 01a15d93-efb8-7108-b94d-4fabb14597ef