A timeout after the request was sent

Your application sends a request for an AI response. A few seconds pass, then the connection times out. There is no answer on screen, so sending the request again feels reasonable.

But a timeout tells you that your application stopped waiting. It does not tell you whether the service received the request, generated an answer, or recorded billable usage. The first request may have succeeded while its response was lost.

This is where careful retries begin: with the difference between a request that failed and a request whose outcome you do not know.

§ Backoff gives a busy service time

A retry is another attempt at an operation. Backoff is the pause before that attempt. Instead of repeating a request immediately, your application waits, then tries again if the failure is suitable for retrying.

With exponential backoff, the pause grows after each failure. A simple schedule might wait one second, then two, then four. Add a small random variation, called jitter, so many applications do not retry at exactly the same moment.

If the service supplies a Retry-After instruction, respect it. Also set a maximum number of attempts and an overall deadline. Three attempts means the original request plus two retries; naming that limit clearly prevents accidental extra attempts.

Backoff reduces pressure during an outage or traffic spike. It does not prevent duplicate work or duplicate charges.

§ A second attempt can become a second bill

Consider a request sent through Vana API, which bills per real token with no monthly fee. If your application sends the same prompt twice and both requests run, both may produce billable usage. Identical text does not make two requests a single operation.

The usual protection is idempotency. Your application gives one logical operation a unique identifier. A service that supports idempotency can recognize repeated attempts with that identifier and apply its documented duplicate-handling rules.

That protection must exist on the receiving side. Adding an arbitrary Idempotency-Key header does not establish a guarantee. Before relying on it, verify support for the specific endpoint, including how long identifiers remain valid, whether request bodies must match, and what happens when the first request is still running.

Vana API offers an OpenAI-compatible endpoint at https://api.vanaapi.com and also speaks the Anthropic Messages and Gemini native protocols. Protocol compatibility alone does not establish an idempotency or billing guarantee. Check the applicable documentation before enabling automatic retries.

§ Keep a small record of each operation

Even when a service supports safe retries, your application needs a durable record. Save the operation identifier before sending the request, along with its status. Useful states are pending, succeeded, failed, and unknown.

• Pending: the request has been started and is awaiting a result.
• Succeeded: the result has been saved and can be shown again.
• Failed: there is sufficient evidence that the operation did not complete.
• Unknown: the connection ended without a confirmed outcome.

When a user clicks again, check that record. Return an existing result, or show that the operation is still being checked. Make the check and state change atomic, meaning two simultaneous clicks cannot both claim permission to start the same work.

§ Treat uncertain outcomes differently

A validation error usually needs a corrected request. A rate limit may justify a delayed retry under the service's documented rules. A timeout or server error can leave the outcome uncertain; the status alone may not prove that no work occurred.

If documented idempotency is available, reuse the same identifier and unchanged request within its supported limits. If it is unavailable, pause automatic retries after an ambiguous outcome. Check available request records or contact support before submitting potentially duplicate work. This trades immediate recovery for protection against an uncertain extra charge.

Also inspect your SDK's retry settings. An SDK and your application can each retry, multiplying attempts without an obvious second click. For streaming responses, a broken connection after some text arrives deserves the same care: restarting may generate a separate response.

If your application charges its own customers, record that charge once per logical operation as well. That protects your customer ledger; preventing repeated upstream usage still depends on the safeguards above.

Create a Vana API account to try a small integration, then confirm its retry behavior before depending on it. Start with bounded waits, saved operation states, and a clear path for uncertain outcomes.