Unternehmerische Planung braucht Kontinuität. Wir teilen Mitarbeitende ein, vereinbaren Termine und organisieren Arbeitsschritte in einer bestimmten Reihenfolge. Eine offengelegte Nutzungsgrenze lässt sich in diese Planung einbeziehen. Geplante Wartungsarbeiten lassen sich berücksichtigen. Ein unerwarteter Stopp ohne klare Erklärung und ohne verlässliche Angabe, wann es weitergeht, ist deutlich schwerer zu handhaben.
Genau dieses Problem erlebe ich mit Codex von OpenAI. Die Meldung ist einfach:
Selected model is at capacity. Please try a different model.
Das ausgewählte Modell ist ausgelastet; man soll ein anderes versuchen. Die Folgen für den Geschäftsbetrieb sind weit weniger einfach. Was kann ich einem Kunden zusagen, wenn das Werkzeug mitten in der Arbeit ausfallen kann? Wie viel Zeit sollte ich für die Wiederaufnahme einplanen? Worauf kann ich mich mit einem Pro-Abonnement verlassen?
Modellkapazität und die Nutzungslimits eines Kontos sind unterschiedliche Fehlerkategorien. Diese Unterscheidung erklärt, warum trotz verbleibendem Kontingent ein Kapazitätsfehler auftreten kann. Sie zeigt zugleich eine Lücke bei der Nutzung eines kostenpflichtigen KI-Dienstes für die unternehmerische Planung.
Planen Sie einen Geschäftsprozess mit KI? Unsere Ingenieure auf Bali helfen Ihnen, die zugrunde liegende Software, Infrastruktur und mögliche Ausweichlösungen zu beurteilen. Sprechen Sie mit unseren Ingenieuren.
Ein Kontingent sagt uns nicht, ob die Arbeit weitergehen kann
Die öffentlich zugänglichen Fehlerdefinitionen von Codex ordnen genau diese Meldung einer Serverüberlastung zu – getrennt von einem aufgebrauchten Nutzungskontingent oder einer überschrittenen Quote. Auch die API-Dokumentation von OpenAI unterscheidet zwischen einem vorübergehend überlasteten Modell und Nutzungs- oder Ausgabenlimits. Diese Quellen erklären die Kategorien; sie diagnostizieren nicht die konkreten Anfragen in meinen Screenshots. Codex-Fehlerdefinitionen, OpenAI-Dokumentation zu Fehlern
Ein Nutzungskontingent beschreibt ein Budget für Aktivitäten. Bei Kapazität geht es darum, ob der Dienst in diesem Moment eine Anfrage annehmen kann. Ein verbleibendes Budget löst daher kein Verfügbarkeitsproblem.
Für ein Unternehmen entsteht damit etwas, das ich als weichen Begrenzungsfaktor bezeichnen würde: eine zusätzliche Einschränkung der tatsächlich möglichen Arbeit, deren Grenze für den Kunden unklar bleibt. Das beschreibt die praktische Wirkung und ist kein offizielles OpenAI-Limit. „Weich“ ist die Unbestimmtheit; die Unterbrechung kann einen vollständigen Stillstand bedeuten.
Ein sichtbares Kontingent hilft mir, den Verbrauch zu kalkulieren. Um eine Lieferung zu terminieren, brauche ich außerdem eine belastbare Grundlage für die Erwartung, dass die Arbeit weitergehen kann.
Die Unterbrechung kommt, nachdem die Arbeit begonnen hat
Meine Screenshots vom 30. Oktober 2026 zeigen die Kapazitätsmeldung in unterschiedlichen Arbeitsphasen. Eine frühere Desktop-Ansicht hält ein Planungsgespräch fest. Eine spätere Ansicht derselben benannten Aufgabe zeigt, wie der Assistent abgeschlossene Vorbereitungen und einige Änderungen an der Website meldet, während weitere Importe und Verknüpfungen noch laufen. Dann erscheint der Kapazitätshinweis mit einer Schaltfläche zum erneuten Versuch.
Bei einer anderen, auf dem Mobilgerät geöffneten Aufgabe erscheint die Warnung neben einer umfangreichen angezeigten Liste von Dateiänderungen. Im Agentenfenster sind drei Agenten weiterhin mit „Working“ gekennzeichnet. Diese Kennzeichnung belegt nicht, ob sie tatsächlich weiterarbeiteten, warteten oder einen veralteten Status anzeigten. Die für das Projekt verantwortliche Person muss den tatsächlichen Arbeitsstand erst ermitteln.
Die Screenshots beweisen keinen Arbeitsverlust. Sie zeigen, warum Unterbrechung und Ungewissheit eine kostspielige Kombination sind: Bevor es weitergehen kann, muss jemand feststellen, was abgeschlossen wurde, was noch aktiv ist und was der nächste Versuch auslösen wird.
Eine Schaltfläche zum erneuten Versuch bietet dem Kunden eine Handlungsmöglichkeit. Sie ist keine Einschätzung, wann das Projekt verlässlich fortgesetzt werden kann.
Andere zahlende Nutzer beschreiben dasselbe Problem
Es gibt öffentliche Berichte anderer Abonnenten, darunter Pro-Nutzer, nach deren Angaben noch Kontingent verfügbar war.
| Datum des Berichts | Vom Abonnenten geschilderte Erfahrung |
|---|---|
| 7. September 2026 | Ein Nutzer von Pro 20x meldete Kapazitätsfehler bei mehreren Modellen, obwohl noch etwa 80 % des Kontingents übrig waren. Neue Sitzungen und Modellwechsel hätten nicht geholfen. GitHub-Bericht |
| 23. Oktober 2026 | Ein Pro-Nutzer berichtete von Ausfällen seit dem Vortag, auch in Codex, obwohl noch mehr als die Hälfte seiner Quote verfügbar war. Neue Chats und Versuche zur Fehlerbehebung hätten den Zugriff nicht wiederhergestellt. Community-Bericht |
| 27. Oktober 2026 | Ein Pro-Nutzer berichtete von mehreren Tagen ohne nutzbaren Zugriff und einer Verbrauchsanzeige ohne Nutzung. Er beschrieb Ausfälle auf verschiedenen Geräten und in unterschiedlichen Netzwerken. Community-Bericht |
| 28. Oktober 2026 | Ein Abonnent, der seinen Tarif als Pro für 200 US-Dollar im Monat bezeichnete, schilderte etwa zwei Wochen mit häufigen Unterbrechungen. Er wandte ein, dass Modellwechsel den Grund für den Abschluss dieses Abonnements untergrüben. Community-Bericht |
| 28. Oktober 2026 | Ein Plus-Nutzer berichtete von wiederholten Kapazitätsfehlern innerhalb einer einzelnen Cloud-Aufgabe, die deren Abschluss verhinderten. GitHub-Bericht |
Dies sind individuelle Schilderungen, keine repräsentative Umfrage und keine unabhängig geprüften Messungen der Dienstqualität. Sie belegen, dass andere Nutzer dieselbe praktische Schwierigkeit melden. Sie zeigen weder, wie häufig die gesamte Kundschaft betroffen ist, noch, ob jeder Vorfall dieselbe Ursache hat.
Auch die Wiederherstellung verläuft unterschiedlich. Ein Desktop-Bericht wurde am 23. Oktober dahingehend aktualisiert, dass sich die Lage deutlich gebessert habe und erneute Versuche meist funktionierten, obwohl weiterhin gelegentliche Ausfälle auftraten. Das ist relevant: Manche Unterbrechungen lösen sich auf, doch die verfügbaren Berichte liefern keine verlässliche Wiederherstellungszeit, die ein Unternehmen für seine nächste Aufgabe einplanen könnte. Aktualisierung zur Wiederherstellung
Abonnementbedingungen können sich ändern, während Unternehmen damit planen
Neben der Verfügbarkeit des Modells gibt es eine weitere Unsicherheit: das im Abonnement enthaltene Kontingent selbst.
Ein Video zur geplanten Kürzung bei Pro 200 am 30. Oktober beschreibt eine Senkung vom Zwanzigfachen auf das Zehnfache des Plus-Kontingents bei unverändert 200 US-Dollar Monatsgebühr. Eine von einem Abonnenten veröffentlichte Kopie der früheren OpenAI-Mitteilung nennt außerdem eine geplante Reduzierung von 200 auf 100 wöchentliche GPT-6-Pro-Nachrichten in Chat sowie 62.500 vorübergehende Nutzungsguthaben im angegebenen Wert von 2.500 US-Dollar, die am 31. Dezember verfallen sollten. Das waren angekündigte Änderungen und damit etwas anderes als eine unerklärte Kapazitätsunterbrechung. Für diesen Artikel bereitgestelltes Video, Kopie der Mitteilung eines Abonnenten
Diese geplante Kürzung wurde abgesagt. Laut den OpenAI-Versionshinweisen vom 29. Oktober behalten Pro-200-Kunden, die bereits das höhere Work- und Codex-Kontingent haben, dieses bei. Kunden mit dem niedrigeren Kontingent werden auf dasselbe Niveau angehoben. Dieselbe Aktualisierung verdoppelt die Work- und Codex-Kontingente für Pro 100 und Pro 500. Sie bedeutet keine weitere Verdopplung für jeden bestehenden Pro-200-Abonnenten. OpenAI-Versionshinweise
Die aktuelle Pro-Hilfeseite bestätigt gesondert, dass das höhere wöchentliche Limit für GPT-6-Pro-Nachrichten erhalten bleibt und Pro-200-Konten mit niedrigerem Limit darauf angehoben werden. Chat-Nachrichtenlimits und die Nutzung von Work/Codex bleiben getrennte Kontingente. Es wäre deshalb falsch zu behaupten, eine der beiden geplanten Pro-200-Kürzungen trete heute in Kraft. Aktuelle Pro-Bedingungen
Die Rücknahme ist eine gute Nachricht für betroffene Abonnenten und verdient Anerkennung. Zugleich verändert sie die Geschichte: Statt einer wirksam werdenden Kürzung geht es nun darum, dass ein Unternehmen eine Ankündigung einordnen, sich darauf vorbereiten und anschließend eine Kehrtwende verarbeiten muss. Wer auf die frühere Mitteilung reagiert hat, hat möglicherweise bereits Zeit in den Vergleich von Alternativen oder die Überprüfung eines Arbeitsablaufs investiert.
Die Berechnungen im Video zeigen eine weitere Schwierigkeit: Der Prozentsatz hängt davon ab, was verglichen wird. Bei der dort angenommenen Token-Zusammensetzung und einer hypothetischen Halbierung des Budgets blieben beim Wechsel von GPT-6 Sol zu GPT-6.1 Sol etwa 76 % des Token-Volumens erhalten. Im selben vereinfachten Vergleich kauft ein halbes Budget bei GPT-6.1 Terra genauso viele Tokens wie ein volles Budget bei GPT-6.1 Sol. Keines dieser Ergebnisse bedeutet, dass dieselben Aufgaben in derselben Qualität erledigt werden. Verglichen werden unterschiedliche Modelle, und die geplante Budgetkürzung wurde inzwischen zurückgenommen.
Hinter einem Teil der Diskussion steht ein überprüfbares Preisverhältnis. Für Astra, Sol 6.1 und Terra 6.1 entsprechen die veröffentlichten Codex-Credit-Sätze bei Standardgeschwindigkeit für Eingaben, zwischengespeicherte Eingaben und Ausgaben zahlenmäßig dem 25-Fachen der jeweiligen Standard-API-Preise in US-Dollar. Dieser Vergleich allein belegt kein garantiertes Budget in API-Dollar innerhalb eines Abonnements. OpenAI trennt die API-Preise ausdrücklich von der im Abonnement enthaltenen Nutzung. Codex-Preise, API-Preise
Vorübergehende Zurücksetzungen erschweren die Bestimmung der Ausgangsbasis zusätzlich. Der im Video genannte Community-Tracker listet zwischen dem 5. und 27. Oktober zwölf Termine im Zusammenhang mit Zurücksetzungen auf, darunter eine zur späteren Nutzung vorgemerkte Zurücksetzung. Die Ankündigung einer Zurücksetzung belegt nicht, dass jeder Abonnent ein weiteres vollständiges Kontingent erhalten und ausgeschöpft hat. Ein arbeitsreicher Monat mit wiederholten Zurücksetzungen ist eine schwache Grundlage, um die dauerhaft nutzbare Kapazität einer normalen Woche einzuschätzen. Community-Tracker für Zurücksetzungen
Für die Kontinuität des Geschäftsbetriebs sind diese Unterschiede wichtig. Ein Kontingent, ein vorübergehendes Guthaben, eine zusätzliche Zurücksetzung im Rahmen einer Aktion und die Modellverfügbarkeit beantworten jeweils eine andere Frage. Klare, datierte Bedingungen sollten es Kunden ermöglichen, sie auseinanderzuhalten, ohne ihr Abonnement aus E-Mails, Videos und Beiträgen in sozialen Medien rekonstruieren zu müssen.
Die Absage der Kürzung erhält das höhere Kontingent als Planungsgrundlage. Sie belegt nicht, dass die hier beschriebenen Kapazitätsunterbrechungen behoben wurden.
Hat OpenAI mehr Zugang verkauft, als es zuverlässig bereitstellen kann?
Diese Frage ist berechtigt. Die vorliegenden Berichte beantworten sie nicht.
OpenAI gab am 31. März 2026 bekannt, 122 Milliarden US-Dollar an zugesagtem Kapital bei einer Bewertung nach der Finanzierungsrunde von 852 Milliarden US-Dollar eingeworben zu haben. Diese datierten Zahlen zeigen die enorme finanzielle Größenordnung. Sie messen nicht die freie Rechenkapazität, die zu einem bestimmten Zeitpunkt für ein bestimmtes Modell verfügbar ist. OpenAI-Mitteilung zur Finanzierung
Auch große Unternehmen können echte Engpässe erleben. Finanzierung wird nicht unmittelbar zu installierter Hardware, Strom oder verfügbarer Inferenzkapazität. Tatsächliche Beschränkungen können zudem gleichzeitig mit Entscheidungen darüber bestehen, wie der Zugang verteilt wird.
OpenAI beschreibt die Steuerung des Datenverkehrs in seiner API-Dokumentation offen: Ratenlimits helfen dabei, den Zugang zu verteilen und die Belastung der Infrastruktur zu steuern. Das belegt, dass es in der API Zuteilungsmechanismen gibt. Es belegt nicht, welche dieser Mechanismen – wenn überhaupt – die Ausfälle bei Codex-Abonnements erklären. OpenAI-Dokumentation zu Ratenlimits
Für die Schlussfolgerung, dass OpenAI seine Kapazitäten überverkauft, wären Belege zum verkauften Zugang, zur bereitgestellten Kapazität, zur erwarteten Nachfrage und zu den bei Kunden geweckten Zuverlässigkeitserwartungen erforderlich. Die Screenshots und Forenberichte liefern dieses vollständige Bild nicht.
Sie rechtfertigen jedoch die Forderung an OpenAI, die Lücke zwischen bezahltem und tatsächlich nutzbarem Zugang zu erklären. Kunden sollten diese Lücke nicht aus Fehlermeldungen erschließen müssen.
Die Meldung lenkt das Verhalten, auch wenn ihre Ursache unklar ist
Die Aufforderung, ein anderes Modell zu versuchen, lenkt den Kunden ausdrücklich zu einer anderen Wahl. Ob die Ursache eine vorübergehende Überlastung, eine Zuteilungsentscheidung oder ein Fehler ist: Der Kunde soll sich anpassen.
Das ist relevant, wenn das ausgewählte Modell Teil eines Arbeitsprozesses ist. Ein Unternehmen hat es möglicherweise nach Tests seiner Genauigkeit oder seiner Fähigkeit zur Bearbeitung einer schwierigen Aufgabe gewählt. Ein Ersatz kann eine erneute Prüfung erfordern. Ein Modellwechsel mitten in einem Auftrag kann deshalb zusätzliche Arbeit verursachen, selbst wenn er den Zugang wiederherstellt.
Manche Nutzer vermuten außerdem kontospezifische Einschränkungen. Der Verfasser des Beitrags vom 27. Oktober berichtet, eine KI-gestützte Supportantwort habe eine Einschränkung auf Kontoebene beschrieben. Das ist die Schilderung eines Supportaustauschs durch den Verfasser, kein unabhängig bestätigter Beleg für eine allgemeine Beschränkungspolitik. Sie verdient Untersuchung, statt als Beweis für gezielte Manipulation behandelt zu werden. Geschilderte Supporterfahrung
Die Unsicherheit selbst richtet Schaden an. Wenn Nutzer nicht erkennen können, ob sie eine Überlastung, einen Produktfehler oder eine Einschränkung erleben, füllt Misstrauen die Lücke, die die fehlende Erklärung hinterlässt.
Geschäftskontinuität braucht klarere Bedingungen für Unterbrechung und Wiederaufnahme
Betrachten wir ein Team, das die Veröffentlichung einer Website plant. Inhaltsvorbereitung, Umsetzung, Prüfung und Freigabe hängen voneinander ab. Stoppt eine KI-Aufgabe während der Umsetzung, muss das Team möglicherweise ihren Stand rekonstruieren, bevor die Prüfung beginnen kann. Selbst wenn alle abgeschlossenen Änderungen erhalten bleiben, kann sich der Liefertermin verschieben.
Das ist ein Beispiel für ein Planungsproblem, keine Behauptung, meine Screenshots belegten eine verpasste Veröffentlichung oder einen finanziellen Verlust. Es zeigt, warum nutzbare Kapazität über die Zahl in einer Kontingentanzeige hinaus wichtig ist.
Ein größeres Abonnementkontingent beantwortet, wie viel Aktivität ein Kunde verbrauchen darf. Es beantwortet für sich genommen nicht, wann ein gewähltes Modell nach einem Kapazitätsfehler wieder verfügbar sein wird. OpenAIs eigene Preisinformationen unterscheiden Nutzungskontingente und erklären, dass der Verbrauch von Modell und Aufgabe abhängt. Diese Angaben helfen bei der Verbrauchsplanung; einen Zeitplan für die Behebung der hier beschriebenen Unterbrechungen liefern sie nicht. OpenAI-Preisinformationen
Für die unternehmerische Planung wünsche ich mir von OpenAI Klarheit zu vier Punkten:
- Der Grund für den Stopp: Aufgebrauchtes Kontingent, Überlastung des Dienstes, Kontoeinschränkungen und Produktfehler sollten so weit unterschieden werden, wie das System sie feststellen kann.
- Die erwartete Wiederaufnahme: Es sollte erkennbar sein, ob Arbeit in einer Warteschlange steht, automatisch erneut versucht wird oder eine Nutzeraktion erfordert – mit einer Zeitschätzung, sofern eine verfügbar ist.
- Der Stand unfertiger Arbeit: Es sollte erklärt werden, was abgeschlossen wurde, was noch aktiv ist und an welcher Stelle die Fortsetzung beginnt.
- Der Wert und die Beständigkeit eines Tarifs: Neben dem regulären Kontingent, zeitlich begrenzten Aktionen und datierten Änderungen sollte klar sein, welche Verbesserungen bei Verfügbarkeit oder Kontinuität der Tarif bietet.
Wenn keine Zeitschätzung möglich ist, ist ein klarer Hinweis darauf hilfreicher, als den Kunden die Bedeutung einer sich verändernden Ladeanzeige erraten zu lassen.
Glaubwürdigkeit hängt davon ab, worauf Kunden sich verlassen können
Ein gelegentlicher Dienstausfall ist verständlich. Wiederholte Unterbrechungen ohne ausreichende Informationen für die Planung erschweren es, einem Anbieter eine betriebliche Abhängigkeit anzuvertrauen.
OpenAI muss keine unbegrenzte Rechenleistung anbieten, um dieses Problem anzugehen. Das Unternehmen muss seine betrieblichen Grenzen jedoch so verständlich machen, dass Kunden entscheiden können, wie viel Verantwortung sie dem Dienst übertragen.
Für meine künftige Planung werde ich ein Pro-Abonnement an abgeschlossener, überprüfter Arbeit und dem Aufwand zur Wiederaufnahme nach Unterbrechungen messen – ebenso wie an seinem nominellen Kontingent. Arbeit mit festen Terminen braucht eine brauchbare Ausweichlösung und ausreichend Zeit für menschliche Prüfung. Diese zusätzliche Vorbereitung gehört zu den Kosten, die entstehen, wenn man sich auf das Werkzeug verlässt.
Offen bleibt, ob der verkaufte Zugang der Kontinuität entspricht, die Unternehmen vernünftigerweise erwarten. Solange OpenAI diese Stopppunkte und die Bedingungen der Wiederaufnahme nicht klarer erklärt, wird die Unsicherheit seine Glaubwürdigkeit als verlässlicher Bestandteil betrieblicher Abläufe weiter schwächen.
Verlässliche Abläufe brauchen ingenieurtechnisches Know-how ebenso wie leistungsfähige KI-Werkzeuge. Bringen Sie Ihr nächstes Software-, Infrastruktur- oder Automatisierungsprojekt zu unserem Team auf Bali. Lassen Sie uns besprechen, wie sich Unterbrechungen und die Wiederaufnahme der Arbeit einplanen lassen. Besprechen Sie Ihr nächstes Projekt mit uns.
Quellen und Nutzerberichte geprüft am 30. Oktober 2026.
