Use cases

Runtime monetization for product actions that need a decision first.

Use Valqio when a product action should be allowed, denied, reserved, committed, released, and explained before it spends credits, quotas, or customer limits.

Valqio runtime decision flow for billable product actions

Where Valqio fits

Call Valqio before the billable action starts.

AI usage and credits

Paid actions

Decide whether a customer can generate, transcribe, analyze, export, or start another paid job.

Budgets

Check model access, token budgets, and prepaid balances before work begins.

Feature and plan gates

Plan access

Allow features by plan, contract, customer segment, or environment.

Seat gates

Resolve named-seat access before invite, login, or activation paths.

Stateful limits

Allowances

Enforce monthly allowances, daily caps, fair-use rules, and credit balances.

Storage gauges

Read current usage and cap expansion before accepting more stateful usage.

Decision evidence

Exports

Export usage and decision evidence to Stripe, support, finance, or your warehouse.

Debugging

Give operators the reason, input snapshot, and evidence ID behind each outcome.

Decision patterns

Start with the action your app must decide.

The common thread is not the pricing model. It is the runtime moment where work should run only if the account has the right plan, credits, quota, or override.

AI generation and credits

Ask before tokens, generations, transcriptions, analyses, or exports spend customer credits or budget.

API credits and quotas

Gate API calls, prepaid allowances, fair-use limits, and overage behavior before the request runs.

Seats and plan gates

Resolve plan access, named seats, contract exceptions, and environment-specific access in one runtime path.

Stateful limits

Check storage, projects, data volume, or other gauges before accepting more stateful usage.

Pricing checks keep spreading

Plan access, custom contracts, customer segments, and environments keep leaking into product routes and jobs.

Retries can spend twice

Balances, allowances, reservations, and failed work need one lifecycle instead of caller-specific patches.

Support needs the reason

Show why an action was allowed or denied without reconstructing plan, usage, and billing state by hand.

Try one runtime decision before wiring your app.

Open the playground to inspect one action from preflight through reservation, retry, release, and evidence.