Video generation API cost budget: reserve credits before dispatching a render
A video generation API cost budget should cover the work you intend to create, the work already accepted, and any replacement work your retry policy permits. A balance check alone cannot express that policy. An account may have enough credits while a particular customer action has already exhausted its approved spending allowance.
Genace calculates credits from the chosen provider’s validated parameters and deducts them before upstream submission. The accepted response includes credits_held. Later job snapshots include credits_actual, which can be null before terminal accounting is recorded.
Start with a concrete request estimate
The table below describes the current repository’s adapter formulas. These are implementation-derived examples, not a permanent price guarantee. Recheck the current model page and configuration before relying on them in a customer quote.
| Model ID | Example request | Current estimated credits |
|---|---|---|
| seedance-2.0-fast | 5 seconds, 720p | 13 |
| seedance-2.0-fast | 5 seconds, 1080p | 25 |
| kling-2.0-standard | 5 seconds, 1080p | 35 |
| veo3 | 8 seconds, 720p | 50 |
Resolution and duration are not interchangeable across these models. A cheaper-looking configuration may be invalid for the selected provider. Estimate only after validating the complete requested specification.
Reserve locally before dispatch
Represent a customer action as a budget envelope. Reserve its estimated credits in your own ledger before acquiring a render permit. After acceptance, attach the remote identifier and actual held amount to that reservation. Resolve any estimate discrepancy before authorizing additional jobs.
function mayDispatch({ approved, consumed, reserved, estimatedNext }) {
const remaining = approved - consumed - reserved;
return {
allowed: estimatedNext <= remaining,
remaining,
required: estimatedNext,
};
}
console.log(mayDispatch({
approved: 100,
consumed: 25,
reserved: 35,
estimatedNext: 50,
}));
The example rejects a fifty-credit next request because only forty credits remain in that local envelope. It is a policy calculation, not an account-balance endpoint. In a distributed application, update reservations transactionally so two workers cannot each spend the same remaining allowance.
Reconcile terminal outcomes
On success, the current service records actual credits equal to held credits. On failed or canceled outcomes, its terminal path invokes a full refund and records zero actual credits. Keep reservations unresolved while the outcome is unknown, including when your collector loses its connection.
Fallback and regeneration each require another reservation. Even if a failed job will be refunded, do not assume the replacement is affordable before checking the updated situation. An intentional second variation also belongs to a new authorized request, rather than hiding inside a delivery retry.
Common mistakes include counting only successful files when estimating spend, ignoring active jobs, and treating every timeout as a free retry. Include download storage and processing costs in your broader application budget, but keep them separate from Genace credit fields for easier reconciliation.
Verification checklist
Test a budget with active reservations, a terminal refund, an estimate change, and two concurrent reservation attempts. Confirm that an exhausted envelope blocks new creation while still allowing collection and file-copy recovery for already accepted jobs.
Read 402 errors, model fallback, and duplicate requests.
Continue with costs and billing
Models covered on this page
Where these facts come from
- codebase: src/ai/providers/seedance.ts
- codebase: src/ai/providers/kling.ts
- codebase: src/ai/providers/veo3.ts
- codebase: src/ai/jobs/service.ts
- Editorial keyword hypothesis; search volume not measured