Skip to main content
Pylva controls should start as visibility, then alerts, then enforcement. Use controls after telemetry is flowing and the dashboard shows the customer, step, pricing, and event data you expect.

​
Choose the right control

Use budget hard stops to cap customer usage.

​
Rollout path

  1. Confirm telemetry is trusted: customer, step, pricing, and dashboard events are visible.
  2. Start with alert-only rules or warn mode before hard stops.
  3. Use drafts for review before production activation.
  4. Activate narrow scopes first: one customer, one step, or one model path.
  5. Catch PylvaBudgetExceeded and return a product-specific fallback.
  6. Monitor rule events, warnings, alerts, and budget behavior after activation.
  7. Expand scope only after the narrow rollout behaves as expected.
  8. Roll back by disabling the rule or moving it back to draft.
For how alerts reach your team or systems, see Alert Delivery And Webhooks.

​
Pre-call and post-call

Pre-call controls can block or steer a call before provider spend happens. Budget hard stops, model routing, and reliability failover are pre-call controls. Post-call controls alert after usage is recorded. Cost thresholds and margin protection do not stop the provider call that already happened.

​
Hard stops

Hard stops only block when the SDK has an active cached rule it can enforce safely. When a hard stop fires, the SDK raises PylvaBudgetExceeded. Catch it and return a fallback such as a cached answer, smaller model path, queued job, “try again later” response, or human handoff. Avoid retry loops that immediately reissue the same expensive call.

​
Fail-open behavior

Pylva fails open when rule state, pricing, or backend access is unavailable, so Pylva does not become the reason your agent is down. That means a call may proceed if the SDK does not have the active rule state needed to enforce safely. Review rule activation, SDK cache timing, and budget sync behavior when testing hard stops.