diff --git a/docs/research/classifier-context-window-scaling.md b/docs/research/classifier-context-window-scaling.md
new file mode 100644
index 0000000..bc880ff
--- /dev/null
+++ b/docs/research/classifier-context-window-scaling.md
@@ -0,0 +1,249 @@
+# Does the qwen-classifier need to match the main model's context window, and would upgrading it to Qwen3-8B or Qwen3-Coder-30B-A3B-Instruct fit on the current R9700?
+
+**Date:** 2026-09-15
+**Question raised:** should `qwen-classifier` be resized to `LLAMA_CTX_SIZE / LLAMA_PARALLEL` (131072, matching the
+main model's per-slot context), should the classifier model itself move up to Qwen3-8B or
+Qwen3-Coder-30B-A3B-Instruct, and does that need a second GPU?
+
+**Answer: No, no, and not for this reason.** qwen-code's own docs state no context-size requirement for
+`fastModel` at all — the "match the main model" premise doesn't come from any primary source. Separately, and
+independently of context size: neither Qwen3-8B nor Qwen3-Coder-30B-A3B-Instruct fits in the ~6.1GiB of VRAM
+actually free on the card today, at *any* context length, once weights alone are counted — this is a raw-VRAM
+problem, not a context-window problem, exactly matching the "qwen8b needs to offload more to the RAM" intuition
+in the request. A second GPU would solve the VRAM problem (and incidentally remove this repo's own
+`GPU_MAX_HW_QUEUES=1` ROCm#5706 workaround from applying to this pair), but isn't deployed hardware today —
+it's a rack-build/acquisition question, not a config change.
+
+## 1. Does qwen-code require the fast/classifier model to match the main model's context window?
+
+No — checked against the user's own three linked pages, fetched directly:
+
+- **`fastModel` settings docs**: "Model used for generating prompt suggestions and speculative execution,"
+  configurable via `inherit` (main model), `fast`, a model ID, or `authType:model-id`; "Leave empty to use the
+  main model." The docs recommend "a smaller/faster model (e.g., `qwen3-coder-flash`) reduces latency and
+  cost" — **no context-window size or capacity requirement is stated anywhere on this page.**
+  Source: [qwen-code docs — Configuration / Settings, `#fastmodel`](https://qwenlm.github.io/qwen-code-docs/en/users/configuration/settings/#fastmodel)
+
+- **Approval Mode / Auto Mode classifier docs**: describes what the classifier evaluates (shell commands,
+  network calls, out-of-workspace edits) and its allow/block behavior, but **does not name a specific model or
+  state any context-window requirement** — the only operational note is that "when the classifier API is
+  unreachable, the action is blocked rather than allowed."
+  Source: [qwen-code docs — Approval Mode, `#4-auto-mode---classifier-driven-approval`](https://qwenlm.github.io/qwen-code-docs/en/users/features/approval-mode/#4-auto-mode---classifier-driven-approval)
+
+- **Auto Mode "How it works"**: confirms the two-stage design (Stage 1: ~300ms, `{shouldBlock}` only; Stage 2:
+  chain-of-thought reconsideration, only on a Stage-1 block) and what data reaches the classifier — user text,
+  assistant tool-use calls, and tool-specific projections (truncated edit content, fetch URLs, shell command
+  text). **Tool results are explicitly never sent to the classifier.** It "uses your configured fast model
+  (`/model --fast`)," falling back to the main session model only if none is set. **No statement anywhere
+  requires or implies the fast model's context window match the main model's.**
+  Source: [qwen-code docs — Auto Mode, `#how-it-works`](https://qwenlm.github.io/qwen-code-docs/en/users/features/auto-mode/#how-it-works)
+
+This confirms and sharpens what this repo's own `fast-model-choice.md` already found by reading qwen-code's
+source directly (`packages/core/src/permissions/classifier-transcript.ts`: `MAX_TRANSCRIPT_MESSAGES=40`,
+`MAX_HISTORICAL_ACTION_CHARS=4000`/message, worst case ~40-50K tokens, live-tested at 15,116 prompt tokens) —
+that doc already called the original `131072` in `settings.json` "copied from the main model's entry, not a
+real qwen-code requirement." The three docs pages fetched here add nothing that contradicts that: **there is no
+primary-source basis for `LLAMA_CTX_SIZE / LLAMA_PARALLEL` symmetry between the two models.** The current
+`65536` classifier ctx already carries ~1.5x margin over the real worst case.
+
+## 2. VRAM math for Qwen3-8B and Qwen3-Coder-30B-A3B-Instruct as classifier candidates
+
+Same method this repo already uses (`qwen3.8-27b-quant.md`, `fast-model-choice.md` §5): per-token KV cache =
+`layers × 2(K+V) × kv_heads × head_dim × bytes`, read directly from each model's own `config.json`.
+
+### Qwen3-8B
+
+- Architecture (`Qwen/Qwen3-8B` `config.json`): `num_hidden_layers: 36`, `num_key_value_heads: 8`,
+  `num_attention_heads: 32`, `head_dim: 128`, `hidden_size: 4096`, `max_position_embeddings: 40960`,
+  `rope_scaling: null`.
+  Source: [Qwen/Qwen3-8B `config.json`](https://huggingface.co/Qwen/Qwen3-8B/raw/main/config.json)
+- **Native context is 32,768 tokens**, not the 262,144 the user's brief assumed (that number belongs to
+  Qwen3-4B-Instruct-2507, a different, non-reasoning 2507-refresh model — Qwen3-8B is the earlier,
+  thinking-capable Qwen3 architecture with a materially smaller native window). Extending past 32K needs YaRN:
+  > "Qwen3 natively supports context lengths of up to 32,768 tokens. For conversations where the total length
+  > (including both input and output) significantly exceeds this limit, we recommend using RoPE scaling
+  > techniques to handle long texts effectively."
+  and llama.cpp-specific YaRN invocation is given explicitly:
+  `./llama-cli ... -c 131072 --rope-scaling yarn --rope-scale 4 --yarn-orig-ctx 32768`, with a documented
+  caveat that "all the notable open-source frameworks implement **static** YaRN, which means the scaling
+  factor remains constant regardless of input length, potentially impacting performance on shorter texts."
+  Source: [Qwen/Qwen3-8B-GGUF — Processing Long Texts](https://huggingface.co/Qwen/Qwen3-8B-GGUF#processing-long-texts)
+- **Weights** (official Qwen quants, fetched from the GGUF repo file list): Q5_K_M = 5.85 GB, Q8_0 = 8.71 GB.
+  Source: [Qwen/Qwen3-8B-GGUF](https://huggingface.co/Qwen/Qwen3-8B-GGUF)
+  *(Not independently verified: unsloth's equivalent `UD-Q4_K_XL` quant, which is what this repo's
+  `docker-compose.yml`/`.env.example` actually download for every model deployed so far — the unsloth file
+  size wasn't fetched, only the official Qwen quants above. Treat Q5_K_M/Q8_0 as a reasonable bound, not the
+  exact file this repo would pull.)*
+- Per-token KV cache: `36 × 2 × 8 × 128 × 2 bytes = 144 KiB/token` fp16 — identical to Qwen3-4B-Instruct-2507's
+  figure in `fast-model-choice.md` §5, since both share the same `layers/kv_heads/head_dim` triple.
+
+| Context | KV (fp16) | KV (q8_0) | KV (q4_0, current classifier setting) |
+|---|---|---|---|
+| 65,536 (current classifier ctx) | 9.0 GiB | 4.5 GiB | **2.25 GiB** |
+| 131,072 (user's proposed "match main model") | 18.0 GiB | 9.0 GiB | **4.5 GiB** |
+
+Weights + KV (q4_0, smallest realistic combo):
+
+| Context | Q5_K_M weights + q4_0 KV | Q8_0 weights + q4_0 KV |
+|---|---|---|
+| 65,536 | 5.85 + 2.25 = **8.1 GB** | 8.71 + 2.25 = **10.96 GB** |
+| 131,072 | 5.85 + 4.5 = **10.35 GB** | 8.71 + 4.5 = **13.21 GB** |
+
+### Qwen3-Coder-30B-A3B-Instruct
+
+- Architecture (fetched from the shared Qwen3-30B-A3B-family `config.json`): `num_hidden_layers: 48`,
+  `num_key_value_heads: 4`, `num_attention_heads: 32`, `head_dim: 128`, `hidden_size: 2048`, **MoE**:
+  `num_experts: 128`, `num_experts_per_tok: 8` (8 of 128 experts active per token — confirms this is a sparse
+  MoE model, not a dense one like the 27B or 8B candidates; the "active params" figure describes *compute*
+  per token, not memory footprint — **all 128 experts' weights still have to be resident** wherever the model
+  is loaded, GPU or RAM).
+  Source: [Qwen/Qwen3-30B-A3B-family `config.json`](https://huggingface.co/Qwen/Qwen3-30B-A3B/raw/main/config.json)
+- **UD-Q4_K_XL file size (the exact quant/quantizer this repo already standardizes on): 17.7 GB.** 30.5B total /
+  3.3B activated parameters. Native context "262,144 natively... can be extended further using Yarn to reach
+  1M tokens."
+  Source: [unsloth/Qwen3-Coder-30B-A3B-Instruct-GGUF](https://huggingface.co/unsloth/Qwen3-Coder-30B-A3B-Instruct-GGUF?show_file_info=Qwen3-Coder-30B-A3B-Instruct-UD-Q4_K_XL.gguf)
+- Per-token KV cache: `48 × 2 × 4 × 128 × 2 bytes = 96 KiB/token` fp16 (smaller per-token than the 8B/4B
+  candidates, since `num_key_value_heads` is 4 here vs. 8 — but this saving is irrelevant given the weights
+  size below).
+
+| Context | KV (fp16) | KV (q8_0) | KV (q4_0) |
+|---|---|---|---|
+| 65,536 | 6.0 GiB | 3.0 GiB | **1.5 GiB** |
+| 131,072 | 12.0 GiB | 6.0 GiB | **3.0 GiB** |
+
+Weights + KV (q4_0):
+
+| Context | Total |
+|---|---|
+| 65,536 | 17.7 + 1.5 = **19.2 GB** |
+| 131,072 | 17.7 + 3.0 = **20.7 GB** |
+
+## 3. Does either candidate fit the ~6.1 GiB actually free on the card today?
+
+**No — neither does, at either context size, even at the smallest quant/KV-quant combination tested.**
+
+- Qwen3-8B's cheapest realistic combination (Q5_K_M weights + q4_0 KV at the *current* 65536 ctx, not even
+  the proposed 131072) is **8.1 GB — already ~2 GB over the measured 6.1 GiB free budget**, before accounting
+  for compute-buffer/batch overhead that `fast-model-choice.md` §"Implementation note" already found could add
+  meaningfully on top of the naive weights+KV estimate (that's exactly why the 4B classifier ended up needing
+  `--flash-attn on` and partial 28/36-layer offload instead of the originally-predicted comfortable full-GPU
+  fit).
+- Qwen3-Coder-30B-A3B-Instruct isn't close at any setting tested — its weights alone (17.7 GB) are triple the
+  entire free budget, and this doesn't change with context size since the weights term dominates.
+- This is a **VRAM-capacity problem, not a context-window problem** — directly confirming the "qwen8b needs to
+  offload more to the RAM" intuition in the original request. Reducing context doesn't fix it; the weights
+  don't fit regardless.
+
+**CPU/RAM offload mechanics:** llama.cpp's `--n-gpu-layers` is documented as "max. number of layers to store in
+VRAM, either an exact number, `'auto'`, or `'all'`" — the layers not selected are computed on CPU, with the
+model loaded via mmap by default (same mechanism this repo's own `.env.example` already documents for
+`LLAMA_GPU_LAYERS`: "if GPU+RAM ever can't hold the working set, the OS pages the rest in from disk
+automatically"). For the MoE Coder-30B-A3B model specifically, this repo's own `.env.example` already flags the
+more targeted alternative — `--n-cpu-moe`/`--cpu-moe`/`--override-tensor "exps"` — as the flags that "target
+Mixture-of-Experts models (e.g. Qwen3.8-2.4T-A95B)," i.e. exactly this model's architecture: these offload only
+expert-tensor weights to CPU while keeping attention/shared layers and KV cache on GPU, which is the
+mechanically correct lever for an MoE model, unlike the blunt `--n-gpu-layers` used for the dense 8B/27B/4B
+models. **Neither llama.cpp's own README nor the Qwen model cards fetched here document a quantified
+performance cost for partial offload** — no primary source gives a "N layers offloaded = X% slower" figure.
+Source: [llama.cpp `tools/server/README.md`](https://raw.githubusercontent.com/ggml-org/llama.cpp/master/tools/server/README.md)
+
+What *is* directly measured, in this repo's own deployment history: CPU-only was tried first for the current,
+much smaller 4B classifier and rejected — "too slow in practice: real classification calls blew past
+OmniRoute's 60s timeout and retry-looped (504→499→504)" (`docker-compose.yml`'s `qwen-classifier` comment
+block). An 8B dense model has roughly double the compute of the 4B model per token; a 30B-A3B model's *routing*
+overhead on CPU (choosing 8 of 128 experts per token, each a separate weight lookup) adds a different kind of
+cost that neither this repo nor the sources fetched here have measured. **Given the classifier's Stage 1 has an
+explicit ~300ms latency budget** (`fast-model-choice.md` §1, from qwen-code's own docs), and this repo already
+has one concrete data point that CPU offload breaks that budget at a smaller model size, extending either
+candidate onto significant CPU offload carries real, unquantified latency risk — the same failure mode already
+observed once, at a favorable (smaller) model size.
+
+## 4. Does a second GPU solve this, and is one actually available?
+
+**Not today.** `docs/server-planing.md` is a rack-build plan for "3-4x AMD Radeon AI PRO R9700 (32GB) GPUs" —
+a future-state document, not present inventory. Every GPU-facing comment in this repo's own
+`docker-compose.yml`/`.env.example`/`rocm-gpu-pin-and-render-group.md` consistently refers to "the single 32GB
+R9700" and measures the "~6.1GiB free" budget against one physical card holding both `llama-server` and
+`qwen-classifier`. Adding a second GPU is a hardware-acquisition and rack-build question — physically sourcing,
+installing, and power/PCIe-provisioning a card per `server-planing.md`'s own build plan — not a
+`docker-compose.yml`/`.env.example` change.
+
+**If a second GPU were added**, it would directly remove one already-documented risk for this specific pair:
+this repo's own `rocm-gpu-pin-and-render-group.md` traced the GPU-pinned-at-100%/ROCm#5706 bug to its precise
+trigger condition —
+
+> "The pin only appears with two concurrent HIP-context-holding processes **on the same GPU**... Root cause: an
+> AMD MES (Micro Engine Scheduler) firmware bug triggered by HIP hardware-queue creation."
+Source: [ROCm/ROCm#5706](https://github.com/ROCm/ROCm/issues/5706), via this repo's own
+[`rocm-gpu-pin-and-render-group.md`](rocm-gpu-pin-and-render-group.md)
+
+Since the confirmed trigger is *two HIP contexts sharing one physical card*, moving the classifier to its own,
+second GPU would put each service on a single-HIP-context card — the condition that trips the bug wouldn't
+exist for this pair anymore, and the `GPU_MAX_HW_QUEUES=1` workaround currently applied to both services
+specifically because they share one card would no longer be load-bearing for *this* pair (it would still apply
+if any future third service shared a card with either model). This wasn't independently re-verified across two
+*separate* physical cards by any source fetched in this pass — it's a direct extrapolation from the confirmed
+root cause, same category of caveat that doc's own author already flagged for its within-one-card claim.
+
+## Bottom line / recommendation
+
+1. **Don't apply `LLAMA_CTX_SIZE / LLAMA_PARALLEL` symmetry to the classifier.** No qwen-code primary source
+   states or implies the fast/classifier model needs to match the main model's context window. The real
+   requirement (§1, already established in `fast-model-choice.md`) is ~40-50K tokens worst case; the current
+   `65536` already has margin. Doubling to 131072 would only double VRAM spent on KV cache for a model that
+   won't otherwise fit anyway (§2-3).
+2. **Don't upgrade the classifier to Qwen3-8B or Qwen3-Coder-30B-A3B-Instruct on the current single-GPU setup.**
+   Neither fits the ~6.1GiB actually free, at any context size — this is a weights-size problem, not a
+   context-window problem. Forcing it would mean either (a) shrinking the main 27B model's own VRAM footprint
+   to make room (a real trade-off against the primary model, not evaluated here), or (b) CPU/partial offload,
+   which this repo has direct, measured evidence already breaks the classifier's latency budget at a *smaller*
+   model size than either candidate.
+3. **A second GPU is the clean fix for VRAM contention and would also retire the ROCm#5706 workaround's
+   relevance for this pair — but it isn't deployed hardware today.** `server-planing.md` is a future build
+   plan; this is an acquisition/rack-build decision, not something achievable via a config change right now.
+4. If the actual underlying motivation is classifier *quality* (not context capacity), that's a separate,
+   legitimate question this doc doesn't answer — worth its own research pass rather than solving it via a
+   bigger model that doesn't fit the hardware.
+
+## Sources
+
+- [qwen-code docs — Configuration / Settings, `#fastmodel`](https://qwenlm.github.io/qwen-code-docs/en/users/configuration/settings/#fastmodel)
+- [qwen-code docs — Approval Mode, `#4-auto-mode---classifier-driven-approval`](https://qwenlm.github.io/qwen-code-docs/en/users/features/approval-mode/#4-auto-mode---classifier-driven-approval)
+- [qwen-code docs — Auto Mode, `#how-it-works`](https://qwenlm.github.io/qwen-code-docs/en/users/features/auto-mode/#how-it-works)
+- [Qwen/Qwen3-8B `config.json`](https://huggingface.co/Qwen/Qwen3-8B/raw/main/config.json)
+- [Qwen/Qwen3-8B-GGUF](https://huggingface.co/Qwen/Qwen3-8B-GGUF)
+- [Qwen/Qwen3-8B-GGUF — Processing Long Texts](https://huggingface.co/Qwen/Qwen3-8B-GGUF#processing-long-texts)
+- [Qwen/Qwen3-30B-A3B-family `config.json`](https://huggingface.co/Qwen/Qwen3-30B-A3B/raw/main/config.json)
+- [unsloth/Qwen3-Coder-30B-A3B-Instruct-GGUF](https://huggingface.co/unsloth/Qwen3-Coder-30B-A3B-Instruct-GGUF?show_file_info=Qwen3-Coder-30B-A3B-Instruct-UD-Q4_K_XL.gguf)
+- [llama.cpp `tools/server/README.md`](https://raw.githubusercontent.com/ggml-org/llama.cpp/master/tools/server/README.md)
+- [ROCm/ROCm#5706](https://github.com/ROCm/ROCm/issues/5706)
+- [docs/research/fast-model-choice.md](fast-model-choice.md) (this repo — classifier transcript sizing,
+  qwen-classifier's real deployment history)
+- [docs/research/qwen3.8-27b-quant.md](qwen3.8-27b-quant.md) (this repo — KV-cache-from-config.json method
+  reused here)
+- [docs/research/rocm-gpu-pin-and-render-group.md](rocm-gpu-pin-and-render-group.md) (this repo — ROCm#5706
+  trigger condition and `GPU_MAX_HW_QUEUES` scoping)
+- [docs/server-planing.md](../server-planing.md) (this repo — confirms only 1 of a planned 4 GPUs is deployed)
+- `docker-compose.yml`, `.env.example` (this repo — current `qwen-classifier`/`llama-server` config and the
+  measured "~6.1GiB free" VRAM figure)
+
+## Confidence / uncertainty summary
+
+- **High confidence:** qwen-code's `fastModel`/Auto-Mode docs state no context-window requirement (direct
+  quotes from all three linked pages); Qwen3-8B's native 32,768 context and YaRN caveat (direct model-card
+  quote); Qwen3-Coder-30B-A3B-Instruct's MoE architecture and 17.7GB Q4_K_XL file size (direct from the
+  quantizer's own repo page); the KV-cache-per-token math for both candidates (computed directly from each
+  model's own `config.json`, same method already validated in this repo's prior research); the ROCm#5706
+  trigger condition being scoped to two HIP contexts on the *same* GPU (direct quote from this repo's own
+  prior research, itself sourced from the upstream issue).
+- **Medium confidence:** the exact unsloth `UD-Q4_K_XL`-equivalent file size for Qwen3-8B — only the official
+  Qwen quants (Q5_K_M/Q8_0) were fetched, not unsloth's own repo, so the real number this repo would actually
+  download wasn't directly verified (bounded reasonably by the Q5_K_M figure, which is already the smallest
+  realistic option and still doesn't fit). The claim that CPU/partial-offload latency risk scales unfavorably
+  for larger/MoE models is a reasoned extrapolation from this repo's one measured data point (4B CPU-only
+  rejected) plus general MoE-routing-overhead reasoning, not a directly measured benchmark for either candidate.
+- **Low confidence / not independently verified:** whether `GPU_MAX_HW_QUEUES=1`/ROCm#5706 genuinely has zero
+  relevance across two *separate* physical GPUs (extrapolated from the confirmed same-GPU trigger condition,
+  same caveat this repo's own prior research already flagged for its own claim); no primary source found that
+  quantifies llama.cpp's actual inference-speed penalty for partial `--n-gpu-layers` or `--n-cpu-moe` offload
+  in general — this is a documented gap in the sources checked, not a guessed number.