generation pricing snapshot: Preserve the assumptions behind each quote

A generation pricing snapshot records the assumptions behind an estimate at the moment a request is approved. It is an application record, not a new pricing endpoint or a promise that a later request will cost the same. Save enough evidence to explain the estimate without reconstructing it from today’s defaults.

Capture the effective configuration

Include the explicit model identifier, endpoint, approved request, effective standard parameters, expected credits, and calculation timestamp. Where your application maintains a reviewed copy of pricing rules, record its revision or source commit. A free-text label such as standard video is not enough to reproduce a duration-sensitive estimate.

Store submitted and normalized values separately when you have internal access to both. Defaults are applied by the provider schema, while alias selection occurs in the route. A missing duration can therefore still produce a concrete priced duration, and an image count omitted from the body can become one.

Exclude secrets from the snapshot. Protect private reference URLs and use stable asset identifiers or hashes for shared reports. The price record rarely needs the full downloadable source URL.

Follow one fictional request

A planning fixture might select seedance-2.0-fast, five seconds, 720p, and one job. The current function computes the ceiling of five multiplied by five multiplied by one half, producing thirteen credits. Save those inputs with the result rather than saving only the number thirteen.

If the reviewer later changes resolution to 1080p, create a new approved estimate linked to that changed request. Do not update the old snapshot in place and leave historical jobs attached to a price they never used.

The same principle applies to image count. A shift from one image to four changes work and credits even when prompt text remains identical.

Add observed accounting

After submission, attach the returned job identifier and credits_held. After settlement, attach the terminal state, actual consumption where available, and refund evidence where relevant. Keep estimate, reservation, and settlement as different fields.

A response lost after submission leaves observation incomplete. Mark the record unresolved and investigate acceptance rather than assuming the estimate was never reserved. A later collection or refund observation can complete the record without deleting the original uncertainty.

The current adapters’ internal usdCost field is an upstream estimate derived from credits. Do not substitute it for the organization’s actual cost of acquiring credits or treat it as a payment receipt.

Acceptance criteria

An operator should be able to reproduce a fictional estimate from its model, normalized parameters, pricing revision, and arithmetic. They should also be able to explain any difference between that estimate and observed reservation or settlement.

Review multi-model cost estimates, default parameters, and ledger reconciliation before using snapshots in budget approvals or customer support.

Continue with costs and billing

• AI image generation API pricing compared: Nano Banana, Flux Pro, Ideogram v3
• How to cap spending on a generation API key
• Flux API cost at volume: what 10, 100 and 10,000 images work out to
• Browse all costs and billing guides