FLUX schnell vs dev: choose by workflow stage, not prestige

Define the product decision each tier serves

Schnell earns its place by making generation cheap and responsive enough to explore. Dev earns its place when additional fidelity, prompt adherence, or finish increases the chance that a selected image ships. Without those distinct decisions, a tier label is merely pricing decoration.

A typical flow produces several fast concepts, captures a shortlist, then renders one or two premium candidates. The user can always keep the accepted draft. This avoids forcing premium spend and avoids presenting the second model as a guaranteed enhancement.

Run a blinded test on your acceptance rubric

Collect representative prompts and randomize output labels. Review prompt adherence, composition, visual artifacts, anatomy, text handling, brand suitability, editing minutes, and overall acceptance. Record latency and provider cost separately.

The internal portrait cost ratio between the two Runware routes is roughly 11.7 at the supplied settings. Dev does not need to be eleven times ‘better’; it needs to create enough extra value on the small promoted subset to improve the total workflow.

• Use identical prompts and dimensions
• Separate aesthetic preference from task success
• Measure editing time to an approved asset
• Include failure and moderation outcomes
• Repeat after model or provider changes

Make promotion explicit in the API and interface

The API uses quality=fast or quality=premium. This is clearer than exposing an ever-changing model menu to every end user. Advanced clients can pin a provider and exact ID, but ordinary workflows should express the desired service level.

A promotion operation should receive a new idempotency key because the request is different. Carry forward the prompt-template version and chosen controls. Where seed behavior differs, warn that composition may change.

premium_payload = {**draft_payload, "quality": "premium"}
result = client.generate(
    premium_payload,
    operation_id=f"asset:{asset_id}:premium:v1",
)

Preserve the requested tier during provider failover

Fast and premium use separate candidate orders. A premium timeout should move to an eligible premium implementation, not silently return a fast image. If no reviewed premium fallback is configured, returning an honest temporary failure is better than violating the product promise.

Expose the provider and model used in metadata. When a fallback changes visual behavior, support and evaluation teams need to know which route produced the asset.