Set CometAPI Image Generation Budgets Before Rendering

Last reviewed: October 29, 2026 (Asia/Shanghai).

Direct answer

Set CometAPI image generation budgets at the final request boundary. Admit only an approved combination of model, image count, size, quality, and output controls; reserve its estimated charge before submission; and keep that commitment visible until usage or billing evidence resolves it. Give each requested asset a separate attempt allowance so a rejected image cannot trigger unlimited paid revisions.

The CometAPI image creation reference documents model-specific controls on POST /v1/images/generations. It recommends one image for broad compatibility, distinguishes encoded output settings from generation settings, and supports asynchronous submission for specified models. Those differences make a generic price-per-request assumption unreliable.

Use a dated configuration table tied to the exact gateway model and billing unit. The CometAPI cost-estimation guide says to combine the model-directory price with the endpoint’s billable units and reconcile estimates with actual usage afterward. It does not establish one universal image rate or a guaranteed saving from a smaller file.

Who this is for

This guide is for engineers operating image-generation services and budget owners funding catalog art, presentation graphics, advertising variants, or other repeated rendering work. It assumes the application controls dispatch and can retain an asset record, attempt identity, and task status across worker restarts.

The policy and acceptance checks below are implementation recommendations derived from public documentation. No authenticated generation, account pricing, or production deployment was tested for this article.

Key takeaways

• Approve complete generation configurations instead of exposing unrestricted model parameters.
• Identify whether the selected route bills by image, task, tokens, or another documented unit.
• Use one image per attempt as the starting policy and bound revisions per asset.
• Keep generation state, creative acceptance, and billing state separate.
• Poll an existing asynchronous task instead of submitting a replacement because it is slow.
• Treat missing usage as unresolved cost, and retain the price revision used for each estimate.

Sources checked

Three primary CometAPI references returned HTTP 200 on October 29, 2026 UTC:

• Create an image defines the generation route, model-specific parameters, optional usage fields, and asynchronous submission behavior.
• Retrieve an image generation task defines the polling route, pending, success, and failure states, and the nested result fields.
• Estimate request cost before calling a model explains pre-call estimates, task multipliers, billing-unit checks, and subsequent usage reconciliation.

These are current official technical references for an evergreen control. They support the request and accounting workflow; they do not supply a verified account-specific tariff. Refresh the configuration’s pricing evidence before approving spend and whenever its model or billing terms change.

Contract details to verify

Build a priced configuration table

Define a small set of application-owned configurations, such as catalog-draft-v1 and catalog-final-v1. Each entry should contain the exact model ID, endpoint, permitted size, quality, image count, output format, background mode where applicable, and synchronous or asynchronous behavior. Store its currency, billing unit, price source, access date, and calculation revision alongside those fields.

The image reference lists low, medium, high, and auto for GPT image quality, with additional levels on named models. Do not infer that every model accepts every value or that one quality label always has the same price. A higher tier needs its own reviewed rate and a demonstrated delivery requirement.

Likewise, the reference describes output_compression as an encoding control for JPEG and WebP, with no effect on PNG. A smaller downloadable file is useful for storage or delivery, but that description does not prove a lower generation charge. Change the generation reservation only when the selected billing contract supports the change.

Keep automatic settings out of a hard spending boundary unless their possible charge is bounded. An average from yesterday’s renders is a forecasting input, not a maximum. If a token-metered route cannot be bounded from its supported controls and documented pricing, use an explicitly approved soft allowance or defer that configuration. Do not label an empirical estimate a guaranteed cap.

Calculate the reservation in the correct unit

For a configuration explicitly priced per generated image, the basic planning calculation is:

attempt_reservation = approved_image_count * approved_price_per_image
asset_exposure = settled_asset_cost + unresolved_asset_reservations
admit only if asset_exposure + attempt_reservation <= asset_budget

Include any other documented billable components. A per-task price uses task count; token-based pricing needs the relevant input and output units and rates. Do not multiply a per-task price by image count unless the contract actually charges for each image.

For illustration only, suppose a reviewed configuration has a $0.08 per-image planning rate, one image per attempt, a $0.24 asset allowance, and a three-attempt limit. After two reconciled $0.08 attempts, one more can fit. A proposed configuration reserving $0.18 cannot fit the remaining $0.08. These are invented worksheet amounts, not CometAPI prices or measured savings. If an earlier attempt remains unresolved, its reservation still consumes the allowance.

Use the site’s pricing-unit normalization workflow to establish the unit first. Enforce admission through the existing atomic budget reservation ledger when several workers share the same allowance.

Submit the approved configuration once

This JSON illustrates a documented request shape. It is not an executed request or a price quote:

{
  "model": "gpt-image-2",
  "prompt": "A paper boat on calm water at sunrise.",
  "n": 1,
  "size": "1024x1024",
  "quality": "low",
  "output_format": "jpeg",
  "async": true,
  "stream": false
}

The creation reference documents asynchronous mode for gpt-image-2 and doubao-seedream-4-0-250828. Verify the selected model’s current availability and support before using the example. Do not transfer asynchronous behavior to another model merely because it shares the endpoint.

Validate the final serialized request against the approved configuration after SDK defaults or application helpers have been applied. Reserve the allowance, claim the attempt once, and then submit. If the caller requests a different size or quality, reject or explicitly select another approved configuration; silently changing it can invalidate the delivery requirement.

Track the task without creating another generation

An asynchronous submission returns data.task_id. Persist that ID against the existing attempt and retrieve it through GET /v1/images/generations/{task_id}. The task reference says data.status is pending while queued or generating, success when results are available, and failure when the task fails.

A top-level code: "success" does not mean rendering finished. Inspect the nested task status. On completion, generated items are in data.data; a returned failure reason can appear in data.fail_reason.

Use a bounded polling schedule and an overall observation deadline chosen for the workload. Reaching that local deadline stops observation or raises an operator alert; it does not prove cancellation, zero cost, or permission to create a replacement job. The reference documents retrieval, not a cancellation guarantee.

If submission times out before the task ID is captured, retain the original attempt and its reservation as uncertain. Reconcile whatever request or billing evidence is available. Do not assume an undocumented idempotency header makes a second submission safe. A permitted replacement is a separately admitted attempt while the first remains financially visible.

Separate delivery from settlement

Maintain three independent outcomes:

• Generation state: submitted, pending, completed, failed, or unknown.
• Acceptance state: awaiting review, accepted, or rejected under the asset’s delivery requirements.
• Billing state: reserved, usage pending, calculated, or reconciled.

A completed image can fail creative review. A failed task can still require billing investigation. Neither outcome alone establishes the charge. Include every confirmed charge in the asset total even when the corresponding image is discarded.

The creation schema makes usage optional and describes token details only when returned by the selected model. The task retrieval schema does not establish a universal usage payload. Preserve billing as pending when the evidence is absent; never substitute zero or infer generation cost from the base64 payload’s length.

Record asset reference, attempt ID, task reference, configuration revision, requested count, returned count, reserved amount, observed task state, acceptance reason, billing state, and evidence reference. Keep prompts, image bytes, base64 output, credentials, and temporary result URLs outside routine cost telemetry. A protected result store can retain the actual deliverable separately.

Failure modes

An interface exposes unrestricted quality or size. A caller bypasses the reviewed configurations. Validate at dispatch, including values introduced by shared client code.

A slow task becomes another POST. The worker treats pending as failure. Continue observing the existing task within policy and keep its reservation when observation ends.

Automatic behavior escapes the estimate. A request uses an unpriced auto setting. Require a bounded allowance or a reviewed explicit configuration before admitting it.

A format change is booked as a rendering saving. Compression reduces bytes, while generation metering remains unverified. Track delivery savings separately and preserve the approved generation estimate.

Creative revisions bypass the attempt counter. Each rejected image starts a new application job with a fresh budget. Keep revisions under one durable asset identity and stop when either its attempt or financial allowance is exhausted.

Missing usage closes the ledger at zero. An apparently successful task loses its cost. Keep a pending liability and use the retry-spend evidence workflow to preserve every billable attempt during reconciliation.

Verification before rollout

Use a fake dispatcher and recorded response fixtures first. These are proposed acceptance checks, not reported test results.

Then run one approved, non-sensitive canary on the actual account. Check supported parameters, result handling, task recovery, and the connection between observed usage and billing records. Widen the rollout only after the reserve calculation and stop conditions are credible for that configuration.

FAQ

Does lower quality always mean a cheaper CometAPI image?

Use the exact model’s current pricing evidence. The API reference defines supported controls; it does not establish one price relationship across all image models or account terms.

Does asynchronous generation reduce the price?

The cited documentation describes submission and polling behavior, not an asynchronous discount. Keep the same approved pricing basis unless the actual contract states otherwise.

Can I request several images to save HTTP overhead?

Only after verifying model support and reserving the complete charge. The image reference recommends one for compatibility and specifically says qwen-image does not support n > 1. Reduced HTTP overhead does not establish lower generation spend.

What if a task succeeds but no image is usable?

Record the rejection reason, retain any confirmed charge, and decide whether another attempt fits both limits. Completion is a technical result; acceptance is the application’s delivery decision.

Reader next step

Choose one image workload and approve one explicit model, size, quality, and output configuration. Attach a current billing-unit record, per-attempt reservation, asset allowance, and attempt limit. Prove that a pending task survives restart without another generation submission and that missing usage remains visible.

When those checks are ready, Start with CometAPI with a single bounded canary. Reconcile that attempt before increasing volume or enabling additional configurations.