Image generation

Studio image generation uses a prompt-first workbench and the current media generation API when a compatible model and provider are available. The request passes validation and safety checks before a media job is accepted. Model lists, provider status, controls, and result actions can change by environment, so inspect the current workbench rather than relying on fixed values.

Choose a model

Select a text-to-image model whose provider is usable in the current environment. A model card identifies a capability and may expose descriptive metadata; it does not prove that the provider is configured.

Provider states can include live, mock, setup-required, failed, fallback, disabled, or provider-unavailable. Prefer the explicit current status over a generic Preview label on the app. If no models are available for the image modality, the API rejects the request.

Do not publish a fixed model count or permanent provider list. Model and provider data are dynamic, and a route that falls back to mock behavior should be labeled accordingly rather than presented as live generation.

Prompting

Describe the image directly. Include the subject, environment, composition, visual treatment, and important exclusions. Put the most consequential details in clear language instead of relying on a long list of loosely related adjectives.

A practical prompt can cover:

• subject and action;
• camera position or framing;
• lighting and setting;
• materials, colors, or style direction;
• text that must or must not appear;
• a reference-image role when supported.

Do not place credentials or confidential source material in the prompt. The route requires a nonempty prompt, and safety preflight can block content or require consent.

Aspect ratio

Aspect-ratio controls are panel-specific. Choose only a value offered by the current Create Image workbench and compatible with the selected model. Image-generation evidence does not establish one universal aspect-ratio list for every image path.

Changing aspect ratio can affect composition and subject placement. Rework the prompt when moving between portrait, landscape, and square formats rather than assuming the provider will preserve framing automatically.

If the chosen value is disabled or omitted from the request, do not invent support. Submit with the supported default or select another model whose current controls match the intended output.

Generation settings

The workbench can expose additional controls, reference behavior, inspector fields, and safety notices. Their availability comes from the panel configuration and selected capability. A visible control may be preview-only or not wired to the active provider.

Before generating, verify:

The API requires prompt and modality, checks that the modality has models, runs safety preflight, and routes the request through the media router. It can link current job and asset records to a supplied project identifier.

Review results

An accepted request returns HTTP 202 and creates a media job. Client phases can include validating, estimating, generating, finalizing, and completed. Use Studio Jobs or the workbench history to inspect progress.

When a result appears, check the job status, provider or model reference, safety outcome, and asset metadata. Estimated credits are not an invoice. A completed status does not establish production durability: the generation API reports local private-beta storage with isProductionDurable: false.

Many result toolbar actions are disabled. Only use download, export, upscale, extend, publish, or handoff when the current control is enabled and its behavior is verified. Keep an external copy of important outputs rather than relying on indefinite retention.

Troubleshooting

If provider status and job output disagree, keep the result under review. A fallback or mock output must not be labeled as a live provider result.

Request path

A grounded image request passes through several checkpoints: client validation, request-body validation, model availability, safety preflight, media routing, job creation, and asset linkage. Failure at an early checkpoint means no provider generation should be assumed.

The API’s accepted response confirms that the current system created a job, not that the image is complete. Follow the job state and result reference instead of treating HTTP 202 as the final asset.

Reference inputs

Some Studio panels can expose reference behavior. Confirm that Create Image and the selected model support the reference before adding one. A reference may guide subject, composition, or style, but the source does not establish a universal strength control or identity-preservation guarantee.

Use media that you are authorized to process. Avoid interpreting a preview thumbnail as proof that the provider received or stored the file.

Provider and fallback interpretation

A provider can be live, setup-required, failed, fallback, disabled, or unavailable. If the route uses mock or fallback behavior, the output must be labeled with that state. A successful-looking image is not enough to identify which backend produced it.

Provider configuration can also change after the model page was loaded. Refresh status before diagnosing a job as a prompt failure.

Job and asset review

Compare the job’s terminal state with the asset surface. Completed should have an interpretable result reference; failed should preserve the error. If the job is complete but the asset is absent, document the store inconsistency rather than generating again immediately.

The current persistence posture means an asset can be usable for review without being suitable as long-term storage. Keep critical creative files elsewhere through a supported action.

Prompt iteration

Change one major variable at a time—composition, subject detail, lighting, or format—so the effect of the revision can be understood. Repeatedly changing the prompt, model, aspect ratio, and reference together makes it difficult to distinguish provider behavior from input changes. This is practical creative guidance and does not imply deterministic output.

Model switch consequences

Changing models can change provider, supported settings, safety handling, and output behavior. Recheck aspect ratio, reference support, and readiness after every switch. Do not carry a setting from one model into another unless the active panel continues to expose it.

Safety consent

A consent-required result is different from a block. Follow the supported consent mechanism when it is present, then submit the request again only as the product directs. Do not add a phrase to the prompt claiming consent or use another provider to evade the control.

Error-to-action mapping

A missing prompt calls for input correction. No models calls for catalog or provider review. Setup required calls for environment configuration. Safety block calls for content review. Provider failure calls for status inspection. These paths should not be collapsed into “generation failed.”

Inspector fields

The inspector can expose model, provider, job, or output details according to the panel. Use those values to identify the result, but do not assume every field is available or permanent. A missing inspector value is unavailable information, not zero.

Asset handoff

If the result is intended for image-to-video, verify that the asset can be selected as a source image. A project association or visible thumbnail may not be enough. Keep the original file available until the target workbench accepts it.

Non-production durability

The API’s explicit non-production-durable flag should guide behavior. Create Image can be genuinely useful while still requiring external retention of important outputs. This is an operational limitation, not evidence that generation itself was mock.

Request identity

Keep the job identifier with the exact prompt revision, selected model, provider state, aspect ratio, and reference input. This avoids attributing a later result to the wrong configuration when several image jobs are active.

Handling fallback output

If a route reports fallback or mock behavior, preserve that label in the asset review. Do not compare its quality or estimated cost as though it came from the originally selected live provider. Fallback can be useful for interface testing while remaining unsuitable for provider evaluation.

Result-action review

Check each result action independently. A workbench can support generation while leaving upscale, extend, export, or publish disabled. The unsupported post-processing action does not invalidate the generated asset; it simply requires another approved workflow for that task.

Modality validation

The request must carry the image modality. A prompt submitted through an image-looking panel is not enough if the API receives another modality or none. Use the returned validation error rather than assuming the workbench corrected it.

Project linkage

Supplying a valid project reference can associate the job and asset with current project data. It does not make either record durable. If the linkage fails, preserve the job result and review the project store rather than resubmitting the generation.

Creative quality versus system success

A completed image can be technically successful while missing the creative goal. Revise the prompt or settings for that case. Provider errors, safety blocks, and missing assets are system or policy outcomes and should be diagnosed separately.

Current-value documentation

Provider, model, status, and estimated usage should be recorded as values observed for the job. Avoid rewriting them as evergreen defaults for future requests.

Current conclusion

Judge the request by its returned validation, safety, provider, job, and asset states rather than by the visual completeness of the workbench.