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

Provider Plugin Manifest (Slovenčina)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 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 · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

---

open-sse/config/providerPluginManifest.ts definuje kontrakt pluginu poskytovateľa bezpečný pre JSON. open-sse/config/providerPluginManifestRegistry.ts prepája tento kontrakt s aktuálnym registrom poskytovateľov pre sidecary, ako sú Bifrost, CLIProxyAPI alebo budúci router v jazyku Go/Rust. Register TypeScriptu zostáva zdrojom pravdy, no sidecary môžu manifest používať bez importovania kódu exekútora, predvolených nastavení OAuth, hlavičiek alebo stavu prostredia procesu.

Rovnaký manifest je dostupný cez HTTP na adrese GET /api/v1/provider-plugin-manifest pre sidecary, ktoré bežia mimo procesu.

OmniRoute oznamuje túto URL systémom Bifrost a CLIProxyAPI prostredníctvom hlavičky požiadavky X-OmniRoute-Provider-Manifest-Url. Nastavte OMNIROUTE_PROVIDER_MANIFEST_URL, keď sidecar potrebuje namiesto lokálneho pôvodu požiadavky verejnú URL alebo URL kontajnerovej siete.

Obnovenie manifestu

Koncový bod HTTP vracia Cache-Control: public, max-age=60 a silný ETag. Sidecar by si mal ponechať posledný overený manifest a pri obnovení odoslať jeho ETag v hlavičke If-None-Match. Odpoveď 304 Not Modified nemá telo; sidecar si ponechá manifest vo vyrovnávacej pamäti. Ak neexistuje žiadny overený manifest vo vyrovnávacej pamäti, sidecar musí namiesto prijatia odpovede 304 odoslať nepodmienenú požiadavku.

Cieľ

Posunúť metadáta poskytovateľov smerom ku kontraktu pluginu, aby mohla byť kritická cesta požiadavky napokon spravovaná sidecarom s nižšou latenciou, zatiaľ čo OmniRoute si ponechá trasu TypeScriptu ako bránu pravidiel a záložné riešenie. Manifest je aditívny: sám osebe nemení smerovanie požiadaviek.

Kontrakt

Manifest obsahuje:

• id a alias poskytovateľa
• formát upstreamu a názov exekútora
• typ autentifikácie, autentifikačnú hlavičku a voliteľný prefix autentifikácie
• statické metadáta koncového bodu
• oprávnenosť pre sidecar a explicitné dôvody, prečo by mal poskytovateľ zostať na TS
• metadáta modelu bezpečné pre JSON, ako sú dĺžka kontextu, príznaky spracovania obrazu/usudzovania a nepodporované parametre
• značky schopností vrátane apikey, oauth, custom-executor, passthrough-models, responses, sidecar-candidate, usage-fetch a usage-supported

Manifest zámerne vylučuje:

• klientske tajomstvá OAuth a predvolené tajné hodnoty
• vyhodnocovanie prostredia za behu
• hlavičky požiadaviek a verejné pomocné funkcie pre prihlasovacie údaje
• dynamické zostavovače URL
• funkcie exekútora
• interné mechanizmy fondu relácií

Značky schopností

capabilities je zoradené pole značiek odvodených od položky registra. Integrátori by ho mali považovať za strojovo čitateľnú odpoveď na otázku „čo tento poskytovateľ dokáže“ namiesto opätovného čítania zdrojov TypeScriptu.

Značka	Význam
apikey	Prijíma kľúč API (authType je apikey alebo optional).
oauth	Používa tok OAuth alebo relácie.
responses	Sprístupňuje základnú URL rozhrania OpenAI Responses API.
passthrough-models	Poskytuje modely priamo z upstreamu namiesto statického katalógu.
custom-executor	Spúšťa nepredvolený exekútor, takže zostáva na ceste TypeScriptu.
sidecar-candidate	Zrkadlí sidecar.eligible — možno ho bezpečne zvážiť na import do sidecaru.
usage-fetch	Má zapojený mechanizmus načítania využitia alebo kvóty (getUsageForProvider).
usage-supported	Rozhranie API využitia prijíma tohto poskytovateľa (isSupportedUsageConnection).

usage-fetch slúži iba na zisťovanie. Informuje, že OmniRoute vie načítať využitie pre poskytovateľa; neaktivuje načítavanie, nemení sémantiku kvót ani nenaznačuje, že je widget kvóty na Dashboarde pre poskytovateľa povolený — tento widget je samostatne riadený pomocou USAGE_SUPPORTED_PROVIDERS. Zdrojom pravdy je USAGE_FETCHER_PROVIDERS v open-sse/services/usage/fetcherProviders.ts.

Tento zoznam je indexovaný reťazcami, ktoré prijíma dispečer využitia, takže kombinuje kanonické id s aliasmi a je o niečo dlhší než počet označených poskytovateľov: položky, ktoré nie sú poskytovateľmi chatu v registri manifestu (napríklad poskytovateľ vyhľadávania firecrawl a poskytovateľ ACP amazon-q), nemajú položku manifestu, ktorú by bolo možné označiť.

usage-supported odpovedá na otázku, či serverové trasy a trasy využitia na Dashboarde prijímajú pripojenie pre daného poskytovateľa. Zrkadlí isSupportedUsageConnection() (src/lib/usage/providerLimits.ts) a supportsProviderQuota() (src/shared/utils/providerQuotaVisibility.ts), pričom obe sú riadené pomocou USAGE_SUPPORTED_PROVIDERS (open-sse/services/usage/supportedProviders.ts). Na rozdiel od usage-fetch sa značka generuje iba na základe id poskytovateľa — kontrola za behu vykonáva USAGE_SUPPORTED_PROVIDERS.includes(providerId) bez vyhodnocovania aliasov, takže manifest zachováva rovnaké pravidlo. Tieto dve značky majú odlišný rozsah: 3 poskytovatelia majú iba usage-fetch (opencode, opencode-zen, xai) a 1 má iba usage-supported (xiaomi-mimo-token-plan), takže jedna neimplikuje druhú.

Používanie sidecarov

Sidecary by mali považovať sidecar.eligible za konzervatívny signál kandidáta, nie za bezpodmienečné rozhodnutie o smerovaní. Prvým cieľom importu by mali byť poskytovatelia používajúci API kľúč, statický koncový bod a predvolený vykonávací modul. Poskytovatelia s vlastnými webovými vykonávacími modulmi, tokmi OAuth/relácií, dynamickými generátormi URL alebo konfiguráciou poolu zostanú na záložnej ceste TypeScriptu, kým sidecar neimplementuje ekvivalentné správanie a telemetria nepotvrdí zhodu.

Navrhované fázy migrácie:

1. Vygenerovať a overiť manifest pluginov poskytovateľov z registra TS.
2. Naučiť Bifrost alebo CLIProxyAPI importovať manifest pre poskytovateľov používajúcich API kľúč a statický koncový bod.
3. Smerovať oprávnených poskytovateľov cez sidecar riadený premennou OMNIROUTE_RELAY_BACKEND, pričom záložná cesta TS zostane povolená.
4. Povýšiť poskytovateľov až vtedy, keď sa úspešnosť, latencia p99, správanie streamovania a spracovanie nepodporovaných parametrov zhodujú s cestou TS.
5. Pridávať natívne pluginy sidecaru pre vlastné vykonávacie moduly postupne, po jednej rodine poskytovateľov.

Prečo nevkladať poskytovateľov priamo do Nextu

Frontend Next by nemal zabezpečovať vykonávanie požiadaviek poskytovateľov. Mal by volať rozhranie API. Backend potom môže rozhodnúť, či použije vykonávací modul TypeScriptu, Bifrost, CLIProxyAPI alebo budúci natívny sidecar. Týmto spôsobom zostanú podpisovanie požiadaviek, kontroly zoznamu povolených položiek, zásady databázy a záložné správanie centralizované pred každým odovzdaním sidecaru.