A retry loop left running after lunch

A script asks an AI model to fix a file, checks the result, and tries again. You leave it running while you eat lunch. When you return, it is still working on the same error. Each attempt looked small, but together they used far more tokens than you expected.

This is a runaway loop: repeated work without a reliable stopping point. It does not require a complicated agent. A retry around a single API request can be enough. The safest approach is to decide when the program must stop before you let it start.

§ Understand what keeps adding up

Vana API relays requests to multiple model providers through an OpenAI-compatible endpoint, with support for Anthropic Messages and Gemini native protocols. Billing is per real token, with no monthly fee. That makes usage important: no monthly fee does not mean an unattended process has a spending ceiling.

Repeated calls can consume both input and output tokens. If your program includes the entire conversation on every turn, later requests may carry more input than earlier ones. A loop can therefore become more expensive as it runs, even when its answers stay short.

§ Give every run a stopping rule

Start with limits that are easy to understand. For a first experiment, you might allow five model calls, two retries after temporary failures, and a few minutes of elapsed time. These are starting points, not universal recommendations.

• Call limit: Count every outgoing attempt, including retries and model calls made inside tool workflows.
• Time limit: Set a deadline for the whole job, not just a timeout for each request.
• Output limit: Configure the supported output-token limit for the protocol and model you use.
• Spending limit: Track estimated cost across the run and refuse another call when it would exceed your allowance.

An output limit applies to one response, not the entire loop. A spending estimate also needs current pricing and token accounting. Leave a margin for uncertainty and requests already in flight. Application-side estimates are useful guardrails, not a guarantee of the final charge.

§ Separate retries from new attempts

A temporary connection problem is different from an answer that fails your test. Treat them separately. Otherwise, a request retry can sit inside a task retry, multiplying the number of calls.

Check whether your SDK already retries automatically. Add bounded delays between retries, and follow documented retry guidance. Authentication errors and invalid requests generally need a correction, not another identical attempt.

A timeout means your client stopped waiting. It does not necessarily mean the remote work never happened or cannot be billed. Avoid immediately launching several replacement requests. If the same task repeatedly fails, stop and inspect it.

§ Notice when the loop is stuck

A successful HTTP response is not proof of useful progress. Your program might keep receiving valid answers that repeat the same suggestion.

Define progress using something outside the model’s own judgment: a previously failing test passes, a required field becomes valid, or a specific task state changes. Stop when consecutive attempts produce the same error or no measurable improvement. Ask a person to review the task rather than letting the model declare that one more attempt will help.

§ Keep the first unattended run small

Use one worker initially. Several concurrent requests can spend past a shared budget before their usage is recorded. Keep only the context needed for the next step, and log the run identifier, attempt count, reported token usage, and reason for stopping. Avoid logging secrets or sensitive prompts unnecessarily.

When using Vana API with Claude Code, Codex, Gemini CLI, or an OpenAI SDK, check the tool’s own retry and automation settings too. Your script’s limits may not control every layer.

Create a Vana API account when you are ready to test a small, bounded workflow. Watch its first run, inspect the usage afterward, and increase its allowance only when you understand where the tokens went. A clean stop is a useful result, even when the task remains unfinished.