OpenRouter batch 24h window and expired vs Sume queued jobs

OpenRouter's Batch API runs on a 24-hour completion window, and a batch that does not finish in time can end as expired. Sume has no equivalent: queue expiration is not a public API option today. A Sume job that is queued stays a normal accepted job until it runs, and the way to drop one you no longer need is to cancel it.

OpenRouter facts are from its Batch API quickstart, read 2026-10-01. Sume facts are from Generation admission.

What does the OpenRouter window say?

The quickstart describes a 24-hour completion window, and its example batch shows completion_window: "24h". Possible statuses beyond completed include failed, expired, cancelling and cancelled; the terminal ones are completed, failed, expired and cancelled. You poll until the batch is terminal.

How do the two models compare?

Is queued a problem on Sume?

No. For paid generation, queued is a normal accepted state; workspace concurrency limits apply when workers move jobs into processing, not when the API accepts a valid job. The job statuses are queued, processing, completed, failed and canceled. Sume exposes queue counts and remaining capacity, not a per-job position or ETA.

How do I enforce my own deadline?

Keep the clock in your code. sync and subscribe modes wait at most 30 seconds; after that, keep polling the job id. If your deadline passes, cancel queued jobs before they start processing. Once generation has started, cancel returns 409 job_generation_already_started and the job completes or fails normally. The docs treat queue expiration as a possible future addition, so check the live OpenAPI schema before relying on it. For the full-queue case see queue_full vs concurrency full.