Ressourcengruppen

Eine Ressourcengruppe wählt Abonnementkonten und API-Kanäle desselben Arbeitsbereichs aus. Nutzen Sie getrennte Gruppen für unterschiedliche Ressourcen oder Modelle. Ressourcen können nicht über Arbeitsbereichsgrenzen hinweg zugeordnet werden.

Ressourcentypen und Routing

Ressourcengruppen binden persönliche Gateway-Schlüssel, Zugriffsrechte für Mitglieder und Modellrichtlinien. API Kanäle separat; jede Ressourcenart hat ihre eigene Verwaltungsseite, während die Isolation des Arbeitsbereichs beibehalten wird.

Neue UI Gruppen bevorzugen Abonnements mit API Fallback off. Eine gemischte Gruppe verwendet API Kanäle für neue Anfragen nur dann, wenn Fallback explizit aktiviert ist und kein berechtigtes Abonnement verfügbar ist. API-nur die Gruppe nutzt die ausgewählten Kanäle direkt. Administratoren bevorzugen API Kanäle oder behalten Sie die Präferenz des Client-Protokolls. API Anrufe können Upstream-Saldo verbrauchen; SubLane Diese Balance wird nicht abgefragt.

Upgrades bewahren die Protokolleinstellungen und Schlüsselbindungen bestehender Gruppen. Bestehende Konversationen werden nach Routing-Änderungen nie zu einer anderen Ressource verschoben. Das Deaktivieren des Fallbacks oder das Entfernen/Deaktivieren einer gebundenen Ressource kann die bestehende Konversation fehlschlagen, anstatt ihre Identität zu ändern.

Die Geschäftsleitung API Haltungsbetriebe /api/groups und kompatibel account_ids Nutzlasten. Das neue UI sendet resources (kind: "subscription" oder "channel" und Ressourcen id) und routing (preference, allow_api_fallbackGemischte Mitgliederrepräsentationen, doppelte IDs und falsche Ressourcentypen werden abgelehnt.

Administrator-Workflow

1. Im ausgewählten Arbeitsbereich, geöffnet Ressourcengruppen und erstellen Sie eine benannte Gruppe. API Neue Ressourcen bleiben bis zur Auswahl für eine Gruppe nicht zugewiesen.
2. Offen Mitglieder und jedem Mitglied Zugang zu den Gruppen gewähren, die es nutzen kann. Ein Zugriffsrecht gilt direkt für dieses Mitglied; es gibt keine Personalteams; neue Mitglieder und neue Gruppen erhalten keine automatischen Zugriffsrechte.
3. Mitglieder erstellen einen persönlichen Schlüssel für eine aktivierte Gruppe, auf die sie zugreifen können. Jeder Schlüssel ist dauerhaft an diesen Arbeitsbereich und diese Gruppe gebunden.

Nicht verwaltete Gruppen können sich das gleiche Upstream-Konto teilen innerhalb eines ArbeitsbereichsA Nutzungskontingent Eine exklusive Gruppe benötigt: Entfernen Sie zuerst ihre Ressourcen aus anderen Gruppen. Sobald eine Gruppe eine Kontingent hat, bleibt ihre Ressourcenmitgliedschaft während des Bestehens der Kontingent festgelegt, auch wenn sie angehalten wird. Deaktivieren einer Gruppe oder Widerrufen eines Zugriffsrechts des Mitglieds blockiert zukünftige Anfragen und WebSocket wendet sich, ohne eine bestehende Konversation in eine andere Ressource zu verschieben.

Ein Arbeitsbereich unterstützt bis zu 32 Gruppen und 100 Ressourcenzuordnungen pro Gruppe. Gruppen können umbenannt und deaktiviert werden. Die aktuelle Benutzeroberfläche löscht keine Gruppen. Mitgliederanforderungslimits und Ressourcenzuweisungen werden separat konfiguriert.

Der folgende Screenshot stammt aus einer früheren Version mit den Ressourcengruppe-Labels; der aktuelle Ressourcengruppen-Editor listet auch die API Channels und Routingpräferenzen:

Anfrage und Gesprächsverhalten

• Key Creation überprüft den aktuellen Mitglieds- und Gruppenzugriff in derselben Transaktion wie die Schlüsseleinfügung.
• Jede Anfrage und WebSocket turn überprüft den Workspace-Status, die Mitgliedschaft, den Schlüsselstatus, den Gruppenzugriff und die Modellrichtlinie.
• Suchen und Inferenz verwenden nur berechtigte Konten in der gebundenen Gruppe. Eine Anforderung kann ein Konto nur verwenden, wenn der gespeicherte Katalog das angeforderte Modell unterstützt.
• Die konversationsaffinität wird auf das mitglied, die gruppe und die sitzung beschränkt wenn das gebundene konto nicht mehr verfügbar ist oder die gruppe verlässt, schlägt die konversation fehl, anstatt stillschweigend konten zu wechseln.
• Eine bereits zugelassene Anfrage kann nach einer Änderung des Zugriffsrechts beendet werden; die nächste Anfrage oder der nächste Zug sieht die neue Richtlinie.

HTTP Endpunkte

Verwaltungsendpunkte erfordern eine Administratorrolle im ausgewählten Arbeitsbereich. Browseranforderungen tragen die Arbeitsbereichsauswahl und erfordern den gleichen Ursprungsschutz für Mutationen.

Das Gateway identifiziert den Arbeitsbereich über den authentifizierten Schlüssel, nicht über den Browserauswahl-Header. Arbeitsbereiche und API-Schlüssel.

Zugang zu Modellen

Ein Administrator kann Zulässige Limitmodelle Geben Sie bis zu 100 genaue IDs ein, eine pro Zeile, mit den von /v1/models. Native IDs erlauben dieses genaue Modell für alle unterstützenden Anbieter in der Gruppe. Bestehende Anbieter-qualifizierte Regeln behalten ihren ursprünglichen Anbieter-Bereich bei; Aktualisierung SubLane Legacy-qualifizierte Regeln können weiterhin explizit eingereicht werden. Wildcards werden nicht unterstützt und Modellvarianten müssen explizit aufgelistet werden.

Gruppen bleiben standardmäßig unbeschränkt, einschließlich neu entdeckter Modelle. API akzeptiert eine optionale model_policy: {"restricted": true, "models": ["synthetic-model"]} bei der Erstellung/Aktualisierung: Unterlassung behält eine bestehende Richtlinie bei; der Zugriff wird nicht zurückgesetzt; Gruppenantworten umfassen restricted_models; Detailantworten umfassen auch allowed_models.

Model Discovery filtert Modelle außerhalb der Allowlist heraus und kontaktiert keine Anbieter, die von der Richtlinie vollständig ausgeschlossen sind. Responses, Chat CompletionsKompaktierung und alle WebSocket Turn (einschließlich lokaler Vorwarm-Politik) vor der Kontoauswahl oder vorgelagerten Arbeiten überprüfen. 403 model_not_allowed; er verbraucht keine Nutzungskontingent für Mitglieder und schafft keine Affinität; bereits zugelassene Anträge können enden.

Automatisch entdeckte Modelle

Offen Modelle Eine Gruppe muss die Vereinigung der gespeicherten Modellkataloge ihrer berechtigten Konten prüfen. Die Liste folgt der Kontomitgliedschaft und wendet die bestehende Erlaubnisliste an; es handelt sich nicht um eine zweite editierbare Kopie dieser Richtlinie. Neue vorgelagerte Modelle erscheinen automatisch nur in uneingeschränkten Gruppen. Explizite Einschränkungen, einschließlich einer aktivierten leeren Deny-All-Liste, bleiben durch Synchronisation unverändert.

Inference verwendet kontospezifische Katalogunterstützung, bevor normale Load-/Cooldown-Regeln angewendet werden. Konten mit unterschiedlichen Abonnementfunktionen können sich eine Gruppe teilen: Eine Anfrage ist nur für Konten zulässig, die ihr Modell gemeldet haben. Modellkataloge für Frische, Misserfolge und Gesprächsaffinität.