starred/DeepClaude
1
0
Fork 0
mirror of https://github.com/ErlichLiu/DeepClaude.git synced 2026-04-25 05:05:57 +03:00
Code Issues 25 Projects Releases Packages Wiki Activity

[GH-ISSUE #17] 程序没有截断处理吗？ #7

New issue
Closed
opened 2026-02-27 01:55:49 +03:00 by kerem · 7 comments
kerem commented 2026-02-27 01:55:49 +03:00
Owner
Copy link

Originally created by @Passerby1011 on GitHub (Feb 6, 2025).
Original GitHub issue: https://github.com/ErlichLiu/DeepClaude/issues/17

客户端请求发出到deepclaude后，deepclaude正在发出请求到deepseek-r1，因为一些原因，现在的r1模型都不太问题，可能需要比较长的时间响应，客户端等不及直接终止了对话，deepclaude这边不会终止吗？
下图可以看出是一个对话，中间等响应不出字，我客户端终止了几次
Image

Originally created by @Passerby1011 on GitHub (Feb 6, 2025). Original GitHub issue: https://github.com/ErlichLiu/DeepClaude/issues/17 客户端请求发出到deepclaude后，deepclaude正在发出请求到deepseek-r1，因为一些原因，现在的r1模型都不太问题，可能需要比较长的时间响应，客户端等不及直接终止了对话，deepclaude这边不会终止吗？ 下图可以看出是一个对话，中间等响应不出字，我客户端终止了几次 ![Image](https://github.com/user-attachments/assets/8379ad17-9568-4d04-b2c7-ffd7bf844bc7)
kerem closed this issue 2026-02-27 01:55:49 +03:00
kerem commented 2026-02-27 01:55:49 +03:00
Author
Owner
Copy link

@ErlichLiu commented on GitHub (Feb 6, 2025):

客户端请求发出到deepclaude后，deepclaude正在发出请求到deepseek-r1，因为一些原因，现在的r1模型都不太问题，可能需要比较长的时间响应，客户端等不及直接终止了对话，deepclaude这边不会终止吗？ 下图可以看出是一个对话，中间等响应不出字，我客户端终止了几次 Image

目前我们没有设置专门的超时处理，链接有默认的超时时间，最长应该是 10 mins。不做这一层还是比较正常的，可能这几天之后热度稍微下降后就会都能顺畅访问了。

<!-- gh-comment-id:2639861549 --> @ErlichLiu commented on GitHub (Feb 6, 2025): > 客户端请求发出到deepclaude后，deepclaude正在发出请求到deepseek-r1，因为一些原因，现在的r1模型都不太问题，可能需要比较长的时间响应，客户端等不及直接终止了对话，deepclaude这边不会终止吗？ 下图可以看出是一个对话，中间等响应不出字，我客户端终止了几次 ![Image](https://github.com/user-attachments/assets/8379ad17-9568-4d04-b2c7-ffd7bf844bc7) 目前我们没有设置专门的超时处理，链接有默认的超时时间，最长应该是 10 mins。不做这一层还是比较正常的，可能这几天之后热度稍微下降后就会都能顺畅访问了。
kerem commented 2026-02-27 01:55:49 +03:00
Author
Owner
Copy link

@Passerby1011 commented on GitHub (Feb 6, 2025):

客户端请求发出到deepclaude后，deepclaude正在发出请求到deepseek-r1，因为一些原因，现在的r1模型都不太问题，可能需要比较长的时间响应，客户端等不及直接终止了对话，deepclaude这边不会终止吗？ 下图可以看出是一个对话，中间等响应不出字，我客户端终止了几次 Image

目前我们没有设置专门的超时处理，链接有默认的超时时间，最长应该是 10 mins。不做这一层还是比较正常的，可能这几天之后热度稍微下降后就会都能顺畅访问了。

理解，不过建议还是加上，万一请求有问题，客户端需要终止修改问题呢？
而且如果是对外开放使用，被有心之人恶意刷就完了，只需要请求终止请求终止就可以刷光你r1的额度

<!-- gh-comment-id:2639994640 --> @Passerby1011 commented on GitHub (Feb 6, 2025): > > 客户端请求发出到deepclaude后，deepclaude正在发出请求到deepseek-r1，因为一些原因，现在的r1模型都不太问题，可能需要比较长的时间响应，客户端等不及直接终止了对话，deepclaude这边不会终止吗？ 下图可以看出是一个对话，中间等响应不出字，我客户端终止了几次 ![Image](https://github.com/user-attachments/assets/8379ad17-9568-4d04-b2c7-ffd7bf844bc7) > > 目前我们没有设置专门的超时处理，链接有默认的超时时间，最长应该是 10 mins。不做这一层还是比较正常的，可能这几天之后热度稍微下降后就会都能顺畅访问了。 理解，不过建议还是加上，万一请求有问题，客户端需要终止修改问题呢？ 而且如果是对外开放使用，被有心之人恶意刷就完了，只需要请求终止请求终止就可以刷光你r1的额度
kerem commented 2026-02-27 01:55:49 +03:00
Author
Owner
Copy link

@ErlichLiu commented on GitHub (Feb 6, 2025):

客户端请求发出到deepclaude后，deepclaude正在发出请求到deepseek-r1，因为一些原因，现在的r1模型都不太问题，可能需要比较长的时间响应，客户端等不及直接终止了对话，deepclaude这边不会终止吗？ 下图可以看出是一个对话，中间等响应不出字，我客户端终止了几次 Image

目前我们没有设置专门的超时处理，链接有默认的超时时间，最长应该是 10 mins。不做这一层还是比较正常的，可能这几天之后热度稍微下降后就会都能顺畅访问了。

理解，不过建议还是加上，万一请求有问题，客户端需要终止修改问题呢？
而且如果是对外开放使用，被有心之人恶意刷就完了，只需要请求终止请求终止就可以刷光你r1的额度

有道理，确实需要加一个默认更短的超时处理，后续来添加

<!-- gh-comment-id:2641137864 --> @ErlichLiu commented on GitHub (Feb 6, 2025): > > > 客户端请求发出到deepclaude后，deepclaude正在发出请求到deepseek-r1，因为一些原因，现在的r1模型都不太问题，可能需要比较长的时间响应，客户端等不及直接终止了对话，deepclaude这边不会终止吗？ 下图可以看出是一个对话，中间等响应不出字，我客户端终止了几次 ![Image](https://github.com/user-attachments/assets/8379ad17-9568-4d04-b2c7-ffd7bf844bc7) > > > > 目前我们没有设置专门的超时处理，链接有默认的超时时间，最长应该是 10 mins。不做这一层还是比较正常的，可能这几天之后热度稍微下降后就会都能顺畅访问了。 > > 理解，不过建议还是加上，万一请求有问题，客户端需要终止修改问题呢？ > 而且如果是对外开放使用，被有心之人恶意刷就完了，只需要请求终止请求终止就可以刷光你r1的额度 有道理，确实需要加一个默认更短的超时处理，后续来添加
kerem commented 2026-02-27 01:55:49 +03:00
Author
Owner
Copy link

@GowayLee commented on GitHub (Feb 7, 2025):

理解，不过建议还是加上，万一请求有问题，客户端需要终止修改问题呢？ 而且如果是对外开放使用，被有心之人恶意刷就完了，只需要请求终止请求终止就可以刷光你r1的额度

目前好像DeepSeek官方以及SiliconFlow的API文档上都没有提及中止API的请求格式.

研究了官网对话的中止按钮, 是发送了如下请求

Image

其中https://chat.deepseek.com/api/v0/chat/stop_stream并非官方公开的API地址.

所以感觉做主动的停止请求可能比较困难.

<!-- gh-comment-id:2641813300 --> @GowayLee commented on GitHub (Feb 7, 2025): > 理解，不过建议还是加上，万一请求有问题，客户端需要终止修改问题呢？ 而且如果是对外开放使用，被有心之人恶意刷就完了，只需要请求终止请求终止就可以刷光你r1的额度 目前好像DeepSeek官方以及SiliconFlow的API文档上都没有提及中止API的请求格式. 研究了官网对话的中止按钮, 是发送了如下请求 ![Image](https://github.com/user-attachments/assets/b1accea1-f564-400f-bb3d-fa0bd8bac272) 其中`https://chat.deepseek.com/api/v0/chat/stop_stream`并非官方公开的API地址. 所以感觉做主动的停止请求可能比较困难.
kerem commented 2026-02-27 01:55:49 +03:00
Author
Owner
Copy link

@Passerby1011 commented on GitHub (Feb 7, 2025):

理解，不过建议还是加上，万一请求有问题，客户端需要终止修改问题呢？ 而且如果是对外开放使用，被有心之人恶意刷就完了，只需要请求终止请求终止就可以刷光你r1的额度

目前好像DeepSeek官方以及SiliconFlow的API文档上都没有提及中止API的请求格式.

研究了官网对话的中止按钮, 是发送了如下请求

Image

其中https://chat.deepseek.com/api/v0/chat/stop_stream并非官方公开的API地址.

所以感觉做主动的停止请求可能比较困难.

我可以很明确的说，各家api的响应都不太一样，我目前知道的硅基流动、豆包、官方比较相似但是也有差别，国外的Azure和openrouter有不一样，在本项目里azure的甚至根本没法用，我之前尝试写截断，发现一套根本没法解决，建议作者直接写明对于那些R1厂家的支持

<!-- gh-comment-id:2641870102 --> @Passerby1011 commented on GitHub (Feb 7, 2025): > > 理解，不过建议还是加上，万一请求有问题，客户端需要终止修改问题呢？ 而且如果是对外开放使用，被有心之人恶意刷就完了，只需要请求终止请求终止就可以刷光你r1的额度 > > 目前好像DeepSeek官方以及SiliconFlow的API文档上都没有提及中止API的请求格式. > > 研究了官网对话的中止按钮, 是发送了如下请求 > > ![Image](https://github.com/user-attachments/assets/b1accea1-f564-400f-bb3d-fa0bd8bac272) > > 其中`https://chat.deepseek.com/api/v0/chat/stop_stream`并非官方公开的API地址. > > 所以感觉做主动的停止请求可能比较困难. 我可以很明确的说，各家api的响应都不太一样，我目前知道的硅基流动、豆包、官方比较相似但是也有差别，国外的Azure和openrouter有不一样，在本项目里azure的甚至根本没法用，我之前尝试写截断，发现一套根本没法解决，建议作者直接写明对于那些R1厂家的支持
kerem commented 2026-02-27 01:55:50 +03:00
Author
Owner
Copy link

@GowayLee commented on GitHub (Feb 7, 2025):

我可以很明确的说，各家api的响应都不太一样，我目前知道的硅基流动、豆包、官方比较相似但是也有差别，国外的Azure和openrouter有不一样，在本项目里azure的甚至根本没法用，我之前尝试写截断，发现一套根本没法解决，建议作者直接写明对于那些R1厂家的支持

Provider的适配确实很耗费人力. 可以在README中写明不错.

<!-- gh-comment-id:2641882468 --> @GowayLee commented on GitHub (Feb 7, 2025): > 我可以很明确的说，各家api的响应都不太一样，我目前知道的硅基流动、豆包、官方比较相似但是也有差别，国外的Azure和openrouter有不一样，在本项目里azure的甚至根本没法用，我之前尝试写截断，发现一套根本没法解决，建议作者直接写明对于那些R1厂家的支持 Provider的适配确实很耗费人力. 可以在README中写明不错.
kerem commented 2026-02-27 01:55:50 +03:00
Author
Owner
Copy link

@Passerby1011 commented on GitHub (Feb 7, 2025):

我可以很明确的说，各家api的响应都不太一样，我目前知道的硅基流动、豆包、官方比较相似但是也有差别，国外的Azure和openrouter有不一样，在本项目里azure的甚至根本没法用，我之前尝试写截断，发现一套根本没法解决，建议作者直接写明对于那些R1厂家的支持

Provider的适配确实很耗费人力. 可以在README中写明不错.

感觉上都一样，对话也都正常，但是放到这种程序里，那就是百花齐放了，乱七八糟的

<!-- gh-comment-id:2641891517 --> @Passerby1011 commented on GitHub (Feb 7, 2025): > > 我可以很明确的说，各家api的响应都不太一样，我目前知道的硅基流动、豆包、官方比较相似但是也有差别，国外的Azure和openrouter有不一样，在本项目里azure的甚至根本没法用，我之前尝试写截断，发现一套根本没法解决，建议作者直接写明对于那些R1厂家的支持 > > Provider的适配确实很耗费人力. 可以在README中写明不错. 感觉上都一样，对话也都正常，但是放到这种程序里，那就是百花齐放了，乱七八糟的
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
fix-logger-level
dev
experiment
v1.0.1
Labels
Clear labels   
bug

   
documentation

   
duplicate

   
enhancement

   
good first issue

   
help wanted

   
invalid

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
wontfix
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
pull-request
question
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/DeepClaude#7
No description provided.