Was ein Entwickler tun sollte, wenn ChatGPT ausfällt

ChatGPT liegt. Twitter ist eine Galerie von Fehlerbildschirmen. Ihr Pull Request wartet weiter. Der Ausfall ist nicht die Story. Die Story ist, ob Sie einfrieren oder weiter liefern.

OpenAI war 2023, 2024, 2025 und 2026 dunkel. An stilleren Tagen auch Claude, Gemini und Copilot. Die nützliche Frage ist nicht „passiert das wieder“. Sie lautet: was ist in der nächsten Stunde wirklich blockiert - und was fühlt sich nur so an, weil der Chat-Tab eine 500 wirft.

Mischen Sie nicht zwei Vorfälle. Sie haben einen Copiloten verloren. Oder die OpenAI-Calls in Ihrem Produkt werfen 500. Das eine ist ein Workflow-Problem. Das andere ist ein Incident. Das sind verschiedene Räume.

1. Die ersten fünf Minuten: ist es wirklich down?

Aktualisieren ist keine Diagnose. Bevor Sie drei andere Chats und einen Thread über „das Ende der KI“ öffnen, nehmen Sie sich fünf Minuten, um den Fehler zu benennen.

• Prüfen Sie status.openai.com, dann status.anthropic.com und den Google-AI-Status, falls Sie die schon nutzen. Downdetector ist Stimmung. Die Vendor-Statusseite ist ein Signal.
• ChatGPT die Website ist nicht die API, und beides ist nicht Cursor. chatgpt.com kann tot sein, während gpt-4o im Editor oder Claude im selben Editor noch antwortet. Benennen Sie die Fläche: Web-App, API, Copilot, Modellwahl in Cursor.
• Schließen Sie Ihre Seite aus: VPN, DNS, Firmenproxy, Werbeblocker, abgelaufene Session. Free-Tier-Limits sehen aus wie ein Ausfall, wenn Sie eine Stunde lang dieselbe Datei einfügen.
• Wenn die Vendor-Statusseite für Ihre Region rot ist, hören Sie auf, vierzigmal zu aktualisieren. Sie wünschen es nicht zurück. Fläche wechseln oder Aufgabe wechseln.

2. Tauschen Sie den Chat, nicht das ganze Hirn

Um 14 Uhr brauchen Sie keine neue Arbeitsphilosophie. Sie brauchen ein anderes Modell, das das Ticket zu Ende bringt. Melden Sie sich bei einer Alternative an und machen Sie dieselbe Aufgabe weiter. Migrieren Sie nicht mitten im Ausfall Ihren „Stack“.

• Claude (Anthropic): oft stärker bei langen Diffs und vorsichtigen Refactors. Wenn Sie den Tab schon haben, ist das die erste Tür.
• Gemini / Google AI Studio: nützlich, wenn Sie eine Zweitmeinung brauchen oder ein Modell, das noch Quota hat. Keine Religion. Ein Ersatzakku.
• Cursor, Claude Code, Copilot, Windsurf: wenn die IDE schon ein anderes Modell verdrahtet hat, wechseln Sie den Picker, bevor Sie einen Browser-Chat öffnen. Der Repo-Kontext ist schon da. Dafür gibt es den agentischen Editor.
• Doc-Suche, GitHub Issues und das offizielle Changelog schlagen eine halluzinierte API, wenn die Frage lautet „hat Next.js das umbenannt“. Ein LLM ist ein schneller Junior. Das Changelog ist die Quelle.

3. Lokale Modelle: wann sie den Nachmittag retten

Ollama, LM Studio, llama.cpp - einem Modell auf dem Laptop ist egal, dass chatgpt.com eine 500 wirft. Es kennt auch nicht das Next.js-Release von letzter Woche. Setzen Sie es für die richtigen Jobs ein.

• Gut: eine Funktion aus eingefügtem Kontext zu Ende schreiben, einen Stacktrace erklären, eine Regex umschreiben, eine Commit-Message entwerfen, aus Notizen einen Testnamen machen.
• Schlecht: Architektur eines Repos, das das Modell nie gesehen hat; „wie heißt die aktuelle App-Router-API“; alles, das mit der Doku von diesem Monat übereinstimmen muss.
• Wenn Sie noch nie ein lokales Modell geholt haben, ist ein Ausfall ein schlechter Startzeitpunkt. Machen Sie es an einem ruhigen Freitag: Ollama installieren, ein 7B- oder 14B-Instruct-Modell ziehen, einen echten Prompt aus dem Job laufen lassen. Dreißig Minuten, einmal.

4. Arbeit, die ChatGPT nie gebraucht hat

Der Stacktrace ist noch da. Der fehlschlagende Test ist noch rot. Git hat immer noch Blame. Ein Ausfall erinnert unhöflich daran, dass das Modell nie die Quelle der Wahrheit war - es war ein schneller Weg, mit ihr zu sprechen.

• Lesen Sie den Fehler. Nicht das Vibe des Fehlers - die Datei, die Zeile, die Meldung. Dann öffnen Sie diese Datei.
• git blame, git log -p, die letzten drei PRs auf diesem Pfad. Die meisten „mysteriösen“ Bugs sind letzter Dienstag.
• Offizielle Doku, MDN, Changelog der Library, eine minimale Reproduktion. Langsamer als ein Chat. Weniger Fiktion.
• Debugger, ein roter Test, ein console.log, den Sie wieder löschen. Gummiente: schreiben Sie das Problem in einen Kommentar. Oft erscheint die Antwort, bevor der Satz fertig ist.
• Wenn Sie ohne Chat keinen Schritt tun können, war die Aufgabe unterspezifiziert - oder Sie haben das Denken outgesourct. Das ist nützliche Information. Das ist kein Charakterfehler. Zuerst die Spec, dann der Code.

5. Wenn das Produkt die OpenAI-API nutzt

Das ist nicht „ich füge eine Stunde lang in Claude ein“. Das ist Incident Response. Nutzer sehen lieber „der Assistent ist vorübergehend nicht erreichbar“ als einen Spinner, der nie endet.

• Benennen Sie den Fehler: Ihr Key, Ihr Quota, Ihr Timeout oder deren 5xx. Dashboard und Statusseite widersprechen sich öfter, als Sie möchten. Loggen Sie den Statuscode, nicht nur „KI ist kaputt“.
• Wenn ein zweiter Anbieter schon verdrahtet ist, failover. Ich habe schon geschrieben, wie ein LLM hinter einem bezahlten Schritt sitzt und was ein Provider wirklich ist. Ein Ausfall ist ein schlechter Zeitpunkt, das zu entwerfen. Ein guter Zeitpunkt, ein vorbereitetes Flag umzulegen.
• Degradieren: Schreibvorgang in die Queue, aus den eigenen FAQs antworten, einen menschlichen Satz zeigen. Kein Retry-Sturm. Backoff. Ein Chatbot, der auf eine sterbende API einschlägt, macht den Incident für alle länger - auch für Sie.

6. Ein Kit, das Sie vor dem nächsten Ausfall zusammenbauen

Dreißig Minuten Setup an einem ruhigen Tag schlagen drei Stunden Twitter-Aktualisieren. Das wissen Sie schon. Der Ausfall ist nur die Rechnung.

• Ein zweiter Chat, in dem Sie schon angemeldet sind: Claude oder Gemini, mit Billing, das einen vollen Nachmittag übersteht. Ein Free-Tab, den Sie seit März nicht geöffnet haben, ist kein Plan.
• Die IDE mit mindestens zwei Modellen im Picker. Wenn Cursor nur OpenAI hat, haben Sie einen Single Point of Failure gekauft und es Workflow genannt.
• Ein lokales Instruct-Modell schon gezogen. Nicht „irgendwann probiere ich Ollama“. Schon gezogen.
• Eine Notizdatei für die One-Liner, die Sie den Chat immer fragen: git, docker, kubectl, das jq, das Sie nie behalten. Wenn der Chat tot ist, funktionieren die Notizen noch offline.
• Für das Produkt: ein Fallback-Flag, Backoff, und ein Satz für die UI, schon geschrieben. Incidents gehen schneller, wenn Sie den Text nicht in Slack erfinden.

7. Die Lektion, die niemand mag

ChatGPT ist ein schneller Junior, der das Internet gelesen hat und keinen Ihrer Produktionsvorfälle. Wenn dieser Junior im Urlaub ist, muss der Senior trotzdem liefern. Ich nutze Agenten jeden Tag. Ich muss trotzdem Diffs lesen, Tests laufen lassen und wissen, wo die Doku liegt.

Ausfälle werden weiterkommen. Modelle werden weiter die Namen wechseln. Die Fähigkeit, die überlebt, ist immer noch: das Ergebnis spezifizieren, den Fehler debuggen, Verantwortung für den Merge übernehmen. Ich habe schon geschrieben, wie Vibe Coding die Disziplin multipliziert, die Sie haben - und wie ein vager Prompt das Chaos schneller ausliefert. Ein Nachmittag ohne ChatGPT ist derselbe Test, unbezahlt.

Fazit: weiter liefern, einen Ersatz bereithalten

Prüfen Sie die Statusseite. Benennen Sie die Fläche. Modell wechseln oder Aufgabe wechseln. Wenn die API das Produkt ist, degradieren Sie sie - tun Sie nicht so, als wäre der Spinner ein Feature. Dann, an einem ruhigen Tag, verdrahten Sie den Ersatz: zweiter Chat, zweites Modell im Editor, ein lokaler Pull, ein Fallback-Flag.

Und einmal im Monat: Chat zu, Ticket trotzdem zu Ende. Nicht aus Nostalgie. Damit der nächste Ausfall eine Unannehmlichkeit ist, kein Blocker. :)