Fixing DeepSeek's "server is busy"
The short version of our full write-up, for people mid-incident.
What it is
Demand exceeds serving capacity at peak hours (~9:00–24:00 China time, UTC+8). The platform sheds load; you see "server is busy", 429-style throttling, or mid-stream stalls. It's not your code, and it's usually not your rate limit.
Fixes that work today
- Exponential backoff + jitter — the single highest-value change. Immediate naive retries make it worse.
- Stream + explicit timeouts — detect stalls early instead of hanging forever.
- Move batch jobs off-peak — outside 9:00–24:00 CST the same code often just works.
- Cache repeated calls — agent loops resend identical sub-queries surprisingly often.
". . . retry with backoff (Python)"
for attempt in range(5):
try:
return client.chat.completions.create(model="deepseek-chat", messages=msgs, timeout=60)
except (RateLimitError, APITimeoutError, APIError):
time.sleep(2 ** attempt + random.uniform(0, 1))The structural fix
DeepSeek's API is OpenAI-compatible, so the endpoint is swappable. Routerra serves international
traffic on international routes — sign up with an email, pay with any card, point
base_url at https://routerra.ai/v1 and keep your code. Keep the retry logic anyway;
every provider has bad moments — what changes is that you're no longer queueing behind China peak hours.