[Bug][desktop] Context compaction shrinks the LLM context but not the rendered transcript - the desktop UI keeps degrading for the rest of the session

Product or interface

Desktop app

Version

MiniMax Code Desktop 3.1.4.186 (Windows build)

Platform

Windows

OS version and architecture

Windows 11 x64, build 10.0.26300

Issue area

UI / UX

Desktop log upload ID (optional)

No response

Steps to reproduce

Run a long, tool-heavy session in the desktop app, so the transcript keeps growing with large tool outputs (raw log dumps, whole-file reads).
Let the session cross the automatic context-compaction threshold.
Observe the turn that triggers compaction, then keep using the same session.

Expected and actual behavior

Expected: after compaction the desktop app should be no slower than before, and the transcript view should not keep degrading for the rest of the session.

Actual: two separate but compounding effects.

(1) Compaction shrinks the LLM context but not the view layer.

The runtime compacts 1,306 messages down to 1, but the persisted transcript (messages.jsonl) still holds all 1,045 lines / 3.2 MB, and the desktop keeps fetching and rendering the full transcript. The compaction boundary is invisible to the UI: the message that was handed to the model has been replaced, while the transcript the UI renders is a different and much larger dataset.

(2) The compaction attempt itself blocks the turn for 71.3 s.

Measurements taken on a single machine over one day, from the local runtime's own request log:

Endpoint	Long session	Short session (137 messages)
`GET /minimax-desktop/api/v1/session/{id}/message`	n=674, avg 104.5 ms, max 716 ms	n=25, avg 15.5 ms, max 24 ms

This endpoint returns the whole transcript, so both the response payload and the renderer's parse + re-render cost grow linearly with history. A short-lived session is unaffected, which is why the problem only shows up once a conversation gets long.

Related numbers from the same session:

POST /minimax-desktop/api/v1/session/{id}/message/edit (history rewrite / branch): 1.0-1.5 s per call, 12+ calls in one day.
The session directory grew to 485 MB: 31 .history-mutation-* directories plus a 6.25 MB full-transcript snapshot per generation.
~/.minimax/v2 in total: 1.3 GB.

Redacted error summary

[local-runtime-v2] context compaction checkpoint attempt settled {
  "event":"context_compaction_checkpoint_attempt_settled",
  "session_id":"mvs_<redacted>",
  "turn_id":"<redacted>",
  "turn_sequence":432,
  "phase":"initial",
  "thinking_level":"high",
  "checkpoint_candidate":"hall",
  "checkpoint_attempt":1,
  "input_message_count":1306,
  "outcome":"generated",
  "duration_ms":71278.5773999989
}

[pi-turn-runner] beforeLlmCall replaced context messages {
  "session_id":"mvs_<redacted>",
  "phase":"initial",
  "replacement_id":"ctx_<redacted>",
  "strategy_version":"local-context-compaction-v3",
  "summary_length":0,
  "first_kept_index":0,
  "tokens_before":543285,
  "tokens_after":60020,
  "messages_before":1306,
  "messages_after":1
}

Questions

Should compaction also prune or virtualize the persisted transcript / the view layer - or at least notify the client that a compaction boundary was crossed so it can drop the pre-compaction segment from the rendered view?
Could GET /session/{id}/message support cursor-based pagination, so the desktop app does not re-fetch and re-parse the entire transcript on every poll?
Should the compaction attempt be moved off the critical path (async / background)? It can currently block a single turn for over a minute.

Related issues (not duplicates, but adjacent)

[Bug]: Auto-compaction 丢失最新用户诉求并保留过期待办，导致压缩后 Agent 持续漂移 #480 - auto-compaction loses the latest user request. The summary_length: 0 with messages_after: 1 observed here looks like it may share a root cause.
[Bug][macOS] Local projects sidebar stays empty with a large history #483 - sidebar stays empty with a large history (same "large history degrades the desktop UI" family).
[Bug]: 长时间运行后 RSS 与 SQLite 运行时 DB 持续膨胀，retention queue 清理不执行 #496 / [Bug]: Mcode ends up using 100% of available RAM on every turn i use #508 - RSS and disk growth over long runs.
[Bug]: Compaction lineage validation runs after replacing the active history #490 - compaction lineage validation ordering.
[Bug]: SQLite WAL is never checkpointed — clean exit leaves a multi-MB -wal file #505 - WAL never checkpointed.

Secondary observation (independent of this issue)

GET /minimax-desktop/api/v1/file/git/changes was called 1,054 times in one day, 80-90% of them at >=100 ms, peaking at 1,890 ms. On a large repository this keeps git status busy in the background and adds to desktop sluggishness. Reported here only because it showed up in the same log window.

Screenshots

No response

Before submitting

I have searched existing issues.
I have included my version and removed sensitive information.

Thanks for the detailed report and timing measurements. To help us investigate the slowdown in the affected session, could you submit feedback through the feedback option at the top of that conversation? You can also use the feedback option in Settings. Please include diagnostic logs if the feedback flow offers that option, and mention issue #513.

After submitting, please share the feedback reference or log upload ID here, if one is provided, along with the app version you tested. This will help us match the report to the relevant session and investigate the history-loading and compaction delays. Please use the in-app feedback flow for logs rather than posting raw logs publicly here. Thank you!

Session-scoped diagnostics submitted through the in-app feedback flow.

Field	Value
Log upload ID / feedback reference	`MCT-202610-K8DNGC3W`
Upload channel	in-app `上传日志` (Settings -> 关于 -> Upload logs); the same reference appears under `我的反馈`
App version	MiniMax Code Desktop 3.1.4.186 (Windows 11 x64, build 10.0.26300)

Key measurements from the affected session, so the uploaded logs can be cross-referenced directly:

Signal	Value
Compaction event	2026-10-20 14:07:56, `turn_sequence=432`
Compaction duration	`duration_ms=71278.577`, `input_message_count=1306`
Context replacement	`messages_before=1306` -> `messages_after=1`; `tokens_before=543285` -> `tokens_after=60020` (`local-context-compaction-v3`)
Persisted transcript	`messages.jsonl` = 1,045 lines / 3.2 MB (unchanged by compaction)
`GET /minimax-desktop/api/v1/session/{id}/message` (long session)	n=674, avg 104.5 ms, max 716 ms
Same endpoint, short session (137 messages)	n=25, avg 15.5 ms, max 24 ms
`POST /minimax-desktop/api/v1/session/{id}/message/edit`	1.0-1.5 s per call
Session directory	485 MB, incl. 31 `.history-mutation-*` full snapshots

For convenience when grepping the uploaded bundle:

runtime-2026102014.log - contains the compaction event (context_compaction_checkpoint_attempt_settled, duration_ms=71278.577) and the following beforeLlmCall replaced context messages line with the messages_before / messages_after / tokens_before / tokens_after fields.
runtime-2026102015.log - contains the GET /minimax-desktop/api/v1/session/{id}/message request log with per-request durationMs for the affected session, and the file/git/changes polling timings.

The two points raised in the issue title are visible in these numbers: the compaction boundary reduces the model-facing context to a single message while the persisted and rendered transcript keeps all 1,045 entries, and the compaction attempt itself blocks the turn for over a minute.

Follow-up: the uploaded logs let the transcript-loading path be measured more precisely, and there is a structural detail worth adding to the original report.

The active history and the compaction generations are separate layers

history-catalog.json for the affected session:

Generation	Kind	File	`messageCount`	`byteLength`
0	snapshot	`g000000000000--ctx_b77e3274-*.jsonl`	524	6,254,894
1	snapshot	`g000000000001--ctx_46b9347b-*.jsonl`	1,630	6,729,200
2	snapshot	`g000000000002--ctx_ac607a9a-*.jsonl`	480	2,661,329
3	snapshot	`g000000000003--ctx_477814a2-*.jsonl`	1,306	6,543,657
4	active	`messages.jsonl`	1,850	5,352,510

The compaction at 14:07 published generation 3 (1,306 messages), and the LLM call then used a single replacement message: messages_before=1306 -> messages_after=1, tokens_before=543285 -> tokens_after=60020, strategy_version=local-context-compaction-v3.

The active history, generation 4, was not reduced by that. It holds 1,850 messages / 5.35 MB - strictly more than the compacted context - and it is the artifact the client renders and that GET /session/{id}/message serves. The compaction boundary is therefore not visible to the UI, and the rendered transcript keeps every message.

Cost of serving the full transcript

GET /minimax-desktop/api/v1/session/{id}/message for this session, by hour on 2026-10-20:

Hour	Requests	Avg	Max
15:00	4	124.5 ms	149 ms
16:00	32	165.5 ms	716 ms
17:00	54	133.6 ms	251 ms
18:00	19	162.9 ms	197 ms

Against a 137-message session: avg 15.5 ms, max 24 ms.

The endpoint returns the whole transcript, so the response payload and the renderer's parse plus re-render cost grow linearly with history.

The session directory also retains a full copy of the history per generation - 6.25 + 6.73 + 2.66 + 6.54 MB of generation snapshots, plus 34 .history-mutation-* directories - and currently totals 565 MB.

Question added to the original three

Since the client renders the active history while the model consumes a compaction generation, could the client be notified when a compaction boundary is crossed, so it can drop the pre-compaction segment from the rendered view instead of keeping it? That single change would let a long conversation stay responsive without asking the user to start a new session.

Navigation Menu

Repository navigation

[Bug][desktop] Context compaction shrinks the LLM context but not the rendered transcript - the desktop UI keeps degrading for the rest of the session #513

Product or interface

Version

Platform

OS version and architecture

Issue area

Desktop log upload ID (optional)

Steps to reproduce

Expected and actual behavior

Redacted error summary

Questions

Related issues (not duplicates, but adjacent)

Secondary observation (independent of this issue)

Screenshots

Before submitting

The active history and the compaction generations are separate layers

Cost of serving the full transcript

Question added to the original three

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug][desktop] Context compaction shrinks the LLM context but not the rendered transcript - the desktop UI keeps degrading for the rest of the session #513

Description

Product or interface

Version

Platform

OS version and architecture

Issue area

Desktop log upload ID (optional)

Steps to reproduce

Expected and actual behavior

Redacted error summary

Questions

Related issues (not duplicates, but adjacent)

Secondary observation (independent of this issue)

Screenshots

Before submitting

Activity

WebGuHui commented on Oct 20, 2026

noqualia commented on Oct 20, 2026

noqualia commented on Oct 20, 2026

The active history and the compaction generations are separate layers

Cost of serving the full transcript

Question added to the original three

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions