ModelWarden Betriebsleitfaden

Zuerst lesen

Ein lokaler Kontrollpunkt, vier getrennte Nachweise

Ein grünes /health zeigt nur, dass der Prozess Anfragen beantwortet. Prüfe Client-Anmeldung und Upstream-Routing getrennt. Für einen Schutznachweis verwende einen harmlosen kontrollierten Tool-Aufruf-Test, prüfe die tatsächliche Durchsetzung, gleiche die konfigurierten Audit-/Ereignisdaten ab und bestätige, was der vorgesehene Client erhält. Eine normale Textantwort ist kein solcher Nachweis.

Für KI-Agents und Automatisierung

Sicherer Arbeitsvertrag für Agents

Ordne jede Beobachtung einem genauen Zustand zu. Der Quellcode, ein veröffentlichter Download, der gerade laufende Binary-Build, seine gespeicherte JSON-Datei und die wirksame lizenzierte Richtlinie können voneinander abweichen. Nenne den belegten Zustand, statt alles als „ModelWarden unterstützt das“ zusammenzufassen.

Prüfungen vor einer Änderung

1. Ermittle den genauen Prozess, dessen eigene --version-Ausgabe, den Hash der ausführbaren Datei, den aktiven --config-Pfad, Listener und Lizenzlebenszyklus. Prüfe vor einem Start, ob bereits eine Instanz lauscht. Bei Startoptionen darfst du Standardpfad und Standardport nicht voraussetzen.
2. Beginne mit maskierten oder schreibgeschützten Ansichten. Gib niemals Tokens, Inhalte von Zugangsdaten-Quellen, Provider-Geheimnisse, Session-Cookies oder eine unmaskierte Konfiguration in Logs oder Chats aus.
3. Bewahre auf einem vertrauenswürdigen Dateisystem eine nur für den Besitzer lesbare Kopie der aktiven Konfiguration und aller für ein Rollback benötigten Zugangsdaten-Quellen auf, niemals in einem gemeinsam genutzten temporären Verzeichnis. Ohne das benachbarte Verzeichnis <Konfigurationsdateiname>.credentials kann eine JSON-Datei unvollständig sein.
4. Nutze für Änderungen die Dashboard-Oberfläche, sofern der genaue routenspezifische API-Vertrag dieser Binärversion nicht geprüft wurde. Aktualisiere die Seite unmittelbar vor der Änderung und lass die Oberfläche aktuelle Revision, Anmeldung und Herkunftsprüfung mitsenden. Es gibt keinen allgemeinen öffentlichen Vertrag für eine „Admin-Schreib-API“; erfinde keinen und spiele keine aufgezeichnete Anfrage erneut ein.
5. Lies den Zustand nach jedem Schreibvorgang erneut. Ein Timeout oder eine verlorene Antwort ist mehrdeutig: Die Änderung kann bereits gespeichert sein.
6. Prüfe zuerst die betroffene Ebene, dann Audit-/Ereignisdaten, Dashboard-Anzeige und vorgesehenen Client. Ein Status 200 von /health belegt keine Durchsetzung.

pgrep -af '(^|/)mw-proxy([[:space:]]|$)'
ss -ltn 'sport = :3758'
ps -p PID -o pid=,lstart=,args=
readlink -f /proc/PID/exe
/proc/PID/exe --version
sha256sum /proc/PID/exe

ModelWarden stellt keine dauerhafte öffentliche Instanz-ID bereit. Verknüpfe eine Beobachtung mit Basis-URL, beobachteter ausführbarer Datei samt Version und Hash, Befehlszeile, Listener und aktiver Konfiguration. PID, Port, Konfigurationsrevision oder Lizenzreferenz sind nützliche Nachweise, aber für sich allein keine dauerhafte Identität.

Verbindliche Leseansichten vor einer Änderung

Nutze für die gewünschte Änderung die kleinste passende, geschwärzte Statusansicht. Administrative Lesezugriffe brauchen die unten beschriebene Berechtigung und geben keine wiederverwendbaren Geheimnisse zurück.

Authentifizierungsregeln je Oberfläche

Dashboard-API-Routen akzeptieren eine gültige Browser-Sitzung oder einen Admin-Bearer, sofern eine Route nicht ausdrücklich nur den Bearer zulässt. Schreibvorgänge mit Browser-Sitzung müssen Same-Origin bleiben. Ein Nicht-Browser-Client mit Bearer sollte Origin weglassen, sofern er nicht den genauen Ursprung des Dashboards senden kann; ein Bearer umgeht die Herkunftsprüfung nicht. Nachdem ein Schreibvorgang auf die Konfigurationssperre gewartet hat, prüft ModelWarden die ursprüngliche Berechtigung erneut. Eine gleichzeitige Erneuerung von Zugangsdaten kann deshalb zu 401 authentication_required führen.

Ergebnis jedes Schreibvorgangs einordnen

Lies nach einer mehrdeutigen Änderung an Zugangsdaten oder Lizenz in dieser Reihenfolge: /admin/api/v1/credentials, /admin/api/v1/license/credentials, /admin/api/v1/license und—falls Provider oder Routen betroffen waren—/admin/api/v1/provider-config. Vergleiche gespeicherte und Laufzeitrevisionen, bevor du eine neue Aktion auswählst.

Bevorzugte nicht-invasive Prüfungen

• Nutze das öffentliche GET /v1/models, um die wirksame Routensuche ohne Inferenzkosten zu prüfen. Der Client-Schlüssel wird dabei nicht authentifiziert.
• Bestätige zuerst, dass die Client-Anmeldung aktiviert ist. Sende dann eine formal gültige Inferenzanfrage mit absichtlich ungültigem Platzhalterschlüssel und erwarte 401 vor einer Weiterleitung. Bei deaktivierter Anmeldung ist dies keine nebenwirkungsfreie Ablehnungsprüfung. Erfolgreiche Anmeldung prüfst du nur über einen Test-Upstream oder einen ausdrücklich freigegebenen echten Upstream.
• Nutze Debug, sofern freigeschaltet, für einen harmlosen synthetischen Tool-Aufruf ohne Ausführung. Die Bewertung kann den konfigurierten Judge kontaktieren und Kosten verursachen; der eingebundene Debug-Evaluator erzeugt keinen normalen Audit-Eintrag zur Durchsetzung.
• Nutze mw-proxy --check-allocation …, um gespeicherte Befehlsentscheidungen ohne Schreibzugriff oder Befehlsausführung zu prüfen.
• Für Routing-Nachweise sende einen normalen Text-Prompt mit deaktivierten Client-Tools über einen Test-Upstream oder einen ausdrücklich freigegebenen echten Upstream. Prüfe Durchsetzung getrennt mit einem Test ohne Tool-Ausführung. Führe niemals einen destruktiven Befehl aus, nur um seine Erkennung zu beweisen.

Wichtig für die Anmeldung

Drei Aufgaben, drei Zugangsdaten

In diesem älteren Modus meldet sich ein Mensch mit dem ausgewählten Passwort oder dem unveränderten Client-Schlüssel an. Der ältere Admin-Bearer ist dessen SHA-256-Hash in Hexadezimalform und nicht der unveränderte Wert. Beim Schützen der Zugangsdaten kann dieser Bearer absichtlich zur Kompatibilität erhalten bleiben; Schutz allein ist daher noch keine Erneuerung.

1. Öffne Config → Credentials, solange du noch Zugang zum Dashboard hast.
2. Wähle Protect credentials. War die Anmeldung ausgeschaltet, fragt das Formular nach einem neuen Passwort und kann einmalig ein neues Admin-Token anzeigen. Im älteren Modus bleiben stattdessen die bisherige Dashboard-Anmeldung und der Admin-Bearer zur Kompatibilität erhalten. In beiden Fällen endet die aktuelle Browsersitzung.
3. Melde dich beim älteren Ablauf noch einmal mit demselben Passwort oder unveränderten Client-Schlüssel an, wähle Change dashboard password, lege ein eigenes Passwort fest und melde dich erneut an. Auch dieser zweite Speichervorgang beendet bestehende Sitzungen. Ändere den Client-Schlüssel erst, wenn das eigene Passwort funktioniert.
4. Wenn die Seite meldet, dass das Admin-Token aus Dashboard-Passwort oder Proxy-Client-Schlüssel abgeleitet wurde, erneuere es, sobald die API-Clients vorbereitet sind. Wurde der bisherige Wert offengelegt oder ist seine Herkunft unklar, ist die Erneuerung Pflicht. Sichere das einmal angezeigte Ergebnis, aktualisiere alle Admin-API-Clients und prüfe ohne Protokollierung beider Tokens, dass der alte Bearer nicht mehr authentifiziert.
5. Schütze, importiere oder erneuere erst danach den Proxy-Client-Schlüssel.

Eine Änderung am Dashboard-Passwort oder Admin-Token beendet bestehende Browser-Sitzungen. Nach dem Schutz der Dashboard-Anmeldung ist ein Client-Schlüsselwechsel davon getrennt; er gilt für neue Proxy-Anfragen. Trage den neuen Schlüssel daher in allen Clients ein, die den alten verwenden.

Plattformgrenze: Die geschützte lokale Migration von Zugangsdaten wird für die aktuell veröffentlichten Linux-Builds unterstützt und dokumentiert. Leite Windows- oder macOS-Unterstützung nicht allein aus einem Plattformpfad in diesem Leitfaden ab; prüfe vor einer geplanten Migration die Downloads-Seite und die Fähigkeit im Zugangsdaten-Status dieses Builds.

Dashboard-Zugang wiederherstellen

Wenn weder das erwartete Passwort noch der bisherige Client-Schlüssel funktionieren, versuche es nicht immer wieder. Die Wiederherstellung ändert die aktive Authentifizierung: Ein KI-Agent muss im Lesemodus bleiben, bis der Betreiber die genaue Instanz und die genaue Sicherung freigibt.

1. Verknüpfe mit den oben genannten Identitätsprüfungen PID, ausführbare Datei, Listener und aktiven Konfigurationspfad. Stoppe nach der Freigabe genau diesen Prozess und niemals über eine breite Namenssuche.
2. Erstelle auf einem vertrauenswürdigen Dateisystem eine nur für den Besitzer lesbare Wiederherstellungskopie der aktuell fehlerhaften Konfiguration, des benachbarten Verzeichnisses <Konfigurationsdateiname>.credentials und aller benachbarten Sicherungen. Bewahre sie als zusammengehörigen Satz auf. Verwende kein gemeinsam genutztes temporäres Verzeichnis, kopiere keine Inhalte in einen Chat und lösche oder bearbeite keine Zugangsdaten-Dateien.
3. Wähle eine Sicherung <config-name>.provider-backup-…, deren Basisname zur aktiven Konfiguration passt und deren Zeitstempel vor der fehlgeschlagenen Änderung liegt. Wähle nicht blind „die neueste“. Prüfe, dass jede von dieser Sicherung benötigte Zugangsdaten-Quelle noch existiert. Bei Unklarheit über Konfiguration, Zeitstempel, Eigentümer oder Zuordnung musst du stoppen.
4. Behalte Eigentümer und Dateimodus der aktiven Datei bei. Ersetze die Konfiguration mit dem Betriebssystem-/Service-Verfahren des Betreibers atomar auf demselben Dateisystem. Verbinde keine Konfigurationssicherung mit unpassendem Zugangsdaten-Material.
5. Starte dieselbe ausführbare Datei mit demselben --config-Pfad. Prüfe den erwarteten Listener und /health, melde dich mit den Zugangsdaten dieser Sicherung an und kontrolliere Dashboard-Passwort, Berechtigung des Admin-Tokens und Zustand des Client-Schlüssels unter Config → Credentials, bevor du etwas Weiteres änderst.

Es gibt keinen sicheren unbeaufsichtigten Kurzbefehl zum Zurücksetzen der Anmeldung. Wenn genaues Ziel, passende Sicherung, Dateieigentümer, Verfahren zum atomaren Ersetzen oder externe Zugangsdaten-Quelle unklar sind, bewahre alles auf und wende dich an den Support. Entferne nicht dashboard.authentication und bearbeite keine Passwort-Prüfsummen von Hand.

Konfiguration

Dateipfade, Dashboard und JSON

Die Konfiguration ist eine JSON-Datei. Ohne Argumente verwendet mw-proxy den Standardpfad des Betriebssystems und legt dort bei Bedarf eine gültige Standarddatei an.

Linux

$XDG_CONFIG_HOME/modelwarden/config.json, sonst ~/.config/modelwarden/config.json.

macOS

~/Library/Application Support/modelwarden/config.json.

Windows

%APPDATA%\modelwarden\config.json.

mw-proxy
mw-proxy --config /absolute/path/config.json
mw-proxy --init --config /absolute/path/config.json
mw-proxy --tui

Für einen fehlenden, ausdrücklich angegebenen Pfad brauchst du --init. Die optionale TUI richtet einige Grundeinstellungen beim Start ein. Für eine bereits laufende Installation ist das Dashboard meist übersichtlicher.

Einstellungen im Dashboard

• Providers verwaltet Upstream-Dienste, Zugangsdaten, Formate, Modellsuche, Status und einfache Routenzuweisungen.
• Routing verwaltet Aliase, Provider-Reihenfolgen, Zeitpläne, Failover, Client-Beispiele und Plugin-Downloads.
• Judge verwaltet Provider und Einstellungen für kontextbezogene Prüfungen. Config verwaltet Schutz, Netzwerk, Betrieb und erweiterte JSON-Einstellungen.
• Unter Credentials kannst du Geheimnisse in geschützten lokalen Dateien oder unterstützten externen Quellen ablegen.

Nutze die gezielten Dashboard-Einstellungen. Sie prüfen den Entwurf und die Lizenzfreigaben und weisen veraltete Revisionen nach dem Vertrag der jeweiligen Änderungsfamilie zurück. Normale Richtlinienänderungen können zur Laufzeit gelten; Ausnahmen stehen unter Übernehmen und neu starten. Prüfe gespeichertes Ergebnis und Sicherungsbestand. Fehlt eine Antwort, lade den aktuellen Stand vor einem erneuten Versuch: Die erste Änderung könnte bereits gespeichert sein.

{
  "version": "0.1.0",
  "enabled": true,
  "heuristics_only": true,
  "api_key": "replace-with-a-client-key",
  "route": {
    "my-model": [{
      "name": "primary",
      "endpoint": "https://provider.example/v1",
      "api_key": "replace-with-provider-key",
      "format": "openai",
      "priority": 1,
      "model": "upstream-model"
    }]
  },
  "proxy": { "host": "127.0.0.1", "port": 3758 }
}

Routing

Provider, Routen, Aliase und Failover

Der Routenschlüssel ist der Modellname, den der Client sendet. Eine Route verweist auf eine oder mehrere Upstream-Provider-Zuordnungen in Prioritätsreihenfolge. Eine Zuordnung kann den Routenschlüssel auf einen anderen Modellnamen beim Provider abbilden.

Für die erste Route öffne Providers → Add Endpoint, richte Endpunkt und Upstream-Modell ein und nutze beim Modell Assign. Kontextbezogene Prüfung richtest du getrennt unter Judge → Provider chain → Add Provider ein. Eine Routenzuweisung konfiguriert nicht zugleich einen Judge.

Provider-Formate

openai, openai_responses (Alias responses), anthropic, gemini, bedrock, ollama und mcp.

Einfache Route

Jedes Profil kann eine Route mit einem Provider einrichten.

Failover nach Reihenfolge

Professional und Enterprise können je nach Lizenz mehrere Provider, Zeitpläne und Aliase ergänzen. Wiederholungsversuche sind begrenzt und enden, sobald Teile der Antwort gesendet wurden.

Routen nach Bildunterstützung

Die Auswahl kann Bildanfragen von Provider-Zuordnungen fernhalten, die Bilder nicht unterstützen.

Der Provider-Status zeigt die Verbindung zum Upstream. Er beweist nicht, dass Sicherheitsprüfungen aktiv sind. Teste eine normale Anfrage über genau die Route und den Client, die du später verwenden willst.

Clients

Clients verbinden, ohne Provider-Schlüssel weiterzugeben

Clients benötigen nur die ModelWarden-Basis-URL, einen Routenschlüssel und den Proxy-Client-API-Schlüssel. Zugangsdaten der Provider bleiben in ModelWarden.

curl --fail http://127.0.0.1:3758/v1/models

read -rsp 'Proxy client key: ' MODELWARDEN_API_KEY; printf '\n'
export ANTHROPIC_BASE_URL=http://127.0.0.1:3758
export ANTHROPIC_API_KEY="$MODELWARDEN_API_KEY"
claude --model my-model

model = "my-model"
model_provider = "modelwarden"

[model_providers.modelwarden]
name = "ModelWarden"
base_url = "http://127.0.0.1:3758/v1"
env_key = "MODELWARDEN_API_KEY"
wire_api = "responses"
supports_websockets = false

Schutz

Prüfen, welcher Schutzmodus aktiv ist

Diese Einstellungen stehen unter Config → Safety → General. on_error gilt nach einem Judge-Aufruf und hat den Standardwert Allow. Ein ungeprüftes Flag folgt unjudged_flag_action, ebenfalls standardmäßig Allow. Prüfe bei sensiblen Einsätzen beide Einstellungen. Ein einzelner Schalter für „bei Fehlern sperren“ deckt nicht alle Fälle ab.

Kein verfügbarer Judge: Die aktuelle wirksame Richtlinie fällt auf reine Heuristik-Prüfung zurück, wenn kein Judge nutzbar ist. Free und Professional verwenden deine eigenen Judge-Zugangsdaten; Enterprise Managed nutzt verwaltete Prüfung nur, wenn der signierte Vertrag sie bereitstellt. Prüfe die wirksame Richtlinie, nicht nur den gespeicherten Schalter.

Entscheidungen

Judge-Prüfung, menschliche Freigaben und Allocations

• Judge: Richte unter Judge eine eigene Provider-Kette ein. Geprüft werden können alle nicht als vertrauenswürdig eingestuften Tools oder nur Aufrufe, die Heuristiken markiert haben.
• Freigaben: Bei berechtigten HTTP-Abläufen kann eine Ask-Entscheidung auf die Antwort eines Menschen warten. Für wartende Anfragen gelten Zeitlimit, Obergrenze gleichzeitiger Anfragen und eine Aktion nach Ablauf.
• MCP stdio: Bietet keine integrierte Oberfläche für menschliche Freigaben. Ask wird abgelehnt. Richte MCP-Richtlinien daher so ein, dass sie ohne Wartezeit sicher Allow oder Deny entscheiden können.
• Allocations: Gespeicherte Entscheidungen für genaue Befehle, Befehlsteile und Vorlagen werden bei Aktivierung durchgesetzt. Sie können normale Markierungen ersetzen, aber niemals zwingende harte Sperren.

Der Standardwert im typisierten Freigabefeld ist Hold. Ohne passende Lizenz wird der Freigabeablauf in der wirksamen Free-Konfiguration jedoch ausgeschaltet. Maßgeblich sind die tatsächlich wirksamen Einstellungen im Dashboard für die aktive Lizenz.

Nachweise

Audit, Replay, Fehler und Überwachung

Prüfe für einen belastbaren Nachweis diese Ebenen der Reihe nach:

1. Proxy-Ergebnis: Wurde die Anfrage erlaubt, abgelehnt, zurückgestellt oder ist sie fehlgeschlagen?
2. Audit-/Ereignisdaten: Enthält der Eintrag Route, Tool, Heuristik- oder Judge-Ergebnis und Durchsetzung?
3. Dashboard: Zeigt Audit, Logs oder Errors dasselbe Ereignis?
4. Client-Test: Funktioniert der vorgesehene Client im gesamten Ablauf korrekt?

Ob Audit-Daten gespeichert werden, hängt von der aktiven Lizenzkonfiguration ab. Ein Audit mit Hash-Kette ist optional, standardmäßig ausgeschaltet und benötigt einen Pfad für den Signaturschlüssel. Auch die dauerhafte Speicherung von Session-Replays ist optional. Lege Aufbewahrungsdauer und Speicherlimits bewusst fest. Weitere Seiten behandeln Tracing, Warnmeldungen, Verfügbarkeit, Cron-Überwachung, Profiling, Versionsverwaltung, Issue-Tracking und Provider-Status.

Kein Eintrag ist noch kein Urteil. Reiner Text enthält möglicherweise keinen zu prüfenden Tool-Aufruf, die Protokollierung erlaubter Ereignisse kann ausgeschaltet sein, und Debug überspringt bewusst die Aufzeichnung in Audit. Gleiche ein kontrolliertes Tool-Aufruf-Ergebnis mit der konfigurierten Ereignisquelle ab, bevor du fehlenden Schutz diagnostizierst.

Datenschutz

Schwärzung von Geheimnissen: was in den Logs verborgen wird

ModelWarden verbirgt Geheimnisse in Tool-Argumenten, bevor ein Audit-Eintrag geschrieben wird. Der Eintrag behält Tool, Entscheidung und die nützlichen Werte; jedes Geheimnis wird zu <redacted>. Das funktioniert ohne weitere Einstellung.

Felder, die anhand ihres Namens verborgen werden

Ein Feld wird verborgen, wenn sein Name einem Wort wie password, secret, API key, access token, refresh token, authorization, cookie oder private key entspricht oder darauf endet. Groß- und Kleinschreibung sowie Satzzeichen spielen keine Rolle, daher werden DEPLOY_API_KEY und db_password beide verborgen.

Geheimnisähnliche Werte überall in einem Befehl

• Private-Key-Blöcke, etwa -----BEGIN PRIVATE KEY-----.
• Provider-Schlüssel: sk-…, GitHub ghp_… und github_pat_…, GitLab glpat-…, Slack xox… und AWS AKIA….
• Anmelde-Tokens (eyJ…).
• Header mit Bearer … und Basic ….
• Paare wie token=… und password: … sowie Optionen wie --token ….
• Passwörter in URLs, etwa postgres://user:pass@host.
• Geheime URL-Parameter, etwa ?token=….
• Cookie-Header.

Eigene Feldnamen ergänzen

"redact_keys": ["ticket_ref"]

Damit wird jedes Feld verborgen, dessen Name mit ticket_ref beginnt oder endet, unabhängig von Groß- und Kleinschreibung und Satzzeichen.

Änderungen gelten für neue Einträge. Bereits geschriebene Einträge bleiben, wie sie sind, und das Dashboard wendet dieselben Regeln erneut an, wenn es sie anzeigt.

Aktueller Quellcode

Funktionsübersicht

Verfügbare Funktionen richten sich nach signiertem Tarif und Kaufart. Unter Funktionen findest du den öffentlichen Tarifvergleich. Die lokalen Seiten License und Config zeigen, was diese Installation tatsächlich verwenden kann.

Lizenz

Aktivierung, Heartbeat und Offlinebetrieb

Füge das vollständige signierte Token auf der lokalen Seite License ein. Der Proxy bevorzugt die im Token signierte, vertrauenswürdige Portal-URL. Setze license.heartbeat_endpoint nur, wenn diese URL fehlt. Bleibt die Maschinen-ID bei der ersten Aktivierung leer, erzeugt der Proxy eine stabile lokale Kennung.

• Signierte Werte issued_at und expires_at geben die Gültigkeit des Tokens an. Für sich allein ändern sie nicht, ob ein Kauf ein dauerhaftes Nutzungsrecht umfasst.
• Aktivierungsbelege, Grenzen gleichzeitiger Vorgänge, Heartbeat-Kontingente, Kaufart und Kulanzregeln bestimmen gemeinsam den wirksamen Zugang.
• Bei Free, Professional und Enterprise BYOK bleiben Provider- und Judge-Zugangsdaten lokal. Bei Enterprise Managed kann das Portal vertraglich vereinbarte verwaltete Daten bereitstellen.

Wenn der Lizenzstatus nicht stimmt, prüfe Lebenszyklus und Funktionsfreigaben auf der License-Seite, bevor du die Konfiguration änderst. Ein erfolgreicher Heartbeat beweist weder, dass eine Modellanfrage funktioniert, noch dass ein Schutzmerkmal aktiv ist.

Offlinebetrieb ist eine Vertragsfreigabe, kein unbegrenzter Betrieb ohne Verbindung. Berechtigtes Enterprise BYOK kann auf regelmäßige Portal-Heartbeats verzichten, benötigt aber weiterhin gültige signierte Daten, den maschinengebundenen Aktivierungsbeleg und die Zeitprüfungen. Erneuerung und Upstream-Netzwerkzugriff bleiben relevant. Enterprise Managed ist ein eigener Betriebsmodus und erhält diese Ausnahme nicht automatisch.

Veröffentlichungsstand

Nach Updates suchen, ohne Quellcode und Download zu verwechseln

About → Check for Updates ist nur ein Hinweis. Die Funktion fragt das konfigurierte Portal nach der erkannten Artefaktplattform der laufenden Binärdatei, sofern vorhanden, prüft die zurückgegebene Veröffentlichungsbeschreibung und zeigt nur dann einen Download-Link, wenn die Angaben in sich stimmig sind und eine sichere HTTP(S)-URL verwenden. Die Prüfung kontaktiert dieses Portal und kann eine lokale, nur für den Besitzer lesbare Update-Cache-Datei erneuern. Sie ändert nicht die Hauptkonfiguration, lädt nichts herunter, installiert keine Binärdatei, ersetzt keine laufende Binärdatei und startet den Proxy nicht neu.

• Die Prüfung verwendet die Portal-URL aus dem wirksamen Lizenzstatus und ersatzweise den konfigurierten Heartbeat-Endpunkt. Fehlen beide Quellen, meldet sie, dass keine Portal-URL eingerichtet ist.
• Ergebnisse werden getrennt nach Portal-Ursprung und genauer Plattform kurz zwischengespeichert. Eine fehlerhafte, widersprüchliche, zu große, zurückgezogene oder ältere Antwort kann nicht zu einem vertrauenswürdigen Download-Link werden. Eine früher erkannte Version kann höchstens als veralteter Diagnosehinweis sichtbar bleiben.
• Die angemeldete Seite Downloads bleibt die verbindliche Quelle für Artefakte. Ein Plattformname im aktuellen Quellcode beweist nicht, dass ein Paket existiert, nativ getestet, signiert beziehungsweise notarisiert oder für dieses Konto verfügbar ist.

Aktuelle Grenze: Der lokale Quellcode kennt folgende Artefaktplattformen: Linux x86-64/ARM64, Windows x86-64/ARM64 sowie macOS Intel/Apple-Silicon/Universal 2. Damit ist nicht belegt, dass Windows-/macOS-Artefakte nativ gebaut, paketiert, signiert, notarisiert, installiert oder zur Laufzeit akzeptiert wurden. Maßgeblich ist das tatsächliche Angebot unter Downloads.

Änderungen übernehmen

Was sofort gilt und was einen Neustart braucht

Konfigurationsschreiber bewahren über ihre jeweilige Speicherlogik benachbarte Sicherungen auf, die nur der Besitzer lesen kann; eine unveränderte Aktion erzeugt nicht zwingend eine neue Kopie. Von den normalen Konfigurationssicherungen bleibt nur eine begrenzte Anzahl der neuesten erhalten. Prüfe vor einer größeren Migration die Sicherungsübersicht und erstelle zusätzlich eine eigene Kopie.

Schnelle Hilfe

Vom Symptom zur nächsten Prüfung

Automatisierung

CLI und wiederholbare Installationen

mw-proxy [--config PATH] [--host HOST] [--port PORT] [--init] [--tui]
mw-proxy models-dev import [--config PATH]
mw-proxy mcp [--config PATH] -- <server command…>
mw-proxy --check-allocation <COMMAND> [--config PATH] [--route KEY] [--tool NAME]
mw-proxy auth openai login …   # experimental; explicit OAuth endpoints required

• models-dev import ruft angekündigte Modellkataloge ab und speichert sie. Ein laufender Proxy benötigt für den CLI-Import einen Neustart; über die authentifizierte Dashboard-API ist der Import zur Laufzeit möglich.
• --check-allocation führt nichts aus. Die Option prüft lediglich gespeicherte Treffer.
• mcp -- startet einen konfigurierten stdio-Unterprozess und prüft Tool-Aufrufe mit derselben Pipeline. Ist das Gateway deaktiviert, leitet es transparent weiter.

Mehrere Installationen ausrollen

1. Erzeuge eine geprüfte JSON-Datei und Quellen für Zugangsdaten mit Berechtigungen, die nur dem Besitzer Zugriff erlauben. Halte Maschinenkennungen und maschinenspezifische Geheimnisse dort eindeutig, wo es erforderlich ist.
2. Starte einen einzelnen Canary mit einem ausdrücklichen Pfad: mw-proxy --config /etc/modelwarden/config.json.
3. Prüfe Prozess, öffentlichen Modellkatalog, Provider-Status und Lizenzlebenszyklus. Teste Client-Anmeldung und Upstream-Routing getrennt von einer harmlosen Tool-Aufruf-Prüfung mit passendem Durchsetzungs- und Ereignisnachweis, Dashboard-Anzeige und echtem Client.
4. Rolle in Gruppen aus und beobachte Errors, Audit, Provider-Status und Client-Erfolg. Bewahre die vorherige Konfiguration und alle referenzierten Zugangsdaten-Dateien für ein Rollback auf.