GPT-6 Astra: max kostet 2.3x so viel wie low, gleiche Antworten

Bei GPT-6 Astra kostet reasoning_effort: "max" 2.3x so viel wie low und liefert bei allen 11 verifizierten Aufgaben dieselbe Antwort. Nur none verändert die Genauigkeit und scheitert in 17 von 33 Läufen (11 Aufgaben mit jeweils 3 Läufen). Mit dem Request-Parameter reasoning_effort wird festgelegt, wie viel intern gerechnet wird, bevor das Modell antwortet. Diese Rechenarbeit wird als Reasoning-Tokens zum Output-Tarif abgerechnet. Dieser Beitrag misst die Abstufungen von none bis max. Sie entsprechen nicht der Dokumentation: Die Eingabevalidierung der API nennt sieben Werte. Einer davon (minimal) wird von jedem Modell abgelehnt, während ein dort nicht genannter Wert (disabled) von Astra akzeptiert wird und nichts deaktiviert. Das ist für die Einordnung der Launch-Benchmarks von OpenAI relevant, die jeweils den “Höchstwert über alle Effort-Stufen” angeben. Der Wert im Leaderboard stammt also von der teuersten Stufe.

TL;DR

• GPT-6 Astra akzeptiert sieben Werte für reasoning_effort, darunter none und disabled. Die Dokumentation nennt fünf und behauptet, none werde nicht unterstützt.
• Nur none reduziert die Reasoning-Tokens auf null und scheitert bei 17 von 33 verifizierten Aufgaben. Alle anderen Stufen erreichen 33 von 33.
• disabled verbraucht 243 Reasoning-Tokens gegenüber 151 bei low und kostet bei gleicher Genauigkeit 54% mehr pro richtiger Antwort.
• Zum Listenpreis kostet GPT-6 Astra pro richtiger Antwort bei low 1.57x und bei max 2.57x so viel wie GPT-5.6 Sol, wenn beide Modelle die Aufgabe korrekt lösen.

Wie schneidet GPT-6 Astra in den Benchmarks ab?

Bei Agenten-Workloads, in denen das Modell Tools wiederholt aufruft, häufig in einem Terminal, liegt Astra vorn. Bei Humanity’s Last Exam und im Artificial Analysis Intelligence Index, einer unabhängigen Zusammenfassung aus zehn Evaluationen, liegt es hinter Claude Fable 5.1. Jeder Wert wurde mit der Effort-Stufe ermittelt, die das beste Ergebnis erzielte. Die folgende Tabelle stammt von OpenAI selbst, genauer von der Launch-Seite, und enthält die von OpenAI ausgewählten Vergleichsspalten:

Drei Punkte gehören zur Einordnung dieser Ergebnisse:

• In der Zeile zu Humanity’s Last Exam liegt Astra 7.8 Punkte hinter Fable 5.1. Das steht zwar in der Tabelle, wird im Text aber nicht erwähnt.
• In OpenAIs eigener Tabelle liegt Astra bei Artificial Analysis hinter Claude Fable 5.1, Claude Opus 5 und Claude Fable 5. Im aktuellen v4.2-Leaderboard erreicht Fable 5.1 mit 57 den ersten Platz und Astra mit 55 den dritten.
• Die Cybersecurity-Ergebnisse wurden laut OpenAI “ohne Schutzmechanismen der Produktionsumgebung” erzielt. Das ausgelieferte Modell “wird Proof-of-Concept-Exploit-Aufgaben ablehnen”.

Der Satz unter den Tabellen stellt den Zusammenhang zwischen den Benchmarks und den Kosten her: “Die Evaluationsergebnisse entsprechen dem Höchstwert über alle Effort-Stufen.” Im Leaderboard von Artificial Analysis erscheint jedes Modell einmal pro Effort-Stufe. Astra erreicht bei xhigh 54 und bei max 55. Im restlichen Beitrag geht es um die Kosten dieses Punkts.

Welche reasoning_effort-Werte akzeptiert GPT-6 Astra?

Sieben, aber nicht dieselben sieben, die von der API angekündigt werden. Ein angekündigter Wert wird von jedem Modell abgelehnt, ein akzeptierter Wert wird nirgends genannt. Auf der Modellseite stehen low, medium, high, xhigh und max. Außerdem heißt es dort, das Modell “unterstütze den Reasoning-Effort none nicht”. Die API widerspricht der Dokumentation an zwei Stellen und sich selbst an einer.

Wird ein ungültiger Wert gesendet, prüft die API zunächst die Form des Requests, noch bevor ein Modell beteiligt ist. Für GPT-6 Astra und GPT-5.6 Sol liefert sie dieselbe Liste zulässiger Werte:

Invalid value: '__invalid__'. Supported values are: 'none', 'minimal', 'low', 'medium', 'high', 'xhigh', and 'max'.

Beim anschließenden Senden dieser Werte lehnt eine zweite, modellspezifische Prüfung einige Werte ab, die von der ersten Prüfung angekündigt wurden. 200 bedeutet, dass der Request verarbeitet wurde, 400 steht für eine Ablehnung:

none funktioniert also entgegen der Dokumentation. minimal wird angekündigt, aber überall abgelehnt. disabled akzeptiert nur Astra, obwohl der Wert in keiner Liste auftaucht. Die Fehlermeldungen verraten außerdem den datierten Build, auf den der Alias gpt-6-astra derzeit zeigt: gpt-6-astra-2026-09-03.

Deaktiviert none das Reasoning, und was macht disabled?

none deaktiviert es und ist der einzige Wert, der das tut. disabled ist eine normale Stufe mit irreführendem Namen. Wir haben 11 Aufgaben verwendet, deren Lösungen zuvor per Exhaustive Search lokal berechnet wurden. Dadurch war sichergestellt, dass der Lösungsschlüssel korrekt ist. Dazu gehörten eine 40-mal hintereinander angewendete Regel, ein Zählproblem mit drei Bedingungen, ein Knapsack-Problem, eine Basisumrechnung, 7 hoch 222 modulo 1000 sowie sechs kürzere Aufgaben. Alle Aufgaben wurden mit allen sieben Effort-Stufen ausgeführt, bei Sol wegen der Ablehnung von disabled mit sechs. Pro Aufgabe und Stufe gab es 3 Läufe über einen Endpoint, der die OpenAI Chat Completions API implementiert. Für die fünf schwierigsten Aufgaben ergibt sich bei GPT-6 Astra:

Die Kosten pro richtiger Antwort entsprechen den Gesamtkosten einer Kombination aus Aufgabe und Effort-Stufe, geteilt durch die Anzahl richtiger Läufe. Bei einer Trefferquote von 20% müssen im Durchschnitt fünf Läufe bezahlt werden, um eine richtige Antwort zu erhalten. Der Leistungseinbruch liegt zwischen zwei direkt benachbarten Stufen. Von low aufwärts erreichten beide Modelle bei allen 11 Aufgaben 33 von 33 Punkten. none erreichte bei Astra 16 von 33 und bei Sol 21 von 33. Bei der Aufgabe mit der wiederholt angewendeten Abbildung lieferte Astra in drei Läufen drei verschiedene falsche Zahlen. Es gibt keinen schrittweisen Qualitätsverlust, auf den man optimieren könnte: Entweder ist Reasoning aktiv oder das Modell rät.

disabled ist die Falle. Der Wert verbraucht mehr Reasoning-Tokens als low, medium oder high und kostet bei derselben Genauigkeit von 100% pro richtiger Antwort 54% mehr als low. Nur xhigh und max kosten pro richtiger Antwort noch mehr als der Wert, dessen Name eine Deaktivierung verspricht.

Was bringt max gegenüber low?

Bei diesen Aufgaben nichts, kostet aber 2.3x so viel: $0.01946 pro Aufruf gegenüber $0.00851. Beide erreichen 100%. Die Reasoning-Tokens steigen von 151 bei low auf 370 bei max. Jedes davon wird zum Output-Tarif von $50 pro Million abgerechnet.

Diese Zahl gehört direkt neben die Benchmark-Tabelle. Wenn jeweils “der Höchstwert über alle Effort-Stufen” angegeben wird, stammt jedes Ergebnis von der Stufe mit der höchsten Punktzahl. Im unabhängigen Leaderboard ist Astras bester Eintrag max, einen Punkt vor xhigh. Unsere Messung beziffert die Kosten dieser Stufe auf das 1.3x-Fache der direkt darunterliegenden Stufe. Bei Workloads, die den Launch-Benchmarks ähneln, kann der zusätzliche Aufwand seine Kosten rechtfertigen. Bei Workloads wie unseren tut er das nicht. Ob das für den eigenen Fall gilt, lässt sich nur messen, am besten zuerst mit low.

Kostet GPT-6 Astra pro Antwort 2.5x so viel wie GPT-5.6 Sol?

Bei low nicht: Dort sind es 1.57x. Bei max ja: 2.57x. Der Listenpreis ist der Token-Preis auf der jeweiligen Anbieterseite. Astra kostet pro Million Tokens $10 für Input und $50 für Output, Sol $4 und $20. Beide Angaben stammen von den OpenAI-Modellseiten für Astra und Sol vom 2026-09-07. Der Abstand beim Listenpreis beträgt damit für Input und Output jeweils 2.5x. Die [Vergleichsseite für GPT-5.6 Sol und GPT-6 Astra](/compare/models/gpt-5-6-sol-vs-gpt-6-astra/) enthält die aktuellen Katalogpreise. Aus den Token-Zahlen aller 11 Aufgaben und den jeweiligen Listenpreisen ergeben sich folgende Kosten pro richtiger Antwort. Beide Modelle erreichten ab low 33 von 33 Punkten:

Bei den niedrigen Stufen benötigt Astra weniger Reasoning-Tokens als Sol, um dieselbe Antwort zu erreichen. Bei low sind es über die 11 Aufgaben hinweg 91 gegenüber 158 pro Aufruf. Deshalb schrumpft der Kostenabstand dort. In den höheren Stufen steigt Astras Reasoning-Verbrauch schneller. Bei max sind es 249 gegenüber 242, womit der Abstand pro Antwort dem vollen Unterschied beim Listenpreis entspricht.

Die Aussage gilt nur für diesen klar abgegrenzten Fall: Beide Modelle erreichen ab low 100%, daher misst dieser Test nicht den Unterschied in ihrer Leistungsfähigkeit, sondern nur die Kosten einer Antwort, die beide korrekt liefern. Je nach Parameter liegen sie zwischen 1.6x und 2.6x. Für Agenten-Workloads weist OpenAIs Launch-Seite in die andere Richtung. Bei Terminal-Bench 4.0 werden die “geschätzten API-Kosten pro Aufgabe” gegenüber Sol und Fable 5.1 mit “ungefähr 9% und 63% weniger” angegeben. Ein Modell, das mehr Aufgaben mit weniger Tokens löst, kann trotz eines höheren Token-Preises günstiger sein. Die Workloads sind unterschiedlich, aber in beiden Fällen bestimmt die Effort-Stufe die Rechnung.

Verursachen ein JSON-Schema oder ein Tool-Aufruf zusätzliche Reasoning-Kosten?

Bei low nicht, bei medium schon. Wir haben eine einstufige Aufgabe (2 Stunden und 37 Minuten zu 08:15 addieren) in drei Varianten gesendet: ohne Formatvorgabe, innerhalb eines strikten response_format-JSON-Schemas, bei dem die Antwort einem vorgegebenen JSON-Schema entsprechen muss, und als erzwungenen Tool-Aufruf. Dabei war tool_choice auf eine Funktion festgelegt, sodass das Modell mit einem Funktionsaufruf antworten musste. Getestet wurden vier Effort-Stufen mit jeweils 3 Läufen. Für GPT-6 Astra ergeben sich folgende durchschnittliche Reasoning-Tokens, jeweils mit ihrem Anteil an allen abgerechneten Output-Tokens, und Kosten pro Aufruf:

low kann bis auf null herunterregeln. Bei einer Aufgabe ohne Zwischenschritte verbraucht es keine Reasoning-Tokens und kostet genauso viel wie none. Bei den mehrstufigen Aufgaben oben verbraucht es je nach Aufgabe 16 bis 345 Tokens und bleibt korrekt, während none einbricht. Damit ist low die sinnvolle Untergrenze. Das Ausgabeformat verursacht nicht die Zusatzkosten: Ein Schema oder Tool-Aufruf fügt bei low nur 0 bis 4 Reasoning-Tokens hinzu. Bei medium entfallen dagegen 57 bis 67% der Output-Tokens auf Reasoning, wenn ohne Formatvorgabe oder mit Schema gearbeitet wird. Beim Tool-Aufruf sind es 18%, obwohl die Aufgabe keinen Reasoning-Bedarf hat. Dieselbe Extraktion kostet innerhalb des Schemas bei medium 1.6x so viel wie bei low, ohne Formatvorgabe sogar 2.2x. Der Kostenleitfaden zu GPT-5.6 vom Juli identifizierte für diese Modellfamilie denselben Hebel. Sol verhält sich gleichmäßiger: Ohne Formatvorgabe und mit Schema fallen bei keiner Effort-Stufe Reasoning-Tokens an. Beim erzwungenen Tool-Aufruf sind es ab medium 14 bis 18 Tokens.

Kann man das bezahlte Reasoning lesen?

Bei einer der beiden API-Oberflächen von OpenAI. Der ältere Chat-Completions-Endpoint und der neuere Responses-Endpoint akzeptieren dasselbe Modell und rechnen auf dieselbe Weise ab. Dieselbe Frage wurde bei medium pro Oberfläche 3-mal gestellt:

Die Token-Zahlen liegen innerhalb der normalen Schwankung. Die Abrechnung ist somit gleich, der einzige Unterschied besteht darin, ob das bezahlte Reasoning sichtbar ist. Bei $50 pro Million Output-Tokens entscheidet der Endpoint darüber. Auch für Tool-Aufrufe verweist die Dokumentation auf Responses (“GPT-6 Astra unterstützt Chat Completions, Tool-Aufrufe erfordern jedoch Responses”). Workloads mit Tools müssen daher ohnehin die Oberfläche verwenden, auf der die Zusammenfassung lesbar ist.

Was wird von GPT-5.6 übernommen?

Der größte Teil des API-Vertrags. Gemessen wurden folgende Punkte:

• Tokenizer. Derselbe Text mit 900 Wörtern wurde bei GPT-6 Astra, GPT-5.6 Sol, GPT-5.6 Luna, GPT-5.5, GPT-5.4 und GPT-5.2 jeweils in 1,017 Prompt-Tokens zerlegt. Für 5.x gemessene Prompt-Größen gelten auch für Astra. Eine erneute Zählung ist nicht nötig.
• Parameter. temperature liefert bei Astra und Sol gleichermaßen 400 (“von diesem Modell nicht unterstützt”). Dasselbe gilt für top_p und logprobs. response_format mit einem strikten JSON-Schema erzeugt bei beiden schema-konforme Ausgaben. max_tokens unter 16 wird von beiden abgelehnt.
• max bei Sol. Im Juli lieferte reasoning_effort: "max" bei GPT-5.6 Sol über Chat Completions noch 400. Der Wert wird inzwischen akzeptiert, und Sol erreichte damit 33 von 33 Punkten.

Folgende Angaben stammen aus der Dokumentation und wurden hier nicht gemessen: Das Kontextfenster umfasst 1,050,000 Tokens, mit maximal 922,000 Input-Tokens und 128,000 Output-Tokens. Prompts mit mehr als 272K Input-Tokens werden mit dem 2x-Fachen des Input- und Cache-Tarifs abgerechnet. Die GPT-5.6-Familie verwendet denselben Schwellenwert, und denselben Mechanismus haben wir anbieterübergreifend gemessen. Cache Reads kosten laut Liste $1 pro Million, Cache Writes $12.50. Der neue Parameter prompt_cache_options.ttl: "30m" ersetzt prompt_cache_retention. Fast Mode ist eine kostenpflichtige Option, die laut OpenAI bis zu 2x so schnell ist und 2x so viel wie der Standardtarif kostet.

So verarbeitet Synthorai den Parameter

Das Gateway reicht reasoning_effort unverändert weiter, einschließlich der Werte, die nicht in der Dokumentation stehen. Im Usage-Datensatz jedes Requests wird reasoning_tokens als eigenes Feld neben completion_tokens und den abgerechneten Kosten gespeichert. Auf diesen Daten basieren alle Tabellen oben: die gesendete Effort-Stufe, die dafür verbrauchten Reasoning-Tokens und die entstandenen Kosten. Alles ist pro Request einsehbar und muss nicht aus einer Monatssumme rekonstruiert werden.

FAQ

Unterstützt GPT-6 Astra reasoning_effort none?

Ja. Laut Dokumentation wird der Wert nicht unterstützt, die API akzeptiert ihn aber bei GPT-6 Astra und GPT-5.6 Sol. Nur dieser Wert liefert null Reasoning-Tokens. Bei einem verifizierten Aufgabensatz scheiterte er allerdings in 17 von 33 Läufen. Er eignet sich daher für Lookups und Transformationen, nicht für Aufgaben mit mehreren Schritten.

Was macht reasoning_effort disabled bei GPT-6 Astra?

Das Modell verwendet Reasoning. disabled wird von GPT-6 Astra akzeptiert und von GPT-5.6 Sol abgelehnt. Der Wert taucht weder in der Dokumentation noch in der angekündigten Liste auf. Bei unserem schwierigen Aufgabensatz verbrauchte er 243 Reasoning-Tokens pro Aufruf gegenüber 151 bei low, bei identischer Genauigkeit. Er sollte als teurer Alias für eine mittlere Stufe behandelt werden, nicht als Ausschalter.

Welchen reasoning_effort-Wert sollte ich bei GPT-6 Astra standardmäßig verwenden?

low. Bei GPT-6 Astra verbrauchte die Einstellung für eine einstufige Aufgabe keine Reasoning-Tokens und für mehrstufige Aufgaben je nach Aufgabe 16 bis 345 Tokens. Sie erreichte 33 von 33 Punkten, während none nur 16 schaffte. max kostete für dieselben Antworten 2.3x so viel. Eine bestimmte Aufrufstelle sollte nur dann höher eingestellt werden, wenn eine Evaluation mit den eigenen Aufgaben bessere Ergebnisse nachweist. Der Wert sollte bei jedem Aufruf explizit gesetzt und die Anzahl der Reasoning-Tokens anschließend aus dem Usage-Block gelesen werden:

resp = client.chat.completions.create(
    model="gpt-6-astra",
    reasoning_effort="low",
    messages=[{"role": "user", "content": prompt}],
)
print(resp.usage.completion_tokens_details.reasoning_tokens)

Gemessen am 2026-09-07 über eine OpenAI-kompatible Chat-Completions-Oberfläche sowie für den Vergleich der Sichtbarkeit über den Responses-Endpoint: 11 Aufgaben mit lokal per Brute Force berechneten Lösungsschlüsseln, 7 Effort-Stufen, 3 Läufe pro Zelle auf beiden Modellen, Prompts mit Salt (ein eindeutiges Suffix pro Request, damit keine Antwort aus einem Cache ausgeliefert wird), Kosten aus der Usage-Abrechnung jedes einzelnen Requests. Die Benchmark-Werte stammen aus OpenAIs Launch-Tabelle und dem Leaderboard von Artificial Analysis, beide am selben Tag abgerufen. Die Kosten pro richtiger Antwort im Vergleich zu GPT-5.6 Sol wurden anhand der Token-Zahlen und der dokumentierten Listenpreise beider Modelle berechnet.

Verwandte Beiträge: Reasoning-Steuerung bei 13 Modellen, Kostenleitfaden zu GPT-5.6, Kosten von Claude Opus 5, Preisstaffeln für lange Kontextfenster, Kosten für Prompt-Cache-Writes.

← Zurück zum Blog