api_plan
Set request and compute allowances, per-minute rate, meter type, period policy, and optional price metadata.
Metering guide
Give a user a plan and test its limit.
Create a plan, assign an active member and period, enable metering for the intended route, then observe usage and denial beyond the quota.
- Plans
- Usage + quota
- Hard denial
Configure plans and quotas.
api_member
Assign one user to the intended active plan and define the current period.
api_usage
Inspect completed metered events with endpoint, method, status, cost, and metadata.
api_quota
Inspect aggregate request, compute-unit, and byte counters for the member period.
Test enforcement separately from accounting.
- A route without metering behaves as intended and does not unexpectedly consume the plan.
- Successful resource, action, or LLM calls produce the expected usage unit and cost.
- The last allowed call succeeds and the next call is denied by hard quota enforcement.
- The per-user, per-plan minute limit works across instances when shared Olric counters are configured.
- A new period resets or selects counters according to the configured membership dates.
- Failed requests and token usage are accounted for according to the intended policy.
- A post-metering credit hook is tested as ledger behavior, not presented as the generic prepaid denial boundary.
Metering is a product feature. URL-based IP traffic limiting is a separate operational safeguard and should not be presented as the same control.
Quota test
Test entitlement and traffic controls separately.
- Give a disposable member a small allowance and confirm admitted work increases the intended meter.
- Exhaust the allowance and verify quota denial occurs before more measured work begins.
- Reset or change plan membership and confirm the expected next request.
- Test post-metering credit hooks independently from the hard quota.
- Configure URL rate limiting separately; it bounds request frequency by client IP and exact path, not commercial entitlement.