Decision-1 returns 429: back off, then fail closed before Sume
Microsoft says retry a Decision-1 429 with exponential backoff. Cap the retries, then route the brief to review so a throttled gate never renders.

When the Decision-1 deployment returns 429, retry with exponential backoff a few times and then give up to review; do not fall through to a Sume render. Microsoft's troubleshooting table says a 429 means the deployment rate limit was exceeded and recommends exponential backoff or more quota. A gate that renders on failure is not a gate.
Two different 429s
Your pipeline now has two services that can return 429, and they want different handling. Sume documents 429 rate_limited (use retry-after when present) and 429 queue_full (the workspace cannot accept another paid generation until a queued or processing job finishes or is canceled) on its errors page.
| Source | What it means | Do |
|---|---|---|
| Decision-1 deployment | Deployment rate limit exceeded | Backoff, cap retries, then review; or request quota |
| Sume rate_limited | Too many requests in the window | Use retry-after if present; same Idempotency-Key |
| Sume queue_full | Concurrency and queue capacity both full | Wait for a job to finish; same Idempotency-Key |
The loop
Keep the retry budget small. The gate is cheap but it is in front of a user action.
import time
def gate_with_backoff(call, tries=3):
"""call() returns a decision string or raises RuntimeError('429')."""
delay = 1.0
for _ in range(tries):
try:
return call()
except RuntimeError as exc:
if str(exc) != "429":
break
time.sleep(delay)
delay *= 2
return "review" # never fall through to a paid render
if __name__ == "__main__":
def throttled():
raise RuntimeError("429")
print(gate_with_backoff(throttled, tries=2))Do not mix the keys
The decision call has no idempotency concept in Microsoft's page; the Sume submit does, and a retry of the Sume call must reuse its key. Never reuse a decision retry as a reason to resubmit a job.
Quota and capacity
If you see 429 regularly, the fix is quota, not a longer loop. Microsoft's table offers it as the alternative to backoff. Batch the questions: combining related questions in one request reduces the request count.
Whatever you do, keep a single place where the gate result is turned into an action, so that 'error' and 'review' can never become 'render' by a refactor.
- Count 429s per hour.
- Merge questions per request.
- Test the failure path in CI.
Sources
Related posts
More in Developers
- Decision-1, then Haiku 5.5, then a person: a three-tier gate
Add an abstention option to a Decision-1 choice, escalate unsure briefs to Claude Haiku 5.5, and keep people for the rest, before any paid Sume call.
- Decision-1 picks a video model; check it against Sume's catalog
Let a choice question pick among three model ids, then validate the pick against GET /v1/videos/models and fall back to sume/auto when it is missing.
- Microsoft-Decision-1 returns 422 or 404: deployment name and endpoint
Decision-1 wants your deployment name in `model`, not the model name. A 422 means a bad name or question; a 404 means a wrong endpoint or path.
- Microsoft-Decision-1: gate a text brief before a paid Sume video job
Send the brief to Decision-1 as a choice question, render only on 'render', and fail closed on any error. Python sample using the Foundry systemone path.
Written by Sume