image-editing-arena: Image Editing Arena: Making Image Models Agree Long Enough to Compare Them

Most image editors ask a simple question: which model should I run? This repo asks a harder one: which model should I trust for this specific edit, at this price, with this latency? That shift turns the interface into a benchmark. The product is the comparison.

A benchmark that behaves like a product

That is the trick. Image Editing Arena does not just render outputs from multiple models, it stages a fair contest. One prompt, one source image, several model backends, then a shared comparison layer that shows what each model actually cost and how long it took.

The real problem is schema mismatch

The neat front end hides a messy truth. Replicate image models do not agree on input shape, so the repo has to normalize one user action into several dialects. Some models want image, others want image_input, and some expect arrays like [image]. The adapter layer is what makes the arena feel uniform.

// Conceptual shape of the adapter layer
function createPrediction(model, input) {
  const payload = { ...input };

  if (model.owner === 'black-forest-labs') {
    payload.input_images = [input.image];
  } else if (model.name.includes('edit')) {
    payload.image = input.image;
  } else {
    payload.image_input = [input.image];
  }

  return proxyToWorker(payload);
}

async function pollPrediction(id) {
  while (true) {
    const res = await fetch(`/api/replicate/predictions/${id}`);
    if (res.status === 200 && res.done) return res.output;
    await wait(nextBackoff());
  }
}

That adapter is the repo’s most important piece of engineering. It hides model-specific quirks behind a common request path, then hands the request off to a polling loop that keeps checking until the result is ready. In other words, it makes disagreement legible.

Why the browser never talks to Replicate directly

The browser stays clean because the secret stays out of it. A Cloudflare Worker sits in front of Replicate, injects authorization, and forwards the request at the edge. That keeps the app deployable as a lightweight single-page experience without turning the front end into a key vault.

This matters for more than security. It makes the demo feel instant, reduces backend ceremony, and keeps the architecture easy to reason about. The worker is not an incidental proxy. It is what lets the product be a product.

The UI makes trade-offs visible

The interface does something many benchmark pages avoid. It puts pricing and performance next to the image results, so the user can judge output quality in context. The StatsPanel, model selector, and cost fields turn a visual task into a decision problem.

Why this matters beyond one repo

The bigger pattern is arena-fication. Text model leaderboards taught people to compare systems side by side, but image editing has its own constraints, its own schemas, and its own failure modes. A single global winner is too blunt an instrument for that reality.

This repo sits between a benchmark and a demo. That is why it is useful. It does not just say which model is good. It shows how quickly a supposedly simple image edit becomes a question of payload shape, edge proxying, polling logic, and cost awareness.