# Quest Turbo (QUEST-30B-RL) — full B70 bench: Paretos + live + games

Model: **QUEST-30B-RL** — arch **`qwen3moe`** (48 layers, 128 experts / 8 active, 2048 embed, ~30B,
native ctx 262144), **Q5_K_M** (21 GB), llama.cpp SYCL on a single **Intel Arc Pro B70** (30.3 GiB),
`llama-server`. **Different architecture from the qwen3_5_moe family** (no gated-delta-net) → measured,
not extrapolated. Served on **:8092** (prod `:8090` untouched). Run date 2026-06-29 (UTC).

## ⚠ Two architecture-specific findings (qwen3moe on this SYCL build)

1. **`llama-batched-bench` segfaults on this arch.** Every cell of both the concurrency and context
   Pareto sweeps crashed with `rc=139` (core dump), *before printing a single line*, even at tiny
   `ctx=2304` and with minimal flags (no `-fa`, no q8_0 KV, no `-ub`). The **same model serves fine under
   `llama-server`**, so this is a `batched-bench`-specific crash on `qwen3moe`, not a model fault.
   → the offline-Pareto path used for the other models is unavailable; **Paretos here are measured live
   through the server instead.**
2. **The server hangs at `c=262144`.** At the 35B family's games context (`-np 6 -c 262144`) the server
   loaded but produced **zero decode tokens in 40 min** (then timed out). At **`c=131072` it works
   perfectly (82 t/s single-stream).** So Quest's usable **context ceiling on this build is 131072**, half
   the 35B family's 262144 — a real limitation of this arch/build combo at high context.

## 1. Concurrency Pareto — live `-np 32 -c 131072` (real concurrent requests, :8092)

Measured through the live server (batched-bench unavailable). **Quest is the fastest model in the
campaign** — `qwen3moe`'s lighter per-token cost batches harder than the 35B-A3B family.

| class | prompt_n | agents | aggregate decode t/s | per-agent t/s |
|---|---:|---:|---:|---:|
| tool | 124 | 1  | 66.46  | 84.59 |
| tool | 124 | 8  | 164.67 | 22.03 |
| tool | 124 | 16 | 222.96 | 14.78 |
| **tool** | 124 | **32** | **335.46** | 11.25 |
| structured | 439 | 32 | 211.17 | 7.51 |
| novel | 774 | 32 | 148.20 | 5.38 |

At 32 tool-agents Quest sustains **335 t/s aggregate** (vs ~224 for the qwen3_5_moe models) — a **5.0×**
gain over its own single-agent 66 t/s, and the per-agent rate stays higher (11.3 vs ~7.9) because the
arch is cheaper per token.

## 2. Context-depth Pareto — live (single-agent depth sweep + depth-at-concurrency)

Measured live (batched-bench unavailable), capped at Quest's safe `c=131072` ceiling.

**Single agent (`-np 1 -c 131072`), 256-tok generation** — the depth-decay curve:

| context (actual prompt tok) | prefill t/s | decode t/s |
|---:|---:|---:|
| 805 | 655.8 | 73.2 |
| 14,563 | 917.0 | 19.5 |
| 61,341 | 283.0 | 5.6 |
| 129,325 | 139.0 | 2.8 |
| > 131,072 | — | **ctx overflow (ceiling)** |

**8 agents (`-np 8 -c 131072`), aggregate vs per-agent depth:**

| per-agent depth (prompt tok) | aggregate decode t/s | per-agent t/s |
|---:|---:|---:|
| 805 | 100.2 | 15.4 |
| 6,963 | 22.4 | 4.0 |
| 14,563 | 9.4 | 2.0 |
| 8 × ~28k > 131,072 | **ctx overflow (ceiling)** | — |

**Read:** Quest's decode **collapses with context depth** — single-agent ~73 → 2.8 t/s from ~0.8k → 129k
tokens (a ~26× fall), and at 8 agents the fleet is throttled to single digits by depth ~8k. This is the
inverse of the `qwen3_5_moe` family: that arch's gated-delta-net holds context to 262144 at steadier
rates, whereas `qwen3moe` is **cheap-per-token at shallow context (hence the 335 t/s concurrency win) but
expensive at depth**, and is hard-capped at `c=131072` on this build. Net: Quest is the better choice for
*wide, shallow* agent fleets; the 35B family for *deep* single-agent context.

## 3. Teamwork build games (frogger + maze)

Canonical `agentic-arcade/teamwork` harness on `:8092`, **team 6 / merge-top 2 / 15-min**, thinking
requested OFF. Because Quest hangs at `c=262144`, games were served at `c=131072` (frogger at `-np 4` =
32768 ctx/slot so each whole-game build fits the slot).

| game | result | seed→final bytes | jsdom valid | notes |
|---|---|---|:--:|---|
| **maze** | built (1 round, merged winner) | 12,173 → 20,597 | ✅ | only 2/6 workers valid |
| **frogger** | **FAILED — no parseable build** | — | — | runaway reasoning, empty `content` (see below) |

### Frogger failure — Quest ignores `enable_thinking:false`

Across **two** full attempts the frogger seed returned **0 bytes**. Diagnosed via the server: the seed
generated **32,624 tokens** (hit the 32768 cap, `truncated=1`) over **30.5 minutes** (decode collapses
from 58→17.8 t/s as the 32k-token context grows), yet the response `content` was empty. A direct probe
(frogger prompt, `max_tokens=1200`, `enable_thinking:false`) confirmed the cause: **`content` length 0,
`reasoning_content` length 4322** ("We are going to create a complete Frogger game…"). QUEST-30B-RL is a
reasoning model that **ignores `enable_thinking:false`** and emits everything into the reasoning channel;
on the frogger prompt its reasoning never terminates within the harness's 32k-token budget, so no game
ever reaches `content`. The maze happened to finish reasoning and emit a game; frogger reproducibly does
not. Under the standard teamwork protocol (thinking-off, 32768 cap), **Quest cannot produce a Frogger.**

## 4. Code-quality eval (Claude Opus 4.8 judge, /50 rubric)

| game | chars | **/50** | Comp | Corr | Struct | Robust | Polish |
|---|---:|---:|:--:|:--:|:--:|:--:|:--:|
| **Maze** | 20,597 | **29** | 9 | 4 | 7 | 5 | 4 |
| **Frogger** | — | **n/a** | — | — | — | — | — |

### Maze — 29/50 (best engine of the four mazes, broken by UI wiring)

The underlying game engine is the **most correct of any maze in the campaign**: collisions use real radii
(`player.radius`/`robot.radius`/`bullet.radius` all defined — no NaN bug), consistent pixel units (no
tile/pixel confusion), **five robot archetypes** (basic/patrol/sniper/fast/tank) with distinct behavior, a
sniper with **line-of-sight** checks and robot bullets, a static maze + door→wave progression, Web Audio
SFX, and `localStorage` high score. `getContext('2d')` correct; validates clean (7/7 assertions).

**But two presentation bugs make it unplayable as shipped:**

- **The start overlay never hides.** The DOM `#startScreen` overlay (`display:flex`, full-screen) is
  **never manipulated in JS** — and `init()` → `resetGame()` forces `gameState='PLAYING'` on `window.onload`,
  so the game auto-starts *underneath* the overlay. The Space handler only acts in `START`/`GAME_OVER`
  states, so it can't dismiss the overlay (state is already `PLAYING`). You see the start screen forever
  while the game runs invisibly behind it.
- **Invisible walls.** `drawMaze()` calls `ctx.fillRect()` for walls with **no `fillStyle` set** → default
  black on the black canvas → walls don't render even if the overlay were removed.

So the cleanest game *engine* of the four mazes, sunk by a UI/state-wiring bug and a missing fill color
(Corr 4: logic sound but the artifact can't be played; Polish 4: plain-circle entities + invisible walls).

### Campaign-wide maze pattern (all 4 models)

Every model's maze is broken by a *different* mechanism, but all pass the validator: Ornith (entity
`radius` undefined → can't shoot), NEX2 (radius undefined → invisible + can't shoot), SIQ (tile/pixel unit
confusion → frozen player), Quest (start overlay never hides + black-on-black walls). The teamwork harness
guarantees *runnable* and *static-gate-passing*, never *playable* — the maze's continuous-coordinate
collision + multi-system UI is where every model trips. Frogger (grid-locked, simpler) fares better:
SIQ 42, NEX2 37, Ornith 33, Quest n/a (runaway reasoning).

## Reproduce
```bash
# live concurrency + games (games at the safe context):
SKIP_BENCH=0 GAMES_NP=4 GAMES_CTX=131072 bash bench/run_live_evals.sh \
  /home/frosty40/quest-turbo/artifacts/quest-30b-rl-Q5_K_M.gguf quest-30b-rl quest 8092
# context-depth frontier (live, <=131072):
bash bench/run_quest_context.sh
# NOTE: llama-batched-bench segfaults on qwen3moe here — Paretos are server-measured.
```