Usage et limites de l’équipe

Pour les vérifications de demande et d'utilisation, commencer par Utilisation quotidienne. Utilisez cette référence pour la récupération de mot de passe, les limites de demande et les statistiques détaillées.

Cycle de vie du mot de passe

Les deux rôles peuvent ouvrir Préférences → Modifier le mot de passe. Le mot de passe actuel est requis; le nouveau mot de passe doit contenir 8-20 caractères Unicode. L'administrateur de la plateforme dans le premier espace de travail peut ouvrir Membres → Plus d'actions → Réinitialiser le mot de passe pour un membre, y compris un membre désactivé. Réinitialiser un membre désactivé ne permet pas ce compte.

Chaque changement réussi remplace atomiquement le hachage Argon2id et révoque toutes les sessions du navigateur pour cet utilisateur, y compris la session en cours. D'autres utilisateurs restent connectés. Vérification du mot de passe et création de session revérifient le même hachage, de sorte qu'un login qui a vérifié un ancien mot de passe ne peut pas créer de session après une réinitialisation simultanée.JSON les contrôles, les gaz d'authentification existants par les pairs/mondiales et le nombre de travailleurs de hachage délimités.

Passerelle API les clés ont un cycle de vie indépendant et restent valides. Revoquez les clés affectées séparément si nécessaire; désactivation d'un membre continue à suspendre toutes leurs clés. Aucun mot de passe ou hash n'est retourné par la direction API ou stocké dans le stockage du navigateur. La fermeture d'un formulaire de mot de passe rejette ses données de mutation en attente.

Si l'administrateur ne peut se connecter, utilisez la commande de récupération locale. Arrêtez l'instance et sauvegardez sa base de données et credentials.key D'abord, ensemble. SUBLANE_DATA_DIR à l'instance existante et fournir le nouveau mot de passe par entrée standard, par exemple à partir d'un fichier privé:

SUBLANE_DATA_DIR=/path/to/data ./bin/sublane reset-admin-password --password-stdin < /secure/path/new-password

La commande accepte une ligne, ne prend jamais de mot de passe dans les arguments en ligne de commande, rejette l'entrée directe du terminal et n'imprime jamais le mot de passe. Elle nécessite une base de données et un administrateur existants, vérifie le schéma de base de données pris en charge et révoque les sessions du navigateur administrateur. HTTP un serveur, initialiser un nouvel administrateur, modifier les clés de passerelle ou modifier les identifiants d'abonnement. Il n'y a pas de point d'arrêt public de récupération.

Limites des demandes des membres

Administrateurs ouverts Membres → Plus d'actions → Demande de limites. Les demandes par minute par défaut à 0 (unlimited), et par défaut à 10 par le membre. La limite à 0 désactive cette limite personnelle. Les limites d'adhésion s'appliquent à chaque rôle; l'espace de travail/la capacité de compte partagé s'applique toujours.

La limite de taux utilise des limites de minutes UTC fixes. Une limite peut admettre les demandes de chacune des fenêtres adjacentes en succession rapide; ce n'est pas une limite de fenêtre coulissante. Une demande consomme une fente de taux après validation et l'admission de la concordance de membre, avant la sélection de compte en amont. Un compte non disponible, la panne de refroidissement ou la défaillance ultérieure du fournisseur consomme encore cette fente. WebSocket La préchauffage ne consomme pas de limites de demande de modèle.

HTTP/SSE, Chat Completions, compactage et chaque WebSocket Les baux des membres restent actifs jusqu'à ce que le cycle de vie de la réponse existante se termine, et libèrent exactement une fois lors de l'achèvement normal, de l'annulation, de la défaillance ou de l'arrêt. Les changements s'appliquent aux demandes subséquentes; l'abaissement d'une limite de cohérence permet de terminer les appels admis. Les limites de passerelle et de compte partagées s'appliquent toujours même lorsque les limites personnelles sont désactivées.

HTTP limite de rejet retour 429 avec member_busy ou member_rate_limited et un en-tête limité Retry-After. WebSocket retourne un événement d'erreur correspondant. Le rejet local ne pénalise jamais un compte en amont. Les politiques et les compteurs de minutes sont maintenus dans SQLite. Les compteurs en vol sont processus-local et vide après redémarrage; exécutez un SubLane processus par base de données.

Exemple de limites de demande par membre avec des valeurs synthétiques:

Allocations d’usage

Créez un groupe de ressources dédié, accordez l’accès aux membres, puis ajoutez une allocation par part, montant, tokens ou fenêtre temporelle. Les parts divisent un budget configuré de tokens ou de USD internes ; les fenêtres appliquent plusieurs plafonds USD par durée. Propriétaires et administrateurs n’ont pas besoin d’une autorisation de groupe directe. Toutes les clés d’un membre liées à la même allocation partagent son solde. Voir allocations d’usage pour la configuration et les remises à zéro.

Note de mise à jour : Pour conserver une limite de jeton, créez une allocation d’usage et une nouvelle clé qui y est liée. Les lignes budgétaires existantes restent dans les bases de données améliorées, mais l'application ne les lit plus ou ne les met plus à jour. L'utilisation pendant cette version n'est pas ajoutée à ces anciens compteurs si vous reculez.

Résumés d'utilisation

Généralités → Aperçu → Votre utilisation affiche les appels de l'utilisateur actuel et les limites personnelles actuelles. Administration → Utilisation de l'équipe Choisissez aujourd'hui ou les derniers 7, 30 ou 90 jours civils UTC, y compris le jour partiel actuel. Les résumés comprennent le nombre de demandes, le nombre de résultats, le taux d'achèvement, la durée moyenne et les jetons d'entrée/sortie déclarés. Les deux rôles sont disponibles quotidiennement, les modèles et les tableaux de distribution; la vue de l'équipe comprend également les membres. Les tableaux non quotidiens indiquent les 20 premières entrées par compte de demande, tandis que les totaux couvrent toujours toute la période sélectionnée. Afficher les détails Pour des valeurs tabulaires exactes. Les trous de jeton restent inconnus plutôt que d'être tracés comme zéro. Les points quotidiens supportent l'inspection pointeur/touch et la navigation avec la touche flèche.

Le taux d'achèvement des demandes est divisé par toutes les tentatives enregistrées; les réponses incomplètes ont un nombre distinct. La durée moyenne comprend le rejet local, l'annulation et l'échec. API. Ce sont des statistiques opérationnelles. des ressources humaines utiliser un grand livre distinct; les totaux sommaires ne sont pas une facture ou l'allocation d’usage restante.

La couverture commence lorsque la collecte de statistiques commence dans la base de données initialisée, et l'interface affiche cet horodatage. Les dossiers de demandes existants ne sont pas remplis car l'historique conservé peut déjà être incomplet. limite de couverture de la demande-histoire: défaillances d'authentification, HTTP Les défauts de validation avant l'entrée de la passerelle, le refus d'admission globale, les requêtes de métadonnées et la préchauffage sont exclus.

Les agrégats sont stockés indépendamment des enregistrements de demandes récents dans les seaux quotidiens UTC par utilisateur, pool, fournisseur et modèle normalisé. Au plus 64 étiquettes de modèles distinctes sont conservées par utilisateur par jour; les étiquettes supplémentaires sont regroupées comme suit: Autres modèles sans diminution des nombres ou des jetons déclarés. Codex pas d'erreur de fournisseur brut, de justificatif, d'adresse IP ou d'identificateur de session est stocké.

Les agrégats sont conservés pendant 90 jours civils. Le nettoyage s'exécute lors de l'enregistrement ou de la lecture de résumés, de sorte qu'une base de données inactive est récupérée lors de la prochaine opération. Aggregate et request-record écrit commit ensemble, et chaque résumé lit utilise un instantané de base de données. Un défaut de stockage est enregistré et aucun écriture n'est signalé comme ayant persisté avec succès.

Exemple de résumé d'utilisation de l'administrateur avec des totaux synthétiques :

Carte thermique de l'activité horaire

À la fois la section sur l'utilisation personnelle sur Aperçu et la page d'utilisation de l'équipe place Activité par temps Les sept rangées représentent le lundi au dimanche et les 24 colonnes représentent les heures UTC. Les couleurs reflètent la mesure courante de la demande/de l'entrée/de l'entrée/de l'entrée/de l'entrée/de l'entrée/de l'entrée, qui est résumée sur les créneaux correspondant à la semaine/d'heure dans la période sélectionnée.

Les agrégats horaires utilisent l'heure de début de la requête et sont enregistrés lorsque la tentative de modèle se termine, dans la même transaction que les agrégats quotidiens et l'historique récent. Ils ne contiennent que l'ID utilisateur, l'heure UTC, le nombre de requêtes, les montants d'entrée/sortie déclarés et leur nombre de rapports. Le stockage est limité à au plus une ligne par utilisateur par heure sur les 90 jours civils retenus, indépendamment du modèle et de la carcinalité du pool.

L'activité horaire enregistre un horodatage de collecte-démarrage séparé. Les totaux quotidiens plus tôt et les dossiers de demande élagés ne sont pas remplis en heures. Les cellules sans aucune fenêtre horaire de correspondance collectée, y compris les futures fentes, restent inconnus plutôt que zéro. Les fenêtres observées sans demande montrent zéro. Les appels sans rapport de jeton conservent l'état non déclaré; les sommes partiellement déclarées sont étiquetées. API expose le démarrage de la collecte et l'horodatage d'observation.

Les touches fléchées se déplacent à l'intérieur de la grille; Accueil/Fin se déplacent à l'intérieur d'une ligne et Ctrl+Accueil/Fin sautent à la première/dernière cellule. Les écrans étroits défilent à l'intérieur de la carte de chaleur. Les réponses d'utilisation existantes comprennent un activity objet contenant des horodatages de couverture et une grille fixe, lundi-premier 168 cellules; le filtrage de propriété reste côté serveur.

Points d'arrivée et stockage

Le démarrage initialise les nouvelles bases et applique, dans l’ordre, les migrations manquantes aux bases existantes compatibles. L’ancienne structure préliminaire avec 001_settings.sql est refusée ; conservez son répertoire avant d’en utiliser un nouveau. Exportez et vérifiez une sauvegarde avant la mise à niveau. Changer uniquement l’image ne restaure pas les données migrées.