category: infrastructure · status: draft · updated: 2026-11-02

τ=0.9 structured compaction: how long rollouts survive their own logs

A cyber agent dies two ways: it gives up, or it drowns. Drowning is the boring one — 200 tool calls into a CTF-style rollout, the context is 90% nmap output and repeated curl responses, and the model can no longer see the task it started. The naive fix (truncate old turns) amputates the wrong thing: it keeps recent junk and discards the mission. The CyberFactory paper (arXiv:2608.23181, v3 HTML) validated a better mechanism, and its ablation says compaction was the single biggest lever in the whole recipe. Our rollout server copies it.

The mechanism

Watch one number: context usage. When it crosses τ = 0.9 (90% of the window), pause the agent and make one extra model call: rewrite everything so far into a continuation state. The rewrite preserves, in fixed sections:

1. Verified evidence — facts established by execution, not guesswork ("payload reflected unescaped in /search?q=").
2. Failed attempts — what was tried and the exact reason it failed ("svg/onload blocked by sanitizer rule X").
3. Open hypotheses — the ranked guesses still worth testing.
4. Artifacts & build status — files written, containers up, which build is patched.
5. Pending actions — the queue the agent was working through.

Everything else — raw HTTP responses, repeated listings, search dumps — is discarded. The agent then resumes with the same task, tools, and oracle, primed only with the continuation state. Applied identically at synthesis time (teacher generating training data) and at inference.

Why 0.9 and not something else? The paper ablated it. At τ = 0.95 there is no room left for the compaction call itself — the rewrite is generated into the window it's trying to shrink, and it overflows. At τ = 0.8 you compact too often: each rewrite is lossy, and running it with a fifth of the window still empty throws away detail you had room to keep. 0.9 leaves ~25K tokens of a 256K window — enough for the summarization pass, not so much that you wasted capacity.

The numbers

CyberGym PoC reproduction, 1-hour budget, Pass@1, same scaffold (v3):

Context strategy	Pass@1
Structured compaction, τ=0.9	58.1
Full history, no compaction	52.1
Truncation (drop oldest)	45.6

Truncation is worse than doing nothing smart — it actively destroys the task while preserving log volume. On the hardest slice (tasks with >40 tool calls) compaction added +8.5 Pass@1 and cut context-exhaustion failures by 11.7 points. For comparison, the entire "skill guidance on the teacher" trick was worth ~3 points on the end model. Compaction is cheap and it's the biggest number on the board.

Worked example

Our fleet, not theirs. A rollout against a procedural XSS instance in the vulhub farm, 256K window:

• 0–60K tokens: recon — crawling, nmap, reading source. Useful facts: maybe 2K tokens of it.
• 60–180K: exploitation attempts. Six payloads, six failures, each with a 4KB response body explaining why. The reasons are 300 tokens; the bodies are 24K.
• 230K (0.9 × 256K): trigger. The compaction call rewrites 230K into ~5K: reflected parameter found; CSP allows inline; sanitizer strips onerror= and <script>; hypothesis — details/ontoggle + autofocus bypass untested; artifacts: req.py harness in /tmp; pending: fuzz sanitizer with DOMPurify cheat-sheet subset.
• 230K → 30K effective: the agent continues with 226K tokens of runway. It solves it at 190K.

Under truncation, the same run forgets the CSP finding at turn 40 and re-derives it three times before the clock runs out. Under full history, attention degrades and per-call latency creeps up as the model re-reads its own curl output every step.

What it means for our stack

• It lives in the rollout server, not the model. Compaction is an orchestrator-level state machine: watch usage, fire the rewrite prompt, swap the context, resume. Teacher synthesis, SFT'd-model inference, and RL rollouts all pass through the same server, so they all inherit it for free — and it's model-agnostic across teacher swaps.
• Continuation states are training data. Compaction events serialize into the published verified trajectories. The SFT'd model doesn't just survive compaction — it learns to read a continuation state, which is exactly the skill a 256K-window copilot needs when the human pastes it into hour three of an engagement.
• It shrinks the training bill. Once compaction caps trajectory length, packing at 131K tokens (CyberFactory's setting, needing 256 GPUs) is dead weight. Our rebuild note in the dossier already plans 32–64K packing for the rented-GPU SFT — compaction is what makes that legitimate rather than lossy.
• It pairs with MTP decoding. Long-context rollouts are where acceptance-rate decay bites speculative decoding (public reports show acceptance falling toward 35% at very long context). Compaction keeps contexts short, which keeps both acceptance and the 150 tok/s goal alive. See [[mtp-speculative-decoding]].

Why it matters here

Our moat is verified trajectories from long-horizon rollouts; context exhaustion is the main way those rollouts die before verification. τ=0.9 compaction is a one-prompt, no-training fix with the best cost/benefit ratio in the CyberFactory paper — we adopt it as infrastructure on day one and publish the continuation-state format as part of the trajectory schema.

See also

[[mtp-speculative-decoding]] · [[small-model-economics]] · [[cyberfactory-openaegis]] · [[bugcrowd-rl-environments]]