How does the DeepSeek API behave under load, given it publishes no rate limits?

## The unusual policy Most providers publish a rate-limit table — requests per minute, tokens per minute, tiers you graduate through — and reject you with 429 when you exceed it. DeepSeek's documented stance is different: it does not constrain a user's rate and will try to serve every request. There is no per-key RPM or TPM number to look up, which means capacity planning against DeepSeek cannot be done by reading a limits page. It has to be done by measuring latency under your own load. ## What back-pressure looks like on the wire Because the platform absorbs rather than rejects, congestion surfaces as waiting. When DeepSeek's servers are under heavy traffic your request may take a long time to produce a response, and during that wait the HTTP connection is deliberately kept alive rather than closed. The server sends filler bytes whose only job is to stop proxies, load balancers and client libraries from treating the silence as a dead connection: - **Non-streaming requests** receive empty lines while they wait. When the answer is ready, the real JSON body follows. A tolerant JSON client skips the leading whitespace without noticing. - **Streaming requests** receive SSE comment lines — lines beginning with a colon. The Server-Sent Events specification defines a line starting with `:` as a comment that the client must ignore, so a conforming SSE parser drops them silently and only surfaces the real `data:` events. The operational lesson is that a hand-rolled parser is where this bites. Code that assumes the first bytes off the socket are JSON, or that treats any non-`data:` line in an SSE stream as a protocol violation, will report failures that are actually the server behaving as designed. ## Timeouts become the real limit If the provider will not reject you, your own timeout becomes the rejection mechanism. A five- or ten-second read timeout — perfectly reasonable against a fast endpoint — will abort DeepSeek calls that were merely queued, and if the client then retries, it adds load to a system that is already congested, producing a retry storm against a provider that was never going to shed the traffic for you. Sound practice is a generous read timeout tuned to observed p99 rather than to a guess, a bounded overall deadline so a request cannot hang forever, and idempotency at the application layer so an abandoned call that the server eventually completed does not cause duplicate side effects. Streaming helps here for a second reason beyond perceived latency: once the first real token arrives you have evidence the request is progressing, which lets you distinguish "queued" from "stuck". ## The error codes still matter "No rate limits" does not mean no errors. DeepSeek's documented status codes include several you must handle distinctly: - **429, rate limit reached** — you are sending requests too quickly. Still possible despite the general policy; back off and pace. - **503, server overloaded** — the platform is under high traffic. Wait and retry. - **500, server error** — a transient fault; retry after a short pause. - **402, insufficient balance** — your account has run out of prepaid credit. This one is categorically different: it is not transient, backoff will never clear it, and retrying just burns your own capacity. It needs an alert to a human and a top-up. - **401** for a bad key, **400** for a malformed body and **422** for invalid parameters are client-side and must not be retried at all. A retry policy that lumps every non-200 into "retry with backoff" is the classic failure here: it turns a billing outage into a silent, long-running loop that nobody notices until the feature has been down for an hour. ## Designing around it Since the provider will not push back, you must bound concurrency yourself. Cap in-flight requests at the application or fleet level so that a traffic spike converts into your own queue — where you can observe it, shed low-priority work, and degrade gracefully — rather than into thousands of connections all waiting on DeepSeek at once, each holding a socket and a thread. Monitor time-to-first-token separately from total latency; under congestion the first diverges while the second stays roughly proportional, which is a clean early signal. Finally, remember that the prepaid model interacts with all of this. Because 402 arrives with no warning at the API layer, balance should be monitored as an availability concern, not as a finance one: the account balance endpoint gives you remaining credit, and alerting on it well above zero prevents a full-feature outage caused by an empty wallet.