Repository navigation
Replies: 6 comments 1 reply
|
I support moving the Rust implementation to Since the two implementations and their storage models have diverged, I suggest making the resulting Session migration should be handled separately: the two SQLite schemas and execution models differ, so switching branches will not migrate existing data or running work. 中文版我支持在切换条件满足后，让 两套实现和存储模型已经分叉，建议切换后的 Session 迁移应单独处理：两边的 SQLite schema 和执行模型不同，切换分支不会自动迁移已有数据或运行中的工作。 |
|
I support replacing the TypeScript version with the Rust version. If the Rust version delivers a real performance improvement, the sooner we make this decision, the better. When the switch happens, I hope we can publish a user-facing feature comparison between the two versions of Maka, clearly identifying which features are retained or have alternatives, which are not yet supported, and which are being removed. This would give contributors a clear direction and help them start contributing directly to the Rust version right away. 中文（点击展开）我赞同用rust版替换ts版，如果rust版确实有性能提升，这种决断越早做越好。希望在正式切换时，面向用户发布一份新旧两版 Maka 的功能差异清单，明确哪些功能已经保留或有替代方案、哪些暂未支持、哪些决定移除。这样有利于开发人员可以立刻直接在rust版进行有方向性的开发工作。 |
|
+1 from me. I support the proposal: no new features on I also agree with the points raised so far:
中文版我投 +1，支持这个方案： 也同意前面几位提到的几点：
|
EnglishI tested five agent harnesses with the same deterministic repair workload: keep existing sessions working, accumulate history, then add more sessions. File operations, code changes and tests were real; the model was replaced with a local scripted service. These are the results when each run stopped. Different stop conditions mean they should not be read as a concurrency-limit ranking.
How to read the counters:
Each user task contains 24 repair cycles / 120 tool calls, followed by another task in the same session. Codex and Claude reached my memory guard: stop when machine OpenCode stopped before reaching that memory boundary. Follow-up experiments point to contention in the bundled Bun runtime’s shared HTTP request queue, although the original request ordering has not been fully reconstructed. For TS, I first changed the adapter to give each session its own connection. After the long run hit the SDK timeout, I relaxed the registration waiting-time limit in an isolated SDK copy. A separate 64-session, 180-second check passed: 64 sessions with verified work, 1,991 tool calls and 383 repair cycles. That was a short validation, not another aged-session long run. I did not continue with another long TS run because progress was already substantially slower than Rust: reaching the initial history gate took about 53 minutes, versus 8 minutes 48 seconds for Rust. Rust’s final active creation minute added 43 sessions, averaging about 1.4 seconds per new session across concurrent creation requests. High-load session creation and disk-write volume are the next optimization targets.
The parenthesized counts belong to the RSS sample. Codex confirmed one additional session afterward. CPU time and writes are whole-run totals, not steady-state measurements at those session counts. Claude had 185 live CLI processes, including processes still initializing. The table shows their individual RSS median; summing RSS would double-count shared pages. Rust Host RSS was 1.200 GiB at 3,000 sessions. CPU time includes all test processes and can exceed wall time through parallel execution. Writes are sampled product-group kernel counters, including the adapter/observer; short-lived processes can be missed. They are not database net growth or SSD NAND writes, so Claude’s low sampled value should not be treated as a complete I/O comparison. Rust’s high observed write volume is nevertheless a cost I intend to investigate and reduce. Wall time includes startup, initial history accumulation, continued work and expansion, then shutdown. Installation, builds and offline analysis are excluded. Creation overlaps business work and is not added again. Test conditions:
Pinned versions, workload scripts and per-product commands are available in the [reproduction kit](https://gist.github.com/M4n5ter/dde3810b7a45dad6f30c7fb2f5bc5e94): git clone https://gist.github.com/dde3810b7a45dad6f30c7fb2f5bc5e94.git runtime-bench
cd runtime-bench
python3 unpack.py "$PWD/kit"
cd kit
sha256sum -c SHA256SUMSFollow 简体中文这轮我主要想看两件事：会话长期使用工具、积累历史后，还能不能继续正常工作；保留老会话、再不断加入新会话时，会先卡在哪里。 模型统一换成本地脚本服务，文件读写、代码修改和测试都是真执行。比较的是运行时表现，不是模型的编程能力。 下面是每场停下来时的结果。停止原因不同，不能直接当作并发上限排名。
表里的几个数字：
每条用户任务要求完成 24 轮修复，共 120 次工具调用，之后继续在同一个会话里做下一条任务。 Codex 和 Claude 撞上的“内存墙”，是我设置的保护线：机器剩余可用内存低于 4 GiB就停止，不一定发生了 OOM 崩溃。 OpenCode 没有触及这条内存线，而是提前停在 MCP 超时。后续小实验提示，内嵌 Bun 的 HTTP 请求共用并发额度，可能导致工具请求排队；原场的请求顺序还没有完整还原。 TS 先改成了每会话独立连接。长测遇到 SDK 超时后，又在独立 SDK 副本中放宽注册等待时间，做了 64 会话、180 秒短测：64 个会话都完成过修复，共 1,991 次工具调用、383 轮修复。这次只验证补丁，没有重跑完整的历史积累长测。由于一开始积累历史就已经明显慢于 Rust，我没有再继续长跑 TS：达到初始门槛用了约 53 分钟，Rust 则约 8 分 48 秒。 Rust 最后一段仍在创建的 1 分钟里新增了 43 个会话，平均约 1.4 秒新增一个。这是并行创建的整体速度，不是单次调用耗时。高负载创建速度和磁盘写入量，都会作为下一步的优化重点。
括号里是 RSS 采样时已创建的会话数。Codex 后来又确认了一个会话，所以和第一张表相差 1。CPU 和写入量是整场累计值，不是固定在这个会话数下的消耗。 Claude 当时有 185 个 CLI 进程，包含还在初始化的进程。表中给的是单个 CLI 的 RSS 中位数，没有把共享页重复相加。Rust 在 3,000 个会话时，Host RSS 为 1.200 GiB。 CPU 时间包含整场测试的所有进程，多核并行时会超过实际经过的时间。写入量来自产品进程组的内核计数，包含适配器／观察客户端，采样可能漏掉短命进程；它不是数据库净增长，也不等于 SSD 实际写入量，因此 Claude 的低数值不能直接当作完整 I/O 对比。Rust 本次观测到的写入量确实偏高，需要继续排查和降低。 总耗时包括启动、首批会话积累历史、扩容和持续工作，以及最后收尾；不包含安装、构建和离线分析。创建和业务执行是并行的，创建耗时不会再额外加一遍。 测试条件：
固定版本、完整脚本和各工具运行命令见 **[复现材料](https://gist.github.com/M4n5ter/dde3810b7a45dad6f30c7fb2f5bc5e94)**： git clone https://gist.github.com/dde3810b7a45dad6f30c7fb2f5bc5e94.git runtime-bench
cd runtime-bench
python3 unpack.py "$PWD/kit"
cd kit
sha256sum -c SHA256SUMS按其中的 |
|
+1. I support concentrating feature development on |
|
The lazy consensus period ended on 2026-10-30 at 08:25 UTC with no objections, so the proposal passes. Thanks to @me2seeks, @chinawch007, @liugddx and @MicroGery for the support, and to @M4n5ter for the benchmark. What changes now:
Two switch conditions were raised in this thread, and I'm adding both to the list:
The other conditions in the proposal still apply. M4n5ter's results above cover the side-by-side comparison. High-load session creation and disk-write volume are the next things to improve on the Rust side. My rough estimate is still late November, and M4n5ter will refine it. I'll announce the switch in a separate post once all the conditions are met. 中文版lazy consensus 已于 2026-10-30 08:25 UTC 到期，期间没有反对，提案通过。感谢 @me2seeks、@chinawch007、@liugddx、@MicroGery 的支持，也感谢 @M4n5ter 做的压测。 接下来的变化：
这个帖子里大家补充了两条切换条件，我都加进条件清单：
提案里原有的其他条件不变。上面 M4n5ter 的结果已经覆盖了同机对比这一项。高负载下新建会话的速度和磁盘写入量，是 Rust 版接下来要优化的地方。切换时间我仍然粗估在 11 月下旬，由 M4n5ter 再校正。所有条件都满足后，我会另发一帖宣布切换。 |
English@Astro-Han I can draft the Rust side of the comparison, and thanks for offering to help fill in the
简体中文@Astro-Han Rust 这部分我来起草，也谢谢你愿意帮忙补充 目前 |
Uh oh!
There was an error while loading. Please reload this page.
rust-previewsplit frommainon September 18 and is now 1,916 commits ahead. As @M4n5ter noted in #6078, it is no longer compatible withmain: the Host protocol, clients and storage are all different. Meanwhile, new features keep landing onmain. The personal assistant is one example. Since the split,mainhas gained about 14,700 lines underpackages/runtime-host/src/assistantandpackages/runtime/src/bots, whilerust-previewhas its own assistant plugin in Rust. Every feature built onmainnow has to be built again onrust-previewor dropped.Most contributors work on
main, where there are 165 open pull requests, and I don't think we've said clearly how long that work will last. I raised this with a few maintainers in chat first; this post is where it gets decided.Proposal
No new features on
mainfrom now on.maintakes bug fixes, security fixes, dependency updates, release work and docs. 0.2.x releases continue frommainuntil the switch, starting with 0.2.2, which is being voted on now.All feature work moves to
rust-preview, including the personal assistant and the Always-on Bot (#6076). Design discussions stay independent of the implementation. I'll also move my own daily work torust-previewbuilds, so problems show up through real use.rust-previewreplacesmainin one switch. The two are different enough that merging doesn't make sense. At the switch, the currentmainbecomes a0.2.xmaintenance branch andrust-previewbecomesmain. Both keep their history. This is a breaking change, and I think that's acceptable at this stage.When to switch
rust-previewbecomesmainwhen these hold:mainSessions can be imported (see below).mainthat people rely on is either available or explicitly dropped, from a written list.Going by the current pace, my rough guess is late November. @M4n5ter @UncertaintyDeterminesYou4ndMe, please correct me.
Session migration
Internal data formats are not compatible, and the Session bundles differ too, so nothing carries over by itself.
rust-previewalready has a session-import plugin that converts Claude, Codex and OpenCode conversations into one normalized transcript. I'd add a Maka 0.2 source to it that readsmain's data without modifying it.That carries conversation history: messages, tool calls and their results, titles and projects. State tied to
main's implementation, such as Goals, scheduled tasks, WorkHub relationships, memory and usage history, goes on the capability list and is either handled one by one or dropped. The old data stays where it is, so a 0.2.x build can still open it.Pull requests on
mainrust-preview, please say so in the PR.main. I'll go through them and ask each author whether to bring the work torust-previewor close it, rather than closing them silently.rust-preview. Once this is agreed, I'll add a short note to CONTRIBUTING and the PR template.Questions
mainstate is worth importing?This Discussion is mirrored to dev@. If there are no objections within 72 hours, I'll take the direction (no new features on
main, feature work onrust-preview, andrust-previewreplacingmainonce the conditions above hold) as agreed by lazy consensus. The details can keep being refined here.中文版（点击展开）
rust-preview在 9 月 18 日从main分出，现在已经领先 1916 个 commit。@M4n5ter 在 #6078 里提到，它已经和main不兼容：Host 协议、客户端和存储都不一样了。与此同时，新功能还在不断进main。个人助理就是一个例子：分叉以来，main在packages/runtime-host/src/assistant和packages/runtime/src/bots下新增了约 1.47 万行，而rust-preview有自己的 Rust 版 assistant 插件。现在在main上做的每个功能，之后要么在rust-preview上重做，要么丢掉。大部分贡献者在
main上工作，那里有 165 个 open PR，我觉得我们一直没讲清楚这些工作还能用多久。我先在群里和几位维护者聊过，正式的决定在这个帖子里做。提议
从现在起
main不再加新功能。main只接受 bug 修复、安全修复、依赖更新、发版和文档。切换之前继续从main发 0.2.x，第一个是正在投票的 0.2.2。所有功能开发转到
rust-preview，包括个人助理和常驻 Bot（#6076）。设计讨论与实现无关。我自己的日常工作也会换到rust-preview的构建上，让问题从真实使用里暴露。rust-preview一次性替换main。 两边差别太大，合并没有意义。切换时，当前main改为0.2.x维护分支，rust-preview成为main，两边历史都保留。这是一次不兼容更新，我认为在现阶段可以接受。什么时候切
满足以下条件后，
rust-preview成为main：main的 Session（见下文）。main上大家依赖的能力，按一份成文清单逐项确认：要么已经可用，要么明确放弃。按现在的进度，我粗估是 11 月下旬。@M4n5ter @UncertaintyDeterminesYou4ndMe 请帮忙校正。
会话迁移
两边的内部数据格式不兼容，Session 包也不一样，所以不会自动迁移。
rust-preview已经有一个 session-import 插件，能把 Claude、Codex 和 OpenCode 的对话转成统一的 transcript。我建议在里面加一个 Maka 0.2 来源，只读main的数据、不改动它。这样能带过去的是对话记录：消息、工具调用和结果、标题和项目。和
main实现绑定的状态，比如 Goal、定时任务、WorkHub 关系、记忆和用量历史，列进能力清单，逐项处理或放弃。旧数据原地保留，0.2.x 的构建仍然可以打开。main上的 PRrust-preview上也有同样的 bug，请在 PR 里说明。main。我会逐个过一遍，问作者是把工作带到rust-preview还是关闭，不会悄悄关掉。rust-preview开始。达成一致后，我会在 CONTRIBUTING 和 PR 模板里加一句说明。想讨论的问题
main上还有哪些状态值得导入？本帖会同步到 dev@。72 小时内没有反对意见，我就视为方向（
main不再加新功能、功能开发转到rust-preview、条件满足后rust-preview替换main）已按 lazy consensus 通过，细节可以继续在这里完善。All reactions