Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[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 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
backend, desktop, performance

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

desktop
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.
主要言語
TypeScript
スター
2k
フォーク
259
平均マージ
9時間 22分
マージ済み PR（30日）
105

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

MiniMax-AI/minimax-code のほかの issue

MiniMax-AI/minimax-code の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。