Cost, Reproducibility, and Troubleshooting
Goal of this lesson
Treat every attempt as a budgeted, recorded experiment. Distinguish requirement, policy, provider, transport, and quality problems.
Cost is more than the price of one image
Total cost includes at least request count, candidates per request, size/quality tier, edit rounds, failed retries, storage and transport, human review, and post-production. Provider pricing changes, so this course does not hard-code prices. At runtime, read unit cost from official pricing pages or billing data, and set max_attempts, max_outputs, and budget thresholds requiring human confirmation at the task layer.
Validate layout and subject at low cost first; raise resolution or quality only after confirming direction. Separate “creative exploration” from “production rendering” queues so every draft does not use the highest specification. Report total attempts required to deliver a successful image, not only the final request.
Reproduction record
Retain: original structured requirement and source_revision; normalized prompt; negative/prohibited items; input asset_id and hash; summary of object-level authorization/ACL decision; adapter version; provider and model response identifier; every explicit parameter; seed if supported; request time; transform_id; output hash; post-production steps; human selection rationale; release_id; revocation/deletion propagation status; and documentation-check date. Keys, complete face input, and sensitive prompts never enter ordinary logs.
Normalize the request object as JSON and compute SHA-256 to determine whether the same task was actually sent. Even with the same request hash, cloud output can differ because of a model update or nondeterministic implementation. The aim of a reproduction record is to explain differences, not promise byte-for-byte identity.
Layered diagnosis
- Requirement error: contradictory constraints, unclear use, or unclear ratio; return to task layer.
- Policy refusal: object-level authorization/ACL, rights, safety, or person rules; record refusal category and do not retry around it. Failed revocation/deletion propagation belongs here too, not under network failure.
- Parameter error: adapter capability is stale; refresh official documentation and capability probe.
- Transient failure: timeout, 429, or 5xx; retry with bounded backoff and check whether the job already exists.
- Damaged output: MIME, length, hash, or decode failure; quarantine the file and download it once again.
- Unacceptable quality: use failure tags to change prompt, split task, or move to post-production; do not confuse this with network retry.
Stop rules
For example: pause after the same failure tag appears three times in succession; hand off to a person at maximum attempts or budget; stop immediately on safety/rights/ACL failure; pause all processing associated with transform_id and release_id after revocation; and begin a new experiment only after changing exactly one variable. Stop rules prevent an Agent from entering a “maybe one more sample will be better” loop.
Exercise and self-check
Design a table for six image experiments with a unique task hash, one-variable change, failure tag, candidate count, and human decision. Why should you query job state before retrying after a request timeout?
Finally complete the Offline Task Audit Project.
References
- OpenAI Image generation guide (interface and output options change over time; checked 2026-07-22)
- Runtime Monitoring