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

Provider Plugin Manifest (தமிழ்)

🌐 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 · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

---

open-sse/config/providerPluginManifest.ts JSON-பாதுகாப்பான provider plugin ஒப்பந்தத்தை வரையறுக்கிறது. open-sse/config/providerPluginManifestRegistry.ts அந்த ஒப்பந்தத்தை Bifrost, CLIProxyAPI அல்லது எதிர்கால Go/Rust router போன்ற sidecar-களுக்கான தற்போதைய provider registry-யுடன் இணைக்கிறது. TypeScript registry தொடர்ந்து உண்மையின் மூல ஆதாரமாக இருக்கும்; ஆனால் executor code, OAuth இயல்புநிலைகள், header-கள் அல்லது process environment நிலையை import செய்யாமல் sidecar-கள் manifest-ஐப் பயன்படுத்தலாம்.

process-க்கு வெளியே இயங்கும் sidecar-களுக்காக இதே manifest, GET /api/v1/provider-plugin-manifest என்ற HTTP முகவரியிலும் கிடைக்கிறது.

OmniRoute, X-OmniRoute-Provider-Manifest-Url request header வழியாக அந்த URL-ஐ Bifrost மற்றும் CLIProxyAPI-க்கு அறிவிக்கிறது. உள்ளூர் request origin-க்குப் பதிலாக sidecar-க்கு public அல்லது container network URL தேவைப்படும்போது OMNIROUTE_PROVIDER_MANIFEST_URL-ஐ அமைக்கவும்.

Manifest-ஐப் புதுப்பித்தல்

HTTP endpoint, Cache-Control: public, max-age=60 மற்றும் வலுவான ETag-ஐ வழங்குகிறது. ஒரு sidecar, கடைசியாகச் சரிபார்க்கப்பட்ட manifest-ஐத் தக்கவைத்துக்கொண்டு, புதுப்பிக்கும்போது அதன் ETag-ஐ If-None-Match-இல் அனுப்ப வேண்டும். 304 Not Modified response-இல் body இருக்காது; sidecar தனது cache செய்யப்பட்ட manifest-ஐத் தொடர்ந்து வைத்திருக்கும். சரிபார்க்கப்பட்ட cache manifest எதுவும் இல்லை என்றால், 304-ஐ ஏற்றுக்கொள்வதற்குப் பதிலாக sidecar நிபந்தனையற்ற request-ஐ அனுப்ப வேண்டும்.

இலக்கு

Provider metadata-வை plugin ஒப்பந்தத்தை நோக்கி நகர்த்துவது இதன் இலக்காகும்; இதனால், எதிர்காலத்தில் hot request path-ஐ குறைந்த latency கொண்ட sidecar நிர்வகிக்க முடியும், அதே நேரத்தில் OmniRoute TypeScript route-ஐ policy gate மற்றும் fallback ஆக வைத்திருக்க முடியும். Manifest சேர்க்கைத் தன்மையுடையது: அது தானாகவே request routing-ஐ மாற்றாது.

ஒப்பந்தம்

Manifest பின்வருவனவற்றைக் கொண்டுள்ளது:

• provider id மற்றும் alias
• upstream format மற்றும் executor பெயர்
• auth type, auth header மற்றும் விருப்பத்திற்குரிய auth prefix
• நிலையான endpoint metadata
• sidecar தகுதி மற்றும் ஒரு provider TS-இல் நீடிக்க வேண்டியபோது அதற்கான வெளிப்படையான காரணங்கள்
• context length, vision/reasoning flag-கள் மற்றும் ஆதரிக்கப்படாத param-கள் போன்ற JSON-பாதுகாப்பான model metadata
• apikey, oauth, custom-executor, passthrough-models, responses, sidecar-candidate, usage-fetch மற்றும் usage-supported உள்ளிட்ட capability tag-கள்

Manifest திட்டமிட்டே பின்வருவனவற்றை விலக்குகிறது:

• OAuth client secret-கள் மற்றும் இயல்புநிலை secret மதிப்புகள்
• runtime environment resolution
• request header-கள் மற்றும் public credential helper-கள்
• dynamic URL builder-கள்
• executor function-கள்
• session pool-இன் உள் விவரங்கள்

Capability Tag-கள்

capabilities என்பது registry entry-யிலிருந்து பெறப்பட்டு வரிசைப்படுத்தப்பட்ட tag-களின் array ஆகும். Integrator-கள் TypeScript source-களை மீண்டும் படிப்பதற்குப் பதிலாக, "இந்த provider என்ன செய்ய முடியும்" என்பதற்கான இயந்திரம் படிக்கக்கூடிய பதிலாக இதைக் கருத வேண்டும்.

Tag	பொருள்
apikey	API key-ஐ ஏற்கிறது (authType என்பது apikey அல்லது optional).
oauth	OAuth அல்லது session flow-ஐப் பயன்படுத்துகிறது.
responses	OpenAI Responses-API base URL-ஐ வெளிப்படுத்துகிறது.
passthrough-models	நிலையான catalog-க்குப் பதிலாக upstream-இலிருந்து நேரடியாக model-களை வழங்குகிறது.
custom-executor	இயல்புநிலையற்ற executor-ஐ இயக்குவதால், அது TypeScript path-இல் நீடிக்கிறது.
sidecar-candidate	sidecar.eligible-ஐப் பிரதிபலிக்கிறது — sidecar import-க்குப் பரிசீலிக்க பாதுகாப்பானது.
usage-fetch	இணைக்கப்பட்ட usage அல்லது quota fetcher (getUsageForProvider) உள்ளது.
usage-supported	Usage API இந்த provider-ஐ ஏற்கிறது (isSupportedUsageConnection).

usage-fetch கண்டறிதலுக்காக மட்டுமே உள்ளது. Provider-ன் usage-ஐ எவ்வாறு படிப்பது என்பது OmniRoute-க்குத் தெரியும் என்பதை இது தெரிவிக்கிறது; இது fetching-ஐச் செயல்படுத்தாது, quota semantics-ஐ மாற்றாது அல்லது அந்த provider-க்கு Dashboard quota widget இயக்கப்பட்டுள்ளது என்பதைக் குறிக்காது — அந்த widget தனியாக USAGE_SUPPORTED_PROVIDERS மூலம் கட்டுப்படுத்தப்படுகிறது. உண்மையின் மூல ஆதாரம் open-sse/services/usage/fetcherProviders.ts-இல் உள்ள USAGE_FETCHER_PROVIDERS ஆகும்.

அந்தப் பட்டியல் usage dispatcher ஏற்கும் string-களைக் key-களாகக் கொண்டிருப்பதால், canonical id-கள் மற்றும் alias-கள் இரண்டையும் கலந்து கொண்டுள்ளது; ஆகவே tag செய்யப்பட்ட provider-களின் எண்ணிக்கையைவிட இது சற்றுப் பெரிதாக உள்ளது: manifest registry-இல் chat provider-களாக இல்லாத entry-களுக்கு (எடுத்துக்காட்டாக firecrawl search provider மற்றும் amazon-q ACP provider) tag செய்வதற்கான manifest entry இல்லை.

usage-supported என்பது server மற்றும் Dashboard usage route-கள் அந்த provider-க்கான connection-ஐ ஏற்கின்றனவா என்பதற்குப் பதிலளிக்கிறது. இது isSupportedUsageConnection() (src/lib/usage/providerLimits.ts) மற்றும் supportsProviderQuota() (src/shared/utils/providerQuotaVisibility.ts) ஆகியவற்றைப் பிரதிபலிக்கிறது; இவை இரண்டும் USAGE_SUPPORTED_PROVIDERS (open-sse/services/usage/supportedProviders.ts) மூலம் கட்டுப்படுத்தப்படுகின்றன. usage-fetch போலல்லாமல், இது provider id-இல் மட்டுமே வெளியிடப்படுகிறது — runtime guard, alias resolution எதுவுமின்றி USAGE_SUPPORTED_PROVIDERS.includes(providerId)-ஐச் செய்கிறது; எனவே manifest அதே விதியைத் தக்கவைக்கிறது. இந்த இரு tag-களுக்கும் வேறுபட்ட வரம்புகள் உள்ளன: 3 provider-கள் usage-fetch மட்டும் கொண்டுள்ளன (opencode, opencode-zen, xai), மேலும் 1 provider usage-supported மட்டும் கொண்டுள்ளது (xiaomi-mimo-token-plan); எனவே ஒன்று மற்றொன்றை உட்குறிக்காது.

Sidecar பயன்பாடு

Sidecar-கள் sidecar.eligible-ஐ நிபந்தனையற்ற வழிமாற்ற முடிவாகக் கருதாமல், ஒரு பழமைவாத வேட்பாளர் சமிக்ஞையாகக் கருத வேண்டும். இயல்புநிலை executor-ஐப் பயன்படுத்தும் API-key, static-endpoint provider-களே முதல் import இலக்காக இருக்க வேண்டும். தனிப்பயன் web executor-கள், OAuth/session ஓட்டங்கள், dynamic URL builder-கள் அல்லது pool config கொண்ட provider-கள், ஒரு sidecar சமமான நடத்தையைச் செயல்படுத்தி, telemetry சமநிலையை நிரூபிக்கும் வரை TypeScript fallback பாதையிலேயே இருக்க வேண்டும்.

பரிந்துரைக்கப்படும் இடமாற்றக் கட்டங்கள்:

1. TS registry-இலிருந்து provider plugin manifest-ஐ உருவாக்கி சரிபார்க்கவும்.
2. API-key/static provider-களுக்கான manifest-ஐ import செய்ய Bifrost அல்லது CLIProxyAPI-க்குக் கற்பிக்கவும்.
3. TS fallback-ஐ இயக்கப்பட்ட நிலையிலேயே வைத்துக்கொண்டு, தகுதியுள்ள provider-களை OMNIROUTE_RELAY_BACKEND-க்குப் பின்னால் உள்ள sidecar வழியாக வழிமாற்றவும்.
4. வெற்றி விகிதம், p99 தாமதம், streaming நடத்தை மற்றும் ஆதரிக்கப்படாத parameter-களைக் கையாளுதல் ஆகியவை TS பாதையுடன் பொருந்தும்போது மட்டுமே provider-களை மேம்படுத்தவும்.
5. தனிப்பயன் executor-களுக்கான sidecar-native plugin-களை, ஒரு நேரத்தில் ஒரு provider குடும்பத்திற்குச் சேர்க்கவும்.

Provider-களை நேரடியாக Next-இல் ஏன் உட்பொதிக்கக் கூடாது

Next frontend, provider செயலாக்கத்திற்குப் பொறுப்பேற்கக் கூடாது. அது API எல்லையை அழைக்க வேண்டும். பின்னர் backend, TypeScript executor, Bifrost, CLIProxyAPI அல்லது எதிர்கால native sidecar ஆகியவற்றில் எதைப் பயன்படுத்துவது என்பதை முடிவு செய்யலாம். இதனால், எந்தவொரு sidecar ஒப்படைப்பிற்கும் முன்பாக request signing, allowlist சரிபார்ப்புகள், DB கொள்கை மற்றும் fallback நடத்தை ஆகியவை மையப்படுத்தப்பட்டவையாக இருக்கும்.