Selected model is at capacity: Codex-Fehler, Maßnahmen und Nutzungslimits

„Selected model is at capacity“ ist ein Fehler, den Codex als Serverüberlastung einordnet. Wir haben die Zuordnung der Meldung im öffentlichen Code von OpenAI geprüft und dieselbe vollständige Meldung zusammen mit serverOverloaded im Ausführungsverlauf dieses Computers gefunden. Dieser Fehler ist von einem ausgeschöpften Nutzungskontingent oder einem PC-Defekt zu unterscheiden. Weder die öffentlichen Informationen noch die Aufzeichnungen auf diesem Computer belegen jedoch, wodurch die Überlastung verursacht wurde.

Selected model is at capacity. Please try a different model.

Was passiert? Das zeigen die offiziellen Störungsberichte

Die Meldung besagt, dass das ausgewählte Modell seine Kapazitätsgrenze erreicht hat, und fordert Sie auf, ein anderes Modell zu versuchen. Es gibt keinen Beleg dafür, dass „capacity“ hier den Arbeitsspeicher oder Speicherplatz Ihres PCs meint. Die offizielle Statusseite von OpenAI dokumentiert Dienststörungen mit dieser Meldung.

Diese beiden Berichte belegen, dass dieselbe Meldung bei Dienststörungen auftreten kann und ein Modellwechsel nicht immer hilft. Aus der Zahl veröffentlichter Störungsberichte lässt sich weder die Häufigkeit des Fehlers ableiten noch, dass Ihr Fehler dieselbe Ursache wie eine frühere Störung hatte. Die Datumsangaben entsprechen den offiziellen Seiten; deren Uhrzeiten haben wir nicht in die japanische Standardzeit umgerechnet.

Keiner der beiden Berichte veröffentlicht eine grundlegende Ursache, etwa einen bestimmten Hardwareengpass oder einen Fehler beim Kontowechsel. Aussagen wie „Es gibt nicht genug GPUs“ oder „Die Pro-Authentifizierung ist defekt“ gehen über die geprüften Informationen hinaus. Wir haben die offiziellen Originalquellen am 1. Oktober 2026 geprüft und unterscheiden belegte Tatsachen von unseren Empfehlungen.

Unterschiede zu Nutzungslimits, 401 und thread not found

Diese Probleme können alle wie ein Stillstand wirken, erfordern aber unterschiedliche Prüfungen. Bei einem Kapazitätsfehler prüfen Sie zunächst sowohl die vollständige Meldung auf dem Bildschirm als auch Ihren Nutzungsstatus. Bei demselben Konto können verschiedene Problemtypen auftreten.

Verbleibendes Kontingent in der Nutzungsanzeige prüfen

OpenAIs Leitfaden zu Preisen und Nutzung verweist zur Prüfung der aktuellen Limits auf das Nutzungsdashboard. Während einer Codex-CLI-Sitzung können Sie auch /status verwenden. Eine Prüfung unmittelbar nach dem Fehler erleichtert den Vergleich mit dem zu diesem Zeitpunkt verbleibenden Kontingent.

Der offizielle Leitfaden erklärt außerdem, dass bereits laufende Arbeit unter Fair-Use-Bedingungen fortgesetzt werden kann, selbst wenn während der Verarbeitung ein Nutzungslimit erreicht wird. Deshalb gilt: Ein Fehler mit anschließendem Abschlussbericht belegt allein nicht, ob ein Limit erreicht wurde. Umgekehrt können Dienststörungen auch bei großzügigem Restkontingent auftreten. Informationen zu enthaltenen Kontingenten und zusätzlichen Credits finden Sie in unserem Vergleich der ChatGPT-Pro-Tarife.

Bei einem 401-Fehler zuerst die Anmeldemethode prüfen

Der Leitfaden zur Codex-Authentifizierung unterscheidet zwischen der Anmeldung mit ChatGPT und mit einem API-Schlüssel. In der Desktop-App zeigt das Profilmenü das aktive Konto oder den API-Schlüsselstatus. In der CLI verwenden Sie codex login status.

Auch wenn bei einer ChatGPT-Anmeldung „Incorrect API key“ erscheint, belegt die Anzeige allein nicht, dass Sie einen falschen Schlüssel eingerichtet haben. Welche Zugangsdaten abgelehnt wurden, muss gesondert untersucht werden. Ein Kapazitätsfehler ist kein Grund, sich sofort abzumelden oder Authentifizierungsdateien zu löschen. Bei Verwendung eines API-Schlüssels fallen die üblichen API-Gebühren zusätzlich zum ChatGPT-Abonnement an.

Bei der Meldung thread not found hilft unsere Untersuchung mit Lösungsansätzen zum Codex-Fehler „thread not found“. Frühere Authentifizierungs- oder Chatfehler auf demselben PC belegen keinen ursächlichen Zusammenhang mit dem aktuellen Kapazitätsfehler.

API-Fehler mit HTTP 503 von der App-Meldung unterscheiden

Der Leitfaden zu OpenAI-API-Fehlercodes beschreibt HTTP 503, service_unavailable_error und server_is_overloaded als Hinweise auf eine vorübergehende Modellüberlastung. HTTP 429 umfasst Fehler zu Anfragehäufigkeit oder Nutzungslimits, HTTP 401 betrifft die Authentifizierung.

Schritte zur Fortsetzung Ihrer Arbeit

Die folgenden Empfehlungen beruhen auf offiziellen Störungsberichten, Nutzungsleitfäden und allgemeiner Fehlerbehebungsdokumentation. Sie sind nicht als garantierte Lösung speziell für diesen Fehler veröffentlicht.

1. Prompt und zuletzt abgeschlossene Arbeit sichern

Wenn Ihr noch nicht gesendeter Prompt sichtbar ist, kopieren Sie ihn und sichern Sie den letzten Abschlussbericht oder den Stand geänderter Dateien. Dokumentieren Sie vor dem Schließen oder Wechseln des Chats, was Sie angefordert haben und wie viel abgeschlossen wurde. Das erleichtert die Fortsetzung.

Eine Fehlermeldung allein beweist nicht, dass keine Dateien bearbeitet oder Befehle ausgeführt wurden. Prüfen Sie bei Entwicklung mit Git den Diff oder führen Sie git status aus, bevor Sie dieselbe Änderung erneut anfordern. Bei Veröffentlichung, Nachrichtenversand oder Käufen wiederholen Sie eine Anweisung erst, nachdem Sie ihr Ergebnis geprüft haben.

2. Kurz warten und die offizielle Statusseite prüfen

Öffnen Sie OpenAI Status und prüfen Sie Störungen bei Codex oder der Modellauswahl. Vergleichen Sie den Fehlerzeitpunkt mit dem Zeitraum der Störung, statt nur ihren aktuellen Status anzusehen. Eine frühere Störung mit demselben Namen bedeutet nicht, dass diese noch anhält.

Bei API-Überlastung empfiehlt die offizielle Dokumentation, mindestens die in Retry-After angegebene Zeit zu warten, sofern dieser Header vorliegt. Andernfalls sollen die Abstände zwischen erneuten Versuchen vergrößert werden. Für App-Nutzer konnten wir keine feste Wartezeit in Sekunden bestätigen, wenn keine angezeigt wird. Wir empfehlen, vor einem neuen Versuch kurz zu warten, statt Anfragen rasch hintereinander zu wiederholen. Bei einer gemeldeten Störung beachten Sie die offiziellen Wiederherstellungsberichte.

Die Statusseite zeigt zusammengefasste Informationen. Sie bildet die Situation eines bestimmten Kontos oder Modells möglicherweise nicht vollständig ab. Eine nicht aufgeführte Störung beweist keinen PC-Defekt.

3. Nutzung prüfen und bei Eile ein anderes Modell erwägen

Prüfen Sie Restkontingent und Rücksetzungszeitpunkt. Wird ausdrücklich ein Nutzungslimit gemeldet, richten Sie Ihre Entscheidung nach diesem Hinweis. Wenn nur ein Kapazitätsfehler angezeigt wird, betrachten Sie zusätzliche Credits oder eine kostenpflichtige Rücksetzung nicht als Wiederherstellungsmaßnahme. Die Wiederherstellung Ihres Kontingents und die Frage, ob das Modell Anfragen annehmen kann, sind getrennte Dinge.

Der offizielle Leitfaden zur Modellauswahl erklärt, dass sich die Steuerelemente für Modell und Denkaufwand in der Desktop-App unter dem Eingabefeld befinden. In der interaktiven CLI verwenden Sie /model. Die verfügbaren Modelle unterscheiden sich je nach Konto, Client und weiteren Faktoren. Gehen Sie deshalb nicht davon aus, dass ein Modell verfügbar ist, das Ihre Oberfläche nicht anzeigt.

Ein Modellwechsel kann Antworten und Verbrauch verändern. Es gibt keinen Beleg dafür, zur Vermeidung von Kapazitätsfehlern immer das höchste Modell zu wählen. Prüfen Sie bei der Übergabe komplexer Implementierungs- oder Entwurfsarbeiten die neuen Ergebnisse anhand von Diffs und Tests. Weitere Orientierung bietet unser Generationenvergleich und Auswahlleitfaden zu GPT Sol.

4. Bei eingefrorener App deren Reaktion getrennt untersuchen

Unterscheiden Sie einen Kapazitätsfehler von nicht reagierenden Eingaben, einem Terminal oder der App-Oberfläche. Für scheinbar festgefahrene Chats empfiehlt die offizielle Fehlerbehebung, ausstehende Genehmigungen zu prüfen, das Terminal mit einem einfachen Befehl zu testen und eine kleine Anfrage in einem neuen Chat zu versuchen.

Wenn das Terminal weiter festhängt, empfiehlt der Leitfaden, vor einem App-Neustart den Abschluss aktiver Chats abzuwarten. Das betrifft eine allgemeine fehlende Reaktion; es wird nicht behauptet, dass ein Neustart einen serverseitigen Kapazitätsengpass behebt. Prüfen Sie zuerst den Stand anderer noch laufender Chats.

Wenn Sie in einem neuen Chat fortfahren, nennen Sie kurz Ziel, Arbeitsordner, abgeschlossene Änderungen und offene Aufgaben. Senden Sie nicht nur „Weiter“, in der Annahme, der gesamte frühere Gesprächsverlauf sei verfügbar. Ein neuer Chat nutzt denselben Dienst und umgeht den Kapazitätsfehler daher nicht garantiert.

Was bei erneutem Auftreten dokumentieren?

Bewahren Sie bei wiederholtem Auftreten Belege für eine spätere Untersuchung auf. Wenn Sie diese vor wiederholten Einstellungsänderungen erfassen, bleiben die Bedingungen des Fehlers nachvollziehbarer.

Je nach vorhandenen Aufzeichnungen lässt sich möglicherweise nicht bestätigen, ob das in den Einstellungen gewählte Modell tatsächlich für die fehlgeschlagene Anfrage verwendet wurde. Wenn Sie nur die sichtbare Einstellung erfasst haben, beschreiben Sie auch nur diesen Beleg. Ebenso beweist eine Wiederherstellung direkt nach dem Modellwechsel nicht dessen Wirksamkeit: Der Dienst könnte gleichzeitig wiederhergestellt worden sein.

Der offizielle Leitfaden erklärt, wie Sie durch Eingabe von / im Nachrichtenfeld Feedback senden. Bei einem bestehenden Chat können Sie entscheiden, ob Sie den Gesprächsverlauf teilen. Entfernen Sie API-Schlüssel, E-Mail-Adressen, private Gespräche und interne Unternehmensinformationen aus versendeten Logs oder Screenshots. Die Schlüsselwerte oder Authentifizierungsdateien selbst müssen nicht veröffentlicht werden.

Ein Bericht mit Datum, Modell, exakter Meldung und angezeigtem Restkontingent ist hilfreicher als „Es geht ständig kaputt“. Ein HTTP-Code oder eine Anfrage-ID kann, sofern verfügbar, den Support unterstützen. Ergänzen Sie fehlende Angaben aber nicht durch Vermutungen.

Ergebnisse auf diesem Computer und offene Fragen

Nach wiederholten Meldungen eines Nutzers mit Screenshots ließ AI Arte Codex am 1. Oktober 2026 auf diesem Computer eine rein lesende Untersuchung von Nutzung und lokalen Logs durchführen. Die Paketversion der Windows-App war 26.928.3736.0. Wir haben nicht überprüft, ob bei den Fehlern dieselbe Version installiert war.

Die erste Suche fand den Fehler weder in 32.737 Einträgen der regulären Log-Datenbank noch in 15 Desktop-Log-Dateien oder 143 aktualisierten Sitzungsdateien. Nachdem ein Leser die Ergebnisse infrage stellte, prüften wir weitere Speicherorte und fanden Fehleraufzeichnungen in einer separaten Datenbank des Ausführungsverlaufs. Der ursprüngliche Suchumfang war unzureichend.

Bei der Nachuntersuchung waren 35 der 6.781 Gesprächsrunden im Ausführungsverlauf fehlgeschlagen. Über den gesamten aufgezeichneten Zeitraum enthielten 13 dieselbe vollständige Fehlermeldung und codexErrorInfo: serverOverloaded. Davon traten 12 in fünf Chats zwischen dem 30. September 2026 um 22:10:01 und dem 1. Oktober um 00:24:55 (JST) auf. Der Chat mit den vom Nutzer angehängten Fehlerscreenshots enthielt ebenfalls vier Fehler am 30. September um 22:15:06, 22:57:58, 23:12:31 und 23:24:38 mit übereinstimmenden Meldungen und Einordnungen. Dies sind aufgezeichnete Abschlusszeiten fehlgeschlagener Gesprächsrunden, keine Screenshot-Zeitstempel. Sie beschreiben die Aufzeichnungen dieses Computers, keine Fehlerquote für alle Nutzer.

Die mit der App ausgelieferte Codex CLI hatte Version 0.159.2. In den Fehlerdefinitionen des passenden öffentlichen Tags entspricht die vollständige Meldung ServerOverloaded und wird getrennt von ausgeschöpften Nutzungskontingenten eingeordnet. Der Code zur Stream-Verarbeitung wandelt server_is_overloaded in einen Überlastungsfehler um; der Code zur Umwandlung in die Anzeige verbindet ihn mit der vollständigen Meldung am Artikelanfang. Es gibt auch einen Pfad, der HTTP-503-Antworten mit demselben Fehlercode umwandelt. Fehler können jedoch ebenfalls innerhalb eines Streams eintreffen. Die angezeigte Meldung belegt daher keine HTTP-503-Antwort.

Festgestellt wurde, dass die Fehler als Serverüberlastung eingeordnet und gespeichert wurden. Die Aufzeichnungen zeigen nicht, ob tatsächlich ein GPU-Engpass, die Weiterleitung von Anfragen oder die Kapazitätssteuerung beteiligt war. Die Zusatzdetails der vier Fehler waren leer; ein HTTP-Code war nicht gespeichert. Bei der ersten Untersuchung waren 31 % des wöchentlichen Kontingents übrig und die normale Nutzung war möglich. Das war nicht das Restkontingent zum Fehlerzeitpunkt. Auch das tatsächlich bei diesen Anfragen verwendete Modell wurde nicht festgestellt.

Zu Authentifizierungsfehlern erklärt der offizielle Ursachenbericht einer gesonderten Störung vom 25. September, dass die irrtümliche Erkennung und Ungültigerklärung interner Dienstzugangsdaten bei über ChatGPT angemeldetem Codex zu 401- und 502-Fehlern führte. Das belegt nicht die Ursache der hier untersuchten Überlastungsfehler. Vermischen Sie diese offiziell erklärte interne Authentifizierungsstörung nicht mit den vorliegenden Überlastungsfehlern.

Bei dieser Untersuchung wurden weder Modelle oder Abonnements geändert noch kostenpflichtige Rücksetzungen verwendet oder Zugangsdaten gelöscht. Wir haben auch nicht absichtlich rasch wiederholte Anfragen gesendet, um das Problem nachzustellen. Daher gibt es keinen experimentellen Vergleich wirksamer Wiederherstellungsmaßnahmen. Wir trennen offiziell bestätigte Störungsbeispiele von Beobachtungen auf diesem einzelnen Computer.

Zusammenfassung: Erst den Fehler einordnen, dann handeln

Bei „Selected model is at capacity“ sichern Sie Ihren Prompt, warten kurz und prüfen Störungsberichte sowie Nutzung. Bei dringender Arbeit können Sie ein anderes verfügbares Modell erwägen, manche Störungen betreffen jedoch mehrere Modelle. Der Kapazitätsfehler allein rechtfertigt weder zusätzliche Ausgaben noch eine kostenpflichtige Rücksetzung oder das Löschen von Zugangsdaten.

Prüfen Sie bei 401 die Authentifizierung, bei thread not found den Zustand des Chats und bei einem Limithinweis den Nutzungsstatus. Zeitpunkt, vollständige Meldung, Modell und Restkontingent bei erneutem Auftreten zu dokumentieren, hilft der nächsten Untersuchung mehr als Einstellungsänderungen ohne bekannte Ursache.

Häufig gestellte Fragen

Kann das mit einem Pro-Abonnement passieren?

Der Nutzer dieses Artikels meldete dieselbe Nachricht mit einem Pro-Abonnement. Aus einem einzelnen Bericht lässt sich jedoch keine Fehlerhäufigkeit je Tarif ableiten. Die offiziellen Störungsberichte sagen nicht, dass Pro ausgenommen ist. Prüfen Sie das verbleibende Abonnementkontingent getrennt davon, ob das Modell zu diesem Zeitpunkt Arbeit annehmen kann.

Helfen zusätzliche Credits oder eine kostenpflichtige Rücksetzung?

Wir fanden keinen offiziellen Beleg dafür, dass diese Maßnahmen den Kapazitätsfehler beheben. Zusätzliche Credits und ähnliche Mechanismen betreffen Ihr eigenes Nutzungskontingent. Prüfen Sie zunächst, ob Sie tatsächlich ein Limit erreicht haben, und unterscheiden Sie die Wiederherstellung des Kontingents von der Behebung eines Kapazitätsfehlers.

Warum tritt der Fehler auch nach einem Modellwechsel auf?

Offizielle Störungsberichte beschreiben dieselbe Meldung bei mehreren Modellen. Ihr Auftreten bei einem anderen Modell beweist allein keinen PC- oder Kontodefekt. Prüfen Sie Störungen und Restkontingent und dokumentieren Sie erneute Versuche. Die öffentliche Dokumentation nennt kein Modell, das den Fehler garantiert vermeidet.

Sollte ich die App neu starten oder einen neuen Chat öffnen?

Wir konnten nicht feststellen, dass eine dieser Maßnahmen erforderlich ist. Sie können bei der Untersuchung einer nicht reagierenden App oder eines Terminals helfen, beheben aber nicht garantiert ein serverseitiges Kapazitätsproblem. Prüfen Sie andere laufende Arbeiten und sichern Sie Prompt, Änderungen und offene Aufgaben, bevor Sie entscheiden.