OmniRoute/docs/i18n/de/docs/reference/PROVIDER_PLUGIN_MANIFEST.md

Provider Plugin Manifest (Deutsch)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇬🇪 ka · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇮🇳 mr · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 pa · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

---

open-sse/config/providerPluginManifest.ts definiert den JSON-sicheren Vertrag für Provider-Plugins. open-sse/config/providerPluginManifestRegistry.ts bindet diesen Vertrag an die aktuelle Provider-Registry für Sidecars wie Bifrost, CLIProxyAPI oder einen zukünftigen Go-/Rust-Router. Die TypeScript-Registry bleibt die maßgebliche Quelle, aber Sidecars können das Manifest verwenden, ohne Executor-Code, OAuth-Standardwerte, Header oder den Zustand der Prozessumgebung zu importieren.

Dasselbe Manifest ist für Sidecars, die außerhalb des Prozesses ausgeführt werden, über HTTP unter GET /api/v1/provider-plugin-manifest verfügbar.

OmniRoute teilt Bifrost und CLIProxyAPI diese URL über den Request-Header X-OmniRoute-Provider-Manifest-Url mit. Setzen Sie OMNIROUTE_PROVIDER_MANIFEST_URL, wenn das Sidecar anstelle des lokalen Request-Ursprungs eine öffentliche URL oder eine URL im Container-Netzwerk benötigt.

Aktualisieren des Manifests

Der HTTP-Endpunkt gibt Cache-Control: public, max-age=60 und einen starken ETag zurück. Ein Sidecar sollte das zuletzt validierte Manifest beibehalten und dessen ETag beim Aktualisieren in If-None-Match senden. Eine Antwort 304 Not Modified hat keinen Body; das Sidecar behält sein zwischengespeichertes Manifest. Wenn kein validiertes zwischengespeichertes Manifest vorhanden ist, muss das Sidecar eine unbedingte Anfrage senden, anstatt eine 304-Antwort zu akzeptieren.

Ziel

Provider-Metadaten sollen schrittweise in einen Plugin-Vertrag überführt werden, sodass der zeitkritische Request-Pfad letztendlich von einem Sidecar mit geringerer Latenz übernommen werden kann, während OmniRoute die TypeScript-Route als Richtlinien-Gate und Fallback beibehält. Das Manifest ist additiv: Es ändert das Request-Routing nicht eigenständig.

Vertrag

Das Manifest enthält:

• Provider-ID und Alias
• Upstream-Format und Executor-Name
• Authentifizierungstyp, Authentifizierungs-Header und optionales Authentifizierungspräfix
• statische Endpunkt-Metadaten
• Sidecar-Eignung und explizite Gründe, wenn ein Provider auf dem TS-Pfad verbleiben sollte
• JSON-sichere Modellmetadaten wie Kontextlänge, Vision-/Reasoning-Flags und nicht unterstützte Parameter
• Funktions-Tags einschließlich apikey, oauth, custom-executor, passthrough-models, responses, sidecar-candidate, usage-fetch und usage-supported

Das Manifest schließt absichtlich Folgendes aus:

• OAuth-Client-Geheimnisse und standardmäßige Geheimniswerte
• Laufzeitauflösung der Umgebung
• Request-Header und öffentliche Hilfsfunktionen für Anmeldedaten
• dynamische URL-Builder
• Executor-Funktionen
• interne Details des Session-Pools

Funktions-Tags

capabilities ist ein sortiertes Array von Tags, die aus dem Registry-Eintrag abgeleitet werden. Integratoren sollten es als maschinenlesbare Antwort auf die Frage „Was kann dieser Provider?“ behandeln, anstatt die TypeScript-Quellen erneut auszulesen.

Tag	Bedeutung
apikey	Akzeptiert einen API-Schlüssel (authType ist apikey oder optional).
oauth	Verwendet einen OAuth- oder Session-Ablauf.
responses	Stellt eine Basis-URL für die OpenAI Responses API bereit.
passthrough-models	Stellt Modelle direkt vom Upstream statt aus einem statischen Katalog bereit.
custom-executor	Führt einen nicht standardmäßigen Executor aus und verbleibt daher auf dem TypeScript-Pfad.
sidecar-candidate	Spiegelt sidecar.eligible wider — kann sicher für einen Sidecar-Import in Betracht gezogen werden.
usage-fetch	Verfügt über eine eingebundene Nutzungs- oder Kontingent-Abruffunktion (getUsageForProvider).
usage-supported	Die Nutzungs-API akzeptiert diesen Provider (isSupportedUsageConnection).

usage-fetch dient nur der Erkennung. Es gibt an, dass OmniRoute weiß, wie die Nutzung für den Provider abgerufen werden kann; es aktiviert den Abruf nicht, ändert keine Kontingentsemantik und impliziert nicht, dass das Dashboard-Kontingent-Widget für den Provider aktiviert ist — dieses Widget wird separat durch USAGE_SUPPORTED_PROVIDERS gesteuert. Die maßgebliche Quelle ist USAGE_FETCHER_PROVIDERS in open-sse/services/usage/fetcherProviders.ts.

Diese Liste verwendet die Zeichenfolgen als Schlüssel, die der Nutzungs-Dispatcher akzeptiert, und enthält daher sowohl kanonische IDs als auch Aliase. Dadurch ist sie etwas länger als die Anzahl der mit Tags versehenen Provider: Einträge, die keine Chat-Provider in der Manifest-Registry sind (beispielsweise der Such-Provider firecrawl und der ACP-Provider amazon-q), haben keinen Manifest-Eintrag, der mit einem Tag versehen werden könnte.

usage-supported gibt an, ob die Nutzungsrouten des Servers und des Dashboards eine Verbindung für den Provider akzeptieren. Es spiegelt isSupportedUsageConnection() (src/lib/usage/providerLimits.ts) und supportsProviderQuota() (src/shared/utils/providerQuotaVisibility.ts) wider, die beide durch USAGE_SUPPORTED_PROVIDERS (open-sse/services/usage/supportedProviders.ts) gesteuert werden. Anders als usage-fetch wird es ausschließlich anhand der Provider-ID ausgegeben — die Laufzeitprüfung führt USAGE_SUPPORTED_PROVIDERS.includes(providerId) ohne Aliasauflösung aus, weshalb das Manifest dieselbe Regel beibehält. Die beiden Tags haben unterschiedliche Geltungsbereiche: 3 Provider tragen ausschließlich usage-fetch (opencode, opencode-zen, xai) und 1 trägt ausschließlich usage-supported (xiaomi-mimo-token-plan), sodass das eine nicht das andere impliziert.

Sidecar-Nutzung

Sidecars sollten sidecar.eligible als konservatives Kandidatensignal und nicht als uneingeschränkte Routing-Entscheidung behandeln. Das erste Importziel sollten Anbieter mit API-Schlüssel und statischem Endpunkt sein, die den Standard-Executor verwenden. Anbieter mit benutzerdefinierten Web-Executors, OAuth-/Sitzungsabläufen, dynamischen URL-Buildern oder Pool-Konfigurationen verbleiben auf dem TypeScript-Fallback-Pfad, bis ein Sidecar ein gleichwertiges Verhalten implementiert und die Telemetrie die Parität bestätigt.

Empfohlene Migrationsphasen:

1. Das Anbieter-Plugin-Manifest aus der TS-Registry generieren und validieren.
2. Bifrost oder CLIProxyAPI so erweitern, dass das Manifest für Anbieter mit API-Schlüssel und statischem Endpunkt importiert werden kann.
3. Geeignete Anbieter hinter OMNIROUTE_RELAY_BACKEND durch den Sidecar leiten, während der TS-Fallback aktiviert bleibt.
4. Anbieter erst dann hochstufen, wenn Erfolgsrate, p99-Latenz, Streaming-Verhalten und die Behandlung nicht unterstützter Parameter dem TS-Pfad entsprechen.
5. Native Sidecar-Plugins für benutzerdefinierte Executors schrittweise für jeweils eine Anbieterfamilie hinzufügen.

Warum Anbieter nicht direkt in Next eingebettet werden sollten

Das Next-Frontend sollte nicht für die Anbieterausführung zuständig sein. Es sollte die API-Grenze aufrufen. Das Backend kann dann entscheiden, ob der TypeScript-Executor, Bifrost, CLIProxyAPI oder ein zukünftiger nativer Sidecar verwendet wird. Dadurch bleiben Request-Signierung, Allowlist-Prüfungen, DB-Richtlinien und Fallback-Verhalten zentralisiert, bevor eine Übergabe an einen Sidecar erfolgt.