Verbuchung von Nutzungskontingente

Beginnen Sie mit Nutzungskontingente Eine Regel gehört zu einem dedizierten Ressourcengruppe in einem Arbeitsbereich. Ihre Kontomitgliedschaft bleibt fixiert, solange die Regel existiert. Mitglieder benötigen einen direkten Poolzugriffsrecht und einen persönlichen Schlüssel, der an die Regel gebunden ist. Ein gewöhnlicher Schlüssel wird nicht automatisch konvertiert. Alle Schlüssel eines Mitglieds für die Regel teilen sich ein Hauptbuch.

Nach Anteil unterstützt ein tägliches/monatliches Gesamtbudget oder bis zu 8 Zeitfenster mit einem eigenen Gesamtbudget je Fenster. Dieselben Mitgliederprozentsätze mit einer Summe von höchstens 100 % gelten für alle Fenster. Die Grundlage sind Tokens oder interne USD:

Nach Token Share: Geben Sie die Gesamtsumme in M-Token ein. Gemeldete Input- und Output-Token zählen gegen den Anteil jedes Mitglieds; zwischengespeicherte Inputs sind Teil der Inputs und werden nicht zweimal gezählt.
Nach Betrag Anteil: Eingeben eines internen USD Gesamtwert. Eingaben, zwischengespeicherte Eingaben und Ausgaben jeder Anforderung werden mit den Modellpreisen konvertiert, die mit dieser Regelrevision gespeichert wurden.

Das Mitgliederlimit je Fenster ist dessen Gesamtbudget multipliziert mit dem Anteil, auf die kleinste Einheit abgerundet. Beispielsweise ergeben 25 % von 1 M Tokens 0,25 M. Positive Anteile, die auf null abrunden, werden abgelehnt. Nicht zugeteilte Anteile und Rundungsreste werden nicht automatisch verliehen. Die Zulassung prüft Mitglieder- und Gruppenbudget einschließlich des Verbrauchs ehemaliger Mitglieder. Das Budget wird nicht je Abonnementkonto neu gestartet.

Diese sind Interne HaushalteEine konfigurierte Token-Gesamtsumme gibt die tatsächliche Kapazität des Abonnements nicht an, und interne USD Es handelt sich nicht um ein Barguthaben oder eine Rechnung. SubLane noch die verfügbaren vorgelagerten Quoten überprüft; der Anbieter kann Anträge ablehnen, bevor das interne Budget erschöpft ist.

Zeitfenster-Betragsgrenzen

Nach Zeitfenster ist ein eigener Kontingenttyp. Bis zu 8 Bedingungen verwenden ganze Stunden/Tage von 1 Stunde bis 365 Tagen und ein gemeinsames internes USD-Standardlimit. Jedes Mitglied wird unabhängig verbucht und kann Bedingungen überschreiben. Ein leeres Limit bedeutet nur für diese unabhängige Bedingung unbegrenzt: Nutzung wird erfasst, aber ohne Kontingentgrenze oder vorläufige Risikoreservierung. Jede abgerechnete Anfrage wird einmal mit den gespeicherten Preisen bewertet und zählt in allen Fenstern. Ist eine endliche Bedingung erschöpft oder keine Reservierung mehr möglich, werden neue Anfragen gesperrt.

Zeitfenster beginnen am Aktivierungsanker und erneuern sich unabhängig nach fester Dauer. Die Erneuerung des Fünfstundenfensters löscht keinen Wochenverbrauch. Dies sind keine gleitenden Rückblickfenster; sie folgen nicht den Rücksetzungen des Anbieters. Die Instanzzeitzone ändert nur die Anzeige.

Mitglieder und geplante Änderungen

Aktuelle Mitglieder bearbeiten ändert Anteile oder persönliche Limits sofort. Verbrauch und Reservierungen zugelassener Anfragen bleiben erhalten. Erhöhungen müssen in jedes aktuelle gemeinsame Budget passen; Entfernen und erneutes Hinzufügen löscht keine Nutzung. Bei Gesamtbudget 100 und A mit Verbrauch 40 benötigen je 33 für A/B/C insgesamt 106 und werden abgelehnt; 40/30/30 passt. Nach einer Erneuerung werden alle Fenster erneut geprüft. Eine Planung umgeht keine Budgetlücke.

Budgets, Fenster-Standardlimits und Preise gelten zum vorhandenen Termin oder zur nächsten Grenze des aktuellen Plans. Bei mehreren Fenstern zählt die nächste Grenze der längsten aktuellen Dauer. Anker, Grenzen und Verbrauch bleiben erhalten; ein kurzes Fenster kann noch laufen und nach einer Senkung bereits erschöpft sein. Neue Preise bewerten alte Anfragen nicht neu.

Normale Budget-/Preisänderungen erhalten die gespeicherten Mitglieder unverändert, auch wenn jemand nicht mehr in der berechtigten Liste erscheint. Dies stellt keinen Zugriff wieder her. Neue Empfänger und ein neuer struktureller Zeitraum erfordern aktuelle Gruppenberechtigungen.

Ein unabhängiger Mitgliederplan in der nächsten Version blockiert die automatische Übertragung einer sofortigen Änderung als Konflikt. Prüfen oder stornieren Sie diese Anweisung ausdrücklich; andere kompatible Budget-/Preistermine bleiben bestehen. Hintergrundaktualisierung hängt keine neuen Versionsbedingungen an alte Entwürfe. Verwenden Sie nach einem Konflikt Aktualisieren und prüfen.

Einheit, Kontingenttyp oder Rücksetzplan dürfen nur mit Bestätigung einer echten strukturellen Ersetzung geändert werden. Regel-, Gruppen- und Key-IDs bleiben erhalten; der geplante Aktivierungszeitpunkt wird neuer Messanker. Reine Mitglieder- oder Preisänderungen erzeugen keinen neuen Zeitraum.

Auf nächste Grenze verschieben verschiebt ausschließlich auf die erste natürliche Grenze strikt nach dem gespeicherten Termin. Maßgeblich ist der aktuelle Plan, vor der ersten Aktivierung der anfängliche Plan. Prüfen und bestätigen Sie die Serverzeit; abgelaufene oder geänderte Bedingungen liefern einen Konflikt.

Geplante Änderung abbrechen verlangt eine bereits wirksame aktuelle Version. Besteht nur die anfängliche Planung, sind Pause oder Verschiebung möglich. Eine anfängliche Verschiebung ersetzt die Version atomar. Eine Pause löscht weder lesbare Konfiguration noch Termin und verweigert auch nach der ersten Aktivierung weiterhin den Zugriff.

Anfängliche Mitgliederkorrekturen verwenden den vollständigen Editor (PATCH /api/allocations/{id}). Sie verlangen das geprüfte Revisionspaar und den Aktivierungszeitpunkt, behalten Termin und Anker bei und prüfen die aktuellen Gruppenrechte der Empfänger erneut. Sie sind nur ohne aktuelle Version und ohne erfasste Anfragen zulässig. Revision, Metadaten und Audit werden gemeinsam in einer Transaktion gespeichert; Fehler oder das Überschreiten der Aktivierung rollen alles zurück. Die anfängliche Planung darf weiterhin nicht abgebrochen werden.

Unterscheidet sich die genehmigte nächste Version strukturell tatsächlich von der aktuellen, wird die bestehende Bestätigung eines neuen Zeitraums auch bei unveränderter Struktur des Entwurfs angeboten. Erneutes Bestätigen erlaubt die Bearbeitung ihrer Mitglieder. Normale Budget-/Preisänderungen behalten Mitglieder und Anker ohne erneute Bestätigung. Wird diese optionale Bestätigung zurückgenommen, erscheint und gilt wieder der gespeicherte Mitgliederplan. Eine Ersetzung verlangt weiterhin einen echten Strukturunterschied zur aktuellen Version.

Für preiswerte Zertifikate ()Betrag, Anteil des Betrags, und Nach Zeitfenster), SubLane Die vom dedizierten Pool unterstützten Modelle werden beim Speichern einer Revision gefüllt. Von Benutzern bereitgestellte Preise setzen diese Momentaufnahme nicht außer Kraft. Wenn ein Modell keinen aktuellen Katalogpreis hat, wird seine zuvor gespeicherte Rate wiederverwendet, wenn verfügbar. Ein neu entdecktes Modell ohne Preis wird im Snapshot weggelassen, so dass Anfragen an es blockiert bleiben, bis eine preisliche Revision wirksam wird. Preiserfassungswarnungen werden berechnet, wenn eine Regel gelesen wird, nicht in seiner Revision gespeichert: Ein wiederhergestellter Katalogpreis löscht die Katalogwarnung automatisch, während ein Modell, das im gespeicherten Preis-Snapshot fehlt, markiert bleibt, bis eine neue Revision sie enthält. Nicht verfügbare Kontokataloge behalten zuvor gespeicherte Raten und zeigen eine Warnung an, bis die Entdeckung wiedererlangt ist. Speichern scheitert nur, wenn kein nutzbarer Preis verbleibt. Ohne einen geladenen Preiskatalog oder einen gespeicherten Preis-Cache kann kein neuer preislicher Zuschlag erstellt werden; aktualisieren Sie den Katalog oder stellen Sie einen Preisrückfall bereit, bevor Sie erneut versuchen.

Bei einem Modell ohne gespeicherten Preis zeigt die Warnung, wann eine jetzt gespeicherte Korrektur wirksam würde. Zeitfenster verwenden die nächste Grenze der längsten aktuellen Dauer; wiederholtes Speichern macht den Preis nicht sofort nutzbar. Eine geplante Version zeigt ihren eigenen Termin und warnt, dass das Modell ohne korrigierte Ersatzversion auch nach Aktivierung gesperrt bleibt.

Direkte Limits und ausstehende Nutzung

Nach Tokens Setzt das token-limit eines mitglieds direkt ein. Betrag Setzt eine direkte interne USD Limit unter Verwendung von gesparten Modellpreisen: Beide verwenden den gleichen Token oder die gleiche Preisrechnung wie die entsprechende Aktienbasis.

Verlässliche endgültige Nutzung wird ohne Warten auf Anbieterprozentsätze abgerechnet. Ohne verlässliche Summen bleibt eine Anfrage zur Korrektur offen; Teilwerte sind sichtbar, aber keine Belastung oder Reservierung. Aktive Anfragen reservieren in jedem endlichen Fenster 10 % des bei Zulassung erfassten Mitgliederlimits, mindestens eine Einheit. Spätere Änderungen verändern diese Reservierung nicht. Pro endlichem Fenster sind höchstens vier gleichzeitig laufende, darin gestartete Anfragen je Mitglied erlaubt; gemeinsame Budgets prüfen auch die Gruppenexposition. Am Ende wird die Reservierung frei. Große Anfragen können Limits überschreiten, unbekannte Nutzung lässt die Exposition unvollständig: Es sind weiche Grenzen. Zuerst erscheinen die neuesten 256 offenen Einträge. Für die Zuordnung zählt die Zulassung nach der Warteschlange, für Diagnosen die Ankunft.

für Codex Bäche, SubLane kann bis zu 3 Sekunden lang weiterlesen, nachdem der Client die Verbindung getrennt hat, um eine vertrauenswürdige Endnutzung zu erfassen. Ein fehlgeschlagenes Terminalereignis, das die vollständige Nutzung beinhaltet, kann auch in Rechnung gestellt werden. Wiederholte vorgelagerte Fehler kühlen das betroffene Konto vorübergehend; eine erfolgreiche Antwort ohne Endnutzung bleibt ausstehend, ohne das Konto zu kühlen. SubLane wiederholt diese anfrage, bevor sie mehr zulassungsgestützte arbeit für das betroffene mitglied zulässt; andere mitglieder können fortfahren.

Tägliche/monatliche Regeln behalten Datum und Uhrzeit in der Instanzzeitzone; fehlende Monatstage fallen auf den letzten Tag des Monats. Standard sind täglich 00:00 oder am Monatsersten 00:00. Normale Änderungen erhalten den Messanker. Pausen und Berechtigungsentzug sperren neue Anfragen und WebSocket-Runden ohne Verlaufsverlust. Kontingentabfragen, Reset-Karten, erneute Autorisierung und Neustarts füllen lokale Budgets nicht auf.

Auswahl Beginn der nächsten Periode beim Erstellen einer Zeitfensterregel wird diese nach der längsten konfigurierten Dauer gestartet.

Lesen und korrekte Salden

Mitglieder sehen ihre eigene Kontingent unter VerwendungWorkspace-Administratoren geöffnet Ressourcenzuweisungen → Nutzung anzeigen Alle konfigurierten Zeitfenster werden unter einem Mitglied mit eigenem Limit, verwendetem Betrag, Restbetrag, Risikoexposition und Reset-Zeitpunkt angezeigt; der Mitgliedsstatus spiegelt die restriktivste Bedingung wider. USD neben gemeldeten Token; Token Salden verwenden M, wobei 1 M = 1,000,000 tokensPersönliche Berichte legen keine Identitäten von Abonnementkonten offen.

Der Saldo trennt verwendet (abgerechnete Nutzung) aus Anträgen während des Fluges und ausstehende Nutzung im laufenden Zyklus. Vorübergehende Reservierungen spiegeln nur Anträge während des Fluges wider; ausstehende Nutzung bleibt zur Korrektur sichtbar und zählt nicht als genutzte Kontingent oder Reservekapazität. Neue Anfragen vorübergehend angehalten wenn eine andere Anfrage mehr Reservierung benötigt als die aktuelle Headroom, oder vier Anfragen noch im Flug sind. Der Status folgt der gleichen Risikoprüfung des aktuellen Zyklus wie der Gateway-Zugang. Es handelt sich um eine Momentaufnahme und kann sich ändern, wenn die Anforderungen abgeschlossen sind. Ausstehende Aufzeichnungen außerhalb des aktuellen Zyklus bleiben zur Korrektur sichtbar, aber unterbrechen die Zulassung nicht.

Wenn ein ausstehender Eintrag nicht automatisch aufgelöst werden kann, kann ein Administrator Eingabe-, Ausgabe- und Zwischenspeichersummen eingeben, die durch vertrauenswürdige Beweise gestützt werden. Die Korrektur verwendet die gespeicherte Abrechnungsregel der Anforderung und schreibt ein Auditereignis. Behandeln Sie fehlende Nutzung nicht als Null oder geben Sie erfundene Gesamtsummen ein.

Workspace-Administratoren verwalten Regeln unter /api/allocations; Mitglieder lesen ihre eigenen Salden bei /api/me/allocationsSchlüssel binden an eine Regel mit scheme_id. siehe Arbeitsbereiche und persönlich API Schlüssel.

API-Schreibbedingungen

Leseantworten behalten ihr Format und ergänzen write_conditions mit den nullable Feldern expected_current_revision_id und expected_next_revision_id. Beide sind für Änderungen bestehender Regeln Pflicht: vollständiges PATCH, Mitglieder, Abbruch/Verschiebung und Ersetzung. Fehlende oder veraltete Bedingungen liefern HTTP 409 ohne Änderung. Prüfen Sie die Daten erneut; alte Entwürfe dürfen nicht automatisch mit neuen IDs wiederholt werden. Explizites Aktivieren/Pausieren und anfragenbezogene Korrekturen behalten ihre Verträge.

Künftige Versionen verlangen zusätzlich den serverbestätigten UTC-Sekundenwert expected_effective_at; strukturelle Ersetzungen auch confirm_replacement=true. POST /api/allocations/{id}/preview akzeptiert schedule, reschedule oder replace. Mitglieder verwenden POST /api/allocations/{id}/members, geplante Aktionen POST /api/allocations/{id}/cancel und POST /api/allocations/{id}/reschedule. Vollständiges Speichern ändert nicht die Aktivierung; verwenden Sie POST /api/allocations/{id}/enabled.

Die erste Erstellung ohne Zeitbedingung behält sofortigen/verzögerten Beginn bei. Mit expected_effective_at ist start_next=true nötig: Kalenderstarts müssen der nächsten Grenze entsprechen; Zeitfensterstarts müssen in der Zukunft und höchstens um die längste konfigurierte Dauer nach der aktuellen Serverzeit liegen. Explizites null liefert 409 wegen fehlender Pflichtbedingung, ungültiges Format 400 und abgelaufene/geänderte Zeit 409. POST /api/allocations/preview liefert nur den Startvorschlag, erstellt aber keine Regel. Ein Bestätigungsfehler fällt nicht auf bedingungslose Erstellung zurück.