A render pipeline has a cost per resolution tier, and picking the wrong tier for a frame is a decision, not an oversight. On this page, the tiers are explicit: 1K costs 10 credits, 2K costs 20, 4K costs 30. The tiers are not quality settings hidden in a menu. They are a pricing structure, which means the tier choice is an engineering decision: it trades resolution against credits, and it should be made per frame based on where the frame will be consumed.
The trap is treating the tier as a quality setting rather than a deployment target. Higher resolution costs more credits per generation, and every rejected frame at 4K is a 30-credit loss. The engineer's job is to spend the high-tier credits on the frames that ship.
Decision model: where does the image live?
Start from the consumer. An image displayed in a 400px sidebar does not benefit from 4K pixels. An image printed on a billboard does. The tier should be chosen from the display context, not from a default.
Three questions sort the tiers:
- Will the frame be displayed at under roughly 1000px on the longest edge? Use 1K.
- Will it be displayed at roughly 1000-2000px, or will it be cropped and retouched? Use 2K.
- Will it be scaled up, printed, or inspected at full resolution? Use 4K.
This is the same logic as choosing a render target in any graphics pipeline. You do not render the shadow map at the resolution of the final composite. You render it at the resolution the consumer needs.
The cost of being wrong
Compare two workflows. Workflow A renders every draft at 4K. Five drafts, one keeper: 5 × 30 = 150 credits. Workflow B renders drafts at 1K, then renders the keeper at 4K: 4 × 10 + 30 = 70 credits. The output composite is identical. The difference is 80 credits spent on frames that were rejected.
The mistake is not using 4K. It is using 4K before the direction is locked. The tier choice should follow the decision gate: once the composition, style, and subject are approved, the next render is the high-tier one.
How the engine choice interacts with tiers
The page offers two engines. Flare is the rapid-iteration engine, optimized for trying directions fast. Sunburst is the detail-focused engine, for final images and reference-led editing. The engine and the tier are orthogonal: you can run a 1K draft on Flare or on Sunburst, and you can run a 4K final on either.
The natural pairing is Flare with 1K drafts and Sunburst with 2K/4K finals, but the pairing is a workflow convention, not a pricing rule. The credit number comes from the tier alone. Do not conflate the two: an engine choice does not add or remove credits.
A concrete routing rule
For a production pipeline, the routing looks like this. On the first pass, run Flare at 1K. This is the exploration stage. When the composition is locked, run a confirmation frame at 2K on Sunburst. This is the working resolution. When the frame is approved for production, run the final at 4K. This is the shipping resolution.
That routing uses 10 credits per exploration, 20 for confirmation, 30 for the keeper. It keeps the cheap frames cheap and the expensive frames rare.
The tier table, the engine descriptions, and the reference-led editing path are all on GPT Image 2.5. The model strength comparison section lists the three credit steps, and the dual engine section lists the two engines, so the routing above maps directly onto the page's own structure.
The one failure mode
The failure mode is defaulting to the top tier. It feels like the "best" setting, and it costs three times the draft tier per frame. In a pipeline, the best setting is the one that matches the consumer. A 1K draft that leads to a 4K keeper is a cheaper path than a 4K draft that leads to a rejected frame.
A note on reference-led pipelines
The tier routing applies to reference-led editing as well. When you upload a product image and restyle the scene, the draft restyles run at 1K on Flare, the confirmed restyle runs at 2K on Sunburst, and the shipping restyle runs at 4K on Sunburst. The reference upload itself has no credit cost. The credits go to the renders, and the renders should be tiered the same way a text-to-image pipeline would be: cheap to explore, expensive to ship.
The pipeline view matters because it is easy to treat each render as a standalone decision. It is not. A render is a step in a sequence, and the tier of each step should match what that step is for. Exploration steps are cheap. Confirmation steps are mid. Shipping steps are top.
Top comments (0)