Interface: RetryConfig
Resolved policy for absorbing upstream 429 Too Many Requests responses.
Databricks Foundation Model endpoints are pay-per-token with an account-level
throughput ceiling that is not exposed as a readable number, so the proxy
cannot pace against it proactively - it can only react. When enabled, a 429
is retried in-proxy with exponential backoff (honoring any Retry-After)
instead of being relayed to the client, so an agentic caller like Codex sees
a slow success rather than “exceeded retry limit”.
Properties
Section titled “Properties”baseDelayMs
Section titled “baseDelayMs”baseDelayMs:
number
First backoff, doubled each attempt (before jitter and the Retry-After override).
enabled
Section titled “enabled”enabled:
boolean
Retry 429s in-proxy rather than relaying them.
maxDelayMs
Section titled “maxDelayMs”maxDelayMs:
number
Ceiling for any single backoff, including a server-sent Retry-After.
maxRetries
Section titled “maxRetries”maxRetries:
number
Maximum retry attempts after the initial try (so N+1 total requests).