Chaining a segmentation model, a compositing model, and an LLM behind one API call for product photos

Most "AI product photo" tools do one thing: cut the background out, or generate a lifestyle scene, or write the listing copy. I built Product Studio to chain all three behind a single payment-gated call, because in practice an Etsy or Amazon seller needs all three from the same photo, and doing them as three separate tools means three separate uploads.

The three models, and why each one is a different model rather than one generalist

product photo → fal-ai/birefnet/v2        (clean transparent cutout)
             → fal-ai/bria/product-shot   (lifestyle scene, optional)
             → gpt-4o-mini                (SEO listing copy, optional)

• birefnet/v2 is a dedicated background-removal/segmentation model. It runs unconditionally on every request because a clean cutout is the baseline deliverable regardless of what else the user paid for.
• bria/product-shot is a compositing model purpose-built for placing a product into a photoreal scene — not a general image-to-image model prompted to "add a nice background." It takes the original photo plus a scene_description and produces the lifestyle shot directly, which is a meaningfully different (and more reliable) task than asking a generalist model to hallucinate a coherent scene around an existing product.
• gpt-4o-mini handles the SEO copy because it's a text-structuring problem (title/bullets/description/backend-keywords/tags in strict JSON, following Amazon A10 and Etsy tag conventions), not an image problem — there's no reason to route it through an image model.

Splitting these three concerns across three purpose-built models instead of trying to get one model to do everything is a smaller version of the same lesson everyone rediscovers with LLM agents: a narrow tool that's good at one thing beats a generalist prompted six different ways.

Scene presets instead of a free-text background prompt

The lifestyle-shot step doesn't take an arbitrary scene description from the user — it offers four presets (marble, wood, studio, outdoor), each a fully-specified scene_description string ("on a clean white marble surface with soft natural window light, minimal editorial ecommerce lifestyle photo, soft realistic shadow"). Sellers know their product; they don't know how to write a compositing model's scene prompt, and a free-text box would mean a much wider variance in output quality for a paid, one-shot generation. Constrained choice beats an open prompt field whenever the buyer's expertise is in their product, not in prompt engineering.

Resilience: independent try/catch per stage, degrade instead of fail

Each of the three stages is wrapped independently: if the cutout succeeds but the lifestyle scene call fails, the user still gets their cutout back rather than a hard error. Only if both image stages fail does the whole request return an error. The SEO-copy failure path is even more explicit — it returns a real result plus a plain-language message pointing the user to support with a refund offer, rather than swallowing the failure silently. On a paid API chain, "one sub-step failed" and "the whole request failed" need to be distinguishable outcomes, or you either refund people who got most of what they paid for, or ship them nothing when you could have shipped two-thirds of it.

Gating three paid capabilities behind one grant

Same HMAC-signed payment-grant pattern as the rest of this pipe family: the grant payload carries whether the SEO-copy add-on (grant.c) was purchased, checked alongside a client-sent wantCopy flag before the OpenAI call ever fires — so an un-paid request can't trigger the more expensive LLM step even if it asks nicely.

What I'd tell anyone chaining multiple AI models behind one endpoint

• Pick a dedicated model per concern (segmentation, compositing, text) over one generalist model reused three ways — you'll get more consistent output and it's easier to reason about failure per stage.
• Offer presets instead of free text wherever the user's expertise doesn't match the prompt-engineering skill the step actually needs.
• Design for partial success. A multi-model chain that returns "at least what worked" is a materially better product than one that's all-or-nothing.

Live tool: https://product-studio-eor.pages.dev/

Happy to go deeper on the fal model chaining or the SEO-copy JSON schema if useful — drop a comment.