Comptabilité des allocations d’usage

Commencez par Allocations d’usage Une règle appartient à un groupe de ressources dédié dans un espace de travail. Son adhésion au compte reste fixe pendant que la règle existe. Les membres ont besoin d'une autorisation de pool direct et d'une clé personnelle liée à la règle; une clé ordinaire n'est pas automatiquement convertie. Toutes les clés d'un membre pour la règle partagent un grand livre.

Part d'un budget total

Par part accepte un total quotidien/mensuel ou jusqu’à 8 fenêtres de durée avec un total propre à chacune. Les mêmes pourcentages, dont la somme est au plus 100 %, s’appliquent à toutes les fenêtres. La base est en tokens ou en USD internes :

• En jeton part: entrez le total en jetons M. Les entrées déclarées plus les jetons de sortie comptent par part de chaque membre; les entrées mises en cache font partie des entrées et ne sont pas comptées deux fois.
• Par part de montant: entrer dans une USD Les entrées, les entrées et les sorties mises en cache de chaque demande sont converties en utilisant le modèle de prix économisé avec cette révision de règle. Ces prix n'indiquent pas la formule de facturation d'abonnement du fournisseur.

Dans chaque fenêtre, le plafond individuel est son budget multiplié par le pourcentage, arrondi à l’unité minimale inférieure. Par exemple, 25 % de 1 M tokens donnent 0,25 M. Une part positive arrondie à zéro est refusée. Les parts non attribuées et les restes d’arrondi ne sont pas prêtés automatiquement. L’admission contrôle à la fois le membre et le total du groupe, y compris la consommation d’anciens membres. Le budget ne se réinitialise pas séparément pour chaque compte d’abonnement.

Ce sont des budget interne. Un total de jetons configurés ne révèle pas la capacité réelle de l'abonnement, et interne USD n'est pas un solde de trésorerie ou une facture. SubLane les contrôles disponibles en amont; le prestataire peut rejeter les demandes avant l'épuisement du budget interne.

Limites de temps-fenêtre

Par fenêtre temporelle est un type distinct. Ajoutez jusqu’à 8 conditions en heures/jours entiers, de 1 heure à 365 jours, avec un plafond interne en USD commun par défaut. Chaque membre est comptabilisé séparément et peut remplacer des conditions. Un plafond vide signifie illimité pour cette condition : l’usage est enregistré sans quota ni réservation de risque provisoire. Chaque requête soldée est valorisée une seule fois aux prix enregistrés et compte dans toutes les fenêtres. Une condition finie épuisée ou sans marge de réservation bloque les nouvelles requêtes.

Les fenêtres partent de l’activation et se renouvellent indépendamment selon leur durée fixe. Le renouvellement des cinq heures n’efface pas l’usage hebdomadaire. Ce ne sont pas des fenêtres glissantes et elles ne suivent pas les remises à zéro du fournisseur. Le fuseau de l’instance ne change que l’affichage.

Membres et modifications planifiées

Modifier les membres actuels change immédiatement parts ou plafonds individuels en conservant consommation et réservations des requêtes admises. Toute hausse doit tenir dans tous les budgets partagés actuels ; retirer puis réintégrer un membre n’efface pas son usage. Avec un total de 100 et A ayant consommé 40, attribuer 33 à A/B/C exige 106 et est refusé ; 40/30/30 tient. Après renouvellement, toutes les fenêtres sont revérifiées : programmer ne contourne pas un manque de budget.

Budgets, plafonds par défaut et prix prennent effet à l’heure déjà prévue ou à la prochaine frontière du plan actuel. Avec plusieurs fenêtres, on utilise celle de la durée actuelle la plus longue. L’ancrage et l’usage restent inchangés : une fenêtre courte peut être en cours et une baisse peut la laisser épuisée. Un nouveau prix ne recalcule pas les requêtes passées.

Une édition ordinaire du budget/prix conserve exactement la liste des membres enregistrée, même si un bénéficiaire n’apparaît plus dans la liste autorisée. Cela ne rétablit pas son accès. Les nouveaux bénéficiaires et une nouvelle période structurelle exigent une autorisation actuelle du groupe.

Si la version suivante porte un plan de membres distinct, la propagation d’une modification immédiate est refusée comme conflit. Révisez ou annulez cette instruction explicitement ; les autres paramètres compatibles restent prévus. Une actualisation de fond n’attache pas de nouvelles versions à un ancien brouillon. Après conflit, utilisez Actualiser et vérifier.

Changer unité, type ou plan de réinitialisation exige de confirmer un vrai remplacement structurel. Les ID de règle, groupe et Key sont conservés ; l’heure d’activation devient le nouvel ancrage. Un changement de membres ou de prix seul ne permet pas de créer une nouvelle période.

Reporter à la prochaine limite déplace uniquement vers la première frontière naturelle strictement après l’activation enregistrée, selon le plan actuel ou le plan initial avant la première activation. Vérifiez l’heure du serveur puis confirmez ; des conditions expirées ou modifiées renvoient un conflit.

Annuler le changement planifié exige une version actuelle effective. Une règle initiale uniquement en attente peut être mise en pause ou reportée. Le report initial remplace la version atomiquement. Une pause ne supprime ni configuration lisible ni activation prévue et continue de refuser l’accès après l’activation initiale.

Les corrections initiales de membres passent par l’éditeur complet (PATCH /api/allocations/{id}). Elles exigent la paire de versions et l’heure vérifiées, conservent activation et ancrage enregistrés et revérifient les permissions de groupe des bénéficiaires. Elles ne sont permises que sans version actuelle et sans requête enregistrée. Version, métadonnées et audit sont sauvegardés dans une même transaction ; un échec ou le passage de l’activation annule tout. L’annulation initiale reste interdite.

Quand la prochaine version approuvée diffère réellement de la structure actuelle, la confirmation existante de nouvelle période reste disponible même si le brouillon garde la structure planifiée. La reconfirmation permet d’en modifier les membres. Les éditions ordinaires de budget/prix gardent membres et ancrage sans reconfirmer. Retirer cette reconfirmation facultative affiche et envoie le plan de membres enregistré. Le remplacement exige toujours une vraie différence structurelle par rapport à la version actuelle.

Pour les quotas à prix réduit (Montant, Part du montantet Par fenêtre temporelle), SubLane Si un modèle n'a pas de prix de catalogue actuel, son taux précédemment enregistré est réutilisé lorsque disponible. Un modèle nouvellement découvert sans prix est omis de l'instantané, de sorte que les demandes lui restent bloquées jusqu'à ce qu'une révision de prix prenne effet. Les avertissements de couverture de prix sont calculés lorsqu'une règle est lue, non stockée dans sa révision : un prix de catalogue restauré efface automatiquement l'avertissement de catalogue, tandis qu'un modèle absent de l'instantané de prix enregistré reste signalé jusqu'à ce qu'une nouvelle révision l'incluse. Les catalogues de comptes non disponibles conservent les taux précédemment enregistrés et affichent un avertissement jusqu'à ce que la découverte se rétablisse. L'enregistrement échoue seulement si aucun prix utilisable ne subsiste. Sans catalogue de prix chargé ou cache de prix sauvegardés, une nouvelle allocation de prix ne peut être créée; rafraîchir le catalogue ou fournir un retour de prix avant de réessayer.

Pour un modèle absent des prix enregistrés, l’avertissement indique quand une correction enregistrée maintenant prendrait effet. Une règle à fenêtres utilise la prochaine frontière de la durée actuelle la plus longue ; enregistrer à nouveau ne rend pas le prix immédiatement disponible. Une version déjà planifiée affiche sa propre heure et prévient que le modèle restera bloqué sans remplacement par une version corrigée.

Limites directes et utilisation en attente

Par les jetons fixe la limite de jeton d'un membre directement. Montant définit un interne direct USD Les deux méthodes utilisent le même jeton ou la comptabilité des prix comme base d'action correspondante.

L’usage final fiable est soldé sans attendre le pourcentage amont. Une requête sans totaux fiables reste à corriger ; ses observations partielles sont visibles sans constituer une charge ou une réservation. Une requête active réserve 10 % du plafond individuel capturé à l’admission, au moins une unité, dans chaque fenêtre finie ; les éditions ultérieures ne changent pas cette réserve. Chaque fenêtre finie limite à quatre les requêtes simultanées de ce membre démarrées dans cette fenêtre ; le budget partagé contrôle aussi l’exposition du groupe. Les réserves sont libérées à la fin. De grosses requêtes peuvent dépasser le plafond et l’usage inconnu laisse une exposition incomplète : ce sont des limites souples. Les 256 entrées en attente les plus récentes apparaissent d’abord. L’attribution utilise l’admission après la file ; la durée diagnostique commence à l’arrivée.

Pour Codex les ruisseaux, SubLane Un événement terminal raté qui comprend une utilisation complète peut également être facturé. Les défaillances en amont répétées refroidissent temporairement le compte concerné; une réponse réussie sans utilisation finale reste en attente sans refroidissement du compte. Si une écriture comptable échoue temporairement, SubLane demande que le membre touché puisse continuer à travailler avec lui avant d'admettre qu'il a droit à une allocation d’usage supplémentaire; d'autres membres peuvent continuer.

Les règles quotidiennes/mensuelles gardent leur date et heure dans le fuseau de l’instance ; un jour absent est ramené au dernier du mois. Les valeurs par défaut sont 00:00 chaque jour ou le premier du mois à 00:00. Les éditions ordinaires gardent l’ancrage. La pause ou la révocation bloque les prochaines requêtes et tours WebSocket sans effacer l’historique. Actualiser le quota, utiliser une carte de réinitialisation, réautoriser ou redémarrer ne recharge pas le budget local.

Choix Début de la période suivante lors de la création d'une règle time-window commence après la plus longue durée configurée.

Lire et corriger les soldes

Les membres perçoivent leur propre allocation sous Utilisation. Administrateurs d'espace de travail ouverts Allocations d’usage → Voir l'utilisation Toutes les fenêtres de temps configurées apparaissent sous un seul membre avec leur propre limite, le montant utilisé, le montant restant, l'exposition au risque et la réinitialisation instantanée; le statut du membre reflète la condition la plus restrictive. USD avec les jetons déclarés; les balances de jetons utilisent M, où 1 M = 1,000,000 tokens. Les rapports personnels n'exposent pas les identités des comptes d'abonnement.

Le solde se sépare utilisé Les réservations temporaires ne reflètent que les demandes en vol; l'utilisation en attente reste visible pour correction et ne compte pas comme allocation d’usage d'utilisation ou capacité de réserve. La salle de tête d'admission comprend le tampon de risque automatique; il ne s'agit pas d'allocation d’usage supplémentaire. Nouvelles requêtes temporairement suspendues quand une autre demande nécessite plus de réservation que la salle de tête actuelle, ou que quatre demandes sont toujours en vol. L'état suit la même vérification des risques du cycle courant que l'entrée de passerelle. C'est un instantané et peut changer à la fin des requêtes.

Lorsqu'une entrée en attente ne peut pas être résolue automatiquement, un administrateur peut saisir des totaux d'entrées, de sorties et de mises en cache appuyés par des preuves fiables. La correction utilise la règle de comptabilité sauvegardée de la requête et écrit un événement d'audit. Ne traitez pas l'utilisation manquante comme zéro ou entrez des totaux inventés.

Les administrateurs de l'espace de travail gèrent les règles à /api/allocations; les membres lisent leurs propres soldes à /api/me/allocations. Les clés se lient à une règle avec scheme_idVoir Espaces de travail et personnel API clés.

Conditions d’écriture de l’API

Les lectures gardent leur format et ajoutent write_conditions, avec expected_current_revision_id et expected_next_revision_id pouvant valoir null. Les deux sont requis pour les modifications d’une règle existante : PATCH complet, membres, annulation/report et remplacement. Une absence ou une version périmée renvoie HTTP 409 sans mutation. Révisez le contenu ; n’obtenez pas de nouveaux ID pour rejouer automatiquement un ancien brouillon. L’activation/pause explicite et la correction liée à une requête gardent leurs contrats.

Une écriture future exige expected_effective_at, en secondes UTC confirmé par le serveur ; le remplacement structurel exige aussi confirm_replacement=true. POST /api/allocations/{id}/preview accepte schedule, reschedule ou replace. Les membres utilisent POST /api/allocations/{id}/members ; les réservations utilisent POST /api/allocations/{id}/cancel et POST /api/allocations/{id}/reschedule. Le formulaire complet ne change pas l’activation : utilisez POST /api/allocations/{id}/enabled.

La première création sans condition temporelle garde l’ancien début immédiat/différé. Envoyer expected_effective_at impose start_next=true : un début calendaire doit correspondre à la prochaine frontière ; un début de durée doit rester futur et à une distance ne dépassant pas la plus longue durée configurée depuis l’heure actuelle du serveur. Null explicite renvoie 409 pour condition requise, un format incorrect 400, une heure expirée/modifiée 409. POST /api/allocations/preview ne fait que proposer l’heure initiale, sans créer de règle ; une confirmation échouée ne revient pas à une création sans condition.