[BUG] 当使用本地部署模型时，Claude Code HaHa 获取输出的速度远远慢于实际生成的速度

[PPicku]

🔍 问题检查清单

• 我已经仔细阅读了 README 常见问题 部分
• 我已经搜索并查看了已关闭的 issues
• 我确认这不是由于 API Key 配置错误、API 端点不兼容、Bun 版本过低等常见原因导致的问题

🐛 问题描述

当使用本地部署模型时，Claude Code HaHa 获取输出的速度远远慢于实际生成的速度。
For example: 如下图
如图， LM Studio 后台可以看到生成已经完毕

但是与此同时 Claude Code HaHa 依然在以固定速度获取输出

现在这个速度严重影响了开发效率，明明一百多 tokens 每秒的生成速度被 Claude Code HaHa 硬控了。
在早期的版本似乎并没有发现这个问题（不确定）

📝 复现步骤

1. 使用 LM Studio 部署本地模型
2. 在 Claude Code HaHa 里使用 LM Studio 的 API 地址。

💻 运行环境

• 操作系统: Windows 11 25H2
• Bun 版本 (bun --version): 1.3.12
• Node 版本 (node --version): 24.7.0
• API 提供商 (如 MiniMax / OpenRouter / Anthropic 官方等): LM Studio
• 使用的模型: Gemma 4 26B A4B
• 启动方式 (TUI / --print / Recovery CLI): TUI

📋 错误日志

无

📷 错误截图

如上文

---

@dosubot

[dosubot]

这个问题之前有其他用户也反馈过，特别是在使用 LM Studio 时。根据代码分析，cc-haha 本身没有刻意加入打字机效果或人为延迟，但有几个架构层面的原因可能导致你看到的"硬控"现象：

可能的原因：

1. 流式超时配置过于激进 — 默认的 30 秒流式超时对于本地模型来说可能太短，导致客户端反复断开重连 [1] [2]
2. WebSocket 缓冲积压 — 桌面端通过 WebSocket 转发 SSE 消息，使用无界队列且没有主动流控，当模型生成速度很快时，消息会在缓冲区中积压 [3] [4]
3. 近期桌面端流式架构变更 — PR #61（4月18日合并）引入了新的桌面端流式基础设施，可能是近期退化的来源
4. MessageBuffer 竞态条件 — 有一个已识别但未被合并的修复 [5]，MessageBuffer.complete() 在并发 flush 时可能导致消息静默丢失

建议的解决方法：

先尝试增加超时时间，设置以下环境变量：

API_TIMEOUT_MS=3000000
CLAUDE_STREAM_IDLE_TIMEOUT_MS=300000

同时建议设置：

CLAUDE_CODE_DISABLE_1M_CONTEXT=1
CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1

你提到"早期版本似乎没有这个问题"，这与 PR #61 引入桌面端流式架构重构的时间线吻合。如果上述环境变量没有改善，可以尝试用 CLI 模式（--print）对比一下速度，以确认问题是否出在桌面端的 WebSocket 转发层。

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[NanmiCoder]

这跟cc-haha没有关系我本地模型在线模型都试了 没问题，使用Anthropic协议