Why do background agents need a different cost model?

They can continue after a user leaves and accumulate spend across model calls, tool calls, retries, waits, and resumptions. A single chat-turn budget cannot contain work that persists beyond the session.

What limits should a background agent have?

Set separate dollar, step, wall-clock, idle-time, model-call, and tool-call limits. Each catches a different failure mode, from an expensive loop to a task that remains alive without making progress.

How should resumed agent work be accounted for?

Use a durable checkpoint and keep the same task ID across resumptions. Record completed steps and resumed spend together so repeated work is visible instead of being misclassified as a new workload.

Quick answer: Background execution is one of the most useful new patterns in agent products: a task can continue after the user closes the app, while the agent waits, calls tools, and returns later with a result....

Background agents change the FinOps clock

Updated September 10, 2026 · first published September 10, 2026

Background execution is one of the most useful new patterns in agent products: a task can continue after the user closes the app, while the agent waits, calls tools, and returns later with a result. It is also a break from the old request-response cost model. Spend is no longer concentrated in a visible session; it can accumulate while nobody is watching.

Google's Managed Agents update describes background execution together with remote MCP, custom functions, and credential refresh. Each capability expands what an agent can do, but also expands the number of billable steps and the time during which a task can remain active.

Budget the task, not the chat turn

A chat-turn budget is too small a boundary for a background agent. Create a task budget that follows the work across model calls, tool calls, retries, waiting periods, and resumptions. The budget should have both a dollar limit and a step limit. A task that has spent little money but made hundreds of low-value tool calls is still unhealthy.

Keep a ledger keyed by task ID. Record start time, end time, model calls, input and output tokens, tool calls, external service charges, retries, and final outcome. This lets you distinguish productive long-running work from an agent that is alive but making no progress.

Use timeouts as financial controls

Timeouts are not only reliability settings. A stale task consumes capacity and can wake up again after a deployment or credential refresh. Set separate limits for total wall-clock lifetime, idle time between steps, maximum model calls, and maximum tool calls. When a limit is reached, pause for human approval or terminate with a useful partial result.

Resumption needs idempotency. A task that is resumed without a durable checkpoint may repeat expensive searches, retrievals, or tool actions. Store the last completed step and the outputs needed to continue. Reconcile resumed work under the original task ID so the second run does not look like a new, unrelated feature.

Charge for value, not runtime

Longer execution is not automatically more valuable. Track completion rate, time to useful result, human interventions, and cost per completed task. A background agent that spends ten minutes and produces the same result as a two-minute workflow is a routing and prompt problem, even if the user experience hides the delay.

A production control loop

Give every background task a dollar, step, wall-clock, and idle-time budget.
Persist checkpoints before expensive or irreversible tool calls.
Require approval before crossing a risk or spend threshold.
Terminate stalled tasks and report the reason to the owner.
Review cost per completed task by workflow version, not only by model.

Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit →

Back to research