Skip to content

Measure the remaining compaction defaults instead of choosing them #164

Description

@yuanhao

Fifth of the trustworthiness items. Generalises what #158 did for one constant.

Why

examples/headroom_sweep.rs settled compact_headroom_turns in about twenty minutes, for free, deterministically — by driving the real effective_target_ratio and compact_messages offline rather than reimplementing them or guessing.

It also disproved a confident claim I had written on #150: that Some(30) was "the aggression that makes compaction destructive". It is a defensible trade — half to a third as many prefix-cache invalidations for ~30% less retention.

The same instrument applies to every other unmeasured constant, and none of them have been measured:

constant current never measured
MIN_HEADROOM_RATIO 0.15 the post-compaction cliff — see #150
keep_recent 10 vs. retention and orphan risk
keep_first 2 whether the opening turn survives usefully
compact_target_ratio 0.7 interacts with everything above
tool_output_max_lines 200 now that truncation is retrievable, is 200 still right?
LlmCompaction::trigger_ratio 0.6 how much wall-clock headroom it actually buys

Why offline first

Two of the four things that matter — compaction frequency and retention — are pure functions of the compaction code. They sweep densely for free and deterministically, with no provider and no nondeterministic model. Only cache hit rate and splice rate need live runs, and those are worth spending on a shortlist rather than a grid.

That ordering is the whole trick, and it is what made the headroom sweep cheap.

Acceptance

  • headroom_sweep generalised to sweep the constants above, or a sibling example per axis.
  • Each shipped default is either confirmed by data or changed, with the measurement recorded next to it in the docs.
  • tool_output_max_lines reconsidered specifically — it predates retrievable tool output, so the cost of truncating is no longer what it was when 200 was chosen.

Caveat

Defaults changes affect every user, so a measurement that shortlists is not the same as a measurement that decides. Anything that changes behaviour should also get a live confirmation before shipping (see #161).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions