Studio models, limits, and troubleshooting
Interpret dynamic model and provider status, avoid unsupported limit claims, and diagnose generation, job, and asset problems.
Studio models, limits, and troubleshooting
Studio model and provider data explains which media capabilities are represented and whether the current environment appears ready to run them. Counts, pricing estimates, limits, and availability are dynamic or unverified. Use this page to diagnose a request without turning a catalog entry or UI control into a permanent service guarantee.
Model availability
A generation model declares a media capability; a provider supplies the runtime. The models surface can show entries in live, preview, mock, setup-required, coming-soon, failed, fallback, disabled, or provider-unavailable states.
A model card alone does not prove live availability. Confirm that:
- the model supports the requested modality;
- the provider is configured in the current environment;
- the workbench is wired to the media API for that capability;
- required reference inputs are present;
- safety preflight allows the request.
Create Image and some text-to-image paths can use the current media API when setup permits. Image to Video requires a source image and FAL configuration. Text to Video is not wired. Audio Studio is placeholder-oriented.
Do not hardcode model or provider totals. The catalog and provider state can change without a documentation release.
Input limits
Model and provider sources do not establish fixed public limits for prompt length, upload size, image dimensions, video duration, audio duration, request frequency, or concurrent jobs. Do not publish implementation polling constants as service limits.
Use validation messages from the active workbench and API. The media generation route requires a prompt and modality, rejects modalities with no models, and requires a reference image for image-to-video. Safety can block the request or require consent.
A visible control may imply a range for the current panel, but that range should not be generalized to every model or provider. When an input is rejected, adjust it according to the returned validation message instead of guessing a universal maximum.
Output limits
No permanent output-size, resolution, format, duration, frame-rate, file-count, or retention contract is verified. Output behavior depends on the selected capability, model, provider, and panel wiring.
Result actions such as export, extend, upscale, publish, or handoff may be disabled. Their presence does not guarantee that a completed asset can be transformed or downloaded through Studio.
Pricing and credit values are estimates, and job completion does not prove durable storage. Keep an external copy of important results using a supported enabled action.
Job failures
| Failure area | Typical signal | Response |
|---|---|---|
| Request validation | Missing prompt, modality, or required reference. | Correct the specific field. |
| Model availability | No model for the modality. | Select another represented capability or stop. |
| Provider setup | Setup required, unavailable, failed, or disabled. | Review current provider status; do not invent a route. |
| Safety | Blocked or consent required. | Follow the supported safety outcome. |
| Queue or processing | Failed terminal job after acceptance. | Inspect the error before considering retry. |
| Capability wiring | Not wired yet or preview-only. | Keep the request as design intent. |
A fallback or mock result must be identified accurately. Do not report it as evidence that the intended provider succeeded.
Asset issues
A completed job can still have an asset problem because job and asset stores are separate concepts. Check whether the job contains a result reference and whether the current asset surface can resolve it.
Projects and assets have mixed mock and foundation behavior. Persistence, ownership, deletion, reuse, and retention are not uniform. A missing item after restart may reflect non-durable storage rather than a verified deletion event.
If a result action is disabled, preserve the job and asset references but do not claim that export or reuse is available. For image-to-video, confirm that the source image is accessible to the target workbench rather than assuming an automatic project handoff.
Debugging checklist
- Identify the exact Studio app and capability.
- Read the app status: live, preview, mock, setup required, coming soon, not wired, failed, fallback, or disabled.
- Confirm the model supports the modality and the provider is ready.
- Check required inputs, including a reference image for image-to-video.
- Review safety preflight and any consent requirement.
- Submit once and inspect the accepted job or returned error.
- Follow the job state through queued, planning, running, processing, or a terminal outcome.
- Verify the result reference and asset separately.
- Treat estimated credits as estimates and current stores as non-production durable.
- Stop at disabled or unwired actions rather than substituting an unsupported API.
For support review, include the app route, modality, model and provider status, job identifier, state, and error. Exclude provider keys, private source media, and unsupported claims about quotas or billing.
Catalog versus runtime
The models page is a catalog and status surface, not a guarantee of immediate generation. A model can be listed because Studio understands its capability while the provider is missing, disabled, or coming soon. The workbench and current environment determine whether the model can be selected and submitted.
Environment changes
Provider status can change when credentials, environment variables, or service availability change. A job created before the change can fail even if the model card initially appeared ready. Refresh status and inspect the returned error before modifying the prompt.
Safety and consent diagnosis
Safety blocking and consent requirements should be separated from model or provider failure. A provider can be healthy while a request is rejected by preflight. Do not switch models merely to bypass a safety outcome. Revise the content only when the request can remain faithful to policy.
Non-durable storage symptoms
A job or asset missing after restart can result from the current local or in-memory storage posture. This is different from an explicit deletion. Check both job and asset stores, but do not promise recovery. Important outputs need an external retained copy through a supported action.
Estimates and unknown limits
Estimated credits, processing phases, and visible control ranges can help the current session. They are not permanent public values. When a user needs a limit that the product does not publish, the documentation should direct them to current validation and status rather than supplying a guessed number.
Escalating a reproducible issue
For a reproducible product problem, collect the Studio app route, modality, selected model, provider state, job identifier, terminal or active state, and returned error. Include whether a reference input and safety consent were involved. Do not include provider keys or private media. This information lets the product team distinguish catalog, validation, provider, queue, asset, and persistence failures.
Capability-first diagnosis
Begin with the requested modality. A model suitable for images does not satisfy video or audio. Within video, image-to-video and text-to-video have different readiness. This first decision often explains an unavailable model more accurately than provider status alone.
Provider-status panel
The provider panel reflects the current environment. Use its explicit live, setup-required, unavailable, failed, fallback, mock, disabled, or coming-soon state. A stale workbench can show earlier information, so refresh before repeating a failed request.
Unknown limit handling
When no published limit exists, do not substitute a provider’s general documentation or a guessed number. Reduce the input according to the current validation message, or state that the maximum is unverified. The same rule applies to output size, duration, count, and concurrency.
Polling and queue behavior
Client polling limits are implementation details. They should not become a promise about maximum processing time or automatic cancellation. If the workbench stops updating, inspect Studio Jobs and the current API record rather than declaring the provider timed out.
Fallback labeling
Fallback or mock behavior can keep a UI path responsive during setup or failure. The resulting media must be labeled accurately. It does not prove that the selected provider, model, price, or latency applies.
Asset-store diagnosis
If a result is visible in the workbench but not in Assets, compare the result reference and current store. If Assets shows an item without a matching job, identify whether it is seed, mock, imported, or from another session. Do not manufacture provenance.
Review-flag consequences
Pricing, limits, provider status, persistence, and maturity remain under review. These flags do not make the page unusable; they define which values must stay dynamic and which claims cannot be promoted to evergreen documentation.
Model-card interpretation
Use model metadata to understand capability and provider association, not to infer hidden routing. The media router makes the current route decision. Documentation should not guess that one provider was selected because its model card appeared first.
Missing values
A missing price, context field, limit, or provider status is unavailable information. Do not convert it to zero, unlimited, or free. Keep the value absent and retain the relevant review flag.
Queue saturation and concurrency
No public concurrency or queue-size contract is verified. A queued job does not prove saturation, and a slow job does not prove a rate limit. Inspect returned errors and state rather than assigning an unsupported infrastructure cause.
Cross-page consistency
Model status, workbench readiness, Jobs state, and asset availability can diverge. Use the most specific source for the current request and document the mismatch. Do not rewrite evergreen model guidance around one temporary environment failure.
Provider setup and model choice
A setup-required provider can make all associated models unavailable in the current environment. Switching among those models does not repair the missing configuration. Select another genuinely ready capability or stop.
Public-limit caution
Internal validation, UI ranges, and polling behavior can change. None should be presented as an SLA, rate limit, quota, or maximum output contract without a dedicated approved source.
Result-action failures
A disabled export, publish, extend, or upscale action is a feature boundary rather than a failed generation job. Keep the completed asset and choose another supported workflow instead of retrying the media request.
Diagnostic ordering
Check app wiring first, then model and provider, then inputs and safety, then job state, then asset persistence. This order prevents an absent runtime from being misdiagnosed as poor prompt quality or storage loss.
Final interpretation
The most reliable statement is capability-specific and time-specific: which app was used, what status it reported, which provider was configured, and what the current job returned. Avoid converting that observation into a permanent model-support claim.
Error-message preservation
Keep the returned error code or message with the job record. Paraphrasing it too early can erase the distinction between unsupported modality, missing provider setup, safety block, and processing failure.
Model availability over time
A model that was ready for one job can become unavailable later. Recheck current status before repeating an old request, especially when environment credentials or provider health may have changed.
No hidden entitlement claims
Catalog visibility does not prove that a user, workspace, or plan is entitled to a provider. Model troubleshooting sources do not define plan-based access, so documentation must not invent it.
Current conclusion
Use dynamic status and returned validation for each request. Fixed limits, prices, counts, entitlements, and provider guarantees remain outside the verified documentation contract.