Image job still running after 50 seconds: slow or stuck?

If an image job is still running at 50 seconds, read its status and events before doing anything else. The Sume docs put it bluntly: on remote MCP, "an image still running at 50s is usually stuck rather than slow." Do not send the create call a second time; the first one is still yours.

That sentence sits in the Jobs and results page, in the section about jobs_wait, where a wait slice is capped at 55 seconds and defaults to 50. It is a rule of thumb for typical image calls. Heavy settings are different, and the Image API page names 4K, high quality and large n as the ones that tend to come back as 202.

What should you read first?

Three reads, in order, all free:

• GET /v1/jobs/{id}/status for queued versus processing.
• GET /v1/jobs/{id}/events for the public timeline.
• GET /v1/jobs/{id} for the whole envelope, including webhook delivery state.

Queued is not stuck

A paid job in queued is a normal accepted state. Workspace concurrency limits apply when workers move jobs to processing, so a busy workspace shows queued for a while. If the queue and balance are the question, the generation-admission docs explain capacity, and queue_full appears at submit time rather than later.

A job in processing for a long time on a light request is the case the 50-second rule is aimed at.

Check the account side too. If balance or admission is the issue, the generation_admission_preview MCP tool and the generation-admission docs show queue capacity and tier limits before you submit, which is cheaper than finding out after a job sits in queued.

Can you cancel it?

Yes, before generation starts. POST /v1/jobs/:id/cancel cancels a job before generation starts; after that it returns 409 job_generation_already_started. It is idempotent on an already-canceled job. A job that has already started will finish or fail on its own, and a failed or cancelled image generation is not billed.

import os, sys, requests
B = "https://api.sume.com"
H = {"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"}
job = sys.argv[1]
print(requests.get(f"{B}/v1/jobs/{job}/status", headers=H).json())
print(requests.get(f"{B}/v1/jobs/{job}/events", headers=H).json())
if input("cancel? [y/N] ").lower() == "y":
    r = requests.post(f"{B}/v1/jobs/{job}/cancel", headers=H)
    print(r.status_code, r.json())

What about transport errors?

A 524 or similar on a wait is a transport failure, never a job outcome. Re-issue the wait or read the status once. Use exponential backoff while polling and stop on completed, failed or canceled. If you never want to wait, a webhook delivers the terminal event instead.

Finally, record what you saw. When you contact support about a job that never moved, the request id, the job id and the event timeline are what they need. Provider internals are not exposed in public errors, so the timeline is the evidence you can share.