[Bug][desktop] Context compaction shrinks the LLM context but not the rendered transcript - the desktop UI keeps degrading for the rest of the session
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 35/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- typescript
- Bereich
- backend, desktop, performance
Rechercherichtung
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.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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/v2in 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}/messagesupport 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)
- #480 - auto-compaction loses the latest user request. The
summary_length: 0withmessages_after: 1observed 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.
- Vorherrschende Sprache
- TypeScript
- Sterne
- 2k
- Forks
- 259
- Ø Merge
- 9 Std. 22 Min.
- Gemergte PRs (30 T.)
- 105
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus MiniMax-AI/minimax-code
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
MiniMax-AI/minimax-code#507 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug needs-triage tui
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
MiniMax-AI/minimax-code#481 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug cli documentation needs-triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
MiniMax-AI/minimax-code#299 · 3 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 15/100
MiniMax-AI/minimax-code#521 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 30/100
MiniMax-AI/minimax-code#520 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in MiniMax-AI/minimax-code
Ähnliche Issues
-
frontend
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 86/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
ranxianglei/billion-context#4172 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
awslabs/threat-composer#362 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Area/Cloud Needs Triage Type/Bug
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 86/100
wso2/product-integrator#2847 ·
Maintainer antworten meist innerhalb von 1 Tag