Am 1. August 2026 hat OpenAI mitgeteilt, dass eine interne Version des kommenden Modells Astra neue Ergebnisse zu zehn offenen Problemen aus Mathematik und theoretischer Informatik vorgelegt hat. Alle zehn Probleme waren seit mindestens zehn Jahren offen. Astra ist ein internes Modell, es wurde nicht veröffentlicht, und niemand außerhalb von OpenAI kann es ausführen.
Die Meldung wurde innerhalb weniger Tage vielfach aufgegriffen, fast immer unter derselben Überschrift: Eine KI löst Mathematikprobleme. Die interessantere Frage ist eine andere. Woher wissen wir, dass das stimmt, und an welcher Stelle genau endet diese Gewissheit? Darum geht es in diesem Text.
Was genau veröffentlicht wurde
Vorgelegt wurden drei Dinge: ein Manuskript von 249 Seiten, die Denkspuren des Modells und Beweiszertifikate in Lean 4, also maschinell prüfbare Beweise. Alles liegt auf GitHub unter der Apache-2.0-Lizenz.
Ein Detail aus diesem Paket verdient mehr Aufmerksamkeit als die Seitenzahl: Das veröffentlichte Zertifikats-Repository weist einen sorry-Zähler von null aus.
Was "sorry auf null" bedeutet
In Lean markiert das Schlüsselwort sorry einen Schritt, der nicht bewiesen ist. Man setzt es ein, wenn man eine Zwischenbehauptung für wahr hält, sie aber noch nicht hergeleitet hat. Der Beweis lässt sich damit trotzdem kompilieren, die Lücke bleibt jedoch sichtbar und vor allem zählbar.
Ein Zähler von null heißt also: Keine einzige Stelle der Formalisierung ist offengelassen. Jeder Zwischenschritt ist auf das zurückgeführt, was Lean als Grundlage akzeptiert. Das ist keine Einschätzung und keine Bewertung, sondern eine binäre Eigenschaft der Dateien. Entweder der Zähler steht auf null oder er steht nicht auf null.
Die Gebiete und das Hauptergebnis
Die zehn Ergebnisse verteilen sich auf Gruppentheorie, von-Neumann-Algebren, Geometrie in hohen Dimensionen, Quantenkomplexität, gitterbasierte Kryptografie und extremale Kombinatorik.
Herausgehoben wird die erste explizite Konstruktion einer nicht-sofischen Gruppe. Der Begriff der Sofizität geht auf Mikhail Gromov zurück, der ihn 1999 eingeführt hat. Ob überhaupt eine nicht-sofische Gruppe existiert, war seither eine zentrale offene Frage der Gruppentheorie. Zusätzlich soll Astra drei Probleme aus dem Umfeld von Paul Erdős gelöst haben.
Thomas Bloom, Mathematiker an der Universität Manchester und Betreiber des Katalogs der Erdős-Probleme, bezeichnete die Ergebnisse auf X als "big news".
Warum Lean die Beweislast verschiebt
Der übliche Einwand gegen mathematische Aussagen von Sprachmodellen lautet: Ein Modell erzeugt Text, der plausibel wirkt. Ein Beweis, der sich flüssig liest, ist deshalb noch nicht korrekt. Genau darauf zielt der Einwand: Ob in der Mitte einer Herleitung ein Schritt fehlt, sieht man einem flüssig geschriebenen Beweis nicht an.
Ein Lean-Zertifikat beseitigt dieses spezielle Problem. Der Prüfer ist ein Programm, das keine Rücksicht auf Formulierung, Eleganz oder Plausibilität nimmt. Es akzeptiert einen Schritt oder es akzeptiert ihn nicht. Ob der Beweis von einem Menschen, einem Modell oder einem Zufallsgenerator stammt, spielt für das Ergebnis der Prüfung keine Rolle.
Das verschiebt die Beweislast an einer entscheidenden Stelle. Man muss OpenAI nicht glauben. Man muss die Denkspuren nicht für schlüssig halten. Man muss nicht einmal die 249 Seiten lesen. Die Prüfung hängt an einer Datei, die öffentlich liegt, und an einer Software, die jeder installieren kann. Eine Behauptung, die durch einen mechanischen Prüfer gegangen ist, hat einen anderen Status als eine Behauptung eines Sprachmodells. Das ist der eigentliche Fortschritt an dieser Veröffentlichung, und er wird in den meisten Zusammenfassungen unterschlagen.
Die Grenze, die kaum jemand nennt
Genau hier setzt der wichtigste Einwand an, und er wird selten deutlich formuliert.
Eine erfolgreiche Lean-Kompilierung bestätigt, dass der Beweis gültig ist für das Theorem, so wie es in Lean formuliert wurde. Sie bestätigt nicht automatisch, dass diese formale Aussage das offene Problem so erfasst, wie die mathematische Gemeinschaft es verstanden hat.
Zwischen dem Problem in Prosa und dem Problem in Lean liegt ein Übersetzungsschritt. Dieser Schritt ist Handarbeit. Definitionen müssen gewählt, Voraussetzungen ausgeschrieben, Quantoren festgelegt werden. Wenn eine Formalisierung eine zusätzliche Annahme enthält, die im ursprünglichen Problem nicht vorgesehen war, oder wenn ein Begriff enger gefasst ist als in der üblichen Lesart, dann ist der Beweis weiterhin korrekt. Er beweist nur etwas anderes als das, was man ihm zuschreibt. Der Prüfer meldet in diesem Fall nichts, denn er prüft die Herleitung, nicht die Absicht.
Ob das hier an einer Stelle geschehen ist, ist offen. Der Abgleich zwischen den zehn formalen Sätzen und den ursprünglichen Problemstellungen liegt bislang nicht vor. Das ist auch nicht der Punkt. Der Punkt ist, dass sich diese Übereinstimmung nicht automatisieren lässt. Sie muss von Fachleuten des jeweiligen Gebiets beurteilt werden, Aussage für Aussage, und das braucht Zeit. Solange diese Beurteilung nicht vorliegt, bleibt offen, ob die zehn formalen Sätze wirklich die zehn offenen Probleme sind. Genau dieser Punkt ist derzeit in der Schwebe, und er ist der Grund, warum die Formulierung "gelöst" verkürzt.
Verifizieren ist nicht reproduzieren
Der zweite Einwand betrifft nicht die Beweise, sondern das Modell. Externe Forscher weisen darauf hin, dass Personal von OpenAI daran mitgewirkt hat, die Artikel vorzubereiten und die Argumente zu formalisieren. Und niemand außerhalb des Unternehmens kann das Modell ausführen, das die Arbeit geleistet hat.
Daraus folgt eine Unterscheidung, die in der Berichterstattung meist verschwimmt:
- Verifizieren heißt, die vorgelegten Beweise zu prüfen. Das ist möglich, öffentlich und unabhängig von OpenAI.
- Reproduzieren heißt, den Vorgang zu wiederholen, der zu diesen Beweisen geführt hat, und zu sehen, ob wieder Vergleichbares entsteht. Das ist von außen nicht möglich.
Für die logische Korrektheit der Beweise ist das nicht ausschlaggebend: Eine Herleitung besteht die maschinelle Prüfung oder sie besteht sie nicht. Für die Einordnung der zehn Ergebnisse ist es dagegen sehr wohl relevant, denn der eine Schritt, den der Prüfer nicht abdeckt, die Übersetzung des offenen Problems in eine formale Aussage, wurde auf der Seite des Unternehmens vorgenommen, das das Ergebnis meldet. Für die Bewertung des Modells ist es ebenfalls ausschlaggebend. Für die Bewertung des Modells ist es dagegen ausschlaggebend. Alles, was über die Fähigkeiten von Astra gesagt wird, beruht auf einer Auswahl, die der Hersteller getroffen hat. Welche Probleme wurden angegangen und nicht gelöst? Wie viele Ansätze führten ins Leere? Diese Zahlen sind nicht veröffentlicht, und ohne sie lässt sich die Trefferquote nicht einschätzen.
Was 2 000 Dollar heißen und was nicht
Die meistzitierte Zahl der ganzen Geschichte sind rund 2 000 Dollar Rechenkosten. Sie beantwortet eine andere Frage als die, für die sie herangezogen wird. Sie beantwortet nur eine andere Frage als die, für die sie herangezogen wird.
Forscher haben darauf hingewiesen, dass dieser Betrag die erfolgreichen Läufe abdeckt, nicht sämtliche Versuche des Modells. Es handelt sich also um Publikationskosten, nicht um Entdeckungskosten. Wie viel Rechenzeit insgesamt in Sackgassen geflossen ist, steht nirgends.
Der Unterschied ist nicht spitzfindig. Die Formulierung "zehn offene Probleme für 2 000 Dollar" legt eine Rechnung nahe, aus der sich hochrechnen ließe, was das nächste Ergebnis kostet, oder das hundertste. Mit den vorliegenden Angaben lässt sich das nicht tun. Bekannt ist der Preis der Treffer, nicht der Preis der Suche. Wer aus dieser Zahl eine Kostenkurve für maschinell erzeugte Mathematik ableitet, rechnet mit einem Wert, der dafür nicht erhoben wurde.
Zusammen mit der Auswahl der veröffentlichten Ergebnisse ergibt das denselben Befund an zwei Stellen: Was man sieht, ist die gefilterte Seite eines Vorgangs, dessen ungefilterte Seite nicht vorliegt.
Was davon für ein Unternehmen übrig bleibt
Die ehrliche Antwort lautet: unmittelbar wenig, mittelbar etwas Konkretes.
Unmittelbar ist Astra nicht verfügbar. Kein Produkt, keine Schnittstelle, kein Zugang. Wer heute über den Einsatz von KI im eigenen Betrieb entscheidet, entscheidet mit den Modellen, die es gibt. Der August 2026 liefert dafür ohnehin lautere Signale: OpenAI hat den Preis von GPT-5.6 Luna um 80 Prozent auf 0,20 Dollar je Million Eingabe-Tokens gesenkt, ChatGPT liegt bei etwa einer Milliarde wöchentlich aktiver Nutzer, und Anthropic hebt bessere Programmierergebnisse sowie ein Kontextfenster von einer Million Tokens hervor. Das sind die Größen, die kurzfristig Budgets bewegen, nicht ein internes Forschungsmodell.
Mittelbar ist der übertragbare Teil dieser Ankündigung nicht das Ergebnis, sondern das Format. OpenAI hat etwas mitgeliefert, das sich ohne Vertrauen in den Absender prüfen lässt. Das ist in der Kommunikation über KI-Systeme die Ausnahme. Daraus lässt sich eine Frage ableiten, die bei jeder Zusage funktioniert, die Ihnen ein Anbieter macht: Woran würde ich merken, wenn es nicht stimmt? Ein Anbieter, der eine bestimmte Trefferquote zusichert, stellt damit zunächst eine Behauptung auf. Auf welchem Datensatz, wer hat ihn zusammengestellt, und darf man nachrechnen? Das sind Fragen, die sich schriftlich stellen und schriftlich beantworten lassen.
Der zweite übertragbare Punkt betrifft die Werkzeuge. Wo eine maschinelle Prüfung existiert, ist sie mehr wert als jede Zusicherung. Das Gegenstück zu Lean ist in der Softwareentwicklung weniger exotisch, als es klingt: strikte Typprüfung, Tests, die bei jedem Commit laufen, Migrationen, die vorher in einer Vorproduktionsumgebung durchlaufen. Solche Verfahren übersetzen die Aussage "das funktioniert" in etwas, das eine Maschine bestätigen oder ablehnen kann. Ihr Wert steigt genau in dem Maß, in dem Code von Modellen erzeugt wird. Wer generierten Code annimmt, weil er plausibel aussieht, hat exakt das Problem, das Lean für Beweise löst.
Der dritte Punkt ist die Kehrseite davon, und er ist der wichtigere. Lean prüft den formalen Satz, nicht dessen Übereinstimmung mit dem gemeinten Problem. In einem Projekt entspricht das der Lücke zwischen Anforderung und Spezifikation. Eine grüne Testsuite belegt, dass die Software das tut, was in den Tests steht. Ob in den Tests das Richtige steht, ist keine technische Frage, sondern eine fachliche. Automatisierung verschiebt diese Frage, sie erledigt sie nicht.
Gary Marcus merkt an, dass die Ergebnisse, so beachtlich sie sind, weder eine allgemeine künstliche Intelligenz noch einen unmittelbar bevorstehenden universellen Löser belegen. Als Beschreibung dessen, was tatsächlich vorliegt, trifft diese Einordnung zu: zehn Ergebnisse in klar umrissenen Gebieten, ausgewählt und aufbereitet von einem Unternehmen, formal geprüft. Als Beschreibung dessen, was tatsächlich vorliegt, trifft sie zu: zehn Ergebnisse in klar umrissenen Gebieten, ausgewählt und aufbereitet von einem Unternehmen, formal geprüft.
Fazit
Etabliert ist Folgendes. Es liegen Beweise vor, die in Lean 4 vollständig kompilieren, ohne offene Stellen. Sie liegen öffentlich unter Apache 2.0. Ihre Korrektheit lässt sich prüfen, ohne OpenAI zu glauben. In dieser Hinsicht liefert die Ankündigung etwas mit, das sich unabhängig vom Absender prüfen lässt, und das ist bei Aussagen von Modellanbietern die Ausnahme.
Nicht etabliert ist ebenso Folgendes. Dass die formalen Aussagen die offenen Probleme so erfassen, wie die Fachgemeinschaft sie versteht. Dass sich das Ergebnis unabhängig wiederholen lässt, denn das Modell bleibt intern. Und was ein solches Ergebnis kostet, wenn man die Fehlversuche mitzählt.
Beides zugleich stehen zu lassen ist die genaueste Beschreibung, die derzeit möglich ist. Wer nur die erste Hälfte wiedergibt, verkauft etwas. Wer nur die zweite wiedergibt, übersieht, dass hier zum ersten Mal ein maschinell prüfbarer Beleg mitgeliefert wurde.
Wenn Sie prüfen möchten, wie sich diese Logik auf ein konkretes Vorhaben übertragen lässt, etwa auf die Frage, welche Zusagen eines Dienstleisters technisch nachprüfbar sind, schreiben Sie uns über das Anfrageformular. Wir arbeiten schriftlich und antworten innerhalb von 24 Arbeitsstunden.
