MoonshotAI / MoonshotAI/kimi-code
上下文很长的对话经常出现打不开(超时)
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 7.5k
- Forks
- 1.2k
- Avg merge
- 11h 53m
- Merged PRs (30d)
- 350
Description
你运行的 Kimi Code 版本是?
0.41
你使用的是哪个开放平台/订阅?
基元律动
你使用的是哪个模型?
glm5.3 flash
你的电脑平台是?
Linux 6.1.0-30-amd64 x86_64 unknown debian
你遇到了什么问题?
所有上下文很长的对话都有很大概率打不开,会出现超时
我有2个上下文很长的对话,ai自己工作了几天了,但是很大概率打不开对话。
第一次打开电脑以后成功打开对话的概率高一些。但是之后就大概率打不开对话了。
我是在vps部署kimi code,用的官方安装命令。然后在我的电脑远程使用网页端操作。使用cloudflare反代。
其他短对话没问题,可以打开。
以下是出错信息:
无法连接到 Kimi 服务器
Web 没有拿到 Kimi 服务器的响应。请确认它仍在运行,或刷新页面重试。
诊断信息:
操作: loadSessionTranscript
Session ID: session_e3c84894-f2db-498f-b05d-fcf0812e64c6
连接状态: connected
时间: 2026-09-07T02:02:36.406Z
耗时: 30000ms
请求: GET /sessions/session_e3c84894-f2db-498f-b05d-fcf0812e64c6/transcript
请求地址: https://(隐藏我的域名)/api/v1/sessions/session_e3c84894-f2db-498f-b05d-fcf0812e64c6/transcript?agent_id=main&page_size=20
Request ID: 01M1WSKVP6SK609F6MQ4MM7HJR
失败阶段: parse
超时设置: 30000ms
HTTP 状态: 200
响应类型: application/json; charset=utf-8
底层原因: AbortError: The user aborted a request.
复现步骤?
1.在vps上(2g内存)使用官方脚本安装kimi code,并启动webui,只对本地开放
2.使用caddy 反代端口,再用cloudflare接管域名,
3.开启一个对话,提出任务,让ai自己工作几天,然后上下文很长
4.然后这个很长的对话就大概率经常打不开,出现上面的出错提示了。其他短的对话没问题
期望的行为是什么?
打开长对话(尤其是ai工作了几天的长对话)不会出现上面的错误。
补充信息
对话满了会自动压缩上下文,我已经压缩上下文几次了
我使用了caddy转发和cloudflare转发
就算能够打开页面,浏览器会非常卡
我觉得对话界面不应该一次性加载太多内容,可以模仿deepseek harness一样只加载最后一部分内容,用户需要查看的时候再提供翻页功能(并给出标签方便用户跳转到指定对话时刻)。这样避免一次性加载太多内容加载失败或者浏览器卡死。
Contribution
- 我愿意自己提交修复此 bug 的 PR(请先等待维护者在本 issue 中批准)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the loadSessionTranscript request to GET /sessions/{session_id}/transcript and reproduce the timeout using a long conversation through the Web UI. Inspect how the response is parsed and rendered, then verify that long transcripts open reliably without excessive browser lag or a 30-second timeout.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- api, frontend, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100