Hintergrund-Tasks

Ein Agent kann Arbeit weiterlaufen lassen, nachdem er geantwortet hat: einen Dev-Server, einen langen Build oder einen Subagent, der für sich arbeitet. OAR nennt das einen Hintergrund-Task. Die Task-Leiste über dem Eingabebereich listet diese Tasks auf, lässt dich jeden einzeln stoppen und die Ausgabe eines Befehls öffnen, und der Bericht des Agents über einen fertigen Task kommt als eigene Antwort.

Was als Hintergrund-Task zählt #

• Ein Shell-Befehl, den der Agent laufen gelassen hat, etwa ein Dev-Server oder ein langer Build. Neu in 0.9.12 Bei Grok jeder Befehl, der länger als zwei Sekunden läuft.
• Ein Subagent, der im Hintergrund arbeitet. Subagents haben eine eigene Seite; hier sind sie eine weitere Zeile in der Leiste.
• Ein Monitor und, bei Claude, ein Ultracode-Workflow (siehe Ultracode-Workflows).

Hat der Agent geantwortet und sind nur noch solche Tasks übrig, läuft in der Konversation kein Turn mehr, untätig ist sie aber auch nicht. Andere Agents sehen das als Zustand background_only (siehe Wie andere Agents es sehen). Du siehst es an der Task-Leiste, die stehen bleibt, solange ein Task läuft. Die Konversationsliste zeigt es an der Farbe des Titels: Eine Session, in der ein Turn oder Hintergrundarbeit läuft, behält den hellgrünen Titel (siehe Was eine Zeile zeigt).

Die Task-Leiste #

Die Leiste sitzt direkt über dem Nachrichtenfeld. Sie ist auf eine Zeile zusammengeklappt, etwa 2 background tasks running (2 Hintergrund-Tasks laufen), mit einem Spinner, solange Tasks laufen, und · 1 finished, wenn fertige Befehle aufgeführt sind. Klick auf die Zeile, um die Liste zu öffnen. Die Leiste ist ausgeblendet, wenn es nichts zu zeigen gibt, und die Liste scrollt, wenn sie mehr Zeilen enthält, als hineinpassen.

Jede Zeile zeigt:

Eine laufende Zeile hat keine eigene Zustandsangabe: Ein Task in der Leiste läuft. Ein Subagent verlässt die Leiste, wenn er endet; ein Shell-Befehl oder Monitor kann eine Stunde lang als fertige Zeile stehen bleiben. Nach Stop zeigt der Button Stopping… (Wird gestoppt…) bis zum nächsten Update der Leiste, höchstens 15 Sekunden lang.

Bei der SDK-Engine von Copilot hat eine Shell keinen Button Stop, wenn die Copilot-Runtime ihre Hintergrund-Tasks nicht auflisten kann. So eine Shell kannst du nur mit Kill session (Session beenden) beenden (siehe Was einen Task beendet).

Preview-Karten liegen in derselben Leiste, über den Tasks. Siehe Was du siehst. Eine Preview hält die Leiste offen, nachdem der Task, der ihren Server gestartet hat, beendet ist.

Die Task-Konsole Neu in 0.9.12 #

Klick in der Leiste auf die Beschreibung eines Shell-Befehls oder Monitors, und seine Konsole öffnet sich: die Ausgabe des Befehls, damit du siehst, was ein Build, ein Dev-Server oder ein Testlauf gerade tut, ohne den Agent zu fragen. Auf dem Handy füllt sie den Bildschirm. Neu in 0.9.13 Auf einem breiteren Bildschirm endet sie über der Zeile des Tasks in der Leiste, sodass Test-Chip, Uhr und Stop der Zeile sichtbar und live daneben bleiben. Escape, ×, ein Klick außerhalb oder der Zurück-Button schließen sie.

• Die letzten 2.000 Zeilen erscheinen beim Öffnen, und neue Ausgabe folgt live. Hast du nach oben gescrollt, bleibst du, wo du bist, und Jump to end ↓ (Zum Ende springen) bringt dich zurück.
• Load earlier (Frühere laden) oben blättert durch das ganze Log zurück, bis zu 2.000 Zeilen auf einmal, bis etwa 5 MB geladen sind. Danach zeigt der Button older output not loaded (ältere Ausgabe nicht geladen). Neu in 0.9.13 Der Header der Konsole hat denselben Button, sobald es frühere Ausgabe gibt, damit er griffbereit ist, während du dem Ende eines langen Logs folgst.
• Fortschrittsbalken, die eine Zeile neu zeichnen, zeigen nur ihren letzten Stand, und eine Zeile, die mehrmals hintereinander kommt, erscheint einmal mit ×N.
• Farben bleiben, ein roter Fehler ist also weiter rot. Neu in 0.9.13 Invertierter Text tauscht seine Farben, sodass die Badges RUN, PASS und FAIL von vitest gefüllt erscheinen. Andere Steuerzeichen fallen weg, und eine Zeile wird bei 4.000 Zeichen abgeschnitten.
• Zugangsdaten werden geschwärzt: Tokens und Keys der üblichen Formen, Bearer- und Basic-Header, ein Passwort in einer Adresse und ein Wert nach einem Namen wie API_TOKEN= oder password: lauten [redacted]. Neu in 0.9.13 Ebenso das Passwort von curl -u name:password, die Werte von --password, --token und --secret, mysql -p…, docker login -p, sshpass -p, redis-cli -a, ein AWS Secret Access Key, ein Slack-Webhook-Pfad, Werte von ?key=, &sig= und &token= in einer Adresse und ein Authorization-Header mit beliebigem Schema. Ein Verweis wie $API_TOKEN oder $(cat ~/.token) bleibt unangetastet. Die Task-Zeilen in der Leiste werden genauso bereinigt: Beschreibung, Zusammenfassung und Aktivitätszeile eines Tasks.

Der Header nennt den Task, seine Art (Shell oder Monitor), wie lange er schon läuft und ob er running, completed, stopped oder failed, exit code 1 ist, oder Neu in 0.9.13 waiting for its worker after the relay restart (siehe Nach einem Relay-Neustart). Er trägt auch den Hinweis auf Stille und den Testlauf-Chip und, solange der Task läuft, ein eigenes Stop.

Agents auf diesem oder einem anderen Relay können dieselbe Ausgabe mit read_task_output lesen. Was jeder Provider bietet, steht unter Nach Provider.

Stille Tasks #

Ein laufender Shell-Befehl oder Monitor, der eine Minute oder länger nichts geschrieben hat, sagt das in seiner Zeile und im Header seiner Konsole: no output for 12 min. Ab Settings → General → Mark a background task as quiet after (Einstellungen → Allgemein → Hintergrund-Task als still markieren nach) wird der Hinweis bernsteinfarben. Das sind standardmäßig 10 Minuten, einstellbar von 1 bis 120 Minuten, und es gilt für jeden Browser am Relay.

Still heißt nicht hängend: Manche Schritte geben lange nichts aus. Öffne die Konsole, um die letzten Zeilen zu sehen, und warte dann, erhöhe die Einstellung oder stoppe den Task mit Stop. Das Relay sieht alle 10 Sekunden in die Ausgabe, der Hinweis kann also so viel hinterherhinken.

Befehle, die in tail geleitet werden Neu in 0.9.13 #

Ein Befehl, der in tail geleitet wird, etwa npm test 2>&1 | tail -40, schreibt nichts, bis er endet: tail hält die letzten Zeilen bis dahin zurück. Seine Konsole sähe hängend aus. Zeigt die Befehlszeile des Tasks so eine Pipe, markiert die Konsole, wo die Ausgabe aufhört, bis mehr Ausgabe kommt oder der Task endet:

Output stops here: this command pipes into tail, so the rest arrives when it ends.
Logging to a file instead (> run.log 2>&1) and following that file shows it live.

Der Hinweis no output for N min der Zeile sagt beim Hovern dasselbe. tail -f und head geben Zeilen weiter, sobald sie kommen, und werden nicht markiert. Um einen Lauf live zu verfolgen, bitte den Agent, in eine Datei zu loggen (> run.log 2>&1), und folge dieser Datei.

Claude, DeepSeek, Copilot und Grok melden dafür die Befehlszeile eines Shell-Tasks. Das Relay schwärzt darin Zugangsdaten wie in der Ausgabe und behält ihre ersten 2.000 Zeichen. Eine Session, deren Agent vor dem Update auf 0.9.13 gestartet wurde, meldet keine.

Testläufe #

Sieht die Ausgabe eines Befehls wie ein Testlauf von vitest, Playwright, node:test, jest, pytest oder turbo aus (auch über pnpm gestartet), zeigen seine Zeile und der Header seiner Konsole einen Chip mit den Zahlen: ✓ 412 ✘ 2 in Rot, wenn Tests fehlgeschlagen sind, oder ✓ 38, wenn keiner fehlschlug. Fahr mit der Maus über den Chip, um den Runner und die Zahlen der bestandenen, fehlgeschlagenen und übersprungenen Tests zu sehen. Die Zahlen folgen dem Lauf, während er läuft. Neu in 0.9.13 Ein noch laufender Lauf wird über sein ganzes Log gezählt, egal wie lang, und weitergelesen, während es wächst, sodass der Chip jeden Test behält, auch wenn die Ausgabe über das hinauswächst, was die Konsole zeigt. Sobald der Runner seine abschließende Zusammenfassung ausgibt, entscheidet diese.

In der Konsole springen der Chip und der Button first failure (erster Fehler) daneben, der erscheint, wenn Tests fehlgeschlagen sind, zum ersten fehlgeschlagenen Test in der geladenen Ausgabe. Liegt er in älterer Ausgabe, sagt die Konsole das; Load earlier holt ihn herein.

Fertige Befehle #

Ein Shell-Befehl oder Monitor, dessen Ausgabe das Relay aus einer Datei liest, bleibt nach seinem Ende eine Stunde lang als abgeblendete Zeile in der Leiste: ✓, wenn er abgeschlossen wurde, ✘, wenn er fehlschlug, ■, wenn er gestoppt wurde, Neu in 0.9.13 ?, wenn das Relay nicht wissen kann, wie er geendet hat (Nach einem Relay-Neustart), mit seiner Laufzeit und seinem Test-Chip. Seine Konsole öffnet sich weiterhin, sodass du nachlesen kannst, warum ein Lauf fehlschlug, nachdem der Agent schon weitergemacht hat. × blendet die Zeile aus, bis du die Seite neu lädst. Pro Konversation bleiben höchstens 20 solcher Zeilen. Neu in 0.9.13 Sie überstehen einen Relay-Neustart (siehe Nach einem Relay-Neustart).

Wenn ein Task fertig ist #

Endet ein Task, verlässt er die Leiste, oder ein Befehl bleibt als fertige Zeile stehen. Der Agent wird geweckt, sieht sich das Ergebnis an und antwortet. Diese Antwort ist eine Fortsetzungsantwort: Sie antwortet nicht auf eine Nachricht von dir, und ihr Header trägt ein Badge background continuation (Hintergrund-Fortsetzung). Du kannst sie lesen wie jede andere Antwort.

Für Benachrichtigungen ist eine Fortsetzung eine Antwort wie jede andere: Ein Gerät, das dich benachrichtigt, wenn ein Turn fertig ist, tut das auch hier: Turn completed (Turn abgeschlossen) in Settings → Notifications (Einstellungen → Benachrichtigungen). Ein Agent, der die Session beobachtet, bekommt stattdessen ein Ereignis task_finished oder task_failed (siehe Wie andere Agents es sehen).

Kommt ein Relay-Neustart zwischen das Ende eines Tasks und seine Fortsetzung, wird die Fortsetzung verworfen, nicht erneut ausgeführt. Siehe Neustarts und Fortsetzen.

Ultracode-Workflows #

Ultracode-Workflows sind eine Funktion von Claude. Die Leiste zeigt einen Workflow als Zeile Workflow mit einem Chevron. Öffne den Chevron, um den Fortschrittsbaum zu sehen.

• Phasen sind Überschriften, und die Agents des Workflows stehen darunter.
• Jeder Agent zeigt ein Zustandssymbol (○ eingereiht, ◐ läuft, ✓ fertig, ✗ fehlgeschlagen oder abgebrochen), sein Label und eine Zeile mit Modell, Tokens, Anzahl der Tool-Aufrufe, Zeit und, nach einem erneuten Versuch, attempt 2. Ein laufender Agent zeigt zusätzlich das Tool, das er gerade nutzt.
• Logzeilen, die letzten fünf, stehen über den Phasen.
• Ein Baum mit mehr als 100 Agents endet mit +N more agents (+N weitere Agents).

Der Baum ist offen, solange der Workflow läuft, und zusammengeklappt, sobald er abgeschlossen ist. Was du mit dem Chevron wählst, bleibt erhalten, solange die Zeile in der Leiste steht. Während der Workflow läuft, können dem Baum Phasentitel und Logzeilen fehlen; der endgültige Baum hat sie.

Endet der Workflow, behält die Antwort, die ihn zusammenfasst, eine zusammengeklappte Karte im Verlauf:

🧩 Finished background task — review-shared-modules · 20 agents · 1.2M tok · 28m

Öffne sie für den endgültigen Baum. Unbekannte Felder werden weggelassen, und ein Workflow, der nicht abgeschlossen wurde, sagt in Klammern, wie, etwa Finished background task (failed), oder (unconfirmed), wenn das Ergebnis nie ankam. Die Karte wird mit der Antwort gespeichert und bleibt nach einem Neuladen erhalten.

Background task timeout (Timeout für Hintergrund-Tasks) #

Settings → General → Background task timeout (Einstellungen → Allgemein → Timeout für Hintergrund-Tasks) legt fest, wie lange Hintergrund-Tasks allein eine Session nach ihrer Antwort am Laufen halten dürfen. Es ist ein Schieberegler von 0 bis 10 Stunden in Schritten von 5 Minuten. Standard sind 4 Stunden. 0 heißt kein Limit: Die Tasks laufen dann, bis sie fertig sind oder du sie stoppst.

Ist die Zeit um, stoppt das Relay die Tasks, und der Agent berichtet darüber in einer Fortsetzungsantwort wie bei jedem Task, der endet. Bei Claude und DeepSeek läuft die Uhr nur, solange nichts außer Tasks die Session in Gang hält, und beginnt wieder bei null, sobald zwischendurch ein Turn läuft. Bei der SDK-Engine von Copilot hat jeder Task seine eigene Uhr, die startet, wenn dieser Task startet. Wie sich das in die anderen Timer einfügt, steht unter Turns und die Queue.

Was einen Task beendet #

Nach einem Relay-Neustart Neu in 0.9.11 #

Ein Worker, der über einen Relay-Neustart weiterläuft, behält seine Tasks, und das Relay fragt ihn beim nächsten Heartbeat des Workers erneut danach. Sie kommen mit ihrer ursprünglichen Startzeit in die Leiste zurück, sodass die Session weiter als arbeitend gilt: Suspend host (Host in den Ruhezustand versetzen) wartet auf sie, und eine beobachtende Session bekommt kein all_idle. Ein Task, der endete, während das Relay weg war, meldet sein Ende trotzdem.

Eine Session, deren Worker vor dem Update auf 0.9.11 gestartet wurde, kann diese Frage noch nicht beantworten. Sie zeigt eine Zeile, background work, details not reported since the relay restarted (Kill session in its ⋯ menu ends it), bis sie eine Änderung meldet. In den ersten 45 Sekunden nach dem Start des Relays wartet ein Ruhezustand auch auf Sessions, die sich noch nicht gemeldet haben.

Neu in 0.9.12 Die Konsolen der zurückkehrenden Tasks öffnen sich wieder, mit dem ganzen Log, und ein Hinweis auf Stille erscheint wieder, sobald das Relay in die Ausgabe gesehen hat.

Neu in 0.9.13 Das Relay hält die Konsolenzeilen in seiner Datenbank, sodass auch die Konsolen den Neustart überstehen:

• Fertige Zeilen kommen für den Rest ihrer Stunde mit ihrem ✓ oder ✘ zurück.
• Die Konsole eines laufenden Befehls liest dessen Ausgabe sofort, noch bevor sein Worker sich gemeldet hat. Bis der Worker sagt, dass der Befehl noch läuft, sagt die Konsole, dass sie auf ihren Worker wartet, und hat kein Stop.
• Ein Befehl, dessen Worker nicht zurückkam (er ging mit dem Relay unter, etwa bei einem Reboot), wird nach etwa anderthalb Minuten als fertig markiert, nie wieder als laufend. Das Relay kann nicht wissen, wie er geendet hat, also zeigt seine Zeile ein neutrales ? statt ✓ oder ✘, mit dem Titel ended, result unknown. Seine Ausgabe bleibt für den Rest der Stunde lesbar.

Befehle, die vor dem Update auf 0.9.13 liefen, haben keine gespeicherte Zeile; sie kommen zurück, wenn ihr Worker sich meldet, wie oben.

Unter dem Linux-Dienst stoppt ein Neustart die Worker und mit ihnen ihre Tasks; siehe Was ein Neustart behält.

Wie andere Agents es sehen #

list_sessions und read_session geben jeder Session einen state: running_turn, background_only (der Agent hat geantwortet, Hintergrundarbeit läuft noch) oder idle. Sie listen auch ihre tasks auf, die Hintergrund-Agents und Shell-Tasks, jeweils mit Start, letzter Aktivität, Ausgang und, wo bekannt, Exit-Code. Eine Session mit nur Hintergrund-Tasks gilt deshalb nicht als inaktiv. Neu in 0.9.12 Bei der SDK-Engine von Copilot meldet ein fertiger Task completed, failed oder stopped, eine Shell ihren Exit-Code und ein Subagent sein Ergebnis (oder seinen Fehler) als Zusammenfassung; vorher endeten solche Tasks als unknown.

Ein Agent, der die Session beobachtet, kann durch die Ereignisse task_finished und task_failed geweckt werden, jeweils mit Beschreibung, Ausgang und Zusammenfassung des Tasks. Ein Task, der gestoppt wurde oder mit einem Code ungleich null endete, zählt als fehlgeschlagen. Er kann auch task_started anfordern. Neu in 0.9.13 Standardmäßig erfährt ein beobachtender Agent von einem Subagent, der fertig ist, und von jedem Task, der fehlschlug, aber nicht von einem Shell-Befehl oder Monitor, der gut ausging; dafür nennt er task_finished.

Neu in 0.9.12 read_session gibt außerdem zu jedem Task seine taskId, ob er lesbare Ausgabe hat und bei einem Befehl seine stille Zeit und seine Testzahlen. Neu in 0.9.13 Außerdem die Befehlszeile eines Shell-Tasks, wo der Provider sie meldet. Beschreibung, Zusammenfassung, letzter Tool-Aufruf und Befehlszeile eines Tasks sind wie in der Konsole von Zugangsdaten bereinigt. read_task_output liest dann das Ende dieser Ausgabe, bereinigt wie die der Konsole.

Nach Provider #

Der Ultracode-Baum und die Karte Finished background task (Abgeschlossener Hintergrund-Task) gibt es nur bei Claude. Die vollständige Funktionstabelle steht unter Provider im Überblick.