Studio overview

Studio is Ethen’s family of creative workbenches for image, video, audio, marketing, and related media tasks. The surfaces do not share one maturity level: some paths can submit a media job when a provider is configured, while others are preview, mock, setup-required, coming soon, or disabled. Use this overview to choose the right workbench and interpret its state before expecting a generated asset.

What Studio is

Studio organizes task-specific apps around a common creative workspace. A workbench can include a prompt composer, control rail, reference input, stage, inspector, history, storyboard or timeline, provider status, safety notices, and result actions. The exact combination depends on the app.

The /studio route directs to Create Image, making image generation the clearest starting point. The app index also links to Text to Video, Image to Video, Product Ad, AI Influencer, Cinematic Scene, Character Motion, Game Assets, and Marketing Studio.

A visible workbench does not prove a live runtime. Panel configuration can label an app Preview, Setup Required, or Not wired yet. Provider state and safety checks can further change what happens after submission.

Creative surfaces

Many result-toolbar actions are visible but disabled. The interface should be read through its status and readiness notes rather than through the presence of a button alone.

Projects and assets

Projects organize creative work, and assets represent saved or referenced media outputs. Current project and asset surfaces include foundation and mock behavior. Some cards explicitly state that no persistence or provider calls occur.

Studio surface evidence does not establish one durable storage contract across every Studio path. Ownership, persistence, deletion, reuse, and retention can differ by store and environment. Use projects and assets for organization where the current surface supports it, but do not assume that every item survives a restart or deployment.

Jobs

Accepted generation creates a media job. The job model includes active and terminal states such as queued, planning, running, processing, completed, failed, canceled, expired, awaiting upload, and awaiting approval.

The generation API returns HTTP 202 and identifies storage as local private-beta with isProductionDurable: false. The Jobs UI separately describes an in-memory, non-durable store. That conflict must remain visible; a completed job does not prove production durability.

Models

Models describe generation capability, while providers supply the runtime backend. Model cards and catalog entries can exist even when the provider is unavailable, setup-required, mock, failed, fallback, or disabled.

Counts and availability are dynamic. Cost or credit values are estimates. Do not treat the models page as a fixed price list, a quota contract, or a guarantee that every listed capability can run in the current environment.

Where to begin

Use Studio quickstart and Create Image for the shortest grounded path. If the provider is configured and the request passes safety checks, Studio can accept a text-to-image job. If setup is missing, the expected result is a clear provider-readiness state rather than a fabricated image.

Continue to the dedicated image or video guide for modality-specific inputs. Read Projects and assets before relying on long-term organization, and use Jobs and generation history to interpret current states without assuming durable retention. Audio Studio should be treated as a placeholder until additional runtime evidence is available.

Workbench anatomy

The shared Studio shell provides a consistent frame, but each app chooses its own controls and readiness. The settings rail gathers app-specific options. The stage displays inputs or results. Universal Composer V3 captures the prompt. Reference, inspector, history, storyboard, and timeline panels appear only where configured. This modular design explains why two Studio apps can look related while having different live behavior.

Read the app’s status label and readiness note before using its controls. A Preview app may still call a live image provider when configured, while a Setup Required app can expose a complete-looking interface without a usable backend. A Not wired yet label should be treated as a firm stop.

Choosing by outcome

Choose Create Image for a grounded text-to-image request. Choose Image to Video only when a source image is available and FAL is configured. Use Text to Video, Audio Studio, canvas, and other preview surfaces for planning when their runtime is unavailable. Specialized marketing and character apps can provide structured prompts or references even when result actions remain disabled.

This outcome-first approach is safer than assuming every app index card represents the same generation contract.

Mixed-state consequences

The manifest maturity and individual capability state can conflict. Preserve the page’s locked metadata while documenting each workbench separately. A user should be able to tell whether a path is live, preview, mock, setup-required, coming soon, failed, fallback, or disabled without interpreting the overall Studio brand as one uniform service state.

Provider readiness across apps

The same provider can support one capability and be unavailable for another. Current FAL evidence applies to image-to-video, not every video panel. OpenAI configuration can support selected image generation in marketing prompt packs without proving a video handoff. Readiness must be evaluated at the app and capability level.

Safety as a shared boundary

The media API runs safety preflight before accepting generation. An app can be visually complete and provider-ready while a particular request is blocked or requires consent. Safety outcome belongs in the request path, not in the model’s permanent availability label.

History and inspector roles

History panels offer quick access to current workbench records; Studio Jobs provides the broader job-state surface. Inspector fields describe the selected or generated item. Neither view settles long-term persistence. Compare job and asset references when a result appears in one surface but not another.

Recommended reading path

Begin with the quickstart, then read the guide for the chosen modality. Consult Jobs for processing states, Projects and assets for organization boundaries, and Models and limits when availability or provider setup is unclear. This sequence avoids using an overview page as a substitute for a capability-specific contract.

Status precedence

When an app card, provider panel, and job record disagree, use the most specific current state. A job error is more specific than a general Preview label. A provider setup warning is more specific than an app index card. Preserve conflicts for review rather than averaging them into “partially available.”

Practical boundary

Studio should be described as usable where a specific app, model, provider, safety path, and job flow are wired—not as globally live or globally mock. That capability-level wording is the central rule for every page in this section.