Diagnose exhausted quota separately from full resource capacity

Identify which dimension is exhausted

A monthly usage allowance measures accumulated activity. Concurrency measures how many resources can be active together. An object limit counts resources such as inboxes or domains, and a request rate limit controls API frequency. An account can have plenty of one dimension and no room in another.

Lupin’s shared plans express allowances and resource limits separately. For example, runtime seconds and browser concurrency are different fields. A client should retain the structured rejection code and affected product instead of showing every refusal as insufficient credit. The proposed repair depends on the actual dimension.

Inspect active resources before increasing spend

If concurrency is full, list resources through an authorized scope and identify work that is truly finished. Cleanup can release capacity, but verify the terminal state rather than assuming that an old user interface tab means the provider resource stopped. An unknown cleanup outcome should remain visible.

A retail overage cap does not automatically buy more concurrent sessions. Lupin documents no self-service purchase flow for additional browser concurrency or nondefault sandbox sizes. Plan changes and optional capacity need the supported workflow; an agent should not promise immediate availability from a generic payment setting.

Check allowances and reservations together

A remaining allowance display can differ from immediately admissible work when reservations already commit part of it. Read settled and reserved quantities and align the billing period. Concurrent jobs can legitimately consume the remaining headroom after an earlier dashboard snapshot.

Provider-cost budgets add another admission gate, including checks for unpriced or unbounded activity. A quota repair does not resolve that gate. Keep the account’s retail quantity, provider-cost reservation and resource capacity in separate diagnostic fields so a support operator can see which condition actually prevented dispatch.

Exclude throttling and unavailable providers

A request rate limit calls for queued work and the returned retry delay, not a bigger monthly allowance. A missing provider binding or unsupported capability calls for deployment or product readiness work. Permissions and verification gates are separate again. Inspect the error reference and current capability state before changing paid settings.

Do not attempt to bypass a gate by rotating keys, creating another workspace or repeatedly switching products. Such workarounds can obscure ownership and produce duplicate external actions. A bounded fallback is appropriate only when it is supported, authorized and subject to the same relevant spending and resource policy.

Report the narrow remedy

An incident report should name the blocked dimension, the observed value, the required authority and the evidence that a remedy took effect. For concurrency, that evidence can be a verified closed resource and a fresh capacity read. For allowance, it can be the applicable entitlement and admitted reservation.

Keep snapshots timestamped because capacity and allowance change during investigation. A successful read from several minutes ago is useful context, not a guarantee of the next create. Let the actual atomic admission decide whether a request fits, and handle a fresh rejection without spinning into automatic account changes.

Sources & verification

Reviewed against the checked-in Lupin implementation and official reference documentation on 2026-11-05. Operational examples are illustrative; no live paid action, provider mutation or external message was executed.

• Lupin billing, metering and retained storage ↗Checked 2026-11-05
• Lupin API rate limits ↗Checked 2026-11-05
• Lupin error reference ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.