DeepSeek erstattet Ausgaben nach mehrstündigem API-Ausfall
DeepSeeks API war teilweise rund fünf Stunden nicht erreichbar. Als Entschädigung erstattet das Unternehmen eine Woche Ausgaben in Form von Guthaben.
Wenn Ihr Code zwischen 00:11 und 05:04 UTC am 15. Oktober DeepSeeks API aufgerufen hat, sprach er mit einem Dienst, den DeepSeeks eigene Statusseite als teilweise ausgefallen markierte. Das ist 08:11 bis 13:04 in Peking, ein ganzer Werktagmorgen dort, und 17:11 bis 22:04 am 14. Oktober in Kalifornien.
Noch am selben Tag sandte DeepSeek den API-Kunden einen Entschädigungshinweis. Laut The Paper verspricht das Unternehmen, jedem Konto die Ausgaben der letzten sieben Tage in voller Höhe zurückzuerstatten: "将按账号7日内（10.8-10.14）的消耗金额以赠金形式全额返还", was bedeutet: "Der vom Konto innerhalb von 7 Tagen (10.8–10.14) verbrauchte Betrag wird in voller Höhe als Guthaben zurückerstattet."
Das ist eine großzügige Wiedergutmachung. Was es nicht kann, ist Ihre Anwendung weiter antworten zu lassen, während die API ausfällt, und dieser Teil liegt weiterhin bei Ihnen.
Der Vorfall auf status.deepseek.com trägt den Titel "DeepSeek 网页/API 部分中断" (DeepSeek Web/API teilweise nicht verfügbar) und listet drei betroffene Komponenten auf: den Chat-Dienst (对话服务), den DeepSeek V4 Pro API-Dienst und den DeepSeek V4.1 Flash API-Dienst. Seine Zeitleiste, in UTC am 15. Oktober:
Die Seite beziffert die Gesamtdauer auf 4 Stunden und 52 Minuten. Caixin berichtet, dass Web und App ab etwa 8:00 Uhr Pekinger Zeit "服务器暂时不可用" (Server vorübergehend nicht verfügbar) anzeigten und dass der Chat-Dienst ab 9:08 Uhr vollständig ausgefallen war. TechNode berichtet ebenfalls von dem Ausfall, der Chat und beide API-Modelle betraf.
DeepSeek hat nicht gesagt, was fehlgeschlagen ist. In dem von IT之家 wiedergegebenen Entschädigungshinweis heißt es, das Unternehmen habe eine umfassende Überprüfung der Dienststabilität eingeleitet und werde einzelne Abhängigkeitspunkte beseitigen. Wenn ein einziger Vorfall zusammen ein Chat-Produkt und zwei API-Modelle außer Betrieb setzt, passt diese Formulierung: Etwas darunter war geteilt.
Eine geteilte Abhängigkeit unter drei Diensten: Das Chat-Produkt und beide API-Modelle fielen im selben Vorfall aus.
Die Bedingungen, wie von The Paper und IT之家 berichtet:
DeepSeeks Preisseite ergänzt das Detail, das für Ihre nächste Rechnung wichtig ist: "当充值余额与赠送余额同时存在时，优先扣减赠送余额。" Wenn Sie sowohl ein aufgeladenes Guthaben als auch ein Bonusguthaben haben, wird zuerst das Bonusguthaben verwendet. Das Guthaben wird also vor Ihrem Geld ausgegeben, sobald es eingeht.
Das Guthaben orientiert sich an Ihren bisherigen Ausgaben, nicht an Ihrem Verlust. Wenn Sie vom 8. bis 14. Oktober viel ausgegeben haben, erhalten Sie viel zurück. Wenn Sie in dieser Woche noch prototypisiert haben, erhalten Sie wenig, selbst wenn der Ausfall am 15. Oktober Ihren Launch traf.
Das Guthaben endet auch an Ihrer Rechnung. Die Anfragen, die Ihr Produkt nicht beantworten konnte, die sich auftürmenden Wiederholungsversuche und die folgenden Support-Tickets sind darin nicht enthalten.
Der Hinweis sagt, so wie berichtet, nicht, ob das Guthaben abläuft. Prüfen Sie Ihre Guthabenseite auf der DeepSeek-Plattform, statt es anzunehmen.
Caixin zählt seit September 13 Störungen. Die meisten waren beeinträchtigte Leistung bei Web und API, und vier betrafen partielle Ausfälle von Web und API. Am 15. Oktober zeigte die Statusseite eine Verfügbarkeit für Juli bis Oktober 2026 von 99,74 Prozent für den V4 Pro API-Dienst und 99,47 Prozent für den V4.1 Flash API-Dienst.
V4.1 Flash ist neu. DeepSeek kündigte es am 10. September an und nennt es "das kleinste Modell in unserer neuen Architekturfamilie", in der API als deepseek-flash bereitgestellt. Ein Newsletter verbindet die Serie von Vorfällen mit der Nachfrage nach dem neuen Modell. DeepSeek hat das nicht gesagt, betrachten Sie es also als Vermutung.
Nichts davon macht DeepSeek ungewöhnlich anfällig. Jede gehostete Modell-API hat schlechte Morgen. Die Lektion ist dieselbe, die DeepSeek in seinen eigenen Hinweis geschrieben hat: eine Abhängigkeit unter allem ist ein Risiko, und Ihre Anwendung hat dasselbe Problem, wenn jeder LLM-Aufruf an einen Anbieter geht.
DeepSeeks API-Dokumentation sagt, dass die API mit dem OpenAI-Format kompatibel ist, unter der Base-URL https://api.deepseek.com, und zeigt, wie sie mit dem offiziellen OpenAI Node SDK funktioniert. Das macht einen Fallback günstig: ein zweiter Client mit einer anderen Base-URL und einem anderen Modell.
Führen Sie bei den Fehlern, die ein Ausfall erzeugt, einen Failover durch, und nur bei diesen.
import OpenAI from " openai "; type Msg = OpenAI. Chat. ChatCompletionMessageParam; const primary = new OpenAI ({ baseURL: " https://api.deepseek.com ", apiKey: process. env.
DEEPSEEK_API_KEY, timeout: 20 _000, maxRetries: 1, }); const fallback = new OpenAI ({ baseURL: process. env. FALLBACK_BASE_URL, apiKey: process. env. FALLBACK_API_KEY, timeout: 20 _000, maxRetries: 1, }); function shouldFailOver ( err: unknown ): boolean { if (! ( err instanceof OpenAI.
APIError )) return false; const s = err. status; return s === undefined || s === 429 || s >= 500; } export async function chat ( messages: Msg []) { try { return await primary. chat. completions. create ({ model: " deepseek-flash ", messages, }); } catch ( err ) { if (! shouldFailOver ( err )) throw err; return fallback. chat. completions. create ({ model: process. env. FALLBACK_MODEL?? "", messages, }); } } Enter fullscreen mode Exit fullscreen mode Einige Entscheidungen darin sind bewusst getroffen:
Ein anderes Modell kann andere Antworten liefern, also führen Sie, wenn Sie strukturierte Ausgaben parsen, Ihre Evals auch gegen das Fallback-Modell aus. Und protokollieren Sie, welcher Anbieter jede Anfrage bedient hat, sonst wissen Sie nicht, wie oft Sie auf der Backup-Lösung laufen.
Ich habe das selbst nicht gegen DeepSeeks API getestet. Das Muster ist eine einfache SDK-Nutzung, und es sollte bei jedem Anbieter, der das OpenAI-Format spricht, gleich funktionieren.
Jedes Design im System Design Pocket Guide: Interviews läuft auf solche Abwägungen hinaus: was jede Abhängigkeit kostet, wenn sie ausfällt, und was Sie zahlen, um das zu überstehen. Eine Modell-API ist eine weitere Abhängigkeit in dieser Liste, und der 15. Oktober war eine Erinnerung, dafür zu entwerfen, dass sie ausfällt.
Wenn das Ding, das eine Modell-API aufruft, Ihr Coding-Agent ist, baue ich Hermes IDE, wägen Sie das also entsprechend ab. Er lässt Sie Agent, Modell und Konto pro Aufgabe wählen, und wenn ein Agent sein Nutzungslimit erreicht, können Sie die Aufgabe in einem anderen fortsetzen. Er ist kostenlos herunterladbar, als Quellcode unter BSL 1.1 verfügbar, läuft auf macOS, Windows und Linux und ist auf GitHub. Er steht in keiner Verbindung zu Nous Research, DeepSeek oder einem Agent-Anbieter.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
If your code called DeepSeek's API between 00:11 and 05:04 UTC on October 15, it was talking to a service that DeepSeek's own status page marked as partially down. That is 08:11 to 13:04 in Beijing, a whole weekday morning there, and 17:11 to 22:04 on October 14 in California.
Later that day DeepSeek sent API customers a compensation notice. According to The Paper, it promises to return each account's spend from the previous seven days in full: "将按账号7日内（10.8-10.14）的消耗金额以赠金形式全额返还", which reads as "the amount consumed by the account over 7 days (10.8–10.14) will be returned in full as bonus credit."
That is a generous make-good. What it can't do is keep your app answering while the API is failing, and that part is still on you.
The incident on status.deepseek.com is titled "DeepSeek 网页/API 部分中断" (DeepSeek web/API partially unavailable) and lists three affected components: the chat service (对话服务), the DeepSeek V4 Pro API service and the DeepSeek V4.1 Flash API service. Its timeline, in UTC on October 15:
The page puts the total at 4 hours 52 minutes. Caixin reports that the web and app were showing "服务器暂时不可用" (server temporarily unavailable) from around 8:00 Beijing time, and that the chat service was fully down from 9:08. TechNode also reports the outage across chat and both API models.
DeepSeek has not said what failed. The compensation notice, reproduced by IT之家, says the company has started a full review of service stability and will remove single points of dependency. When one incident takes down a chat product and two API models together, that wording fits: something underneath was shared.
One shared dependency under three services: the chat product and both API models went down in the same incident.
The terms, as reported by The Paper and IT之家:
DeepSeek's pricing page adds the detail that matters for your next invoice: "当充值余额与赠送余额同时存在时，优先扣减赠送余额。" When you have both a top-up balance and a bonus balance, the bonus balance is used first. So the credit is spent before your cash, once it lands.
The credit tracks your past spend, not your loss. If you spent a lot from October 8 to 14, you get a lot back. If you were still prototyping that week, you get a little, even if the October 15 outage hit your launch.
The credit also stops at your bill. The requests your product failed to answer, the retries that piled up and the support tickets that followed aren't in it.
The notice, as reported, doesn't say whether the credit expires. Check your balance page on the DeepSeek platform rather than assuming.
Caixin counts 13 faults since September. Most were degraded performance on web and API, and four involved partial outages of web and API. On October 15, the status page showed uptime for July to October 2026 of 99.74% for the V4 Pro API service and 99.47% for the V4.1 Flash API service.
V4.1 Flash is new. DeepSeek announced it on September 10 and calls it "the smallest model in our new architecture family," served in the API as deepseek-flash. One newsletter connects the run of incidents to demand for the new model. DeepSeek hasn't said that, so treat it as a guess.
None of this makes DeepSeek unusually fragile. Every hosted model API has bad mornings. The lesson is the same one DeepSeek wrote into its own notice: one dependency under everything is a risk, and your app has the same problem if every LLM call goes to one provider.
DeepSeek's API docs say the API is compatible with the OpenAI format, at the base URL https://api.deepseek.com, and they show it working with the official OpenAI Node SDK. That makes a fallback cheap: a second client with a different base URL and model.
Fail over on the errors an outage produces, and only on those.
import OpenAI from " openai "; type Msg = OpenAI. Chat. ChatCompletionMessageParam; const primary = new OpenAI ({ baseURL: " https://api.deepseek.com ", apiKey: process. env.
DEEPSEEK_API_KEY, timeout: 20 _000, maxRetries: 1, }); const fallback = new OpenAI ({ baseURL: process. env. FALLBACK_BASE_URL, apiKey: process. env. FALLBACK_API_KEY, timeout: 20 _000, maxRetries: 1, }); function shouldFailOver ( err: unknown ): boolean { if (! ( err instanceof OpenAI.
APIError )) return false; const s = err. status; return s === undefined || s === 429 || s >= 500; } export async function chat ( messages: Msg []) { try { return await primary. chat. completions. create ({ model: " deepseek-flash ", messages, }); } catch ( err ) { if (! shouldFailOver ( err )) throw err; return fallback. chat. completions. create ({ model: process. env. FALLBACK_MODEL?? "", messages, }); } } Enter fullscreen mode Exit fullscreen mode A few choices in there are deliberate:
A different model can give different answers, so if you parse structured output, run your evals against the fallback model too. And log which provider served each request, or you won't know how often you're running on the backup.
I haven't run this against DeepSeek's API myself. The pattern is plain SDK usage, and it should work the same for any provider that speaks the OpenAI format.
Every design in the System Design Pocket Guide: Interviews comes down to trade-offs like this one: what each dependency costs you when it fails, and what you pay to survive that. A model API is one more dependency in that list, and October 15 was a reminder to design for it going away.
If the thing calling a model API is your coding agent, I build Hermes IDE, so weigh this with that in mind. It lets you pick the agent, model and account per task, and when one agent hits its usage limit you can continue the task in another. It's free to download, source-available under BSL 1.1, runs on macOS, Windows and Linux, and is on GitHub. It isn't affiliated with Nous Research, DeepSeek or any agent vendor.