Repository navigation
Tell the memory condenser how many bytes its summary may take - #48
Conversation
Memory condensing kept aborting with `not-smaller`: on most runs the summary model rewrote the condensed history at greater length than the material it replaced, so the rebuilt file came out 20-40% larger than the original and the size check (correctly) discarded it. Files that most needed shrinking never shrank. The prompt never said how much room the summary had. Its only size hint was "Target <= 1500 words", which is unrelated to the file being condensed: for a file whose verbatim regions already fill most of it, 1500 words is more than the whole budget, and a model aiming for the hint grows the file. Compute the room instead and state it. The rewrite should come out at no more than 80% of the original; the header, pinned facts and the newest sections kept verbatim are a known size, so the condensed section gets whatever is left, and the prompt gives that number as a hard ceiling. The existing not-smaller check stays as the backstop for a model that ignores the limit.
🚫 This PR is missing its before/after evidenceEvery pull request here has to show its work. Screenshots or a short screen recording, before the change and after it.
How to fix it: edit the description, keep the A bug fix with no visible surface still needs it: show the failing behaviour, then the same steps passing. A terminal recording is fine. Genuinely nothing to show — a CI tweak, a typo, a dependency bump? A maintainer can apply the |
…e target is out of reach The condense prompt states how many bytes the summary may take: what is left of 80% of the file once the regions kept verbatim are counted. On files whose pinned facts and newest sections already take more than 80% of the file, that came to nothing, and the prompt told the model it had 0 bytes. A model that obeyed wrote an empty summary, which fails to parse, so the condense failed without setting the not-smaller backoff and was paid for again on every scan, indefinitely. The rewrite those files could still take (anything under 95% of the old size, the size check's own limit) was never asked for. When the 80% target is out of reach, state the room the size check allows instead, less a fixed allowance for pinned facts the summary may hoist (they are not known until it returns). When even that leaves no room, no summary could be accepted: skip the call and set the same backoff a not-smaller result sets, so the autonomous scan stops paying for it until the file grows.
|
Review round 1 addressed in 700e609 (refactor: name the 95% acceptance ratio) and 83cde92 (fix). When the verbatim regions leave no room for the 80% target, the stated limit falls back to the room the size check allows, less 512 bytes for hoisted facts. When even that is 0, no summary is requested and the not-smaller backoff is set. Two new tests, both RED first. 6 of 6 mutants killed (no allowance, no skip, no backoff, no fallback, always fallback, an off-by-600 accepted room). Suite 1762 of 1764, 0 fail, 2 skipped; typecheck clean. |
1 participant
What & why
Memory condensing kept aborting with
not-smaller: the summary model rewrote the condensed history at greater length than the material it replaced, so the rebuilt file came out larger than the original and the size check discarded it. The files that most needed shrinking never shrank.The prompt never said how much room the summary had. Its only size hint was "Target <= 1500 words", which has nothing to do with the file being condensed. This PR computes the room and states it. The rewrite should come out at no more than 80% of the original. The header, the pinned facts and the newest sections kept verbatim are a known size, so the condensed section gets whatever is left. The prompt gives that number, in bytes, as a hard ceiling (a new input
(D) SIZE LIMIT).The existing not-smaller check is unchanged and remains the backstop for a model that ignores the limit. The keep-set byte budget and the model are untouched.
Type of change
Evidence
This change has no UI. The evidence is the new tests going red, then green.
Before
New tests run against the unchanged
reflect.ts:After
Full suite (
npm run test:focused): 1760 of 1762 pass, 0 fail, 2 skipped. The baseline on the base commit was 1756 of 1759, with 2 skipped and one pre-existing failure intest/proc-kill.test.cjs, which passed on this run.Mutation check: each of these changes to
reflect.tsturns at least one new test red. All 5 are caught:How I tested it
npm run typecheck: 0 errors.npm run test:focused: the result above.npm run build: succeeds.