gpt-5.6-preise und kosten pro anfrage. kosten pro anfrage sind das, was euch ein nutzer bei jeder berührung eurer ki-funktion kostet. gpt-5.6s drei stufen erlauben es euch, diese aufrufe aufzuteilen, sodass die günstigen nicht länger zum flaggschiff-preis abgerechnet werden. das hier ist der blick eines product owners auf die rechnung, nicht der blick eines entwicklers auf das modell.
am 26. juni 2026 hat OpenAI die gpt-5.6-familie ausgeliefert: sol, terra und luna. luna kostet 1 US-Dollar eingabe / 6 US-Dollar ausgabe pro 1 million tokens. sol kostet 5 / 30 US-Dollar. das ist eine 5-fache spanne auf derselben produktoberfläche, wie finout berichtet.
wenn ihr bei einem series-b-saas-unternehmen mit einer kundenseitigen ki-funktion product leitet, ist diese spanne euer nächstes finance-review. die frage ist nicht, welches modell am klügsten ist. die frage ist, welche aufrufe wirklich sol brauchen und welche im stillen dafür überzahlt haben.
#wofür ist gpt-5.6s luna-stufe eigentlich gedacht?
was ist die gpt-5.6-luna-stufe und wie günstig ist sie?
luna ist die günstigste von openais drei gpt-5.6-stufen, am 26. juni 2026 eingeführt mit 1 US-Dollar eingabe und 6 US-Dollar ausgabe pro 1 million tokens gegenüber sol mit 5 / 30 US-Dollar – eine 5-fache lücke. openai zielt mit luna auf klassifizierung, intent-routing und zusammenfassung: die hochvolumigen aufrufe mit wenig denkaufwand, die hinter den meisten ki-funktionen stecken.
die meisten kundenseitigen ki-funktionen sind nicht eine aufgabe. sie sind ein haufen kleiner aufgaben, der einen einzigen button trägt. diese nachricht taggen. sie in den richtigen flow leiten. den gesprächsfaden zusammenfassen. und dann, manchmal, wirklich über einen schwierigen fall nachdenken.
die ersten drei sind genau das, wofür luna kalkuliert ist. die vierte ist der grund, warum ihr sol behaltet. wenn heute jeder dieser aufrufe auf euer flaggschiff-modell trifft, zahlt etwa 80 % eures token-volumens 5-mal mehr, als nötig wäre.
#wie viel nimmt die aufteilung der stufen tatsächlich von der rechnung?
nehmt eine funktion, die 10 millionen ausgabe-tokens pro monat verarbeitet, wovon 80 % auf routing, tagging und zusammenfassung entfallen. allein auf sol kostet diese ausgabe 300.000 US-Dollar im monat. verschiebt die 80 % auf luna, und dieselbe arbeit kostet 88.000 US-Dollar. die denkaufrufe bleiben unangetastet auf sol, denn genau dort muss die qualität halten.
der nutzer merkt keinen unterschied. das tag sitzt weiterhin, die zusammenfassung liest sich weiterhin gut, die schwierige frage bekommt weiterhin die gute antwort. das einzige, was sich geändert hat, ist, welche stufe für welchen aufruf abgerechnet wurde.
#verändert caching die rechnung ebenfalls?
ja, und es addiert sich. gpt-5.6 behält einen rabatt von 90 % auf zwischengespeicherte eingaben bei, mit expliziten cache-breakpoints und einer mindestlebensdauer des caches von 30 minuten, laut eesel vom 26. juni 2026. cache-schreibvorgänge werden mit dem 1,25-fachen abgerechnet, sodass die einmaligen kosten gering ausfallen.
euer system-prompt ist bei jedem aufruf identisch. genau diesen teil cacht ihr. bei einer funktion, die bei jeder anfrage einen 2.000-token-anweisungsblock sendet, nimmt das caching 90 % von diesem teil der eingabe – zusätzlich zu der stufe, auf die ihr den aufruf ohnehin geroutet habt.
we are
stennir ist eine ki-consultancy, die die routing-schicht ausliefert, damit eure funktion jeden aufruf liest und günstige arbeit an luna und echtes denken an sol schickt.
we aren't
stennir ist kein reseller, der eure modell-id gegen die günstigste stufe austauscht und hofft, dass die qualität übersteht.
#müsst ihr die funktion neu bauen, um das zu bekommen?
nein. unsere ai for product-builds teilen den traffic bereits nach aufgabe auf. routing, tagging und moderation laufen über die günstige stufe. denkaufgaben laufen über das flaggschiff. eine neue stufe wie luna ist damit eine konfigurationsänderung auf der günstigen spur, kein umbau der funktion, auf die sich eure nutzer verlassen.
wenn eure funktion heute alles an ein einziges modell schickt, ist genau das die erste lücke, die ihr schließen solltet. die aufteilung ist ein bis zwei tage arbeit. die ersparnis wächst mit jedem monat, in dem eure nutzung steigt.
unser cfo hat nicht gefragt, welches modell wir nutzen. er hat gefragt, was uns ein aktiver nutzer kostet. die aufteilung der stufen war die antwort, mit der die funktion das review überstanden hat.
das gehört zu unserer consultancy-praxis, und im journal findet ihr die belege aus funktionen, die wir bereits in produktion gebracht haben. wenn ihr eure eigenen zahlen vor dem nächsten finance-review wollt, bucht einen 30-minütigen discovery-call, und wir gehen die traffic-aufteilung eurer funktion gemeinsam mit euch durch.