Schau dir an, was dein Team letzte Woche produziert hat. Ein kleiner Teil davon war das Feature, das im Standup besprochen wurde. Der Großteil war das Drumherum: Bug-Triage, Labels, ein Changelog, Erstkommentare zu elf Pull Requests, Test-Gerüste für ein Modul, das niemand übernehmen will, Dependency-Bumps, eine Doku-Seite, die veraltet ist, als sich das Format einer Response geändert hat. Hohes Volumen, wenig Ruhm – und bis zu dieser Woche kostete das pro Token dasselbe wie die interessante Arbeit, weil es auf derselben Runtime lief.
OpenAI hat GPT-6 Luna am 22. September veröffentlicht, für $0,10 pro Million Input-Tokens und $0,50 pro Million Output, API-ID gpt-6-luna, 1M-Kontextfenster. Genau in diese Kategorie gehört die langweilige 80-Prozent-Arbeit. Die sinnvolle Frage ist nicht, ob Luna gut ist, sondern welche Aufgaben dorthin wandern, welche auf keinen Fall, und wie man eine Task schreibt, die eine günstige Runtime abschließen kann.
TL;DR
Route Arbeit nach Überprüfbarkeit in die günstige Kategorie, nicht nach Schwierigkeit. Wenn ein Ergebnis verifiziert werden kann, ohne es neu zu machen, und eine falsche Antwort einen Reviewer eine Minute statt einen Nachmittag kostet, gehört sie auf Luna. Behalte Ermessensentscheidungen, alles, worauf das Board automatisiert, und alles, was niemand prüfen wird, auf der teuren Runtime. Formuliere Akzeptanzkriterien, die eine Maschine auswerten kann, halte den Aufwand für kurze Aufgaben niedrig, und lass jedes Ergebnis zur Task zurückkehren, wo ein Mensch es abnimmt.
Was Luna kostet – und womit es verglichen wird
Die von OpenAI veröffentlichten Luna-Vergleiche beziehen sich auf Kosten pro Task statt auf Leaderboard-Positionen – der richtige Rahmen für diese Arbeit.
| Veröffentlichtes Ergebnis | Luna | Verglichen mit |
|---|---|---|
| DeepSWE 1.1 | 66,6 % bei maximalem Aufwand | Vergleichbar mit Claude Opus 5 und Fable 5 bei mittlerem Aufwand, bei 93 % niedrigeren Kosten pro Task als Opus 5, 96 % niedriger als Fable 5 |
| AutomationBench 1.0.6 | +5,4 pp gegenüber dem Vorgänger bei hohem Aufwand | 58 % niedrigere Kosten pro Task |
| OSWorld 2.0 offline | Schlägt GPT-5.6 Sol bei mittlerem Aufwand | Etwa ein Zehntel der Kosten |
| Faktentreue | Gleichauf mit GPT-5.6 Sol bei höherem Aufwand | Etwa ein Hundertstel der Kosten |
Zwei Einschränkungen gehören zu diesen Zahlen. OpenAI beschreibt Sol und Luna als 50 % günstiger als das Promo-Preisniveau von GPT-5.6. „Promo“ ist OpenAIs Wort, und das ist wichtig: Die Vergleichsbasis ist ein Rabatt, kein Listenpreis. Gegen den GPT-5.6-Luna-Listenpreis, den unsere eigene Launch-Berichterstattung dokumentiert hat – $1 pro Million Input und $6 pro Million Output – liegt der Rückgang auf $0,10 und $0,50 näher bei 90 % beim Input und 92 % beim Output. Der echte Rückgang ist größer als die Schlagzeile, und die Schlagzeile misst gegen einen Sale.
Und jeder Anthropic-Vergleich in dieser Tabelle richtet sich gegen Claude Opus 5. Anthropic hat Opus 5 am selben Tag, an dem OpenAI veröffentlichte, durch Opus 5.5 ersetzt – für $4 pro Million Input und $20 pro Million Output gegenüber Opus 5 mit $5 und $25. Lies diese Margen als gegen die vorherige Generation gemessen, denn das sind sie. Wir erklären keinen Sieger zwischen den beiden aktuellen Flaggschiffen, und kein Anbieter hat diesen direkten Vergleich veröffentlicht.
Artificial Analysis, ein Drittanbieter und nicht einer der beiden Anbieter, platziert Luna bei 37 auf seinem Intelligenzindex, gegenüber 58 für Opus 5.5. Luna ist kein Frontier-Modell und wird auch nicht als eines verkauft. Es ist ein kompetenter Arbeiter zu einem Versorgungs-Preis – und genau darum geht es.
Die Eigenschaft, die entscheidet, was wandert
Teams sortieren Agent-Arbeit nach Schwierigkeit. Das ist die falsche Achse: Schwierigkeit ist eine Eigenschaft des Problems, und dein Risiko ist eine Eigenschaft des Review-Loops. Sortiere stattdessen nach Überprüfbarkeit.
Arbeit gehört in die günstige Kategorie, wenn beides zutrifft. Das Ergebnis kann verifiziert werden, ohne es neu zu machen – durch einen Test, einen Diff, eine Lint-Regel oder zehn Sekunden Lesen. Und ein falsches Ergebnis kostet einen Reviewer eine Minute, nicht einen Nachmittag, weil der Blast Radius ein Label, ein Kommentar oder eine Datei ist.
Dieses Paar ist der Grund, warum Test-Gerüste infrage kommen und ein Security-Review nicht – obwohl beides Textgenerierung über dasselbe Repository ist. Ein generierter Test läuft entweder oder nicht, und du erfährst es in derselben Minute. Ein übersehenes Autorisierungsleck in einem Review-Kommentar sieht genauso aus wie ein sauberer.
Was man abgeben kann
| Aufgabe | Was der Agent zurückgibt | Wie es geprüft wird | Blast Radius bei Fehler |
|---|---|---|---|
| Triage eingehender Bug-Reports | Zusammenfassung, vermutete Komponente, Reproduktionsversuch, Prioritätsvorschlag | Vier Zeilen, gelesen beim Aufnehmen der Task | Eine falsch geroutete Task |
| Labeling und Metadaten | Labels und Task-Typ, mit Nennung der angewandten Regel | Sichtbar auf dem Board | Ein falsches Label |
| Changelog und Release Notes | Entwurf von Notizen aus den gemergten Diffs eines Sprints | Diff gegen die Commits | Redaktionell, vor dem Release abgefangen |
| Erstkommentare beim Review | Beobachtungen als Kommentare, ausdrücklich keine Freigabe | Der Reviewer liest sie oder ignoriert sie | Rauschen, wenn nichts davon abhängt |
| Test-Gerüste | Testdateien, die kompilieren und laufen, mit klar markierten Lücken | Der Testlauf | Roter Build |
| Dependency-Bumps | Ein Bump pro Task, mit Changelog-Auszug und Testergebnis | CI | Ein Revert |
| Doku-Nachträge nach einem Merge | Doku-Änderungen mit Verweis auf den Quell-Diff | Diff-Review | Eine veraltete Seite bleibt veraltet |
Die gemeinsame Form: Jede liefert ein Artefakt, das jemand anderes in Sekunden anhand der vom Agent beigefügten Belege bewertet. Keine ist das letzte Wort zu irgendetwas – das ist der Test, den du anwendest, wenn du die Liste um das nächste, was dein Team aufnimmt erweiterst.
Was man nicht abgeben sollte
Drei Grenzlinien sind es wert, klar benannt zu werden, denn eine günstige Kategorie lädt zu diesen Fehlern ein.
Ein Erstcheck ist kein Review. Ein Agent, der Beobachtungen zu einem Diff postet, erzeugt Lesematerial. Es ist keine Freigabe, und in dem Moment, in dem ein Team einen sauberen Erstcheck als Signal dafür nimmt, dass eine Änderung sicher ist, wurde die günstige Kategorie in die Akzeptanzentscheidung befördert. Sei präzise dabei, was ein Review-Agent verifizieren kann und was nicht, und kennzeichne den Kommentar im Kommentar selbst als Erstcheck.
Ein Label, worauf das Board automatisiert, ist eine Entscheidung, keine Notiz. Wenn das Verschieben einer Task in einen Status einen Run auslöst, oder die Priorität steuert, was das Team als Nächstes aufnimmt, dann setzt ein Labeling-Agent die Richtung. Halte entweder die Automatisierung von diesen Feldern fern oder halte Labeling auf der Kategorie, der du Richtungsentscheidungen anvertraust.
Arbeit, die niemand prüfen wird, wird nicht günstiger, sondern unsichtbar. Eine günstige falsche Antwort ist nur günstig, wenn sie jemand bemerkt. Wenn eine Aufgabe keinen Leser hat, dann ist die Lösung, die Aufgabe zu streichen, nicht eine günstigere Runtime.
Also das Entscheidungspaar. Nutze Luna, wenn Arbeit hohes Volumen hat, begrenzt ist und durch etwas anderes als Vertrauen verifiziert wird. Nutze Sol oder Opus 5.5, wenn eine Task Kontext über Stunden halten muss, mehrere Module überspannt, oder mehr kostet, sie auf halbem Weg zu stoppen, als die Tokens kosten würden. Wenn du einen Agent auf einem Repository betreibst, splitte die Kategorien gar nicht auf: Wähle die Runtime, die zu deiner schwersten Arbeit passt.
Eine Task schreiben, die eine günstige Runtime abschließen kann
Ein Agent in Sharkly ist eine gespeicherte Arbeitskonfiguration und nicht ein einmaliger Prompt. Seine Anweisungen, Runtime, Skills, Repositories, Umgebung und Run-Einstellungen prägen, wie er Arbeit bearbeitet, also ist die richtige Einheit ein Agent pro langweiliger Aufgabentyp, nicht ein cleverer Agent, der alle sieben macht. Ein Team kann getrennte Agents für Code-Änderungen, Review, Testing, Dokumentation oder operatives Triage pflegen, ohne für jede Task die Anweisungen neu zu schreiben.
Eine günstige Runtime braucht einen engen Scope und eine mechanische Ziellinie:
SH-312 Triage: 9 unassigned bug reports from this week
Assignee: Triage Agent (Codex Runtime, gpt-6-luna)
For each report, return on the Task:
- one-sentence restatement of the observed behavior
- the suspected component, with the file or module that led you there
- whether you could reproduce it locally, and the exact command you ran
- a priority suggestion with one reason
Do not change files. Do not close or merge anything.
Finish with any question that must be answered before implementation.
Drei Dinge in dieser Task leisten die Arbeit. Der Scope ist ein Durchgang über neun Punkte, also ist ein Fehlschlag günstig zu verwerfen. Jede Behauptung trägt ihren Beleg, also ist das Prüfen Lesen statt Nachrecherche. Und die letzten beiden Zeilen setzen die Grenze: Dieser Agent berichtet, er handelt nicht.
Eine Einstellung ist es wert, bewusst entschieden zu werden. Lunas veröffentlichte Erfolge liegen bei hohem und maximalem Reasoning-Aufwand, und Aufwand ist eine Kosten- und Latenzentscheidung, kein Qualitätsregler, den man oben stehen lässt. Artificial Analysis – wieder ein Drittanbieter – hat die Variante mit maximalem Reasoning bei 153,9 Output-Tokens pro Sekunde für Luna gemessen, mit etwa 124 Sekunden bis zum ersten Token. [VERIFY] Was auch immer der aktuelle Wert ist, die Form bleibt: Bei maximalem Aufwand sind die günstigen Modelle nicht die schnell startenden. Eine Labeling-Aufgabe, die zwei Minuten nachdenkt, wirkt auf einem Board wie hängend. Betreibe kurze Aufgaben mit moderatem Aufwand und spare die hohen Einstellungen für Tasks, die sie verdienen.
Zwei Hinweise zum Zugang, denn in dieser Kategorie onboarden Teams. Luna läuft in Codex und ChatGPT Work für Plus-, Pro-, Business-, Enterprise- und Edu-Pläne, und Free- und Go-Konten erhalten es in der Desktop-App. In Chat ist es noch nicht. In Sharkly wird das Modell in der Runtime- oder Computer-Tool-Konfiguration festgelegt, niemals am Agent, und Sharkly zeigt dir den Modellnamen nicht zurück an.
Der Teil, den eine Preissenkung nicht löst
Neun Triage-Zusammenfassungen zu Luna-Preisen kosten fast nichts. Sie erzeugen trotzdem neun Dinge, die ein Mensch lesen muss. Ein Team, das sein ganzes Drumherum in eine günstige Kategorie verschiebt, hat die Entscheidungen, die auf einen Menschen warten, nicht reduziert, sondern nur deren Erzeugung günstiger gemacht – was nicht dasselbe ist wie günstiger abzunehmen. Deshalb bleibt die Review-Queue die Obergrenze, egal was der Token-Preis macht.
Was du ändern kannst, ist, wie gut diese Queue lesbar ist. Halte das Ziel, den Run, die Belege, die Blocker und den Human Review an der Task fest – von der Anfrage bis zum Release –, damit ein Erstkommentar sichtbar ein Erstcheck ist, eine Triage-Zusammenfassung den Befehl mitführt, der sie erzeugt hat, und die Elemente, die tatsächlich auf dich warten, von denen trennbar sind, die nur rauschen. Agents recherchieren, führen aus, testen und berichten. Menschen setzen die Richtung, erteilen Befugnisse und nehmen das Ergebnis ab.
Wenn du mehrere Agents betreibst und sich die günstigen gleich vervielfachen, gibt Sharkly dir einen Ort, um ihre Tasks zuzuweisen, zu sehen, was jeder Run produziert hat, und zu entscheiden, was ausgeliefert wird. Verbinde einen Computer, erstelle einen Agent für deine langweiligste Aufgabe und weise ihm eine echte Task zu.
