VanaAPI

← Writing

A token budget for an agent left running overnight

Money mattersEN2026-10-30

An agent left running overnight can make valid API requests while doing very little useful work. It may repeat a failed tool call, revisit the same files, or keep asking for clarification from another agent. Each step looks ordinary in isolation. The surprise arrives when those steps accumulate.

The useful comparison is not between a capable model and a cheaper one. It is between an execution path that can continue indefinitely and one that must stop within an explicit budget. Here are the two approaches side by side.

§ A completion condition beside a stopping condition

Unbounded approach: Tell the agent to continue until the tests pass. If the environment is broken or the task is impossible, that instruction has no reliable endpoint. A repeated failure becomes another reason to try.

Budgeted approach: Define success separately from permission to continue. For example, allow no more than twelve model calls, three attempts at the same failing command, and twenty minutes of elapsed time. Stop when any limit is reached, even if the task remains unfinished. Return a short progress report instead of launching another recovery loop.

§ A response limit beside a run budget

Unbounded approach: Set a small output-token limit and assume the bill is controlled. That limits one response, not the number of responses. Repeated requests can also resend an expanding conversation, so input costs continue to accumulate.

Budgeted approach: Track cumulative input and output usage across the entire run. Vana API bills per real token with no monthly fee; that makes request volume and context size relevant even during unattended work. Calculate spending using the applicable model rates, rather than treating all tokens as equally priced. Include any other billable usage categories shown in the applicable pricing.

Before starting each request, check whether the remaining budget can accommodate it. Reserve a conservative allowance for in-flight work, then reconcile against reported usage. Treat this as an application-side control unless you have verified a provider-side spending limit.

§ Automatic retries beside classified failures

Unbounded approach: Retry every error, with retry logic in the SDK, the job runner, and the agent itself. These layers can multiply attempts without making that multiplication obvious in the application logs.

Budgeted approach: Give retries one accountable owner. Retry plausibly transient failures with bounded exponential backoff and jitter. Stop on invalid credentials or malformed requests rather than repeatedly submitting them. A timeout does not necessarily mean the upstream request never ran, so avoid assuming every retry is cost-free. Count retries against the same run budget as ordinary calls.

§ Growing context beside selected evidence

Unbounded approach: Append every tool result to the conversation. A large build log or repeated directory listing then travels through subsequent requests, even when only a few lines matter.

Budgeted approach: Bound tool output before it enters the prompt. Keep relevant error lines, summarize completed work, and retain references to larger artifacts outside the conversation. Preserve enough evidence for correct decisions; aggressive truncation that hides the actual error can create more attempts. Watch for repeated tool calls with substantially identical inputs and results, and pause when they stop producing new information.

§ Parallel workers beside a shared allowance

Unbounded approach: Give each worker its own generous limit. Ten individually bounded workers can still exceed the budget intended for one task.

Budgeted approach: Use a shared spending ledger and reserve capacity atomically before dispatching work. Cap concurrency as well as total calls. When a limit is reached, prevent new requests and cancel queued work. Treat cancellation of in-flight requests as best effort, not a guarantee that no further usage will be billed.

§ A compatible endpoint beside operational safeguards

Vana API provides an OpenAI-compatible endpoint at https://api.vanaapi.com and also supports the Anthropic Messages and Gemini native protocols. Compatibility makes integration easier, but it does not replace budget enforcement in your client or agent runner.

Create a Vana API account, then test these safeguards with a deliberately small allowance before leaving a job unattended. Log request identifiers, usage, retry counts, and the reason each run stopped. A predictable stop with unfinished work is easier to investigate than an apparently healthy loop that spends through the night.