qbrix
On this page

Start hereHow qbrix works

How qbrix works

qbrix runs two paths that never block each other.

The selection path answers select() — it picks a variant and returns. The learning path consumes feedback() and updates what the policy knows. Selection stays fast because it never waits for learning, and learning stays thorough because it never has to fit inside a request.

Everything below is a contract you can design against: what happens on each path, what qbrix guarantees when things go wrong, and how long changes take to land.

The selection path

  1. Your appselect()
  2. Gaterollout, schedule, rules
  3. Policypicks a variant
  4. Responsevariant + token
Your app never waits on training to get a decision.
  1. qbrix authenticates the request — API key or JWT.
  2. If the experiment has a feature gate, the gate evaluates rollout, schedule, and targeting rules.
  3. If the gate commits a variant, it returns immediately. The policy is never consulted.
  4. Otherwise the policy picks a variant from its current parameters.
  5. The response carries the variant plus a signed selection token.

When parameters are warm, step 4 runs entirely in memory — no database call, no network hop, no lock. That's the whole reason selection is fast, and it's why selection latency doesn't move when your feedback volume does.

The learning path

  1. Your appfeedback()
  2. Queueddurably, then returns
  3. Trainedin batches, per experiment
  4. Publishednew parameters
feedback() returns at step 2 — everything after it happens on qbrix's own time.
  1. qbrix verifies the signed selection token from your feedback() call.
  2. The reward is queued.
  3. qbrix trains in batches, per experiment.
  4. Updated parameters are published.
  5. Selection picks them up on the next refresh.

feedback() returns as soon as the reward is queued — it does not wait for training. A slow-training experiment never delays another one, and it never delays selection.

Tip

Feedback is asynchronous by design. Don't write client code that expects a reward to be reflected in the very next select() call — see Timings for the windows that actually apply.

Timings

These are the only latency numbers that affect how you write your integration.

ChangeTime to take effect
Feedback → updated policy parametersUp to 60s
Policy or experiment config changeUp to 5 min
Feature gate changeUp to 30s
New experiment or poolImmediate

Parameter updates are eventually consistent. During the window, some requests may still be served by the previous parameters — which is correct behaviour for an adaptive system, not a defect. Learning is statistical; a handful of requests either side of a refresh changes nothing about where the policy converges.

Guarantees

No feedback is lost

Rewards are durably queued before feedback() returns. If training is interrupted mid-batch, in-flight rewards are recovered and reprocessed on restart. An unclean shutdown does not drop rewards.

A broken gate never breaks a request

If a feature gate fails to evaluate for any reason — malformed config, missing metadata, an unexpected error — it falls through to normal policy selection instead of failing the request. This is deliberate: for gate logic, qbrix chooses availability over correctness. A gate misconfiguration degrades targeting, never uptime.

Feedback correlation needs no session state

Every selection response includes an HMAC-signed token encoding the experiment, the chosen variant, and the request context. When feedback arrives, qbrix verifies and decodes that token to correlate the two.

This means you don't need to store anything between select() and feedback(). The token is the correlation. Pass it through your queue, your webhook, or your job runner, and send it back whenever the outcome is known — minutes or hours later is fine.

Rate limits protect the hot path only

A flat per-principal abuse guard applies to /api/v1/agent/select and /api/v1/agent/feedback. Management endpoints — pools, experiments, gates, billing — are not rate-limited.

The limit is not tiered. Plans meter on selection volume and bill overage; they don't throttle your request rate. See Plans & limits.

Next steps