Skip to main content

Unified Access Budgets

Budget-policy APIs let you create, update, inspect, and simulate hourly, daily, weekly, and monthly limits. The current Unified Access reservation path does not call the budget-policy enforcement function, so these policies do not yet cap live request spend before wallet reservation. The wallet balance check is the active funding gate.

Budget windows​

You can combine multiple windows in a single stored policy:

  • Hourly — short-term burst control
  • Daily — team or organization spend guardrail
  • Weekly — shared runway for recurring usage
  • Monthly — invoice and cost-center control

The effective-policy and simulation flows calculate the most restrictive matching limit. That result is not currently applied by live wallet reserve.

Policy design tips​

  • Start with monthly org-wide limits, then layer stricter team or service-user budgets.
  • Pair access policies with budget policies so only approved users can consume the most expensive models.
  • Use simulation and effective-budget endpoints to review policy intent, and do not describe the result as live enforcement until the reserve path is wired.

Wallet reservation and lot attribution​

The reservation path checks and debits the wallet's total available balance. It does not treat seat credits, wallet top-ups, and auto top-up as three attempts to fund the same request.

When the ledger attributes that debit to credit lots, it consumes monthly seat- credit lots before wallet-top-up lots. That order is accounting attribution inside one wallet balance, not a separate reservation fallback chain.

If total wallet balance cannot cover the reservation, the request is rejected before it reaches the model provider. Add funds, then retry the request.

Auto top-up​

The API stores auto-top-up settings and exposes related history, but the current runtime does not initiate the first auto-top-up attempt when a reservation is insufficient or a settlement lowers the balance. The retry sweep only processes an already-created retry state, so it does not make auto top-up an active funding path on its own.

Do not rely on auto top-up to rescue the current request or replenish later requests until that initial execution hook is implemented. Use manual wallet top-up and balance monitoring in production.

  1. Create read-only dashboards for budget state and wallet balance.
  2. Apply alerting on repeated near-limit events.
  3. Use wallet balance controls for the active hard stop while you evaluate stricter policy windows for a future enforced rollout.

Next steps​