OpenWebUI Auto-Routing-Pipe mit AWS Bedrock selbst bauen

Warum manuelles Modell-Switching teuer und ineffizient ist

Wer KI intern produktiv einsetzen will, steht schnell vor einem Problem: Man hat plötzlich einen wilden Zoo aus Modellen. Einfache Modelle für kurze Antworten, leistungsstarke Reasoner für komplexe Fragen, Vision-Modelle für Bilder. Das manuelle Hin- und Herschalten nervt nicht nur – es kostet auch richtig Geld, wenn simple Prompts unnötig über teure Modelle laufen.

Unsere Lösung: Wir haben eine Auto-Routing-Pipe für OpenWebUI gebaut, die jeden Prompt erst klassifiziert und dann gezielt an das passende Modell schickt. Das Ergebnis? Die Nutzererfahrung wird spürbar besser, weil nichts mehr manuell ausgewählt werden muss. Und gleichzeitig bleiben die Kosten transparent und kontrollierbar.

Der komplette Quellcode liegt in unserem GitHub-Repository. Das Skript funktioniert sowohl als OpenWebUI-Pipe als auch als lokales CLI-Tool zum Testen. Bei eggs unimedia betreiben wir OpenWebUI seit Monaten als interne AI-Plattform und haben dabei gelernt: Intelligentes Routing ist einer der wirksamsten Hebel für Effizienz.

Technisch setzen wir für die Klassifizierung auf Amazon Nova Micro über AWS Bedrock. Das Modell ist extrem günstig im Vergleich zu den "großen" Modellen, aber trotzdem schnell und stabil. Die Pipe entscheidet damit, ob ein Prompt an ein kompaktes Modell geht oder ob GPT-4o, Claude oder Pixtral ran müssen – und das nur, wenn es wirklich nötig ist. Das entlastet die Premium-Modelle, spart Tokens und sorgt trotzdem für hochwertige Antworten.

false

In diesem Tutorial bauen wir die Pipe von Grund auf: Wir skizzieren die Architektur, erklären die OpenWebUI-"Plugin"-Struktur (Filter, Pipes, Valves), führen Schritt für Schritt durch das Routing-Mapping und testen erst lokal gegen Bedrock, bevor wir die Funktion ins UI bringen. Ziel ist, dass man das Ganze nachvollziehen, erweitern und an die konkreten Bedürfnisse anpassen kann.

Hintergrund: OpenWebUI als interne AI-Plattform – warum wir darauf setzen

OpenWebUI ist für uns die ideale Basis geworden. Die Plattform ist self-hosted, wahrt Datenschutz und Compliance und integriert trotzdem Modelle verschiedener Anbieter – OpenAI, Anthropic, Mistral, you name it. So haben wir eine breite Auswahl für unterschiedliche Einsatzzwecke, ohne bei jedem Anbieter extra Accounts zu brauchen. Einen tieferen Überblick über die Grundarchitekturen haben wir bereits in einem eigenen Artikel veröffentlicht.

Was uns besonders überzeugt: die Erweiterbarkeit durch Filter und Pipes. Über die Admin-Oberfläche lassen sich diese zwei Arten von Functions hinzufügen. Filter wirken als Hooks vor und nach dem LLM-Aufruf – sie können eingehende Nachrichten transformieren oder ausgehende Antworten nachbearbeiten und werden einem Modell bzw. einer Pipe vorgeschaltet. Pipes sind dagegen "eigene Modelle" mit eigener Logik: Sie erscheinen im Model-Selector und können externe Services/LLMs ansteuern – in unserem Fall übernimmt die Pipe das komplette Routing.

Über sogenannte Valves sind Pipes zudem konfigurierbar, etwa um die Standard-Modelle für bestimmte Kategorien zu setzen oder die ID des Klassifizierers zu ändern. Das ist praktisch: Wir können Modelle tauschen, Kategorien erweitern oder Features ein-/ausschalten, ohne die Pipe neu zu packen oder Code zu deployen.

Für uns verbindet OpenWebUI das Beste aus zwei Welten: Benutzerfreundlichkeit (jeder kann direkt mit Modellen arbeiten) mit technischer Kontrolle (wir können Integrationen, Zugriffsrechte und Sicherheitsstandards zentral verwalten). Das macht OpenWebUI zu einem leistungsfähigen Hub, auf dem wir eigene Erweiterungen wie die Auto-Routing-Pipe nahtlos andocken können.

AWS Bedrock & Nova Micro – unser Setup erklärt

Während OpenWebUI die Oberfläche und die Orchestrierung übernimmt, brauchen wir im Hintergrund einen Dienst, der zuverlässig mit unterschiedlichen Modellen sprechen kann. Genau hier setzt AWS Bedrock an: Als Managed Service abstrahiert Bedrock die Modell-APIs verschiedener Hersteller und bietet eine einheitliche REST-Schnittstelle.

Das bringt uns gleich mehrere Vorteile – einheitliches Billing, zentrale Rechteverwaltung über IAM und keinen Wildwuchs an API-Keys. Statt jedes Modell einzeln anzubinden, haben wir Bedrock einmal in die Infrastruktur integriert und können über die Runtime API alle verfügbaren Modelle ansprechen.

Ein Highlight von Bedrock ist für uns die Amazon Nova-Familie. Nova ist Amazons eigene Modellreihe und deckt verschiedene Leistungsklassen ab – von Micro über Lite bis Pro. Für unsere Auto-Routing-Pipe nutzen wir bewusst Nova Micro: ein Modell, das auf hohe Geschwindigkeit und extrem niedrige Kosten optimiert ist. Es eignet sich hervorragend für Klassifizierungsaufgaben, bei denen es nicht um lange, kreative Antworten geht, sondern um präzise Entscheidungen: "Ist dieser Prompt Coding oder Content?"

Der Clou: Durch die vorgeschaltete Klassifizierung mit Nova Micro laufen nur die Prompts auf ein großes Modell durch, die es wirklich brauchen. Für einfache Fragen reicht ein kleineres Modell, für komplexe Analysen wird gezielt GPT-4o oder Claude aktiviert. Dieses Muster ist nicht nur technisch elegant, sondern spart auch bares Geld: Klassifizierung kostet etwa ein Tausendstel von dem, was eine Generation mit einem Premium-Modell verbrauchen würde.

Architektur unserer Auto-Routing-Pipe

Unsere Auto-Routing-Pipe besteht aus drei zentralen Bausteinen, die klar voneinander getrennt sind:

1. Der Router verwaltet Kategorien und ordnet ihnen jeweils ein Zielmodell zu. Beispiele sind "default" für Alltagsfragen, "coding" für technische Prompts, "deep-reasoning" für komplexe Aufgaben oder "vision" für bildbasierte Anfragen.

2. Die Klassifizierung wird von Nova Micro übernommen. Das Modell erhält einen kompakten Systemprompt, in dem alle Kategorien mit kurzer Beschreibung aufgelistet sind, und liefert anschließend genau eine Kategorie zurück.

3. Die Ausführung hängt vom Modus ab. In OpenWebUI wird die Pipe eingebunden und entscheidet, wohin der Prompt geleitet wird. Im CLI-Testmodus können wir denselben Ablauf lokal mit Bedrock durchspielen, um Logik und Fehlerszenarien zu prüfen.

Mit dieser Trennung aus schneller Klassifizierung und gezielter Generierung steht das Funktionsprinzip. Jetzt sorgen wir dafür, dass es auch in der Praxis trägt: Wir richten das Projekt ein, konfigurieren Bedrock (Region, Berechtigungen, Modell-IDs), wählen kostenbewusste Defaults und testen die Pipe lokal, bevor sie ins OpenWebUI wandert.

Schritt 1: Projektgrundlage & Abhängigkeiten einrichten

Bevor wir mit der eigentlichen Logik starten, richten wir eine schlanke lokale Umgebung ein. So können wir das Routing erst im CLI testen und sicherstellen, dass Klassifizierung und Mapping wie gewünscht funktionieren – erst danach heben wir die Pipe ins UI.

Wir arbeiten mit Python ab Version 3.10 und nutzen am besten ein frisches virtuelles Environment. Für den lokalen Zugriff auf Bedrock installieren wir boto3: pip install boto3. Das SDK übernimmt die HTTP-Requests an die Bedrock Runtime API. Die Authentifizierung läuft über Umgebungsvariablen: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY und AWS_REGION (bei uns eu-central-1). Die CLI nutzt damit direkt den Bedrock-Runtime-Endpunkt.

Für die Klassifizierung setzen wir auf Nova Micro. Im CLI wird standardmäßig die Modell-ID eu.amazon.nova-micro-v1:0 verwendet. Es ist wichtig, dass die gewählte ID zur Region passt, sonst schlägt der Aufruf fehl – das ist erfahrungsgemäß eine der häufigsten Fehlerquellen beim ersten Test.

In OpenWebUI selbst brauchen wir an dieser Stelle noch keine Konfiguration vorzunehmen. Später werden wir die Pipe über das Admin-Menü hochladen (Functions → New) und die zugehörigen Valves wie CLASSIFIER_MODEL_ID oder die Zielmodelle einrichten.

Wenn diese Grundlagen stehen, können wir im nächsten Schritt die Kategorien definieren und das kostenbewusste Mapping im Router anlegen – das eigentliche Herzstück des Auto-Routings.

Schritt 2: Router bauen – Kategorien & Mapping

Hier wird's konkret: Der Router ist das Herzstück der Pipe. Hier legen wir fest, welche Kategorien es gibt und auf welches Modell sie jeweils zeigen. Die Kategorien bilden die "Logik" des Routings – ohne sie wüsste Nova Micro zwar, dass etwas klassifiziert werden soll, aber nicht, welche Zielmodelle dafür zur Verfügung stehen.

Unser Start-Setup umfasst sechs Kategorien:

• default – für einfache Alltagsfragen

• coding – für technische Prompts

• deep-reasoning – für komplexe Aufgaben

• structured-analysis – für längere, strukturierte Texte

• content-generation – für kreative oder geschäftliche Inhalte

• vision – für Prompts mit Bildbezug

Jede Kategorie ist mit einer kurzen Beschreibung versehen, die Nova Micro im System-Prompt erhält. Damit wird das Modell in die Lage versetzt, Prompts verlässlich einzuordnen:

self.categories = {
    "default": {
        "model": "azure.gpt-4o-mini",
        "description": "For everyday, relatively simple requests with short to medium "
                       "length (1–3 paragraphs). Covers small talk, short explanations, "
                       "summaries, or general questions that do not require deep reasoning."
    },
    "coding": {
        "model": "eu.anthropic.claude-sonnet-4",
        "description": "For technical requests related to programming, debugging, "
                       "architecture, or IT tools. Includes code snippets, error messages, "
                       "and in-depth technical explanations."
    },
    "deep-reasoning": {
        "model": "azure.gpt-4o",
        "description": "For complex analytical tasks requiring multi-step reasoning, "
                       "strategic analysis, or detailed problem-solving approaches."
    },
    # [...] and so on
}

Dieses Mapping ist flexibel erweiterbar: Wenn im Unternehmen neue Anwendungsfälle hinzukommen – etwa Übersetzungen oder domänenspezifische Analysen – lassen sich zusätzliche Kategorien ergänzen und auf passende Modelle routen. Die Beschreibungen sollten dabei präzise, aber nicht zu detailliert sein – Nova Micro soll schnell entscheiden können, nicht über Grenzfälle grübeln.

Schritt 3: Klassifizierungs-Prompt für Nova Micro

Damit Nova Micro zuverlässig arbeitet, brauchen wir einen straffen System-Prompt. Wir formulieren ihn auf Englisch, damit er zu den üblichen Modell-Erwartungen passt:

system = (
    "You are a strict classification assistant. "
    "Choose EXACTLY ONE category from the allowed list. "
    "Return ONLY the category token in lowercase...\n\n"
    f"Valid categories: {valid_labels}\n\n"
    f"Categories:\n{descriptions}"
)

Der Prompt ist bewusst strikt gehalten: "EXACTLY ONE category", "ONLY the category token". Das minimiert das Risiko, dass Nova Micro zusätzliche Erklärungen oder mehrere Kategorien zurückgibt.

Für die Weiterverarbeitung führen wir ein kurzes Post-Processing durch: Wir nehmen die erste nicht-leere Zeile der Modellantwort, trimmen Leerzeichen und normalisieren die Schreibweise (z. B. in Kleinbuchstaben). So erhalten wir einen stabilen Kategorienamen, den der Router direkt gegen die erlaubten Kategorien prüft.

Schritt 4: Laufzeit-Erkennung – OpenWebUI vs. lokal

Clever gelöst: Als Nächstes stellen wir sicher, dass wir die Pipe lokal testen können, ohne eine zweite Codebasis zu pflegen. Wir halten den Code bewusst einheitlich: dieselbe Datei läuft als Pipe in OpenWebUI und als CLI-Tool lokal.

Zur Laufzeit prüfen wir per Import-Erkennung, ob OpenWebUI-Bibliotheken verfügbar sind, und setzen ein Flag (zum Beispiel OPENWEBUI). Ist das Flag gesetzt, verwenden wir die internen OpenWebUI-Hooks (etwa generate_chat_completion); andernfalls nutzen wir lokal die Bedrock Runtime API:

try:  # OpenWebUI runtime
    from open_webui.utils.chat import generate_chat_completion
    # [...] (further imports)
    OPENWEBUI = True
except ImportError:  # Local CLI runtime
    import boto3
    OPENWEBUI = False

Das hat zwei klare Vorteile: Erstens testen wir die komplette Routinglogik vor dem UI-Rollout – schnell und ohne Risiko für Nutzer:innen. Zweitens vermeiden wir doppelte Implementierungen. Das bedeutet: Wir debuggen Prompts, Kategorien und Modell-IDs erst im CLI, und wenn alles stabil ist, aktivieren wir die Pipe im Adminbereich von OpenWebUI.

Schritt 5: CLI-Testing – das Routing durchprobieren

Bevor wir ins UI gehen, verifizieren wir das Routing lokal. Ziel ist ein schneller Check, ob Klassifizierung und Mapping zusammenspielen: Wir starten das Skript im CLI, geben ein paar typische Prompts ein und prüfen, ob die erwarteten Kategorien und Zielmodelle ausgegeben werden.

Beispiele für unseren Test:

• "Bitte debugge diesen Python-Fehler" → sollte "coding" werden

• "Fasse drei Bulletpoints in zwei Sätzen zusammen" → sollte "default" werden

• "Analysiere diese Architekturidee in verschiedenen Varianten" → sollte "deep-reasoning" werden

Für reproduzierbare Ergebnisse setzen wir beim Klassifizierer enge Parameter (temperature = 0.0, maxTokens ≈ 5). Das hält die Antwort strikt beim Kategorienamen und vermeidet unnötige Rechenzeit.

Wir achten beim Test auf drei Dinge: Erstens, ob jede Hauptkategorie mindestens einmal sauber getroffen wird; zweitens, ob Randfälle (kurze Code-/Textmischungen) sinnvoll zugeordnet werden; drittens, ob die Latenz im erwartbaren Rahmen bleibt (Nova Micro sollte unter einer Sekunde antworten).

Häufige Stolperfallen sind schnell behoben: Region und Modell-ID müssen zusammenpassen (Nova Micro zur gewählten AWS-Region), und die Antwort kann Zeilenumbrüche oder Whitespace enthalten, die wir in der Auswertung kurz normalisieren. Wenn diese Checks passen, ist die Logik stabil genug für die Integration in OpenWebUI.

Schritt 6: OpenWebUI-Pipe implementieren (inkl. Valves)

Jetzt integrieren wir die getestete Logik als Pipe in OpenWebUI. Eine Pipe ist die Laufzeitkomponente, die zwischen Eingabe und Modell sitzt: Sie nimmt die letzte User-Message entgegen, ruft erst den Klassifizierer auf und setzt danach das Zielmodell, bevor die eigentliche Antwort generiert wird. Über die Methode pipes() meldet sich die Klasse mit einer ID und einem Anzeigenamen an; danach erscheint sie im Model-Selector (z. B. "Auto Prompt Router").

Valves sind die Konfigurationsfelder einer Function/Pipe in OpenWebUI – das ist ziemlich praktisch. Sie sind typisiert (z. B. String, Boolean), im Admin-UI sichtbar und zur Laufzeit änderbar, ohne dass wir Code neu deployen müssen. Wir nutzen Valves, um das Klassifizierer-Modell zu setzen (etwa amazon.nova-micro-v1:0), pro Kategorie die Zielmodelle festzulegen (default, coding, deep-reasoning, content-generation, structured-analysis, vision) und optional einen Schalter zu aktivieren, der Statushinweise erlaubt. So können wir Modelle tauschen, Kategorien erweitern oder Features ein-/ausschalten, ohne die Pipe neu zu packen – ein echter Vorteil im laufenden Betrieb.

Der Ablauf in pipe() bleibt geradlinig: Wir lesen die letzte User-Nachricht aus dem Request, bauen den Klassifizierungs-Prompt, rufen den Klassifizierer über die OpenWebUI-Hooks auf und normalisieren die Antwort minimal (erste sinnvolle Zeile, Trimmen, Kleinschreibung, Schreibweise harmonisieren). Anschließend prüfen wir, ob die Kategorie bekannt ist, setzen body["model"] auf das passende Zielmodell und übergeben den unveränderten Prompt an die Generierung. Details zu Fehlerbehandlung und Sicherheitsaspekten folgen im späteren Abschnitt.

async def pipe(self, body: dict, __user__: dict) -> str:
    # build the classifier request
    prompt = self._extract_last_user_message(body)
    classifier_request = self._build_classifier_request(prompt)

    # run it and process the response
    clf_response = await generate_chat_completion(
        __request__, classifier_request, user
    )
    raw_label = self._parse_classifier_label(clf_response)
    category = (raw_label or "").strip().lower()

    # set the model
    model_id = self.router.model_for(category)
    body["model"] = model_id

    # forward the initial prompt
    return await generate_chat_completion(__request__, body, user)

Aus Anwendersicht erscheint die Pipe nach dem Upload im Model-Selector (z. B. "Auto Prompt Router"). Wir testen sie dort mit denselben Prompts wie im CLI, passen bei Bedarf die Valves an (Classifier-ID, Zielmodelle) und sind damit bereit für den produktiven Einsatz.

Schritt 7: Sofort-Feedback für Nutzer:innen (Events)

Ein Auto-Router wirkt anfangs wie Magie. Kurze Zwischenmeldungen schaffen Transparenz und erhöhen die Akzeptanz: Sobald der Klassifizierer entschieden hat, senden wir eine knappe Statusnachricht in den laufenden Stream, etwa "Kategorie: coding → Modell: Claude Sonnet". Nutzer sehen damit sofort, dass etwas passiert, während die eigentliche Antwort des Zielmodells noch generiert wird. Die wahrgenommene Reaktionszeit verbessert sich spürbar – und gleichzeitig wächst das Vertrauen, dass komplexe Prompts tatsächlich bei den großen Reasoning-Modellen landen.

Technisch läuft das über das Event-System von OpenWebUI: Die Pipe erhält einen __event_emitter__. Ist unser Valve für Statusmeldungen aktiv, emittieren wir direkt nach der Klassifizierung ein Event vom Typ "status" mit einer kurzen, gut lesbaren Beschreibung der erkannten Kategorie und des gewählten Modells. Das Event ist nicht blockierend, wird im Chat-Stream angezeigt und hält die Antwortpipeline frei. Wichtig ist, die Nachricht bewusst knapp zu halten (nur Kategorie und Modell) – informativ, aber ohne unnötige Details.

Schritt 8: OpenWebUI-Upload über das Web-Interface

Jetzt heben wir die fertige Pipe ins OpenWebUI. Voraussetzung sind Admin-Rechte; den Code bringen wir direkt über die Oberfläche hinein – kein Dateisystemzugriff nötig. Vorgehen:

1. Im Admin-Bereich zu Functions → New wechseln und eine neue Pipe Function anlegen (Name, Beschreibung).

2. Den kompletten Inhalt von prompt_router.py in den Editor einfügen und speichern.

3. Die Funktion aktivieren; im Model-Selector erscheint z. B. "Auto Prompt Router".

4. Valves prüfen/setzen:

   • CLASSIFIER_MODEL_ID (z. B. eu.amazon.nova-micro-v1:0)

   • Zielmodelle je Kategorie (MODEL_DEFAULT, MODEL_CODING, MODEL_DEEP, MODEL_STRUCT, MODEL_CONTENT, MODEL_VISION)

   • optional ROUTING_STATUS_ENABLED für kurze Statusmeldungen im Chat

Tipp aus der Praxis: Achte darauf, dass Modell-IDs zur Region passen (insbesondere beim Wechsel zwischen lokalem Test und UI-Betrieb). Die IDs sind case-sensitive und müssen exakt der OpenWebUI-Notation entsprechen.

So testen wir im UI: den "Auto Prompt Router" auswählen, typische Prompts senden (Coding, Default, Deep-Reasoning) und prüfen, ob Kategorie und Zielmodell wie erwartet zugeordnet werden. Falls aktiviert, erscheint direkt nach der Klassifizierung eine kurze Statusmeldung mit erkannter Kategorie und gewähltem Modell – damit lässt sich das Feedbackverhalten gleich mit verifizieren.

Fehlerverhalten: bewusst einfach

Kurzer Erfahrungsbericht aus der Implementierung: Wir fahren ein "fail fast"-Verhalten. Wenn der Klassifizierer ein unerwartetes Format liefert oder eine unbekannte Kategorie zurückkommt, brechen wir mit einem klaren Fehler ab. Es gibt keine stillen Fallbacks auf "default" und keine verdeckten Korrekturen; die Status-Events aus Schritt 7 sind reine Transparenz, nicht Fehlerbehandlung.

Warum so strikt? Das System läuft intern – hier ist es hilfreicher, Fehler sofort sichtbar zu machen, statt sie zu kaschieren. Das hält den Code schlank, gut wartbar und leicht zu debuggen (KISS-Prinzip). Und falls es im Einzelfall hakt, können User jederzeit ein konkretes Modell manuell auswählen, auch mitten in der Unterhaltung. So bleibt der Workflow trotz bewusst einfachem Error Handling jederzeit handhabbar.

Wenn später mehr Absicherung benötigt wird (z. B. soft Fallbacks, Retries, Timeouts oder Synonym-Mappings), lässt sich das gezielt ergänzen. Die aktuelle Version priorisiert jedoch Einfachheit und Nachvollziehbarkeit – Eigenschaften, die sich in der Praxis als wertvoller erwiesen haben als ausgefeilte Fehlerbehandlung.

Kostenbeispiel: Breakeven nach wenigen Prompts

Für eine grobe, leicht verdauliche Wirtschaftlichkeitsrechnung nehmen wir folgende, runde Annahmen (pro Prompt, stark vereinfacht und im Durchschnitt gedacht; je nach Region/Modus weichen Preise ab – uns geht es hier ums Prinzip):

• Premium-Modelle (z. B. Claude oder GPT-4o): ca. 1 Cent

• Kleines Modell (z. B. GPT-4o mini): ca. 0,1 Cent

• Klassifizierung mit Nova Micro: ca. 0,001 Cent

Jetzt rechnen wir mit 10.000 Prompts:

• Die Klassifizierung aller 10.000 Prompts über Nova kostet zusammen rund 10 Cent.

• Wenn wir einen Prompt statt Premium über das kleine Modell laufen lassen, sparen wir 0,9 Cent (1,0 − 0,1).

• Das heißt: Schon ab etwa 12 umgerouteten Prompts (12 × 0,9 Cent = 10,8 Cent) haben wir die 10 Cent Klassifizierungskosten vollständig kompensiert – alles darüber ist reiner Kostenvorteil.

Takeaway: Der Breakeven liegt extrem niedrig. In der Praxis reichen schon wenige "leichte" Prompts (z. B. kurze Bestätigungen, "Danke", Mini-Rückfragen), die über ein günstiges Modell laufen, damit sich das vorgeschaltete Routing mit Nova Micro klar rechnet. Bei unserem internen Einsatz haben wir bereits nach wenigen Tagen einen messbaren Kostenvorteil gesehen.

Fazit: Qualität, Transparenz und Kosten im Gleichgewicht

Wir haben eine Auto-Routing-Pipe gebaut, die in der Praxis genau das leistet, was Teams brauchen: vereinfachte Bedienung, nachvollziehbare Entscheidungen und kontrollierbare Kosten. Der Weg dorthin ist bewusst schlank: Wir testen lokal, integrieren dann als Pipe in OpenWebUI, steuern alles über Valves und geben auf Wunsch sofortiges Feedback per Event-Stream aus. Das reduziert Reibung spürbar – niemand muss mehr manuell ein Modell wählen, und zugleich ist jederzeit sichtbar, wohin geroutet wurde.

Technisch bleibt die Lösung wartungsarm: klarer Klassifizierungs-Prompt, kompakter Router, KISS-basiertes Fehlerverhalten mit "fail fast". Wirtschaftlich ist der Effekt schnell messbar: Weil Nova Micro extrem günstig ist, liegt der Breakeven praktisch bei wenigen leichten Prompts pro tausend Anfragen. Für uns ist das der pragmatische Weg, KI intern zu skalieren: bessere Nutzererfahrung, weniger Komplexität, und Kosten, die planbar bleiben.


Simon Bönisch, November 2025