[DISCUSS] Rust execution and GPUI desktop rewrite

[Astro-Han]

I'd like to discuss Rust execution work by @M4n5ter and GPUI desktop work by @UncertaintyDeterminesYou4ndMe , aiming for lower memory and battery use and faster, cheaper task completion.

Boundary and performance

Keep Runtime Host as the execution authority and its existing protocol as the shared contract. GPUI can connect to the current Host; the Rust implementation can serve the current client. The rewrites can progress independently.

Compare the same workloads, with the same model and settings for execution:

• Execution: task completion rate, cost, elapsed time and memory.
• Desktop: memory, responsiveness and battery use during long conversations, streaming and idle operation.

Questions for discussion

1. What is the current status of each rewrite (branch/PR and what already works), and which part do you plan to replace first?
2. Which old paths can be removed as replacements land, and how should existing Session data and ongoing work carry over?
3. Which Host and client plugin capabilities need to carry over? PR #6004 is a concrete reference, with proactive checks and task delegation built through plugin interfaces.

Always-on Bot harness (#6076) covers the continuing-work and interaction model. This discussion covers implementation and performance. Host lifecycle changes remain a separate decision.

---

中文版（点击展开）

我想讨论 M4n5ter 的 Rust 执行端重写和 U4DYM 的 GPUI 桌面端重写，目标是更少的内存、更低的耗电，以及更快、更低成本地完成任务。

边界与性能

Runtime Host 仍是执行权威，以现有 Host 协议为共同契约。GPUI 可以连接当前 Host，Rust 实现也可以服务当前客户端，两边分别推进。

使用同样的工作负载比较，执行端保持相同模型和配置：

• 执行端：任务完成率、成本、耗时和内存。
• 桌面端：长对话、持续输出和空闲时的内存、响应和耗电。

想讨论的问题

1. 两个重写当前进展如何（分支／PR、已跑通的部分），各自打算先替换哪部分？
2. 替换完成后，哪些旧路径可以删除？已有 Session 数据和进行中的工作怎样继续使用？
3. 哪些 Host 和客户端插件能力需要承接？PR #6004通过插件接口实现主动检查和任务委派，可以作为具体参考。

Always-on Bot harness（#6076）讨论持续工作和交互方式。本篇讨论实现和性能，Host 生命周期改变仍需单独定案。

[Astro-Han]

@M4n5ter @UncertaintyDeterminesYou4ndMe I’d love to try the Rust Host and GPUI together for daily work.

How close do you think the two branches are to a first usable build—something that can run real tasks and continue existing work after a restart? Do you have a rough timeframe in mind?

What are the main things still to connect or work through? I’d be happy to help where I can.

中文版（点击展开）

@M4n5ter @UncertaintyDeterminesYou4ndMe，想早点试试 Rust Host + GPUI 一起跑日常工作。

你们觉得两个分支离第一个可日用的联合版本还有多远，大概什么时候能试上？能跑真实任务、重启后继续已有工作就很好。

现在主要还有哪些地方需要接起来，或者有什么卡点？也想看看有没有我能帮上忙的地方。

[M4n5ter]

English

Thanks for bringing this up! An update from the Rust side: the foundational work is already in place on rust-preview, and most of the core TUI functionality is already usable. The main remaining gap is the desktop implementation and its integration with this branch.

One important clarification to the original post: rust-preview is no longer compatible with main. We should not assume that the existing Host protocol remains an unchanged shared contract, or that the current clients and the Rust Host are interchangeable. A desktop implementation targeting rust-preview needs to integrate with that branch’s interfaces. Carrying over existing Sessions and in-progress work from main is also a separate migration question, rather than something we can assume will work seamlessly.

@UncertaintyDeterminesYou4ndMe, I’d prefer for you to lead the GPUI desktop design and implementation. An agent-assisted walkthrough of rust-preview should help you get familiar with the current architecture fairly quickly. From there, you can shape the desktop design and see whether the current interfaces fit its needs. If you find gaps or architectural decisions that get in the way, let’s discuss them—the current design is not something the desktop has to work around at all costs.

At this early stage, I think it’s better to keep the desktop design and implementation under one clear lead, rather than split the work across more contributors before the direction has taken shape. That should help keep the design coherent and avoid unnecessary coordination overhead and conflicting changes.

中文版

感谢发起讨论！更新一下 Rust 侧的进展：rust-preview 上的基础工作已经完成，TUI 的主要功能也已经可用了。目前主要缺口是 desktop 实现，以及它与该分支的集成。

需要澄清原帖中的一个重要前提：rust-preview 与 main 已经不兼容。 不能假设现有 Host 协议可以保持不变地作为共同契约，也不能假设当前客户端与 Rust Host 可以直接互换使用。面向 rust-preview 的 desktop 实现，需要对接该分支的接口。如何承接 main 的已有 Session 和进行中的工作，也是需要单独讨论的迁移问题，不能默认能够无缝衔接。

@UncertaintyDeterminesYou4ndMe，我更倾向于由你主导 GPUI desktop 的设计和实现。借助 agent 梳理一下 rust-preview，应该能比较快地了解当前架构，然后由你来规划 desktop 的设计，并判断现有接口是否满足需求。如果发现能力缺失，或者某些架构设计妨碍了 desktop 实现，我们可以一起讨论调整，不需要把当前设计当成 desktop 必须迁就的固定前提。

在这个早期阶段，我觉得更适合先由你集中主导设计和实现，而不是在方向尚未成形之前就拆给更多人并行参与。这样更容易保持设计的一致性，也能减少不必要的沟通成本和修改冲突。

[UncertaintyDeterminesYou4ndMe]

English

Thanks, @M4n5ter. I'm happy to lead the desktop. I went through rust-preview (at ae6c7304f) with agents; here is where I've landed.

What fits. The Host services cover most of what a desktop needs: the Agent service (history with cursors, watch, send and stop, the queue, pending interactions, attachments), Settings, skills and the plugin manager. The views of the GPUI client I've been building against main (feat/desktop-gpui-shell: the conversation with find, the workbar, the terminal, settings) can move over; their data layer has to be rewritten against these services.

What gets in the way. Today the desktop draws the same TypeScript scenes as the TUI. Every callback sends the component's whole JSON state through the UI worker and back; the scene vocabulary has no virtualized list, menus, tabs, splitters, tooltips or theming; and native components only render what they are given, so they cannot fetch their own data. That works for sharing one view between the TUI and the desktop, but long streaming conversations, a colored terminal and a diff view need native components that own their data.

What I'd like to discuss first:

1. Let the desktop's native components subscribe to and call Host services directly, within the grants their composition gives them. The transcript, composer, workbar and terminal would be native components placed by the composition; plugin pages (settings pages, the plugin manager, third-party panels) stay on JS scenes. This changes the ui-runtime rule that native components only render.
2. The Host's lifetime and the Root lease. The Host is a child of the desktop process and the desktop holds the Root exclusively, so as far as I can tell from the code, work stops when the window closes, and the TUI and the desktop cannot share a Root. Should the desktop attach to a long-lived Host instead, such as the public Host? The original post leaves the Host lifecycle as a separate decision; I raise it here because it decides the desktop's process model.

Smaller items I'll bring with the design: structured error codes instead of strings; serving the terminal's raw byte stream, which exists but is not exposed, so the desktop can render it with alacritty; and services the desktop needs that don't exist yet (git status and diff for a changes view, file listing and watching, a context breakdown, forking a session for side chats, whole-word and case-insensitive search).

Next I'll build and run maka desktop on a scratch Root to see where it stands, then write up a design proposal with a phased plan. @Astro-Han, I can give a realistic timeframe once that proposal is up.

中文版

谢谢 @M4n5ter，我来主导 desktop。我借助 agent 梳理了 rust-preview（ae6c7304f），结论如下。

能直接用的。 Host 服务基本覆盖了 desktop 的需要：Agent 服务（带游标分页的历史、watch、发送和停止、队列、待处理的交互、附件）、Settings、skills 和插件管理器。我在 main 上做的 GPUI 客户端（feat/desktop-gpui-shell：带查找的对话、工作栏、终端、设置）的视图层可以搬过来，数据层要按这些服务重写。

妨碍 desktop 的。 现在 desktop 画的是和 TUI 共用的 TypeScript scene。每次回调都要把组件的整份 JSON state 经 UI worker 来回传一遍；scene 词汇里没有虚拟列表、菜单、tab、分栏、tooltip 和主题；原生组件只渲染传进来的数据，不能自己取数据。这适合让 TUI 和 desktop 共用一份视图，但长对话的流式输出、彩色终端和 diff 视图都需要自己持有数据的原生组件。

想先讨论的两件事：

1. 允许 desktop 的原生组件在组合授予的权限内直接订阅和调用 Host 服务。对话、composer、工作栏、终端作为原生组件，由组合放置；插件页面（设置页、插件管理器、第三方面板）继续用 JS scene。这会改变 ui-runtime 里"原生组件只负责渲染"这条规则。
2. Host 的生命周期和 Root 租约。Host 是 desktop 进程的子进程，Root 由 desktop 独占，所以按代码推断，关掉窗口工作就停了，TUI 和 desktop 也不能共用一个 Root。desktop 是否应该改连一个常驻的 Host，比如公开 Host？原帖把 Host 生命周期留作单独决定；我在这里提出来，是因为它决定了 desktop 的进程模型。

几个小一些的问题会随设计一起提：错误改用结构化的错误码；把终端已有但没有对外提供的原始字节流暴露出来，让 desktop 用 alacritty 渲染；补上 desktop 需要但还没有的服务（Changes 视图用的 git status 和 diff、文件列表和监听、上下文构成、为 side chat 分叉会话、全字匹配和不区分大小写的搜索）。

接下来我会在临时 Root 上构建并运行 maka desktop，看清现状，然后写一份带分阶段计划的设计提案。@Astro-Han，时间上等提案出来后我能给出比较实际的估计。

[M4n5ter]

@UncertaintyDeterminesYou4ndMe

English

Thanks—these are valuable observations, and exactly the boundaries we should discuss now.

To clarify the intent behind the current architecture: we are exploring how to combine Rust and native performance with a highly flexible, programmable UI, so users can create entirely new products by writing and composing plugins. The current JS components, native capabilities and composition model are attempts toward that goal. Their state, scene and execution boundaries remain open to redesign; they are not fixed constraints that Desktop must accommodate.

On the first point, I agree that whole-state round trips, gaps in the presentation API and high-frequency data paths deserve attention. I also support components calling and subscribing to Host services within their composition grants. However, I would like us to evaluate the implementation boundaries before deciding that the transcript, composer, workbar and other core product views should all be implemented in Rust. Users should be able to change those interactions through plugins, or replace the entire product—not merely arrange a fixed set of compiled components.

gpui-shell is worth including in this discussion. It lets scripts retain View state and define presentation and application behavior, while Rust supplies native state, layout and rendering. We can evaluate using it directly or adopting the parts of its design that fit Maka. Its threading model, update granularity and plugin execution costs still need validation against our workloads.

Implementation complexity should not deter us from a better architecture. If achieving both performance and flexibility requires changing existing interfaces, state ownership or the runtime, we should be willing to do that. TUI and Desktop can share contracts, composition mechanisms and suitable application logic while each uses its own presentation capabilities fully. They do not need identical UI representations.

On the second point, I agree that this is a capability gap we should close. The Host should have a lifecycle independent of any window, and both TUI and Desktop should be able to connect to the same Host and access the same business state. Closing a window or disconnecting a client should not implicitly stop background work already accepted by the Host. Closing the UI, stopping a task and stopping the Host need distinct semantics. Exclusive ownership of the business Root should remain with that Host; allowing multiple processes to write the same Root is not the solution.

We already have foundations for an independently running Host, but the frontend connection, caller-state and shutdown paths are not fully integrated with it. I will work on closing that gap on the Host side. The Desktop design can target an independent Host with multiple clients.

Please continue leading the Desktop proposal. We should validate performance with real long conversations, streaming output, terminals and diffs, while also demonstrating that a third party can build a complete product with a different workflow without modifying Maka’s native code. Both are necessary to meet the goal of this architecture.

中文版

谢谢，这些反馈很有价值，也正是现在需要一起讨论的边界。

先说明一下当前架构的出发点：我们正在探索如何在使用 Rust、获得原生性能的同时，保留极高的 UI 灵活度，让用户通过编写和组合插件创造全新的产品。 当前的 JS 组件、原生能力和组合机制都是围绕这个目标的尝试，具体的 state、scene 和执行边界仍然可以重新设计，不是 Desktop 必须迁就的固定约束。

关于第一点，我认同你指出的整份 state 往返、展示能力不足和高频数据路径的问题，也支持组件在组合授予的权限内直接调用和订阅 Host 服务。但我希望我们一起评估具体的实现边界，不提前把 transcript、composer、workbar 等核心业务界面全部确定为 Rust 实现。用户应当能够用插件改变这些交互，甚至替换整个产品，而不只是排列几个官方编译好的组件。

gpui-shell 值得纳入这个设计讨论。它让脚本保留 View 状态、定义界面和业务行为，同时由 Rust 提供原生状态、布局和渲染能力。我们可以评估直接采用它，也可以借鉴其中适合 Maka 的设计；它的线程模型、更新粒度和插件执行成本仍需要结合实际负载验证。

我们不需要因为实现复杂度而回避更好的架构。 如果要同时实现性能和自由度，需要调整现有接口、状态所有权或运行时，就可以大胆改。TUI 和 Desktop 可以共享契约、组合机制及适合共享的业务逻辑，各自充分发挥展示能力，不要求使用完全相同的 UI 表达。

关于第二点，我同意这是需要补齐的能力。Host 应当具有独立于窗口的生命周期，TUI 和 Desktop 都能够连接同一个 Host，访问同一份业务状态。 关闭窗口或断开客户端，不应默认停止 Host 已接受的后台工作；显式停止任务、停止 Host 和关闭界面需要区分。业务 Root 的唯一所有权应保留在负责它的 Host，不能通过放松租约、让多个进程直接写同一个 Root 来解决。

目前已有独立 Host 的基础，但前端的连接、调用方状态和退出清理还没有完整接到这条路径上。这部分我会在 Host 侧推进补齐，Desktop 的设计可以把独立 Host 和多客户端接入作为目标。

你可以继续主导 Desktop 提案。希望我们用真实的长对话、持续输出、终端和 diff 场景验证性能，同时验证第三方能否在不修改 Maka 原生代码的情况下，构建一个不同工作流的完整产品。两方面都成立，才算达到了这次架构探索的目标。

[UncertaintyDeterminesYou4ndMe]

@M4n5ter

English

Thanks, that clarifies the goal. I've moved away from "core views in Rust": the measurements below suggest the transcript itself can be a script, as long as the heavy pieces it uses (virtualized list, markdown, diff, terminal) are native components that own their data.

I ran a first gpui-shell spike (gpui-kit main at 1a01f925, release build, Apple M4, 120 Hz, so the frame budget is 8.3 ms). It used fake data and no Host, which keeps the UI runtime's cost separate from the services'.

Transcript as a script. The script uses MessageScroller and Message/Bubble/Marker, with TextView.markdown for each message. It streams one answer at 50 tokens/s, then scrolls back fast through the history.

	Frame mean (phase average)	Worst P95	Script per update
2,000 messages, streaming	2.0 ms	≤ 4.0 ms	0.1–0.2 ms per token
10,000 messages, answer grows to 38 KB	2.2 ms	≤ 4.8 ms	about 0.16 ms per token
10,000 messages, scroll through all of them	4.0 ms	≤ 7.7 ms	about 6 row callbacks per frame

Making each message its own view halves the per-token script cost. The trade-off is fast scrolling: about 4.6 ms per frame, with P95 up to 9.3 ms (over budget), because each row that comes into view renders for the first time. Memory for 10k messages is about 140 MB after loading and levels off around 300 MB after scrolling the whole history.

Diff and terminal as native components.

• A 43,868-line, 411-file patch from rust-preview loads into the native Diff in 16 ms and draws in under 1 ms per frame.
• For the terminal, I wrote a small embedding host that registers a Terminal component (alacritty_terminal with a local PTY), which a script imports from a host module. With seq 1 3000000 it holds 120 fps at 0.2–0.4 ms per frame, with zero script renders and zero script calls from frames. Keyboard focus and key handling work for a native element inside the script tree.

Neither involves script on the hot path.

Plugin execution cost is the open question. gpui-shell runs QuickJS on the UI thread, with no worker. I ran the same pure-JS module under both engines over 10,000 messages (5.9 MB). QuickJS (release, with its JIT tier on) is 2–27× slower than V8:

• a whole-word, case-insensitive regex over every message: 27 ms vs 1 ms;
• finding every match: 55 ms vs 3 ms;
• JSON.stringify: 27 ms vs 3 ms;
• building a block/line model: 86 ms vs 26 ms.

On the UI thread, a 27–55 ms task drops 3–7 frames. Describing UI is cheap, so this does not matter for views. It does matter for plugins that compute. My proposal is a rule for desktop UI scripts: they describe views, handle events and call services. Search, indexing, transforms and anything else over the whole history go to Host services or Host-side plugins, and the Desktop calls them asynchronously. A third party's product would then put its logic in Host plugins and its interface in desktop scripts. Does that boundary fit what you have in mind for "a complete product without modifying Maka's native code"?

What gpui-shell is missing for an embedding host. I'd raise these with its maintainers and can send PRs:

• A runtime takes a single component catalog. A host cannot add its own module beside gpui-component, and the built-in catalog is returned already frozen, so it cannot be extended. Export names must also be unique across all components.
• The generated typings always declare "gpui-component".
• Scripts cannot release retained state, so a closed terminal keeps its PTY until reload.
• MessageScrollerState has no script methods, so a script cannot append rows. I patched this locally.
• The root's focus-cycling bindings take Tab before a native element's key listeners see it.

I worked around all of these with small local hooks; none blocked the spike.

Next.

1. Real data: a host module that exposes the Agent service (history pages, watch, send/stop, pending interactions) to scripts, run against real long sessions. This will target the independent Host once your side lands.
2. A small third-party product with a different workflow, built from scripts only.
3. Then the design proposal with phases.

Side note on the current maka desktop at ae6c7304f: it exits at startup with mount has no committed frame. Since 1a66d8fb6, run() still reads application.frame(&mount); falling back to prepared_frame fixes it. After that, text in the scenes collapses to one character per line, in both zh-CN and English. I haven't pursued these further, given the direction; details on request.

中文版

谢谢，目标清楚了。我不再坚持"核心界面用 Rust 写"：下面的数据说明，对话界面本身可以是脚本，只要它用到的重型部件（虚拟列表、markdown、diff、终端）是自己持有数据的原生组件。

我先做了一轮 gpui-shell 验证（gpui-kit main 1a01f925，release 构建，Apple M4，120 Hz，所以每帧预算 8.3 ms）。用的是假数据，不接 Host，这样能把 UI 运行时的开销和服务的开销分开看。

对话界面用脚本写。 脚本用 MessageScroller 和 Message/Bubble/Marker，每条消息用 TextView.markdown。先以 50 token/s 流式输出一条回答，再快速滚回历史。

	每帧均值（整段平均）	最差 P95	每次更新的脚本开销
2000 条消息，流式输出	2.0 ms	≤ 4.0 ms	每 token 0.1–0.2 ms
1 万条消息，回答增长到 38 KB	2.2 ms	≤ 4.8 ms	每 token 约 0.16 ms
1 万条消息，从头滚到尾	4.0 ms	≤ 7.7 ms	每帧约 6 次行回调

每条消息做成独立 view，每 token 的脚本开销能减半。代价在快速滚动：每帧约 4.6 ms，P95 最高 9.3 ms（超出预算），因为每条进入视口的行都要做第一次渲染。1 万条消息加载后内存约 140 MB，滚完全部历史后稳定在 300 MB 左右。

diff 和终端用原生组件。

• rust-preview 的一份 43868 行、411 个文件的真实 patch，交给原生 Diff，加载 16 ms，每帧不到 1 ms。
• 终端方面，我写了一个最小的嵌入宿主，注册 Terminal 组件（alacritty_terminal + 本地 PTY），脚本从宿主模块 import 它。跑 seq 1 3000000 时稳定 120 fps，每帧 0.2–0.4 ms，脚本渲染次数和帧内脚本调用都是 0。原生元素放在脚本树里，键盘焦点和按键处理都正常。

两者的热路径上都没有脚本参与。

没解决的是插件执行成本。 gpui-shell 的 QuickJS 跑在 UI 线程上，没有 worker。我用同一段纯 JS 模块在两个引擎上跑 1 万条消息（5.9 MB）。QuickJS（release，JIT 层已开启）比 V8 慢 2–27 倍：

• 对所有消息做全字匹配、不区分大小写的正则：27 ms 对 1 ms；
• 找出全部匹配：55 ms 对 3 ms；
• JSON.stringify：27 ms 对 3 ms；
• 构建块/行模型：86 ms 对 26 ms。

在 UI 线程上，27–55 ms 的任务会掉 3–7 帧。描述界面很便宜，所以这对视图没有影响，但对要做计算的插件有影响。我的提议是给 desktop 的 UI 脚本定一条规则：它们只负责描述视图、处理事件、调用服务。搜索、索引、转换以及其他针对全部历史的计算，都放到 Host 服务或 Host 侧插件里，Desktop 异步调用。这样第三方的产品就是：逻辑写在 Host 插件里，界面写在 desktop 脚本里。这条边界符合你说的"不修改 Maka 原生代码就能构建完整产品"吗？

嵌入宿主还缺什么。 这些我会和 gpui-shell 的维护者提，可以提 PR：

• 一个运行时只接收一份组件目录。宿主没法在 gpui-component 旁边加自己的模块，内置目录拿到时已经冻结，也没法扩展。导出名还必须在所有组件里唯一。
• 生成的类型声明固定写成 "gpui-component"。
• 脚本不能释放保留的 state，所以关掉的终端会一直占着 PTY，直到重新加载。
• MessageScrollerState 没有暴露给脚本的方法，脚本没法追加行。我在本地补上了。
• 根视图的焦点切换绑定会在原生元素的按键监听之前拿走 Tab。

这些我都用本地的小改动绕过了，没有一个卡住验证。

接下来：

1. 接真实数据：写一个宿主模块，把 Agent 服务（历史分页、watch、发送和停止、待处理的交互）暴露给脚本，用真实的长会话测。等你那边的独立 Host 落地后就接上去。
2. 只用脚本做一个工作流不同的第三方小产品。
3. 然后写带分阶段计划的设计提案。

另外，当前 ae6c7304f 的 maka desktop 一启动就退出，报 mount has no committed frame。1a66d8fb6 之后 run() 仍然读 application.frame(&mount)，回退到 prepared_frame 就能修好。修好后，scene 里的文字会被压成每行一个字，中英文界面都这样。考虑到方向在变，我没有继续追，需要的话我可以补充细节。

[M4n5ter]

English

This boundary fits what I have in mind. The Rust architecture is also exploring how to combine native performance with a highly programmable UI. Building a complete product through Host plugins and desktop scripts matches that goal.

UI scripts can own view state and interaction behavior, while shared business state, continuing tasks, and expensive operations over the full dataset belong in Host services or Host-side plugins. Native components handle the high-frequency rendering and interaction paths. Your measurements give us a useful basis for pursuing this direction.

The next steps you outlined make sense: connect real Host data, test long sessions, and build a third-party product with a different workflow. That product would be particularly useful if it defines its own Host services as well as its interface. Together, these should give us the evidence needed for the design proposal.

I’ll address the independent Host lifecycle and shared TUI/Desktop access on the Rust side soon. This shouldn’t hold up the UI work: the UI runtime, native components, and product prototypes can move forward in parallel. We can coordinate any service-interface needs along the way, then validate shared connections and task continuity once the Host lifecycle work lands.

The embedding gaps you identified also look like reasonable upstream work. We can vendor a patched copy under third-party/ and periodically sync with upstream while the patches are pending. As those fixes land upstream, we can drop the corresponding local patches. Upstream merge timing shouldn’t block desktop development.

Regarding the current desktop: it is an early proof of concept I wrote and did not continue maintaining. It is currently completely unusable, so the startup and layout problems you found are consistent with its state. There is no need to make repairing that prototype a prerequisite for the new desktop design.

中文版

这条边界符合我的预期。Rust 侧的架构本身也在探索如何结合原生性能与高度可编程的 UI。通过 Host 插件和 desktop 脚本构建完整产品，符合这个目标。

UI 脚本可以拥有视图状态和交互行为；共享业务状态、持续任务，以及针对完整数据集的重计算，由 Host 服务或 Host 侧插件承担。原生组件负责高频渲染和交互路径。你这轮测量为继续探索这个方向提供了有用的依据。

你提出的下一步很合理：接入真实 Host 数据、测试长会话，再构建一个工作流不同的第三方产品。如果这个产品同时定义自己的 Host 服务和界面，会更有验证价值。这些结果可以作为设计提案的依据。

我近期会补齐 Rust 侧的独立 Host 生命周期，以及 TUI/Desktop 共享接入。这不应该阻塞 UI 侧的开发：UI 运行时、原生组件和产品原型可以并行推进。过程中需要哪些服务接口，我们可以随时对齐；Host 生命周期落地后，再验证多客户端共享接入和任务持续运行。

你列出的嵌入能力缺口，也适合作为上游改进推进。我们可以先在 third-party/ 下 vendor 打过补丁的源码，在补丁合并前定期同步上游；上游接纳后，再移除对应的本地补丁。Desktop 开发不需要等待上游合并。

关于当前 desktop：那是我早期写的概念验证代码，之后没有继续维护，目前确实完全不可用。你发现的启动和布局问题符合它的现状，不需要把修复这套原型作为新 desktop 设计的前置条件。

[UncertaintyDeterminesYou4ndMe]

@M4n5ter

English

Progress on the desktop, and one Host performance problem that long sessions run into.

Desktop on the independent Host. On a local branch of rust-preview (not pushed yet):

• gpui-shell is vendored under third-party/gpui-kit/crates/shell, following the convention for Base: upstream.json hashes and a SOURCE.md section. The patches are limited to Base API adaptation plus two development switches. The gpui-component catalog is left out, because at c5f8eca it does not build against the adapted Base. The desktop uses the bare runtime and registers its own components.
• The desktop exposes one generic module to scripts, maka-host, with query, mutate, subscribe, next and close. It runs over an owned Client session. I chose a generic bridge over Agent-specific functions so that a third-party product can call its own Host services without native code. The Host's endpoint grants still bound what a script can reach.
• The session list, transcript (history pages at a fixed through fence, watch from nextAfter, deltas into a live row, reconciliation on transcript_changed/ended) and composer (send/stop) are plain JavaScript and mirror the TUI's agent-screen logic. Against a dev Host with a 1,000-turn session (2,100 rows):
  • First tail page: 376–403 ms.
  • All 23 older pages: about 7.7 s.
  • A streamed reply: first delta 252 ms after send.
  • Stop: about 65 ms.
  • While a reply streams, each script render takes 1.4 ms on average and 5.3 ms at worst. That is 286 renders, in a debug build.
• Script-runtime gaps found while doing this (list position lost when items change, no tail-follow, no visible-range callback, no submit-on-Enter) are going to gpui-kit as PRs.

Turn time grows with session length. Seeding that session through agent.send with a fake model, one turn at a time, turn time rose from 63 ms at turn 20 to about 14 s near turn 1,000. CPU was in SQLite parsing JSON on the writer connection.

The cause is prepare_prune_candidates, which runs at the start of every Run and after each tool batch (plugins/agent/engine/src/runner.rs:175, steps.rs:308). It does three slow things:

1. The scan can't use its index. The query's NOT EXISTS (platform/event-log/src/archive/candidates.rs:102) compares json_extract(a.event_json,'$.fact.placeholder.identity.runtime_event_id') without the CAST(... AS TEXT) that the partial index archived_tool_result (migrations/0001_runtime.sql:348) is built on. So for every candidate, SQLite walks every event of the session and parses its JSON. context/tail.rs:45 already uses the CAST form.
2. It re-checks old results on every turn. Each LIMIT 1 step re-evaluates the remaining candidates with a temp B-tree sort. Results too small to archive are never recorded as checked, so every turn re-checks every tool result since the last compaction.
3. target::read scans the whole database on every call. Its accepted_calls CTE (model_items.rs) is materialized over the whole event_log.

Together this is roughly k²·n per turn, where k is the number of tool results since compaction and n is the number of session events. At 1,000 turns (about 20.8k events, 50 tool results), the release build spends 10.0–12.5 s of a 13.4–16.7 s turn in this scan. A history read meanwhile waits behind it on the same connection, and I saw a 24 s first page while seeding.

Measured on copies of that database (scan plus target reads per turn):

	250 turns	500	740	1,000
Current	0.19 s	1.0 s	3.5 s	11.2 s
A + B	35 ms	134 ms	345 ms	774 ms
A + B + C	1.5 ms	2.8 ms	5.2 ms	9.8 ms

• A: add the CAST(... AS TEXT) at candidates.rs:102, so the plan uses archived_tool_result.
• B: in target::read, restrict accepted_calls to the target's invocation: LEFT JOIN (SELECT * FROM accepted_calls WHERE invocation_id = (SELECT invocation_id FROM event_log WHERE event_id = ?1)) c. This is equivalent because event_id is unique and the join already requires the same invocation. It returned identical rows for all 50 targets.
• C: a partial index on event_log(json_extract(event_json,'$.invocation.session_id'), sequence) WHERE kind='tool_settled'.

With A, B and C patched into the Host, a turn at 1,000 turns took 1.7–2.8 s in release, down from 13.4–16.7 s. What remains is mostly full-session reads that grow linearly. For example, context/evidence.rs:55 reads every event of the session five times per turn, about 0.45 s per turn in release at 1,000 turns. I checked origin/rust-preview at 8c0c697d0: the compaction work there changed candidates.rs and target.rs, but these three points are unchanged.

Since this is your code, I'm leaving the fix to you. I haven't run the event-log test suite against A, B or C, so treat them as measured suggestions.

Host API notes from the client side. These are not blockers:

• An owned client has no public way to find or start a Host. connect_local is private to the CLI and startup::launch is pub(crate).
• host serve's ready line has no epoch, and its socket path is fixed under the system temp directory.
• A refused send surfaces only as agent_execution_unavailable, with no logged cause. Here the cause was an explicit thinkingLevel: "off" sent to an lm-studio model.
• The Host process installs no log subscriber, so sqlx slow-statement warnings go nowhere.

中文版

同步桌面端进展，以及长会话下遇到的一个 Host 性能问题。

桌面端已接上独立 Host。 在 rust-preview 的本地分支上（尚未推送）：

• gpui-shell 按 Base 的惯例 vendor 到 third-party/gpui-kit/crates/shell，有 upstream.json 哈希和 SOURCE.md 说明。补丁只有 Base API 适配和两个开发开关。c5f8eca 的 gpui-component 编不过改过的 Base，所以没有引入；桌面端用裸运行时，自己注册组件。
• 桌面端给脚本暴露一个通用模块 maka-host，提供 query、mutate、subscribe、next、close，底层是 owned Client 会话。之所以选通用桥接而不是 Agent 专用函数，是为了让第三方产品不写原生代码也能调用自己的 Host 服务；脚本能访问什么，仍由 Host 的 endpoint grant 限定。
• 会话列表、对话（固定 through 栅栏分页、从 nextAfter 续订 watch、delta 写入实时行、transcript_changed/ended 时与历史对齐）和输入框（send/stop）都是纯 JavaScript，逻辑对照 TUI 的 agent-screen。在开发 Host 上，用一个 1000 轮（2100 行）的会话测：
  • 首个尾页 376–403 ms；
  • 全部 23 个更早的页约 7.7 s；
  • 流式回复发送后 252 ms 出现第一个 delta；
  • stop 约 65 ms。
  • 流式输出期间，每次脚本渲染平均 1.4 ms，最慢 5.3 ms（共 286 次，debug 构建）。
• 过程中发现的脚本运行时缺口（条目变化时列表丢失位置、不能跟随底部、没有可见范围回调、没有 Enter 提交）会以 PR 提给 gpui-kit。

每轮耗时随会话长度增长。 用假模型通过 agent.send 逐轮给这个会话造数据，每轮耗时从第 20 轮的 63 ms 涨到第 1000 轮附近的约 14 s。CPU 耗在写连接上的 SQLite JSON 解析。

原因在 prepare_prune_candidates，它在每个 Run 开始和每批工具之后都会运行（plugins/agent/engine/src/runner.rs:175、steps.rs:308）。慢在三处：

1. 扫描用不上索引。 查询里的 NOT EXISTS（platform/event-log/src/archive/candidates.rs:102）比较 json_extract(...runtime_event_id) 时没有加 CAST(... AS TEXT)，而部分索引 archived_tool_result（migrations/0001_runtime.sql:348）建在 CAST 表达式上。所以每个候选都要遍历整个会话的事件并解析 JSON。context/tail.rs:45 做同样的检查时用的是 CAST 写法。
2. 每轮都重查旧结果。 每次 LIMIT 1 都会用临时 B-tree 重新评估剩余全部候选。太小、不需要归档的结果不会被记成"已检查"，于是每轮都要把上次压缩以来的所有工具结果重查一遍。
3. target::read 每次都扫全库。 它的 accepted_calls CTE（model_items.rs）每次都在整个 event_log 上物化。

三者合起来，每轮代价约为 k²·n（k 是上次压缩以来的工具结果数，n 是会话事件数）。1000 轮时（约 2.08 万个事件、50 个工具结果），release 构建一轮 13.4–16.7 s，其中 10.0–12.5 s 花在这次扫描上。这期间读历史要在同一连接上排队等它，造数据时我见过 24 s 的首页。

在数据库副本上实测（每轮的扫描加 target 读取）：

	250 轮	500	740	1000
现状	0.19 s	1.0 s	3.5 s	11.2 s
A + B	35 ms	134 ms	345 ms	774 ms
A + B + C	1.5 ms	2.8 ms	5.2 ms	9.8 ms

• A： 在 candidates.rs:102 加上 CAST(... AS TEXT)，查询计划就会走 archived_tool_result。
• B： target::read 把 accepted_calls 限定到目标所在的 invocation（LEFT JOIN (SELECT * FROM accepted_calls WHERE invocation_id = (SELECT invocation_id FROM event_log WHERE event_id = ?1)) c）。因为 event_id 唯一，而且 join 本来就要求同一 invocation，所以两者等价；50 个目标的结果逐行相同。
• C： 部分索引 event_log(json_extract(event_json,'$.invocation.session_id'), sequence) WHERE kind='tool_settled'。

把 A、B、C 打进 Host 后，1000 轮时 release 一轮 1.7–2.8 s（原来 13.4–16.7 s）。剩下的主要是线性增长的整会话读取。例如 context/evidence.rs:55 每轮把会话的全部事件读 5 遍，1000 轮时 release 下每轮约 0.45 s。我对照了 origin/rust-preview 的 8c0c697d0：那里的压缩改动动过 candidates.rs 和 target.rs，但上面三处还在。

这部分是你的代码，就交给你来改。A、B、C 我没有跑 event-log 的测试，请当作实测过的建议看。

客户端视角的 Host 接口备注（都不阻塞）：

• owned 客户端没有公开的发现或启动 Host 的方式：connect_local 是 CLI 私有，startup::launch 是 pub(crate)。
• host serve 的就绪行没有 epoch，socket 路径固定在系统临时目录下。
• send 被拒时只报 agent_execution_unavailable，原因没有日志。这次的原因是给 lm-studio 模型显式传了 thinkingLevel: "off"。
• Host 进程没有装日志订阅者，sqlx 的慢语句警告没有地方输出。