Match the price to the task
Section titled “Match the price to the task”Use the existing model calculator and account model prices. Match model, duration, resolution, quality and any other priced dimensions before comparing two options. A starting price is only meaningful for its stated configuration. Provider list prices, public default prices and your account prices are different inputs.
This page introduces no fixed prices, discounts or savings claims. If you record a comparison, include the source URL, observation date, account/public basis, currency, billing unit and exact specifications. If those do not match, label the comparison incomplete rather than inventing a discount.
Estimate with the actual billing unit
Section titled “Estimate with the actual billing unit”| Price rule | Workload estimate | What to verify |
|---|---|---|
| Per request | planned attempts × matched unit price | Which configuration the price covers |
| Per generated second | sum of billable seconds × matched per-second rate | Duration basis and model-specific rules |
| Per token | expected billable token categories × their rates | Image/output categories and actual usage availability |
These are planning formulas, not a substitute for billing logic. Do not multiply a per-request price by seconds or assume every image has a fixed price. The live model contract and calculator determine the applicable unit. Avoid adding overlapping usage categories twice.
Bound the batch before submission
Section titled “Bound the batch before submission”Maintain an application work list with an operation ID, selected model, exact input, approved attempt budget and returned task ID. Limit the number of submissions in flight. A batch of 20 inputs does not authorize unlimited creative revisions or transport retries; allocate a separate attempt budget for each.
Submit an item once, persist its task ID, and poll that ID until a terminal state. Stop new submissions when your application budget or concurrency limit is reached. A local timeout is not evidence that the task stopped. If a POST response was lost, investigate task history instead of blindly resending. This guide does not assume an idempotency key or a bulk endpoint.
Reconcile actual task records
Section titled “Reconcile actual task records”The public task view exposes estimated_points, charged_points and refunded_points. Preserve their decimal-string values and labels, plus pricing_snapshot and usage when present. Check what each field represents in your account’s records; do not silently subtract or add values under an unverified net-cost formula. Missing data is unknown, not zero.
After the run, compare planned attempts with accepted tasks, completed tasks, failures and outputs that actually pass your quality rubric. A technically successful image can still need review. Include unsuccessful attempts and creative revisions in the observed experiment spend; do not exclude them to make a model appear cheaper. No assumption is made that every failure is charged or refunded identically.
Use image specification planning to avoid mismatched configurations and the Node.js video tutorial to keep submission and recovery separate. For language models, use the existing LLM cost guide because native token responses and media tasks have different contracts.