generation budget admission control: Reserve application budgets before submission
A generation budget admission control policy decides whether your application may submit work before any provider request is made. It can enforce campaign, team, or experiment limits that differ from the user’s gateway balance. A balance preview is useful input, but it is not a concurrency-safe budget reservation.
Define a local budget unit
Choose whether the policy limits credits, estimated money, number of requests, or accepted deliverables. Credits are the clearest match to the gateway reservation. A money limit needs a documented credit acquisition assumption, and an accepted-deliverable limit cannot be known from request count alone.
Record the campaign budget, settled spend, local pending approvals, and unresolved gateway reservations separately. A submitted task should keep its local reservation until its actual outcome is reconciled. Releasing that reservation merely because an HTTP request timed out can allow uncontrolled replacement work.
The gateway computes credits after validating the selected provider’s parameters. Use the same effective parameters for your estimate, including duration, image count, and resolution where applicable.
Handle concurrent callers
Suppose two agents each see ten credits of remaining campaign budget and each plans work estimated at eight. Independent read-then-submit checks can approve both. A local atomic reservation or serialized admission queue is needed if the campaign limit must prevent that overlap.
This application reservation does not replace the gateway’s balance lock and transactional deduction. The gateway protects its credit accounting; your application protects its own campaign allocation. Keep the two records linked by local attempt and job identifiers.
When a task is rejected locally, preserve the reason and proposed request so a reviewer can change the scope. Do not quietly reduce duration or switch models to fit a budget without reviewing the resulting creative intent.
Define release rules
On a known validation rejection before reservation, release the local pending amount according to your application state machine. On a known terminal outcome, settle against observed credit consumption and refund evidence. On unknown acceptance, retain exposure and investigate rather than marking the amount free.
An explicit submission-failure record with pending refund settlement is different from confirmed zero consumption. Keep a pending status until the evidence establishes which amount was returned.
Do not use extra to change priced upstream fields behind the admission estimate. The adapters spread extra after mapping standard fields, so collisions can undermine the assumptions behind your budget calculation.
Offline acceptance
Review concurrent admission, a stale balance preview, explicit validation failure, a lost POST response, and a full refund. Use local fixtures and avoid paid model calls. Every path should leave either a settled budget entry or a visible unresolved reservation.
Continue with credit reservation lifecycle, multi-model estimates, and extra overrides before enabling autonomous campaign submission.
Continue with costs and billing
Where these facts come from
- codebase: src/ai/api/credits.ts
- codebase: src/credits/credits.ts
- codebase: src/ai/jobs/service.ts
- codebase: src/ai/jobs/db.ts
- Editorial keyword hypothesis; search volume not measured