性能
Chord 面向长时间交互会话做了性能优化：大 transcript、模型流式输出、滚屏，以及后台 agent 活动都应保持可控。
这些数据来自特定场景，主要展示 Chord 的上下文剪裁、低开销 TUI 和内存占用在哪些地方有价值；硬件、运行环境、会话内容、模型行为和实现路径都会影响结果。
下面两张表都标注了各自的测试版本。
真实编码任务
Section titled “真实编码任务”我们让六款 agent harness 跑了同一个 DeepSWE v1.1 任务：给 httpx 加上流式 JSON 迭代接口。Chord 用时最短、成本最低：6m37s、￥0.348，第二名的耗时是它的 1.49 倍、成本是 1.51 倍。
这个任务要按 media type 分流 application/json、application/*+json、NDJSON 和 JSON text sequence 四种解析规则，还要处理流式响应只能迭代一次、解码失败和 Content-Type 参数等细节。
| Harness | 耗时 | 成本 |
|---|---|---|
| Chord 0.8.1 | 6m37s | ￥0.348 |
| deepseek-harness 0.1.5-rc.1 | 9m50s（1.49 倍） | ￥0.527（1.51 倍） |
| pi 0.85.1 | 10m22s（1.57 倍） | ￥0.576（1.65 倍） |
| codex 0.154.0 | 17m01s（2.57 倍） | ￥0.929（2.67 倍） |
| mini-swe-agent 2.4.6 | 18m29s（2.79 倍） | ￥0.835（2.40 倍） |
| claude code 2.1.272 | 22m25s（3.39 倍） | ￥1.104（3.17 倍） |
完整 token 明细：
| Harness | 耗时 | 模型调用 | 输入 tokens | 输出 tokens | 缓存读取 tokens | 成本 |
|---|---|---|---|---|---|---|
| Chord 0.8.1 | 6m37s | 49 次 | 54,530 | 58,559 | 2,961,280 | ￥0.348 |
| deepseek-harness 0.1.5-rc.1 | 9m50s（1.49 倍） | 93 次 | 58,569 | 80,314 | 7,357,440 | ￥0.527（1.51 倍） |
| pi 0.85.1 | 10m22s（1.57 倍） | 101 次 | 79,189 | 94,733 | 5,871,488 | ￥0.576（1.65 倍） |
| codex 0.154.0 | 17m01s（2.57 倍） | 121 次 | 72,363 | 135,310 | 15,787,264 | ￥0.929（2.67 倍） |
| mini-swe-agent 2.4.6 | 18m29s（2.79 倍） | 158 次 | 161,893 | 77,320 | 18,206,592 | ￥0.835（2.40 倍） |
| claude code 2.1.272 | 22m25s（3.39 倍） | 143 次 | 106,546 | 214,126 | 7,024,768 | ￥1.104（3.17 倍） |
括号里是相对 Chord 的倍数。
成本看的是 token 结构，不是总量：缓存读取比未命中缓存的输入便宜 50 倍、比输出便宜 200 倍，所以 Chord 那 296 万缓存读取 token 只花掉约 ￥0.06，真正占大头的是 58,559 个输出 token，占了 ￥0.348 的三分之二。六次运行里 Chord 的输入 token、输出 token 和模型调用次数都最少。
注：
- 六次运行都用 deepseek-v4.1-flash。
- 成本按该模型的标价估算，每 100 万 token：输入 ￥1、输出 ￥4、缓存读取 ￥0.02。括号里的倍数用未舍入的估算值计算，和直接用表中舍入金额相除可能略有出入。
- 耗时排除环境准备和最终收尾时间，包含模型交互、代码修改和测试执行。
我们还测了应用交互层的内存占用：空会话，以及加载 200 条消息后。
| Harness | 空会话内存 | 200 消息内存 |
|---|---|---|
| Chord 0.8.1 | 30MB | 39MB |
| codex 0.154.0 | 27MB | 47MB |
| claude code 2.1.273 | 143MB | 216MB |
注：
- 内存数据测于 macOS 15.3.2（arm64）。
- 不同会话和环境的内存占用会有差异，表中数据仅用于估算。
- 模型输出文本或思考过程时，TUI 仍保持响应。
- 长回复期间 CPU 受控，避免按 token 做高成本工作。
- 加载或浏览大历史会话时内存稳定。
- 后台任务活跃时，滚屏和键盘输入仍然顺滑。
- 流式批处理：流式文本以很小的 delta 到达；Chord 会合并 provider delta，让一次 UI 更新处理多个 delta，而不是每个小片段都唤醒 TUI。
- 渲染 cadence：流式内容按节奏刷新到屏幕，而不是每个 token 都重绘。真正的结构变化（新 block、布局边界、回滚）仍会及时刷新。
- streaming cheap path：assistant 和 thinking block 流式输出期间，只有稳定下来的内容走完整 Markdown 渲染；正在变化的尾部走更便宜的纯文本路径。所以长段落在流式期间看起来更朴素，这是预期行为。
- View 缓存：主 viewport、info panel、status bar 等高成本区域按帧缓存，只有输入变化时才重新渲染。
- 滚屏批处理：鼠标滚轮和触摸板 delta 会合并后按短 cadence 应用；大 transcript 只有可见窗口保持热数据，屏幕外区域保持冷却。
- 会话懒加载：恢复大会话时先加载当前窗口供交互，搜索 / 跳转 / 目录的 metadata 和更早的 transcript 区域在后台逐步加载。
- 有界搜索状态：transcript 搜索只缓存当前查询在渲染结果中的命中位置，不再长期保留每一行的渲染副本。搜索可检查已 spill 的冷卡片，但不会让其正文或派生索引常驻热窗口。
请求与上下文成本
Section titled “请求与上下文成本”性能不只在 UI 侧。Chord 还会在请求时剪裁陈旧工具输出、保留结构化摘要，并在长会话接近模型限制前做压缩。请求剪裁不改写会话历史；持久压缩会用摘要替换后续上下文，并把原文归档。这些机制用于控制请求大小和成本，实际收益取决于任务。
可配置项见上下文剪裁。
流式工具早执行
Section titled “流式工具早执行”Chord 还会在模型响应完全结束前就启动安全工具，降低体感延迟。模型流式输出某个工具调用的参数时，只要参数已经完整且合法，Chord 就可能立刻开始执行该工具，不必等 provider 的「整轮结束」信号，结果一就绪就展示出来。适用对象是本地、低副作用的工具，如 read、grep、glob 和只读 shell 命令；web_fetch 这类网络请求仍等流结束再发，会改动文件的工具只在调用被确认为最终时提交（若被丢弃则回滚）。Chord 对判定安全的工具默认开启，无需配置；哪些工具能早执行、能碰什么，仍由与普通工具调用相同的权限规则约束。
- 缩小当前会话上下文：运行
/compact，或为无关工作另开新会话。 - 换一个终端模拟器对比：不同终端的渲染开销差异明显。
- 超大会话里首次访问很早的 transcript 区域会比热窗口慢，再次访问会命中缓存。
如果某个交互持续偏慢，复现时采集一份 CPU profile，连同诊断包（Ctrl+G）一起附在反馈里：
CHORD_PPROF_PORT=6060 chordgo tool pprof http://127.0.0.1:6060/debug/pprof/profile?seconds=15