Quotas and cost accounting: the hold-and-settle engine

Tetto che valgono prima che la spesa accada

I tetti di utilizzo in una installazione AI multi-utente vivono di solito in una dashboard - un rapporto che leggi dopo che la bolletta esiste. Il quota engine di Simmetric Chat li colloca prima: nel percorso della richiesta, prima della prima chiamata LLM. Il motore copre tre generi di tetti - token, storage e costo (contabilità a soldi veri, in cents) - e lo fa con la stessa forma ovunque: un ledger come verità del consumo, bilanci derivati, gate pre-turn, e un fallimento sempre esplicito.

Questo articolo percorre il progetto: l'invariante "nessun secondo metro" poggiato sul ledger, la catena di risoluzione che decide il tetto di ogni utente, come funziona la finestra mobile del reset (la storia non viene mai cancelata), e la prenotazione a due fasi hold-and-settle che rende la quota di costo una gate vera invece che un allarme rinviato.

Uno strumento dell'operatore (la classe della feature Community). Fatti da FACT-CENSUS.md F-QUOTA-1.

Nessun secondo metro

L'invariante non negoziabile: la verità del consumo resta nel ledger del token-usage ESISTENTE della piattaforma. Bilanci, hold e ancore di reset sono stato derivato - mai una seconda tabella di contatori che potrebbe scostarsi dalla realtà. Le conseguenze:

• Un reset è un'ancora del ledger, non una cancellazione. Un reset scrive una riga-ancora che cinge la finestra mobile; la storia dell'uso/dei costi non viene mai cancellata né azzera. L'operatore può fare audit all'indietro in qualunque momento.
• Le gate sono a livello di servizio e pre-turn - corrono dove vivono i dati del dominio (prima della prima chiamata LLM nell'orchestratore, prima dell'ingest nelle vie di caricamento). Non c'è un middleware da by-passare: il controllo sta nel percorso del servizio stesso.
• La matematica dei soldi è Decimal→cents. Ogni calcolo di costo passa per il layer decimale e atterra come cents INTERI - mai virgola mobile, mai deriva di arrotondamento.

La catena di risoluzione

Il tetto di un utente si risolve in una catena a tre livelli, in ordine:

1. L'override per-utente - l'amministratore fissa direttamente i tetti token/storage/costo di un utente nominato.
2. Il preset dell'installazione - le chiavi dei default installazione nella configurazione di sistema (tetto token, storage GB, tetto di costo in EUR).
3. Illimitato - il sentinel "0"/vuoto significa NON configurato, e il motore fallisce aperto: zero cambi di comportamento per le installazioni che non toccano mai le quote.

Fail-open è una funzione con una forma esplicita: il quota engine è uno strumento opt-in per l'operatore, e "non configurato" non deve mai diventare in silenzio "bloccato".

I tre generi

Le quote token girano su una somma di uso finestrata dal ledger, cinta dall'ancora di reset più recente. La risoluzione restituisce un limite più il suo livello sorgente - l'interfaccia dell'operatore può dire quale riga ha deciso, per utente. Il superamento = un errore di quota nominato il cui payload la frontend, il widget e i gestori dei connettori leggono tutti allo stesso modo.

Le quote storage si applicano nelle vie di caricamento prima di dislocare sul collector: l'override per-utente, il default dell'installazione, o l'illimitato.

Le quote di costo - il branco a soldi veri - sono il progetto hold-and-settle, qui sotto.

Hold-and-settle: una prenotazione a due fasi

Una spesa in token accade quando accadono i token; una spesa in euro accade mentre lo stream corre. La gate di costo dunque prenota PRIMA della chiamata LLM e liquida alla giuntura dell'uso:

1. Reserve (prima della chiamata) - un update condizionale il cui predicato il database valuta row-locked (spent + stima ≤ tetto): N richieste concorrenti si SERIALIZZANO invece di correre tutte attraverso un check stantio, più la riga di hold nella stessa transazione (la prenotazione è atomica col controllo).
2. Settle (alla giuntura) - l'hold si finalizza e rimborsa stima meno effettivo. La finestra accettata è l'overshoot in volo (effettivo > stima) - nessun kill a metà stream per un motivo di costo; l'invariante a riposo è esatta: spesa liquidata + hold aperti ≤ tetto.

Quella coppia dà alla quota di costo la proprietà che un rapporto non può avere: il tetto si applica prima che la spesa si impegni col modello, via una prenotazione row-locked onesta sotto concorrenza.

Pricing: per modello, congelato a snapshot, mai gratuito in silenzio

La sorgente di pricing per riga: uno snapshot congelato dei model-costs dove esiste (una rettifica del tasso mai ri-scrive la storia), altrimenti le tariffe di fallback dell'installazione (la dottrina SC-4: un modello senza prezzo non by-passa mai la quota di costo - un piano non-zero built-in si applica con un log warn-once, così nulla può apparire gratuito per omissione). Le valute: il ledger registra totali per valuta (USD, EUR, GBP, JPY, CNY, INR in v1 - nessuna conversione); il costo atterra all'evento done dello stream.

La configurazione vive nel percorso degli operatori: Settings → Providers → l'azione pricing del modello (le tariffe input/output per 1M token + la valuta), o il pricing per-utente per le chiavi own-provider. N/A significa "configura una tariffa"; $0.00 significa esplicitamente gratuito (i modelli locali riportati a 0).

Il principal del widget

I visitatori anonimi del widget non sono utenti: il consumo del widget si lega al principal dell'organizzazione del widget - il traffico widget attinge dalla catena di quota di quell'organizzazione invece di inventare identità per-visitatore. Il traffico dei connettori e i chat interni condividono lo stesso unico orchestratore, quindi le gate pre-turn coprono uniformemente le tre classi di superficie di chat.

Per continuare

La guida porta il riferimento operativo completo - le chiavi, gli endpoint, il comportamento del reset, il dettaglio del pricing - su /it/docs/quotas-and-costs:

• Quotas and costs - la guida
• La versione in linguaggio semplice
• Fatti in questo post: riga FACT-CENSUS.md F-QUOTA-1 (i tre generi, il ledger senza secondo metro, il motore hold-and-settle)

• Richiedi una demo

Provenance: Simmetric Chat docs/QUOTAS.md (v0.28.1, Phases 207/216) + docs/MODEL_COSTS.md (Phases 203/209/216), quotaService.ts/costQuotaService.ts - allo stato documentale fissato dal census (SHA aca5b8ff).