Cuotas y contabilidad de costes: el motor hold-and-settle

Techos que se aplican antes de que el gasto pase

Los techos de uso en una instalación AI multiusuario suelen vivir en un panel - un informe que lees después de que la factura existe. La quota engine de Simmetric Chat los coloca antes: en el camino de la petición, antes de la primera llamada LLM. El motor cubre tres clases de techos - tokens, almacenamiento y coste (aritmética de dinero real, en cents) - y lo hace con la misma forma en todos lados: un ledger como verdad del consumo, saldos derivados, puertas pre-turn, y un fallo siempre explícito.

Este artículo recorre el diseño: el invariante "ningún segundo medidor" apoyado en el ledger, la cadena de resolución que decide el techo de cada usuario, cómo trabaja la ventana móvil del reset (la historia nunca se borra), y la reserva hold-and-settle en dos fases que vuelve al techo de coste una puerta real en lugar de una alarma aplazada.

Una herramienta del operador (la clase Community). El dato: FACT-CENSUS.md F-QUOTA-1.

Ningún segundo medidor

El único invariante no negociable: la verdad del consumo queda en el ledger de token-usage EXISTENTE de la plataforma. Saldos, holds y anclas de reset son estado derivado - jamás una segunda tabla de contadores que pudiera escabullirse de la realidad. Las consecuencias:

• Un reset es un ancla del ledger, un borrado. Un reset escribe una fila-ancla que acota la ventana móvil; la historia de uso/costes nunca se borra ni se pone a cero. El operador puede auditar hacia atrás en cualquier momento.
• Las puertas son de nivel de servicio y pre-turn - corren donde viven los datos del dominio (antes de la primera llamada LLM en el orquestador, antes del ingest en las vías de subida). No hay middleware que esquivar: el chequeo está en el propio camino del servicio.
• La matemática del dinero es Decimal-a-cents. Cada cálculo de coste pasa por la capa decimal y aterriza en cents ENTEROS - nunca coma flotante, nunca deriva de redondeo.

La cadena de resolución

El techo de un usuario se resuelve por una cadena de tres niveles, en orden:

1. La sobreescritura por usuario - el admin fija directamente los techos de token/almacenamiento/coste de un usuario nombrado.
2. El preset de instalación - las claves de valores por defecto a nivel de instalación en la configuración del sistema (techo de token, GB de almacenamiento, techo de coste en EUR).
3. Ilimitado - el centinela "0"/vacío = NO configurado, y el motor falla abierto: cero cambio de comportamiento para las instalaciones que jamás tocan las cuotas.

El fail-open es una característica con forma explícita: la quota engine es la herramienta opt-in del operador, y "sin configurar" nunca debe convertirse silenciosamente en "bloqueado".

Las tres clases

Las cuotas de token ruedan sobre una suma de uso en ventana desde el ledger, acotada por la ancla de reset más reciente. La resolución devuelve un límite y su nivel de origen - la interfaz del operador puede señalar qué fila decidió, por usuario. Superar = un error de cuota nombrado cuyo payload es la llave que la frontend, el widget y los gestores de conectores comparten.

Las cuotas de almacenamiento se imponen en las vías de subida antes de despachar al collector: la sobreescritura por usuario, el defecto de instalación, o ilimitado.

Las cuotas de coste - el brazo de dinero real - son el diseño hold-and-settle, abajo.

Hold-and-settle

Un gasto en token pasa cuando pasan los tokens; un gasto en euro pasa mientras el stream corre. La puerta de coste por eso reserva ANTES de la llamada LLM y liquida en la costura del uso:

1. Reserve (antes de la llamada) - una actualización condicional cuyo predicado la base evalúa con bloqueo de fila (gastado + estimado ≤ techo): N peticiones concurrentes SE SERIALIZAN en vez de colarse todas por el mismo chequeo caducado, más la fila de hold en la misma transacción (la reserva es atómica con el chequeo).
2. Settle (en la costura) - el hold finaliza y reembolsa estimado menos real. La ventana aceptada es el sobrepaso en vuelo (real > estimado) - sin kill a mitad de stream por un motivo de coste; el invariante en reposo es exacto: gastado liquidado + holds abiertos ≤ techo.

Ese par le da al techo de coste la propiedad que un informe no puede tener: el techo se aplica antes de que el gasto se comprometa con el modelo, mediante una reserva con bloqueo de fila honesta bajo concurrencia.

El pricing: por modelo, congelado por instantánea, nunca gratis en silencio

La fuente de pricing por fila: una instantánea congelada de costes por modelo donde exista (un retoque de tarifa nunca reescribe la historia), si no las tarifas de reserva de la instalación (la doctrina SC-4: un modelo sin precio nunca esquiva el techo de coste - un suelo no nulo integrado aplica con un log warn-once, de modo que nada puede parecer gratis por omisión). Monedas: el ledger sigue los totales por moneda (USD, EUR, GBP, JPY, CNY, INR en v1 - sin conversión); el coste aterriza en el evento done del stream.

La configuración vive en el camino de los operadores: Settings → Providers → la acción de pricing del modelo (las tarifas de entrada/salida por 1M tokens + la moneda), o pricing por usuario para las llaves own-provider. N/A significa "configura una tarifa"; $0.00 significa explícitamente gratis (los modelos locales devueltos a 0).

El principal del widget

Los visitantes anónimos del widget no son usuarios: el consumo del widget se liga al principal de la organización del widget - el tráfico del widget bebe de la cadena de cuota de esa organización en vez de inventar identidades por visitante. El tráfico de conectores y los chats internos comparten el mismo único orquestador, así que las puertas pre-turn cubren de forma uniforme las tres clases de superficie de chat.

Para seguir

La guía lleva la referencia completa del operador - las claves, los endpoints, el comportamiento del reset, el detalle del pricing - en /es/docs/quotas-and-costs:

• Quotas and costs - la guía
• Datos de este post: fila FACT-CENSUS.md F-QUOTA-1 (las tres clases, el ledger sin segundo medidor, el motor hold-and-settle)

Provenance: Simmetric Chat docs/QUOTAS.md (v0.28.1, Phases 207/216) + docs/MODEL_COSTS.md (Phases 203/209/216), quotaService.ts/costQuotaService.ts - en el estado documental fijado por el census (SHA aca5b8ff).