Follow-on to #15 (backend token tracking + admin panel).
Summary
Build billing / quota / enforcement on top of the token usage now tracked per turn. #15 only records tokens; this ticket acts on them.
Depends on
#15 — PromptMetric.tokens_in / tokens_out persisted with conversation-level aggregation.
#36 — multi-plan catalog (Founders / Standard / Pro / Business / Backer), feature flags, and prompt-window rate limits. Token-period quotas here should read limits from the same plan model #36 introduces (or extend it), not a second parallel plan table.
#36 — owns plan definitions, Backer whitelist, feature gating (text vs image), and 100/200/300 prompts per 6h. This ticket owns token usage rollups over a billing period and warn/block based on those token caps.
Requirements
Define quota model (per user and/or per company; period-based, e.g. monthly) keyed off plans from #36.
Aggregate token usage per user/company over a billing period (reuse conversation-level rollups from #15).
Enforce limits: warn near cap, block or degrade when exceeded (define behavior).
Admin/reporting: view usage vs. quota; optionally reset/adjust quotas.
Consider provider-usage gaps: turns with null tokens must not silently under-count — document handling.
Document precedence vs #36 prompt-window limits (either gate may block a turn).
Acceptance criteria
Quota configuration per user and/or company (aligned with #36 plans)
Period usage aggregation from PromptMetric tokens
Enforcement path (warn + block/degrade) wired into chat flow
Admin visibility into usage vs. quota
Tests cover aggregation, threshold warnings, and enforcement
Tracking-only is intentionally the scope of #15; billing/quotas/enforcement deferred here. Prompt-count rate limits and feature flags live in #36; this ticket is token-period billing/enforcement.
Follow-on to #15 (backend token tracking + admin panel).
## Summary
Build billing / quota / enforcement on top of the token usage now tracked per turn. #15 only *records* tokens; this ticket *acts* on them.
## Depends on
- #15 — `PromptMetric.tokens_in` / `tokens_out` persisted with conversation-level aggregation.
- #36 — multi-plan catalog (Founders / Standard / Pro / Business / Backer), feature flags, and **prompt-window** rate limits. Token-period quotas here should read limits from the same plan model #36 introduces (or extend it), not a second parallel plan table.
## Related / coordinate with
- #16 — chat UI token (and optionally plan/quota) display
- #36 — owns plan definitions, Backer whitelist, feature gating (text vs image), and **100/200/300 prompts per 6h**. This ticket owns **token usage rollups over a billing period** and warn/block based on those token caps.
## Requirements
- Define quota model (per user and/or per company; period-based, e.g. monthly) **keyed off plans from #36**.
- Aggregate token usage per user/company over a billing period (reuse conversation-level rollups from #15).
- Enforce limits: warn near cap, block or degrade when exceeded (define behavior).
- Admin/reporting: view usage vs. quota; optionally reset/adjust quotas.
- Consider provider-usage gaps: turns with null tokens must not silently under-count — document handling.
- Document precedence vs #36 prompt-window limits (either gate may block a turn).
## Acceptance criteria
- [ ] Quota configuration per user and/or company (aligned with #36 plans)
- [ ] Period usage aggregation from PromptMetric tokens
- [ ] Enforcement path (warn + block/degrade) wired into chat flow
- [ ] Admin visibility into usage vs. quota
- [ ] Tests cover aggregation, threshold warnings, and enforcement
- [ ] Shared plan→limits with #36; no duplicate catalog
## Notes
Tracking-only is intentionally the scope of #15; billing/quotas/enforcement deferred here. Prompt-count rate limits and feature flags live in #36; this ticket is token-period billing/enforcement.
Coordination note: Multi-plan / feature / prompt-quota work is #36.
Split of ownership:
#36 — plan catalog, Backer emails, feature gates (text vs image), prompts per 6h (100/200/300)
#17 (this) — token aggregation over billing period + warn/block on token caps
Depends on #36 for the shared plan→limits model. Either limit may block a generation turn; document precedence in the PR.
**Coordination note:** Multi-plan / feature / prompt-quota work is #36.
**Split of ownership:**
- #36 — plan catalog, Backer emails, feature gates (text vs image), **prompts per 6h** (100/200/300)
- #17 (this) — **token** aggregation over billing period + warn/block on token caps
Depends on #36 for the shared plan→limits model. Either limit may block a generation turn; document precedence in the PR.
Implemented in PR https://git.aimloperations.com/ai_ml_operations/chat_backend/pulls/37 (token-period quotas + aggregation) with FE usage display in https://git.aimloperations.com/ai_ml_operations/chat_web_app/pulls/72. Shares plan model with #36.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Follow-on to #15 (backend token tracking + admin panel).
Summary
Build billing / quota / enforcement on top of the token usage now tracked per turn. #15 only records tokens; this ticket acts on them.
Depends on
PromptMetric.tokens_in/tokens_outpersisted with conversation-level aggregation.Related / coordinate with
Requirements
Acceptance criteria
Notes
Tracking-only is intentionally the scope of #15; billing/quotas/enforcement deferred here. Prompt-count rate limits and feature flags live in #36; this ticket is token-period billing/enforcement.
Coordination note: Multi-plan / feature / prompt-quota work is #36.
Split of ownership:
Depends on #36 for the shared plan→limits model. Either limit may block a generation turn; document precedence in the PR.
Implemented in PR #37 (token-period quotas + aggregation) with FE usage display in ai_ml_operations/chat_web_app#72. Shares plan model with #36.