20. Juli 2026
Mingly in Production: Multi-LLM-Routing in der Desktop-App — was 3 Monate Betrieb gelehrt haben
Wir haben Mingly, unsere Multi-LLM-Desktop-App, vor drei Monaten in Production gebracht. Hier sind die ehrlichsten Erkenntnisse aus dem Betrieb.
Vor gut drei Monaten haben wir die erste produktive Version von Mingly ausgeliefert — unserer Desktop-App für Multi-LLM-Workflows. Das Problem, das Mingly löst, ist konkret: Wissensarbeiter wechseln täglich zwischen vier oder fünf KI-Oberflächen. ChatGPT für Textentwürfe, Claude für Analysen, ein lokales Modell für vertrauliche Inhalte, Perplexity für Recherche. Mingly fasst das in einer einzigen nativen Desktop-Anwendung zusammen — mit einem Router, der automatisch das richtige Modell für jede Aufgabe wählt. Dieser Artikel ist unsere ehrlichste Retrospektive auf drei Monate Betrieb.
Warum Electron und nicht eine Web-App?
Drei Entscheidungen haben uns zu Electron geführt. Erstens: lokale Modelle. Wir wollten Ollama als Sidecar-Prozess mitliefern — das ist im Browser nicht möglich. Mingly startet Ollama automatisch beim Launch und kommuniziert über die lokale API auf Port 11434. Der Nutzer installiert keine externe Software; er öffnet die App. Zweitens: nativer Dateizugriff. Per Drag-and-Drop landen PDFs, Word-Dokumente und Code-Dateien direkt im Chat — ohne Upload-Formular, ohne Dateigrössen-Limits der Browser-API. Drittens: Tray-Integration und globale Tastenkürzel. Mingly sitzt in der Menubar und ist mit einem Kürzel aus jeder anderen Anwendung heraus aufrufbar. Modernes Electron bringt WebGPU out-of-the-box, was lokale Inferenz auf Apple-Silicon-Macs mit 20 bis 35 Tokens pro Sekunde ermöglicht — ohne externe Abhängigkeiten jenseits von Ollama.
Das Routing-Problem: Nicht jede Anfrage braucht das teuerste Modell.
Eine einfache E-Mail-Betreffzeile braucht kein Claude Opus oder o3. Llama 3 8B schafft das mit vergleichbarer Qualität für einen Bruchteil der Kosten. Wenn Nutzer täglich Dutzende Anfragen stellen, summieren sich die Preisunterschiede schnell. Dass Multi-Modell-Routing inzwischen Standard ist, belegen aktuelle Zahlen: 78% der Entwicklungsteams in Production nutzen heute mindestens zwei LLM-Familien parallel; der Anteil mit drei oder mehr Familien stieg innerhalb von drei Monaten von 36% auf 59% (Ash Dubai, «Multi-provider LLM orchestration in production: A 2026 Guide», dev.to, 2026). Der Druck, Routing einzuführen, kommt nicht aus Interesse an Architektur-Eleganz — er kommt aus der Kostenstelle.
Wie Mingys Router Anfragen verteilt.
Mingly klassifiziert jede Anfrage in eine von vier Task-Kategorien, bevor sie ein Modell sieht: - Quick — Ein-Satz-Antworten, einfache Transformationen: Llama 3 8B (lokal) oder Mistral Small - Standard — Textentwürfe, Zusammenfassungen, strukturierte Extraktion: Claude Haiku oder GPT-4o Mini - Deep — Mehrstufige Analysen, langer Kontext, Code-Erklärungen: Claude Sonnet oder GPT-4o - Expert — Code-Refactoring über mehrere Dateien, komplexe Schlussfolgerungsketten: Claude Opus oder o3 Die Klassifikation läuft regel-basiert: Keyword-Matching kombiniert mit der Länge des Kontextfensters. Regel-basiertes Routing kostet unter 1 Millisekunde Overhead — embedding-basierte Klassifikation wäre etwas genauer, aber die 5ms zusätzliche Latenz rechtfertigen sich in unserem Szenario nicht (Akshay Ghalme, «Multi-Model Routing — The AI Gateway Pattern That Cuts LLM Bills 40-70%», akshayghalme.com, 2026). Bei Modell-Ausfall greift eine dreistufige Fallback-Kette: primäres Remote-Modell → alternatives Remote-Modell → lokales Ollama-Modell.
Fallback-Kette: wenn eine API nicht antwortet.
Der Nutzer sieht eine Hinweiszeile im Chat-Header — «Verwendet lokales Modell — API nicht erreichbar» — aber der Workflow bricht nie einfach ab. Das klingt einfach und ist es im Kern auch. Der Aufwand steckt im Testen: Wir simulieren API-Ausfälle in unserer Test-Suite mit Prüfstand, unserem eigenen Eval-Framework, um sicherzustellen, dass Fallback-Modelle die richtige Qualität liefern. Ein Fallback, der stilistisch oder inhaltlich weit vom primären Modell abweicht, ist schlimmer als eine ehrliche Fehlermeldung — er erzeugt stille Fehler, die der Nutzer erst Stunden später bemerkt.
Was drei Monate Production gelehrt haben: Zwei Überraschungen.
Erste Überraschung: Nutzer merken den Modellwechsel häufiger als erwartet. Wir hatten Routing ursprünglich vollständig im Hintergrund versteckt. Das war ein Fehler. Wenn Mingly für eine Aufgabe ein günstigeres Modell wählt und die Antwortqualität merklich schlechter ist, verlieren Nutzer das Vertrauen in die App — nicht ins Modell. Seit Version 0.4 zeigen wir im Chat-Header immer das aktive Modell. Das Feedback war sofort positiv: Nutzer fühlen sich informiert statt manipuliert. Zweite Überraschung: Lokale Modelle sind kein Notfallplan — sie sind ein Feature. Wir hatten Ollama ursprünglich nur als Offline-Reserve konzipiert. Tatsächlich nutzen 34% unserer aktiven Nutzer das lokale Modell als primären Kanal — wegen Datenschutz, nicht wegen Kosten. Besonders bei Anwälten und HR-Teams ist der lokale Betrieb der entscheidende Kaufgrund.
Das Cascade-Muster funktioniert — aber Schwellen brauchen Kalibrierung.
Das Prinzip: günstiges Modell zuerst, teures Modell nur wenn nötig. In der Theorie spart das 40 bis 70% der Inferenzkosten. In der Praxis haben wir drei Wochen gebraucht, um die Schwellen für unsere konkreten Use Cases richtig einzustellen. Ein zu tiefer Schwellwert schickt zu viele Anfragen ans teure Modell und spart wenig. Ein zu hoher liefert häufig schwache Ergebnisse und frustriert Nutzer. Die Kalibrierung geht nur mit Daten: Wir loggen für jede Anfrage Task-Kategorie, gewähltes Modell, Latenz, Token-Count und Nutzerfeedback (Daumen hoch/runter). Ohne dieses Logging hätten wir nie gewusst, dass 34% der Nutzer das lokale Modell bevorzugen — und hätten weiter in Remote-Kapazität investiert, wo Datenschutz-Infrastruktur gefragt war.
Was das für andere Teams bedeutet.
Multi-LLM-Routing ist 2026 kein Experiment mehr — es ist Standard in produktiven KI-Anwendungen. Unsere Empfehlungen aus drei Monaten Betrieb: - Fang regel-basiert an. Bevor du einen ML-Classifier baust, probiere Keyword-Matching und Kontextlänge als Routing-Signal. Das trägt 80% der Anwendungsfälle. - Mach Modell-Transparenz zur Pflicht. Zeige dem Nutzer immer, welches Modell aktiv ist. Verstecktes Routing erzeugt Misstrauen. - Frag deine Nutzer explizit nach Datenschutz-Anforderungen. Der Anteil, für den lokale Modelle keine Option, sondern Bedingung sind, wird dich überraschen. - Investiere früh in Observability. Routing-Schwellen ohne Daten zu kalibrieren ist Raterei. Mingly erscheint im Herbst 2026 als öffentliche Beta. Wer die frühe Version testen oder Feedback einbringen möchte: Meldung über digital-opua.ch/kontakt.
Quellen
Ash Dubai: «Multi-provider LLM orchestration in production: A 2026 Guide», dev.to, 2026 — https://dev.to/ash_dubai/multi-provider-llm-orchestration-in-production-a-2026-guide-1g10 · Akshay Ghalme: «Multi-Model Routing — The AI Gateway Pattern That Cuts LLM Bills 40-70%», akshayghalme.com, 2026 — https://akshayghalme.com/blogs/multi-model-routing-ai-gateway-pattern/