Image generation for character products — prompts, consistency, cost

Chat retains; images convert. A character the user can see — in new scenes, new outfits, new moods — is the single strongest premium mechanic we know in this category. Here is how to build the feature well against eroq-image-one.

Speaking diffusion

Image One is a diffusion engine, and diffusion has a dialect. It reads both prose and comma-separated tags; what it rewards is specificity in the right order:

subject and identity, action or pose, outfit, setting, lighting, camera, style

{
  "model": "eroq-image-one",
  "prompt": "young woman with silver bob and amber eyes, leaning on a workbench, grease-stained overalls, spaceship hangar, warm practical lights, 35mm, shallow depth of field",
  "negative_prompt": "blurry, extra fingers, watermark, text"
}

Three rules that do most of the work:

• Front-load identity. Tokens earlier in the prompt weigh more. The character's defining traits — hair, eyes, build — come first, every time.
• Always send a negative prompt. blurry, extra fingers, watermark, text is the floor; add whatever your style must exclude. It is a free quality lever.
• One scene per prompt. Diffusion averages competing instructions into mush. "In the hangar AND at the beach" produces neither.

cfg_scale (prompt adherence) defaults sensibly; raise it toward 9–12 when the engine takes too much creative liberty, drop toward 4–6 when results look overcooked.

The consistency problem

The hard problem in character imagery is that a diffusion model invents a new face every call. You cannot fully prompt your way out — but you can get surprisingly far:

1. Fix a canonical description. Write one 15–25 token identity block per character and prepend it verbatim to every image prompt. Word-for-word stability matters; synonyms drift the face.
2. Fix the style block too. A consistent rendering style ("35mm, soft grain") makes faces read as the same person even when features wobble.
3. Seed galleries, don't stream them. For a character's public gallery, generate in batches, curate the on-model results, discard the rest. At 10 credits a render, a curated 12-image gallery costs about $1.50 including rejects — price the feature, not the attempt.

Refused or empty generations refund automatically, and a prompt the engine declines returns an explicit content_blocked code rather than a silent failure — so your retry logic can tell "rephrase" from "try again".

Where images fit the product

The pattern that converts, in order of effort:

• The reveal — a one-time "see them" moment early in a relationship. One image, massive activation effect.
• Scene stills — user-triggered "show me this moment" during chat. Charge your users per render; your cost is a known 10 credits.
• The gallery — curated, drip-released, subscription-gated. Batch-generated off-peak.

Each maps to one POST /v1/images/generations call — the reference covers the parameters, and outputs return inline (base64) for you to store; nothing is retained on our side.

Budget table

Feature	Renders/user/mo	Credits	~Cost
Reveal (once)	1	10	$0.10
Scene stills	12	120	$1.20
Gallery drops (curated 3:1)	16	160	$1.60

Against a $10–15/month subscription, imagery lands comfortably inside margin while being the most visible thing the subscription buys. That combination — cheap to run, premium to perceive — is why it is the first feature we tell builders to add after chat.