Flux Kontext Dev API Documentation

Flux Kontext Dev API Documentation

Playground

FLUX.1 Kontext Dev is an open-weight, open-code image-to-image model that edits images from text prompts for precise, text-guided retouching and style transfer. Ready-to-use REST inference API, best performance, no coldstarts, affordable pricing.

Features

FLUX.1 Kontext Dev is an open-weight, open-code image-to-image model built for instruction-based editing. Provide a source image plus a natural-language edit request, and the model rewrites the image while preserving the original context when asked—making it suitable for targeted retouching, object changes, background swaps, text edits, and controlled style transforms.

Key capabilities

• Instruction-based image editing from a single input image
• Strong subject and scene preservation when you explicitly request it
• Local and global edits: change specific regions or the whole image
• Iterative editing workflow: apply multiple edits step-by-step with minimal drift

Typical use cases

• Retouching: lighting, exposure, cleanup, blemish removal
• Object edits: add/remove/replace items, change colors/materials
• Background replacement: swap environments while keeping the subject consistent
• Text edits: add or replace words on signs, posters, packaging
• Style transforms: convert to clay, illustration, cinematic, etc., while preserving composition

Pricing

$0.025 per image.

Cost per run = num_images × $0.025 Example: num_images = 4 → $0.10

Inputs and outputs

Input:

• One source image (upload or public URL)
• One edit instruction (prompt)

Output:

• One or more edited images (controlled by num_images)

Parameters

• prompt: Edit instruction describing what to change and what to keep
• image: Source image
• width / height: Output resolution
• num_inference_steps: More steps usually improves quality but increases latency
• guidance_scale: Higher values follow the prompt more strongly; too high may over-edit
• num_images: Number of variations generated per run
• seed: Fixed value for reproducibility; -1 for random
• output_format: jpeg or png
• enable_base64_output: Return BASE64 instead of a URL (API only)
• enable_sync_mode: Wait for generation and return results directly (API only)

Prompting guide

Write prompts like an editor’s brief:

1. Preserve clause: what must stay the same
2. Edit clause: what must change
3. Constraints: realism level, lighting, placement, typography, materials
4. Consistency: match shadows/highlights to the new scene

Template: Keep [what must stay]. Change [what to edit]. Ensure [constraints]. Match [lighting/shadows/style consistency].

Example prompts

• Keep the person’s face, pose, and clothing unchanged. Change the background to a foggy gothic castle. Match lighting and shadows to the new environment.
• Change the car color to red. Preserve reflections and keep the rest of the scene unchanged.
• Add the text “COOL” on the sign in the same perspective, with realistic shadows, and do not alter anything else.
• Turn the image into a clay style with handcrafted texture and soft studio lighting, while keeping the composition and subject identity.
• Remove the background crowd and keep the main subject sharp and unchanged.

Best practices

• Start simple, then iterate: do one change per run for maximum control.
• If the edit is too aggressive, lower guidance_scale and strengthen the preserve clause.
• For A/B comparisons, keep seed fixed and change only one parameter at a time.
• Use aspect-matched width/height to avoid unintended stretching.

Authentication

For authentication details, please refer to the Authentication Guide.

API Endpoints

Submit Task & Query Result

set -euo pipefail

export WAVESPEED_API_KEY="your-api-key"

REQUEST_BODY=$(cat <<'JSON'
{
  "num_inference_steps": 28,
  "guidance_scale": 2.5,
  "num_images": 1,
  "output_format": "jpeg"
}
JSON
)

# 1. Submit the prediction once. Never retry this request automatically:
# a retry after an unclear failure can create a second, billed task.
CHECK='The task may already exist. Check History or the predictions list before submitting again.'
if ! SUBMIT_RESPONSE=$(curl --silent --show-error --fail-with-body \
  --connect-timeout 10 --max-time 60 \
  -X POST "https://api.wavespeed.ai/api/v3/wavespeed-ai/flux-kontext-dev" \
  -H "Authorization: Bearer ${WAVESPEED_API_KEY}" \
  -H "Content-Type: application/json" \
  -d "${REQUEST_BODY}"); then
  printf 'Submit failed. %s\n' "${CHECK}" >&2
  exit 1
fi

TASK=$(printf '%s' "${SUBMIT_RESPONSE}" | jq 'if type == "object" and has("data") then .data else . end')
PREDICTION_ID=$(printf '%s' "${TASK}" | jq -r '.id // empty')
if [ -z "${PREDICTION_ID}" ]; then
  printf 'Submission response did not contain a prediction id. %s\n' "${CHECK}" >&2
  exit 1
fi
RESULT_URL="https://api.wavespeed.ai/api/v3/predictions/${PREDICTION_ID}/result"

# 2. Poll until the prediction reaches a final status.
BODY_FILE=$(mktemp)
trap 'rm -f "${BODY_FILE}"' EXIT
while true; do
  # Transient errors (429, 5xx) are retried, honoring Retry-After.
  HTTP_CODE=$(curl --silent --show-error --fail-with-body \
    --connect-timeout 10 --max-time 60 --retry 5 --retry-delay 2 \
    --output "${BODY_FILE}" --write-out '%{http_code}' \
    "${RESULT_URL}" \
    -H "Authorization: Bearer ${WAVESPEED_API_KEY}" || true)
  case "${HTTP_CODE}" in
    2??) ;;
    000|429|5??)  # dropped connection or temporary error: keep polling
      printf 'Task %s: HTTP %s, polling again in 10s\n' "${PREDICTION_ID}" "${HTTP_CODE}" >&2
      sleep 10; continue ;;
    *) printf 'Task %s: HTTP %s\n' "${PREDICTION_ID}" "${HTTP_CODE}" >&2
      cat "${BODY_FILE}" >&2; exit 1 ;;
  esac
  RESULT=$(jq 'if type == "object" and has("data") then .data else . end' "${BODY_FILE}")
  STATUS=$(printf '%s' "${RESULT}" | jq -r '.status // empty')

  case "${STATUS}" in
    completed) printf '%s\n' "${RESULT}" | jq '.outputs'; break ;;
    failed|cancelled|timeout|deleted)
      printf 'Task %s ended with status %s\n' "${PREDICTION_ID}" "${STATUS}" >&2
      printf '%s\n' "${RESULT}" | jq . >&2; exit 1 ;;
    *) sleep 2 ;;
  esac
done

Parameters

Task Submission Parameters

Request Parameters

Every model also accepts the global request options enable_sync_mode and enable_base64_output; see their pages for details.

Response Parameters

Result Request Parameters

Result Response Parameters