effect-uai-model-retry

Retry transient model failures with exponential backoff and jitter.

30|4|Updated Apr 26, 2026
One-click install
npx skills add https://github.com/betalyra/effect-uai --skill effect-uai-model-retry
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: effect-uai-model-retry
Source: https://github.com/betalyra/effect-uai/tree/main/skills/effect-uai-model-retry
Command: npx skills add https://github.com/betalyra/effect-uai --skill effect-uai-model-retry

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill enables automatic retry of transient model failures (rate limits, transport hiccups, timeouts) using exponential backoff, while letting non-retryable failures (ContentFiltered, AuthFailed, InvalidRequest, ContextLengthExceeded, etc.) propagate immediately.

Core Features & Use Cases

  • Retry policy with exponential backoff for RateLimited, Unavailable, and Timeout errors.
  • Non-retryable errors are surfaced without retry.
  • Use cases include robust model invocation in streaming or multi-turn workflows, across providers, with safe cap on retries.

Quick Start

Wrap your model calls in a retryable pipeline with exponential backoff and a capped retry limit.

Frequently Asked Questions about effect-uai-model-retry

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I retry transient model failures like rate limits and timeouts?

Retry transient model failures such as RateLimited, Unavailable, and Timeout by applying an exponential backoff schedule with jitter to your model calls. This automatically handles temporary transport hiccups while capping the total retry attempts.

What is exponential backoff with jitter for model API calls?

Exponential backoff with jitter is a retry strategy that progressively increases wait times between failed model calls while adding randomized jitter. This prevents thundering herd problems and manages rate limits safely across providers without overwhelming the endpoint.

How do I ensure non-retryable errors like ContentFiltered or AuthFailed propagate immediately?

Non-retryable errors like ContentFiltered, AuthFailed, InvalidRequest, and ContextLengthExceeded propagate immediately without triggering retries. A tagged error flow distinguishes these permanent failures from transient ones, ensuring only temporary issues trigger the backoff schedule.

Does this retry policy work with multi-turn and streaming model workflows?

This retry policy works with both single-turn and multi-turn model calls across various provider responses. It integrates as an inline pipeline without requiring a helper service, making it suitable for streaming and complex conversational workflows.

When should I use exponential backoff for model invocation instead of failing fast?

Use exponential backoff when experiencing transient failures like rate limits, transport hiccups, or timeouts. If errors are permanent such as InvalidRequest or AuthFailed, the system fails fast and surfaces the error immediately rather than retrying.

What are the limitations of using an inline retry pipeline without a helper service?

An inline retry pipeline operates without a helper service, meaning retry logic executes directly within the call flow. It caps retry limits safely but requires the application to manage the backoff schedule state directly during multi-turn or streaming workflows.