OpenRouter batch statuses vs Sume job statuses mapped

OpenRouter batches normally move validating to in_progress to finalizing to completed. Sume jobs move queued to processing to completed, failed or canceled. Sume has no validating, finalizing or expired state, and it spells canceled with one L, where OpenRouter uses cancelled.

Sources: OpenRouter's Batch API quickstart and Sume's Generation admission page, read 2026-10-01.

Which statuses does each side define?

OpenRouter lists the progression above plus failed, expired, cancelling and cancelled. Its terminal set is completed, failed, expired and cancelled. Sume's admission page shows submit, then queued, then processing, then completed | failed | canceled. The docs do not publish an official mapping, so the rows below pair states by meaning only.

How does my client know a Sume job is done?

Do not match status strings alone. In async mode, poll status_url until terminal is true, then GET result_url once result_ready is true. Read terminal and result_ready off the envelope. A 2xx on submit means the job exists, not that it finished.

Does queued mean something went wrong?

No. Concurrency is a dispatch limit, not a submit limit: a workspace at its concurrency limit can still accept jobs as queued while queue capacity remains. Treat queued like a wait, not an error. If you only accept OpenRouter's spelling, add canceled to your set; the same one-L trap appears in OpenRouter video statuses vs Sume.