Image Generation
Image generation lets the assistant produce product-mockup images: a user uploads a photo — their living room, their bedroom, or themselves — and the assistant edits that photo to composite your products into the scene, preserving its real layout, lighting, and perspective. It builds on the widget's existing file-upload support, so there's nothing extra to integrate on the host page — you enable it per application in the dashboard.
Image generation is a paid, metered capability. Each generated image counts toward your plan's monthly image allowance and is billed per image beyond that (see Billing). It is off by default — enable it explicitly per application.
How it works
- The user uploads a photo through the widget (the same paperclip/attachment flow used for any image or document).
- They ask for a mockup — e.g. "show me this quilt on my bed" or "put this jacket on me".
- The assistant edits the uploaded photo and returns a generated image, which renders inline in the conversation and persists in history.
The model only ever edits the user's uploaded photo — it preserves the existing scene and composites your product in. It will not invent unrelated brands, and it never adds, removes, or swaps the people in the photo. It can dress or re-dress a person who is already there, so a customer can see a garment on themselves.
Your product photo is the source of truth
The assistant chooses which product image to render, but never describes it. Colour, material, pattern and shape are taken from the photo's pixels, and the product's name, colour field and description are deliberately kept out of the renderer entirely.
This matters because catalog text and catalog photography drift apart in practice — a stale colour field, a colourway whose hero shot shows a different variant, a lifestyle image of last season's cut. When they disagree, the renderer follows the photograph.
If a product's metadata disagrees with its photograph, the photograph is what your customer sees. To change what a mockup looks like, change the product image the assistant is given — editing the product's description or colour field will not affect the render.
For products sold in several colourways, give each variant its own image so the assistant can pick the right one when a customer asks for "the blue one".
Where the source image may come from
Your product data can be any shape — the assistant reads whatever your tools return and finds the image field itself, whether you call it images, media, photos or something else. Two rules are enforced server-side regardless of shape:
- It must come from one of your tools. Only image URLs returned by a product lookup in that conversation can be rendered. A URL the assistant wrote from memory, guessed from a URL pattern, or read off the page is refused.
- It must belong to the product being rendered. Lookups often return related or recommended products alongside the one asked for. The assistant names the product it is rendering, and an image taken from a neighbouring record in the same response is refused rather than rendered.
If your media lives outside the product record — a separate assets collection, say — the second check can't be applied and the render proceeds on the first alone.
Enabling it
In the dashboard, open your application's Behavior settings and turn on Enable image generation. While the toggle is off, the assistant has no access to the image tool and cannot generate images.
Quality
Once enabled, choose a quality tier:
| Quality | Best for | Relative cost |
|---|---|---|
| Low | Fast previews | Lowest |
| Medium | Everyday mockups | Medium |
| High (default) | Marketing-grade mockups | Highest |
You control the quality tier — the model never does. Every generated image is billed at the same per-image rate for your plan regardless of the quality you pick, so a lower tier only reduces latency and the underlying generation cost, not your invoice line.
Higher quality produces more convincing mockups but takes longer to generate. Start with Medium if latency matters more than fidelity for your use case.
Guardrails
A few limits keep cost and abuse bounded, enforced server-side:
- Per-conversation cap — once a conversation has generated several images, the tool is withheld for the rest of that conversation.
- Per-turn cap — a single assistant turn generates at most a small number of images.
- Rate limiting — image-capable turns are rate-limited per client; over the limit, the assistant continues as text-only rather than failing.
Billing
Image generation is its own metered dimension, separate from AI messages and voice. Each plan includes a monthly image allowance; usage beyond it is billed at the plan's per-image overage rate. Image generation is available on every plan, including PAYG.
| Plan | Included images / mo | Overage |
|---|---|---|
| PAYG | 0 | $0.45 / image |
| Growth | 100 | $0.45 / image |
| Business | 400 | $0.40 / image |
| Scale | 1,000 | $0.35 / image |
| Enterprise | Custom | Custom |
You can track image usage on the Usage page and see your included allowance, usage, and any overage on the Billing page.
Privacy. Photos a user uploads are sent to the image model to generate the mockup and are stored on Yak's private CDN, served only through signed CloudFront access. Generated mockups are retained for 30 days so they remain visible in conversation history, then automatically deleted. Uploaded source photos follow the standard 7-day chat-upload retention.