Conduit: ein Flutter-Client, der Open WebUI auf das Handy bringt

Das Problem liegt am Rand der mobilen Nutzung, nicht im Chat selbst

Das README benennt die Ausgangslage ungewöhnlich konkret: Open WebUI funktioniere am Desktop gut, breche auf dem Handy aber an den Rändern. Genannt werden Authentifizierung hinter einem Reverse Proxy, Streaming, das abbricht, wenn die App in den Hintergrund wandert, der Weg eines Screenshots in einen Prompt und der Start eines Chats vom Home-Bildschirm. Das sind keine Modellprobleme. Es sind Probleme der mobilen Laufzeit, der Sitzungsverwaltung und der Art, wie eine Web-Oberfläche in einem mobilen Browser altert. Die Zielgruppe sind entsprechend nicht Neugierige, die zum ersten Mal mit einem LLM sprechen wollen, sondern Betreiber einer eigenen Instanz. Wer Open WebUI, Ollama oder einen Agenten bereits laufen hat, bekommt hier einen Client, der auf diese Umgebung zugeschnitten ist. Seit Version 4.0 funktioniert die App laut README auch ohne Open-WebUI-Server, was den Kreis auf alle erweitert, die direkt gegen einen Anbieter oder ein lokales Modell sprechen wollen.

Vier Verbindungswege mit sehr unterschiedlichen Fähigkeiten

Beim ersten Start fragt Conduit, wie verbunden werden soll. Der Open-WebUI-Weg liefert den vollen Funktionsumfang: Chats, Ordner, Notizen, Channels, Workspace, Tools, Websuche und Bildgenerierung. Der Direct-Weg spricht OpenAI-kompatible Endpunkte über Chat Completions oder Responses an, dazu LM Studio, Azure-artige API-Versionen, natives Ollama und OpenRouter. Ein API-Schlüssel ist optional, für ein lokales Endpunkt ohne Authentifizierung kann er entfallen. Direct-Verbindungen, die bereits in Open WebUI konfiguriert waren, werden laut README automatisch übernommen; Schlüssel und eigene Header bleiben im sicheren Speicher der Plattform. Dazu kommen zwei Apple-Wege und der Hermes-Agent. Diese Aufteilung ist die eigentliche Designentscheidung: Die App tut nicht so, als wären alle Backends gleich. Sie unterscheidet zwischen einem Server, der Ordner, Notizen und Workspace kennt, und einem reinen Modellendpunkt, der nur Nachrichten austauscht. Wer die App testet, sollte mit dem Direct-Weg gegen ein lokales Ollama beginnen, weil dort am wenigsten Serverlogik dazwischenliegt.

Die Apple-Modelle sind bewusst eingeschränkt

Apple On-Device nutzt SystemLanguageModel, ist auf iOS beschränkt, verlangt iOS 26 und Apple Intelligence und arbeitet offline. Unterstützt werden Streaming, Sampling-Parameter und JSON-Schema-Antworten bei einem Kontextfenster von 4K. Bildinput, Reasoning-Steuerung und Tool-Calling fehlen. Apple Private Cloud Compute geht über das Foundation Models-Framework, verlangt iOS 27, verfügbarkeit von Apple Intelligence und eine verwaltete PCC-Berechtigung. Dort sind Bildinput, Reasoning-Stufen, Sampling, Ausgabelimits, JSON-Schema-Antworten, Live-Anzeige von Kontingent und Kontext sowie ein optionaler On-Device-Rückfall bei Netzfehlern vorgesehen. Tool-Calling ist auch hier nicht aktiviert. 4K Kontext ist für längere Code-Diskussionen knapp, und der fehlende Werkzeugaufruf schließt die Apple-Wege für agentische Abläufe aus. Das README sagt das offen, statt die Einschränkungen in einer Funktionsliste zu verstecken. Wer heute einen Agenten mit Werkzeugen braucht, ist auf dieser Route falsch.

Streaming über WebSocket und lokal gehaltene Chats

Das README beschreibt Token-für-Token-Streaming über WebSocket. Der Transkriptbereich halte seine Position, während eine Antwort wächst, angeheftete Prompts blieben stehen, und lange Konversationen ließen sich laden, ohne die Oberfläche zu blockieren. Das ist die technische Antwort auf das eingangs genannte Problem: Ein Web-Client im mobilen Browser verliert bei einem Verbindungsabbruch den sichtbaren Zustand, eine native App kann ihn rekonstruieren. Die Aussage, dass Chats zuerst auf dem Gerät liegen und nichts über einen vom Maintainer betriebenen Backend-Server läuft, ist der zweite Teil dieser Architektur. Sie bedeutet nicht, dass keine Daten das Gerät verlassen: Bei einer Open-WebUI-, Ollama- oder OpenAI-Verbindung gehen die Anfragen selbstverständlich an den jeweiligen Endpunkt. Sie bedeutet, dass zwischen App und Endpunkt kein zusätzlicher Dienst des Projekts geschaltet ist. Für Betreiber, die ihre Instanz hinter einem Reverse Proxy mit eigener Authentifizierung betreiben, ist genau das der relevante Unterschied.

Rendering jenseits von Markdown, und die Workspace-Frage

Die Oberfläche ist natives Flutter, kein Web-View in einer Hülle. Das README listet syntaxhervorgehobene Codeblöcke mit Kopieren und Vorschau, nativ gerenderte Mermaid-Diagramme, LaTeX und Mathematik, aufklappbare Abschnitte für Reasoning, Werkzeugaufrufe und Code-Ausführung, Inline-Zitate mit Quellkarten und Folgevorschlägen sowie Chart.js-Einbettungen. Das ist mehr, als die meisten mobilen Chat-Clients leisten, und es erklärt, warum das Projekt in Dart geschrieben ist statt als dünne Hülle um eine Web-Oberfläche. Der Workspace bildet Modelle, Wissen, Prompts, Tools und Skills als native Bildschirme ab, mit gemeinsamer Einstellungsnavigation. Wichtig ist der Nachsatz: Bereiche, für die keine Berechtigung besteht, erscheinen einfach nicht. Das klingt nach guter Nutzerführung, ist aber auch ein Diagnoseproblem. Fehlt eine Funktion, kann die Ursache in der eigenen Serverkonfiguration, in einer älteren Open-WebUI-Version oder in den Rollen des Kontos liegen. Die App zeigt nicht, was sie verschweigt.

Was das README nicht beantwortet

Zu Installation und Selbstbau verweist das README auf docs/BUILDING.md, ohne die Schritte im Text zu wiederholen. Konkrete Kommandos wie flutter build oder Angaben zu Signierung, Flavors und Zielplattformen stehen damit nicht in dem Material, das hier vorliegt. Auch zu den Lizenzfolgen sagt das Repository nur GPL-3.0. Wer die App unverändert aus dem App Store oder von Google Play bezieht, berührt damit in der Regel keine Verbreitungspflichten. Wer dagegen einen Fork erstellt, ihn im Unternehmen verteilt oder im Store veröffentlicht, muss die GPL-3.0-Bedingungen selbst prüfen; das ist keine Rechtsberatung, sondern der Hinweis, dass die Lizenz hier nicht permissiv ist. Nicht belegt ist ebenfalls, wie sich die App gegen ältere Open-WebUI-Versionen verhält, wie groß der Wartungsaufwand bei einem eigenen Fork wäre und ob die Store-Versionen und die Quellversion funktional identisch sind. Wer auf Reproduzierbarkeit angewiesen ist, sollte das vor einer Entscheidung klären.

Hermes als Gegenmodell zum reinen Chat

Der Hermes-Agent verbindet sich mit einem eigenen Hermes-Server. Man sieht Werkzeuge live arbeiten, bestätigt heikle Schritte vor der Ausführung und lässt geplante Agenten laufen. Konversationen und Zeitpläne bekommen einen eigenen Tab, und Conduit zeigt laut README nur die Fähigkeiten, die der Server tatsächlich meldet. Das ist die zweite Stelle, an der die App eine Grenze zieht statt sie zu überspielen. Ein Agent, der Werkzeuge ausführt, braucht eine Bestätigungsschicht, und die ist hier Teil der Oberfläche. Wer stattdessen einen Chat-Client sucht, der nur Nachrichten hin und her schickt, wird von diesem Tab nichts vermissen. Wer einen Agenten ohne Genehmigungsschritt betreiben will, findet hier nicht die passende Lösung.

Wann ein Web-Client die bessere Wahl bleibt

Die naheliegende Alternative ist die Open-WebUI-Weboberfläche selbst, im mobilen Browser oder als installierte Web-App. Der Unterschied liegt nicht in den Modellen, sondern in der Schicht darüber: Der Web-Client braucht keine Store-Installation, keine zweite Codebasis und keinen eigenen Build, wenn die eigene Instanz angepasst wurde. Er läuft überall dort, wo ein Browser läuft. Dafür bezahlt man mit den Problemen, die das README eingangs nennt: Sitzungen hinter einem Reverse Proxy, Streaming, das beim Wechsel in eine andere App abbricht, und ein Datei- und Kamera-Zugriff, der von den Browserrichtlinien abhängt. Conduit tauscht diesen Aufwand gegen eine Flutter-Anwendung, die pro Plattform gebaut und aktualisiert werden muss. Für eine Einzelperson mit einer kleinen Instanz ist der Web-Client oft ausreichend. Für alle, die täglich vom Handy aus mit einem eigenen Server arbeiten, ist der native Client die plausiblere Wahl.

Redaktionelles Fazit

Conduit passt zu Teams und Einzelpersonen, die bereits eine Open WebUI-Instanz oder einen eigenen Ollama- beziehungsweise OpenAI-kompatiblen Endpunkt betreiben und dafür einen nativen Mobile-Client wollen, der die Chats lokal hält. Wer einen reinen Web-Client sucht, der ohne Store-Installation auskommt, oder wer auf Tool-Calling über Apple-Modelle angewiesen ist, sollte bei der Web-Oberfläche bleiben. Vor dem Ausrollen im Team ist zu prüfen, ob die eigene Open-WebUI-Version die in Conduit sichtbaren Bereiche wie Channels, Tools und Workspace tatsächlich meldet, denn die App blendet laut README nur ein, was der Server berichtet.

Offizielle Quellen

1. cogwheel0/conduit on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases