fix(compression): skip auto-lower when context_length is user-configured

[liuhao1024]

What does this PR do?

Fixes auxiliary.compression.context_length in config.yaml having an unintended side effect: it triggers the auto-lower mechanism, reducing the session's compression threshold to the config value — causing near-useless compression loops on long-running sessions.

Root cause: In check_compression_model_feasibility(), when aux_context < threshold, the auto-lower unconditionally sets threshold_tokens = aux_context. But when aux_context comes from the user's explicit auxiliary.compression.context_length config, it represents an input budget for the summarizer, not a capability limit of the compression model. A flash model can process 400K+ tokens just fine — the user set 128K to limit how much history to feed it, not to declare it can't handle more.

Fix: Skip auto-lower when _aux_compression_context_length_config is set (indicating the value came from user config). The auto-lower still engages when the aux model's detected context is genuinely below the threshold (no config override).

Related Issue

Fixes #58407

Type of Change

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

Changes Made

• agent/conversation_compression.py: In check_compression_model_feasibility(), skip the auto-lower when aux_context originates from explicit user config (_aux_compression_context_length_config is not None). Added 7 lines (1 logic + 6 comment).
• tests/run_agent/test_compression_config_auto_lower.py: Added 2 regression tests — one verifying auto-lower is skipped when config is set, one verifying it still engages without config.

How to Test

1. Set auxiliary.compression.context_length: 128000 in config.yaml with a main model context of 800K+ and compression.threshold: 0.50
2. Run a long session (300+ messages) — compression should NOT fire on every turn
3. Remove the context_length config — auto-lower should re-engage when the aux model's detected context is below threshold
4. Run: python -m pytest tests/run_agent/test_compression_config_auto_lower.py -xvs — should pass
5. Run: python -m pytest tests/run_agent/test_compression_feasibility.py -xvs — all existing tests should still pass

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
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes
• I've tested on my platform: macOS

Documentation & Housekeeping

• I've updated relevant documentation — or N/A
• I've updated cli-config.yaml.example — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md — or N/A
• I've considered cross-platform impact — or N/A
• I've updated tool descriptions/schemas — or N/A

[teknium1]

Thanks — the bug is confirmed real (#58407's every-turn compression loop traced exactly as you described, and the 1.3M-token burn is a serious defect), and your diagnosis of the mechanism was correct.

Closing on fix direction rather than quality: the auto-lower you're skipping is the overflow guard for the summarizer — it exists so compression's own request fits inside the aux model's window. auxiliary.compression.context_length's documented meaning (#8499, and the MINIMUM_CONTEXT error text) is a capability declaration for custom endpoints that misreport their context. Those users — the exact population that sets this key — would, with the skip, get threshold-sized summarization requests fired into genuinely small endpoints: hard overflow, compression permanently broken. It fixes your scenario by breaking the documented one.

The resolution needs a semantics decision, not a provenance gate — tracked in #58745 (candidate designs: cap/chunk the summarizer input, warn-and-refuse, or splitting capability from budget), alongside the related #57102/#53235. Your report and analysis are credited there; if the design lands on a direction you'd like to implement, a fresh PR against that decision would be very welcome. Your other PRs from today (#58431, #58378, #58397) were all merged with your authorship preserved — thanks for the strong batch.