[Bug] K2 Horizon context window assumed to be 8k — auto-compaction kicks in far too early

[cmoalem]

Bug: K2 Horizon context window assumed to be 8k — auto-compaction kicks in far too early

Koder version: 0.4.1
Models: ifm/k2-horizon-375b-a23b/featherless, ifm/k2-horizon-32b/featherless (provider aixplain-code)
OS: Linux

Observed behavior

In every K2 Horizon session, the compaction service operates as if the model's context window were 8192 tokens:

INFO ... service=session.compaction protect=3276 minimum=1638 pruning

protect=3276 / minimum=1638 are exactly 40% / 20% of 8192. In the same Koder version, sessions on other models show e.g. protect=40000 minimum=20000 (a 100k context), so the 8k assumption is specific to the K2 Horizon models.

Auto-compaction fired on a session that was only ~14k tokens long:

INFO 2026-09-25T10:37:45Z service=session.compaction budget=4096 size=14262 total=0 tail fallback

(session ses_f27e189c7ffe94hwfblNefzdkk, model ifm/k2-horizon-375b-a23b/featherless)

Expected context size

K2 Horizon models support context sizes well above 500k tokens. Koder's own model cache (~/.cache/koder/aixplain-models-*.json) even lists limit.context: 32768 for all K2 Horizon entries — yet the effective compaction budget corresponds to 8192 tokens, causing auto-compaction to trigger very early and wasting most of the available context.

Expected behavior

Koder should use the model's actual context window (500k+ for K2 Horizon) when computing compaction thresholds, instead of an 8k assumption.