GPT-6 Astra, Sol oder Luna: Auswahl nach Aufgabe und Gesamtkosten
GPT-6 Luna eignet sich als günstiger Startpunkt für klar abgegrenzte und leicht prüfbare Aufgaben, Sol als Standardkandidat für komplexe Programmierung und agentische Workflows und Astra für besonders schwierige End-to-End-Arbeit mit hohen Fehlerkosten. Dieser Leitfaden vergleicht OpenAI Standard und BetterToken, erklärt die Preisstufe oberhalb von 272K Kontext, Caching, API-Abrechnung gegenüber Codex-Plänen sowie eine kontrollierte Migration von GPT-5.5.
Inhalt
Sie wissen vielleicht schon, dass Luna am günstigsten und Astra am leistungsfähigsten ist. Das beantwortet aber nicht die entscheidende Frage: Rechtfertigt diese Aufgabe einen 20- oder 100-mal höheren Tokenpreis? Nutzen Sie diese Startregel: überprüfbare Massenarbeit auf Luna, komplexe Programmierung und gewöhnliche agentische Workflows auf Sol, mehrdeutige oder teuer scheiternde End-to-End-Aufgaben auf Astra. Danach können Sie das Startmodell, die Eskalationssignale und die Kosten derselben Tokenlast bei OpenAI Standard und BetterToken bestimmen.
Hier beginnen: Luna für prüfbares Volumen, Sol für komplexe Entwicklung, Astra für teure Fehler
Wählen Sie das Startmodell nach Aufgabengrenzen und Fehlerkosten und korrigieren Sie die Route anschließend mit Ihren eigenen Abnahmedaten.
| Modell | Offizielle Positionierung von OpenAI | Geeignete erste Kandidaten | Wann eskalieren? |
|---|---|---|---|
gpt-6-luna | Effizientes Modell für fokussierte Aufgaben mit hohem Volumen | Kleine klar begrenzte Änderungen, strukturierte Extraktion, Klassifikation, Formatumwandlung, Tests nach eindeutiger Spezifikation und Batch-Aufgaben mit deterministischer Prüfung | Die Prüfung schlägt wiederholt fehl; dateiübergreifendes Denken ist nötig; die Werkzeugkette wird länger; eine kritische Unklarheit bleibt bestehen |
gpt-6-sol | Für komplexe Programmierung und agentische Workflows entwickelt | Funktionen über mehrere Dateien, Debugging, Code Review, Repository-Aufgaben mit mehreren Tool-Aufrufen sowie mittelkomplexe Recherche oder Dokumentation mit klaren Grenzen | Ein falscher Plan hätte große Folgen; mehrere Versuche übersehen zentrale Bedingungen; systemübergreifende Abwägungen oder schwierige Recherche werden nötig |
gpt-6-astra | OpenAIs leistungsfähigstes Modell für die schwierigste End-to-End-Arbeit | Architekturentscheidungen, komplexe Migrationen, systemübergreifende Störungsanalyse, riskante Codeänderungen und lange Abläufe mit Recherche, Dokumenterstellung oder computer use | Astra ist bereits die höchste Stufe dieser Gruppe; scheitert es weiter, sollte die Aufgabe enger gefasst, mit Belegen ergänzt oder um einen menschlichen Entscheidungspunkt erweitert werden |
Das Ziel ist nicht, jede vermeintlich „einfache“ Aufgabe zwingend Luna zuzuweisen. Gesucht wird das günstigste Modell, das die geforderte Qualitätsgrenze zuverlässig erreicht. Ein billiges Modell mit vielen Fehlversuchen kann am Ende teurer sein. Umgekehrt bezahlt man bei jeder gut spezifizierten Aufgabe mit Astra möglicherweise für Fähigkeiten, die der Workflow nicht nutzt.
Die öffentliche Dokumentation enthält noch keinen unabhängigen Vergleich von Astra, Sol und Luna auf denselben realen Aufgaben. Nutzen Sie die Matrix als ausführbaren Ausgangspunkt und erfassen Sie Erstabnahme, Wiederholungen, reale Zeit bis zum akzeptierten Ergebnis und Gesamtkosten pro akzeptierter Aufgabe.
Ähnliche Kontextgrenzen machen die Modelle nicht austauschbar
Die drei Modelle haben ähnliche Kontext- und Tool-Rahmen; Aufgabenform, Reasoning-Konfiguration und Fehlerkosten zählen daher stärker als die Fenstergröße. OpenAI positioniert Astra für komplexes Schlussfolgern, Programmierung, computer use, Recherche und Dokumente, Sol für komplexe Programmierung und agentische Workflows und Luna für fokussierte Arbeit mit hohem Volumen. Das hilft beim ersten Kandidaten, aber Ihre Ergebnisse müssen den Standard bestimmen.
Alle drei Modelle besitzen ein Kontextfenster von 1.050.000 Token, maximal 922.000 Input-Token und maximal 128.000 Output-Token. Die reine Kontextkapazität trennt sie daher kaum. Praktischer sind diese Unterschiede:
- Astra unterstützt bei
reasoning.effortdie Wertelow,medium,high,xhighundmax. - Sol und Luna unterstützen zusätzlich
none; Standard istmedium. Bei eng gefassten Aufgaben zeigt ein Test mit geringerer Denkstufe, ob Kosten vom Modell oder von unnötigem reasoning stammen. - Für tool-intensive agentische Abläufe sollte die Responses API bevorzugt werden. Bei Sol und Luna setzt function calling in Chat Completions einen
reasoning_effortvonnonevoraus. - Modell, Kontext, reasoning, Werkzeuge, Retrieval und Caching beeinflussen den Verbrauch. Die Prompt-Länge allein ist kein verlässlicher Kostenindikator.
Für einen fairen Vergleich müssen Schnittstelle, Kontext, Werkzeuge, reasoning effort, maximale Ausgabe und Abnahmekriterien gleich bleiben. Werden mehrere Variablen zugleich verändert, kann der beobachtete Unterschied von der Konfiguration statt vom Modell kommen.
Bei gleichen Token BetterToken nur mit OpenAI Standard vergleichen
Bei identischer Tokennutzung lagen die am 2026-09-24 geprüften BetterToken-Tarife bei 68 % der entsprechenden OpenAI-Standard-Tarife. Das ist nicht in jedem Fall der billigste Weg: OpenAI Batch und Flex sind niedriger, während Wiederholungen, Tools und menschliche Nacharbeit die Gesamtkosten bestimmen. Die Tabelle verwendet USD pro 1 Million Token und zeigt den Input-Kontext bis 272K.
| Model ID | Quelle | Input | Cache-Lesen | Cache-Schreiben | Output |
|---|---|---|---|---|---|
gpt-6-astra | OpenAI Standard | $10.00 | $1.00 | $12.50 | $50.00 |
gpt-6-astra | BetterToken | $6.80 | $0.68 | $8.50 | $34.00 |
gpt-6-sol | OpenAI Standard | $2.00 | $0.20 | $2.50 | $10.00 |
gpt-6-sol | BetterToken | $1.36 | $0.136 | $1.70 | $6.80 |
gpt-6-luna | OpenAI Standard | $0.10 | $0.01 | $0.125 | $0.50 |
gpt-6-luna | BetterToken | $0.068 | $0.0068 | $0.085 | $0.34 |
Überschreitet eine Anfrage 272K Input-Kontext, wechseln alle drei GPT-6-Modelle bei beiden Anbietern in die Langkontext-Stufe: Input, Cache-Lesen und Cache-Schreiben kosten das 2-Fache der Tabellenwerte, Output das 1,5-Fache; die höhere Stufe gilt für die gesamte Anfrage. Bei gpt-6-sol mit langem Kontext liegen Input/Cache-Lesen/Cache-Schreiben/Output beispielsweise bei OpenAI Standard bei $4.00/$0.40/$5.00/$15.00 und bei BetterToken bei $2.72/$0.272/$3.40/$10.20.
Preise sind dynamisch. Vor dem produktiven Einsatz sollten Sie die aktuellen Preise ansehen und Modellverfügbarkeit, Währung sowie die zutreffende Stufe erneut prüfen. OpenAI Batch und Flex kosten derzeit 50 % von Standard und liegen in diesem Stand unter den BetterToken-Preisen. Wenn asynchrone oder niedriger priorisierte Verarbeitung passt, dürfen sie nicht mit OpenAI Standard in derselben Vergleichsgrundlage vermischt werden. Regionale Aufschläge, Tool-Aufrufe, Container und Wiederholungen sind ebenfalls nicht enthalten.
Die GPT-Gruppe von BetterToken kann über API, Codex und externe Werkzeuge mit benutzerdefinierter Base URL genutzt werden. BetterToken ist kein OpenAI-Produkt, und seine API-Nutzung entspricht weder Nachrichten noch enthaltenem Kontingent oder credits eines ChatGPT- oder Codex-Abonnements.
GPT-5.5 im Einsatz? Vor dem Wechsel die Basis sichern
Wenn Ihr GPT-5.5-Workflow stabil ist, wechseln Sie nicht nur wegen einer neuen Modellfamilie. Sichern Sie die Basis für Qualität, Zeit und Kosten und spielen Sie dieselben Aufgaben auf Sol, Luna und Astra nach. Die folgenden Preise gelten in USD pro 1 Million Token und wurden am 2026-09-24 geprüft.
| Model ID | Quelle | Kontext | Input | Cache-Lesen | Output |
|---|---|---|---|---|---|
gpt-5.5 | OpenAI Standard | ≤ 272K | $5.00 | $0.50 | $30.00 |
gpt-5.5 | OpenAI Standard | > 272K | $10.00 | $1.00 | $45.00 |
gpt-5.5 | BetterToken | Keine Stufen | $3.40 | $0.34 | $20.40 |
BetterToken verwendet für gpt-5.5 keine gesonderte Langkontext-Stufe; OpenAI Standard tut dies oberhalb von 272K. Ein Preis für Cache-Schreiben fehlt, weil die veröffentlichte GPT-5.5-Preiszeile von OpenAI keinen solchen Wert enthält; er bleibt leer statt geschätzt zu werden.
Außerdem müssen zwei Migrationsfragen getrennt werden. OpenAI gibt an, dass GPT-5.5 am 2026-10-14 aus ChatGPT, ChatGPT Work und Codex in allen Plänen entfernt wird, während die OpenAI API nicht betroffen ist. Nutzer eines Codex-Plans benötigen daher vor diesem Datum eine Alternative. API-Key-Workloads müssen nicht allein wegen dieser planseitigen Abschaltung migrieren. Codex-Plankontingente, zusätzliche credits und in USD abgerechnete API-Nutzung sind unterschiedliche Abrechnungssysteme.
Die relevante Kennzahl sind Kosten pro akzeptierter Aufgabe
Der Preis eines Aufrufs zeigt nicht, welches Modell die Arbeit günstiger abschließt. Addieren Sie Fehlschläge, Wiederholungen, Cache-Schreibvorgänge, Tools und menschliche Nacharbeit und teilen Sie durch akzeptierte Ergebnisse. Das folgende Beispiel isoliert zunächst beide Abrechnungswege mit derselben Tokenmischung.
Angenommen, ein akzeptierter Lauf verbraucht:
- 120.000 nicht gecachte Input-Token,
- 100.000 aus dem Cache gelesene Input-Token,
- 10.000 Output-Token,
- keinen neuen Cache-Schreibvorgang,
- insgesamt 220K Input-Kontext und damit die kurze Stufe.
Mit „Token ÷ 1.000.000 × jeweiliger Preis“ ergibt sich für einen Lauf:
| Model ID | OpenAI Standard | BetterToken |
|---|---|---|
gpt-6-luna | $0.01800 | $0.01224 |
gpt-6-sol | $0.36000 | $0.24480 |
gpt-6-astra | $1.80000 | $1.22400 |
gpt-5.5 | $0.95000 | $0.64600 |
Das Beispiel vergleicht nur die Abrechnung derselben Token-Mischung, nicht Qualität, Geschwindigkeit oder endgültigen Nutzen. Bei gleicher Token-Mischung und Verarbeitungsstufe kostet Sol das 20-Fache von Luna, Astra das 5-Fache von Sol. Fehlversuche, längere Ausgaben, mehr Werkzeuge oder menschliche Nacharbeit können den Unterschied der Gesamtkosten jedoch verkleinern oder umkehren.
Eine nützlichere Formel lautet:
Abschlusskosten = Token-Kosten aller Versuche + Cache-Schreibkosten + Tool-Kosten + Fehlversuche und Nacharbeit.
Teilt man diese Summe durch die Zahl akzeptierter Aufgaben, erhält man die Kosten pro akzeptiertem Ergebnis. Diese Kennzahl ist für Produktionsrouting wesentlich aussagekräftiger als der Preis einer einzigen erfolgreichen Anfrage.
Erstes Modell nach Workflow wählen und Eskalation festlegen
Die Startverteilung kann eindeutig sein: risikoarme Arbeit mit zuverlässiger automatischer Prüfung auf Luna, komplexe Entwicklung auf Sol, hohes Risiko oder starke Mehrdeutigkeit auf Astra.
Prüfbare Massenarbeit: mit Luna beginnen
Wenn schema, linter, unit tests oder eine andere deterministische Regel Fehler schnell erkennen, testen Sie zuerst Luna. Feste Formatumwandlungen, Extraktion bekannter Felder, lokale Umbenennungen, Tests nach genauer Spezifikation und Massenausgaben mit zuverlässiger automatischer Abnahme sind gute Kandidaten.
Wenn die Prüfung fehlschlägt, eine nicht genannte Abhängigkeit auftaucht oder eine modulübergreifende Entscheidung nötig wird, sollte zu Sol eskaliert werden. Ein kleineres Modell darf nicht unbegrenzt dieselbe falsche Richtung wiederholen.
Mehrdatei-Code und agentische Workflows: mit Sol beginnen
Wenn die Aufgabe mehrere Dateien verstehen, Tools nacheinander nutzen oder den Plan nach Ausführungsergebnissen ändern muss, beginnen Sie mit Sol. Typische Beispiele sind Mehrdatei-Funktionen, Diagnose fehlgeschlagener Tests, Repository-Suche vor Änderungen und Fortsetzung anhand von Tool-Ergebnissen.
Der Umfang sollte trotzdem begrenzt bleiben. Ein Abschlusskriterium wie „analysieren, ändern, die relevantesten Tests ausführen und offene Punkte melden“ ist meist hilfreicher als reasoning.effort ohne Plan zu erhöhen. Astra kommt zum Einsatz, wenn Sol bei repräsentativen Aufgaben wiederholt Architekturbedingungen übersieht.
Mehrdeutige oder riskante End-to-End-Aufgaben: mit Astra beginnen
Beginnen Sie mit Astra, wenn die Kosten einer falschen Antwort deutlich über dem Modellaufschlag liegen. Systemübergreifende Migrationen, schwierige Produktionsstörungen, kritische Sicherheitsgrenzen, forschungsintensive Entscheidungen und Abläufe mit Code, computer use und langer Tool-Kette gehören dazu.
Auch Astra braucht eine Prüfung. Teilen Sie die Arbeit in Kontrollpunkte für Plan, Belege, Änderungen und Verifikation, damit das stärkste Modell nicht mehr Zeit auf einer falschen Annahme verbringt.
Noch unsicher? Modelle auf denselben realen Aufgaben vergleichen
Sie brauchen keine universell feste Beispielzahl. Sie brauchen einen repräsentativen Satz aus normalen, Grenz- und Fehlerfällen mit denselben Abnahmeregeln für jedes Modell.
- Repräsentativen Satz wählen. Kleine Änderungen, Mehrdatei-Entwicklung, Debugging, Tool-Nutzung und Wissensarbeit abdecken, nicht nur sorgfältig vorbereitete Demos.
- Abnahme vor dem Lauf definieren. Tests, lint, schemas, Faktenliste oder menschliche Prüfung verwenden. Eine nachträglich geänderte Bewertung macht den Vergleich unzuverlässig.
- Andere Variablen konstant halten. Gleichen Kontext, Tools, API, Reasoning-Aufwand, maximale Ausgabe und Umgebung verwenden. Einen anderen
reasoning.effortals separates Experiment behandeln. - Jeden Versuch erfassen. Erstabnahme, Wiederholungen, reale Zeit bis zum akzeptierten Ergebnis, Input-/Cache-/Output-Token, Toolaufrufe und Endkosten speichern.
- Kosten pro akzeptiertem Ergebnis berechnen. Fehlversuche und menschliche Nacharbeit einbeziehen, nicht nur den letzten Erfolg.
- Nach Aufgabenklasse urteilen. Ein Modell kann Codeänderungen bestehen, aber bei Recherche oder langen Agent-Läufen scheitern. Ein globaler Standard verdeckt diese Differenz.
- Route nach mehreren realen Läufen je Klasse prüfen. Verbessert eine höhere Stufe Abnahme oder Gesamtkosten nicht wiederholbar, zum kleineren Modell zurückkehren oder den bestehenden GPT-5.5-API-Workflow behalten.
Mindestens Erstabnahme, endgültige Abnahme, Gesamtkosten pro akzeptiertem Ergebnis sowie Median und hohes Perzentil der Zeit vergleichen. Ein Modell wird nur Standard, wenn es unter Ihrer realen Qualitätsschwelle dauerhaft gewinnt.
Wegen wiederholter Fehler und Risiko eskalieren, nicht wegen Modellprestige
Eskalation sollte durch beobachtbare Fehlersignale ausgelöst werden, nicht durch die Annahme, ein teureres Modell müsse automatisch besser sein.
- Luna → Sol: deterministische Prüfung derselben Aufgabenklasse scheitert wiederholt; datei- oder modulübergreifendes Denken ist nötig; Tool-Ergebnisse ändern den Plan wesentlich; oder eine kritische Unklarheit bleibt nach Präzisierung der Bedingungen bestehen.
- Sol → Astra: wiederholte Pläne übersehen wichtige Einschränkungen; ein Fehler betrifft Produktion, Sicherheit oder eine große Migration; oder die Aufgabe verbindet schwieriges Reasoning, Recherche, Dokumentation und Ausführung.
- Astra → Aufgabe verkleinern: scheitert auch Astra, Evidenz ergänzen, Workflow teilen oder menschliche Entscheidung anfordern, statt Kontext und Reasoning endlos zu erhöhen.
- Neues Modell → GPT-5.5-Rollback: in API-Workflows GPT-5.5 behalten, solange Qualität, Latenz und Wartung passen. Ein neuerer Name allein ist kein Migrationsgrund.
Luna → Sol → Astra ist die Startkette: zuverlässiger Prüfer bedeutet Luna, komplexe Entwicklung Sol, hohes Risiko Astra. Ändern Sie die Regel nur, wenn Ihre Daten zu Abnahme, Wiederholungen, Zeit und Kosten pro akzeptiertem Ergebnis eine andere Route besser zeigen.
