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

Provider Plugin Manifest (Ελληνικά)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇪🇸 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 ορίζει τη σύμβαση plugin παρόχου που είναι ασφαλής για JSON. Το open-sse/config/providerPluginManifestRegistry.ts συνδέει αυτήν τη σύμβαση με το τρέχον μητρώο παρόχων για sidecars όπως τα Bifrost, CLIProxyAPI ή έναν μελλοντικό δρομολογητή σε Go/Rust. Το μητρώο TypeScript παραμένει η πηγή αλήθειας, αλλά τα sidecars μπορούν να καταναλώνουν το manifest χωρίς να εισάγουν κώδικα executor, προεπιλογές OAuth, κεφαλίδες ή την κατάσταση περιβάλλοντος της διεργασίας.

Το ίδιο manifest είναι διαθέσιμο μέσω HTTP στη διεύθυνση GET /api/v1/provider-plugin-manifest για sidecars που εκτελούνται εκτός διεργασίας.

Το OmniRoute γνωστοποιεί αυτήν τη διεύθυνση URL στα Bifrost και CLIProxyAPI μέσω της κεφαλίδας αιτήματος X-OmniRoute-Provider-Manifest-Url. Ορίστε το OMNIROUTE_PROVIDER_MANIFEST_URL όταν το sidecar χρειάζεται μια δημόσια διεύθυνση URL ή μια διεύθυνση URL δικτύου container αντί για την τοπική προέλευση του αιτήματος.

Ανανέωση του Manifest

Το τελικό σημείο HTTP επιστρέφει Cache-Control: public, max-age=60 και ένα ισχυρό ETag. Ένα sidecar θα πρέπει να διατηρεί το τελευταίο επικυρωμένο manifest και να στέλνει το ETag του στο If-None-Match κατά την ανανέωση. Μια απόκριση 304 Not Modified δεν έχει σώμα· το sidecar διατηρεί το αποθηκευμένο στην κρυφή μνήμη manifest του. Εάν δεν υπάρχει επικυρωμένο manifest στην κρυφή μνήμη, το sidecar πρέπει να υποβάλει ένα αίτημα χωρίς συνθήκες αντί να αποδεχτεί μια απόκριση 304.

Στόχος

Η μεταφορά των μεταδεδομένων παρόχων προς μια σύμβαση plugin, ώστε η κρίσιμη διαδρομή των αιτημάτων να μπορεί τελικά να αναληφθεί από ένα sidecar χαμηλότερης καθυστέρησης, ενώ το OmniRoute διατηρεί τη διαδρομή TypeScript ως πύλη πολιτικής και εφεδρική λύση. Το manifest είναι προσθετικό: δεν αλλάζει από μόνο του τη δρομολόγηση αιτημάτων.

Σύμβαση

Το manifest περιέχει:

• αναγνωριστικό και ψευδώνυμο παρόχου
• μορφή upstream και όνομα executor
• τύπο ελέγχου ταυτότητας, κεφαλίδα ελέγχου ταυτότητας και προαιρετικό πρόθεμα ελέγχου ταυτότητας
• στατικά μεταδεδομένα τελικού σημείου
• καταλληλότητα για sidecar και σαφείς λόγους όταν ένας πάροχος πρέπει να παραμείνει στο TS
• μεταδεδομένα μοντέλου ασφαλή για JSON, όπως μήκος context, σημαίες vision/reasoning και μη υποστηριζόμενες παράμετροι
• ετικέτες δυνατοτήτων, συμπεριλαμβανομένων των apikey, oauth, custom-executor, passthrough-models, responses, sidecar-candidate, usage-fetch και usage-supported

Το manifest εξαιρεί σκόπιμα:

• μυστικά πελάτη OAuth και προεπιλεγμένες μυστικές τιμές
• επίλυση περιβάλλοντος κατά τον χρόνο εκτέλεσης
• κεφαλίδες αιτημάτων και δημόσια βοηθητικά εργαλεία διαπιστευτηρίων
• δυναμικούς δημιουργούς URL
• συναρτήσεις executor
• εσωτερικές λεπτομέρειες των session pool

Ετικέτες Δυνατοτήτων

Το capabilities είναι ένας ταξινομημένος πίνακας ετικετών που προκύπτουν από την καταχώριση του μητρώου. Οι υπεύθυνοι ενσωμάτωσης θα πρέπει να το αντιμετωπίζουν ως τη μηχανικώς αναγνώσιμη απάντηση στην ερώτηση «τι μπορεί να κάνει αυτός ο πάροχος», αντί να διαβάζουν ξανά τον πηγαίο κώδικα TypeScript.

Ετικέτα	Σημασία
apikey	Αποδέχεται κλειδί API (το authType είναι apikey ή optional).
oauth	Χρησιμοποιεί ροή OAuth ή session.
responses	Εκθέτει ένα βασικό URL για το OpenAI Responses API.
passthrough-models	Παρέχει μοντέλα απευθείας από το upstream αντί από στατικό κατάλογο.
custom-executor	Εκτελεί έναν μη προεπιλεγμένο executor, οπότε παραμένει στη διαδρομή TypeScript.
sidecar-candidate	Αντικατοπτρίζει το sidecar.eligible — ασφαλές να εξεταστεί για εισαγωγή σε sidecar.
usage-fetch	Διαθέτει συνδεδεμένο μηχανισμό ανάκτησης χρήσης ή quota (getUsageForProvider).
usage-supported	Το API χρήσης αποδέχεται αυτόν τον πάροχο (isSupportedUsageConnection).

Το usage-fetch προορίζεται μόνο για εντοπισμό. Αναφέρει ότι το OmniRoute γνωρίζει πώς να διαβάζει τη χρήση για τον πάροχο· δεν ενεργοποιεί την ανάκτηση, δεν αλλάζει τη σημασιολογία των quota και δεν υπονοεί ότι το widget quota του Dashboard είναι ενεργοποιημένο για τον πάροχο — αυτό το widget ελέγχεται ξεχωριστά από το USAGE_SUPPORTED_PROVIDERS. Η πηγή αλήθειας είναι το USAGE_FETCHER_PROVIDERS στο open-sse/services/usage/fetcherProviders.ts.

Αυτή η λίστα χρησιμοποιεί ως κλειδιά τις συμβολοσειρές που αποδέχεται ο dispatcher χρήσης, επομένως συνδυάζει κανονικά αναγνωριστικά με ψευδώνυμα και είναι ελαφρώς μεγαλύτερη από τον αριθμό των παρόχων με ετικέτες: οι καταχωρίσεις που δεν είναι πάροχοι chat στο μητρώο manifest (για παράδειγμα, ο πάροχος αναζήτησης firecrawl και ο πάροχος ACP amazon-q) δεν διαθέτουν καταχώριση manifest στην οποία να προστεθεί ετικέτα.

Το usage-supported απαντά εάν οι διαδρομές χρήσης του server και του Dashboard αποδέχονται μια σύνδεση για τον πάροχο. Αντικατοπτρίζει το isSupportedUsageConnection() (src/lib/usage/providerLimits.ts) και το supportsProviderQuota() (src/shared/utils/providerQuotaVisibility.ts), τα οποία ελέγχονται αμφότερα από το USAGE_SUPPORTED_PROVIDERS (open-sse/services/usage/supportedProviders.ts). Σε αντίθεση με το usage-fetch, εκπέμπεται μόνο για το αναγνωριστικό παρόχου — ο έλεγχος κατά τον χρόνο εκτέλεσης εκτελεί USAGE_SUPPORTED_PROVIDERS.includes(providerId) χωρίς επίλυση ψευδωνύμων, οπότε το manifest διατηρεί τον ίδιο κανόνα. Οι δύο ετικέτες έχουν διαφορετικά πεδία εφαρμογής: 3 πάροχοι φέρουν μόνο το usage-fetch (opencode, opencode-zen, xai) και 1 φέρει μόνο το usage-supported (xiaomi-mimo-token-plan), επομένως η μία δεν συνεπάγεται την άλλη.

Χρήση Sidecar

Τα sidecar θα πρέπει να αντιμετωπίζουν το sidecar.eligible ως ένα συντηρητικό σήμα υποψηφιότητας και όχι ως άνευ όρων απόφαση δρομολόγησης. Ο πρώτος στόχος εισαγωγής θα πρέπει να είναι πάροχοι με κλειδί API και στατικό endpoint που χρησιμοποιούν τον προεπιλεγμένο executor. Οι πάροχοι με προσαρμοσμένους web executors, ροές OAuth/συνεδρίας, δυναμικούς δημιουργούς URL ή διαμόρφωση pool παραμένουν στη διαδρομή εφεδρείας TypeScript έως ότου ένα sidecar υλοποιήσει ισοδύναμη συμπεριφορά και η τηλεμετρία αποδείξει την ισοδυναμία.

Προτεινόμενες φάσεις μετάβασης:

1. Δημιουργήστε και επικυρώστε το manifest των plugin παρόχων από το μητρώο TS.
2. Προσθέστε στο Bifrost ή στο CLIProxyAPI τη δυνατότητα εισαγωγής του manifest για παρόχους με κλειδί API/στατικό endpoint.
3. Δρομολογήστε τους επιλέξιμους παρόχους μέσω του sidecar πίσω από το OMNIROUTE_RELAY_BACKEND, διατηρώντας παράλληλα ενεργοποιημένη την εφεδρική διαδρομή TS.
4. Προωθήστε παρόχους μόνο όταν το ποσοστό επιτυχίας, η καθυστέρηση p99, η συμπεριφορά streaming και ο χειρισμός μη υποστηριζόμενων παραμέτρων αντιστοιχούν στη διαδρομή TS.
5. Προσθέστε εγγενή plugin του sidecar για προσαρμοσμένους executors, μία οικογένεια παρόχων κάθε φορά.

Γιατί να μην ενσωματωθούν οι πάροχοι απευθείας στο Next

Το frontend Next δεν θα πρέπει να αναλαμβάνει την εκτέλεση των παρόχων. Θα πρέπει να καλεί το όριο API. Στη συνέχεια, το backend μπορεί να αποφασίζει αν θα χρησιμοποιήσει τον executor TypeScript, το Bifrost, το CLIProxyAPI ή ένα μελλοντικό εγγενές sidecar. Έτσι, η υπογραφή αιτημάτων, οι έλεγχοι allowlist, η πολιτική της βάσης δεδομένων και η εφεδρική συμπεριφορά παραμένουν κεντρικά διαχειριζόμενα πριν από οποιαδήποτε παράδοση σε sidecar.