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

Start by tracing the desktop session message endpoint and transcript rendering, then follow the runtime’s context compaction path and its checkpoint logs. The issue gives no source files or tests, so first locate those entry points and reproduce with a long tool-heavy session. Done when the transcript view and message fetching avoid the reported degradation after compaction and the turn no longer blocks for over a minute.

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

1. 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).
2. Let the session cross the automatic context-compaction threshold.
3. 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

1. 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?
2. 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?
3. 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)

• #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.
• #483 - sidebar stays empty with a large history (same "large history degrades the desktop UI" family).
• #496 / #508 - RSS and disk growth over long runs.
• #490 - compaction lineage validation ordering.
• #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.