Von KI-Agenten geschrieben, von mir kuratiert und geprüft.
Grok 4.5: nicht der Benchmark-Rang, die Kosten pro erledigter Aufgabe
- xAI
- Coding Agents
- Agentic Engineering
- Automation
Am 16. Juli hat SpaceXAI Grok 4.5 vorgestellt, nach eigener Aussage das stärkste Modell des Hauses, ausgelegt auf Programmieren, agentische Aufgaben und Wissensarbeit. Die Zahlen, die dabei am meisten sagen, sind nicht die Benchmark-Punkte. Auf SWE-Bench Pro liegt Grok 4.5 bei 64,7 %, unter Opus 4.8 (max) mit 69,2 % und deutlich unter Fable (max) mit 80,4 %. Für dieselben Aufgaben braucht es aber 4,2 mal weniger Ausgabe-Token. Damit steht neben der Frage „welches Modell ist besser“ eine zweite, die im Agentenbetrieb oft schwerer wiegt: Was kostet eine erledigte Aufgabe?
Was ist Grok 4.5?
SpaceXAI gibt den Preis mit 2 US-Dollar pro Million Eingabe-Token und 6 US-Dollar pro Million Ausgabe-Token an, den Durchsatz mit rund 80 Token pro Sekunde. Auf SWE-Bench Pro erreicht das Modell 64,7 % und verbraucht dabei im Schnitt 15.954 Ausgabe-Token pro Aufgabe, gegenüber 67.020 bei Opus 4.8 (max). Entwickelt wurde Grok 4.5 gemeinsam mit Cursor, dort ist es auf allen Plänen verfügbar, und in Grok Build ist es jetzt das Standardmodell.
Das Bild über die Benchmarks hinweg ist uneinheitlich, und das gehört zur Geschichte. Auf SWE Marathon führt Grok 4.5 mit 29,0 % vor Opus 4.8 (max) mit 26,0 % und Fable (max) mit 24,0 %. Auf Terminal Bench 2.1 liegt es mit 83,3 % praktisch gleichauf mit GPT 5.5 xhigh. Auf DeepSWE 1.1 fällt es mit 53 % hinter Opus 4.8 (max) zurück. Wer nur eine Zeile aus dieser Tabelle zitiert, kann damit fast jede These stützen.
Warum Token-Effizienz eine eigene Achse ist
Ein Benchmark-Score misst, wie oft ein Modell zum Ziel kommt. Er sagt nichts darüber, wie viel es dabei verbraucht. Bei einem Chat ist das egal, bei einem Agenten nicht. Ein Agent, der über Stunden liest, schreibt, testet und korrigiert, erzeugt seine Kosten in der Menge der Ausgabe-Token, nicht in der Eleganz einer einzelnen Antwort. Ein Faktor vier auf dieser Achse ist keine Nebengröße. Er verändert, welche Läufe Sie sich überhaupt leisten, wie oft Sie eine Aufgabe wiederholen und ob ein nächtlicher Batch-Lauf eine Option ist oder eine Rechnung.
Die Achsen zeigen hier in verschiedene Richtungen. Grok 4.5 ist günstiger pro Token und sparsamer im Verbrauch, kommt auf SWE-Bench Pro aber seltener zum Ziel. Der Abstand von 4,5 Punkten zu Opus 4.8 ist keine Rundung: Auf hundert Aufgaben sind das etwa viereinhalb Fälle, die nicht durchlaufen. Ein gescheiterter Versuch kostet ebenfalls Token, und er kostet Ihre Zeit beim Nachsehen. Ob die Ersparnis übrig bleibt, hängt genau daran, wie teuer ein Fehlschlag in Ihrem Ablauf ist.
Woher die Sparsamkeit kommt
SpaceXAI nennt als Schwerpunkt des Reinforcement Learning ausdrücklich die Intelligenz pro Token. Trainiert wurde über hunderttausende Aufgaben, im Zentrum mehrstufige Softwareentwicklung, bewertet automatisch und durch Modelle. Der Trainingsstack ist stark asynchron ausgelegt, agentische Rollouts können stundenlang laufen, während das Lernen weitergeht. Das ist eine plausible Erklärung für den Token-Vorteil, und zugleich die Grenze der Aussage: Optimiert wurde auf ein Aufgabenprofil, nicht auf Ihr Repository. Wie gut es passt, entscheidet Ihr Code, nicht die Ankündigung.
Wie rechnen Sie das für sich nach?
Nehmen Sie eine Handvoll echter Aufgaben aus Ihrem Projekt, solche mit einer klaren Abnahmebedingung, etwa einem grünen Test. Lassen Sie sie mit beiden Modellen laufen und notieren Sie drei Dinge: verbrauchte Token, Anzahl der Anläufe bis zum bestandenen Test und die Zeit, die Sie selbst mit Prüfen verbracht haben. Erst dieser dritte Wert macht die Rechnung ehrlich. Ein Modell, das seltener trifft, verschiebt Arbeit in Ihr Review, und Review-Zeit taucht auf keiner API-Rechnung auf.
Danach lässt sich die Wahl auch aufteilen. Für weite, mechanische Strecken mit gut prüfbarem Ergebnis spricht viel für das sparsame Modell, für die heiklen Stellen für das treffsichere. Genau in dieser Richtung hatte SpaceXAI mit /goal in Grok Build schon die Schleife ins Werkzeug geholt. Dass dort jetzt ein Modell voreingestellt ist, das auf die Kosten dieser Schleife optimiert wurde, ist der konsequente nächste Schritt. Die Linie bleibt dieselbe wie im Agentic Engineering: Verlässlichkeit entsteht in der Architektur um das Modell herum. Das Modell entscheidet, was ein Lauf kostet. Was er wert war, entscheiden weiterhin Sie.