bug(desktop): enabling models one by one can stall Windows Settings → Models #5549

Activity

1. me2seeks

   added

   bugSomething isn't workingSomething isn't working

   on Sep 21, 2026
2. me2seeks commented on Sep 21, 2026

   

   me2seeks

   on Sep 21, 2026

   ContributorAuthor

   More actions

   take
3. github-actions

   assigned

   me2seeks

   on Sep 21, 2026
4. sunrioa commented on Oct 19, 2026

   

   sunrioa

   on Oct 19, 2026

   Contributor

   More actions

   I can reproduce stuttering and dropped model-toggle inputs on macOS too, using the installed desktop app rather than a local source build.

   • Maka: 0.2.1-dev.91.20261018
   • macOS: 26.5.2 (25F84), Apple Silicon
   • Surface: Settings → Models → provider detail

   When I quickly enable or disable several different models, only the first change takes effect, and the page visibly stutters. After the save/refresh finishes, I can operate the other switches again. The clicks made while the page was busy are not replayed.

   I also checked main at 109cb74b82061810d67929bf7b312593c4701d27. The save guard remains active through both the update and the subsequent refresh. An isolated check using the actual settings controller with delayed save/refresh responses passed four cases covering rapid enables, rapid disables, the refresh-phase lock, and recovery after completion. This confirms the dropped-input mechanism, not the cause of the stutter.

   Some measurements from the affected installation:

   • The full catalog contains 4 connections and 516 discovered models.
   • A complete catalog read requires 9 sequential page requests. Four read-only measurements took approximately 44–76 ms each. These are catalog-query timings, not end-to-end toggle timings.
   • In native process sampling around the reproduction, the foreground renderer’s main thread was outside wait states in approximately 90.5% of samples, compared with 0.2% in a later no-interaction capture. These are stack-sample proportions, not CPU-utilization percentages.

   The samples suggest that foreground processing during the interaction deserves further profiling, alongside the repeated catalog refreshes already described here. They do not yet identify the expensive JavaScript function or establish that the reported Windows crash has the same cause. I observed stuttering and ignored inputs in this reproduction, not a process crash.

   简体中文

   我在 macOS 上也复现了页面卡顿和模型开关操作被忽略的问题，使用的是已安装的桌面应用，而不是本地源码构建。

   • Maka：0.2.1-dev.91.20261018
   • macOS：26.5.2（25F84），Apple Silicon
   • 页面：设置 → 模型 → 提供商详情

   快速连续启用或禁用几个不同的模型时，只有第一个修改生效，页面同时出现明显卡顿。等待保存和刷新完成后，其他开关可以继续操作；页面繁忙期间被忽略的点击不会自动补执行。

   我还检查了 main 的 109cb74b82061810d67929bf7b312593c4701d27。保存锁会一直持续到更新及后续刷新完成。使用实际设置页控制逻辑、模拟保存和刷新延迟的隔离验证中，快速启用、快速禁用、刷新期间保持锁定、完成后恢复操作这四项检查均通过。这个验证确认的是点击被忽略的机制，不是卡顿的原因。

   受影响安装环境中的一些测量结果：

   • 完整目录包含 4 个连接、516 个发现的模型。
   • 完整读取目录需要连续请求 9 页。四次只读测量分别耗时约 44–76 毫秒。这是目录查询耗时，不是一次模型切换从开始到结束的总耗时。
   • 复现过程附近的原生进程采样中，前台渲染主线程约 90.5% 的采样点不在等待状态；之后停止操作的对照采样约为 0.2%。这些数字是调用栈采样比例，不是 CPU 占用率。

   除了本 issue 已描述的重复目录刷新，交互期间的前台处理开销也值得进一步分析。目前采样还没有定位到具体耗时的 JavaScript 函数，也不能证明 Windows 上报告的崩溃与此同因。这次复现观察到的是卡顿和操作被忽略，没有观察到进程崩溃。

   👍React with 👍1Reacted by Zhang
5. me2seeks

   added a commit that references this issue on Oct 19, 2026

   fix(desktop): save model selection as a local draft (#6162)

   ...

   6c09ba7
6. sunrioa commented on Oct 19, 2026

   

   sunrioa

   on Oct 19, 2026

   Contributor

   More actions

   Adding some Windows test feedback for #6162. I hope these observations help with further investigation and fixes for this issue.

   The local-draft and explicit Save behavior works in my testing: changes to multiple model switches are retained and saved together, and reopening the connection confirms that the saved selection persists. I did not reproduce the previous first-operation-only behavior.

   Test environment:

   • Windows 11 Home (Chinese), x64, OS version 10.0.26300.
   • Intel Core Ultra 5 225H.
   • Tested commit: 2289ea2b7f1378a0667bc96051a3c682603324cd.
   • Local development build using Electron 43.5.0.
   • Build tools: Node.js 24.18.1, npm 11.19.0.
   • OpenRouter connection with 471 models, configured in an isolated test profile with separate userData and Runtime Host workspace.

   The build and typecheck passed. All 63 targeted tests passed: 37 connection-settings tests and 26 overlay tests, with no failures or skips.

   During manual testing with the full model catalog visible, model switches and the unsaved-changes confirmation felt somewhat slow. After entering a search keyword to reduce the visible list, switching became noticeably smoother; the keyword used in this test was deep.

   Entering the model detail page from the OpenRouter connection card also repeatedly showed an approximately 1–2 second delay. During the latest Windows manual checks, Save caused no obvious UI freeze, and no process crash was observed. Cancelling the unsaved-changes confirmation preserved the draft.

   With Codex-assisted read-only profiling, I captured the interaction from the connection card to the model detail page:

   • Two valid captures recorded renderer main-thread long tasks of approximately 1,135 ms and 1,694 ms, respectively.
   • The detail region contained approximately 10,774 DOM elements.
   • In one Chromium timeline capture, four synchronous Layout events totalled approximately 347 ms, and four style-update events totalled approximately 79 ms. The initiating stacks for the synchronous layouts pointed to readPortalWritingContext in Astryx’s useLayer code.

   These measurements identify a renderer performance hotspot, but do not establish the complete root cause. The captures came from a development build with diagnostic probes, including a previously installed probe that remained active. Timeline recording and React development-mode checks can also add overhead. A clean baseline without those probes, and verification in a packaged production build, are still outstanding.

   I have not isolated a specific CSS selector or mapped these layout events to individual floating-layer instances. These results do not establish that the delay is a regression introduced by #6162, that it is Windows-specific, or that the originally reported crash has been fixed.

   I also reviewed the scope of #6164/#6165: they address the model list’s height limit and scrolling behavior. This Windows test did not include #6165, so its actual effect on the remaining delays still needs verification.

   简体中文

   补充一个针对 #6162 的 Windows 测试反馈，希望这些观察能为这个问题的后续排查和修复提供参考。

   本次测试中，本地草稿和显式保存的行为正常：连续修改多个模型开关后，选择能够保留并一起保存，重新进入连接详情也能确认保存结果仍然存在。没有再次复现此前只有第一个操作生效的问题。

   测试环境：

   • Windows 11 家庭中文版，x64，系统版本 10.0.26300。
   • Intel Core Ultra 5 225H。
   • 测试提交：2289ea2b7f1378a0667bc96051a3c682603324cd。
   • 本地开发版，Electron 43.5.0。
   • 构建工具：Node.js 24.18.1、npm 11.19.0。
   • OpenRouter 连接，共 471 个模型；使用独立隔离的测试配置，userData 和 Runtime Host 工作区均与日常使用环境分开。

   构建和类型检查通过。63 项定向测试全部通过，包括 37 项连接设置测试和 26 项 overlay 测试，无失败、无跳过。

   我在 Windows 上人工测试时，完整显示模型目录的情况下，开关按钮和未保存离开提示的响应稍慢。在模型搜索框输入关键词、缩小显示范围后，切换明显更加流畅；本次使用的关键词为 deep。

   从 OpenRouter 连接卡片进入模型详情页时，也重复观察到约 1–2 秒的响应延迟。最近一轮 Windows 人工检查中，保存没有出现明显的界面卡死，也没有观察到进程崩溃。在未保存离开提示中取消离开后，草稿仍然保留。

   借助 Codex，对“从连接卡片进入模型详情页”这段交互做了只读性能采样：

   • 两次有效采样分别记录到约 1,135 毫秒和 1,694 毫秒的渲染主线程长任务。
   • 详情区域约有 10,774 个 DOM 元素。
   • 一次 Chromium 时间线采样中，4 次同步 Layout 事件合计约 347 毫秒，另外 4 次样式更新事件合计约 79 毫秒。同步布局事件的起始调用栈指向 Astryx useLayer 中的 readPortalWritingContext。

   这些数据定位到了一个渲染性能热点，不代表已经确认完整根因。采样来自带诊断探针的开发构建，其中先前安装的探针仍在运行。时间线记录和 React 开发模式检查也会增加额外开销。无上述探针的干净基线对照，以及 production 打包版验证仍未完成。

   目前还没有隔离出具体 CSS 选择器，也没有将这些布局事件对应到具体浮层实例。这些结果不能证明它们是 #6162 引入的回归、Windows 独有的问题，或最初报告的崩溃已经修复。

   我也查看了 #6164/#6165 的范围：它们处理模型列表的高度限制和滚动体验。本轮 Windows 测试没有包含 #6165，因此它对上述延迟的实际影响仍需验证。