Sie starten um 16 Uhr ein Refactoring und klappen um 18 Uhr den Laptop zu. Am nächsten Morgen ist der Durchlauf entweder abgeschlossen, läuft immer noch oder hat um 21:40 Uhr angehalten, um eine Frage zu stellen, die niemand beantworten konnte. Drei völlig unterschiedliche Situationen – und von außen sahen sie die ganze Nacht über genau gleich aus.
Anthropic gibt an, dass Claude Opus 5.5 18 Stunden oder länger an einer Aufgabe arbeiten kann. Nehmen Sie das wörtlich. Ein Durchlauf, der am Ende eines Arbeitstages gestartet wird, ist zu Beginn des nächsten noch längst nicht vorbei. Er hat elf Stunden lang ohne Sie Entscheidungen getroffen – und das Einzige, was ihn vor einer Fehlentscheidung bewahrt, ist das, was Sie vor Feierabend festgehalten haben.
Ein Durchlauf, der in Ihren Arbeitstag passt, wird beaufsichtigt. Zu einem Durchlauf, der Ihren Arbeitstag überdauert, kehrt man am nächsten Morgen zurück. Das sind zwei grundlegend verschiedene Arbeitsweisen – und die meisten Teams nutzen immer noch die erste.
TL;DR
Ein langlebiger Agenten-Durchlauf läuft über den Zeitpunkt hinaus, an dem noch jemand anwesend ist. Jede Entscheidung, die der Agent nicht selbst treffen kann, muss daher als gespeicherter Zustand warten – statt als Prompt in einem Terminal, das niemand liest. Drei Voraussetzungen müssen erfüllt sein, damit das sicher funktioniert: eine Abbruchbedingung, die der Agent eigenständig anwendet, ein Status für das Warten auf menschliche Eingaben, der sich klar von „In Arbeit“ und „Fehlgeschlagen“ unterscheidet, und eine Inbox, die morgens von einer namentlich benannten Person geöffnet wird. Agenten recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen Freigaben und nehmen die Ergebnisse ab. Sharkly bildet alle drei Punkte direkt im Task ab.
Was sich am 22. September 2026 geändert hat
Zwei KI-Labore haben am selben Tag neue Modelle veröffentlicht – und gemeinsam haben sie sowohl die Laufzeit als auch den Preis eines Durchlaufs drastisch verändert.
| Claude Opus 5.5 | GPT-6 Sol | GPT-6 Luna | |
|---|---|---|---|
| API-ID | claude-opus-5-5 |
gpt-6-sol |
gpt-6-luna |
| Input / Output pro Million Token | $4 / $20 | $2 / $10 | $0.10 / $0.50 |
| Gecachter Input | $0.20 Read, $5 Write | 90 % Rabatt auf Reads | 90 % Rabatt auf Reads |
| Kontextfenster | 1M | 872k | 1M |
Laut Anthropic ist Opus 5.5 im Betrieb 40 % günstiger als Opus 5, generiert Ausgaben etwa 30 % schneller, bietet eine maximale Ausgabelänge von 128k Tokens und bleibt 18 Stunden oder länger an einer Aufgabe. OpenAI gibt an, dass Sol und Luna jeweils 50 % günstiger sind als die Aktionspreise von GPT-5.6; „promotional“ ist OpenAIs eigene Wortwahl, der Vergleich bezieht sich also auf einen bereits rabattierten Tarif und keinen Listenpreis. Zudem meldet OpenAI einen Rabatt von 90 % auf gecachte Input-Reads bei GPT-6 und erklärt, dass Änderungen am Reasoning Effort oder an verfügbaren Tools den Cache nicht mehr invalidieren – was insbesondere für Durchläufe entscheidend ist, die die ganze Nacht über andauern.
Ein Durchlauf kann nun also gleichzeitig lang und günstig sein. Der menschliche Arbeitstag hat sich dadurch allerdings nicht verlängert – und die Kapazität, Ergebnisse zu sichten, ebenso wenig.
Das Review-Prinzip kehrt sich um
Wenn Sie einen Durchlauf live beobachten, fungieren Sie als dessen Error-Handler. Sie sehen, wie der Agent die falsche Datei öffnet, und greifen ein. Diese Korrektur taucht in keinem Log auf, weil es schlicht nicht nötig war.
Über Nacht fällt all das weg. Jede Korrektur, die Sie vorgenommen hätten, muss entweder bereits als Regel im Agenten hinterlegt sein oder zu einem Stopp führen. Eine dritte Option gibt es nicht. Ein langlebiger Agent ist kein unbeaufsichtigter Agent, der einfach fertig wird. Es ist ein Agent, der auf eine Entscheidung stößt, die Sie treffen müssen, während Sie schlafen. Konzipieren Sie Systeme daher für den Stopp, nicht für den Abschluss.
Anthropic berichtet außerdem von 85 % weniger erfolgreichen Versuchen, vorgegebene Leitplanken bei Opus 5.5 zu umgehen. Geringere Wahrscheinlichkeiten sind jedoch keine Abbruchbedingung. Auch ein Modell, das sich schwerer von seinen Instruktionen abbringen lässt, braucht um 2 Uhr morgens einen Ort, an dem es eine Rückfrage hinterlegen kann.
Drei unverzichtbare Voraussetzungen
1. Eine Abbruchbedingung, die der Agent ohne Sie anwenden kann
Das Ganze besteht aus zwei Teilen: einer harten Obergrenze, die die Plattform erzwingt, und schriftlichen Bedingungen, die der Agent selbst anwendet.
Die Obergrenze ist reine Konfiguration. Ein Sharkly-Agent verfügt über eine maximale Anzahl paralleler Tasks sowie ein Timeout pro Task, das direkt am Agenten und nicht pro Durchlauf definiert wird. Setzen Sie das Timeout über die längste gewünschte Laufzeit und unter die längste Laufzeit, für die Sie noch zu zahlen bereit sind. Es fungiert als Sicherung (Circuit Breaker), nicht als Zeitplan.
Die schriftlich festgelegten Bedingungen sind der Teil, den Teams gerne überspringen. Ein Agent, der nie stoppt, ist nicht fleißig, sondern unbeaufsichtigt.
Stop and wait for a human when:
- a change would touch a file outside the paths named in the Task;
- a check that passed at the start of the run still fails after two attempts;
- the Task description and the code disagree about intended behavior;
- you are about to run a command that writes outside the working directory.
When you stop, leave one comment: what you did, what you need, and the single
question that unblocks you. One question per stop.
Wählen Sie ein langes Timeout, wenn der Task eine klar abgegrenzte Änderung umfasst und Tests dem Agenten verlässlich signalisieren können, ob er fertig ist. Beschränken Sie es auf ein bis zwei Stunden, wenn der Task explorativer Natur ist, wenn die Akzeptanzkriterien noch vage formuliert sind und Diskussionen erfordern oder wenn der Durchlauf Bereiche berühren könnte, die Sie nicht ungeprüft geändert sehen möchten. Approval Gates definieren, wo ein Agent selbst dann stoppen muss, wenn er sich seiner Sache sicher ist.
2. Ein Wartezustand, der sich vom Arbeitszustand unterscheidet
In Sharkly sind der Lebenszyklus-Status eines Tasks und der Arbeitsstatus des Agenten getrennte Datenpunkte. Ein Task kann auf „In Progress“ stehen, während der Agent den Zustand „Working“, „Waiting for human reply“, „Waiting for human review“ oder „Error“ aufweist. Der zugrunde liegende Durchlauf besitzt wiederum eigene Statuswerte: Queued, Dispatched, Waiting for local directory, Running, Completed, Failed, Canceled.
Das klingt nach bürokratischer Detailverliebtheit – bis man acht Durchläufe über Nacht laufen lässt. Ohne diese Unterscheidung zeigt das Board um 9 Uhr morgens „In Progress“ für einen Agenten an, der mitten im Editieren steckt, genauso wie für einen, der vor elf Stunden gestoppt hat und auf eine einzige Antwort wartet. Man muss alle acht öffnen, um herauszufinden, welcher welcher ist.
| Was Sie sehen | Bedeutung | Was Ignorieren kostet |
|---|---|---|
| Working | Die Runtime arbeitet aktiv am Task | Vorerst nichts |
| Waiting for human reply | Der Agent hat gestoppt und eine Rückfrage gestellt | Jede Minute bedeutet ungenutzte Kapazität |
| Waiting for human review | Die Arbeit ist abgeschlossen, aber noch nicht abgenommen | Die Änderung wird nicht ausgeliefert |
| Error / Failed | Der Durchlauf ist fehlgeschlagen | Ein erneuter Versuch, den Sie noch nicht gestartet haben |
Das Ausführungsprotokoll macht einen Stopp am nächsten Morgen nachvollziehbar: warum ein Durchlauf in die Warteschlange gestellt wurde, wann er begann und endete, die Tool-Aufrufe und Runtime-Events, die Auslösequelle sowie Details zu Fehlern oder Abbrüchen. Das ist es, was Sie morgens ohne Vorwissen und ohne Erinnerung an den ursprünglichen Prompt prüfen müssen. Unter Status, Logs und Fehlersignale erfahren Sie, welche Daten Sie erfassen sollten, wenn Sie ein solches System selbst aufbauen.
3. Eine Inbox, für die eine feste Person zuständig ist
Ein Wartezustand ohne Verantwortlichen wartet endlos. Über-Nacht-Durchläufe scheitern lautlos – ganz anders als Durchläufe am Tag –, weil niemand da ist, der die Stille bemerkt.
Die Sharkly-Inbox ist eine persönliche Warteschlange für Task-Aktivitäten. Der Bereich „Primary“ bündelt alle Signale, die menschliches Eingreifen erfordern: Warten auf Ihre Antwort, Warten auf Ihr Review, fehlgeschlagene oder blockierte Aufgaben, direkte Erwähnungen und Ihnen zugewiesene Tasks. Fehlgeschlagene Durchläufe und Blockaden werden der zuständigen Person gemeldet statt an alle Abonnenten gestreut. So landet ein um 3 Uhr morgens gescheiterter Durchlauf gezielt bei jemandem – und nicht bei allen, was letztlich das Gleiche wäre wie bei niemandem.
Zwei gespeicherte Ansichten entscheiden über den Morgen: Tasks, die auf ein Review warten, und Tasks, die Agenten zugewiesen und derzeit blockiert sind. Benennen Sie eine feste Person, die diese prüft. „Das Team“ öffnet keine Inbox.
Der morgendliche Durchgang
Die Reihenfolge ist entscheidend – und es ist nicht die Reihenfolge, die das Board vorgibt.
- Zuerst: Warten auf menschliche Antwort. Eine Antwort setzt einen angehaltenen Agenten wieder in Gang; ein Review stößt erst einmal nichts an. Wenn SH-312 seit 21:40 Uhr wartet, ist eine kurze Antwort per Kommentar das Effizienteste, was Sie am ganzen Tag tun können – sie reiht sofort einen Folge-Durchlauf für denselben Task ein.
- Als Zweites: Fehlgeschlagen und blockiert. Lesen Sie den Titel des Ausführungsprotokolls und die technischen Details, bevor Sie einen erneuten Versuch starten. Ein einzelner HTTP-Status ist nur ein Anhaltspunkt, keine Diagnose.
- Als Drittes: Warten auf Review. Das ist die eigentliche Warteschlange – und genau die wächst, wenn Durchläufe günstiger werden.
- Zuletzt: Noch laufende Tasks. Lassen Sie den Task weiterlaufen oder brechen Sie ihn ab. Ein abgebrochener Durchlauf wird zwar nicht an derselben Stelle fortgesetzt, der Task und sein Verlauf bleiben jedoch erhalten. Brechen Sie ihn also ohne Zögern ab, wenn die Richtung nicht stimmt. Werfen Sie aber vorher einen Blick ins Log.
Was das Problem nicht löst
Längere Durchläufe reduzieren den Review-Aufwand nicht – sie konzentrieren ihn. Ein 18-stündiger Durchlauf liefert ein einziges Ergebnis, das die Entscheidungen einer ganzen Nacht bündelt. Und nach wie vor muss ein Mensch dieses Ergebnis lesen, beurteilen und abnehmen. OpenAIs eigene Forscher zeigen, wohin das führt: Ein durchschnittlicher Forscher verursacht täglich Inferenzkosten von über 600 $ zu API-Preisen; im 90. Perzentil sind es sogar über 7.000 $ pro Tag – während die Zahl der Personen, die diesen Output prüfen können, unverändert geblieben ist. Wir haben die Berechnung aufgestellt, als OpenAI diese Zahlen veröffentlichte, und an diesem Nenner ändert auch das jüngste Release nichts.
Günstigere und längere Durchläufe ermöglichen mehr parallele Versuche, bedeuten aber nicht weniger Entscheidungen. Menschliche Reviews sind der Flaschenhals – und Preissenkungen verschärfen dieses Problem zunächst, bevor sie es verbessern. Automatisierung endet dort, wo das Urteilsvermögen des Teams gefragt ist; und wenn sie stoppt, liefert sie ein Arbeitsergebnis mit vollständigem Kontext und nachvollziehbaren Belegen ab.
FAQ
Wie hoch sollte das Task-Timeout bei einem 18-Stunden-Modell angesetzt werden? Länger als der gewünschte Durchlauf, aber kürzer als ein Durchlauf, den Sie bereuen würden. Beginnen Sie bei alltäglichen Aufgaben mit wenigen Stunden und erhöhen Sie den Wert je nach Agent für Tasks, die wirklich eine ganze Nacht beanspruchen. Das Timeout beendet Durchläufe, die in einer Endlosschleife hängen; es bestimmt nicht, wie lange gute Arbeit dauern darf.
Was passiert mit einer Frage, die der Agent um 2 Uhr morgens stellt? Sie sollte in den Status „Waiting for human reply“ übergehen und als Inbox-Eintrag für die zugewiesene Person landen – nicht als Zeile im Scrollback-Puffer eines Terminals. Wenn Ihr aktuelles Setup solche Fragen übersehen würde, sollten Sie diese Lücke schließen, bevor Sie Timeouts hochsetzen.
Was das für die Praxis bedeutet
Kein Anbieter liefert den Teil mit, auf den es hier wirklich ankommt: Denn entscheidend ist, wo der Stopp landet und wer am nächsten Morgen die Verantwortung übernimmt. Diese Frage stellt sich bei Claude Code, Codex und allen anderen Tools gleichermaßen – weshalb die Verantwortung auf Task-Ebene gehört und nicht in die Sitzung eines einzelnen Anbieters.
Wenn Sie Agenten bereits über Nacht laufen lassen, ist der Test denkbar einfach: Öffnen Sie um 9 Uhr morgens Ihr Board und prüfen Sie, ob es einen nachdenkenden Agenten von einem unterscheidet, der seit letzter Nacht auf eine Antwort wartet. Falls nicht, ist das der erste Hebel, den Sie ansetzen sollten. Genau an dieser Schicht setzt Sharkly an: Der Task bündelt das Ziel, den Ausführungsstatus, Blocker, das Ergebnis und die menschliche Entscheidung – von der Anfrage bis zum Release.
