A Spending Ceiling for Every Project Key

A project key should identify more than the application making a request. It should also define how much that application is allowed to spend. Separate budgets keep a staging experiment, a background worker, and a production assistant from silently consuming the same allowance.

This walkthrough builds that boundary in your own backend: one project credential, one budget ledger, and a check before every upstream request. It does not depend on an undocumented dashboard setting.

§ Step 1: Separate projects before setting budgets

Create an account with Vana API, then keep your upstream credential in server-side secret storage. Requests are billed on the tokens they actually use, so your budget ledger needs to track monetary cost rather than request counts alone. ([vanaapi.com](https://vanaapi.com/plug-in?locale=en))

Issue a separate internal credential for each project and environment. Map those credentials to the upstream secret inside your backend; do not distribute that secret to browsers or untrusted clients. Otherwise, callers could bypass your spending checks.

• Production assistant: a dedicated budget and owner.
• Staging assistant: a smaller, independent allowance.
• Batch processor: its own ceiling and concurrency limit.

§ Step 2: Define exactly what the ceiling means

For each project, record a budget amount, currency, accounting period, reset time, and responsible owner. Decide whether the allowance resets monthly or remains fixed for the project's lifetime. Use an explicit time zone for recurring resets.

As an illustrative policy, give staging a $20 monthly allowance and production a $100 allowance. These are example budgets, not Vana API prices. Set warning thresholds at 70% and 90%, with a blocking threshold at 100%. A warning notifies someone; a ceiling must prevent additional work from starting.

§ Step 3: Route every request through the check

Place budget enforcement after project authentication and before the upstream call. Vana API uses https://api.vanaapi.com as its base address; OpenAI-compatible SDK clients use the /v1 suffix. Keep that endpoint configuration separate from your project-budget policy. ([vanaapi.com](https://vanaapi.com/plug-in?locale=en))

Make every execution path use the same gate: interactive requests, scheduled jobs, retries, and agent tool loops. A project's allowance should follow its identity, not the particular worker or interface making the call.

§ Step 4: Reserve cost before starting work

Do not wait until a response finishes to decide whether it was affordable. Before dispatch, reserve a conservative amount based on the selected model's applicable rates, estimated input usage, and permitted output length. Include other billable categories wherever they apply.

Use this admission rule: settled spend + outstanding reservations + proposed reservation must not exceed the ceiling. Make the comparison and reservation one atomic database operation. Otherwise, simultaneous requests could each see the same remaining balance and all proceed.

If you cannot calculate a defensible upper bound, reject the request or require a smaller workload. An optimistic estimate is not a hard spending guarantee.

§ Step 5: Settle against actual usage

After completion, replace the reservation with the charge calculated from reported usage and the applicable rates. Release only the unused portion. Keep a record of project identity, request identity, model, usage, reservation, and settled cost.

Make settlement idempotent so a repeated completion event cannot charge the ledger twice. Treat uncertain outcomes separately: a timeout does not establish that no upstream work occurred. Preserve the reservation until you can reconcile it, and budget each potentially billable retry independently.

§ Step 6: Make the stop condition explicit

When insufficient allowance remains, return a clear project-budget error and pause queued work. Tell the caller which project is blocked, when its allowance resets, and who can approve an increase. Do not automatically switch credentials or borrow another project's budget.

Keep this distinct from upstream account exhaustion. Vana API documents HTTP 402 for an exhausted account balance; that is not evidence that your own project ceiling has been enforced. ([vanaapi.com](https://vanaapi.com/plug-in?locale=en))

§ Step 7: Test the boundary before rollout

Give a test project a deliberately small allowance. Exercise a normal completion, an oversized request, concurrent requests, a timeout, and a retry. Confirm that reservations block excess work and that completed requests settle exactly once.

Finally, review budget warnings with the project owner. Raise allowances deliberately, with an audit trail. The useful result is not merely a spending chart: it is a predictable point where each project stops until someone authorizes more.