Quota-aware compaction: on subscription plans, context compaction should trigger on a token budget, not only near the model's max context window

[salim4n]

Summary

Kimi Code only triggers context compaction when the conversation approaches the model's maximum context window. With K3's 1M-token window (max_context_size = 1048576) and the default reserved_context_size = 50000, compaction effectively never happens in real sessions. Every agentic loop step re-sends the entire growing context, and on subscription plans (quota-based, not pay-per-token) this burns through the weekly/monthly allowance in a single working session — even though 98%+ of input tokens are cache hits.

Real measurements from my machine

Extracted from ~/.kimi-code/sessions/*/agents/*/wire.jsonl (usage.record events):

Metric	Value
LLM requests analyzed	1,281 across ~20 sessions
Total input tokens processed	~180M
Cache read ratio	98.5% (176.9M cached reads)
Max context reached in one session	361,094 tokens
Heaviest single session	~100M tokens processed, 445 requests
Parallel sub-agents observed	up to 9 per session, each with its own full context

Config at the time of measurement:

default_model = "kimi-code/k3"        # max_context_size = 1048576
[loop_control]
reserved_context_size = 50000         # compaction only near ~998K
[thinking]
enabled = true
effort = "high"

Why this hurts subscription users specifically

The compaction trigger is calibrated on the model's technical window (when compaction is needed to avoid context overflow errors). But subscription plans are quota-limited: what costs the user is total tokens processed per session, including cached tokens. The current design optimizes for "never hit the context limit", while the quota-limited user needs "keep total processed tokens bounded per task".

Concrete effect: with K3, a session can grow to 361K+ tokens of context (measured) without any compaction, and each of the 445 loop steps re-processes it. The same task on a 262K-window model would have compacted ~4x earlier and processed a fraction of the tokens.

Proposed feature

Add a quota-aware compaction trigger, orthogonal to the window-based one:

[loop_control]
# New: compact when the session's cumulative processed input tokens
# (cached included) exceed this budget, regardless of window headroom.
session_token_budget = 5_000_000   # example

# Or, simpler v1: compact when context exceeds this absolute size,
# decoupled from max_context_size.
compact_context_threshold = 150_000  # example

Behavior:

1. When cumulative input tokens (or absolute context size) cross the threshold, trigger the same summarization compaction that window-overflow uses today.
2. Surface the counter in the UI: "this session has processed N tokens (x% cached)" — users on quota plans need this visibility before their allowance is gone.
3. Optionally: a per-model default profile, so K3 (1M window) doesn't silently disable compaction for quota users.

Workarounds I'm using meanwhile

• Default to kimi-code/kimi-for-coding (262K window) instead of K3 → compaction triggers ~4x earlier
• Manual /compact at every task phase change
• New session per distinct task; fewer parallel sub-agents

Environment

• Kimi Code CLI (migrated from kimi-cli), macOS
• Config: ~/.kimi-code/config.toml as shown above
• Subscription: Kimi For Coding (quota-based)

---