DEV Community

Cover image for Routing GPT Image 2.6: Fast Previews, Precise Final Edits
Germey
Germey

Posted on Originally published at platform.acedata.cloud

Routing GPT Image 2.6: Fast Previews, Precise Final Edits

#ai #architecture #webdev #api

A production image endpoint should not treat every request the same. “Show me three background ideas” and “make the approved product image ready for launch” have different latency, quality, and review requirements.

GPT Image 2.6 exposes Flare and Sunburst. This article places them behind one service without scattering model choice through UI code.

Adapted with AI assistance from two AceDataCloud articles. Check the current model catalog and API documentation for parameters, pricing, permissions, and availability.

Start with an intent contract

Do not let clients send an arbitrary model name. Accept business intent:

type ImageStage = "preview" | "final" | "precision_edit";
type ImageJob = {
  stage: ImageStage;
  prompt: string;
  sourceImage?: string;
  preserve?: string[];
  requestId: string;
};
Enter fullscreen mode Exit fullscreen mode

The backend owns routing:

function chooseModel(stage: ImageStage) {
  if (stage === "preview") return "gpt-image-2.6-flare";
  return "gpt-image-2.6-sunburst";
}
Enter fullscreen mode Exit fullscreen mode

Flare is oriented toward responsive iteration. Public release information says it can reach about six seconds with quality=low under relevant conditions. Treat that as conditional, not a universal SLA. Sunburst fits tasks where detail and edit consistency matter more.

Build prompts from change and preservation rules 

function buildEditPrompt(job: ImageJob) {
  const keep = job.preserve?.length
    ? `Preserve: ${job.preserve.join(", ")}.` : "";
  return [job.prompt, keep,
    "Do not add text, logos, or extra objects unless requested."
  ].filter(Boolean).join(" ");
}
Enter fullscreen mode Exit fullscreen mode

For product photos, preserve might include bottle proportions, label position, camera angle, and shadow direction. These instructions improve clarity, but generative editing is not pixel locking. Text, reflections, hands, faces, and occluded regions still need human review.

Call the editing endpoint from the server 

const endpoint = "https://api.acedata.cloud/openai/images/edits";

async function submitEdit(job: ImageJob) {
  if (!job.sourceImage) throw new Error("sourceImage is required");
  const response = await fetch(endpoint, {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.ACE_API_TOKEN}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      model: chooseModel(job.stage),
      image: job.sourceImage,
      prompt: buildEditPrompt(job)
    })
  });
  if (!response.ok) throw new Error(`Image API failed: ${response.status}`);
  return response.json();
}
Enter fullscreen mode Exit fullscreen mode

Keep the token server-side. Never place it in browser code, screenshots, logs, or a repository. Check exact fields against the current Images Edits documentation.

Add an approval state machine

An HTTP success does not mean the visual asset is approved.

SUBMITTED -> GENERATED -> REVIEW_REQUIRED -> APPROVED
                                  |-> REJECTED
Enter fullscreen mode Exit fullscreen mode

Persist request and task identifiers, source authorization, model, prompt version, protected details, output reference, reviewer, decision, and rejection reason. This creates an audit trail and makes regression testing possible.

Handle retries by failure class

  • 401/403: stop and fix credentials or permissions.
  • 429: use bounded backoff.
  • 5xx/network timeout: limit retries and use an idempotency strategy to avoid duplicate paid jobs.
  • Visual rejection: revise prompt or preservation rules; a transport retry will not fix ambiguity.

Track time to first preview and time to approved asset separately. Also record revisions and preservation failures. A fast preview path is useful only if it reduces total review time.

For experiments, use AceDataCloud Studio. For implementation, consult the current generation and editing documentation.

The architecture is simple: route by stage, express preservation constraints, keep secrets server-side, and require approval. Flare and Sunburst can do different jobs without creating two parallel codebases.

Sources

Top comments (0)