FLUX or SDXL is the wrong first question

The starting file is a 1600-pixel SketchUp viewport with correct massing, flat materials, three placeholder trees, and a weak sky. One designer recommends SDXL with depth and edge controls. Another says FLUX produces better realism. A third points to FLUX.2 editing. All three can be right, because they are answering different jobs.

The current ComfyUI discussion around architectural renders keeps circling the same request: show me the workflow that makes this image photoreal. Yet “this image” might be a sketch, clay view, basic render, or nearly finished frame. The amount of valid evidence changes at each stage. Model choice should follow that evidence.

ComfyUI officially documents separate model families and warns that their latent formats, text encoders, VAEs, and control models are not interchangeable. That is not installation trivia. It means an office should maintain a few named routes instead of growing one graph into an unreadable switchboard.

Route 1: SDXL when control infrastructure matters most

Choose an SDXL checkpoint when the studio already has tested SDXL ControlNets, LoRAs, inpainting models, and known-good node graphs. Its value is not that every SDXL image beats every FLUX image. Its value is a mature, well-understood control path that can turn depth, Canny edges, line work, masks, and regional prompts into repeatable passes.

This route fits a basic rendered view that needs better lighting, material texture, planting, and atmosphere while the camera and major edges stay fixed. Build the minimum graph: load checkpoint and matching VAE, encode the positive and negative instructions, load the source image, derive or load the chosen control image, apply a compatible SDXL ControlNet, sample, decode, and save.

Use one structural control first. Depth usually protects large volumes and relative distance. Canny or line guidance protects visible edges but can overvalue furniture, seams, and temporary model lines. Combine controls only after each works by itself. More guidance is not automatically more fidelity.

Route 2: FLUX.1 Depth for a fresh image held to massing

ComfyUI's official FLUX.1 ControlNet example includes depth and Canny options from compatible providers. The documented FLUX.1 Depth route uses the FLUX diffusion model, its own autoencoder, dual text encoding, the depth control component, an input image, and the normal sampling path. It is a separate graph family, not an SDXL graph with a new checkpoint dropped in.

Use this route when the source has trustworthy massing and camera depth but weak or intentionally absent surface information. A clay model, white-card export, or simplified BIM view is a reasonable candidate. Describe the building type, material assignment by element, time of day, weather, and what must remain fixed. Keep the first run focused on the whole scene. Save selective repairs for later passes.

Depth does not preserve every design fact. Two windows can occupy similar depth and still merge. A railing can keep its position while changing its section. Text, signs, thin mullions, brick coursing, and open joints need visual inspection. Treat the depth map as evidence about distance, not as a hidden building model.

Route 3: FLUX.2 editing when the image is already close

FLUX.2 is built for image editing and multiple references as well as generation. Black Forest Labs describes editions for production, fine control, maximum quality, and a compact Klein family aimed at fast work. ComfyUI documents local FLUX.2 Dev and Klein workflows, including image editing and multi-image reference routes.

Choose editing when the source image already contains most of what should survive. A finished render with the wrong chairs, a facade needing one material swap, a daylight view that needs an evening mood, or an interior requiring a known product reference are editing problems. State the change narrowly and state what stays unchanged.

Multiple references are useful when each has a declared role. Reference one can be the base render, reference two the approved stone, and reference three the exact chair. Do not throw ten attractive interiors into the input and expect design accountability. Name the role in the project log and in the prompt.

Generation asks for a new answer. Editing asks for a controlled difference.

Route 4: FLUX.2 Klein for previews and graph decisions

The compact Klein variants make sense when latency is the problem. ComfyUI's official guide presents 4B and 9B versions, with base and distilled choices, and reports that the smaller distilled model can run within a modest high-end GPU memory budget. Actual speed and memory depend on hardware, resolution, quantization, other loaded models, and the rest of the graph.

Use Klein to test prompt wording, reference roles, crops, masks, and composition before spending time on the final route. It can also support live design sessions where five quick material directions are more valuable than one slow polished frame. Do not promote the preview automatically. Re-run the approved instruction through the chosen delivery model, then repeat the geometry review.

Build four small graphs, not one universal graph

Create a folder for each route and freeze a known-good starter workflow. Use only core or approved custom nodes. Record the ComfyUI build, model filenames, source URLs, license notes, expected folder locations, and a sample input-output pair. If a model family needs a different VAE or text encoder, keep that dependency inside its manifest.

Name inputs by purpose: SOURCE_RENDER, DEPTH_CONTROL, EDGE_CONTROL, MATERIAL_REFERENCE, and MASK. Name outputs with project, view, route, seed or job ID, and version. Save the workflow metadata in the output when policy permits, plus a separate JSON export when the image will pass through software that strips metadata.

At the top of each graph, add a note stating what the route is for and what it cannot prove. “FLUX1_DEPTH: atmosphere and material direction from clay view; check openings and thin elements.” That sentence is more useful to the next designer than a group labeled “magic.”

Run the same acceptance test on every route

Model comparisons become useful when outputs face the same review. Lock the source image, crop, output size, and permitted change. Give each route a fixed retry allowance. Then score camera, silhouette, opening count, major edges, material assignment, lighting intent, repair time, runtime, and memory or cloud cost.

Inspect failures by category. If SDXL preserves edges but creates weaker surfaces, it may still be the right base for a geometry-sensitive deliverable. If FLUX.2 makes the best single edit but alters an adjacent bay, narrow the mask or instruction. If Klein gives the idea in seconds but loses fine assembly detail, it has done its preview job.

The winner is not the prettiest unassisted frame. It is the route that reaches the acceptance threshold with the least correction and the clearest record.

Our take: choose the graph by the change budget

Architecture teams do not need a permanent answer to FLUX versus SDXL. They need a routing rule. Ask how much of the source may change. Ask which geometric evidence is available. Ask whether the work is generation, control, editing, or preview. Ask which dependencies the studio can maintain.

A good ComfyUI setup makes these choices visible before the queue runs. Four small graphs beat one mythical graph that does everything.

Name the change. Then load the model.

Based on the 10 September 2026 intel sweep, current ComfyUI documentation for FLUX.1 ControlNet, FLUX.2 Dev and Klein, and Black Forest Labs documentation for FLUX.2 editing. Model files, licenses, performance, and node support change quickly; verify official documentation before deployment.