fix(compression): don't recommend a threshold the small-context floor will ignore

[Sora-bluesky]

What does this PR do?

The auxiliary-compression feasibility warning computes its compression.threshold suggestion as aux_context / main_context (agent/conversation_compression.py), independently of ContextCompressor._effective_threshold_percent()'s raise-only small-context floor (agent/context_compressor.py:1261-1262). For main windows under 512K the floor raises any configured value below 75% back up, so a suggestion like threshold: 0.40 is silently ignored and the identical warning returns every session — an advice loop the user cannot exit by following the advice.

This PR derives the suggestion's viability through the compressor's own floor logic (the _effective_threshold_percent staticmethod, so the two can't drift): the "lower the threshold" option is offered only when the floored value still fits the auxiliary model's context; otherwise the message recommends only a larger compression model and explains the floor. This is the issue's first two suggested fixes — no new config surface.

Related Issue

Fixes #67422

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• agent/conversation_compression.py — compute threshold_suggestion_viable via ContextCompressor._effective_threshold_percent(); branch the persistence-guidance section of the warning on it. Unknown main context keeps the legacy message (the floor can't be evaluated without a window size).
• tests/run_agent/test_compression_feasibility.py — the existing auto-correct test (200K main, 40% suggestion → floored) now pins the new branch: no threshold: suggestion, floor explained. Two new tests pin the surviving suggestion at/above the floor on a small window (100K main, 80% ≥ 75%) and below 75% on a 512K+ window where no floor applies (1M main, 30%).

How to Test

1. scripts/run_tests.sh tests/run_agent/test_compression_feasibility.py -q
2. Manual repro (from the issue): main model with a <512K window + aux compression model below 75% of it → the warning no longer suggests a sub-0.75 compression.threshold; it explains the floor and recommends a larger aux model. Previously, applying the suggested value changed nothing and the warning repeated every session.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits
• I searched for existing PRs to make sure this isn't a duplicate (topic search + issue timeline: none; triage relates fix(compression): respect user-configured threshold below 0.50 on small-ctx models #66249 as adjacent but distinct)
• My PR contains only changes related to this fix/feature
• I've run the compression suites (tests/run_agent/test_compression_feasibility.py, tests/agent/test_context_compressor.py) — 201 passed, zero failures on my platform
• I've added tests for my changes (the updated floored-branch test fails against the previous code)
• I've tested on my platform: Windows 11

Documentation & Housekeeping

• Docstrings/comments — the viability rationale is documented at the computation site — or N/A
• cli-config.yaml.example — N/A (no config surface added)
• CONTRIBUTING.md / AGENTS.md — N/A
• Cross-platform impact — N/A (pure string/arithmetic logic)
• Tool descriptions/schemas — N/A

Screenshots / Logs

$ pytest tests/run_agent/test_compression_feasibility.py tests/agent/test_context_compressor.py -q  (Windows 11)
201 passed

# Against the unfixed code (regression proof, changed test):
1 failed (test_auto_corrects_threshold_when_aux_context_below_threshold), new pinning tests pass

🤖 Generated with Claude Code

[alt-glitch]

This was generated by AI during triage.

Related to #67422 and #66249. This patch fixes the warning/recommendation contract; #66249 changes the underlying small-context threshold behavior.

[teknium1]

Thanks for isolating the stale recommendation loop; the underlying mismatch is present on current upstream main (agent/conversation_compression.py:341, agent/context_compressor.py:1261-1263).

Problems

• agent/conversation_compression.py:353 checks only the percentage floor against the raw context window. The actual built-in trigger also uses the output reservation, 64K floor, and effective-window guard in agent/context_compressor.py:1293-1305. That can suppress a threshold recommendation that would actually fit after the persisted setting is recomputed.
• The new code unconditionally imports and applies built-in ContextCompressor policy. Plugin engines can be active at agent/agent_init.py:1881-1908, and that code explicitly states that external engines own compaction policy.

Suggested changes

• Gate the floor-specific calculation to the built-in compressor and use _compute_threshold_tokens(..., max_tokens) after applying the effective percent.
• Add a reservation-based regression test and a non-built-in-engine test.

Automated hermes-sweeper review.

[teknium1]

This is not the complete built-in trigger calculation: _compute_threshold_tokens() also applies max_tokens reservation, the 64K floor, and the degenerate effective-window branch (agent/context_compressor.py:1293-1305). It also should not run for a plugin context engine, which owns its own policy. Please gate this to ContextCompressor and compare aux_context to the fully recomputed token threshold.

[Sora-bluesky]

Both points addressed in 75d5b2a84:

1. Full trigger recomputation. The guard now mirrors _compute_threshold_tokens(...) (output reservation + 64K floor + degenerate-window guard) applied to the effective percent, not just the raw-window percentage. Regression test: a 200K window with max_tokens=120K recomputes to 64K, so the suggestion is correctly kept for an 80K aux model — the case the raw-window check wrongly suppressed.
2. Plugin engines untouched. The built-in policy is gated behind isinstance(agent.context_compressor, ContextCompressor); non-built-in engines keep the plain suggestion (per Codex gpt-5.5 autoraise should defer to external context engines #44439's "external engines own compaction policy"). Passthrough test added.

The non-viable message now names the recomputed trigger instead of hardcoding the 75%/512K wording, so it stays accurate when the reservation — not the percentage floor — is what makes the value unreachable.

[Sora-bluesky]

Agreed the original suggestion skipped _compute_threshold_tokens's max_tokens reservation, 64K floor, and degenerate-window guard. Thanks for salvaging the complete version into #69332, which mirrors the full recomputation.

[Sora-bluesky]

Thanks for the review. Both points were against commit 7073d1a8; the follow-up 21a59ab (six minutes later, and on the current head) already does what it asks:

• The viability check now recomputes the full trigger: it calls _compute_threshold_tokens(main_ctx, _effective_threshold_percent(...), max_tokens), so the output reservation, the 64K floor, and the effective-window guard from context_compressor.py all apply, instead of the raw percentage-against-window it used before.
• The floor logic is gated on isinstance(agent.context_compressor, ContextCompressor), so a plugin engine keeps its own policy and the plain suggestion is left untouched.
• Both suggested tests are in: test_threshold_suggestion_kept_when_reservation_shrinks_trigger (a 120K reservation on a 200K window shrinks the trigger to the 64K floor, and the recommendation is not suppressed) and test_plugin_engine_keeps_plain_suggestion.

Flagging in case the keep_open verdict was rendered before that follow-up landed.

[teknium1]

Merged via #69332 (commit cca7b93). All three of your commits were cherry-picked with authorship preserved — cleanest submission of the three competing fixes, no follow-up needed. Thanks!

[Sora-bluesky]

Late reply — my monitoring only covered open threads until this week, and this landed in the blind spot; found it in today's backfill. Verified all three (dbc71fb, 19a59f7, cca7b93) on main with authorship intact. Thanks for carrying them.