Zwei "Code-Nuklearbomben" an einem Tag: OpenAI hat das erste Codex-Modell vorgestellt, das "Echtzeitkooperation im Vordergrund" hat, und Google hat Gemini Deep Think herausgebracht. Die Code-Kraft hat sich in die Weltspitze 8 geschoben.
1
OpenAI stellt neues Modell für Echtzeit-Codierung vor
Letzte Nacht hat OpenAI die Forschungs-Vorschauversion von GPT-5.3-Codex-Spark offiziell vorgestellt. Dies ist eine vereinfachte Version, die aus dem Hauptmodell GPT-5.3-Codex "abgeschnitten" wurde und zugleich das erste Modell von OpenAI, das speziell für Echtzeit-Codierungsszenarien (real-time coding) entwickelt wurde.
Was die Positionierung betrifft, soll Codex-Spark nicht das bestehende Codex ersetzen, sondern die Lücken in "Echtzeit-Interaktions"-Szenarien schließen. In der Vergangenheit war Codex besser für komplexe Aufgaben geeignet, die lange dauern. Das Ziel von Codex-Spark ist jedoch klar: Die Interaktionsverzögerung zwischen Mensch und Modell soll so gering wie möglich werden, nahezu "unmerklich".
Diese Veröffentlichung ist auch ein wichtiges Zwischenergebnis der Zusammenarbeit zwischen OpenAI und dem Chip-Startup Cerebras. Um die Abhängigkeit von Nvidia-Chips zu verringern, hat OpenAI letzten Monat ein über 10 Milliarden US-Dollar betragendes Abkommen unterzeichnet, um die Hardware von Cerebras zu nutzen und die Reaktionsgeschwindigkeit seiner Modelle zu verbessern. Codex-Spark gilt als erster technologischer Meilenstein dieser Zusammenarbeit.
Entwickelt für Echtzeit: Die Kernkompetenz von Codex-Spark ist "Geschwindigkeit"
In der offiziellen Definition ist Codex-Spark ein "Modell, das speziell für die Echtzeitnutzung von Codex entwickelt wurde". Es unterstützt gezielte Bearbeitungen, die Umgestaltung von Logiken oder die Optimierung von Benutzeroberflächen und ermöglicht die sofortige Ansicht der Ergebnisse. Hinter dieser Formulierung verbirgt sich eine neue Annahme über die Interaktionsweise.
In dem traditionellen AI-Codierungsablauf müssen Entwickler oft warten, bis das Modell eine relativ vollständige Inferenz und Generierung abgeschlossen hat, bevor sie auf der Grundlage der Ergebnisse die nächste Runde an Anpassungen vornehmen können. Dieser Ansatz ist bei komplexen Aufgaben notwendig, aber im täglichen Entwicklungsalltag - wie bei kleinen Codeänderungen, Logik-Umstrukturierungen oder Anpassungen der Benutzeroberfläche - wird die hohe Verzögerung zum Engpass für die Effizienz.
Codex-Spark richtet sich genau an solche häufig auftretenden, fragmentierten und auf sofortige Rückmeldungen extrem empfindlichen Nutzungsszenarien.
Laut OpenAI zeigt Codex-Spark bei der Ausführung von langlaufenden Aufgaben herausragende Vorteile. Es kann ohne menschliche Eingriffe stundenlang, tage- oder sogar wochenlang autonom laufen. Mit Codex-Spark unterstützt Codex nun sowohl komplexe langlaufende Aufgaben als auch die sofortige Erledigung von Arbeiten.
Bei der Veröffentlichung hat Codex-Spark ein Kontextfenster von 128k und unterstützt nur Text. Während der Forschungs-Vorschauphase wird Codex-Spark eine eigene Rate-Limitierung haben, und die Nutzung wird nicht in die Standard-Rate-Limitierung einbezogen. Wenn die Nachfrage jedoch hoch ist, können Benutzer möglicherweise auf Zugangseinschränkungen oder vorübergehende Warteschlangen stoßen, da die Zuverlässigkeit für verschiedene Benutzer ausgeglichen werden muss.
OpenAI hat auch angekündigt, dass Codex-Spark für interaktive Arbeiten optimiert ist, in denen Verzögerung genauso wichtig ist wie Intelligenz. Benutzer können in Echtzeit mit dem Modell zusammenarbeiten, es während des Laufs jederzeit unterbrechen oder umleiten und schnell iterieren, um nahezu sofortige Antworten zu erhalten. Da Codex-Spark auf Geschwindigkeit setzt, arbeitet es standardmäßig sehr schlank: Es führt nur minimale, gezielte Bearbeitungen durch und führt keine Tests automatisch aus, es sei denn, der Benutzer fordert dies explizit an.
Wie ist die Codierungsfähigkeit?
Im Bewertungsbereich zeigt Codex-Spark als kleines Modell dennoch hervorragende Leistungen in mehreren Software-Engineering-Referenztests.
Codex-Spark wurde speziell für schnelle Inferenz optimiert. In den beiden Referenztests SWE-Bench Pro und Terminal-Bench 2.0, die die Software-Engineering-Fähigkeiten von Agenten bewerten, hat GPT-5.3-Codex-Spark ausgezeichnet abgeschnitten, und die Zeit, die für die Aufgabenbewältigung erforderlich war, war deutlich kürzer als bei GPT-5.3-Codex.
Die geschätzte Dauer ist die Summe folgender Faktoren: (1) Die Zeit für die Ausgabeerzeugung (Anzahl der Ausgabe-Tokens ÷ Sampling-Geschwindigkeit), (2) die Vorauffüllzeit (Anzahl der Vorauffüll-Tokens ÷ Vorauffüll-Geschwindigkeit), (3) die gesamte Zeit für die Werkzeugausführung und (4) die gesamte Netzwerk-Overhead-Zeit.
Wie wird diese Programmierleistung erreicht? Bei der Entwicklung von Codex-Spark hat OpenAI festgestellt, dass die Geschwindigkeit des Modells nur ein Teil der Echtzeitkooperation ist - es muss auch die Verzögerung im gesamten Anfrage-Antwort-Prozess verringert werden. Deshalb hat das Entwicklerteam im Rahmen eine Ende-zu-Ende-Verzögerungsoptimierung implementiert, die alle Modelle profitieren lässt.
Bei der Entwicklung von Codex-Spark hat OpenAI ein Schlüsselproblem erkannt: Die Geschwindigkeit des Modells selbst ist nur ein Teil der Echtzeit-Erfahrung.
Was den Benutzer wirklich betrifft, ist der gesamte Ende-zu-Ende-Weg, von der Anfrage des Clients bis zum ersten sichtbaren Token und der anschließenden kontinuierlichen Generierung.
Deshalb hat OpenAI die unterliegende Architektur von Codex auf Systemebene optimiert, einschließlich: die Vereinfachung des Prozesses von Client zu Server und der Serverantwort, die Neuimplementierung des Schlüsselpfads im Inferenz-Stack, die Verbesserung des Sitzungsinitialisierungsmechanismus, die Einführung einer dauerhaften WebSocket-Verbindung und die gezielte Optimierung der Antwort-API.
Zu den quantifizierten Ergebnissen dieser Änderungen gehören:
- Die Kosten für einen einzelnen Hin- und Rückweg zwischen Client und Server wurden um 80 % gesenkt.
- Die Verarbeitungsaufwendungen pro Token wurden um 30 % reduziert.
- Die Zeit bis zum ersten Token wurde um 50 % verkürzt.
Codex-Spark aktiviert standardmäßig den WebSocket-Pfad, und diese Kommunikationsmethode wird in Zukunft allmählich die Standardkonfiguration für alle Modelle werden.
Dies bestätigt die Kernpositionierung von Codex-Spark: Es gewinnt nicht durch komplexere Inferenzketten, sondern durch schnellere Feedback-Schleifen, um die Gesamteffizienz zu steigern.
Entwickler interessieren sich nicht nur für "schneller"
Nach der Veröffentlichung der Forschungs-Vorschauversion von Codex-Spark für Echtzeit-Codierungsszenarien durch OpenAI hat sich auf x schnell eine Diskussion entwickelt. Im Vergleich zur offiziell betonten "sehr geringen Verzögerung" und "Echtzeit-Zusammenarbeitserfahrung" konzentriert sich die Community deutlich stärker auf eine Frage: Kann das Modell bei einer stark erhöhten Geschwindigkeit noch eine ausreichende Inferenztiefe und Codequalität aufrechterhalten?
Aus den bisherigen Diskussionen geht hervor, dass die Rückmeldungen zu Codex-Spark nicht einheitlich sind, sondern verschiedene repräsentative Stimmen enthalten.
Ein x-Benutzer hat gesagt:
"Das eigentliche Problem ist nicht nur die Geschwindigkeit. Der entscheidende Punkt ist, ob es unter Druck die Qualität aufrechterhalten kann. Wenn die Verzögerung verringert wird und die Inferenztiefe nicht abnimmt, wird dies den täglichen Arbeitsablauf verändern."
Andere Benutzer haben OpenAI beschuldigt, sich zu sehr auf die Codierungsleistung zu konzentrieren und andere Leistungen zu vernachlässigen.
"Ihr richtet alle Aufmerksamkeit auf den Code und diese Werbung, die sich auf die Benutzererfahrung auswirkt, aber das ist nicht das, was die meisten alltäglichen Benutzer wirklich interessiert. Ihr ignoriert die Stimme von #Keep4o (Beibehalten des 4o-Modells), genauso wie wir eure schrecklichen neuen Produkte ignorieren. Auch wenn ihr es vorspielt, dass ihr es nicht seht, werden wir nicht aufhören."
"Schneller" ist natürlich gut, aber die eigentliche Frage ist: Kann es bei hoher Geschwindigkeit die Codequalität aufrechterhalten?
Einige Benutzer haben darauf hingewiesen, dass ein schneller, aber fehlerhafter Code nutzlos ist. Ein langsamer, aber korrekter Code ist dagegen nützlich. Man ist gespannt, ob Spark in beiden Aspekten das Beste erreichen kann.
Mehrere Benutzer haben ähnliche Ansichten geäußert und gefragt, was es nützt, wenn es nur schnell ist. Es sollte zumindest das Niveau des GPT 5.3-Codex erreichen. "Andernfalls wirst du bald nichts mehr haben."
2
Google aktualisiert Gemini 3 Deep Think, das reale Forschungsherausforderungen lösen kann
Während OpenAI ein neues Modell vorstellt, hat auch Google nicht ruhen lassen.
Google hat letzte Nacht sein am meisten forschungsorientiertes Inferenzmodell - Gemini 3 Deep Think - synchron aktualisiert. Diese Aktualisierung ist keine gewöhnliche Leistungsverbesserung, sondern eine systematische Aufwertung, die sich klar an moderne wissenschaftliche Forschung, Ingenieurmodellierung und komplexe Inferenzprobleme richtet.
Es ist bemerkenswert, dass Shunyu Yao, ein bekannter Forscher aus der Physik der Tsinghua-Universität, der im vergangenen September bei Google DeepMind aufgenommen wurde, ebenfalls einer der Kernmitarbeiter am neuen Deep Think-Modell ist.
Was die offizielle Positionierung betrifft, zielt Gemini 3 Deep Think nicht auf ein reibungslosereres Dialogerlebnis ab, sondern auf die Lösung von "schwierigen Problemen", die Wissenschaftlern und Ingenieuren seit langem Kopfzerbrechen bereiten:
Diese Probleme haben oft keinen klaren Lösungspfad, es gibt keine eindeutig richtige Antwort, und die Daten selbst sind oft unvollständig, mit vielen Störungen versehen oder sogar widersprüchlich.
Google hat angegeben, dass diese Aktualisierung auf der langjährigen Zusammenarbeit mit einer Vielzahl von Wissenschaftlern und Forschern basiert. Das Designkonzept des Modells ist auch deutlich auf reale Forschung und Ingenieurpraxis ausgerichtet und nicht nur auf die Demonstration abstrakter Inferenzfähigkeiten.
Das neue Deep Think ist jetzt in der Gemini-Anwendung verfügbar und kann von Abonnenten von Google AI Ultra genutzt werden. Darüber hinaus haben wir erstmals über die Gemini-API ausgewählten Forschern, Ingenieuren und Unternehmen den Zugang zu Deep Think gewährt.
Zugangsadresse für Deep Think: https://forms.gle/eEF5natXTQimPhYH9
Hier ist eine Demonstration, wie frühe Testbenutzer die neueste Version von Deep Think nutzen:
Lisa Carbone, eine Mathematikerin an der Rutgers University, arbeitet an der Erforschung der mathematischen Strukturen, die für die Hochenergiephysik benötigt werden, um die Kluft zwischen Einsteins Gravitationstheorie und der Quantenmechanik zu schließen. Da in diesem Bereich nur begrenzte Trainingsdaten verfügbar sind, hat sie Deep Think-Technologie eingesetzt, um eine hoch spezialisierte mathematische Studie zu überprüfen. Deep Think hat erfolgreich einen feinen logischen Fehler erkannt, der bisher bei der manuellen Peer-Review nicht bemerkt wurde.
Im Wang-Labor an der Duke University wurde Deep Think-Technologie eingesetzt, um die Herstellungsmethode für die komplexe Kristallzucht zu optimieren, um neue Halbleitermaterialien zu entdecken. DeepThink hat erfolgreich ein Verfahren entwickelt, mit dem Filme mit einer Dicke von mehr als 100 Mikrometern hergestellt werden können, was mit bisherigen Methoden kaum erreichbar war.
Anupam Pathak, Leiter der Forschung und Entwicklung der Google Platform und Devices Division und ehemaliger CEO von Liftware, hat das neue Deep Think getestet, um die Entwicklung von physikalischen Komponenten zu beschleunigen.
Verbesserung der Inferenzfähigkeit durch mathematische und algorithmische Strenge
In den bisherigen Bewertungssystemen für Large Language Models wird die Inferenzfähigkeit oft anhand