Studio quickstart

This quickstart uses the Create Image workbench because it has the clearest verified path through the media generation API. The outcome depends on provider configuration and safety review. You may receive an accepted media job, a setup-required state, or a blocked request; each is a valid current result.

Create a project

Projects can organize related creative work, but current project surfaces include mock or foundation behavior. You can open the projects route and inspect the available controls, yet the supplied sources do not verify durable creation, ownership, or retention across every environment.

For this quickstart, a project is optional. If the Create Image workbench accepts a project reference, it can link the submitted job and resulting asset to that identifier. Do not invent a project ID or rely on the project record as permanent storage.

If project creation appears mock, proceed without claiming that a durable project was created. Keep your prompt and result references available through another approved process when they are important.

Choose a generator

Open Create Image. The workbench is configured for a text-to-image capability and can route to the current media API when provider setup permits.

Inspect the model and provider status shown by the current environment. A model entry identifies a capability; the provider state determines whether the runtime is live, setup-required, unavailable, fallback, mock, failed, or disabled. Do not select a model solely because it appears in a catalog.

If no image model is available, stop and use the provider-status information to identify the missing setup. The API rejects modalities that have no models.

Configure a job

Enter a prompt that states the subject, setting, composition, and important constraints. Avoid real credentials or unnecessary personal information. Add a reference input only when the workbench and selected capability support it.

Configure the visible controls conservatively. Aspect ratio, style, or other options can vary by panel and model; the repository does not prove that every visible control is sent to every provider. Treat the readiness note and disabled state as authoritative.

The media request requires a prompt and a modality. If a project identifier is supported and you choose to use it, verify that it refers to the intended current project surface. Image-to-video rules do not apply to this text-to-image quickstart.

Before submission, review any safety notice. The generation route runs a safety preflight that can allow the request, require consent, or block it.

Generate

Submit the request from the Create Image workbench. The client can move through phases such as validating, estimating, generating, finalizing, and completed. These phases describe the current job flow, not a guaranteed public latency.

The API validates the prompt and modality, checks model availability, runs safety preflight, routes through the media router, and creates job and asset references. An accepted request returns HTTP 202 rather than a completed file immediately.

Expected outcomes include:

Do not repeatedly resubmit a safety or setup failure as though it were a transient queue delay.

Review assets

When the job completes, inspect the stage, result board, history, and inspector fields that the workbench provides. The generated output may be represented as an asset and linked to the job or optional project.

Check the final status before using the result. A completed job means the current flow reached its terminal completion state; it does not prove that the asset is stored durably. The API reports local private-beta storage and non-production durability, while other Studio UI text describes an in-memory store.

Many result actions are disabled. Do not assume that download, export, publish, extend, upscale, or handoff works merely because a toolbar item is visible. Use only actions that are enabled and supported by the current panel.

Troubleshooting

If generation does not start, check the prompt, modality, model availability, provider status, and safety result in that order. An empty prompt or unsupported modality should be corrected before reviewing provider setup.

If the request is accepted but no result appears, open Studio Jobs and locate the current job state. Queued, planning, running, and processing are active states; failed, canceled, expired, and completed are terminal. Awaiting upload or approval indicates an unmet prerequisite.

For a provider setup message, use the current models and provider-status surface. Do not follow an invented provider URL. When the job completes but the asset cannot be found later, treat the persistence contract as unresolved rather than claiming deletion or permanent loss.

Prepare a test request

Use a prompt and subject that are safe to process and easy to recognize. A controlled first request helps separate prompt quality from provider or storage problems. Avoid a complex reference workflow until the text-to-image path has produced a clear accepted or setup-required result.

Record the app route, selected capability, model or provider state, and optional project reference before submission. These details are more useful for diagnosis than a screenshot of the final stage alone.

Follow the job rather than the spinner

The client’s phases are helpful orientation, but the media job is the durable concept within the current request. After HTTP 202, inspect the job identifier and state. A workbench that continues to show a spinner after the job failed can be misleading; the Jobs surface provides the more specific processing record.

Do not infer a service-level time from how long one preview job takes. Provider setup and the non-production store can change behavior between environments.

Safety outcomes

A blocked safety result is terminal for that request. Revise the prompt only when the content can be made compliant without hiding the original intent. A consent-required result should be handled through the supported UI if present; do not simulate consent in a free-form field.

Safety notices can also appear in panel configuration before submission. Treat them as part of job preparation rather than decorative copy.

Retain important outputs

Because current storage is not production durable, an accepted and completed result should not be the only copy of important work. Use an enabled supported result action or another approved process. A disabled download or export control cannot be treated as a backup path. Keep the job and asset references alongside the retained output so later review can identify the source request.

Model and provider preflight

Before entering a long prompt, confirm that Create Image displays a usable text-to-image model and a provider state that permits generation. A setup-required or disabled provider should be resolved or documented first. This prevents a creative-editing problem from being confused with environment configuration.

Prompt review before submission

Read the prompt once for subject clarity and once for safety and privacy. Remove credentials, unnecessary personal data, and instructions that conflict with the desired composition. If a reference image is involved, confirm that the current panel supports it and that you are authorized to process it.

Accepted response details

HTTP 202 indicates that the media request was accepted for asynchronous work. Preserve the job identifier and current storage metadata. It does not mean the asset is ready or durable. The workbench may continue through estimating and generating while the job record provides the precise state.

Provider setup outcome

If the request cannot proceed because a provider is not configured, capture the capability and provider status. The quickstart should end there rather than offering an unsourced setup URL or secret format. Configuration is environment-specific.

Result verification

When a result is visible, verify that the job is completed and that the asset reference matches the request. If the provider state indicates fallback or mock behavior, label the output accordingly. Do not infer the backend from image appearance.

After the first image

For a second request, change one creative variable and compare the job and asset metadata. This helps demonstrate the supported iteration path without implying that the provider is deterministic. If the first job exposed a storage or result-action limitation, address that before creating more important work.

Expected quickstart endpoints

The procedure can end in three honest ways: an accepted job, a setup or availability message, or a safety decision. Only the first can progress to result review. The other outcomes still confirm that the request reached a grounded product boundary.

Avoid duplicate submissions

After HTTP 202, follow the existing job instead of submitting the same prompt again. Duplicate requests can create additional estimated usage and complicate result comparison. Resubmit only after the job has failed or a supported correction has been made.

Record the storage response

When the generation response identifies local private-beta storage and non-production durability, retain that information with the job. It affects how the result should be saved and shared. Do not hide it behind a generic completed message.

Quickstart completion

The quickstart is complete after you can explain the request, provider state, safety outcome, job state, and result or blocking reason. A generated image is one possible endpoint, not the only valid one.

Keep the job reference

Copy the returned job identifier into your review notes without including secrets or private prompt content.