8feea123bb
* feat(docs): mirror every docs/ page in all 65 locales Extends the documentation mirrors from the 22-page core set (#13940) to every Markdown page under docs/: 152 sources x 65 locales = 9,880 mirrors (6,208 new), language bars rewritten for the full locale list, state adopted so the blocking drift gate now covers all 152 pages. run-translation.mjs: an oversized block made only of table rows or list items (PROVIDER_REFERENCE.md 244-row table, FREE_TIERS.md 71-item list) is cut at item boundaries and rejoined without a blank line — the single 16-40 KB request outlived the backend socket for verbose scripts. 48 older mirrors whose tables had lost rows were retranslated with --force. * docs(i18n): refresh mirrors for the sources the base changed since the branch cut Section-level retranslation of the 29 docs (and README.md) whose source or mirrors moved on release/v3.8.51 during the run, then state adoption; the drift gate is green again on the merged tree.
12 KiB
Provider Plugin Manifest (Suomi)
🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇷 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 määrittelee JSON-turvallisen palveluntarjoajalisäosan sopimuksen. open-sse/config/providerPluginManifestRegistry.ts sitoo kyseisen sopimuksen nykyiseen palveluntarjoajarekisteriin Bifrostin, CLIProxyAPI:n tai tulevan Go-/Rust-reitittimen kaltaisia sivuprosesseja varten. TypeScript-rekisteri säilyy ensisijaisena tietolähteenä, mutta sivuprosessit voivat käyttää manifestia tuomatta suorittajakoodia, OAuth-oletuksia, otsakkeita tai prosessin ympäristötilaa.
Sama manifesti on saatavilla HTTP:n kautta osoitteessa
GET /api/v1/provider-plugin-manifest prosessin ulkopuolella suoritettavia sivuprosesseja varten.
OmniRoute ilmoittaa kyseisen URL-osoitteen Bifrostille ja CLIProxyAPI:lle
X-OmniRoute-Provider-Manifest-Url-pyyntöotsakkeella. Aseta
OMNIROUTE_PROVIDER_MANIFEST_URL, kun sivuprosessi tarvitsee paikallisen pyynnön alkuperän sijaan julkisen tai konttiverkon URL-osoitteen.
Manifestin päivittäminen
HTTP-päätepiste palauttaa otsakkeen Cache-Control: public, max-age=60 ja vahvan
ETag-tunnisteen. Sivuprosessin tulee säilyttää viimeisin validoitu manifesti ja lähettää sen ETag-arvo
If-None-Match-otsakkeessa päivityksen yhteydessä. 304 Not Modified -vastauksessa ei ole runkoa;
sivuprosessi säilyttää välimuistissa olevan manifestinsa. Jos validoitua välimuistissa olevaa manifestia ei ole,
sivuprosessin on tehtävä ehdoton pyyntö sen sijaan, että se hyväksyisi 304-vastauksen.
Tavoite
Siirtää palveluntarjoajien metatietoja kohti lisäosasopimusta, jotta pyyntöjen suorituspolku voidaan lopulta siirtää pienemmän viiveen sivuprosessin vastuulle samalla, kun OmniRoute säilyttää TypeScript-reitin käytäntöporttina ja vararatkaisuna. Manifesti on täydentävä: se ei itsessään muuta pyyntöjen reititystä.
Sopimus
Manifesti sisältää seuraavat tiedot:
- palveluntarjoajan tunniste ja alias
- ylävirran muoto ja suorittajan nimi
- todennustyyppi, todennusotsake ja valinnainen todennusetuliite
- päätepisteen staattiset metatiedot
- soveltuvuus sivuprosessille sekä nimenomaiset syyt sille, miksi palveluntarjoajan tulisi pysyä TS-polulla
- JSON-turvalliset mallin metatiedot, kuten kontekstin pituus, näkö-/päättelyominaisuuksien liput ja ei-tuetut parametrit
- ominaisuustunnisteet, mukaan lukien
apikey,oauth,custom-executor,passthrough-models,responses,sidecar-candidate,usage-fetchjausage-supported
Manifesti jättää tarkoituksella pois seuraavat:
- OAuth-asiakassalaisuudet ja salaisuuksien oletusarvot
- suoritusympäristön dynaaminen selvitys
- pyyntöotsakkeet ja julkisten tunnistetietojen apufunktiot
- dynaamiset URL-rakentajat
- suorittajafunktiot
- istuntopoolin sisäiset tiedot
Ominaisuustunnisteet
capabilities on rekisterimerkinnästä johdettu järjestetty tunnistetaulukko. Integroijien
tulisi käsitellä sitä koneellisesti luettavana vastauksena kysymykseen ”mitä tämä palveluntarjoaja osaa tehdä” sen sijaan,
että TypeScript-lähteitä luettaisiin uudelleen.
| Tunniste | Merkitys |
|---|---|
apikey |
Hyväksyy API-avaimen (authType on apikey tai optional). |
oauth |
Käyttää OAuth- tai istuntoprosessia. |
responses |
Tarjoaa OpenAI Responses API:n perus-URL-osoitteen. |
passthrough-models |
Tarjoaa mallit suoraan ylävirrasta staattisen luettelon sijaan. |
custom-executor |
Suorittaa muun kuin oletussuorittajan, joten se pysyy TypeScript-polulla. |
sidecar-candidate |
Vastaa arvoa sidecar.eligible — turvallinen harkittavaksi sivuprosessiin tuontia varten. |
usage-fetch |
Käyttö- tai kiintiöhakija on kytketty (getUsageForProvider). |
usage-supported |
Käyttö-API hyväksyy tämän palveluntarjoajan (isSupportedUsageConnection). |
usage-fetch on tarkoitettu vain tunnistamiseen. Se ilmaisee, että OmniRoute osaa lukea palveluntarjoajan
käyttötiedot; se ei aktivoi hakua, muuta kiintiöiden semantiikkaa eikä tarkoita, että
Dashboardin kiintiöwidget olisi käytössä palveluntarjoajalle — kyseistä widgetiä ohjataan erikseen
USAGE_SUPPORTED_PROVIDERS-arvolla. Ensisijainen tietolähde on USAGE_FETCHER_PROVIDERS tiedostossa
open-sse/services/usage/fetcherProviders.ts.
Luettelo on avaimettu käyttötilanteiden välittäjän hyväksymillä merkkijonoilla, joten siinä on sekä kanonisia tunnisteita
että aliaksia, ja se on hieman pidempi kuin tunnisteen saaneiden palveluntarjoajien määrä: merkinnöillä, jotka eivät ole
manifestirekisterin keskustelupalveluntarjoajia (esimerkiksi firecrawl-hakupalveluntarjoaja
ja amazon-q-ACP-palveluntarjoaja), ei ole manifestimerkintää, johon tunniste voitaisiin liittää.
usage-supported ilmaisee, hyväksyvätkö palvelimen ja Dashboardin käyttöreitit yhteyden
kyseiselle palveluntarjoajalle. Se vastaa funktioita isSupportedUsageConnection() (src/lib/usage/providerLimits.ts)
ja supportsProviderQuota() (src/shared/utils/providerQuotaVisibility.ts), joita molempia ohjaa
USAGE_SUPPORTED_PROVIDERS (open-sse/services/usage/supportedProviders.ts). Toisin kuin
usage-fetch, se lisätään vain palveluntarjoajan tunnisteen perusteella — suorituksenaikainen tarkistus tekee kutsun
USAGE_SUPPORTED_PROVIDERS.includes(providerId) ilman aliasten selvitystä, joten manifesti
noudattaa samaa sääntöä. Kahdella tunnisteella on eri kattavuusalueet: 3 palveluntarjoajalla on vain
usage-fetch (opencode, opencode-zen, xai) ja yhdellä vain
usage-supported (xiaomi-mimo-token-plan), joten kumpikaan ei tarkoita automaattisesti toista.
Sidecarin käyttö
Sidecarien tulee käsitellä sidecar.eligible-arvoa konservatiivisena ehdokassignaalina, ei ehdottomana reitityspäätöksenä. Ensimmäisenä tuonnin kohteena tulisi olla API-avainta ja staattista päätepistettä käyttävät palveluntarjoajat, jotka käyttävät oletussuoritinta. Mukautettuja verkkosuorittimia, OAuth-/istuntovirtoja, dynaamisia URL-osoitteiden muodostimia tai poolimäärityksiä käyttävät palveluntarjoajat pysyvät TypeScript-varapolulla, kunnes sidecar toteuttaa vastaavan toiminnan ja telemetria osoittaa vastaavuuden.
Ehdotetut siirtymävaiheet:
- Luo palveluntarjoajalaajennusten manifesti TS-rekisteristä ja validoi se.
- Opeta Bifrost tai CLIProxyAPI tuomaan API-avainta ja staattista päätepistettä käyttävien palveluntarjoajien manifesti.
- Reititä ehdot täyttävät palveluntarjoajat sidecarin kautta
OMNIROUTE_RELAY_BACKEND-asetuksen takana ja pidä samalla TS-varapolku käytössä. - Ota palveluntarjoajia varsinaisesti käyttöön vain, kun onnistumisaste, p99-viive, suoratoiston toiminta ja ei-tuettujen parametrien käsittely vastaavat TS-polun toimintaa.
- Lisää mukautetuille suorittimille sidecar-natiiveja laajennuksia yksi palveluntarjoajaperhe kerrallaan.
Miksi palveluntarjoajia ei pidä upottaa suoraan Nextiin
Next-käyttöliittymän ei pidä vastata palveluntarjoajien suorituksesta. Sen tulee kutsua API-rajapintaa. Taustajärjestelmä voi sitten päättää, käytetäänkö TypeScript-suoritinta, Bifrostia, CLIProxyAPIa vai tulevaa natiivia sidecaria. Näin pyyntöjen allekirjoitus, sallittujen kohteiden luettelon tarkistukset, tietokantakäytännöt ja varapolun toiminta pysyvät keskitettyinä ennen pyyntöjen siirtämistä sidecarille.