deepseek-ai/DeepSeek-R1
1
0
Fork 0
mirror of https://github.com/deepseek-ai/DeepSeek-R1.git synced 2026-11-05 00:47:42 +00:00
Code Issues 45 Projects Packages Wiki Activity

[GH-ISSUE #430] DeepSeek should publicly disclose its rate limit rules so that users can comply accordingly. #342

New issue
Closed
opened 2026-10-26 21:19:39 +00:00 by bsakaguchi · 8 comments
bsakaguchi commented 2026-10-26 21:19:39 +00:00
Owner
Copy link

Originally created by @link89 on GitHub (Feb 17, 2025).
Original GitHub issue: https://github.com/deepseek-ai/DeepSeek-R1/issues/430

Although DeepSeek claims on this page:

DeepSeek API does NOT constrain user's rate limit. We will try our best to serve every request.
However, please note that when our servers are under high traffic pressure, your requests may take some time to receive a response from the server.
If the request is still not completed after 30 minutes, the server will close the connection.

This is not true.

I've noticed that when I restart a batch text-parsing job after a long period of inactivity, the first 8-10 requests can success without error. However, after that, I start encountering the following error:

json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

Clearly, once my requests to DeepSeek reach a certain threshold, they get deprioritized. At the same time, DeepSeek imposes a backend timeout of 60 seconds per request. As a result, these requests fail with the above error after waiting 60s instead of waiting for 30 minutes to complete.

A reasonable solution would be to make the rate limit rules explicit, allowing developers to have clear expectations about response times and adjust their request strategies accordingly. Requests that exceed the rate limit should fail immediately rather than being forced to wait 60 seconds before failing. With the current approach, the only option for developers is to keep retrying, which is actually counterproductive to solving the problem.

Originally created by @link89 on GitHub (Feb 17, 2025). Original GitHub issue: https://github.com/deepseek-ai/DeepSeek-R1/issues/430 Although DeepSeek claims on [this page](https://api-docs.deepseek.com/quick_start/rate_limit): > DeepSeek API does NOT constrain user's rate limit. We will try our best to serve every request. > However, please note that when our servers are under high traffic pressure, your requests may take some time to receive a response from the server. > If the request is still not completed after 30 minutes, the server will close the connection. This is not true. I've noticed that when I restart a batch text-parsing job after a long period of inactivity, the first 8-10 requests can success without error. However, after that, I start encountering the following error: ``` json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0) ``` Clearly, once my requests to DeepSeek reach a certain threshold, they get deprioritized. At the same time, DeepSeek imposes a backend timeout of 60 seconds per request. As a result, these requests fail with the above error after waiting 60s instead of waiting for 30 minutes to complete. A reasonable solution would be to make the rate limit rules explicit, allowing developers to have clear expectations about response times and adjust their request strategies accordingly. Requests that exceed the rate limit should fail immediately rather than being forced to wait 60 seconds before failing. With the current approach, the only option for developers is to keep retrying, which is actually counterproductive to solving the problem.
bsakaguchi 2026-10-26 21:19:39 +00:00
bsakaguchi commented 2026-10-26 21:19:40 +00:00
Author
Owner
Copy link

@ashburnham commented on GitHub (Feb 27, 2025):

+1 on this

For me it's basically sort of queuing them so it's only dealing with one request at a time which is fine but it'd be nice if it's documented so we could figure out how to do that

<!-- gh-comment-id:2687544130 --> @ashburnham commented on GitHub (Feb 27, 2025): +1 on this For me it's basically sort of queuing them so it's only dealing with one request at a time which is fine but it'd be nice if it's documented so we could figure out how to do that
bsakaguchi commented 2026-10-26 21:19:40 +00:00
Author
Owner
Copy link

@github-actions[bot] commented on GitHub (Apr 25, 2025):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!

<!-- gh-comment-id:2829103072 --> @github-actions[bot] commented on GitHub (Apr 25, 2025): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!
bsakaguchi commented 2026-10-26 21:19:40 +00:00
Author
Owner
Copy link

@QwertyOfficial commented on GitHub (May 15, 2025):

yes

<!-- gh-comment-id:2881949178 --> @QwertyOfficial commented on GitHub (May 15, 2025): yes
bsakaguchi commented 2026-10-26 21:19:40 +00:00
Author
Owner
Copy link

@github-actions[bot] commented on GitHub (Jun 27, 2025):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!

<!-- gh-comment-id:3010767157 --> @github-actions[bot] commented on GitHub (Jun 27, 2025): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!
bsakaguchi commented 2026-10-26 21:19:41 +00:00
Author
Owner
Copy link

@github-actions[bot] commented on GitHub (Jul 12, 2025):

false

<!-- gh-comment-id:3064344582 --> @github-actions[bot] commented on GitHub (Jul 12, 2025): false
bsakaguchi commented 2026-10-26 21:19:41 +00:00
Author
Owner
Copy link

@QwertyOfficial commented on GitHub (Nov 2, 2025):

Alright

<!-- gh-comment-id:3477513014 --> @QwertyOfficial commented on GitHub (Nov 2, 2025): Alright
bsakaguchi commented 2026-10-26 21:19:42 +00:00
Author
Owner
Copy link

@JordanLzG commented on GitHub (Mar 20, 2026):

still a problem

<!-- gh-comment-id:4099946296 --> @JordanLzG commented on GitHub (Mar 20, 2026): still a problem
bsakaguchi commented 2026-10-26 21:19:42 +00:00
Author
Owner
Copy link

@QwertyOfficial commented on GitHub (Apr 5, 2026):

yes

<!-- gh-comment-id:4189578644 --> @QwertyOfficial commented on GitHub (Apr 5, 2026): yes
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
v1.0.0
Labels
Clear labels   
bug

   
closed-as-stale

   
closed-as-stale

   
enhancement

   
pull-request
Mirrored from GitHub Pull Request

  
stale

   
stale
No labels
bug
closed-as-stale
closed-as-stale
enhancement
pull-request
stale
stale
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
deepseek-ai/DeepSeek-R1#342
No description provided.