How long does GPT Image 2.5 take? Time your own jobs on Sume

Sume's docs give no per-model time for GPT Image 2.5, so this post quotes none. What they do give is a budget: POST /v1/images blocks for up to 30 seconds, and most catalog models finish inside it. Anything slower returns a 202 job to poll. The honest way to learn your own number is to time your prompts at the quality and size you plan to ship.

Waits and job rules are from Sume's Image API and Jobs and results docs, read 2026-09-29.

What does the 30-second limit actually mean?

It bounds how long the HTTP request blocks, not how long the job may take. wait_timeout_seconds runs from 0 to 30 with a default of 30. When it runs out, Sume returns the job envelope with 202, and the docs say to poll rather than resubmit.

How do I time my own prompts?

Send the same prompt at each quality you care about and print the status code with the elapsed time. Run each setting several times, since one sample says little. A 200 time is a real finish time; a 202 only tells you the job outlasted the wait.

for q in low medium high xhigh; do
  for i in 1 2 3; do
    curl -s -o /dev/null -w "$q run $i: %{http_code} %{time_total}s\n" \
      -X POST https://api.sume.com/v1/images \
      -H "Authorization: Bearer $SUME_API_KEY" \
      -H "Content-Type: application/json" \
      -d "{\"model\":\"openai/gpt-image-2.5\",\"prompt\":\"A ceramic teapot on a wooden table\",\"image_size\":\"1024x1024\",\"quality\":\"$q\"}"
  done
done

Which settings push a job past 30 seconds?

The docs name three: 4K output, high quality and large n. Omitting quality runs high, so a default request already sits in the slow group. Compare your timings across tiers to see how far each step moves the number for your prompts.

How long should I wait for a 202 job?

Poll GET /v1/jobs/{id}/status and fetch GET /v1/jobs/{id}/result once it is ready. On Sume's remote MCP, the jobs page says an image still running at 50 seconds is usually stuck rather than slow. That figure is for MCP waits, so treat it as a hint and set your own timeout from the timings you measured.

How should I record the timings?

Log the status code, the elapsed time, the quality and the size for every call, then read the spread rather than one number. Look at the median and at the slowest run in each group. The slowest run is the one that decides how long your users wait and how often you fall into the 202 path.

Repeat the test at a different hour, since a single quiet minute can flatter the result. Store the log with the date so the next model change can be compared against it. A dated table from your own traffic will tell you more than any figure quoted from a launch page.