feat(agent-loop): aggressive prune tier at 60% context (#3) - #221
Closed
yogthos wants to merge 1 commit into
Closed
Conversation
…PLAN #3) The per-result cap (cap_oversized_tool_results) was a flat 3000 tokens regardless of context pressure. Near the limit, a single uncapped tool result could push the NEXT request over before the reactive 75% post-response fold fires. Add a tiered cap: above AGGRESSIVE_CAP_THRESHOLD (60% estimated context) the per-result cap tightens to AGGRESSIVE_RESULT_CAP_TOKENS (1000) via a pure `tiered_result_cap(estimate, ctx_max)` helper; below it stays at 3000. The 60% threshold sits below the 75% fold trigger so the tighter cap has room to work first. Wired at the pre-send cap site in run_loop. Unit test for the tiering (normal below 60%, strict boundary at 60%, aggressive above). 2136 pass at -D warnings. Stacked on the circuit-breaker branch (PR #220).
This was referenced May 29, 2026
Collaborator
Author
allen-munsch
pushed a commit
to allen-munsch/dirge
that referenced
this pull request
May 29, 2026
The pre-send snip (cap_oversized_tool_results) freed tokens but never reported how many, so the post-response fold always fired at 75% even when the snip had just bought plenty of headroom. - Add `cap_oversized_tool_results_counted` — wraps the unchanged capper and reports tokens freed (measured with the same estimator the fold decision uses). Existing callers stay on the Vec-returning fn. - run_loop tracks `snip_tokens_freed` from the (now tiered) cap site. - In the post-usage Fold path, a pure `snip_bought_enough(freed, ctx_max, aggressive)` skips a NORMAL fold when the snip freed > SNIP_SUFFICIENT_FRACTION (10%) of the window. Aggressive / force-summary folds still fire. The credit resets after each post-usage decision so a stale snip can't suppress a later fold. Tests: snip_bought_enough gating (normal vs aggressive, <10%, div-0 guard) and cap_counted freed-token accuracy. 2138 pass at -D warnings. Stacked on the aggressive-prune branch (PR dirge-code#221).
allen-munsch
pushed a commit
to allen-munsch/dirge
that referenced
this pull request
Jun 3, 2026
The pre-send snip (cap_oversized_tool_results) freed tokens but never reported how many, so the post-response fold always fired at 75% even when the snip had just bought plenty of headroom. - Add `cap_oversized_tool_results_counted` — wraps the unchanged capper and reports tokens freed (measured with the same estimator the fold decision uses). Existing callers stay on the Vec-returning fn. - run_loop tracks `snip_tokens_freed` from the (now tiered) cap site. - In the post-usage Fold path, a pure `snip_bought_enough(freed, ctx_max, aggressive)` skips a NORMAL fold when the snip freed > SNIP_SUFFICIENT_FRACTION (10%) of the window. Aggressive / force-summary folds still fire. The credit resets after each post-usage decision so a stale snip can't suppress a later fold. Tests: snip_bought_enough gating (normal vs aggressive, <10%, div-0 guard) and cap_counted freed-token accuracy. 2138 pass at -D warnings. Stacked on the aggressive-prune branch (PR dirge-code#221).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Phase 2 of IMPROVEMENTS_PLAN. Stacked on #220 (base = circuit-breaker branch).
Problem
cap_oversized_tool_resultsused a flat 3000-token cap at every context level. Near the limit, one uncapped tool result could push the next request over before the reactive 75% post-response fold fires.Fix
Tiered cap via a pure
tiered_result_cap(estimate, ctx_max): aboveAGGRESSIVE_CAP_THRESHOLD = 0.60the per-result cap tightens toAGGRESSIVE_RESULT_CAP_TOKENS = 1000; below, it stays 3000. 60% sits under the 75% fold trigger so the tighter cap has room to work first. Wired at the pre-send cap site inrun_loop.Unit test covers normal (<60%), the strict 60% boundary, aggressive (>60%), and a div-by-zero guard. 2136 pass at
-D warnings.Next: #4 snip feedback loop (builds on this), then #2 file restore, then #5 report enrichment.