Files

T

retoor af080fe68e Strict goal verification, approval hardening, retrieval eval, work limits, sandbox caps (1.38.0)

- Approval: re-prompt unknown answers (max 3), shell-only affirmative
  guidance recovery; destructive actions stay strict
- GoalVerifier subagent with strict JSON verdicts, bounded follow-up
  rounds, nonzero exit plus open turn on unverified one-shots
- Retrieval eval (Hit@K/MRR/nDCG/Context Precision), FTS cascade with
  title weighting, query/read event logging, --eval-retrieval CLI
- Supervisor caps (8 parallel, 64 records) and scheduler hardening
  (4 fires/tick, per-schedule lease, stated misfire policy)
- Sandbox box resource trio: 2g/2.0/256 at create, best-effort
  update for existing boxes, rm -f recovery pointer
- Research archive: 12 subjects, 667 sources, 27 conclusions;
  suites 979 + 16 green

2026-10-18 12:13:24 +02:00

2.6 KiB

Raw Blame History

Compaction

Metadata

Field	Value
Institute	Molodetz Institute — Research & Retrieval Division
Subject	prompt-context-scaling
Document type	Source Dossier
Tier	1
Source title	Compaction
Source URL	https://developers.openai.com/api/docs/guides/compaction
Source publisher / author	OpenAI
Source type	vendor docs
Source date (published)	Unknown — not stated (living documentation page)
Date researched	2026-10-18
Researched by	tai (agent), model: Muse Spark, on behalf of retoor
Research method	both
Confidence	High
Status	Active

Summary

OpenAI's server-side compaction guide confirms threshold-triggered summarization as a first-class platform feature: past a configured token threshold the server emits a compaction item carrying prior state forward, and clients drop everything before it. The stated purpose is balancing quality, cost, and latency as conversations grow.

Key findings

"Compaction helps you balance quality, cost, and latency as conversations grow."
"When the rendered token count crosses the configured threshold, the server runs server-side compaction", emitting a compaction item in-stream and pruning context before continuing inference.
"The returned compaction item carries forward key prior state and reasoning into the next run using fewer tokens."
"You can drop items that came before the most recent compaction item to keep requests smaller and reduce long-tail latency."
The example threshold in the guide is 200,000 tokens.

Pros / strengths

Independent vendor confirmation that threshold-triggered compaction is the standard mechanism, with the same trigger/prune/carry shape as tai's client-side version.
Makes the cost/latency motive explicit: compaction is as much about bills and tail latency as about fitting the window.

Cons / limitations / caveats

Server-side and opaque ("not intended to be human-interpretable"); tai's summary is client-side and inspectable, which is better for audit but costs a visible extra model call.
No guidance on what to preserve versus discard; the compaction-item content policy is OpenAI-internal.

Relevance to tai

Validates tai's compact_messages trigger design (ratio of a cap, summarize middle, keep recent) as the industry shape. tai's 32k cap with 0.8 trigger is far smaller than the guide's 200k example, which is correct for its weaker backends: the RULER dossier shows claimed context far exceeds usable context on small models.

Changelog

Date	Change
2026-10-18	Initial dossier created.

2.6 KiB Raw Blame History