Flux-1 Kontext Max Prompt Recipes: Copy-Paste Editing Prompts That Work

What a Kontext Max Prompt Recipe Actually Is

A prompt recipe is not a paragraph of description — it is a compact instruction format that tells the model exactly what to change and what to leave alone. For Flux-1 Kontext Max, every reliable recipe we use follows the same four-part structure:

• Verb — the operation: replace, remove, recolor, add, extend, restyle.
• Target — the region or object the verb applies to, named explicitly ("the red jacket the person on the left is wearing").
• Desired change — the end state, not the process ("make it navy blue" rather than "change the color").
• Preservation clause — what must stay identical ("keep the same fabric folds, lighting, and background").

So a recipe reads like: replace the jacket on the person at left with a navy wool coat; keep pose, lighting, and background unchanged.

The key mental model: Kontext Max is an editor, not a generator. It starts from your input image and applies a diff. The smaller and more precisely bounded that diff, the more predictable the result. Prompts that read like image-generation captions ("a moody portrait of a woman in a city at night") give the model permission to regenerate everything, and it will.

The preservation clause is the piece most people skip, and it is the piece that does the most work. Without it, the model treats the rest of the image as fair game. With it, you have effectively drawn a mask in natural language — useful because you never have to build one.

Instruction-Phrasing Rules That Change the Outcome

These are the levers you control at the prompt level. Each one reliably shifts output in a predictable direction.

Imperative over descriptive

Write "remove the trash can in the lower right" not "there is a trash can that should not be there." Imperative voice maps directly to an edit operation. Descriptive voice reads as a scene caption and invites re-generation.

Name the target, not the whole image

"The sign above the door" beats "the text in the image." If your image has three signs, say which one ("the wooden sign hanging above the left doorway"). Spatial anchors — left, right, top, foreground, behind the subject — cost almost nothing and remove most ambiguity.

One edit per instruction

If you need two changes, chain them with a semicolon only when they touch the same region: remove the chair; keep the floorboards and shadows beneath it. Unrelated edits belong in separate calls. Stacking unrelated changes in one prompt is the single most common cause of collateral damage.

Order: constraint before style

Put preservation and scope constraints before any optional adjectives. Keep the background, wardrobe, and expression unchanged; restyle the lighting to soft window light works. Restyle to soft cinematic lighting, keep background unchanged leaks the cinematic treatment into the whole frame. The model weights whatever it reads last as the dominant frame of reference, so end on what must not move.

State the end state, not the steps

"Make the sky overcast with flat gray clouds" is a target. "Desaturate, add clouds, reduce contrast" is a workflow the model will not follow literally and may over-apply. Describe the result you want to see.

Avoid negation where a positive target exists

"Remove the watermark" is fine because removal is the operation. But "don't make it blurry" is weaker than "keep the subject sharp and in focus." Where you can, phrase the constraint as a positive invariant.

Keep it short

A recipe longer than a couple of sentences dilutes the instruction. If your prompt needs a paragraph, you probably have two edits or an under-specified target.

Copy-Paste Recipes for Common Edits

Each recipe below is paste-ready. Swap the bracketed parts for your specifics. The reasoning note explains why the wording is shaped that way — steal the pattern, not just the text.

Object replacement

replace the [object] at [spatial anchor] with [new object]; keep the surrounding [key surface, e.g. table/floor] and lighting unchanged Reasoning: anchor plus preservation keeps the compositing believable. Naming the surrounding surface prevents the model from re-rendering the context.

Object removal

remove the [object] at [spatial anchor]; reconstruct the background behind it to match the surrounding [surface] and fill the shadow naturally Reasoning: removal needs an instruction for what goes in its place. Without "reconstruct the background," you often get a smudge or a mismatched patch.

Background swap

replace the background with [new setting]; keep the subject's silhouette, edge detail, and lighting direction identical Reasoning: edge detail and lighting direction are where background swaps fall apart. Calling them out explicitly preserves them.

Text edit on signage

change the text on the [sign/label] to read "[new text]"; keep the font weight, perspective, and material of the sign unchanged Reasoning: short, unambiguous target plus a font-perspective lock. Keep new text short — long strings are where artifacts appear.

Color and material change

recolor the [object] to [color]; preserve the original texture, folds, and highlight placement Reasoning: "recolor" rather than "change the color to" keeps the instruction tight, and the texture clause prevents a flat fill.

Outpainting / extension

extend the image to the [left/right/top] by roughly [fraction, e.g. one third]; continue the existing [surface, e.g. wall/ground] seamlessly and match the current lighting Reasoning: naming the surface to continue and the lighting to match is what separates a clean extension from a visible seam.

Pose or expression refinement

adjust the subject's expression to a slight smile; keep head angle, hair, and the rest of the face unchanged Reasoning: "the rest of the face unchanged" is the guardrail. Face edits drift unless you fence off the neighboring features.

Restyle with a scope limit

apply a [style, e.g. watercolor] treatment to the foreground subject only; leave the background photographic and unchanged Reasoning: restyle prompts are the biggest source of over-application. A scope limit on the style is mandatory, not optional.

Wiring Recipes Into Your Code

Recipes are strings — treat them like strings in your codebase, with parameters and versions.

Parameterize, don't concatenate

Store recipes with named slots and fill them at call time:

RECIPES = {
    "object_replace": "replace the {object} at {anchor} with {replacement}; "
                      "keep the surrounding {surface} and lighting unchanged",
    "object_remove": "remove the {object} at {anchor}; reconstruct the background "
                     "behind it to match the surrounding {surface} and fill the shadow naturally",
}

def build(recipe_key, **slots):
    return RECIPES[recipe_key].format(**slots)

This keeps the phrasing stable across thousands of images. If a recipe needs tuning, you change one string, not a hundred call sites.

Keep the input image fixed per comparison

When you are tuning a recipe, reuse one baseline image. Changing both the prompt and the input makes it impossible to attribute a difference to either.

Validate slots before the call

An empty anchor is worse than a wrong one — it silently widens the edit scope. Assert that every slot is filled and that free-text slots (like new signage text) are short.

One edit per request

Since Kontext Max edits are per-call, model your pipeline as a list of edit steps, each with its own recipe and parameters, rather than one mega-prompt. A small step runner that applies recipes sequentially is easier to debug than a single sprawling instruction.

Log the rendered prompt

Log the filled prompt next to the output reference and the recipe version. When output quality shifts, you want to know whether the phrasing changed or the model's behavior did.

When the Edit Comes Back Wrong

Most failures fall into three buckets. Diagnose the symptom first, then apply the matching fix.

Symptom: the target was missed entirely

The edit happened somewhere else, or nothing visible changed.

• Widen and sharpen the anchor: "the sign above the door" → "the wooden sign hanging above the doorway on the left."
• If the object is small, say so: "the small label in the lower-right corner."
• If the model changed a similar object, add a disambiguator: "the leftmost of the two signs."

Symptom: over-editing

You asked for one thing; the model changed three.

• Add or strengthen the preservation clause: name the exact elements that must stay ("keep pose, wardrobe, and background unchanged").
• Move the constraint after the change instruction, or repeat it at the end — position matters.
• Split a stacked prompt into separate calls.

Symptom: drift

You got the right idea but the surrounding image shifted — colors, lighting, or fine detail moved.

• Convert vague preservation into concrete invariants: instead of "keep it the same," write "keep the original white balance, shadow direction, and fabric texture."
• Check for style adjectives bleeding outward; scope-restrict them ("foreground only").
• Reduce the instruction to its smallest form and re-test on the baseline image.

The loop

Run recipe → classify the failure as missed target, over-edit, or drift → apply the corresponding single fix → re-run on the same baseline input. Change one variable per iteration. Two changes at once gives you no information about which one helped.

Keep a short failure log: recipe version, filled prompt, symptom, fix, verdict. After a few projects, this log becomes more valuable than any single prompt.

Building Your Own Recipe Library

The teams that get consistent results from Kontext Max are not writing better one-off prompts — they are maintaining a small, versioned set of proven ones.

Version recipes explicitly

Give each recipe a key and a version (object_replace@v2). When you change phrasing, bump the version and keep the old one available. Small wording changes produce visibly different output, so an unversioned prompt library is a source of silent regressions.

Test against a fixed suite

Maintain a handful of fixed input images with known expected edits — a replacement, a removal, a background swap, a signage edit. Any change to a recipe runs against the suite. You are looking for two things: did the target get edited, and did the surrounding image stay put. A recipe that aces the first and fails the second is not ready.

Compare recipes, don't guess

When two phrasings both seem reasonable, run both on the same baseline input and keep the one that holds the preservation clause. The comparison is cheap; re-shooting an edited batch is not.

Let recipes accumulate organically

Start with the eight patterns above. When a teammate solves a new edit case, add it with a note on why the wording works. Over time the library becomes your team's implicit prompt-engineering documentation — and the onboarding material for anyone new to the API.

Deprecate, don't delete

The context window of your own memory is short. A recipe that failed for one image class may be perfect for another. Archive retired recipes with a note on why they were retired, so the next person does not rediscover the same dead end.

Treat prompts like code: versioned, tested, reviewed, and reused. That discipline is what turns Flux-1 Kontext Max from a demo into a dependable part of your pipeline.