# Token limit check

Row 125 (#1619), REQ-LIMIT-3 and REQ-LIMIT-4, limit-check interface 2. Enable
with `"plugins": { "limit-check": ["token-limit"] }` in the organization file,
keeping its other plug-in kinds. Human changes use `mosaic plugins set` and the
current revision.

It enforces `launch.limits.tokens`: per role instance (`instances`), provider
(`providers`), provider and model (`models.<provider>.<model>`) and key
(`keys`). Each limit is `{limit, since}`.

- A count is `input + output + cacheWrite + cacheRead` summed over the known
  per-turn records whose subject matches and whose `at` is at or after `since`.
  An unknown turn adds nothing; `unknownTurns` counts the distinct unknown
  turns apart, so a count is a floor, not proof.
- With no usage source switched on, every turn's record is unknown (source
  `@none`), so every limit counts zero.
- `mayLaunch` and `mustStop` answer the first limit, in the order above, that
  covers the subject and whose count is at or over it. A limit of 0 refuses
  every launch of its subject.
- A key matches a record's `account`. Until accounts are named (row 126),
  every record's account is null, so a key limit matches nothing and `report`
  shows it as `not enforced: no records name a key` (lead decision 150, Q1).
- Counts are summed as BigInt; one past `Number.MAX_SAFE_INTEGER` is reported
  as a digit string.

The module is pure: it reads no file and no store. A bad `since` or record
`at` throws `bad-time`, a bad amount `bad-record`, and records that aren't a
list `bad-records`; core turns any throw into a refusal, a stop, or `check
failed` (fail closed).