Compressor does not effectively reduce long session-history blocks

[dhaern]

What happened?

In a long-running OpenCode TUI session, Magic Context keeps injecting a very large <session-history> block with hundreds of compartments. The historian is working and new compartments/facts are generated, but the number of persisted/injected compartments barely decreases over time even when the history block is well above the configured compression budget.

Current observed status:

History Compression
- Compartments: 202
- Facts: 20
- History block: ~38,496 tokens
- Compression budget: ~20,800 tokens (185% used)
- Compressor fires: when history block exceeds budget after historian run

Expected behavior:

• When the rendered history block is significantly above the compression budget, the compressor should reduce it enough to approach the budget over a reasonable number of passes.
• Exposed compressor config fields should affect compressor behavior.
• Long sessions should not keep injecting hundreds of compartments indefinitely if compression is enabled and the history block is above budget.

Observed behavior:

• The compressor does run, but it usually only reduces 15 compartments into 12.
• This only removes 3 compartments per pass, while the historian may later add more compartments.
• In practice, the session remains around ~180-200+ compartments and the injected <session-history> stays large.
• Some schema-exposed compressor settings appear to be accepted by config but not passed to the compressor runtime.

Relevant log excerpt:

compressor: history block ~38584 tokens exceeds budget 20800 by ~17784 tokens
compressor: depth histogram (205 total) d0=205
compressor: scored 205, picked 15 contiguous (1-1310, ~5617 tokens), avg_depth=0.0 → output_depth=1 (ratio=1.33, target=12 compartments)
compressor: completed depth-1 (15 → 12)
independent compressor completed in background — compressed history will appear on next cache-busting pass

Other runs show the same pattern:

compressor: history block ~39399 tokens exceeds budget 19500 by ~19899 tokens
compressor: scored 209, picked 15 contiguous (...), avg_depth=0.0 → output_depth=1 (ratio=1.33, target=12 compartments)
compressor: completed depth-1 (15 → 12)

compressor: history block ~42643 tokens exceeds budget 19500 by ~23143 tokens
compressor: scored 205, picked 15 contiguous (...), avg_depth=0.0 → output_depth=1 (ratio=1.33, target=12 compartments)
compressor: completed depth-1 (15 → 12)

This makes compression too conservative for long sessions. The compressor is technically running, but it does not materially reduce the injected history block.

Config issue

The schema exposes these fields:

"compressor": {
  "enabled": true,
  "min_compartment_ratio": 500,
  "max_merge_depth": 5,
  "cooldown_ms": 120000,
  "max_compartments_per_pass": 25,
  "grace_compartments": 6
}

However, from inspection of the built package, only these values appear to be passed through to compression:

minCompartmentRatio
maxMergeDepth
cooldownMs

The following fields appear to be read by the schema but not actually passed to runCompressionPassIfNeeded():

max_compartments_per_pass
grace_compartments

So users can configure them, but the compressor still appears to fall back to defaults:

DEFAULT_COMPRESSOR_MAX_COMPARTMENTS_PER_PASS = 15
DEFAULT_COMPRESSOR_GRACE_COMPARTMENTS = 10

Aggressiveness issue

The effective merge ratio also appears hardcoded:

COMPRESSOR_MERGE_RATIO_BY_DEPTH = {
  1: 1.33,
  2: 1.5,
  3: 2,
  4: 2,
  5: 0
}

For depth 1 this means:

15 compartments → 12 compartments

That is too weak when the history block is far above budget, for example at 185% of budget. There does not seem to be a config option for compressor aggressiveness or merge ratios.

Model configuration issue

The compressor seems to reuse the historian agent/model. I could not find a separate compressor.model setting. That may be intentional, but it means users cannot choose a stronger/cheaper model specifically for compression.

Current historian config example:

"historian": {
  "model": "omniroute-chat/gh/gpt-5.4-mini",
  "two_pass": false
}

Questions:

1. Should the compressor reduce the number of compartments more aggressively when the history block is far above budget?
2. Should max_compartments_per_pass and grace_compartments be wired through to runCompressionPassIfNeeded()?
3. Should compressor aggressiveness be configurable, for example via compressor.aggressiveness: conservative | balanced | aggressive, or via configurable merge ratios / stronger over-budget behavior?
4. Should there be an optional compressor.model, falling back to historian.model when unset?

Diagnostics

I can provide doctor --issue output if needed. Relevant sanitized details:

Client: OpenCode TUI
Magic Context config:
- ctx_reduce_enabled: true
- execute_threshold_percentage: 65
- history_budget_percentage: 0.08
- compressor.enabled: true
- compressor.min_compartment_ratio: 500
- compressor.max_merge_depth: 5
- compressor.cooldown_ms: 120000
- compressor.max_compartments_per_pass: 25
- compressor.grace_compartments: 6
- historian.two_pass: false

Observed /ctx-status:
- Compartments: 202
- Facts: 20
- History block: ~38,496 tokens
- Compression budget: ~20,800 tokens
- Budget usage: 185%

Plugin version

0.17.2

OpenCode version

Unknown / current installed OpenCode TUI

Platform

Linux arm64

Client

OpenCode TUI (CLI)

Log output

compressor: history block ~38584 tokens exceeds budget 20800 by ~17784 tokens
compressor: depth histogram (205 total) d0=205
compressor: scored 205, picked 15 contiguous (1-1310, ~5617 tokens), avg_depth=0.0 → output_depth=1 (ratio=1.33, target=12 compartments)
compressor: completed depth-1 (15 → 12)
independent compressor completed in background — compressed history will appear on next cache-busting pass

compressor: history block ~39399 tokens exceeds budget 19500 by ~19899 tokens
compressor: depth histogram (209 total) d0=209
compressor: scored 209, picked 15 contiguous (...), avg_depth=0.0 → output_depth=1 (ratio=1.33, target=12 compartments)
compressor: completed depth-1 (15 → 12)

compressor: history block ~42643 tokens exceeds budget 19500 by ~23143 tokens
compressor: depth histogram (205 total) d0=193 d1=12
compressor: scored 205, picked 15 contiguous (...), avg_depth=0.0 → output_depth=1 (ratio=1.33, target=12 compartments)
compressor: completed depth-1 (15 → 12)

[dhaern]

Additional data point: I ran /ctx-recomp on the affected long-running session to check whether a full state rebuild would reduce the injected history size.

Result:

Before /ctx-recomp: 202 compartments
After /ctx-recomp: 207 compartments
Facts: increased as well

So /ctx-recomp did rebuild/reorganize the session state, but it did not reduce the size of the persisted/injected history in this case. It may improve ordering or normalization, but it is not an effective workaround for this issue.

This reinforces that the problem is not only stale or poorly ordered session state. For long sessions, there still needs to be an effective compression path that materially reduces the number/size of compartments when the rendered history block is above budget.

[ualtinok]

Did this happen after changing from a bigger model to smaller model?

[dhaern]

Did this happen after changing from a bigger model to smaller model?

Not intentionally. My configured historian/compressor model stayed the same (omniroute-chat/gh/gpt-5.4-mini). It’s possible my proxy may have fallen back once or twice, but this doesn’t look tied to a deliberate model downgrade.

The stronger signal is that /ctx-recomp rebuilt the state but increased compartments from 202 to 207, and normal compression keeps doing very small passes like 15 → 12 while the history block stays far above budget.

So model quality may affect summary quality, but this specific issue looks more related to low compressor aggressiveness and config wiring than to changing models.

[dhaern]

Looks like after a few hours of use after I did ctx-recomp the compartments are starting to reduce slowly, now im at 195 from 207 after I did ctx recomp (before recomp was 202). Idk if compressor needs a revision or adjustment from your side but Im updating all relevant info that I see now.