Catalogues de modèles

Utilisez ceci lorsque la liste de modèles est vide ou que vous devez contrôler les modèles disponibles. Un modèle montré dans votre pool est suffisant pour votre première demande.

SubLane Les listes d'autorisations de pool restent la politique de l'administrateur; la découverte ne les remplace jamais. Un modèle rapporté décrit le support en amont, pas le quota restant ou un test de génération réussi.

Exemple de catalogue de modèles avec des ID de modèles synthétiques :

Synchronisation et stockage

Importation de compte, OAuth La réautorisation efface l'ancien catalogue même si le jeton soumis est inchangé. Les comptes existants découvrent paresseusement quand leur catalogue ou pool est lu, ou avant leur première demande de modèle. Vérifier la connexion et Actualiser les modèles partager la même opération de découverte.

Le schéma consolidé stocke une limited JSON snapshot et révision du cycle de vie sur chaque compte. Un snapshot contient des ID de modèle natif triés, dédoublement, le dernier temps d'observation réussi et un marqueur source de découverte. Codex version client et révision de l'adaptateur; mise à jour que le contrat rafraîchit les snapshots plus anciens ou non marqués, quel que soit leur âge. Chaque compte est limité à 512 modèles ID de 128 caractères ASCII au maximum; aucune instruction, manifestes ou identifiants en amont ne sont stockés. Un snapshot null signifie un support inconnu.

Les snapshots sont frais pendant 15 minutes. Une lecture stale retourne la valeur enregistrée et commence un retouche de fond partagé. Il n'y a pas de sondage périodique en amont pendant le ralenti. Les requêtes froides se joignent également à un rafraîchissement lorsque le marqueur source de découverte change. Un rafraîchissement de mise à jour échoué peut conserver des capacités connues auparavant, mais un catalogue obsolète ne peut pas prouver qu'un modèle non inscrit n'est pas supporté.

Au maximum deux découvertes de modèles s’exécutent simultanément, dans la capacité de l’espace de travail : 128 opérations par défaut, configurable par SUBLANE_GATEWAY_CAPACITY. Les lecteurs d’un même compte et d’une même révision partagent l’opération, avec le contexte du processus et un délai de 45 secondes. La déconnexion du navigateur n’annule que son attente. La découverte initiale dispose aussi de 45 secondes au total. L’arrêt annule et attend les tâches avant de fermer SQLite ; un catalogue à jour ne nécessite aucun accès distant.

Conditionnel écrit les résultats de rejet d'une autorisation obsolète, d'un compte désactivé/supprimé ou d'une révision du cycle de vie plus précoce. Codex version une fois; les résultats d'une version remplacée par la requête réseau sont rejetés, et les instantanés conservent la version effectivement envoyée en amont. La politique de version et la synchronisation automatique de la version stable sont gérés dans paramètres du système. Bourses de pool, adhésion, politiques et instantanés persistants sont lus à nouveau en une seule SQLite transaction avant la publication d'un résultat de pool. Les modèles retirés du pool ne peuvent pas fuir à travers un rafraîchissement commencé avant l'édition.

Catalogues et routage de pools

Le catalogue de pool efficace est l'union dédoublée des instantanés de compte utilisables, filtré par le modèle exact du pool licencielist. Les comptes désactivés et réautorisés-requis sont exclus. Cooldown, concurrency et le quota d'abonnement restant restent des préoccupations d'exécution distinctes; un modèle répertorié ne promet pas un emplacement de demande disponible immédiatement.

Les catalogues des comptes, groupes et clés utilisent les identifiants natifs sans préfixe ajouté. Les ressources admissibles Codex, Claude, Antigravity, Grok Build et API compatibles OpenAI participent selon le routage et le repli du groupe. Le catalogue public exclut les modèles masqués. Les identifiants visibles identiques sont fusionnés ; owned_by vaut sublane si plusieurs fournisseurs offrent une route visible. Les variantes de raisonnement conservent l’identifiant complet pour les droits et utilisent le modèle de base découvert pour les capacités. La limite agrégée est de 4 096 identifiants. Les anciens préfixes de fournisseur restent acceptés et limitent explicitement les candidats.

Avant l'inférence, la découverte réchauffe les catalogues manquants/stales pour les fournisseurs admissibles dans le pool; un préfixe explicite l'héritage réduit la découverte à ce fournisseur. Compaction réchauffe et sélectionne Codex Le programmeur revérifie la politique de pool et les instantanés de compte dans sa transaction de sélection, filtre les comptes qui ne supportent pas le modèle demandé, puis applique les règles de cohérence, de refroidissement et de rotation existantes. 404 model_not_available; retour de capacités inconnues ou sur-âge 503 model_catalog_unavailable D'autres comptes admissibles et connus peuvent encore servir de modèle lorsque la découverte d'un pair échoue.

Les demandes natives sélectionnent parmi les comptes disponibles autorisés déclarant le modèle. La sélection et la réservation des comptes partagent la transaction existante et le verrouillage du processus. Les conversations natives existantes maintiennent un compte unique liant les fournisseurs. Lorsque le client modifie explicitement les modèles et envoie l'historique portable complet, un compte qui ne supporte pas le nouveau modèle peut être remplacé par un compte admissible dans le même pool. Si le compte courant supporte le nouveau modèle, il reste sélectionné.

Maintien du fournisseur conserve son compte : références de réponse précédente ou de conversation stockée, références d'éléments, raisonnement crypté/compaction, signées Claude la pensée et Gemini contenu/signatures en cache ne peuvent pas autoriser un commutateur de modèle. WebSocket les tours ne peuvent pas changer le modèle; envoyer une histoire complète indépendante response.create Tourne plutôt. HTTP previous_response_id reste rejeté; envoie l'entrée complète sans cette référence. Requêtes liées non supportées retour conversation_account_unavailable.

Les account_affinity table stores native routage sous un auto Les reliures mises à jour avec des métadonnées de modèle inconnues restent coincées jusqu'à ce qu'une requête prise en charge enregistre le modèle; commencez une nouvelle conversation si cela n'est pas disponible. Une reliure unique du fournisseur est adoptée sans changer le hachage de compte ou de session en amont; plusieurs reliures du legs sous la même session restent ambiguës. Les requêtes explicites de préfixe du legs conservent leurs reliures spécifiques au fournisseur seulement lorsque ce fournisseur est actif. API- clé / lien de compte est ajouté.

APIs d'interface utilisateur et navigateur

• Comptes → Modèles montre les derniers modèles d'ID déclarés d'un compte, le temps d'observation et l'état de synchronisation, avec mise à jour manuelle.
• Groupes de ressources → Modèles affiche le catalogue de pool dérivé automatiquement, filtré par politique. L'éditeur de pool continue de gérer séparément la licenselist.
• API clés → Modèles affiche le catalogue de pool autorisé de la clé actuelle. Importation dans CC Switch fournit un model picking consultable en utilisant le même catalogue.

L'accès au catalogue personnel revérifie l'activation de la clé, l'expiration, la révocation et l'accès au pool. Responses Une réponse partielle de pool révèle que certains catalogues de comptes restent inconnus au lieu de les traiter comme supportant chaque modèle.

Limite de vérification

Les tests automatisés utilisent des comptes synthétiques et des faux en amont locaux. Ils couvrent la persistance de redémarrage, les catalogues vides faisant autorité, la rétention/rétrograde, les courses d'autorisation et de rappel de pool, l'annulation/découpage, le routage mixte des comptes, les licenselists de pool, les variantes de pensée, l'affinité de conversation, la propriété des paramètres et la persistance du nouveau schéma.

Diagnostic de disponibilité du modèle

Les résultats montrent l'éligibilité locale pour une nouvelle demande, les raisons d'exclusion, le temps d'observation et les temps de réessayer connus. Les administrateurs peuvent inspecter les détails de niveau de compte; les clés personnelles reçoivent des agrégats sans identité d'abonnement. Les vérifications n'exécutent pas d'inférence, ne rafraîchissent pas les métadonnées, ne réservent pas de créneaux ou ne créent pas de liens de conversation. Les données inconnues/stales restent inconnues. L'éligibilité ne garantit pas le succès en amont; les limites de clé, de membre et de quotas s'appliquent toujours et les conversations existantes conservent leur compte.

Tests manuels des modèles

Les administrateurs peuvent ouvrir la liste des modèles d’un compte ou d’un canal API et sélectionner Tester à côté d’un modèle. Chaque test envoie une véritable requête de génération, consomme le quota du fournisseur et occupe de la capacité, avec un délai maximal de 30 secondes. Le résultat indique la réussite ou une erreur sans données sensibles et la durée en millisecondes pour cette ressource au moment du test. Il ne vérifie ni l’accès d’une clé personnelle au groupe ni son allocation d’usage. Le diagnostic local de disponibilité ci-dessus n’envoie aucune requête de génération.

La visibilité définie par le fournisseur et la capacité de routage sont distinctes : les modèles masqués n’apparaissent ni dans les catalogues du navigateur ni dans GET /v1/models, mais une requête qui les désigne explicitement peut être acheminée si le compte les prend en charge et si la politique actuelle l’autorise. Ils restent soumis aux permissions, aux quotas et aux limites de capacité.

Visibilité des modèles internes

Les modèles Antigravity marqués isInternal et Grok Build marqués hidden ou _meta.hidden restent appelables. Les fenêtres authentifiées des comptes, groupes de ressources et clés personnelles les affichent après les modèles visibles, avec une étiquette de modèle masqué et un tri alphabétique dans chaque groupe. GET /v1/models et le sélecteur CC Switch les excluent. Les appels explicites appliquent toujours politiques, droits, quotas, allocations, capacité, délais de récupération et état du compte. Grok lit le catalogue de l’abonnement authentifié et normalise les alias en identifiants natifs de routage. Les anciens catalogues sont actualisés automatiquement pour obtenir les métadonnées de visibilité.