Stop Runaway API Loops Before They Run Up a Bill

Money mattersEN2026-10-25

A useful automation should have a clear stopping point, including when something goes wrong. Before leaving an AI workflow unattended, define how many requests it may make, how long it may run, and how much spending you are willing to authorize.

With Vana API, keep these controls in the application calling the endpoint. Its support for OpenAI-style clients and native Gemini requests makes client configuration relevant, but endpoint compatibility is not a substitute for your own execution limits. ([vanaapi.com](https://vanaapi.com/))

§ Step 1: Define a bounded job

Start with one concrete task, such as reviewing a document and returning a summary. Give each execution a unique job ID and an explicit completion condition. Avoid instructions such as “keep improving until satisfied” unless an independent controller decides when to stop.

For an initial test, choose conservative application limits:

Maximum model steps: six per job.
Maximum network attempts: eight across the entire job, including retries.
Maximum elapsed time: two minutes.
Maximum concurrent requests: one.

These are starting examples, not Vana API defaults. Check every limit before dispatching another request. When a limit is reached, save the partial result and return a clear stopped status.

§ Step 2: Put retries under one controller

Inspect your SDK before adding retry logic. The official OpenAI Python SDK retries certain failures twice by default and lets you configure or disable those retries. A second retry loop in your application needs to account for that behavior. ([github.com](https://github.com/openai/openai-python/blob/main/README.md?plain=1&utm_source=openai))

Choose one layer to own retries. For a tightly bounded worker, consider disabling SDK retries and implementing a small, explicit attempt budget in the application. Retry only failures you classify as transient, with capped exponential backoff and jitter. Do not retry authentication or invalid-request errors unchanged.

Count attempts across the whole job, not separately inside each tool or function. Treat a timeout as an uncertain outcome rather than proof that no processing occurred; require review before repeating an operation with external side effects.

§ Step 3: Limit every response

Set an explicit output-token ceiling on each request. In OpenAI APIs, parameter names differ by endpoint: Responses uses max_output_tokens, while Chat Completions uses max_completion_tokens. These limits include generated tokens that may not appear as visible answer text. Verify the supported equivalent for your chosen Vana API model and protocol. ([developers.openai.com](https://developers.openai.com/api/docs/guides/token-counting?utm_source=openai))

Match the ceiling to the task. A classification should not receive the same allowance as a long report. Also establish an input-size policy: reject oversized documents, select relevant passages, and avoid automatically appending complete logs to every subsequent request.

§ Step 4: Reserve budget before dispatch

Create a per-job spending allowance and a shared allowance for the service. Before sending a request, reserve a conservative estimated amount using the selected model’s current rates, estimated input tokens, and maximum output allowance. Include applicable token categories rather than assuming one flat rate.

After completion, reconcile the reservation against reported usage. OpenAI-style usage distinguishes input and output token counts; use those reported fields rather than estimating cost from the visible answer’s length. ([developers.openai.com](https://developers.openai.com/api/docs/guides/token-counting?utm_source=openai))

Make reservation updates atomic across workers. If usage is unavailable after a timeout, retain a conservative reservation until reconciled. Describe this as an application guardrail, not a guaranteed billing ceiling.

§ Step 5: Stop repetition and require approval

Record each tool name, normalized arguments, and a fingerprint of its result. Pause when the same action produces the same outcome repeatedly. Require explicit approval to increase the budget or continue after a stopping condition.

Enforce these decisions in code outside the model conversation. A request to “stay within budget” is not enforcement: Anthropic’s documented task-budget mechanism, for example, is a soft hint rather than a hard cap. ([platform.claude.com](https://platform.claude.com/docs/en/build-with-claude/task-budgets?utm_source=openai))

§ Step 6: Test the stop path

Before deployment, simulate repeated tool failures, timeouts, oversized inputs, and competing workers. Confirm that limits prevent further dispatch, reservations remain consistent, and a service-wide kill switch blocks new requests.

Create a Vana API account, then begin with one supervised, low-budget job. Expand its permissions only after you have verified how it stops, not merely how it succeeds.