The first render happens once. Revision happens until approval.

A client likes the exterior, then asks for warmer brick, fewer people, and a brighter entrance. Those are not edge cases. They are the work.

Yet most AI rendering comparisons still lead with the monthly plan, generation speed, and the best image each product can make. Today’s intel sweep surfaced a useful exception. Syntina’s own comparison asks about revision cost structure and notes that a project will produce far more revisions than first generations. The publisher sells one of the products in its table, so its rankings remain vendor communication, not independent testing. The question is still the right one.

Subscription price tells you the cost of access. Revision cost tells you whether the tool can survive a project.

Separate the invoice from the operation

A revision can consume four different resources. First are product charges: credits, compute time, export limits, or a paid editing tier. Second is active operator time spent masking, prompting, waiting, selecting, and repairing. Third is collateral drift, meaning an accepted part of the image changes while another part is corrected. Fourth is verification, because every regenerated region has to be checked again.

A comparison that records only the credit charge misses the expensive parts. A free edit that makes the glazing, planting, and roofline move can cost more staff time than a paid local correction. A full rerender may finish in seconds and still restart the approval cycle.

Use one accepted image and three edits

Start with an image your team would send to a client. The purpose is not to make another attractive option. It is to find out whether the software can change an accepted artifact without destroying its accepted parts.

Give every candidate the same three requests:

1. Material edit: change one facade finish while holding openings, joints, adjacent materials, and lighting.
2. Object edit: remove one person, vehicle, or plant while reconstructing the background cleanly.
3. Lighting edit: brighten one entrance or room without changing the building, camera, or overall time of day.

These edits test different control problems. Material replacement needs selection and texture continuity. Object removal needs bounded reconstruction. Local lighting needs a change in appearance without a new composition. A single success does not prove the other two.

Before each run, save the input and write a short protected list. Include the camera, opening count, roof profile, major edges, approved materials outside the target, and any design feature that must not move. Then time from the first click to a reviewed, accepted file. Generation time alone is not the clock.

Count drift as a revision charge

Suppose a material edit costs one credit and returns in twelve seconds. The brick is correct, but a window narrows and the pavement changes. The operator masks the window, restores the pavement, and checks every opening against the source. The product charged one credit. The project paid for three corrections and a facade review.

Use a simple drift ledger. List every visible difference that was not requested, classify it as acceptable, repairable, or rejecting, and record the repair time. If the interface offers a targeted edit, test whether pixels outside the selection remain stable. If it performs a full generation, assume nothing is protected until checked.

The cheapest revision is the one that leaves approved decisions alone.

This is also why the same nominal feature can carry different value. Two products may both advertise editing. One may isolate a region and preserve the rest. Another may treat the edit prompt as guidance for a fresh image. The button label does not describe the failure boundary.

Do not let credit systems hide labor

Credit pricing can make comparisons look precise while shifting the largest variable off the page. Record the number of attempts, but also record why each attempt failed. A low keeper rate may come from weak control, a poor source image, an unsuitable model, or an unclear brief. The test is not a universal verdict on the product. It is evidence about the product on your work.

For hosted tools, note whether a failed generation consumes the same credits as an accepted one, whether editing has its own rate, and whether higher resolution or video uses a multiplier. Verify those details on the current pricing and terms pages on the day of the test. Plans change too quickly to inherit a number from a roundup.

For local tools such as ComfyUI, zero per-image charge does not mean zero revision cost. Setup, model storage, node maintenance, GPU time, graph debugging, and staff knowledge still belong in the ledger. The cost unit changes from a vendor credit to practice time and equipment.

Test a handoff, not only the expert

After the primary operator completes the three edits, give the saved project, workflow, or settings to a colleague. Ask that person to repeat one accepted correction on a second view. Record what had to be explained.

This catches a common procurement error. A tool appears economical because one enthusiastic user remembers the prompt, mask sequence, and repair trick. The process is not yet a studio capability. If the handoff requires a live tutorial every time, include that support in the cost.

Save enough evidence for someone else to reconstruct the result: source revision, input image, target mask, prompt, model or engine name, settings, raw candidates, selected output, and rejection notes. A polished final file without its path is not a repeatable workflow.

Turn the result into a buying rule

Do not combine everything into one mysterious score. Set gates that reflect the project. A concept team may tolerate modest drift if variations are fast and cheap. A design-development team may reject any tool that changes openings during a material edit. A small practice may accept slower local processing to avoid recurring credit charges. A larger team may pay more for predictable handoffs and support.

A practical scorecard can show median operator minutes, total attempts, direct charge, number of unrequested changes, and whether a second operator succeeded. Add a short note naming the hardest failure. Those columns are less glamorous than image quality, but they forecast the Monday after purchase.

Syntina’s comparison is right to put revision structure on the checklist, and right to disclose that its own product is one of the options. It is not a substitute for testing the claim on a project file. Neither is any other vendor table, including one that calls itself honest.

Take one approved image, ask for warmer brick, remove the cyclist, brighten the door. The invoice starts after the first picture.

Sources and method

This field guide responds to the 24 September 2026 intel sweep. It uses Syntina’s vendor-published comparison for the revision-cost prompt and disclosure context. It does not report hands-on testing of Syntina or the other products named there. Pricing and product behavior should be checked against current first-party pages during an actual trial.