Plans & limits
qbrix meters on selections. Every plan includes a monthly selection allowance; usage beyond it is billed as overage rather than blocked.
Plans
| Plan | Included selections / mo | API keys | Seats | Active experiments |
|---|---|---|---|---|
| Free | 100,000 | 2 | 3 | 3 |
| Starter | 1,000,000 | Unlimited | Unlimited | Unlimited |
| Growth | 10,000,000 | Unlimited | Unlimited | Unlimited |
| Scale | 50,000,000 | Unlimited | Unlimited | Unlimited |
| Enterprise | Custom | Unlimited | Unlimited | Unlimited |
The free tier is the only one with hard resource caps. On every paid plan, API keys, seats, and active experiments are unlimited — the allowance is the only thing that meters.
How metering works
Only select() calls count. Feedback, pool and experiment management, gate changes, and console activity are never metered.
Usage accrues against your monthly allowance. Once you pass it, additional selections are rated as overage and appear on your next invoice — nothing stops serving, and no request is rejected for being over the allowance.
Gate fall-throughs still count as selections. A request that the gate answers with the default arm is a decision qbrix made for you, so it meters like any other.
Rate limits
Request rate is not tiered — moving up a plan buys you allowance, not throughput.
A flat per-principal abuse guard protects the two operational endpoints:
| Endpoint | Rate limited |
|---|---|
/api/v1/agent/select | Yes |
/api/v1/agent/feedback | Yes |
| Pools, experiments, gates, billing | No |
Authentication endpoints (login, register, refresh, forgot-password, reset-password) carry their own separate pre-auth limiter, applied per IP and per email, returning 429 with a Retry-After header.
Feature availability
Some capabilities require a minimum plan:
| Feature | Minimum plan |
|---|---|
| Insights & analytics | Growth |
| Event log | Scale |
| SSO | Scale |
| Custom roles | Scale |
Roles & permissions
Every workspace member holds one of three roles. Permissions are granted as scopes.
| Capability | Admin | Member | Viewer |
|---|---|---|---|
| View pools, experiments, gates | Yes | Yes | Yes |
| Create & edit pools | Yes | Yes | — |
| Create & edit experiments | Yes | Yes | — |
| Delete pools & experiments | Yes | Yes | — |
Call select() | Yes | Yes | Yes |
Send feedback() | Yes | Yes | — |
| Edit feature gates | Yes | Yes | — |
| View metrics & insights | Yes | Yes | Yes |
| View the event log | Yes | Yes | Yes |
| Invite & remove members | Yes | — | — |
| Assign roles | Yes | — | — |
| Manage billing | Yes | — | — |
Viewer can read every resource and call select(), but cannot write anything — including feedback. That combination is deliberate: it lets a read-only integration serve decisions without being able to influence what the policy learns. Member covers all day-to-day experiment work. Admin adds team, role, and billing control.
API keys carry their own scopes, set per key when you create it. A key never has more access than the role that created it.
Next steps
- Workspace & API keys — invite members and manage keys
- How qbrix works — the guarantees behind the limits