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.

4 min readSume
All posts

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.

429 from the gate versus 429 from Sume, vendor and Sume docs read 2026-10-13
SourceWhat it meansDo
Decision-1 deploymentDeployment rate limit exceededBackoff, cap retries, then review; or request quota
Sume rate_limitedToo many requests in the windowUse retry-after if present; same Idempotency-Key
Sume queue_fullConcurrency and queue capacity both fullWait 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

All Developers posts

Written by Sume