Use FLUX.1 dev as a premium image generation tier after a concept is selected — then measure cost per accepted asset.
“Luxury solid ceramic perfume bottle, completely opaque matte lilac glaze, rectangular modern flacon, matching ceramic stopper, thin polished chrome collar, warm travertine plinth, soft peach studio backdrop, commercial product photography, portrait composition”
FLUX Dev · premium · 960 × 1472Change the quality tier, not your application architecture
Premium generation uses the same endpoint, authentication, dimensions, idempotency, and response metadata as fast generation. The client changes quality to premium. The router selects runware:101@1 by default and can move to a separately configured premium fallback after a transient failure.
Do not send a premium request with an idempotency key previously used for the fast payload. Idempotency keys bind to the complete request; reusing one with different quality correctly returns a conflict rather than silently returning the draft.
{
"prompt": "Refined editorial still life, sculptural glassware, controlled caustics",
"quality": "premium",
"width": 960,
"height": 1472,
"n": 1
}Evaluate premium on acceptance, not subjective detail alone
Side-by-side reviewers tend to reward visible detail even when it does not improve the business asset. Use a blinded rubric tied to the task: prompt adherence, composition, anatomy where relevant, brand suitability, text accuracy, artifact rate, and editing effort. Track how often the premium output replaces the accepted fast draft.
A premium route can also fail operationally. Measure p50 and p95 duration, timeout rate, cost per accepted asset, and fallback frequency. The included response metadata makes these analyses possible without exposing vendor-specific telemetry to every product team.
| Metric | Question answered | Decision |
|---|---|---|
| Acceptance lift | Does premium ship more often? | Keep or narrow premium use |
| Edit minutes saved | Does it reduce human cleanup? | Value the time, not only tokens |
| p95 latency | Can the workflow remain synchronous? | Move to jobs/webhooks if needed |
| Cost per accepted image | Is quality worth the route cost? | Set credit price and limits |
Verify model and provider rights before selling the route
Model names do not replace legal diligence. Review the current model license, provider terms, permitted commercial uses, data handling, retention, and content policies for every enabled provider. Store the review date and block a route if terms no longer fit the product.
RenderRoute keeps model IDs configurable so legal or operational changes do not require a client migration. That flexibility must be paired with an approval record; otherwise a convenient fallback can introduce a model your product was never cleared to use.
Questions about FLUX dev API
How do I select FLUX.1 dev?
Set quality to premium. To pin Runware, also set provider to runware and model to runware:101@1.
Is the $0.007 cost guaranteed?
No. It is an reference portrait measurement. Provider pricing and settings can change, so benchmark again before launch.
Can premium fall back to a fast model?
Not by default. Fast and premium have separate provider orders so a premium request does not silently downgrade.
Should premium be synchronous?
It can be for low-latency workloads, but applications with strict response budgets should add the documented job and webhook extension.