pi-tuck 1.0.10 → 1.0.11

package/CHANGELOG.md

@@ -3,7 +3,52 @@
 All notable changes to pi-tuck. The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and versions follow
 [Semantic Versioning](https://semver.org/).
 
-## [1.0.10] - 2026-11-01
+## [1.0.11] - 2026-11-06
+
+### Fixed
+
+- A prompt that fits the room is no longer dropped when the previous summary alone fills it (the 1.0.10 known issue): a cut can now shrink a
+  summary that sits alone, when the cut is due. A prompt that fits beside the summary is sent as it stands.
+- A fresh tool result is clipped in more of the cases where the request would otherwise be refused. The clip's budget is now counted in the
+  same units as the request and allows for what the smallest cut keeps, so a round that fits only when clipped no longer ends the run. This
+  is most of the refusals the settings stress test found.
+- One wrong usage report no longer refuses later prompts: a reply that reports more than the model's window is not learned from.
+- When a provider refuses a request as over its window, pi-tuck now says so in a notice, where the turn could read as a hang.
+- Every refusal says why.
+
+### Added
+
+- A settings stress test (`test/stress`, run with `STRESS=1`): real Pi with a scripted fake model, across 272 cells of window, reserve,
+  keep-recent, output cap, setup size and usage reports. CI runs it on Pi 1.2.0 and the newest Pi. Rejection wordings and usage reports in
+  it are scripted: no hosted provider API is tested.
+
+### Known issues
+
+- Same settings stress test, this build: 4 of 272 cells report a failure (90 on 1.0.10), none stuck and none losing work. The next prompt runs.
+  - A fresh assistant message larger than the free room is refused: nothing can clip it yet. A short next prompt recovers. In an unattended
+    `pi -p` run, a refusal ends the run.
+  - With a setup near the band, cuts can come too often: with Pi's defaults, a 40k setup at a 65,536 window made 25 cuts in 60 tool rounds, each
+    freeing little. It costs extra work, not a task. One sampled cell at a 167,739 window also trips this count. The fix is planned for the next
+    patch.
+  - A wrong usage report at or under the window can still raise the estimate for a while: in the stress cell for it, a 6,000-token prompt is
+    refused in a 28,672-token room.
+- If a provider keeps rejecting requests in a wording Pi does not class as a context overflow, or with a bare HTTP 413, pi-tuck does not recover
+  on its own: the provider's error reaches you, the session stays intact, and every prompt can fail until the request shrinks. Try `/compact`.
+
+### Release gates
+
+- **Shipped without a live gate.** Its replay matches 1.0.10, so the paired live test has nothing to measure on recorded sessions; the fixes
+  act only where a request would otherwise be refused. For that reason replay cannot show them working either, and they are shown by the stress
+  test alone, on a scripted model.
+- Passed: tests; replay of the exact code on 29 recordings against 1.0.10 (13,946 requests, 0 differ, 0 dead tasks, the same 9 clips, all read
+  back); the stress test (no cell stuck, none losing work; no cell has a failure 1.0.10 does not. One cell makes 8 cuts where 1.0.10 made 6,
+  because its prompts now run instead of being refused).
+- An earlier 1.0.11 build ran Pi's defaults on chain t06 with no lost task
+  ([`benchmark/RESULTS-DEFAULTS-1010.md`](benchmark/RESULTS-DEFAULTS-1010.md)). One of its tasks, task 21, ran to the 30-minute wall cap on a
+  first request the local server never answered, and recorded no token. It is read as a server stall. It was counted as passing under the bar's
+  definition; the registered counter alone would count one dead task.
+
+## [1.0.10] - 2026-11-05
 
 ### Fixed
 
@@ -28,8 +73,9 @@ All notable changes to pi-tuck. The format follows [Keep a Changelog](https://ke
 
 - Passed: tests; replay of the exact build on 29 recordings (no dead task, no refused request, every oversize result clipped and read
   back); the Pi-defaults rerun on chain t06, which lost 28 of 30 tasks on 1.0.8: 0 dead tasks and 0 stuck sessions
-  ([`benchmark/RESULTS-DEFAULTS-1010.md`](benchmark/RESULTS-DEFAULTS-1010.md)). Two of its tasks sat on a first request the local server never
-  answered, ran to the 30-minute cap and recorded no token; they are read as server stalls, and a strict no-token count would not meet the bar.
+  ([`benchmark/RESULTS-DEFAULTS-1010.md`](benchmark/RESULTS-DEFAULTS-1010.md)). It ran on a slow local server: 27 of 30 tasks hit the 30-minute
+  wall cap, and 2 of them sat on a first request the server never answered and recorded no token. Those 2 are read as server stalls, and a strict
+  no-token count would not meet the bar.
   One task was refused mid-run: its round carried 9,020 tokens of reasoning, so the next request was about 17,801 against the 16,384-token room.
 - **Failed as registered:** the paired 32k gate against 1.0.9 (chains t01 and t02, 60 tasks). No task was lost in either arm, but 1.0.10
   resolved 49 tasks against 50, so "resolved no lower" failed by one task (−1.7 points, one-sided 95% lower bound −8.3;

package/README.md

@@ -1,6 +1,6 @@
 # pi-tuck
 
-**Compaction for [Pi](https://pi.dev) with no model call, and a history the agent can search by keyword, and on Apple silicon by meaning, all on your machine.** In our live run, a cut took a median 0.09 s. It costs no tokens. The same session always gives the same summary. And nothing is lost: the agent can read back anything earlier, word for word, and on Apple silicon it can find it by meaning.
+**Compaction for [Pi](https://pi.dev) with no model call, and a history the agent can search by keyword, and on Apple silicon by meaning, all on your machine.** In our 128k live run, a cut took a median 0.08 s (pi-tuck 1.0.1). It costs no tokens. The same session always gives the same summary. And nothing is lost: the agent can read back anything earlier, word for word, and on Apple silicon it can find it by meaning.
 
 ```sh
 pi install npm:pi-tuck
@@ -8,22 +8,29 @@ pi install npm:pi-tuck
 
 ## pi-tuck against Pi's built-in compaction
 
-Pi's built-in compaction asks a model to write a summary. pi-tuck builds the summary from the session itself. The two time and context rows compare pi-tuck 1.0.1 with Pi 1.4.0's built-in compaction, where a local model writes the summary. Each measured result in this README names the pi-tuck build or version it was measured on; the release you install may be newer.
+Pi's built-in compaction asks a model to write a summary. pi-tuck builds the summary from the session itself. The time, context and task rows compare pi-tuck 1.0.1 with Pi 1.4.0's built-in compaction, where a local model writes the summary. Each measured result in this README names the pi-tuck build or version it was measured on; the release you install may be newer.
 
 | | Pi's built-in (local model writes the summary) | pi-tuck |
 |---|---|---|
 | Model call per cut | One, to a model you pay for or wait on | None |
-| Time per cut | **269 s** (median) | **0.09 s** (median) |
-| Context carried after a cut | 29,200 tokens | 27,800 tokens (about the same) |
+| Time per cut | **235 s** (median) | **0.08 s** (median; an upper bound, see below) |
+| Context carried after a cut | 27,750 tokens | 26,790 tokens (about the same) |
+| Facts cut away, asked back at 128k (mechanical probes) | Answered from the summary alone, with no recall tool | Answered from the summary and pi-tuck's recall tools, cuts 1 to 4 only. Claim line below the table |
+| Tasks resolved at 128k (300 SWE-bench Verified tasks per arm, pi-tuck 1.0.1) | 251 of 300 | 258 of 300. The registered claim is only "no loss larger than 0.4 points"; chain s09 matters, see below |
 | Same session, same summary | Not guaranteed, since a model writes it | Yes |
 | Can the agent get dropped detail back | No recall tool in Pi 1.4.0. The full history stays in the session file, but the agent has no tool made to search it | Yes. `tuck_recall` reads any original exactly |
 | Search history by meaning | No | Yes, with `tuck_search`, on macOS with Apple silicon. It runs locally on your Mac's GPU, and no text leaves your machine. Elsewhere there is no `tuck_search`, and `tuck_recall` searches by keyword |
 | Can the summary invent history | It can, since a model writes it | No, it holds only recorded text |
 | What the summary leaves out | Whatever the model dropped | Tool output only; the agent reads it back exactly |
-| Billed input at the default 60% cut point (simulated) | Not measured | 10–18% less than pi-tuck cutting at the full room. This is not a comparison with the built-in |
 | Tasks resolved at a 32k window (150 SWE-bench Verified tasks, one model, pi-tuck 1.0.5) | 94 of 150 | 120 of 150 (+17.3 points, 95% lower bound +10.7). Limits below the table |
 
-The time and context rows are live runs with a 131k window: 27 cuts per arm over 5 chains, interim. The 32k row is one model, one window and five chains. Observation masking, a third approach, resolved 117 of the same 150 tasks (pi-tuck +2.0 points, lower bound −2.7: no difference shown). In the 32k run only pi-tuck was held to the 16,384-token room: Pi's built-in compaction sent a request over it in 97 of 150 tasks. Every number comes from a file in this repository. Conditions, sample sizes and the full limits are in [Benchmarks](#benchmarks).
+The time and context rows are from the 128k live run: 10 chains of 30 tasks, pi-tuck 1.0.1, medians over 46 pi-tuck cuts and 48 cuts by Pi's compaction. pi-tuck's cut time is an upper bound, read from the session file ([`benchmark/DEVIATIONS.md`](benchmark/DEVIATIONS.md)).
+
+The retention row is a paired replay on mechanical probes only: files changed, test-runner summary, required tag, error class and the session's result-line rule. No probe judged how well an agent reasons. The claim line, as [`benchmark/RESULTS-MAIN.md`](benchmark/RESULTS-MAIN.md) words it: **pi-tuck, answering with its recall tools, retains probed facts at a rate not more than 3 points below that of "Pi's compaction prompts on mac-studio/main:xhigh" (20 recordings) or of "Pi's compaction prompts on GPT-6.1 Terra" (19 of 20 recordings, s09-A missing), each answering from its summary alone, on these probes.** This is not summary against summary: it compares pi-tuck's summary together with its recall tools against Pi's compaction without them, and the run has no pi-tuck arm without its recall tools. It says nothing about any other compactor, model or window.
+
+In the replay behind pi-tuck's retention numbers, 52 of its 95 answer sets ended in an abort (0 of 95 for Pi's compaction prompts on the same local model), so those numbers cover cuts 1 to 4 only and no retention claim is made past cut 4; see [`benchmark/RESULTS-MAIN.md`](benchmark/RESULTS-MAIN.md).
+
+The 32k row is one model, one window and five chains. Observation masking, a third approach, resolved 117 of the same 150 tasks (pi-tuck +2.0 points, lower bound −2.7: no difference shown). In the 32k run only pi-tuck was held to the 16,384-token room: Pi's built-in compaction sent a request over it in 97 of 150 tasks. Every number comes from a file in this repository. Conditions, sample sizes and the full limits are in [Benchmarks](#benchmarks).
 
 ## Ask your history
 
@@ -89,14 +96,14 @@ On Apple silicon, both tools cost about 1,050 tokens of tool description per req
 
 ## What is proven, and what is not
 
-**Measured so far.** In the live run at a 131k window, a pi-tuck cut took a median 0.09 s, where Pi's built-in compaction with a local model writing the summary took a median 269 s. A cut calls no model, so it costs no tokens. After a cut, pi-tuck carried about as many tokens as the built-in did, not fewer. In simulation, cutting at 60% of the room instead of 100% saved billed input for pi-tuck itself, and answers held in replay. At a 32k window, in one suite of 150 SWE-bench Verified tasks with one model, pi-tuck 1.0.5 resolved 120 tasks and Pi's built-in compaction 94 (+17.3 points, 95% lower bound +10.7). Observation masking resolved 117 (pi-tuck +2.0 points, lower bound −2.7: no difference shown). The limits of that result are in [Benchmarks](#benchmarks).
+**Measured so far.** In the 128k live run (pi-tuck 1.0.1), a pi-tuck cut took a median 0.08 s, where Pi's compaction with a local model writing the summary took a median 235 s. A cut calls no model, so it costs no tokens. After a cut, both carried about the same context. On mechanical probes about facts cut away, pi-tuck with its recall tools was not more than 3 points below Pi's compaction prompts on mac-studio/main:xhigh, or below Pi's compaction prompts on GPT-6.1 Terra, each answering from its summary alone (claim line above; cuts 1 to 4 only). Over 300 tasks per arm, pi-tuck resolved 258 and Pi's compaction 251; the registered claim is only that pi-tuck lost no more than 0.4 points. In replay, answers held when pi-tuck cut at 60% of the room instead of 100%. At a 32k window, in one suite of 150 SWE-bench Verified tasks with one model, pi-tuck 1.0.5 resolved 120 tasks and Pi's built-in compaction 94 (+17.3 points, 95% lower bound +10.7). Observation masking resolved 117 (pi-tuck +2.0 points, lower bound −2.7: no difference shown). The limits of each result are in [Benchmarks](#benchmarks).
 
-**Not claimed.** This README does not say that pi-tuck is as good as, or better than, Pi's built-in compaction at a 128k window or in any other setting than the one above. The tests were pre-registered before any result came in. The plans, and every result, including those that did not favour pi-tuck, are in [`benchmark/`](benchmark).
+**Not claimed.** This README does not say that pi-tuck is as good as or better than any compactor, model, window or kind of task other than those named, and it never calls it "the best LLM compactor". The retention tests compare pi-tuck with its recall tools against Pi's compaction without them. The tests were pre-registered before any result came in. The plans, and every result, including those that did not favour pi-tuck, are in [`benchmark/`](benchmark).
 
 The pre-registered plan has three parts:
 
 1. **A live run** at a 128k window on a local model, with pi-tuck 1.0.1. Ten chains of 30 SWE-bench Verified tasks per arm, with Pi's built-in compaction in one arm and pi-tuck in the other. Official grading.
-2. **A paired replay with probe questions.** The same cuts, made by pi-tuck and by Pi's summarize prompts, then questions about facts that fell before the cut. Pre-registered rule: the claim holds only if pi-tuck is no more than 3 points worse than the better compactor, with a 95% bound. The comparators are named in [`benchmark/PINS.md`](benchmark/PINS.md).
+2. **A paired replay with probe questions.** The same cuts, made by pi-tuck and by Pi's summarize prompts, then questions about facts that fell before the cut. Pre-registered rule: the claim holds only if pi-tuck is no more than 3 points worse than the better compactor, with a one-sided 95% bound. The comparators are named in [`benchmark/PINS.md`](benchmark/PINS.md) and above.
 3. **A 32k suite**, where tasks are bigger than the room, so cuts must summarise work in progress. Its result is the 32k row above.
 
 The plan: [`benchmark/PREREG.md`](benchmark/PREREG.md), [`benchmark/PREREG-32K.md`](benchmark/PREREG-32K.md), [`benchmark/PREREG-TERRA.md`](benchmark/PREREG-TERRA.md), and every change after the freeze in [`benchmark/DEVIATIONS.md`](benchmark/DEVIATIONS.md).
@@ -104,22 +111,29 @@ The plan: [`benchmark/PREREG.md`](benchmark/PREREG.md), [`benchmark/PREREG-32K.m
 Known limits today:
 
 - pi-tuck's summary does not explain why things happened. It holds the words that were said, not a model's reading of them. The agent must look things up. Each look-up costs a tool call.
-- Small windows: an upstream that spends far more context on tool schemas than others (some OpenRouter upstreams do) can leave a small input room too little space, and pi-tuck then refuses to cut rather than overflow. This is what made 1.0.1 refuse at a 32k window with Pi's default 16,384 reserve. Since 1.0.4 the notice says when the provider is counting far above pi-tuck's estimate. In 1.0.4, after an oversize tool result or a "Nothing to compact" error from Pi, a session could keep refusing later prompts. 1.0.5 fixes both. Since 1.0.8, a fresh tool result too large for the room is clipped (its head and tail, with a `tuck_recall` locator to the rest) instead of refusing the run. Pin a different upstream, lower the reserve, or use a larger window; see [Small windows](#small-windows).
-- Small window, after a stopped run (1.0.8 and 1.0.9): Pi's default `compaction.keepRecentTokens` (20,000) can exceed pi-tuck's input room, which is the window less the larger of `compaction.reserveTokens` and the model's maximum output. At a 32k window with the default 16,384 reserve the room is 16,384. After a run that is stopped (Esc, or a time limit) with the context above the room, every later prompt can be refused with "The request needs a cut and Pi has none to make (Nothing to compact (session too small))", and the session stays stuck. In one check at these defaults (pi-tuck 1.0.8, 32k window, one session of 30 tasks, one local model), 28 tasks were lost, tasks 3 to 30; it shows that the failure occurs, not how often ([`benchmark/RESULTS-DEFAULTS.md`](benchmark/RESULTS-DEFAULTS.md)). Workaround until 1.0.10: set `"compaction": { "keepRecentTokens": N }` in Pi's `settings.json`, with N well below the room; the 32k benchmark used 3,333 (see [Small windows](#small-windows)). Windows of 128k and up are not affected at the defaults, since the room there is far above 20,000 tokens. 1.0.10 is planned to fix this: pi-tuck will make prompt-time cuts itself.
+- Small windows: an upstream that spends far more context on tool schemas than others (some OpenRouter upstreams do) can leave a small input room too little space. pi-tuck then refuses to cut rather than overflow. This made 1.0.1 refuse at a 32k window with Pi's default 16,384 reserve. Version 1.0.4 added a notice that says when the provider counts far above pi-tuck's estimate. In 1.0.4, after an oversize tool result or a "Nothing to compact" error from Pi, a session could keep refusing later prompts; 1.0.5 fixed both. Version 1.0.8 clips a fresh tool result that is too large for the room (its head and tail, with a `tuck_recall` locator to the rest) instead of refusing the run. If a small window still refuses, pin a different upstream, lower the reserve, or use a larger window; see [Small windows](#small-windows).
+- Small window, after a stopped run (1.0.8 and 1.0.9 only; fixed in 1.0.10): Pi's default `compaction.keepRecentTokens` (20,000) can exceed pi-tuck's input room, which is the window less the larger of `compaction.reserveTokens` and the model's maximum output (16,384 at a 32k window with the default reserve). After a run that is stopped (Esc, or a time limit) with the context above the room, every later prompt could be refused with "The request needs a cut and Pi has none to make (Nothing to compact (session too small))", and the session stayed stuck. In one check at these defaults (pi-tuck 1.0.8, 32k window, one session of 30 tasks, one local model), 28 tasks were lost, tasks 3 to 30 ([`benchmark/RESULTS-DEFAULTS.md`](benchmark/RESULTS-DEFAULTS.md)). If you are on 1.0.8 or 1.0.9, upgrade to 1.0.10. In 1.0.10 the cut a prompt needs is pi-tuck's own, so `keepRecentTokens` no longer leaves it with nothing to cut. A rerun of the same check on the 1.0.10 candidate lost no task and got stuck nowhere, with the caveat that two of its tasks had a first request the local server never answered, which a literal no-token count would call lost ([`benchmark/RESULTS-DEFAULTS-1010.md`](benchmark/RESULTS-DEFAULTS-1010.md)). Windows of 128k and up were not affected at the defaults.
+- Small window, a large prompt after a summary-only cut (1.0.10): when the previous summary alone fills the room and a large prompt arrives, the prompt is dropped, because a cut cannot yet shrink a summary on its own. 1.0.10 drops it with no message, where 1.0.9 refused it with one. The next prompt runs normally. Seen once, on a 25,160-character prompt at a 32k window ([`benchmark/RESULTS-CUTLATER.md`](benchmark/RESULTS-CUTLATER.md), t03 task 24). A fix is planned for 1.0.11.
+- Other extensions (1.0.10): a prompt's cut no longer goes through Pi's `session_before_compact`, so another extension's veto there no longer stops it. It never stopped a cut between tool rounds. Pi's own threshold and overflow cuts, and `/compact`, still ask other extensions as before.
 - Semantic search (`tuck_search`) needs a Mac with Metal (Apple silicon). Elsewhere, compaction and `tuck_recall`'s word search work, there is no `tuck_search`, and nothing is downloaded.
 
 ## Benchmarks
 
-Each row says what was measured, under which conditions, and where the data is. "Interim" means the run is not finished.
+Each row says what was measured, under which conditions, and where the data is.
 
 | What | Result | Conditions | Source |
 |---|---|---|---|
-| Pi's default compaction settings, 32k window | 28 of 30 tasks lost (tasks 3 to 30, each refused at its prompt); 1 resolved. Fails the pre-registered bar of 0 lost tasks | pi-tuck 1.0.8 (`86935e9`), `mac-studio/main`, window 32,768, output cap 16,384, `reserveTokens` 16,384 and `keepRecentTokens` 20,000 (larger than the room), one session of chain t06. One session, one model, one build: it shows that the failure occurs at these settings, not how often. Not comparable with other rows | [`benchmark/RESULTS-DEFAULTS.md`](benchmark/RESULTS-DEFAULTS.md) |
+| Pi's default compaction settings, 32k window, pi-tuck 1.0.10 candidate | Passed as registered: 0 dead tasks and 0 stuck sessions on 30 tasks, on a slow local server (27 of 30 tasks hit the 30-minute wall cap, and 2 had a first request the server never answered). 6 resolved. A counter written later, which counts a task with no token as dead, would count those 2 | Candidate `a67ec30` of 1.0.10, `mac-studio/main`, window 32,768, output cap 16,384, Pi's default `reserveTokens` 16,384 and `keepRecentTokens` 20,000, one session of chain t06. One mid-run refusal (a round with 9,020 tokens of reasoning against the 16,384-token room). One session, one model; a pass shows no lost task in these 30 tasks, not that none can occur | [`benchmark/RESULTS-DEFAULTS-1010.md`](benchmark/RESULTS-DEFAULTS-1010.md) |
+| Pi's default compaction settings, 32k window, pi-tuck 1.0.8 | 28 of 30 tasks lost (tasks 3 to 30, each refused at its prompt); 1 resolved. Fails the pre-registered bar of 0 lost tasks | pi-tuck 1.0.8 (`86935e9`), `mac-studio/main`, window 32,768, output cap 16,384, `reserveTokens` 16,384 and `keepRecentTokens` 20,000 (larger than the room), one session of chain t06. One session, one model, one build: it shows that the failure occurs at these settings, not how often. Not comparable with other rows | [`benchmark/RESULTS-DEFAULTS.md`](benchmark/RESULTS-DEFAULTS.md) |
 | Tasks resolved, 32k window | Pi's built-in compaction 94 of 150; pi-tuck 120 of 150 (+17.3 points, 95% lower bound +10.7); observation masking 117 of 150 (pi-tuck +2.0, lower bound −2.7: no difference shown). Turns per task: 9.4 (built-in), 24.0 (pi-tuck), 11.9 (masking). Tokens per session: 6.10 M, 6.39 M, 7.02 M. Spend per arm for the five sessions: $0.87, $0.55, $0.94 | pi-tuck 1.0.5 (commit `aa30824`, the 1.0.5 code; 1.0.6 and 1.0.7 are not measured). DeepSeek V4.1 Flash pinned to one upstream, window 32,768, reserve 16,384, 5 chains of 30 SWE-bench Verified tasks, paired by task, one-sided bootstrap over tasks. **Limits:** only pi-tuck is held to the 16,384-token room (the built-in sent a request over it in 97 of 150 tasks, masking in 73, so the window is nominal for them). The difference by chain is +10.0, −3.3, +50.0, +16.7 and +13.3 points; leaving out chain t03 it is +9.2. The bootstrap resamples tasks, not chains. The pi-tuck arm ran at a different time from the others. One model, one window. pi-tuck refused to cut mid-run in 5 tasks, where one fresh tool result was larger than the room; they count as unresolved. In the same setup pi-tuck 1.0.3 resolved 72 of 150, with 52 dead tasks (tasks refused at their prompt after an earlier failure). In the pi-tuck arm of this row there was 1 dead task (t03 task 24: refused at its prompt with "Nothing to compact"; the next task ran normally), so this build missed the pre-registered acceptance bar of zero dead tasks by one task (the other part of the bar, no loss against 1.0.3 by more than 3 points, was met) | [`benchmark/RESULTS-32K-ACCEPT.md`](benchmark/RESULTS-32K-ACCEPT.md) |
+| The 1.0.10 candidate against 1.0.9, 32k window | 0 dead tasks in both arms; no mid-run refusal. Resolved 50 of 60 (1.0.9) and 49 of 60 (1.0.10 candidate): −1.7 points, 95% lower bound −8.3. **The gate failed as registered, by one task**; 1.0.10 shipped as an exception because of the small-window defect. Turns per task 25.08 and 29.12; cuts 731 and 884; total tokens 13.07 M and 15.12 M | Pre-registered gate. pi-tuck `a67ec30` against 1.0.9 (`cd4626b`). DeepSeek V4.1 Flash pinned to one upstream, window 32,768, reserve 16,384, `keepRecentTokens` 3,333, chains t01 and t02, 60 paired tasks. One model, one window, one run per arm; 60 tasks cannot separate a one-task difference from run-to-run variation | [`benchmark/RESULTS-V110.md`](benchmark/RESULTS-V110.md) |
 | The 1.0.8 candidate against 1.0.7, 32k window | 0 dead tasks in both arms. Resolved 46 of 60 in both (+0.0 points, 95% lower bound −6.7). No mid-run refusal in either arm. Turns per task 25.37 (1.0.7) and 26.10 (1.0.8) | Pre-registered gate, passed as registered. pi-tuck `a2e7d1a` (the tool-result clip and the cut at the end of a run, on 1.0.6) against 1.0.7. Released 1.0.8 is that build merged with 1.0.7's Metal-only recall; its replay requests are reported byte-identical to the gated build on 29 recordings (stated in the source file, not re-run for this README). DeepSeek V4.1 Flash pinned to one upstream, window 32,768, reserve 16,384, chains t01 and t02, 60 paired tasks, both arms run together. One model, one window, one run per arm; 60 tasks cannot show a difference smaller than the bound. The run shows that the change introduced no refusal; no refusal occurred in the 1.0.7 arm for the clip to prevent | [`benchmark/RESULTS-V108.md`](benchmark/RESULTS-V108.md) |
-| Cut time, live | pi-tuck median 0.087 s (90th percentile 0.205 s); Pi's built-in median 268.8 s (90th percentile 421.6 s). Context carried after a cut, median: 27,751 against 29,241 tokens | **Interim.** pi-tuck 1.0.1, Pi 1.4.0, SWE-bench Verified chains of 30 tasks, 131,072-token window, reply reserve 32,768, local model `mac-studio/main` writing Pi's summaries. 27 cuts per arm, 5 chains. The built-in time depends on that model and on server load. pi-tuck's time is an upper bound read from the session file | [`benchmark/RESULTS-INTERIM.md`](benchmark/RESULTS-INTERIM.md) section 1 |
-| Cut time, paired replay | pi-tuck median 0.062 s (range 0.005 to 0.48 s); local-model summarizer 193.4 s (77.3 to 413.3 s); frontier summarizer 96.1 s (39.1 to 267.8 s; measured on the retired model `openai/gpt-6-astra`; feeds no test). Context carried after a cut, median: 28,006 (pi-tuck), 26,424 (local), 25,555 (frontier) tokens | **Interim.** The same recorded sessions cut at the same positions. pi-tuck: 10 recordings, 52 cuts. Summarizers: 6 recordings, 28 and 29 cuts. pi-tuck's time leaves out the background search index | [`benchmark/RESULTS-INTERIM.md`](benchmark/RESULTS-INTERIM.md) section 2 |
-| Billed input, cutting at 60% of the room instead of 100% | −17.9% at 128k, −14.0% at 32k with automatic prompt caching; −17.0% and −9.6% with explicit cache breakpoints. Cuts go from 6 to 12 (128k) and from 84 to 157 (32k); none frees under a tenth of the room | Simulated billing, not provider bills. Prompt caching priced. Build `1bda64b` (the default shipped in 1.0.3). 5 recorded live sessions. 128k = 131,072 window, reserve 32,768. 32k = 32,768 window, reserve 16,384 | [`rnd/replay32/RESULT-lean.md`](rnd/replay32/RESULT-lean.md) |
+| Cut time, live, 128k | pi-tuck median 0.081 s (46 cuts; 90th percentile 0.279 s). Pi's compaction median 235.3 s (48 cuts; 90th percentile 403.8 s). Context carried after a cut, median: 26,790 tokens (pi-tuck), 27,750 (Pi's compaction) | pi-tuck 1.0.1, Pi 1.4.0, SWE-bench Verified, 10 chains of 30 tasks, window 128,000, reply reserve 32,768, `mac-studio/main:xhigh` writing Pi's summaries. The built-in time depends on that model and on server load. pi-tuck's time is an upper bound, read from the session file: the time between the entry written just before the cut and the compaction entry, so it includes anything between the last message and the cut (pi-tuck's tool-loop cuts emit no compaction events). The 44 failed compaction attempts in chain s09-A have no compaction entry and are not in the counts | [`benchmark/RESULTS-MAIN.md`](benchmark/RESULTS-MAIN.md) test 3 |
+| Cut time, paired replay, 128k | pi-tuck median 0.061 s (95 cuts). Pi's compaction prompts on mac-studio/main:xhigh 154.6 s (86 cuts). Pi's compaction prompts on GPT-6.1 Terra 53.2 s (87 cuts, 19 recordings). Context carried after a cut, median: 27,656, 25,790 and 22,784 tokens; median summary 85,561, 23,598 and 11,200 characters | The same recorded sessions cut at the same raw positions. pi-tuck 1.0.1. Terra's cuts ran through Codex, not on the local server | [`benchmark/RESULTS-MAIN.md`](benchmark/RESULTS-MAIN.md) test 3 |
+| Retention, 128k, test 1a: pi-tuck with its recall tools against Pi's compaction prompts on mac-studio/main:xhigh | Registered claim: not more than 3 points below, on these probes (cuts 1 to 4 only) (supported). Accuracy on the probes each was asked: 89.7% (783 probes) and 61.8% (1,677). Difference over the 783 shared probes, which come from the 43 of pi-tuck's 95 answer sets that did not abort: +25.7 points, one-sided 95% lower bound +22.0 (+22.3 clustered by chain). By probe type, pi-tuck / comparator: error class 80.2 / 24.7, files changed 84.5 / 78.9, result-line rule 100.0 / 100.0, required tag 100.0 / 99.3, test-runner summary 90.1 / 31.6 | pi-tuck 1.0.1, 20 recordings, mechanical probes only, evidence at least 35,000 raw tokens before the cut. pi-tuck answered with its recall tools and the comparators with none, from the summary and the kept recent messages. Every one of the 43 asks behind the 783 probes made recall calls (1.25 per probe on average), so no pi-tuck answer lacked the tools; the run cannot show how much of the result comes from the summary and how much from recall. No pi-tuck arm without recall tools exists. The comparators' agents had unrestricted bash, and the logs cannot rule out that one read a recording; nothing shows it. pi-tuck's accuracy does not rise with more calls per probe (87.9%, 90.8%, 90.0% by thirds; post hoc, descriptive). The 783 shared probes are fewer than the 2,969 needed to certify a difference near the margin | [`benchmark/RESULTS-MAIN.md`](benchmark/RESULTS-MAIN.md) test 1a |
+| Retention, 128k, test 1b-Terra: pi-tuck with its recall tools against Pi's compaction prompts on GPT-6.1 Terra | Registered claim: not more than 3 points below, on these probes (cuts 1 to 4 only) (supported). Accuracy on the probes each was asked: 89.7% (783) and 57.8% (1,685). Difference over the 728 shared probes, from the same 43 of pi-tuck's 95 answer sets: +33.7 points, one-sided 95% lower bound +30.4 (+30.1 clustered by chain). By probe type, pi-tuck / Terra: error class 80.2 / 14.7, files changed 84.5 / 72.3, result-line rule 100.0 / 100.0, required tag 100.0 / 93.3, test-runner summary 90.1 / 38.1 | As test 1a, on 19 of the 20 recordings: s09-A is missing because its Terra cut job hit a Codex usage limit, and the set was closed at 19 before any Terra result was read. The claim is non-inferiority. The same limits as test 1a apply | [`benchmark/RESULTS-MAIN.md`](benchmark/RESULTS-MAIN.md) test 1b-Terra |
+| Tasks resolved, 128k, test 2 | Pi's compaction 251 of 300, pi-tuck 258 of 300. Registered claim: no loss larger than 0.4 points. All 10 chains: +2.3 points, lower bound +0.3. Without chain s09: +1.5 points, lower bound −0.4 | pi-tuck 1.0.1, 10 chains of 30 tasks, paired by task, bootstrap over chains. In s09-A Pi's compaction failed 44 times ("generation hit the token cap") from task 23 on, and no other chain has a failed compaction; that is why the bound changes without s09 | [`benchmark/RESULTS-MAIN.md`](benchmark/RESULTS-MAIN.md) test 2 |
+| Tokens per session, input plus output without cache reads, 128k | 241,000 fewer for pi-tuck per session on average, one-sided 95% upper bound −21,000, with all 10 chains. Without chain s09 the mean is −174,000 and the upper bound +43,000 | pi-tuck 1.0.1, paired by chain, bootstrap over sessions. The line holds only with all chains | [`benchmark/RESULTS-MAIN.md`](benchmark/RESULTS-MAIN.md) test 3 |
 | Answers after cutting at 60% instead of 100% | No more losses than the limit on all 4 sets. Losses / wins over n questions: 128k shared 3 / 7 of 99; 128k asymmetric 3 / 1 of 67; 32k shared 5 / 3 of 77; 32k asymmetric 9 / 5 of 343. In the 32k asymmetric set the losses lean against 60% (test_result 4 / 2, error_hit 3 / 1); it is the set to watch | Paired replay, same 5 sessions, DeepSeek flash as agent and judge. Limit, set in advance: losses minus wins at most max(2, 5% of n). Asymmetric = evidence the base keeps native and the variant has summarised | [`rnd/replay32/RESULT-lean.md`](rnd/replay32/RESULT-lean.md) |
 | 1.0.2 changes (plain-text summary, shrinking dialogue view, time on user turns only) against 1.0.1 | No more losses than the limit on all 4 sets. Losses / wins: 128k 1 / 2 of 128; 128k time questions 0 / 0 of 48; 32k 4 / 2 of 127; 32k asymmetric 0 / 2 of 56 | Paired replay, 5 recorded live sessions, DeepSeek flash as agent and judge. 11 of 146 answer sessions hit a 15-minute wall limit and drop out of the pairing | [`rnd/replay32/RESULT-lean.md`](rnd/replay32/RESULT-lean.md), [`CHANGELOG.md`](CHANGELOG.md) |
 | Summary size, plain-text format against the 1.0.1 JSON format | About 30% shorter where the agent writes little, about 14% shorter where it writes a lot | Same dialogue | [`CHANGELOG.md`](CHANGELOG.md) 1.0.2 |
@@ -128,9 +142,8 @@ Each row says what was measured, under which conditions, and where the data is.
 
 Notes:
 
-- The billing figures come from a simulation that replays real sessions through the real cut trigger and prices every request. They are not bills.
 - The answer replays use one cheap hosted model (DeepSeek flash) as agent and judge. They compare pi-tuck with other pi-tuck settings and versions. They do not compare pi-tuck with an LLM compactor.
-- The live and replay time rows measure pi-tuck 1.0.1. The newer versions are listed in the [changelog](CHANGELOG.md). A cut still calls no model, but the eval has not yet re-timed 1.0.3.
+- The 128k rows measure pi-tuck 1.0.1. The newer versions are listed in the [changelog](CHANGELOG.md). A cut still calls no model, but the 128k run has not been repeated on them.
 - Everything here is from SWE-bench-style tasks on a small set of models. It may not carry to your work.
 
 ## Settings
@@ -141,7 +154,7 @@ pi-tuck needs none. Two are optional. Put them in `pi-tuck.json` in Pi's agent f
 { "cutAt": 0.6, "semanticRecall": true }
 ```
 
-- **`cutAt`** (above 0, at most 1; default 0.6) is the part of the input room a request may fill before pi-tuck cuts. At 0.6, each cut leaves room to grow, so fewer tokens are carried and billed per request. `{ "cutAt": 1 }` cuts at the full room. A lower value cuts earlier and smaller. The whole room still decides which request pi-tuck refuses.
+- **`cutAt`** (above 0, at most 1; default 0.6) is the part of the input room a request may fill before pi-tuck cuts. At 0.6, each cut leaves room to grow. `{ "cutAt": 1 }` cuts at the full room. A lower value cuts earlier and smaller. The whole room still decides which request pi-tuck refuses.
 - **`semanticRecall`** (`false` turns semantic search off, on Apple silicon). Nothing is then downloaded, and `tuck_search` uses keywords only.
 
 A bad file is reported at session start, and pi-tuck uses the defaults.
@@ -156,14 +169,6 @@ pi-tuck keeps room for the model's reply: the larger of the model's output limit
 
 The reserve is the larger of `reserveTokens` and the model's `maxTokens`, so lowering `reserveTokens` alone does nothing when `models.json` sets a larger `maxTokens` for that model. Lower both, and keep `maxTokens` above your largest expected reply.
 
-If a session gets stuck after a stopped run (see Known limits), set `keepRecentTokens` well below the room, in `~/.pi/agent/settings.json` for all models, or for one model:
-
-```json
-{ "compaction": { "modelOverrides": { "my-provider/my-model": { "keepRecentTokens": 3333 } } } }
-```
-
-3,333 is the value the 32k benchmark used: the main run's 20,000 of a 98,304 room, scaled to a 16,384 room (`benchmark/PREREG-32K.md`).
-
 If you reach the model through OpenRouter, you can also pin one upstream, so that every request is served by the same one. Put this in `models.json` in Pi's agent folder, and name the upstream you want:
 
 ```json

package/dist/src/build-id.d.ts

@@ -1 +1 @@
-export declare const BUILD_ID = "3c4da6131a995651dda4f51db08a27e509958ef5a18dcfc14a264b07c04663aa";
+export declare const BUILD_ID = "828ac4821689607af006d54a41fd5960bb910bc65aa43adbd81c2f6aac25d180";

package/dist/src/build-id.js

@@ -1 +1 @@
-export const BUILD_ID = "3c4da6131a995651dda4f51db08a27e509958ef5a18dcfc14a264b07c04663aa";
+export const BUILD_ID = "828ac4821689607af006d54a41fd5960bb910bc65aa43adbd81c2f6aac25d180";

package/dist/src/clip.d.ts

@@ -4,6 +4,14 @@ export interface Clip {
     toolCallId: string;
     content: ToolResultMessage["content"];
 }
+/** The budgets to offer a fresh round the room cannot hold whole, in the units the round and the mandatory input are counted in, tried in order.
+ * The room is the provider's, so it is divided by the factor the provider's counts have been running at - the same conversion the planner's own
+ * reserve makes (budget.ts) - before the input no cut can remove is taken out; counting the provider's room against an estimate asks the round for
+ * more than the room holds at a factor above 1. The first try is half of what that leaves. `kept` is what the smallest cut leaves the request
+ * besides the fresh results - the summary floor and its quote of the prompt - measured from the planner's own preview, not a new formula: a half
+ * cannot spend it, so the second try is the whole free room less it. Omit it when the planner bailed before building a preview, and only the half
+ * is tried. Nothing is offered when the mandatory input alone leaves no room. */
+export declare const clipBudgets: (room: number, factor: number, mandatory: number, kept?: number) => number[];
 /** The round's text results within `budget` tokens together: each result smaller than an equal share of what is left stays whole, and the
  * rest are clipped to that share, keeping the most head and tail characters that fit it. None when the round already fits, or when a share
  * cannot hold even the locator. A round of one result gets the whole budget. Deterministic: the same round and budget always clip the same way. */

package/dist/src/clip.js

@@ -9,6 +9,19 @@ const clipped = (text, keep, entryId) => {
                 `\n[pi-tuck: characters ${head}-${text.length - tail} of ${text.length} are not shown, to fit the context window; read them with ` +
                 `tuck_recall {"entryId":"${entryId}","offset":${head}}, up to ${MAX_RECALL_CHARACTERS} characters a call]\n` + text.slice(text.length - tail) }];
 };
+/** The budgets to offer a fresh round the room cannot hold whole, in the units the round and the mandatory input are counted in, tried in order.
+ * The room is the provider's, so it is divided by the factor the provider's counts have been running at - the same conversion the planner's own
+ * reserve makes (budget.ts) - before the input no cut can remove is taken out; counting the provider's room against an estimate asks the round for
+ * more than the room holds at a factor above 1. The first try is half of what that leaves. `kept` is what the smallest cut leaves the request
+ * besides the fresh results - the summary floor and its quote of the prompt - measured from the planner's own preview, not a new formula: a half
+ * cannot spend it, so the second try is the whole free room less it. Omit it when the planner bailed before building a preview, and only the half
+ * is tried. Nothing is offered when the mandatory input alone leaves no room. */
+export const clipBudgets = (room, factor, mandatory, kept) => {
+    const free = Math.floor(room / Math.max(1, factor)) - mandatory;
+    if (free <= 0)
+        return [];
+    return [...new Set(kept === undefined ? [Math.floor(free / 2)] : [Math.floor(free / 2), free - kept - 1])].filter(budget => budget > 0);
+};
 /** The round's text results within `budget` tokens together: each result smaller than an equal share of what is left stays whole, and the
  * rest are clipped to that share, keeping the most head and tail characters that fit it. None when the round already fits, or when a share
  * cannot hold even the locator. A round of one result gets the whole budget. Deterministic: the same round and budget always clip the same way. */

package/dist/src/compaction.d.ts

@@ -6,6 +6,9 @@ import type { RecallPolicy } from "./recall.js";
 /** What a capacity refusal tells the operator. When the provider has counted far more input than pi-tuck's estimate, the refusal most
  * likely comes from that counting (an upstream behind a router can spend much more context on tool schemas), so the notice says so. */
 export declare const refusalNotice: (message: string, factor: number) => string;
+/** What the operator hears when the provider refuses a request pi-tuck admitted as over its window: the bound that reply puts on the counting, and
+ * what pi-tuck did with it. A bound pi-tuck cannot carry (above the ceiling) says so rather than implying the next request is planned at it. */
+export declare const overflowNotice: (contextWindow: number, bound: number, learned: boolean) => string;
 /** The most a seed or an overflow raise may set the calibration factor to. A paired reply's own ratio is not bounded by it. */
 export declare const CALIBRATION_CEILING = 1.5;
 /** How many recent paired replies (and overflow bounds, and the seed while it is among them) the calibration factor is the maximum of. */

package/dist/src/compaction.js

@@ -5,7 +5,7 @@ import { exportSource } from "./source-export.js";
 import { isDeepStrictEqual } from "node:util";
 import { assertNativeToolRounds } from "./protocol.js";
 import { projectedMessages } from "./omissions.js";
-import { applyClips, clipFor } from "./clip.js";
+import { applyClips, clipBudgets, clipFor } from "./clip.js";
 import { DEFAULT_CUT_AT, bandOf, chooseCut, conversationTokens, decideCut, gateCut, incomingEventTokens, incomingTokens, measurableConversationTokens, planningReserve, projectedConversationTokens, requestTokens, systemPart, validCutAt } from "./budget.js";
 import { isContextOverflow } from "@earendil-works/pi-ai";
 import { convertToLlm, SessionManager, SettingsManager } from "@earendil-works/pi-coding-agent";
@@ -52,6 +52,10 @@ class CapacityError extends Refusal {
  * likely comes from that counting (an upstream behind a router can spend much more context on tool schemas), so the notice says so. */
 export const refusalNotice = (message, factor) => message + "; shorten the input, use a model with a larger window, or lower Pi's compaction.reserveTokens, then retry." +
     (factor >= 1.5 ? ` This provider has counted up to ${factor.toFixed(1)}x the input pi-tuck estimates; through a router such as OpenRouter, a different upstream may count less.` : "");
+/** What the operator hears when the provider refuses a request pi-tuck admitted as over its window: the bound that reply puts on the counting, and
+ * what pi-tuck did with it. A bound pi-tuck cannot carry (above the ceiling) says so rather than implying the next request is planned at it. */
+export const overflowNotice = (contextWindow, bound, learned) => `pi-tuck: the provider refused this request as over its ${contextWindow}-token window, so the input counted at least ${bound.toFixed(2)}x what pi-tuck estimated` +
+    (learned ? "; the next request is planned at that." : "; too far out to be a low estimate, so the factor is unchanged.");
 /** The most a seed or an overflow raise may set the calibration factor to. A paired reply's own ratio is not bounded by it. */
 export const CALIBRATION_CEILING = 1.5;
 /** How many recent paired replies (and overflow bounds, and the seed while it is among them) the calibration factor is the maximum of. */
@@ -253,10 +257,14 @@ export async function installCompaction(pi, options = {}) {
             return;
         // The provider refused this exact request for exceeding the window: its true count was at least window + 1, a lower bound on the ratio. A
         // bound above the ceiling says the estimate is not merely low, so it is not learned: the overflow ends the attempt as it does without it.
+        // Either way the operator hears it from pi-tuck. The estimate is what admitted the request, and a turn that ended in the provider's error
+        // with no word from pi-tuck read as a hang: every other refusal says why, and this is the path that skipped it.
         if (overflow) {
-            const candidate = (ctx.model.contextWindow + 1) / paired.tokens;
-            if (candidate <= CALIBRATION_CEILING)
-                learn(candidate);
+            const bound = (ctx.model.contextWindow + 1) / paired.tokens;
+            const learned = bound <= CALIBRATION_CEILING;
+            ctx.ui.notify(overflowNotice(ctx.model.contextWindow, bound, learned), "warning");
+            if (learned)
+                learn(bound);
             return;
         }
         const usage = message.usage;
@@ -266,7 +274,10 @@ export async function installCompaction(pi, options = {}) {
         if (!counts.every(n => Number.isSafeInteger(n) && n >= 0))
             return;
         const input = counts.reduce((a, b) => a + b, 0), ratio = input / paired.tokens;
-        if (input > 0 && Number.isSafeInteger(input) && Number.isFinite(ratio))
+        // A request that was answered cannot have held more than the model's window, so a report above it describes something that never happened.
+        // Learning from one sets the factor for the requests after it: a 60,000-token cache read reported in a 32,768-token window made a
+        // 6,000-token prompt refuse. The overflow branch above learns from a refusal, where the count is a lower bound, and the ceiling is unchanged.
+        if (input > 0 && input <= ctx.model.contextWindow && Number.isSafeInteger(input) && Number.isFinite(ratio))
             learn(ratio);
     });
     pi.on("agent_start", () => { admittedRun = true; pending = undefined; phase = "idle"; });
@@ -320,7 +331,9 @@ export async function installCompaction(pi, options = {}) {
     const clips = new Map();
     const fail = (error, ctx) => {
         recorder.stop("native-attempt-failed");
-        const notify = !failure && error instanceof CapacityError;
+        // Every refusal says why, once per attempt: a capacity error with what the user can change, a cut Pi failed to commit with what that
+        // means for the session, anything else as it is (an attempt that ended with no word looked like a hang).
+        const notify = !failure;
         // A CommitFault stays whatever fails after it.
         if (!(failure instanceof CommitFault))
             failure = error instanceof Error ? error : new Error(String(error));
@@ -333,7 +346,9 @@ export async function installCompaction(pi, options = {}) {
         finally {
             try {
                 if (notify)
-                    ctx.ui.notify(refusalNotice(failure.message, factor), "error");
+                    ctx.ui.notify(failure instanceof CapacityError ? refusalNotice(failure.message, factor) : failure instanceof CommitFault
+                        ? `pi-tuck: ${failure.message}; the session holds a cut its file may lack, so start a new session.`
+                        : `pi-tuck could not plan this request (${failure.message}); the next prompt is planned afresh.`, "error");
             }
             finally {
                 ctx.abort();
@@ -544,7 +559,9 @@ export async function installCompaction(pi, options = {}) {
             unreduced: "Incoming prompt compaction did not reduce context within the estimated request budget",
             plan: (target) => {
                 const reserve = planReserve(target, room, mandatory, ctx);
-                const draft = tuckObservedDraft(tuck, { branchEntries: ctx.sessionManager.getBranch(), tokensBefore: before, previousSummary, newPrompt: true }, ctx, reserve, plannerMeasureFor(ctx), options.recallPolicy, false);
+                // Only a due cut re-renders a summary that sits alone in the session: inside the band a cut is opportunistic, and a smaller summary
+                // there buys nothing the request needed and costs history the next recall would have found.
+                const draft = tuckObservedDraft(tuck, { branchEntries: ctx.sessionManager.getBranch(), tokensBefore: before, previousSummary, newPrompt: true, reRenderSummary: !gate.opportunistic }, ctx, reserve, plannerMeasureFor(ctx), options.recallPolicy, false);
                 if (!draft.compaction)
                     return { draft: false, capacityRejected: Boolean(draft.capacityRejected), reason: draft.unavailable };
                 const messages = withCut(ctx, { type: "compaction", ...draft.compaction, tokensBefore: before });
@@ -595,7 +612,13 @@ export async function installCompaction(pi, options = {}) {
         const queued = event.context.pendingMessages.length ? conversationTokens(event.context.pendingMessages) : 0;
         const mandatory = system + host + queued;
         const previousSummary = saved.find(message => message.role === "compactionSummary")?.summary;
+        // The cut previews this decision has built, in the order it built them. The clip retry below measures them for what a cut leaves the
+        // request besides the fresh results. Reset per decision, so a retry sizes itself against the cut it is retrying, not an earlier attempt's.
+        let previews = [];
+        let floorKept;
         const decide = () => {
+            previews = [];
+            floorKept = undefined;
             const before = measure(saved);
             return decideCut({
                 total: before + mandatory, mandatory, before, room, band, fits: (tokens, limit) => fits(tokens, limit, ctx),
@@ -603,8 +626,15 @@ export async function installCompaction(pi, options = {}) {
                 plan: (target) => {
                     const reserve = planReserve(target, room, mandatory, ctx);
                     const draft = tuckObservedDraft(tuck, { branchEntries: ctx.sessionManager.getBranch(), tokensBefore: before, previousSummary }, ctx, reserve, plannerMeasureFor(ctx), options.recallPolicy, true);
-                    if (!draft.compaction)
+                    if (!draft.compaction) {
+                        // The planner's own floor, so a clip's second budget is measured against what the smallest cut really keeps.
+                        if (draft.floorMessages && event.toolResults) {
+                            const fresh = new Set(event.toolResults.map(result => result.toolCallId));
+                            const kept = measure(draft.floorMessages.filter(message => !(message.role === "toolResult" && fresh.has(message.toolCallId))));
+                            floorKept = Math.min(floorKept ?? kept, kept);
+                        }
                         return { draft: false, capacityRejected: Boolean(draft.capacityRejected), reason: draft.unavailable };
+                    }
                     const header = ctx.sessionManager.getHeader();
                     if (!header)
                         throw new Error("Missing native session header at tool-loop boundary");
@@ -612,27 +642,36 @@ export async function installCompaction(pi, options = {}) {
                     preview.appendCompaction(draft.compaction.summary, draft.compaction.firstKeptEntryId, before, draft.compaction.details, true);
                     const messages = preview.buildSessionProjection().messages;
                     assertNativeToolRounds(messages);
+                    previews.push(messages);
                     return { draft: true, after: measure(messages), mode: draft.mode, compaction: draft.compaction, reserve };
                 },
             });
         };
         let decision = decide();
-        // Only a request that would be refused is clipped. A fresh result is kept whole by every cut (it has not reached the model yet), so
-        // a round larger than the room refuses the run. In their place the request carries the results' heads and tails, together at most
-        // half of what the room leaves the conversation, each with a tuck_recall locator to its rest. When even that is refused the refusal stands.
+        // Only a request that would be refused is clipped. A fresh result is kept whole by every cut (it has not reached the model yet), so a round
+        // larger than the room refuses the run; in its place the request carries the result's head and tail with a tuck_recall locator to the rest.
+        // clipBudgets states the budgets tried and why they are counted in the estimate's units; `kept` is measured from the previews this decision
+        // built, so the second budget is the cut's own floor and not a new formula. When nothing is clipped or the decision still faults, the
+        // refusal stands.
         if (decision.kind === "fault" && event.toolResults) {
             const branch = ctx.sessionManager.getBranch();
             const entryIdOf = (toolCallId) => branch.findLast(entry => entry.type === "message" && entry.message.role === "toolResult" && entry.message.toolCallId === toolCallId)?.id;
-            const round = clipFor(event.toolResults, entryIdOf, Math.floor((room - mandatory) / 2));
-            if (round.length) {
+            const fresh = new Set(event.toolResults.map(result => result.toolCallId));
+            const kept = previews.length ? Math.min(...previews.map(preview => measure(preview.filter(message => !(message.role === "toolResult" && fresh.has(message.toolCallId)))))) : floorKept;
+            for (const budget of clipBudgets(room, factor, mandatory, kept)) {
+                const round = clipFor(event.toolResults, entryIdOf, budget);
+                if (!round.length)
+                    continue;
                 for (const clip of round)
                     clips.set(clip.toolCallId, clip);
                 const clippedDecision = decide();
                 if (clippedDecision.kind === "fault")
                     for (const clip of round)
                         clips.delete(clip.toolCallId);
-                else
+                else {
                     decision = clippedDecision;
+                    break;
+                }
             }
         }
         const before = measure(saved);

package/dist/src/diagnostic-replay.d.ts

@@ -24,6 +24,7 @@ export declare function inspectIncident(records: IncidentRecord[]): {
             mode?: never;
             unavailable: string;
             capacityRejected?: boolean;
+            floorMessages?: import("@earendil-works/pi-agent-core").AgentMessage[];
         };
         receiptId: string | null;
         matchesRecordedProposal: boolean | null;

package/dist/src/diagnostics.d.ts

@@ -1,6 +1,6 @@
 import { type RecallPolicy } from './recall.js';
 import type { SessionEntry } from '@earendil-works/pi-coding-agent';
-export declare const DIAGNOSTIC_BUILD = "3c4da6131a995651dda4f51db08a27e509958ef5a18dcfc14a264b07c04663aa";
+export declare const DIAGNOSTIC_BUILD = "828ac4821689607af006d54a41fd5960bb910bc65aa43adbd81c2f6aac25d180";
 export interface Receipt {
     id: string;
     build: string;

package/dist/src/tuck.d.ts

@@ -21,6 +21,7 @@ type Draft = {
     mode?: never;
     unavailable: string;
     capacityRejected?: boolean;
+    floorMessages?: AgentMessage[];
 };
 interface SearchHit {
     index: number;
@@ -84,13 +85,15 @@ export declare function historicalAllowance(window: number, reserve: number, bas
 export declare function tuckDraft(tuck: Tuck, event: SessionBeforeCompactEvent, ctx: ExtensionContext, reserveTokens: number, measure: Measure, policy?: RecallPolicy, retainCurrentInput?: boolean, operatorManual?: boolean, newPrompt?: boolean): Draft;
 /** Shared compiler observes canonical branch and current token estimate; no native preparation utility. */
 /** `newPrompt`: the cut is planned for a run that has not begun (a prompt Pi has not appended yet, an operator's manual cut, Pi's own cut before
- * a run a custom message starts); the session has moved on from an ended run. */
+ * a run a custom message starts); the session has moved on from an ended run.
+ * `reRenderSummary`: the cut is due, so its summary may be re-rendered smaller (see the `no_live_messages` branch below). */
 export declare function tuckObservedDraft(tuck: Tuck, input: {
     branchEntries: SessionEntry[];
     tokensBefore: number;
     previousSummary?: string;
     operatorManual?: boolean;
     newPrompt?: boolean;
+    reRenderSummary?: boolean;
 }, ctx: ExtensionContext, reserveTokens: number, measure: Measure, policy?: RecallPolicy, retainCurrentInput?: boolean): Draft;
 /** Numeric references use the original session index, then intersect with readable current-branch entries. */
 export declare function tuckRecall(tuck: Tuck, entries: readonly SessionEntry[], branch: readonly SessionEntry[], input: RecallOptions & {

package/dist/src/tuck.js

@@ -31,7 +31,8 @@ export function tuckDraft(tuck, event, ctx, reserveTokens, measure, policy = {},
 }
 /** Shared compiler observes canonical branch and current token estimate; no native preparation utility. */
 /** `newPrompt`: the cut is planned for a run that has not begun (a prompt Pi has not appended yet, an operator's manual cut, Pi's own cut before
- * a run a custom message starts); the session has moved on from an ended run. */
+ * a run a custom message starts); the session has moved on from an ended run.
+ * `reRenderSummary`: the cut is due, so its summary may be re-rendered smaller (see the `no_live_messages` branch below). */
 export function tuckObservedDraft(tuck, input, ctx, reserveTokens, measure, policy = {}, retainCurrentInput = true) {
     const { isHistorySource, readable } = createRecall(policy);
     const projected = ctx.sessionManager.buildSessionProjection();
@@ -62,6 +63,12 @@ export function tuckObservedDraft(tuck, input, ctx, reserveTokens, measure, poli
     if (cut.ok)
         cut = tuck.applyTailBudget(entries, cut, { charsPerToken, maxTokens,
             oversizedFactor: Math.min(OVERSIZED_TAIL_FACTOR, inputRoom / Math.max(1, maxTokens)) });
+    // Nothing since the last cut: its summary alone is the conversation, and only a cut that is due can re-render it. A summary is compiled from
+    // the original sources, so the cut takes the whole history again under this cut's allowance, and a summary that leaves the request no room is
+    // made smaller. Inside the band a cut is opportunistic, and re-rendering there shrinks the summary and costs history for nothing (replays
+    // s04-B task 13, s08-B task 23: a 13,008-token first request became 3,336), so an opportunistic cut refuses as it did before.
+    else if (input.reRenderSummary && cut.reason === "no_live_messages" && entries.some(entry => entry.type === "compaction"))
+        cut = { ok: true, messages: [], selectedIds: [], firstKeptEntryId: "", compactAll: true, keptUserTurns: 0, keepFallbackToCompactAll: false };
     if (!cut.ok)
         return { unavailable: `pi-tuck cannot select a cut: ${cut.reason}` };
     // The latest call's trailing receipts have not reached a subsequent response.
@@ -196,7 +203,8 @@ export function tuckObservedDraft(tuck, input, ctx, reserveTokens, measure, poli
         const model = ctx.model;
         const floorAt = (keep) => {
             const ledger = [...actionRecords(actions, keep), ...ledgerRecords(items, keep)];
-            return { ledger, base: measure(preview(serializeTranscript([...mandatory, ...ledger]) + DIALOGUE_SUFFIX)) };
+            const messages = preview(serializeTranscript([...mandatory, ...ledger]) + DIALOGUE_SUFFIX);
+            return { ledger, messages, base: measure(messages) };
         };
         const fits = (base) => Boolean(model) && base + reserveTokens < model.contextWindow && base < before;
         // When the whole floor cannot fit, the trail and the ledger keep only their headings and counts; only that can refuse the cut.
@@ -205,7 +213,7 @@ export function tuckObservedDraft(tuck, input, ctx, reserveTokens, measure, poli
             floor = floorAt(0);
         const { ledger, base } = floor;
         if (!model || !fits(base))
-            return { unavailable: "pi-tuck's mandatory context cannot fit or reduce the request budget", capacityRejected: Boolean(model && base + reserveTokens >= model.contextWindow) };
+            return { unavailable: "pi-tuck's mandatory context cannot fit or reduce the request budget", capacityRejected: Boolean(model && base + reserveTokens >= model.contextWindow), floorMessages: floor.messages };
         const maxBriefChars = historicalAllowance(model.contextWindow, reserveTokens, base, before);
         const compileInput = { messages, sourceIndices, sourceEntryIds: originalCut.selectedIds, sourceTimes: originalCut.selectedIds.map(id => resolveSourceTime(entryById.get(id))), receiptContext,
             ranking: { maxBriefChars, mandatorySourceIndices: new Set(mandatory.flatMap(r => r.sourceIndex === undefined ? [] : [r.sourceIndex])) }, };
@@ -244,7 +252,7 @@ export function tuckObservedDraft(tuck, input, ctx, reserveTokens, measure, poli
         const { summary, after } = offer ?? assemble(tuck.compileShrunkDialogue(compileInput));
         // Draft reduction concerns conversation. Final request admission owns the effective system/tools.
         if (after + reserveTokens >= model.contextWindow || after >= before)
-            return { unavailable: "pi-tuck's draft does not reduce context within the request budget", capacityRejected: after + reserveTokens >= model.contextWindow };
+            return { unavailable: "pi-tuck's draft does not reduce context within the request budget", capacityRejected: after + reserveTokens >= model.contextWindow, floorMessages: floor.messages };
         const mode = offer ? "dialogue" : "shrunk";
         return { compaction: { summary, firstKeptEntryId: cut.firstKeptEntryId, tokensBefore: input.tokensBefore, details: { ...details, tokensAfter: after, view: offer ? "complete-dialogue" : "shrunk-dialogue", mode } }, after, mode };
     };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-tuck",
-  "version": "1.0.10",
+  "version": "1.0.11",
   "description": "Deterministic compaction for Pi with no model call, plus exact recall of earlier history. Search by meaning on Apple silicon.",
   "keywords": [
     "pi-package",

package/src/build-id.ts

@@ -1 +1 @@
-export const BUILD_ID = "3c4da6131a995651dda4f51db08a27e509958ef5a18dcfc14a264b07c04663aa";
+export const BUILD_ID = "828ac4821689607af006d54a41fd5960bb910bc65aa43adbd81c2f6aac25d180";

package/src/clip.ts

@@ -16,6 +16,19 @@ const clipped = (text: string, keep: number, entryId: string): ToolResultMessage
         `tuck_recall {"entryId":"${entryId}","offset":${head}}, up to ${MAX_RECALL_CHARACTERS} characters a call]\n` + text.slice(text.length - tail) }];
 };
 
+/** The budgets to offer a fresh round the room cannot hold whole, in the units the round and the mandatory input are counted in, tried in order.
+ * The room is the provider's, so it is divided by the factor the provider's counts have been running at - the same conversion the planner's own
+ * reserve makes (budget.ts) - before the input no cut can remove is taken out; counting the provider's room against an estimate asks the round for
+ * more than the room holds at a factor above 1. The first try is half of what that leaves. `kept` is what the smallest cut leaves the request
+ * besides the fresh results - the summary floor and its quote of the prompt - measured from the planner's own preview, not a new formula: a half
+ * cannot spend it, so the second try is the whole free room less it. Omit it when the planner bailed before building a preview, and only the half
+ * is tried. Nothing is offered when the mandatory input alone leaves no room. */
+export const clipBudgets = (room: number, factor: number, mandatory: number, kept?: number): number[] => {
+    const free = Math.floor(room / Math.max(1, factor)) - mandatory;
+    if (free <= 0) return [];
+    return [...new Set(kept === undefined ? [Math.floor(free / 2)] : [Math.floor(free / 2), free - kept - 1])].filter(budget => budget > 0);
+};
+
 /** The round's text results within `budget` tokens together: each result smaller than an equal share of what is left stays whole, and the
  * rest are clipped to that share, keeping the most head and tail characters that fit it. None when the round already fits, or when a share
  * cannot hold even the locator. A round of one result gets the whole budget. Deterministic: the same round and budget always clip the same way. */

package/src/compaction.ts

@@ -5,10 +5,10 @@ import { exportSource } from "./source-export.js";
 import { isDeepStrictEqual } from "node:util";
 import { assertNativeToolRounds } from "./protocol.js";
 import { projectedMessages } from "./omissions.js";
-import { applyClips, clipFor, type Clip } from "./clip.js";
+import { applyClips, clipBudgets, clipFor, type Clip } from "./clip.js";
 import { DEFAULT_CUT_AT, bandOf, chooseCut, conversationTokens, decideCut, gateCut, incomingEventTokens, incomingTokens, measurableConversationTokens, planningReserve, projectedConversationTokens, requestTokens, systemPart, validCutAt,
     type AgentMessage, type Messages, type Plan, type Target, type ToolShape } from "./budget.js";
-import { isContextOverflow } from "@earendil-works/pi-ai";
+import { isContextOverflow, type ToolResultMessage } from "@earendil-works/pi-ai";
 import { convertToLlm, SessionManager, SettingsManager, type ExtensionAPI, type ExtensionContext, type SessionEntry } from "@earendil-works/pi-coding-agent";
 import { Type } from "typebox";
 import { Check } from "typebox/value";
@@ -54,6 +54,11 @@ class CapacityError extends Refusal {}
 export const refusalNotice = (message: string, factor: number): string =>
     message + "; shorten the input, use a model with a larger window, or lower Pi's compaction.reserveTokens, then retry." +
     (factor >= 1.5 ? ` This provider has counted up to ${factor.toFixed(1)}x the input pi-tuck estimates; through a router such as OpenRouter, a different upstream may count less.` : "");
+/** What the operator hears when the provider refuses a request pi-tuck admitted as over its window: the bound that reply puts on the counting, and
+ * what pi-tuck did with it. A bound pi-tuck cannot carry (above the ceiling) says so rather than implying the next request is planned at it. */
+export const overflowNotice = (contextWindow: number, bound: number, learned: boolean): string =>
+    `pi-tuck: the provider refused this request as over its ${contextWindow}-token window, so the input counted at least ${bound.toFixed(2)}x what pi-tuck estimated` +
+    (learned ? "; the next request is planned at that." : "; too far out to be a low estimate, so the factor is unchanged.");
 /** The most a seed or an overflow raise may set the calibration factor to. A paired reply's own ratio is not bounded by it. */
 export const CALIBRATION_CEILING = 1.5;
 /** How many recent paired replies (and overflow bounds, and the seed while it is among them) the calibration factor is the maximum of. */
@@ -232,13 +237,24 @@ export async function installCompaction(pi: ExtensionAPI, options: CompactionOpt
             !isDeepStrictEqual(convertToLlm(paired.messages), paired.snapshot)) return;
         // The provider refused this exact request for exceeding the window: its true count was at least window + 1, a lower bound on the ratio. A
         // bound above the ceiling says the estimate is not merely low, so it is not learned: the overflow ends the attempt as it does without it.
-        if (overflow) { const candidate = (ctx.model.contextWindow + 1) / paired.tokens; if (candidate <= CALIBRATION_CEILING) learn(candidate); return; }
+        // Either way the operator hears it from pi-tuck. The estimate is what admitted the request, and a turn that ended in the provider's error
+        // with no word from pi-tuck read as a hang: every other refusal says why, and this is the path that skipped it.
+        if (overflow) {
+            const bound = (ctx.model.contextWindow + 1) / paired.tokens;
+            const learned = bound <= CALIBRATION_CEILING;
+            ctx.ui.notify(overflowNotice(ctx.model.contextWindow, bound, learned), "warning");
+            if (learned) learn(bound);
+            return;
+        }
         const usage = message.usage;
         if (!usage) return;
         const counts = [usage.input, usage.cacheRead, usage.cacheWrite];
         if (!counts.every(n => Number.isSafeInteger(n) && n >= 0)) return;
         const input = counts.reduce((a, b) => a + b, 0), ratio = input / paired.tokens;
-        if (input > 0 && Number.isSafeInteger(input) && Number.isFinite(ratio)) learn(ratio);
+        // A request that was answered cannot have held more than the model's window, so a report above it describes something that never happened.
+        // Learning from one sets the factor for the requests after it: a 60,000-token cache read reported in a 32,768-token window made a
+        // 6,000-token prompt refuse. The overflow branch above learns from a refusal, where the count is a lower bound, and the ceiling is unchanged.
+        if (input > 0 && input <= ctx.model.contextWindow && Number.isSafeInteger(input) && Number.isFinite(ratio)) learn(ratio);
     });
     pi.on("agent_start", () => { admittedRun = true; pending = undefined; phase = "idle"; });
     pi.on("agent_settled", () => { admittedRun = false; pending = undefined; phase = "idle"; forgetFailure(); clips.clear(); promptCut = undefined; });
@@ -295,14 +311,18 @@ export async function installCompaction(pi: ExtensionAPI, options: CompactionOpt
     const clips = new Map<string, Clip>();
 	const fail = (error: unknown, ctx: ExtensionContext) => {
 		recorder.stop("native-attempt-failed");
-        const notify = !failure && error instanceof CapacityError;
+        // Every refusal says why, once per attempt: a capacity error with what the user can change, a cut Pi failed to commit with what that
+        // means for the session, anything else as it is (an attempt that ended with no word looked like a hang).
+        const notify = !failure;
 		// A CommitFault stays whatever fails after it.
 		if (!(failure instanceof CommitFault)) failure = error instanceof Error ? error : new Error(String(error));
         pendingBoundaryCommit = false;
         pending = undefined;
         promptCut = undefined;
 		try { options.fail?.(error); } finally {
-            try { if (notify) ctx.ui.notify(refusalNotice(failure.message, factor), "error"); }
+            try { if (notify) ctx.ui.notify(failure instanceof CapacityError ? refusalNotice(failure.message, factor) : failure instanceof CommitFault
+                ? `pi-tuck: ${failure.message}; the session holds a cut its file may lack, so start a new session.`
+                : `pi-tuck could not plan this request (${failure.message}); the next prompt is planned afresh.`, "error"); }
             finally { ctx.abort(); }
         }
 	};
@@ -472,7 +492,9 @@ export async function installCompaction(pi: ExtensionAPI, options: CompactionOpt
             unreduced: "Incoming prompt compaction did not reduce context within the estimated request budget",
             plan: (target): Plan<{ compaction: NonNullable<ReturnType<typeof tuckObservedDraft>["compaction"]>; reserve: number }> => {
                 const reserve = planReserve(target, room, mandatory, ctx);
-                const draft = tuckObservedDraft(tuck, { branchEntries: ctx.sessionManager.getBranch(), tokensBefore: before, previousSummary, newPrompt: true }, ctx, reserve, plannerMeasureFor(ctx), options.recallPolicy, false);
+                // Only a due cut re-renders a summary that sits alone in the session: inside the band a cut is opportunistic, and a smaller summary
+                // there buys nothing the request needed and costs history the next recall would have found.
+                const draft = tuckObservedDraft(tuck, { branchEntries: ctx.sessionManager.getBranch(), tokensBefore: before, previousSummary, newPrompt: true, reRenderSummary: !gate.opportunistic }, ctx, reserve, plannerMeasureFor(ctx), options.recallPolicy, false);
                 if (!draft.compaction) return { draft: false, capacityRejected: Boolean(draft.capacityRejected), reason: draft.unavailable };
                 const messages = withCut(ctx, { type: "compaction", ...draft.compaction, tokensBefore: before });
                 assertNativeToolRounds(messages);
@@ -515,7 +537,13 @@ export async function installCompaction(pi: ExtensionAPI, options: CompactionOpt
         const queued = event.context.pendingMessages.length ? conversationTokens(event.context.pendingMessages as Messages) : 0;
         const mandatory = system + host + queued;
         const previousSummary = saved.find(message => message.role === "compactionSummary")?.summary;
+        // The cut previews this decision has built, in the order it built them. The clip retry below measures them for what a cut leaves the
+        // request besides the fresh results. Reset per decision, so a retry sizes itself against the cut it is retrying, not an earlier attempt's.
+        let previews: Messages[] = [];
+        let floorKept: number | undefined;
         const decide = () => {
+            previews = [];
+            floorKept = undefined;
             const before = measure(saved);
             return decideCut({
             total: before + mandatory, mandatory, before, room, band, fits: (tokens, limit) => fits(tokens, limit, ctx),
@@ -523,29 +551,46 @@ export async function installCompaction(pi: ExtensionAPI, options: CompactionOpt
             plan: (target): Plan<{ compaction: NonNullable<ReturnType<typeof tuckObservedDraft>["compaction"]>; reserve: number }> => {
                 const reserve = planReserve(target, room, mandatory, ctx);
                 const draft = tuckObservedDraft(tuck, { branchEntries: ctx.sessionManager.getBranch(), tokensBefore: before, previousSummary }, ctx, reserve, plannerMeasureFor(ctx), options.recallPolicy, true);
-                if (!draft.compaction) return { draft: false, capacityRejected: Boolean(draft.capacityRejected), reason: draft.unavailable };
+                if (!draft.compaction) {
+                    // The planner's own floor, so a clip's second budget is measured against what the smallest cut really keeps.
+                    if (draft.floorMessages && event.toolResults) {
+                        const fresh = new Set(event.toolResults.map(result => result.toolCallId));
+                        const kept = measure(draft.floorMessages.filter(message =>
+                            !(message.role === "toolResult" && fresh.has((message as ToolResultMessage).toolCallId))));
+                        floorKept = Math.min(floorKept ?? kept, kept);
+                    }
+                    return { draft: false, capacityRejected: Boolean(draft.capacityRejected), reason: draft.unavailable };
+                }
                 const header = ctx.sessionManager.getHeader();
                 if (!header) throw new Error("Missing native session header at tool-loop boundary");
                 const preview = SessionManager.inMemory(ctx.cwd, undefined, [header, ...ctx.sessionManager.getBranch()]);
                 preview.appendCompaction(draft.compaction.summary, draft.compaction.firstKeptEntryId, before, draft.compaction.details, true);
                 const messages = preview.buildSessionProjection().messages;
                 assertNativeToolRounds(messages);
+                previews.push(messages);
                 return { draft: true, after: measure(messages), mode: draft.mode, compaction: draft.compaction, reserve };
             },
             });
         };
         let decision = decide();
-        // Only a request that would be refused is clipped. A fresh result is kept whole by every cut (it has not reached the model yet), so
-        // a round larger than the room refuses the run. In their place the request carries the results' heads and tails, together at most
-        // half of what the room leaves the conversation, each with a tuck_recall locator to its rest. When even that is refused the refusal stands.
+        // Only a request that would be refused is clipped. A fresh result is kept whole by every cut (it has not reached the model yet), so a round
+        // larger than the room refuses the run; in its place the request carries the result's head and tail with a tuck_recall locator to the rest.
+        // clipBudgets states the budgets tried and why they are counted in the estimate's units; `kept` is measured from the previews this decision
+        // built, so the second budget is the cut's own floor and not a new formula. When nothing is clipped or the decision still faults, the
+        // refusal stands.
         if (decision.kind === "fault" && event.toolResults) {
             const branch = ctx.sessionManager.getBranch();
             const entryIdOf = (toolCallId: string) => branch.findLast(entry => entry.type === "message" && entry.message.role === "toolResult" && entry.message.toolCallId === toolCallId)?.id;
-            const round = clipFor(event.toolResults, entryIdOf, Math.floor((room - mandatory) / 2));
-            if (round.length) {
+            const fresh = new Set(event.toolResults.map(result => result.toolCallId));
+            const kept = previews.length ? Math.min(...previews.map(preview => measure(preview.filter(message =>
+                !(message.role === "toolResult" && fresh.has((message as ToolResultMessage).toolCallId)))))) : floorKept;
+            for (const budget of clipBudgets(room, factor, mandatory, kept)) {
+                const round = clipFor(event.toolResults, entryIdOf, budget);
+                if (!round.length) continue;
                 for (const clip of round) clips.set(clip.toolCallId, clip);
                 const clippedDecision = decide();
-                if (clippedDecision.kind === "fault") for (const clip of round) clips.delete(clip.toolCallId); else decision = clippedDecision;
+                if (clippedDecision.kind === "fault") for (const clip of round) clips.delete(clip.toolCallId);
+                else { decision = clippedDecision; break; }
             }
         }
         const before = measure(saved);

package/src/tuck.ts

@@ -18,7 +18,8 @@ export type Measure = (messages: AgentMessage[]) => number;
 /** The summary view that produced a draft: the whole pre-cut dialogue, or the same dialogue shrunk to the allowance. Both carry the file ledger. */
 export type DraftMode = "dialogue" | "shrunk";
 type Draft = { compaction: Pick<Extract<SessionEntry, { type: "compaction" }>, "summary" | "firstKeptEntryId" | "tokensBefore" | "details">; after: number; mode: DraftMode; unavailable?: never; capacityRejected?: never }
-    | { compaction?: never; mode?: never; unavailable: string; capacityRejected?: boolean };
+    // The actual floor projection lets the caller measure it without the fresh results it may clip.
+    | { compaction?: never; mode?: never; unavailable: string; capacityRejected?: boolean; floorMessages?: AgentMessage[] };
 interface SearchHit { index: number; role: string; summary: string }
 export interface RecallContinuation { query: string; throughEntryId: string; offset: number }
 /** Includes JSON escaping, hit metadata and continuation, not just excerpt text. */
@@ -63,8 +64,9 @@ export function tuckDraft(tuck: Tuck, event: SessionBeforeCompactEvent, ctx: Ext
 }
 /** Shared compiler observes canonical branch and current token estimate; no native preparation utility. */
 /** `newPrompt`: the cut is planned for a run that has not begun (a prompt Pi has not appended yet, an operator's manual cut, Pi's own cut before
- * a run a custom message starts); the session has moved on from an ended run. */
-export function tuckObservedDraft(tuck: Tuck, input: { branchEntries: SessionEntry[]; tokensBefore: number; previousSummary?: string; operatorManual?: boolean; newPrompt?: boolean }, ctx: ExtensionContext,
+ * a run a custom message starts); the session has moved on from an ended run.
+ * `reRenderSummary`: the cut is due, so its summary may be re-rendered smaller (see the `no_live_messages` branch below). */
+export function tuckObservedDraft(tuck: Tuck, input: { branchEntries: SessionEntry[]; tokensBefore: number; previousSummary?: string; operatorManual?: boolean; newPrompt?: boolean; reRenderSummary?: boolean }, ctx: ExtensionContext,
  reserveTokens: number, measure: Measure, policy: RecallPolicy = {}, retainCurrentInput = true): Draft {
  const { isHistorySource, readable } = createRecall(policy);
 	const projected = ctx.sessionManager.buildSessionProjection();
@@ -92,6 +94,12 @@ export function tuckObservedDraft(tuck: Tuck, input: { branchEntries: SessionEnt
 	let cut = tuck.buildOwnCut(entries, 1);
 	if (cut.ok) cut = tuck.applyTailBudget(entries, cut, { charsPerToken, maxTokens,
         oversizedFactor: Math.min(OVERSIZED_TAIL_FACTOR, inputRoom / Math.max(1, maxTokens)) });
+    // Nothing since the last cut: its summary alone is the conversation, and only a cut that is due can re-render it. A summary is compiled from
+    // the original sources, so the cut takes the whole history again under this cut's allowance, and a summary that leaves the request no room is
+    // made smaller. Inside the band a cut is opportunistic, and re-rendering there shrinks the summary and costs history for nothing (replays
+    // s04-B task 13, s08-B task 23: a 13,008-token first request became 3,336), so an opportunistic cut refuses as it did before.
+    else if (input.reRenderSummary && cut.reason === "no_live_messages" && entries.some(entry => entry.type === "compaction"))
+        cut = { ok: true, messages: [], selectedIds: [], firstKeptEntryId: "", compactAll: true, keptUserTurns: 0, keepFallbackToCompactAll: false };
 	if (!cut.ok) return { unavailable: `pi-tuck cannot select a cut: ${cut.reason}` };
     // The latest call's trailing receipts have not reached a subsequent response.
     // A preferred tail size must not erase this first exposure when the whole
@@ -213,7 +221,8 @@ export function tuckObservedDraft(tuck: Tuck, input: { branchEntries: SessionEnt
     const model = ctx.model;
     const floorAt = (keep: number) => {
         const ledger = [...actionRecords(actions, keep), ...ledgerRecords(items, keep)];
-        return { ledger, base: measure(preview(serializeTranscript([...mandatory, ...ledger]) + DIALOGUE_SUFFIX)) };
+        const messages = preview(serializeTranscript([...mandatory, ...ledger]) + DIALOGUE_SUFFIX);
+        return { ledger, messages, base: measure(messages) };
     };
     const fits = (base: number) => Boolean(model) && base + reserveTokens < model!.contextWindow && base < before;
     // When the whole floor cannot fit, the trail and the ledger keep only their headings and counts; only that can refuse the cut.
@@ -221,7 +230,7 @@ export function tuckObservedDraft(tuck: Tuck, input: { branchEntries: SessionEnt
     if (!fits(floor.base) && (items.length || actions.length)) floor = floorAt(0);
     const { ledger, base } = floor;
     if (!model || !fits(base))
-        return { unavailable: "pi-tuck's mandatory context cannot fit or reduce the request budget", capacityRejected: Boolean(model && base + reserveTokens >= model.contextWindow) };
+        return { unavailable: "pi-tuck's mandatory context cannot fit or reduce the request budget", capacityRejected: Boolean(model && base + reserveTokens >= model.contextWindow), floorMessages: floor.messages };
     const maxBriefChars = historicalAllowance(model.contextWindow, reserveTokens, base, before);
     const compileInput = { messages, sourceIndices, sourceEntryIds: originalCut.selectedIds, sourceTimes: originalCut.selectedIds.map(id => resolveSourceTime(entryById.get(id)!)), receiptContext,
         ranking: { maxBriefChars, mandatorySourceIndices: new Set(mandatory.flatMap(r => r.sourceIndex === undefined ? [] : [r.sourceIndex])) },
@@ -259,7 +268,7 @@ export function tuckObservedDraft(tuck: Tuck, input: { branchEntries: SessionEnt
     const { summary, after } = offer ?? assemble(tuck.compileShrunkDialogue(compileInput));
     // Draft reduction concerns conversation. Final request admission owns the effective system/tools.
     if (after + reserveTokens >= model.contextWindow || after >= before)
-        return { unavailable: "pi-tuck's draft does not reduce context within the request budget", capacityRejected: after + reserveTokens >= model.contextWindow };
+        return { unavailable: "pi-tuck's draft does not reduce context within the request budget", capacityRejected: after + reserveTokens >= model.contextWindow, floorMessages: floor.messages };
     const mode: DraftMode = offer ? "dialogue" : "shrunk";
 	return { compaction: { summary, firstKeptEntryId: cut.firstKeptEntryId, tokensBefore: input.tokensBefore, details: { ...details, tokensAfter: after, view: offer ? "complete-dialogue" : "shrunk-dialogue", mode } }, after, mode };
     };