Decision-1 score question: order a Sume render queue by urgency
A Decision-1 score is a probability-weighted index, good for ordering but not an absolute grade. Sort briefs with it, then respect Sume's queue limits.

Yes, a Decision-1 score question is a reasonable way to order a render queue, as long as you use it for relative order only. Microsoft's page says the returned score is the probability-weighted average of the level indexes and advises preferring scores for relative ordering and thresholds, not as absolute, calibrated ratings.
How the score is built
You list levels from lowest to highest in criteria. With four levels the result runs from 0 through 3 and can land between levels. A brief the model finds borderline between Minor and Major might score 1.5, which is exactly what you want when sorting.
| Piece | Fact | Consequence |
|---|---|---|
| Scale | Levels listed lowest to highest; result between 0 and n-1 | Sort descending to put most urgent first |
| Calibration | Not an absolute rating | Do not compare scores across differently worded questions |
| Sume capacity | queue_full when concurrency and queue are both full | Submit in waves; wait when you get 429 queue_full |
| Order inside Sume | Not documented as priority-based | Order on your side before you submit |
Order, then submit in waves
Sort your briefs by score and submit the top of the list first. Because Sume does not document a priority input, the order is your own: send what matters most while capacity remains, and hold the rest. The generation admission page explains how queued and processing jobs count, and jobs_wait or polling tells you when a slot opens.
Wording shifts scores, so keep the same question text for the whole batch and re-test it if you edit it.
Edge cases
Ties are common when scores are rounded. Break them with something you control, such as submit time. If a request's score is missing, because the call failed, put it in review and not at the head of the queue.
Re-score when the brief changes, because a changed state is a new question to the model.
- Break ties by time.
- Never default a failure to top priority.
- Re-score on edit.
Sources
Related posts
More in Developers
- Decision-1: judge a pending generate_video call as JSON state
Decision-1 accepts JSON as state. Pass the tool arguments of a pending Sume call and ask one noul question; keep keys and signed URLs out of the state.
- Image API returned 202 at 4K: handle the job envelope in Python
A slow 4K, high-quality or large-n request can miss the 30 second wait and return 202 with a job, not images. Branch on the status code, then poll.
- Omni Flash edit: test at 360p, then run the final at 1080p
Prove an Omni Flash edit prompt at 360p ($0.0375 a second on Sume) before paying for 1080p ($0.1875 a second). Use a new Idempotency-Key for each resolution.
- Omni Flash edit in sync mode: it waits 30 seconds, then you poll
Sync mode on Sume waits at most 30 seconds. An Omni edit may not finish in that time, so read the job id from the reply and poll it. Never resubmit.
Written by Sume