Reliability guide

Retry only errors that are safe to repeat

Unbounded retries increase cost and can duplicate side effects. Classify the failure, keep the original request identifier and cap each retry path.

Create account Read the docs View pricing

Planned recharge methods: Alipay and USDT. Collection is not enabled yet.

Typical categories

Authentication: fix the key or account state; do not retry blindly.
Validation: correct the request.
Rate limit: back off with jitter.
Timeout: retry only when the operation is idempotent.
Upstream unavailable: fail over only to a tested model path.

Log useful evidence

Request ID
Model name
HTTP status
Error code
Attempt count
Duration

Never log the full API key or sensitive prompt data by default.

Common questions

How many times should I retry?

Use a small bounded number based on the error class and request latency budget. There is no safe universal unlimited retry policy.

Can I retry a tool action?

Only when the action is idempotent or protected by an idempotency key and your application can determine the previous outcome.

Related resources

Rate limits answer different failure modes Treat a streamed response as an interruptible sequence Security starts with narrow keys and visible limits Service availability and support policy