* 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.
18 KiB
Provider Plugin Manifest (ગુજરાતી)
🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇳🇬 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 JSON-સલામત પ્રોવાઇડર પ્લગઇન કોન્ટ્રાક્ટ નિર્ધારિત કરે છે. open-sse/config/providerPluginManifestRegistry.ts તે કોન્ટ્રાક્ટને Bifrost, CLIProxyAPI અથવા ભવિષ્યના Go/Rust રાઉટર જેવા સાઇડકાર્સ માટે વર્તમાન પ્રોવાઇડર રજિસ્ટ્રી સાથે જોડે છે. TypeScript રજિસ્ટ્રી સત્યનો અધિકૃત સ્રોત રહે છે, પરંતુ સાઇડકાર્સ executor કોડ, OAuth ડિફૉલ્ટ્સ, હેડર્સ અથવા પ્રોસેસ એન્વાયર્નમેન્ટ સ્ટેટ ઇમ્પોર્ટ કર્યા વિના મેનિફેસ્ટનો ઉપયોગ કરી શકે છે.
આ જ મેનિફેસ્ટ HTTP પર
GET /api/v1/provider-plugin-manifest ખાતે પણ ઉપલબ્ધ છે, જે આઉટ-ઓફ-પ્રોસેસ ચાલતા સાઇડકાર્સ માટે છે.
OmniRoute, X-OmniRoute-Provider-Manifest-Url રિક્વેસ્ટ હેડર દ્વારા Bifrost અને CLIProxyAPIને તે URLની જાણ કરે છે. જ્યારે સાઇડકારને સ્થાનિક રિક્વેસ્ટ ઓરિજિનને બદલે જાહેર અથવા કન્ટેનર નેટવર્ક URLની જરૂર હોય ત્યારે OMNIROUTE_PROVIDER_MANIFEST_URL સેટ કરો.
મેનિફેસ્ટ રિફ્રેશ કરવું
HTTP એન્ડપોઇન્ટ Cache-Control: public, max-age=60 અને મજબૂત ETag પરત કરે છે. સાઇડકારે છેલ્લું માન્ય કરાયેલ મેનિફેસ્ટ જાળવી રાખવું જોઈએ અને રિફ્રેશ કરતી વખતે તેનો ETag If-None-Matchમાં મોકલવો જોઈએ. 304 Not Modified રિસ્પોન્સમાં કોઈ બોડી હોતી નથી; સાઇડકાર તેનું કૅશ કરેલું મેનિફેસ્ટ જાળવી રાખે છે. જો કોઈ માન્ય કરેલું કૅશ્ડ મેનિફેસ્ટ ઉપલબ્ધ ન હોય, તો સાઇડકારે 304 સ્વીકારવાને બદલે બિનશરતી રિક્વેસ્ટ કરવી આવશ્યક છે.
લક્ષ્ય
પ્રોવાઇડર મેટાડેટાને પ્લગઇન કોન્ટ્રાક્ટ તરફ ખસેડવું, જેથી હૉટ રિક્વેસ્ટ પાથ આખરે ઓછી લેટન્સીવાળા સાઇડકારની માલિકીમાં આવી શકે, જ્યારે OmniRoute TypeScript રૂટને નીતિ ગેટ અને ફૉલબૅક તરીકે જાળવી રાખે. મેનિફેસ્ટ ઍડિટિવ છે: તે પોતે રિક્વેસ્ટ રાઉટિંગ બદલતું નથી.
કોન્ટ્રાક્ટ
મેનિફેસ્ટમાં આનો સમાવેશ થાય છે:
- પ્રોવાઇડર id અને ઉપનામ
- અપસ્ટ્રીમ ફૉર્મેટ અને executor નામ
- ઑથ પ્રકાર, ઑથ હેડર અને વૈકલ્પિક ઑથ પ્રીફિક્સ
- સ્ટેટિક એન્ડપોઇન્ટ મેટાડેટા
- સાઇડકાર પાત્રતા અને જ્યારે પ્રોવાઇડર TS પર જ રહેવો જોઈએ ત્યારે તેના સ્પષ્ટ કારણો
- JSON-સલામત મૉડલ મેટાડેટા, જેમ કે કૉન્ટેક્સ્ટ લંબાઈ, વિઝન/રીઝનિંગ ફ્લૅગ્સ અને અસમર્થિત પેરામ્સ
apikey,oauth,custom-executor,passthrough-models,responses,sidecar-candidate,usage-fetchઅનેusage-supportedસહિતના ક્ષમતા ટૅગ્સ
મેનિફેસ્ટ ઇરાદાપૂર્વક આનો સમાવેશ કરતું નથી:
- OAuth ક્લાયન્ટ સિક્રેટ્સ અને ડિફૉલ્ટ સિક્રેટ મૂલ્યો
- રનટાઇમ એન્વાયર્નમેન્ટ રિઝોલ્યુશન
- રિક્વેસ્ટ હેડર્સ અને જાહેર ક્રેડેન્શિયલ હેલ્પર્સ
- ડાયનેમિક URL બિલ્ડર્સ
- executor ફંક્શન્સ
- સેશન પૂલની આંતરિક વિગતો
ક્ષમતા ટૅગ્સ
capabilities એ રજિસ્ટ્રી એન્ટ્રી પરથી મેળવવામાં આવેલા ટૅગ્સની સૉર્ટ કરેલી ઍરે છે. ઇન્ટિગ્રેટર્સે TypeScript સ્રોતોને ફરી વાંચવાને બદલે, તેને "આ પ્રોવાઇડર શું કરી શકે છે" તેના મશીન-રીડેબલ જવાબ તરીકે ગણવું જોઈએ.
| ટૅગ | અર્થ |
|---|---|
apikey |
API કી સ્વીકારે છે (authType એ apikey અથવા optional છે). |
oauth |
OAuth અથવા સેશન ફ્લોનો ઉપયોગ કરે છે. |
responses |
OpenAI Responses-API બેઝ URL ઉપલબ્ધ કરાવે છે. |
passthrough-models |
સ્ટેટિક કૅટલૉગને બદલે સીધા અપસ્ટ્રીમમાંથી મૉડલ્સ સર્વ કરે છે. |
custom-executor |
બિન-ડિફૉલ્ટ executor ચલાવે છે, તેથી તે TypeScript પાથ પર રહે છે. |
sidecar-candidate |
sidecar.eligibleને પ્રતિબિંબિત કરે છે — સાઇડકાર ઇમ્પોર્ટ માટે વિચારવા યોગ્ય સુરક્ષિત વિકલ્પ. |
usage-fetch |
ઉપયોગ અથવા ક્વોટા ફેચર (getUsageForProvider) જોડાયેલો છે. |
usage-supported |
ઉપયોગ API આ પ્રોવાઇડરને સ્વીકારે છે (isSupportedUsageConnection). |
usage-fetch માત્ર ડિસ્કવરી માટે છે. તે જણાવે છે કે OmniRoute પ્રોવાઇડર માટેનો ઉપયોગ કેવી રીતે વાંચવો તે જાણે છે; તે ફેચિંગ સક્રિય કરતું નથી, ક્વોટાની સિમેન્ટિક્સ બદલતું નથી અથવા પ્રોવાઇડર માટે Dashboard ક્વોટા વિજેટ સક્ષમ છે એવું સૂચવતું નથી — તે વિજેટને અલગથી USAGE_SUPPORTED_PROVIDERS દ્વારા ગેટ કરવામાં આવે છે. સત્યનો અધિકૃત સ્રોત open-sse/services/usage/fetcherProviders.tsમાં રહેલું USAGE_FETCHER_PROVIDERS છે.
તે સૂચિ usage dispatcher દ્વારા સ્વીકારવામાં આવતી સ્ટ્રિંગ્સ દ્વારા કી કરવામાં આવી છે, તેથી તેમાં કૅનોનિકલ ids અને ઉપનામોનું મિશ્રણ છે અને તે ટૅગ કરેલા પ્રોવાઇડર્સની સંખ્યા કરતાં થોડી લાંબી છે: મેનિફેસ્ટ રજિસ્ટ્રીમાં ચૅટ પ્રોવાઇડર્સ ન હોય તેવી એન્ટ્રીઓ (ઉદાહરણ તરીકે firecrawl સર્ચ પ્રોવાઇડર અને amazon-q ACP પ્રોવાઇડર) પાસે ટૅગ કરવા માટે કોઈ મેનિફેસ્ટ એન્ટ્રી નથી.
usage-supported એ પ્રશ્નનો જવાબ આપે છે કે સર્વર અને Dashboard usage રૂટ્સ પ્રોવાઇડર માટેનું કનેક્શન સ્વીકારે છે કે નહીં. તે isSupportedUsageConnection() (src/lib/usage/providerLimits.ts) અને supportsProviderQuota() (src/shared/utils/providerQuotaVisibility.ts)ને પ્રતિબિંબિત કરે છે, અને બંનેને USAGE_SUPPORTED_PROVIDERS (open-sse/services/usage/supportedProviders.ts) દ્વારા ગેટ કરવામાં આવે છે. usage-fetchથી વિપરીત, તે ફક્ત પ્રોવાઇડર id પર જ ઉત્સર્જિત થાય છે — રનટાઇમ ગાર્ડ કોઈ ઉપનામ રિઝોલ્યુશન વિના USAGE_SUPPORTED_PROVIDERS.includes(providerId) કરે છે, તેથી મેનિફેસ્ટ પણ એ જ નિયમ જાળવે છે. બંને ટૅગ્સની સીમાઓ અલગ છે: 3 પ્રોવાઇડર્સ પાસે ફક્ત usage-fetch (opencode, opencode-zen, xai) છે અને 1 પાસે ફક્ત usage-supported (xiaomi-mimo-token-plan) છે, તેથી એક ટૅગ બીજાનો અર્થ સૂચવતો નથી.
Sidecar નો ઉપયોગ
Sidecar એ sidecar.eligible ને બિનશરતી રૂટિંગ નિર્ણય તરીકે નહીં, પરંતુ સાવચેતીપૂર્વકના ઉમેદવાર સંકેત તરીકે ગણવું જોઈએ. આયાત માટેનું પ્રથમ લક્ષ્ય ડિફૉલ્ટ executor નો ઉપયોગ કરતા API-key, static-endpoint providers હોવા જોઈએ. કસ્ટમ web executors, OAuth/session flows, dynamic URL builders અથવા pool config ધરાવતા providers, જ્યાં સુધી કોઈ sidecar સમકક્ષ વર્તન અમલમાં ન મૂકે અને telemetry સમાનતા સાબિત ન કરે ત્યાં સુધી, TypeScript fallback પાથ પર રહેવા જોઈએ.
સૂચિત માઇગ્રેશન તબક્કાઓ:
- TS registry માંથી provider plugin manifest જનરેટ કરો અને તેને માન્ય કરો.
- API-key/static providers માટે manifest આયાત કરવાનું Bifrost અથવા CLIProxyAPI ને શીખવો.
- TS fallback સક્ષમ રાખીને
OMNIROUTE_RELAY_BACKENDપાછળ sidecar મારફતે પાત્ર providers ને રૂટ કરો. - સફળતા દર, p99 latency, streaming વર્તન અને unsupported-param હેન્ડલિંગ TS પાથ સાથે મેળ ખાય ત્યારે જ providers ને પ્રમોટ કરો.
- એક સમયે એક provider family માટે custom executors માટે sidecar-native plugins ઉમેરો.
Providers ને સીધા Next માં શા માટે એમ્બેડ ન કરવા
Next frontend એ provider execution ની જવાબદારી લેવી જોઈએ નહીં. તેણે API boundary ને કૉલ કરવું જોઈએ. ત્યારબાદ backend નક્કી કરી શકે છે કે TypeScript executor, Bifrost, CLIProxyAPI અથવા ભવિષ્યના native sidecar નો ઉપયોગ કરવો. આ કોઈપણ sidecar handoff પહેલાં request signing, allowlist checks, DB policy અને fallback વર્તનને કેન્દ્રીકૃત રાખે છે.