[App反馈][IOS] Clarify and improve context compression and context window management

[Minazuki-Banki]

反馈类型

• 功能建议（Feature）

详细描述

Please improve the context-management feature and documentation in ETOS LLM Studio. The current UI exposes Context Window Count and Lazy Loading Rounds, but their relationship to model context limits and context compression is unclear. Please consider: (1) clearly documenting the difference between Context Window Count, Lazy Loading Rounds, model context length, and maximum output tokens; (2) adding an explicit automatic context-compression/summarization option, with configurable trigger threshold and retention policy; (3) indicating whether older messages are summarized, truncated, or merely loaded on demand; (4) displaying current context/token usage and warning before the model context limit is reached; (5) providing recommended values for different model types; and (6) clarifying the performance and memory implications of setting both values to 0.

可复现步骤

1. Open ETOS LLM Studio 1.7.0 (Build 372) on iOS. 2. Open Settings. 3. Open Preferences. 4. Scroll to Context Window Management. 5. Observe Context Window Count and Lazy Loading Rounds, both set to 0, and the brief explanatory text. 6. Try to determine how automatic context compression or summarization is configured.

预期行为

Users should be able to understand and configure how long conversations are loaded and compressed, know when compression or truncation occurs, and see clear warnings or usage information before reaching the model's context limit.

实际行为

In ETOS LLM Studio 1.7.0 (Build 372), Settings > Preferences > Context Window Management shows only two options: Context Window Count and Lazy Loading Rounds. Both are currently set to 0. The description says that 0 loads all conversation history, but the UI does not explain whether these settings are related to token limits, automatic summarization, truncation, or context compression. I could not find a clear, dedicated context-compression setting or documentation in the app.

补充信息

App: ETOS LLM Studio; Version: 1.7.0 (Build 372); Git commit shown in About: c4090fd; Developer: Eric-Terminal; Platform: iOS/watchOS. Relevant UI path shown in screenshots: Settings > Preferences > Context Window Management. Current values: Context Window Count = 0; Lazy Loading Rounds = 0. The About page links to the project at github.com/Eric-Terminal/ETOS-LLM-Studio and documentation at docs.els.ericterminal.com. This is a feature/documentation suggestion rather than a report of a crash.

环境信息

• 平台: ios
• App 版本: 1.7.0 (Build 372)
• Git 提交: c4090fd
• 分发通道: App Store
• 系统版本: Version 26.5 (Build 23F77)
• 设备型号: iPhone17,2
• 语言: zh-Hans_HK
• 时区: Asia/Hong_Kong

最小诊断日志

• timestamp=2026-07-13T04:11:48Z
• provider_count=2
• session_count=10
• platform=iOS
• distribution_channel=appStore
• app_version=1.7.0(372)

服务端附注

• 来源: source/app-feedback
• 同步标记: 由用户提出自动更新的
• 客户端IP哈希: 1484711a5ebe730a77401e48ce33909abaa282b4b17dbb6c2a61b5c28bd37308

[Eric-Terminal]

Thank you for your very detailed feedback. Regarding the suggestions in your feedback, such as adding a context compression feature, I will implement these recently. In order for you to get the latest features, you can join the TestFlight test:

https://testflight.apple.com/join/d4PgF4CK

That lazy loading rounds is actually on the UI level, in order to solve the problem of long conversations rendering being very laggy. Then the context window is what truncates and sends according to the conversation rounds.

Because I didn't expect that daily chatting could still have situations that hit the context window (because the context window of current LLMs is already very hard to reach).

[PsYcGoD]

Been wrestling with this on iOS too. Here's what I landed on after a lot of trial and error:

1. Compress tool outputs aggressively - most shell command output is 90%+ compressible. A 50KB npm install log becomes 200 bytes ("installed 847 packages in 12s, 0 vulnerabilities").

2. Track token usage per-turn - I log input/output tokens for every exchange. Helps identify which operations are expensive. Discovered that reading large files was eating 40% of my context budget.

3. Sliding window with anchors - keep the first message (original task) and last N messages, but also "anchor" any message containing a decision or file path. This prevents losing critical context while staying under limit.

4. Budget alerts - warn at 60% and 80% context usage so the user can checkpoint or summarize before hitting the wall.

The key realization: compression should happen at the tool output layer, not after it's already in context. Once it's in the conversation, you're paying for it.

[Eric-Terminal]

I pushed the Compact feature to the new version of TestFlight. You can try it out and see how it works.

[Minazuki-Banki]

Hi Eric, I joined the TestFlight and tested the new conversation compression feature. Thank you for implementing it so quickly.

I understand that compression creates a condensed version of the current conversation and continues it in a new chat. The approach itself is reasonable, but splitting one ongoing task across multiple chats can make conversation management harder.

Although there is an option to trace a compressed conversation back to its source, the relationship is not very discoverable in the current UI. It can be difficult to tell which chat is the original, which is the compressed continuation, and where the full history is located.

It may help to show a clear “Continued from / Compressed into” link or badge in both conversations, group related sessions together in the history list, and provide a prominent one-tap way to open the complete original conversation.

I would also suggest adding an Archive entry or section for managing older sessions. Users could archive completed or older conversation branches, then sort or filter them by last updated time, creation date, or compression relationship. This would make long-running conversations easier to manage, while keeping the active chat list clean and making the context structure more intuitive.

I think these improvements would preserve the benefits of compression while making a long-running task feel like one continuous thread rather than several separate chats.