Modellkataloge

Verwenden Sie dies, wenn die Modellliste leer ist oder Sie verfügbare Modelle steuern müssen. Ihre erste Anfrage.

SubLane Modell-IDs pro Abonnement-Konto entdeckt und den Katalog jedes Pools aus seinen aktivierten Konten ableitet. Pool-Zulassungslisten bleiben Administrator-eigene Richtlinien; Discovery ersetzt sie nie. Ein gemeldetes Modell beschreibt Upstream-Unterstützung, keine verbleibenden Quoten oder einen erfolgreichen Generationstest.

Beispielmodellkatalog mit synthetischen Modell-IDs:

Synchronisation und Speicherung

Kontoeinfuhr, OAuth Nachdem die Anmeldeinformationen gespeichert wurden, wird mit der Neuautorisierung der alte Katalog gelöscht, auch wenn der eingereichte Token unverändert ist. Bestehende Accounts entdecken faul beim Lesen ihres Katalogs oder Pools oder vor der ersten Modellanforderung. Durch die erneute Aktivierung eines Accounts wird überprüft, ob der gespeicherte Katalog aktualisiert werden muss. Verbindung überprüfen und Erfrischungsmodelle Die gleiche Discovery-Operation.

Das konsolidierte Schema speichert eine Begrenzung JSON Eine Momentaufnahme enthält sortierte, deduplizierte native Modell-IDs, die letzte erfolgreiche Beobachtungszeit und einen Discovery-Source-Marker. Codex Eine Client-Version und eine Adapter-Revision; ein Upgrade dieses Vertrages aktualisiert ältere oder nicht markierte Snapshots unabhängig von ihrem Alter. Jedes Konto ist auf 512 Modell-IDs mit höchstens 128 ASCII-Zeichen beschränkt; es werden keine vorgelagerten Anweisungen, Manifeste oder Anmeldeinformationen gespeichert. Ein Null-Snapshot bedeutet unbekannte Unterstützung. Eine erfolgreich abgerufene leere Liste ist ein bekannter leerer Katalog.

Snapshots sind 15 Minuten lang frisch. Ein abgestandener Lesewert gibt den gespeicherten Wert zurück und startet eine gemeinsame Hintergrundaktualisierung. Es gibt keine periodische Upstream-Abfrage im Leerlauf. Cold Requests schließen sich auch einer Aktualisierung an, wenn sich der Discovery-Source-Marker ändert. Eine fehlgeschlagene Upgrade-Aktualisierung kann zwar zuvor bekannte Funktionen beibehalten, aber ein veralteter Katalog kann nicht beweisen, dass ein nicht gelistetes Modell nicht unterstützt wird. Manuelle Aktualisierungen haben eine Abklingzeit von fünf Sekunden. Fehlgeschlagene Aktualisierungen behalten den letzten erfolgreichen Snapshot und schalten sich für 30 Sekunden aus. Fehlgeschlagene Beobachtungen ändern nie ihren Zeitstempel. Nach 24 Stunden bleibt der alte Snapshot für Administratoren sichtbar, wird aber von beworbenen und routbaren Modellen bis zum Aktualisieren ausgeschlossen. Erfrischungszustand und Backoff sind prozesslokal; erfolgreiche Snapshots überleben Neustarts.

Höchstens zwei Modellerkennungen laufen gleichzeitig innerhalb der Arbeitsbereichskapazität: standardmäßig 128 Vorgänge, einstellbar mit SUBLANE_GATEWAY_CAPACITY. Leser desselben Kontos und derselben Revision teilen eine Erkennung mit Prozesskontext und 45 Sekunden Zeitlimit. Ein Browserabbruch beendet nur dessen Wartezeit. Auch die erstmalige Erkennung hat insgesamt 45 Sekunden. Beim Herunterfahren werden Aufgaben vor SQLite beendet; aktuelle Kataloge benötigen keine externe Abfrage.

Reject-Ergebnisse aus einer veralteten Autorisierung, einem deaktivierten/gelöschten Account oder einer früheren Lifecycle-Revision. Discovery erfasst die Laufzeit Codex Einmalige Version; Ergebnisse einer Version, die während der Netzwerkanforderung ersetzt wurde, werden verworfen, und Snapshots behalten die tatsächlich vorgelagerte Version bei. SystemeinstellungenPool-Zugriffsrechte, Mitgliedschaft, Politik und anhaltende Momentaufnahmen werden in einem gelesen SQLite Transaktion vor der Veröffentlichung eines Poolergebnisses: Aus dem Pool entfernte Modelle können nicht durch eine vor der Bearbeitung begonnene Aktualisierung durchsickern.

Pool-Kataloge und Routing

Der effektive Pool-Katalog ist die deduplizierte Vereinigung von nutzbaren Konto-Snapshots, gefiltert nach der exakten Modell-Erlaubnisliste des Pools. Deaktivierte und reautorisierungspflichtige Konten sind ausgeschlossen. Cooldown, Parallelität und verbleibende Abonnement-Quote bleiben separate Laufzeitbedenken; ein gelistetes Modell verspricht keinen sofort verfügbaren Anfrage-Slot.

Konto-, Gruppen- und Schlüsselkataloge verwenden native Modell-IDs ohne zusätzliche Anbieterpräfixe. Geeignete Ressourcen von Codex, Claude, Antigravity, Grok Build und OpenAI-kompatiblen APIs tragen gemäß Routing und Rückfallregeln der Gruppe bei. Öffentliche Listen schließen versteckte Modelle aus. Gleiche sichtbare IDs werden zusammengeführt; bei sichtbaren Routen mehrerer Anbieter ist owned_by gleich sublane. Denkvarianten behalten die vollständige ID für Berechtigungen und verwenden das erkannte Basismodell für Fähigkeiten. Die Gesamtgrenze beträgt 4.096 IDs. Bisherige Anbieterpräfixe bleiben unterstützt und begrenzen bei expliziter Angabe die Kandidaten.

Vor der Inferenz wärmt Discovery fehlende/stale Kataloge für berechtigte Anbieter im Pool; ein explizites Legacy-Präfix verengt Discovery auf diesen Anbieter. Compaction wärmt und wählt Codex Nur Konten: Der Scheduler überprüft die Poolrichtlinien und Konto-Snapshots in seiner Auswahltransaktion, filtert Konten heraus, die das angeforderte Modell nicht unterstützen, und wendet dann bestehende Regeln für Übereinstimmung, Abklingzeit und Rotation an. Ein bekanntes nicht unterstütztes Modell gibt zurück 404 model_not_available; unbekannte oder Überalterung Fähigkeiten Rückkehr 503 model_catalog_unavailable Andere berechtigte, bekannte Konten können einem Modell noch dienen, wenn die Entdeckung eines Peers fehlschlägt.

Native Requests wählen zwischen zulässigen, verfügbaren Konten, die das Modell melden. Kontoauswahl und -reservierung teilen sich die bestehende Transaktions- und Prozesssperre. Bestehende native Gespräche halten ein einzelnes Konto anbieterübergreifend verbindlich. Wenn der Client Modelle explizit ändert und den gesamten portablen Verlauf sendet, kann ein Konto, das das neue Modell nicht unterstützt, durch ein berechtigtes Konto im selben Pool ersetzt werden. Wenn das Girokonto das neue Modell unterstützt, bleibt es ausgewählt. Sättigung, Cooldown, Entfernung, Deaktivierung und verlorene Unterstützung für ein unverändertes Modell führen niemals zu einem automatischen Failover.

Anbieter-Fortsetzungen behalten ihr Konto: Referenzen für vorherige Antworten oder gespeicherte Gespräche, Artikelreferenzen, verschlüsselte Argumentation / Kompaktierung, signiert Claude Denken und Gemini Zwischengespeicherte Inhalte/Signaturen können einen Modellwechsel nicht autorisieren. WebSocket Turns können das Modell nicht ändern; senden Sie eine unabhängige vollständige Geschichte response.create Drehen Sie stattdessen. HTTP previous_response_id bleibt abgelehnt; senden Sie vollständige Eingabe ohne diese Referenz. conversation_account_unavailable.

Die bestehenden account_affinity Tabelle speichert natives Routing unter einer auto Umfang und Aufzeichnung des normalisierten Modells durch eine additive Migration. Upgraded Bindings mit unbekannten Modellmetadaten bleiben gepinnt, bis eine unterstützte Anforderung das Modell aufzeichnet; eine neue Konversation starten, wenn diese nicht verfügbar ist. Eine einzelne Legacy-Providerbindung wird übernommen, ohne den Account oder Upstream-Session-Hash zu ändern; mehrere Legacy-Bindungen unter derselben Sitzung bleiben mehrdeutig. Explizite Legacy-Präfix-Anforderungen behalten ihre Provider-spezifischen Bindungen nur bei, wenn dieser Anbieter aktiv ist. Keine permanente API-key/account binding wird hinzugefügt.

UI und Browser APIs

• Accounts → Modelle zeigt die letzten gemeldeten Modell-IDs eines Kontos, Beobachtungszeit und Synchronisationszustand mit manueller Aktualisierung an.
• Ressourcengruppen → Modelle zeigt den automatisch abgeleiteten, Policy-gefilterten Pool-Katalog an. Der Pool-Editor verwaltet die Allowlist weiterhin separat.
• API Keys → Modelle zeigt den autorisierten Poolkatalog des aktuellen Schlüssels an. Einfuhr in die Gemeinschaft CC Switch stellt einen durchsuchbaren Modellauswahler bereit, der denselben Katalog verwendet.

Persönlicher Katalogzugriff überprüft erneut Schlüsselaktivierung, Ablauf, Widerruf und Poolzugriff. Administratoren können den persönlichen Endpunkt nicht verwenden, um den Schlüssel eines anderen Besitzers zu inspizieren. Responses Modell-Metadaten und aggregierte Frischezahlen enthalten, keine Abonnement-Account-IDs, Namen oder Anmeldeinformationen. Eine partielle Pool-Antwort zeigt, dass einige Account-Kataloge unbekannt bleiben, anstatt sie als jedes Modell unterstützend zu behandeln.

Prüfgrenze

Automatisierte Tests verwenden synthetische Konten und lokale gefälschte Upstreams. Sie umfassen Neustart-Persistenz, autoritative leere Kataloge, fehlgeschlagene Aktualisierungs-Retention / Backoff, Autorisierungs- und Pool-Revocation-Rennen, Stornierung / Shutdown, Mixed-Account-Routing, Pool-Erlaubnislisten, Denkvarianten, Konversationsaffinität, Endpunkt-Besitz und Frischschema-Persistenz. Frontend-Tests umfassen Katalogzustände, Tastaturmodellauswahl und veraltete Antworten nach Identitätsänderungen. Discovery untersucht nicht die Modellgenerierung, und Upstream-Kataloge können zwischen Synchronisation und einer tatsächlichen Anforderung wechseln.

Modellverfügbarkeitsdiagnose

Mit den Pool- und Personal-Key-Modelldialogen können Sie eine native Modell-ID überprüfen. Die Ergebnisse zeigen die lokale Berechtigung für eine neue Anforderung, Ausschlussgründe, Beobachtungszeit und bekannte Wiederholungszeiten. Administratoren können Details auf Kontoebene überprüfen; persönliche Schlüssel erhalten Aggregate ohne Abonnementidentitäten. Prüfungen führen keine Rückschlüsse aus, aktualisieren Metadaten, reservieren Slots oder erstellen Konversationsbindungen. Unbekannte/Stale-Daten bleiben unbekannt. Die Berechtigung garantiert keinen Upstream-Erfolg; Schlüssel-, Mitglieds- und Kontingentgrenzen gelten weiterhin und bestehende Gespräche behalten ihr Konto.

Modelle manuell testen

Administratoren können die Modellliste eines Kontos oder API-Kanals öffnen und neben einem Modell Testen wählen. Jeder Test sendet eine echte Generierungsanfrage, verbraucht Anbieterkontingent und belegt Kapazität. Das Zeitlimit beträgt 30 Sekunden. Das Ergebnis zeigt Erfolg oder einen Fehler ohne sensible Daten sowie die Dauer in Millisekunden für diese Ressource zum Testzeitpunkt. Es prüft weder den Gruppenzugriff noch das Nutzungskontingent eines persönlichen Schlüssels. Die lokale Verfügbarkeitsdiagnose oben sendet keine Generierungsanfragen.

Sichtbarkeit beim Anbieter und Routing-Fähigkeit sind getrennt: Ausgeblendete Modelle erscheinen weder in den Browserkatalogen noch in GET /v1/models. Bei einer Anfrage mit expliziter Modell-ID können sie dennoch verwendet werden, wenn das Konto sie unterstützt und die aktuelle Modellrichtlinie dies erlaubt. Berechtigungen, Kontingente und Kapazitätsgrenzen gelten weiterhin.

Sichtbarkeit interner Modelle

Antigravity-Modelle mit isInternal und Grok-Build-Modelle mit hidden oder _meta.hidden bleiben aufrufbar. Die angemeldeten Modellansichten für Konten, Ressourcengruppen und persönliche Schlüssel zeigen sie mit einer Kennzeichnung für versteckte Modelle hinter den sichtbaren Modellen; beide Gruppen sind alphabetisch sortiert. GET /v1/models und die CC-Switch-Auswahl blenden sie aus. Explizite Aufrufe prüfen weiterhin Modellrichtlinien, Berechtigungen, Kontingente, Nutzungslimits, Kapazität, Abkühlzeiten und Kontostatus. Grok liest den authentifizierten Abonnementkatalog und normalisiert Auswahlnamen zu nativen Routing-IDs. Ältere Kataloge werden automatisch für Sichtbarkeitsmetadaten aktualisiert.