---
title: "OpenAI GPT-5.6: Neue Preise, mehr Tempo und Strategie zur Modellwahl"
locale: de
category: ai_data
category_name: "KI-Daten"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/openai-gpt-5-6-price-performance-model-routing
published_at: 2026-08-01T07:15:42+09:00
---

# OpenAI GPT-5.6: Neue Preise, mehr Tempo und Strategie zur Modellwahl

> OpenAI senkte ab dem 30. Juli 2026 die API-Preise für GPT-5.6 Luna und Terra um 80% beziehungsweise 20% und führte für Sol den Fast mode ein. Die Neugestaltung konzentriert sich auf eine Strategie, bei der Modelle passend zu den Phasen Planung, Ausführung und Validierung eingesetzt werden, anstatt für alle Aufgaben das Spitzenmodell zu verwenden, um so die Kosten pro Ergebnis zu senken.

## Key Points

- Der API-Preis von GPT-5.6 Luna wurde auf 0.20 Dollar je 1 Million Eingabe-Token und 1.20 Dollar je 1 Million Ausgabe-Token gesenkt.
- Der API-Preis von GPT-5.6 Terra wurde auf 2 Dollar je 1 Million Eingabe-Token und 12 Dollar je 1 Million Ausgabe-Token gesenkt.
- Der Fast mode von GPT-5.6 Sol ist laut Ankündigung bis zu 2.5-mal schneller als die Standardverarbeitung, kostet doppelt so viel und behält das Intelligenzniveau des Modells bei.
- Unternehmen können eine gestufte Konfiguration einsetzen, bei der Sol komplexe Entscheidungen und Planungen übernimmt, während Luna oder Terra die wiederholte Ausführung und Validierung verarbeiten.
- OpenAI erklärt, dass die gemeinsame Optimierung von Modell, Inferenzinfrastruktur und Agenten-Harness die Preissenkungen und die Verbesserung des Durchsatzes ermöglicht habe.

OpenAI hat die verbesserte Ausführungseffizienz der GPT-5.6-Produktfamilie mit niedrigeren API-Preisen und einer höheren Verarbeitungsgeschwindigkeit verknüpft. Entscheidend ist nicht, für alle Aufgaben ein einziges, besonders leistungsfähiges Modell einzusetzen, sondern Sol, Terra und Luna je nach Risiko, Komplexität, Latenz und Überprüfbarkeit der Aufgabe zu kombinieren, um die Kosten pro Ergebnis zu senken.

Die Preis- und Leistungsangaben basieren auf der Ankündigung von OpenAI vom 30. Juli 2026. Die Kundenbenchmarks und Angaben zu Effizienzsteigerungen stammen aus Messungen von OpenAI oder den in der Ankündigung zitierten Unternehmen und können daher nicht als in jeder Umgebung identisch reproduzierbar angesehen werden.

## API-Preisänderungen vom 30. Juli 2026

Die geänderten API-Preise für GPT-5.6 Luna und Terra lauten wie folgt.

| Modell | 1 Million Eingabetoken | 1 Million Ausgabetoken | Preissenkung | Hauptaufgabe |
|---|---:|---:|---:|---|
| GPT-5.6 Luna | 0.20 Dollar | 1.20 Dollar | 80% | Massenverarbeitung, wiederkehrende Aufgaben, klar definierte Ausführungsaufgaben |
| GPT-5.6 Terra | 2 Dollar | 12 Dollar | 20% | Alltagsaufgaben, die ein Gleichgewicht zwischen Qualität, Kosten und Geschwindigkeit erfordern |
| GPT-5.6 Sol | laut Ankündigung unverändert | laut Ankündigung unverändert | keine | komplexes Schlussfolgern, Planung, wichtige Entscheidungen |

Die Preise für kostenpflichtige Abonnements von ChatGPT und Codex sowie das gesamte Kontingentbudget ändern sich durch diese Ankündigung nicht. Bei der Nutzung von Terra und Luna werden jedoch weniger Credits abgezogen. OpenAI teilte mit, dass die Preisänderungen über AWS ab dem späteren Verlauf des 30. Juli schrittweise umgesetzt werden.

### Beispiel zur Berechnung der API-Kosten

Die Tokenkosten lassen sich wie folgt berechnen.

`Gesamtkosten = Anzahl der Eingabetoken ÷ 1,000,000 × Eingabepreis + Anzahl der Ausgabetoken ÷ 1,000,000 × Ausgabepreis`

Werden beispielsweise 10 Millionen Eingabetoken und 2 Millionen Ausgabetoken verarbeitet, ergeben sich auf Grundlage der einfachen Tokenpreise folgende Kosten.

| Modell | Eingabekosten | Ausgabekosten | Gesamt |
|---|---:|---:|---:|
| Luna | 2 Dollar | 2.40 Dollar | 4.40 Dollar |
| Terra | 20 Dollar | 24 Dollar | 44 Dollar |

Die tatsächliche Abrechnung kann durch dienstspezifische Bedingungen beeinflusst werden, etwa durch die Nutzung von Caching, die gewählte Verarbeitungsart oder die Struktur der Tool-Aufrufe.

## Aufgaben der GPT-5.6-Produktfamilie

GPT-5.6 ist kein einzelnes Modell, sondern eine gestufte Produktfamilie mit unterschiedlichen Kosten- und Leistungsniveaus.

### GPT-5.6 Sol

Sol übernimmt Schlussfolgerungen auf höchstem Niveau und die Lösung komplexer Probleme. Es eignet sich für Entscheidungen mit unklaren Anforderungen oder hohen Fehlerkosten, für langfristige Planung und für die Überprüfung wichtiger Ergebnisse.

### GPT-5.6 Terra

Terra zielt auf ein Gleichgewicht zwischen Leistung, Kosten und Antwortgeschwindigkeit. Es eignet sich für Aufgaben wie interne Fragen und Antworten in Organisationen, klar abgegrenzte Agentenaufgaben sowie allgemeine Analysen und Programmierung, die mehr Urteilsvermögen als Luna erfordern, aber nicht immer den Einsatz von Sol notwendig machen.

### GPT-5.6 Luna

Luna ist die schnellste und günstigste Stufe. Da es nicht nur kurze, einfache Texte erzeugen, sondern auch Tool-Aufrufe und mehrstufige Workflows unterstützen kann, lässt es sich als Ausführungsmodell einsetzen, das klar definierte Aufgaben in großem Umfang wiederholt.

Typische Einsatzgebiete sind:

- Klassifizierung großer Mengen von Dokumenten und Kundenanfragen
- Extraktion strukturierter Daten
- Wiederkehrende Codeänderungen
- Erstellung und Ausführung von Tests
- Dokumentenerstellung nach klaren Regeln
- Prüfung großer Mengen von Inhalten
- Automatisierung von Hintergrundagenten
- Unterstützung bei wiederkehrenden Recherchen

OpenAI behauptet, Luna biete eine Leistung auf einem ähnlichen Niveau wie Modelle, die vor einem Jahr als Spitzenmodelle galten, und zwar zu etwa 6% der geschätzten Kosten pro Aufgabe sowie mit nahezu 9-facher Geschwindigkeit. Die 6% beziehen sich hierbei nicht auf einen direkten Vergleich der Tokenpreise, sondern auf einen Vergleich der geschätzten Kosten, die zum Erzielen desselben Arbeitsergebnisses anfallen.

## Merkmale des Fast mode von Sol

Für GPT-5.6 Sol wurde ein Fast mode für die API eingeführt. Dieser ersetzt das bisherige Priority Processing und entspricht konzeptionell der `/fast`-Funktion von Codex.

| Punkt | Fast mode |
|---|---|
| Geschwindigkeit | bis zu 2.5-mal schneller als die Standardverarbeitung |
| Modellintelligenz | laut OpenAI identisch mit Standard |
| Preis | das 2-Fache des Preises der Standardverarbeitung |
| Abwärtskompatibilität | Anfragen mit dem Tag `priority` werden automatisch im Fast mode verarbeitet |

Die Formulierung „bis zu 2.5-mal schneller“ beim Fast mode garantiert nicht, dass sich die Latenz aller Anfragen exakt im gleichen Verhältnis verkürzt. Die tatsächlich wahrgenommene Geschwindigkeit kann je nach Länge des Prompts, Ausgabelänge, Dienstauslastung und Anzahl der Tool-Aufrufe variieren.

### Wann sich der Fast mode eignet

- Echtzeitdienste, bei denen Nutzer auf eine Antwort warten
- Entwicklungsumgebungen mit schnellen Wiederholungen von Codeänderungen und Prüfungen
- Aufgaben, bei denen Sol-Aufrufe die Gesamtlatenz des Agenten bestimmen
- Situationen wie die Reaktion auf Vorfälle oder die Analyse von Störungen, in denen bereits Verzögerungen von wenigen Minuten wichtig sind
- Aufgaben, bei denen die durch Verarbeitungsverzögerungen entstehenden Kosten höher sind als die zusätzlichen API-Kosten

Für Aufgaben ohne dringenden Fertigstellungstermin, etwa Hintergrund-Batches, nächtliche Analysen oder asynchrone Verarbeitung, kann die Standardverarbeitung wirtschaftlicher sein.

## Ergebnisorientierte Kriterien für die Modellauswahl

Bei der Modellauswahl geht es nicht darum, das in einer Rangliste höchstplatzierte Modell zu wählen. Für jede Aufgabe sollten die folgenden Fragen geprüft werden.

| Beurteilungsfaktor | Zu prüfende Frage |
|---|---|
| Folgen eines Fehlers | Welche Auswirkungen hat ein Fehler auf Kunden, Umsatz, Sicherheit oder regulatorische Compliance? |
| Fehlertoleranz | Können Menschen oder automatische Regeln Fehler erkennen? |
| Latenz | Wartet der Nutzer in Echtzeit oder ist eine asynchrone Verarbeitung möglich? |
| Durchsatz | Wie viele Vorgänge müssen pro Tag oder Monat verarbeitet werden? |
| Klarheit des Problems | Sind Eingaben, Regeln und erwartete Ausgaben ausreichend definiert? |
| Wert des Schlussfolgerns | Verbessert stärkeres Schlussfolgern die tatsächliche Ergebnisqualität in bedeutendem Maß? |
| Überprüfbarkeit | Lässt sich das Ergebnis durch Tests, Schemata oder Gegenprüfungen beurteilen? |

Klar definierte und automatisch überprüfbare Aufgaben eignen sich mit hoher Wahrscheinlichkeit für Luna. Ist ein bestimmtes Maß an Urteilsvermögen erforderlich, kann Terra in Betracht gezogen werden. Für die Klärung von Mehrdeutigkeiten, risikoreiche Entscheidungen oder die abschließende Prüfung folgenreicher Ergebnisse eignet sich Sol.

## Mit Sol planen und mit Luna ausführen

Auch innerhalb einer einzelnen Agentenaufgabe können für die verschiedenen Schritte unterschiedliche Modelle eingesetzt werden. Ein Programmieragent kann beispielsweise wie folgt aufgebaut sein.

1. Sol identifiziert Unklarheiten in den Anforderungen und strukturiert die Fragen.
2. Sol legt den Implementierungsplan, den Änderungsumfang und die Risikofaktoren fest.
3. Luna implementiert die geklärten Änderungen als Code.
4. Luna erstellt die Tests und führt sie aus.
5. Luna oder Terra bewertet die Testergebnisse und die Codeunterschiede.
6. Nur Schlussfolgerungen mit hoher Fehlerwahrscheinlichkeit oder besonderer Bedeutung werden erneut von Sol geprüft.

Diese Struktur kann die Kosten gegenüber dem Einsatz von Sol in allen Schritten senken und gleichzeitig hohe Fähigkeiten zum Schlussfolgern auf wichtige Entscheidungen konzentrieren. Werden die Modelle aufgeteilt, müssen jedoch Routingregeln, Fehlerbehandlung, Logverfolgung und Evaluierungssysteme separat konzipiert werden.

## Drei Effizienzebenen als Grundlage der Preissenkung

OpenAI erklärt, dass die Kostensenkungen nicht nur auf einer Preispolitik, sondern auf technischen Verbesserungen auf drei Ebenen beruhen.

1. Tokeneffizienz des Modells selbst
2. Hardwareeffizienz des Inferenzsystems
3. Effizienz des Agenten-Harness, das Modelle, Tools und Kontext miteinander verbindet

Diese Erläuterung basiert auf den von OpenAI veröffentlichten technischen Materialien; die vollständige detaillierte Kostenstruktur wurde jedoch nicht öffentlich gemacht. Daher lässt sich von außen nicht abschließend bestimmen, welchen Anteil technische Effizienz und strategische Preispolitik jeweils an der Preissenkung hatten.

## Optimierung von Modell und Inferenzsystem

### Verbesserte Arbeitsleistung pro Token

Nach Angaben von OpenAI wurde GPT-5.6 so trainiert, dass nicht nur die Erfolgsquote bei Aufgaben, sondern auch die Verarbeitungseffizienz optimiert wird. Das bedeutet, dass unnötig lange Schlussfolgerungen und Wiederholungen reduziert werden und das Modell mit weniger Token zum erforderlichen Ergebnis gelangt, wodurch Intelligenz und Arbeitsleistung pro Token steigen.

### Lastverteilung und Anfrage-Routing

Das Inferenzsystem verteilt Anfragen anhand der Region, verfügbaren Kapazität und Art des Beschleunigers auf Rechenzentren und Cluster. Innerhalb eines Clusters wird die Modellinstanz unter Berücksichtigung der aktuellen Last, der Länge des Eingabekontexts, der möglichen Cache-Nutzung und der Merkmale der Anfrage ausgewählt.

OpenAI erklärte, GPT-5.6 Sol und Codex für die Analyse des Produktionsverkehrs, die Suche nach Ursachen von Lastungleichgewichten, das Testen von Routingstrategien und die Anpassung von Heuristiken eingesetzt zu haben.

### Optimierung von GPU-Kernels

GPU-Kernels sind der zentrale Code, der die mathematischen Operationen eines Modells auf der Hardware ausführt. Je nach Speicherbewegungen, Synchronisierung, Datenanordnung und Parallelisierung können sich die Verarbeitungskosten selbst auf derselben GPU unterscheiden.

Laut OpenAI war GPT-5.6 Sol in der Codex-Umgebung daran beteiligt, Produktions-Kernels mithilfe von Triton und Gluon zu erstellen und zu optimieren. Durch die Kombination aus Kernelverbesserungen und zugehörigen Optimierungen seien die End-to-End-Kosten der Modellbereitstellung um 20% gesunken, erklärte das Unternehmen.

End-to-End-Kosten bezeichnen nicht nur die Kosten einer bestimmten Operation, sondern die Kosten der gesamten tatsächlichen Anfrageverarbeitung, einschließlich Routing, Datenübertragung, Modellausführung und Ausgabeerzeugung.

### Überprüfung der Korrektheit von Kernels

Auch schnelle Kernels sind unbrauchbar, wenn sie numerisch falsche Ergebnisse erzeugen. OpenAI erklärte, in Prüfwerkzeuge einschließlich FpSan investiert zu haben, um die Korrektheit von KI-generierten Kernels zu prüfen. FpSan ist die Abkürzung für Floating-Point Sanitizer und bezeichnet ein Open-Source-Werkzeug zur Erkennung von Fehlern bei Gleitkommaoperationen.

Dies zeigt, dass bei der Erzeugung von Produktionsinfrastruktur-Code durch KI neben Leistungsbenchmarks auch numerische Prüfungen, Regressionstests und Wiederherstellungsverfahren für Fehlerfälle erforderlich sind.

## Spekulatives Decoding und KV-Cache

### Spekulatives Decoding

Beim spekulativen Decoding schlägt ein kleines Entwurfsmodell zunächst Token vor, die als Nächstes erzeugt werden sollen, und ein großes Hauptmodell prüft mehrere Kandidaten parallel. Werden die Vorschläge akzeptiert, lässt sich die Anzahl der teuren sequenziellen Berechnungen des Hauptmodells reduzieren.

OpenAI erklärte, GPT-5.6 Sol habe Hunderte Experimente konzipiert und durchgeführt, bei denen Größe und Struktur des Entwurfsmodells verändert wurden, und das Training überwacht. Dadurch habe sich die Effizienz der Tokenerzeugung um mindestens 15% verbessert.

### KV-Cache und arbeitslastspezifische Einstellungen

Bei der Verarbeitung einer Eingabe erstellt das Modell einen Key-Value-Cache, also einen KV-Cache. Die optimale Konfiguration hängt von Eingabe- und Ausgabelänge, Batchgröße, Cache-Trefferrate, Anzahl gleichzeitiger Anfragen, Speicherkapazität und Art des Modell-Shardings ab.

OpenAI erklärt, mit Sol und Codex reale Arbeitslasten analysiert und Konfigurationskandidaten bewertet zu haben, um die Engine-Konfiguration für jeden Aufgabentyp präzise abzustimmen. Ziel ist es, mit derselben Hardware mehr Anfragen zu verarbeiten.

## Agenten-Harness und Kontextkosten

Ein Agent ruft Modelle und Tools mehrfach auf, um eine einzelne Nutzeranfrage zu bearbeiten. Entsteht bei einer Aufgabe mit 30 erforderlichen Modellaufrufen bei jedem Aufruf eine unnötige Verzögerung von 1 Sekunde, kann sich die Gesamtlatenz um etwa 30 Sekunden erhöhen.

OpenAI beschreibt die Rust-basierte Orchestrierungsebene, die Modelle, Tools und Nutzerumgebungen miteinander verbindet, als Agenten-Harness.

### Verzögerte Bereitstellung nur benötigter Tools

Werden Informationen zu Tools, Plug-ins, Skills und MCP-Integrationen von Beginn an vollständig in den Prompt aufgenommen, steigen die Anzahl der Eingabetoken und die Latenz. Das Harness nutzt einen Ansatz der verzögerten Erkundung, bei dem Informationen zu relevanten Tools erst dann bereitgestellt werden, wenn sie benötigt werden. Laut OpenAI sind Tool-Ausgaben standardmäßig auf 10.000 Token begrenzt, sofern das Modell kein separates Limit anfordert.

### Exakte Präfixerhaltung und Prompt-Cache

Beim Prompt-Caching wird der identische Anfang einer zuvor verarbeiteten Eingabe wiederverwendet, um redundante Berechnungen zu reduzieren. Für die Wiederverwendung des Cache muss das Prompt-Präfix exakt übereinstimmen.

Das Harness von OpenAI verwaltet den Verlauf in einer Append-only-Struktur und fügt neue Nachrichten und Tool-Ergebnisse am Ende hinzu. Tools werden in einer deterministischen Reihenfolge präsentiert, während Ausführungseinstellungen wie Genehmigungsrichtlinien zur Laufzeit angewendet werden, ohne die Tool-Definition selbst zu verändern. Dieser Ansatz ist vorteilhaft, um die Cache-Trefferrate wiederkehrender Agentenschleifen zu erhöhen.

## Wie Zahlen aus Unternehmensbeispielen zu lesen sind

Die offizielle Ankündigung von OpenAI enthält Bewertungen von Replit, Notion, Ramp, Blitzy, Cognition und Dust.

- Notion erklärte, dass Terra in der eigenen Bewertung eine mit GPT-5.5 vergleichbare Qualität zu den halben Kosten pro Aufgabe und in 60% kürzerer Zeit geliefert habe.
- Blitzy erklärte, dass nach der Einführung von Luna die Wiederverwendungsrate des Prompt-Cache von 24% auf 90% gestiegen sei und die Kosten 87% niedriger als beim vorherigen Standardmodell gewesen seien.
- Dust erklärte, Luna sei bei denselben Agentenaufgaben 40% schneller und 40% günstiger als das vorherige Standardmodell gewesen.
- Ramp erklärte, Luna als Standardmodell für die Automatisierung von Hintergrundagenten zu verwenden.

Diese Zahlen stammen aus Messungen mit den internen Aufgaben, Prompts, Bewertungskriterien und Systemstrukturen der jeweiligen Unternehmen. Da es sich nicht um einen unabhängigen gemeinsamen Benchmark handelt, sollten sie nicht unverändert auf die Aufgaben anderer Organisationen übertragen werden. Vor der Einführung ist eine eigene Evaluierung erforderlich, die reale Daten und Fehlerkosten berücksichtigt.

## Checkliste für die Prüfung vor der Einführung

1. Repräsentative Aufgabenstichproben sowie korrekte Antworten oder Bewertungskriterien vorbereiten.
2. Erfolgs- und Wiederholungsraten von Luna, Terra und Sol unter identischen Bedingungen vergleichen.
3. Nicht nur Tokenkosten, sondern auch Tool-Aufrufe, Prüfpersonal und Kosten der Fehlerbehebung einbeziehen.
4. Neben der durchschnittlichen Latenz auch die Latenz der oberen 95% oder 99% messen.
5. Schritte, die durch automatische Tests oder Schemaüberprüfungen validiert werden können, als Kandidaten für kostengünstige Modelle einstufen.
6. Für Aufgaben mit Bezug zu personenbezogenen Daten, Sicherheit oder Regulierung separate Genehmigungs- und Protokollierungsrichtlinien anwenden.
7. Routingkriterien festlegen, nach denen Ergebnisse mit geringer Vertrauenswürdigkeit auf Terra oder Sol hochgestuft werden.
8. Mit realem Datenverkehr prüfen, ob der Wert der geringeren Latenz die zusätzlichen Kosten des Fast mode übersteigt.

## Bedeutung und Grenzen

Diese Neuausrichtung zeigt, dass sich der Maßstab im Wettbewerb der KI-Modelle von einem einzelnen Höchstwert hin zu den Kosten pro Ergebnis verschiebt. Werden Luna für umfangreiche wiederkehrende Aufgaben, Terra für alltägliche Wissensarbeit und Sol für mehrdeutige und wichtige Entscheidungen eingesetzt, lassen sich Intelligenz, Geschwindigkeit und Kosten je nach Aufgabe kombinieren.

Allerdings lässt sich anhand der öffentlich verfügbaren Informationen nur schwer trennen, in welchem Umfang die Preissenkung um 80% jeweils auf technische Effizienzsteigerungen und Marktstrategien zurückzuführen ist. Auch die Wirtschaftlichkeit kostengünstiger Modelle wird nicht allein durch den Tokenpreis bestimmt. Führt eine höhere Fehlerquote zu mehr Wiederholungen und menschlichen Prüfungen, können die Gesamtkosten der Aufgabe steigen.

Die entscheidende Kennzahl ist daher nicht der Preis eines einzelnen Modellaufrufs, sondern die Gesamtkosten für ein einzelnes Ergebnis, das die Überprüfung bestanden hat. Nur wenn Erfolgsquote, Anzahl der Wiederholungen, Latenz und Prüfungskosten für jedes Modell gemeinsam gemessen werden, lässt sich beurteilen, ob die Preissenkung von GPT-5.6 tatsächlich einen geschäftlichen Mehrwert schafft.

## FAQ

### Wie hoch sind die geänderten API-Preise für GPT-5.6 Luna?
Mit Stand vom 30. Juli 2026 kostet Luna 0,20 Dollar pro 1 Million Eingabe-Token und 1,20 Dollar pro 1 Million Ausgabe-Token. Die von OpenAI bekannt gegebene Preissenkung gegenüber den bisherigen Preisen beträgt 80 %.

### Wie hoch sind die geänderten API-Preise für GPT-5.6 Terra?
Terra kostet 2 Dollar pro 1 Million Eingabe-Token und 12 Dollar pro 1 Million Ausgabe-Token. Die von OpenAI bekannt gegebene Preissenkung beträgt 20 %.

### Wurde auch der Preis von GPT-5.6 Sol gesenkt?
Nein. In dieser Ankündigung von OpenAI blieb der Preis für die Standard-Verarbeitung von Sol unverändert. Stattdessen wurde der Fast mode hinzugefügt, der bis zu 2,5-mal schneller als Standard ist und doppelt so viel kostet.

### Sinkt die Qualität der Modellantworten bei der Nutzung des Fast mode?
OpenAI erklärt, dass der Fast mode die Verarbeitungsgeschwindigkeit erhöht, ohne das Intelligenzniveau von Sol zu senken. Die Angabe „bis zu 2,5-mal“ bezeichnet jedoch eine Obergrenze; die tatsächliche Latenz kann je nach Länge der Anfrage, Ausgabemenge, Tool-Aufrufen und Systemauslastung variieren.

### Müssen bestehende Priority-Processing-Anfragen geändert werden?
Laut der Ankündigung von OpenAI funktioniert das `priority`-Tag bestehender API-Anfragen weiterhin und wird automatisch mit der Verarbeitung im Fast mode verknüpft. In einer Produktionsumgebung ist es sicherer, den Zeitpunkt der Anwendung und die tatsächlich abgerechneten Beträge separat zu überprüfen.

### Für welche Aufgaben eignet sich Luna?
Es eignet sich für umfangreiche, repetitive Aufgaben, bei denen die Regeln und die erwartete Ausgabe klar definiert sind und eine automatische Überprüfung möglich ist. Typische Beispiele sind die Klassifizierung von Dokumenten, die Datenextraktion, wiederholte Codeänderungen, die Ausführung von Tests, die Überprüfung von Inhalten und die Hintergrundautomatisierung.

### Welches Modell sollte man wählen, Terra oder Luna?
Wenn niedrige Kosten und ein hoher Durchsatz Vorrang haben und die Aufgabe klar definiert ist, kann zunächst Luna evaluiert werden. Wenn ein besseres Kontextverständnis und mehr Urteilsvermögen erforderlich sind, aber keine fortgeschrittenen Schlussfolgerungen auf dem Niveau von Sol, kann Terra geeignet sein.

### Sollte Sol nicht für alle Schritte eines Agenten verwendet werden?
Das ist möglich, kann jedoch die Kosteneffizienz verringern. Wenn Sol die Planung und Entscheidungen mit hohem Risiko übernimmt, während Luna oder Terra klar definierte Ausführungs- und Testaufgaben bearbeiten, lassen sich möglicherweise die Gesamtkosten senken und zugleich die Qualität der wichtigen Schritte aufrechterhalten.

### Beziehen sich die Aufgabenkosten von 6 % bei Luna auf einen Vergleich der Token-Preise?
Nein. Die von OpenAI genannten etwa 6 % sind die geschätzten Kosten pro Aufgabe, die erforderlich sind, um ein mit dem Vergleichsmodell vergleichbares Arbeitsergebnis zu erzielen. Dieser Wert ergibt sich nicht aus einer einfachen direkten Division der Token-Preise und ist als Vergleich zu verstehen, der die Evaluierungsaufgaben und die Erfolgsquote einbezieht.

### Wie sollte die tatsächliche Wirtschaftlichkeit eines API-Modells bewertet werden?
Dabei sollten nicht nur die Token-Preise, sondern auch die Erfolgsquote, die Anzahl der Wiederholungsversuche, die Kosten für Tool-Aufrufe, die Antwortlatenz, der Zeitaufwand für die menschliche Überprüfung und die Kosten der Fehlerbehebung berücksichtigt werden. Die nützlichste Kennzahl sind die Gesamtkosten pro Ergebnis, das die Überprüfung bestanden hat.

## Sources

- [Die Grenzen des Preis-Leistungs-Verhältnisses mit GPT-5.6 verschieben | OpenAI](https://openai.com/index/advancing-the-price-performance-frontier-with-gpt-5-6/)
- [Wie GPT-5.6 führende Intelligenz mit führender Effizienz vereint | OpenAI](https://openai.com/index/gpt-5-6-frontier-intelligence-efficiency/)

## Images

![Modellauswahl mit Puzzleteilen, gestaffelten KI-Chips, Aufgabenband und schrumpfenden Münzstapeln](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NDY2OSwicHVyIjoiYmxvYl9pZCJ9fQ==--5c50f46b468b0057808eb3e6351730cbce2f4b78/ai-4f6037ef.webp)
![Infografik zum Vergleich von KI-Modellabläufen, Geschwindigkeit, Kosten und Hardware](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NDY3NSwicHVyIjoiYmxvYl9pZCJ9fQ==--920476799a53738205d619a3a057685b5af9d05d/ai-334533bc.webp)