export interface RetryInfo {
    attempt: number;
    nextDelayMs: number;
    error: unknown;
}
export interface RetryConfig {
    maxRetries: number;
    maxRetryDelayMs?: number;
    onRetry?: (info: RetryInfo) => void;
    signal?: AbortSignal;
}
/**
 * Ceiling on how long a single retry may sleep, in milliseconds.
 *
 * A server-sent `retry_after` is honored verbatim, and the backend emits
 * day-scale values on purpose — the trial rebind cap returns
 * `retry_after ≈ 86400` (24h) as a *retryable* 429. Without a ceiling one
 * `await client.trial.revoke(...)` would sit in an uninterruptible sleep for
 * a day (three of them, at the default `maxRetries: 3`), which an integrator
 * experiences as a hang rather than as a rate limit. 60s covers every
 * limiter window the API actually uses; anything beyond it is something the
 * caller should schedule itself, not something the SDK should sleep through.
 */
export declare const DEFAULT_MAX_RETRY_DELAY_MS = 60000;
export declare function isRetryable(err: unknown): boolean;
/**
 * How long the next attempt should wait, in milliseconds.
 *
 * A honored `retry_after` is returned **raw and unclamped** on purpose: the
 * caller needs the true figure for the `onRetry` diagnostic and for the
 * error path. Enforcing the ceiling is `withRetries`' job — it rethrows
 * rather than sleeping when the raw value overshoots, so the two branches
 * stay distinguishable (`> maxDelayMs` means "don't wait", not "wait
 * `maxDelayMs`"). Only the exponential fallback is clamped here, since it
 * grows unboundedly with `attempt` and has no caller-visible meaning.
 */
export declare function computeBackoff(attempt: number, err: unknown, maxDelayMs?: number): number;
export declare function withRetries<T>(fn: () => Promise<T>, config: RetryConfig): Promise<T>;
//# sourceMappingURL=retry.d.ts.map