Der morgendliche Testbericht kann fertig sein, bevor du Open WebUI öffnest

Montagmorgen um 8:30 Uhr öffnet eine Entwicklerin die nächtlichen Testergebnisse. Drei Jobs sind rot. Der erste verlor die Verbindung zur Testdatenbank, der zweite lief sporadisch in ein Zeitlimit, und der dritte scheiterte an einer Assertion in Code, der am Freitag geändert wurde. Die Ergebnisse zu sortieren dauert länger, als die roten Symbole zu erkennen. Ein wiederkehrender Coding-Agent könnte einen kurzen Bericht im Chat hinterlassen, mit der fehlgeschlagenen Assertion und dem relevanten Logauszug ganz oben.

Open WebUI, eine selbst hostbare Chatoberfläche für KI-Modelle und Werkzeuge, unterstützt in v0.13.3 Coding-Agenten in geplanten Automatisierungen. GitHub datiert das Release auf den 8. November 2026 um 23:48 UTC. Eine Automatisierung kann ein Terminal, ein Arbeitsverzeichnis und einen dort verfügbaren Coding-Agenten speichern. Die Ergebnisse landen in einem Chat. Der Zeitplan startet den Auftrag damit in einer konkreten Arbeitsumgebung, was den Morgenbericht praktikabel macht. Release-Hinweise zu Open WebUI v0.13.3

Als erster geplanter Auftrag eignet sich ein Bericht, den jemand in wenigen Minuten prüfen kann. Die Automatisierung sammelt Belege. Die nächste Entscheidung bleibt bei der Person, die das Projekt verantwortet. Ein brauchbarer, wiederholbarer Bericht liefert eine Grundlage für die Frage, ob ein weiteres Recht nötig ist.

Die Automatisierung merkt sich die Arbeitsumgebung

Open WebUI unterstützt bereits wiederkehrende Prompts. Ein Lauf startet einen Chat über den üblichen Ablauf zur Antwortgenerierung. Dadurch können Modelleinstellungen, Werkzeuge, Filter und anwendbare Speichereinstellungen wirken. Version 0.13.3 ergänzt die Auswahl eines Coding-Agenten, den ein Terminal meldet. Nach Wahl des Terminals zeigt die Modellauswahl verfügbare Kombinationen im Format Agent/Modell. Bei einem Wechsel von Terminal oder Ordner kann sich die Auswahl ändern. Vor dem Start prüft Open WebUI, ob gespeichertes Terminal und Agent noch verfügbar sind. Fehlt eines von beiden, schlägt der Lauf fehl und der Eigentümer kann das Ausführungsprotokoll prüfen. Dokumentation zu Open WebUI Automations

Der Zeitplaner startet einen Chat mit den gespeicherten Einstellungen. Eigene Illustration von Telli.sh auf Basis der Release-Hinweise zu Open WebUI v0.13.3.

Das Arbeitsverzeichnis beantwortet eine einfache Frage mit womöglich teuren Folgen. Welchen Checkout soll der Agent lesen, wenn zwei Projekte ähnliche Dateinamen haben oder dasselbe Projekt mit Feature- und Release-Branch auf dem Datenträger liegt? Ein ausdrücklicher Pfad lässt den Job am vorgesehenen Ort beginnen und gibt der prüfenden Person eine Referenz. Er bleibt ein Startverzeichnis. Lese- und Schreibrechte, erreichbare Dateien, Umgebungsvariablen, Netzwerkzugriff und Agentenverhalten bestimmen, was der Lauf außerdem erreichen kann.

Auch das Ziel der Ergebnisse ist festgelegt. Coding-Agent-Automatisierungen geben sie im Chat aus. Die Release-Hinweise unterscheiden sie von gewöhnlichen Modellautomatisierungen, die Kanäle als Ziel verwenden können. Verlauf und Chat reichen für den persönlichen Morgenbericht. Für eine gemeinsame Meldung muss das Team separat entscheiden, welche Informationen wohin gehen und wer die zugrunde liegenden Logs sieht. Auch ein fehlgeschlagener Job braucht eine verantwortliche Person, die weiß, wo sie nachsehen kann. Release-Hinweise zu Open WebUI v0.13.3

Der erste Job braucht kleine, prüfbare Eingaben

Beim Montagsbericht genügen Kopien der letzten nächtlichen Testzusammenfassung, eine automatisch erzeugte Commit-ID und wenige Fehlerlogs. Ein vorhandener CI-Artefaktexport oder eine manuelle Kopie in ein temporäres Verzeichnis liefert stabile Eingaben. Jede Datei braucht genug Kontext, um einen Fehler einem Job und einem Commit zuzuordnen. Entferne offensichtliche Geheimnisse und fremde Logs, bevor sie in den Ordner kommen. Ein vereinbarter Dateiname und ein prüfbarer Zeitstempel erleichtern die Arbeit, weil der Agent die neueste Fassung nicht erraten muss.

Bitte um drei Teile in einer Chatantwort. Der erste nennt die Fehler, die Aufmerksamkeit brauchen. Der zweite nennt Umgebungsfehler oder ungeklärte Fälle. Der dritte verweist für jeden Eintrag auf Quelle oder Pfad. Halte das Format kompakt, damit sich der Bericht mit der CI-Ansicht abgleichen lässt. Ein Job, der sechs identische Tickets anlegt, weil ein Test in sechs Matrixläufen auftaucht, macht aus einem kleinen Leseproblem ein größeres Prüfproblem.

Ein brauchbarer Prompt sagt, was die Ausgabe erhalten muss. Das folgende Beispiel nutzt Testdateien mit Commit-Angabe und exportierter Jobzusammenfassung. Verzeichnis und Dateien dienen als Beispiel.

Lies die exportierte Testzusammenfassung und die zugehörigen Fehlerauszüge im zugewiesenen Projektordner. Beginne mit Lauf-ID, Commit und Zeitstempel aus der Eingabe. Fasse wiederholte Fehler aus der Testmatrix zusammen. Nenne je eigenständigem Fehler den Testnamen, den kürzesten brauchbaren Auszug und den Quellpfad. Trenne ausdrücklich gemeldete Fehler von möglichen Ursachen. Fehlt die Zusammenfassung, ist sie veraltet oder unvollständig, benenne die fehlende Eingabe und stoppe. Lasse die Dateien unverändert.

Solche Anweisungen verringern Mehrdeutigkeit. Das Terminal braucht weiterhin passende Rechte. Liest der Job nur Dateien, gib ihm eine schreibgeschützte Ansicht oder eine temporäre Kopie ohne Zugangsdaten zum Repository. Ein fehlgeschlagener Test kann beliebigen Text aus einer Quelldatei, einer Drittanbieter-Abhängigkeit oder Testdaten ausgeben. Dieser Text gehört zu den Belegen. Er soll keine neue Anweisung für den Agenten werden. Das ist besonders wichtig, wenn der Job startet, bevor seine verantwortliche Person wach ist.

Dasselbe Verfahren kann einen zweiten wiederkehrenden Job unterstützen. Eine Entwicklungsleitung kann dem Agenten eine datierte Abhängigkeitsliste und eine separat beschaffte Liste von Sicherheitsmeldungen geben. Der Agent markiert mögliche Versionsübereinstimmungen und zitiert die passenden Einträge. Brauchbar ist eine Prüfliste mit Paket, Version und Quelle. Ein vertrauenswürdiger Scanner kann weiter deterministisch vergleichen, und ein Mensch beurteilt, ob der betroffene Codepfad erreichbar ist. Stabile Dateien machen den Bericht leichter reproduzierbar, wenn die Erklärung zwischen Läufen wechselt.

Die kurze Einrichtung zeigt, wo die Arbeit liegt

Open WebUI dokumentiert einen globalen Automations-Schalter und ein eigenes Recht für Personen ohne Adminrolle. Prüfe, ob die Instanz v0.13.3 oder eine spätere kompatible Version nutzt, die Funktion aktiv ist und das Konto Zugriff hat. Das Terminal muss verbunden und im Automationskontext erlaubt sein. Es kann im Modelleditor sichtbar und aufgrund seiner Konfiguration dennoch von automatischen Jobs ausgeschlossen sein. Das erklärt, warum ein Job im normalen Chat funktioniert und geplant scheitert. Open WebUI Automations · Dokumentation zur Anbindung von Open Terminal

1. Testdaten vorbereiten. Lege einen erfolgreichen Lauf, einen typischen Fehler und ein Manifest mit Commit und Zeitstempel in einem temporären Arbeitsbereich ab. Halte die Eingaben klein und Produktionsschlüssel, Cloud-Konfiguration und private Dateien außerhalb.
2. Automations öffnen und einen Job anlegen. Nutze Titel, Prompt, Modell und Zeitplan. Wähle im Editor ein Terminal, gib das Arbeitsverzeichnis ausdrücklich an und wähle den Agenten in der Modellauswahl. Warte kurz, bis die Umgebung die dort verfügbaren Agenten meldet.
3. Den Job einmal aus dem Editor starten. Öffne Chat und Ausführungslog. Prüfe Commit, Quelldateien, Zusammenfassung von Duplikaten und Dateirechte. Vergleiche das Ergebnis mit dem Original und prüfe, ob der Quellbaum sauber bleibt.
4. Einen Fehlerfall testen. Entferne das Manifest aus separaten Testdaten oder verwende absichtlich eine alte Eingabe. Der Bericht sollte den fehlenden Beleg sichtbar machen. Prüfe auch, ob ein für Automatisierungen nicht verfügbares Terminal als Fehler im Verlauf erscheint.
5. Zeitplan setzen und erste Ergebnisse prüfen. Vergleiche den Start mit dem Abschluss des CI-Exports. Ein Bericht, der zu früh startet und gestern liest, hat ein Zeitplanproblem, auch wenn sein Text aktuell klingt. Pausiere den Job, wenn sich die Eingaben ändern oder die Berichte abweichen.

Behandle Testdaten und Berichts-Prompt als Paar. Wird ein Ordner umbenannt, eine Branch-Konvention geändert oder ein Test in eine andere Suite verschoben, aktualisiere auch die Testdaten. So verliert der Job die Belege für die Gruppierung nicht unbemerkt. Ändert jemand den Prompt, sichere das bisherige Beispiel und vergleiche beide Ausgaben auf derselben Eingabe. Die günstigste Korrektur ist oft ein genaueres Eingabemanifest, besonders wenn zwei Jobs dieselbe Definition des jüngsten Laufs brauchen.

Die Terminalwahl bringt eine Berechtigungsgrenze mit

Eine selbst gehostete Chatoberfläche kann Modelle oder Agenten anderer Anbieter einbinden. Prüfe den Anbieter des gewählten Agenten, die übermittelten Daten und verfügbare Zugangsdaten. Ein Checkout im Container oder temporären Arbeitsbereich erlaubt es, den Auftrag einzuschränken. Das Startverzeichnis allein hilft wenig, wenn dasselbe Konto den übrigen Rechner lesen kann oder der Agent Schreibrechte am Repository hat. Die Terminaldokumentation beschreibt getrennte Einsatzkontexte, darunter Automatisierungen. Administratoren können den Zugriff vor dem ersten Lauf begrenzen. Dokumentation der Terminalanbindung

Ein schreibgeschützter Bericht trennt Belege, Ausführungsrechte und Prüfentscheidung. Eigene Illustration von Telli.sh.

Gespart wird die Zeit zwischen dem Öffnen der Ergebnisse und dem Wissen, wo man nachsehen muss. Ein verlässlicher Befehl kann viel Vorarbeit leisten. Lass ihn Lauf-ID und Status liefern und den Agenten Fehler aus verschiedenen Ausgaben erklären. Die Teilung hilft bei Störungen. Vergleiche die gemeldete ID mit dem Manifest. So erkennst du falsche Eingaben, bevor du einen anderen Agenten ausprobierst.

Auch Kosten gehören dazu. Geplante Läufe können abrechenbare Nutzung verursachen, wenn der Agent ein kostenpflichtiges Modell aufruft. Lange Logs erhöhen die Eingabemenge, und wiederholte Testfehler können zu wiederholten Analysen führen. Miss zuerst, wie viel Prüfwert ein begrenzter Logauszug bei wenigen Läufen liefert. Verarbeitet jeder Lauf dieselben großen Dateien, lass einen günstigen deterministischen Schritt feststellen, ob sich etwas geändert hat. Ein täglicher Zeitplan ist kalkulierbar, wenn die Eingabemenge je Lauf begrenzt ist.

Für kleine Teams ist die Zuständigkeit so wichtig wie das Terminal. Laut Dokumentation gehört eine Automatisierung der Person, die sie angelegt hat, und ist nur für sie sichtbar. Ein persönlicher Bericht kann dort bleiben. Eine gemeinsame Release-Freigabe braucht einen sichtbaren Weg, Belege zu teilen und Verantwortung bei Abwesenheit weiterzugeben. Der Automationsverlauf hilft einer Person bei der Fehlersuche. Eine gemeinsame CI-Prüfung hält die Build-Entscheidung für das ausliefernde Team sichtbar. Zugriffsregeln für Open WebUI Automations

Ob sich der Morgenbericht lohnt, zeigt die Prüfung

Sieh nach der ersten Woche nach, welche Berichte tatsächlich geöffnet wurden. Prüfe Link oder Auszug zu jedem dringenden Punkt. Zähle Fälle, in denen die Zusammenfassung einen Fehler übersah, einen bekannten wiederholte oder den falschen Commit nannte. Frage die prüfende Person, ob der Bericht ihr half, den nächsten Test zu finden. Das sagt mehr über den Wert des Zeitplans als die Zahl automatischer Antworten.

Bleibt die Ausgabe brauchbar, kannst du jeweils eine Datei mit einer neuen Belegart hinzufügen. Gib dem Terminal einen festen Arbeitsort, halte die Zugangsdaten des Jobs eng begrenzt und lasse Änderungen an Code und Infrastruktur durch die gewohnte Teamprüfung laufen. Ein guter Morgenbericht ist verlässlich genug, um danach zu handeln, und schnell überprüfbar, wenn etwas nicht stimmt.

Quellen

• Release-Hinweise zu Open WebUI v0.13.3
• Einrichtung, Rechte und Ausführungsverlauf von Open WebUI Automations
• Open WebUI Terminalanbindung und Kontexte

---

Um Gespräche und Entscheidungen hinter deiner Arbeit durchsuchbar festzuhalten, erstelle ein Telli.sh-Konto.