Immer wieder erscheinen bessere und günstigere KI-Modelle. Das Modell, das beim Release deiner App sinnvoll war, ist vielleicht schon wenige Wochen später nicht mehr die beste Wahl. Doch wenn die Modell-ID in einer veröffentlichten iOS-App oder auf einem bereitgestellten Server fest verankert ist, wird jedes Upgrade zu einem weiteren Release. Wie hältst du die Anwendung aktuell, während Nutzer noch alte Builds verwenden? Haimaker ermöglicht es dir, die Modelle deiner Anwendung zu aktualisieren, ohne sie erneut zu deployen. Sende haimaker/auto als Modell-ID und ändere dann das Standardmodell oder promptspezifische Regeln im Dashboard.
Dieses Problem wiederholt sich bei jedem neuen Modell-Release. Entwickler müssen Qualität, Kosten und Fähigkeiten anhand ihrer Workload testen. Wenn die Modellwahl außerhalb des deployten Codes liegt, können sie auf diese Ergebnisse reagieren, ohne einen weiteren App- oder Server-Release einzuplanen.
Eine feste Modell-ID wird nach dem Release veraltet
Eine feste Modell-ID macht jedes Modell-Upgrade vom Release-Prozess der Anwendung abhängig. Das ist noch handhabbar, solange du die erste Version baust. Nach dem Launch kann jede vielversprechende Modelländerung oder Preisanpassung bedeuten, dass Code bearbeitet, Tests durchgeführt, Server deployed oder ein Mobile-Update eingereicht werden muss. Neue Modelle können zwischen App-Releases erscheinen.
Bei einer iOS-App kann eine im Client eingebettete Modell-ID für Nutzer, die kein Update installiert haben, nicht geändert werden. Apple prüft App-Updates vor der Verteilung, und Nutzer behalten ältere Versionen oft lange, nachdem ein neuer Build verfügbar ist. Den API-Call ins Backend zu verlagern verhindert, dass ein Provider-Key in der App gespeichert wird, aber eine hartcodierte Modell-ID im Backend erfordert trotzdem eine Konfigurationsänderung oder ein Deployment.
Ein Gateway-Endpoint allein löst das Problem nicht. Wenn eine Anfrage ein festes Modell benennt, bleibt der Aufrufer an diese Wahl gebunden. OpenRouter unterstützt beispielsweise benannte Modelle ebenso wie seinen eigenen openrouter/auto Router. Ein Auto-Router kann die zugrunde liegende Modellwahl aus dem deployten Code heraushalten. Mit Haimaker kannst du die Routing-Policy für deine eigenen Prompt-Klassen anpassen, nachdem die Anwendung ausgeliefert wurde.
Wie bleibt eine deployte App bei neuen Modellen auf dem Laufenden?
Sende eine stabile Modell-ID von der Anwendung und verwalte die Auswahl-Policy in Haimaker. Ein Router hat ein Standardmodell für nicht zugeordnete Anfragen und Regeln, die bestimmte Arten von Prompts an andere Modelle weiterleiten. Der Router ist einem API-Key zugewiesen. Wenn du seine Ziele änderst, können nachfolgende Anfragen andere Modelle erreichen, obwohl der deployte Aufrufer weiterhin haimaker/auto sendet.
Bei einem Mobile-Produkt sollte die App dein Backend aufrufen und das Backend Haimaker. So bleibt der API-Key von den Geräten der Nutzer fern. Eine Server-Anwendung kann dasselbe Muster direkt verwenden: Ihr Anfrage-Code bleibt unverändert, während ein Operator den Router anpasst. Die Setup-Dokumentation zeigt, wie man einen Router erstellt, ein Standardmodell wählt, einen API-Key zuweist und Anfragen testet.
import OpenAI from "openai";
// Run this on your backend; do not bundle the API key in a mobile app.
const client = new OpenAI({
baseURL: "https://api.haimaker.ai/v1",
apiKey: process.env.HAIMAKER_API_KEY,
});
const response = await client.chat.completions.create({
model: "haimaker/auto",
messages: [{ role: "user", content: prompt }],
});
Der Code oben benötigt keinen neuen Modellnamen, wenn sich das Standardmodell ändert. Haimaker hält Router-Konfigurationen für bis zu 60 Sekunden im Cache, also plane eine Minute ein, bis eine Dashboard-Änderung alle nachfolgenden Anfragen erreicht.
Standardmodell aktualisieren, dann günstigere Arbeit separat routen
Das Standardmodell zu ändern, verbessert die gesamte Workload. Regeln ermöglichen gezieltere Änderungen, wenn ein neues Modell für eine Aufgabe günstiger oder besser ist. Diese Unterscheidung ist wichtig: Eine App braucht vielleicht ein leistungsfähiges Standardmodell für Langtext-Bearbeitung, während kurze Titel-Vorschläge an ein günstigeres Modell gehen. Beide Entscheidungen können nach dem Release geändert werden, ohne die Modell-ID des Aufrufers zu ändern.
Stell dir eine Schreib-App vor, deren Backend jede KI-Anfrage über denselben Router sendet. Ein neu veröffentlichtes Modell verbessert die Langtext-Bearbeitung, also testet das Team es und ändert das Standardmodell des Routers. Später erledigt ein günstigeres Modell Titel-Vorschläge gut genug. Das Team fügt eine Regel mit Beispielen wie „Schlage fünf kurze Titel für diese Notiz vor” und „Gib diesem Entwurf eine prägnante Überschrift” hinzu und weist diese Regel dem günstigeren Modell zu. Nutzer mit älteren App-Versionen erhalten beide Änderungen über das bestehende Backend.
Für beispielbasierte Regeln verwende 3 bis 10 repräsentative Prompts pro Aufgabe. Bei einer Übereinstimmung wird die Anfrage an das Ziel der Regel weitergeleitet; nicht zugeordnete Anfragen verwenden das Standardmodell. Fähigkeitsprüfungen verhindern, dass eine Regel eine Vision-, Tool-Use- oder Structured-Output-Anfrage an ein Modell sendet, das sie nicht verarbeiten kann. Die Routing-Logs zeigen das aufgelöste Modell und die Regel, die es ausgewählt hat. Für die Mechanik hinter Matching und Fallback sieh dir unseren Routing-Walkthrough und den Cost-Routing-Leitfaden.
Was ändert sich für ein Team nach dem Launch?
Der Hauptvorteil ist, dass die Modellwahl der Workload statt dem Release-Kalender zu folgen kann. Ein Team kann ein neues Standardmodell übernehmen, eine wiederkehrende Prompt-Klasse auf ein günstigeres Modell verschieben oder ein früheres Ziel wiederherstellen, wenn die Ergebnisse schlechter werden. Server-Code und installierte Mobile-Clients senden weiterhin dieselbe API-Anfrage. Die Arbeit verlagert sich auf das Testen und Überprüfen der Routing-Entscheidung.
| Änderung nach dem Launch | Mit festem Modell im Code | Mit haimaker/auto |
|---|---|---|
| Ein besseres Allround-Modell erscheint | Modell-ID ändern und Code oder Config releasen | Testen, dann das Standardmodell des Routers ändern |
| Ein günstigeres Modell passt zu einer Prompt-Klasse | Anwendungs-Routing-Logik hinzufügen und deployen | Eine Regel für diese Prompt-Klasse hinzufügen oder bearbeiten |
| Eine Modelländerung verschlechtert die Ausgabequalität | Code- oder Config-Änderung zurücknehmen | Das frühere Router-Ziel wiederherstellen |
| Nutzer verwenden noch einen älteren Mobile-Build | Die eingebettete Modell-ID bleibt veraltet | Das Backend kann die aktuelle Router-Policy nutzen |
Das hilft auch, wenn für Server-Releases noch andere Arbeiten anstehen. Eine Modellentscheidung muss nicht auf dieses Deployment-Fenster warten. Separate Workloads können separate Router verwenden, indem sie verschiedenen API-Keys zugewiesen werden; Haimaker unterstützt einen Router pro Key.
Routing-Änderungen erfordern weiterhin dieselbe Sorgfalt wie Code-Änderungen. Die Dashboard-Sandbox zeigt, welches Modell ein Prompt auswählen würde, aber sie beweist nicht, dass die Antwort gut ist. Teste repräsentative Prompts mit dem vorgeschlagenen Modell, prüfe echte Ausgaben, beobachte die Logs zum aufgelösten Modell und kehre zum vorherigen Ziel zurück, wenn die Qualität nachlässt. Haimaker ändert die Modellauswahl; Änderungen an Prompts, Tool-Schemas oder Anwendungsverhalten erfordern weiterhin Arbeit an der Anwendung.
Modellwahl für den nächsten Release bereithalten
Erstelle einen Router, wähle ein Standardmodell und weise ihn dem API-Key zu, den dein Backend verwendet. Sende haimaker/auto in der Anfrage und teste dann einige Prompts, die die Workload repräsentieren. Wenn ein neues Modell erscheint, evaluiere es anhand dieser Prompts, bevor du das Standardmodell oder eine spezifische Regel änderst. Die Haimaker-Dokumentation deckt Router-Setup, Test-Sandbox und Routing-Verlauf ab.
Neue Modelle können vor deinem nächsten App-Release erscheinen. Wenn die Modellwahl in Haimaker liegt, bleibt die Anwendung aktuell, während Entwickler ihre Release-Zyklen für Änderungen nutzen können, die neuen Code erfordern.
Häufig gestellte Fragen
Wie kann ich das KI-Modell in einer veröffentlichten Mobile-App ändern?
Lass die App dein Backend aufrufen und das Backend model: ‘haimaker/auto’ an Haimaker senden. Dann kannst du das Standardmodell des Routers oder Prompt-Regeln im Dashboard ändern, ohne einen neuen Mobile-Build einzureichen. Router-Änderungen können bis zu 60 Sekunden benötigen, um wirksam zu werden.
Erfordert der Modellwechsel über Haimaker ein Server-Deployment?
Nein. Wenn der bereitgestellte Server bereits model: ‘haimaker/auto’ mit einem API-Key sendet, der einem Router zugewiesen ist, kannst du die Modellziele des Routers im Dashboard ändern. Änderungen an Anwendungs-Prompts, Anfrageformaten oder Code erfordern weiterhin das übliche Deployment.
Kann ich nur einfache Prompts auf ein günstigeres Modell verschieben?
Ja. Füge eine Regel mit 3 bis 10 Beispiel-Prompts für eine einfache Aufgabe hinzu und wähle ein günstigeres Zielmodell. Haimaker prüft, ob das Ziel die Anfrage unterstützt, während Prompts, die keiner Regel entsprechen, das Standardmodell des Routers verwenden.