A sandbox bounds what an agent touches, not what it spends

A container bounds what an agent can damage, not what it can bill. Containment works by refusing access to resources the host is able to revoke — filesystem paths, network destinations, memory, CPU — and every one of those limits is enforced by denying something that would otherwise have cost nothing. The provider API call is the single capability a coding or research agent cannot work without, which means it is on the egress allowlist by construction. A perfectly contained agent spends exactly what an uncontained one does.

Containment keeps arriving as the answer

Several Hacker News items in the week to 2026-10-16 treat the sandbox as the control surface for an autonomous agent. One submission on 2026-10-16 is titled, in full, "Space (AI agent containment sandbox) software open source". A commenter in a thread about on-device models described the same setup as routine practice:

I primarily use AI coding agents within a container on a dedicated computer. I'd be annoyed if it somehow broke out of its container and managed to rm -rf /.

A launch the same week for cross-platform agent lifecycle management lists kill and resume controls alongside auto-discovery and a searchable audit trail.

Every one of these is the right instinct about a different failure. rm -rf / is state you cannot get back; a kill switch ends a process; an audit trail tells you who owned it. None of them is a ceiling, because the resource that runs away is not held locally and cannot be taken back once granted. The sandbox shrinks the blast radius in the dimension of damage and leaves the spend blast radius exactly where it was.

The one capability the boundary has to allow

Write the egress rules for a coding agent and the list converges fast: package registries, the Git remote, and the provider endpoint. Drop the last one and the agent is a text editor. So the request that bills is the request the boundary is configured to permit, and it is permitted on every turn, for as long as the container is up.

The grain is wrong too. A container is one boundary around however many agents the process defines. According to Capsera's July 2026 scan of 133 public agent repositories, the repositories making direct model calls carried a median of 2 agents each and 8 at the 90th percentile — all of them inside one process, and therefore inside one sandbox. Most agent repositories call providers through a framework rather than directly, so the socket the container sees is opened by library code on behalf of an agent whose name never reaches the network layer. A network policy can tell you that something in there talked to a provider. It cannot tell you which of the eight. The method and its limitations are published, including what the scan counts as an agent.

A limit the agent can read becomes more calls

The second-order effect runs the other way, and it is the part worth sitting with. A resource limit inside a sandbox is usually surfaced to the agent as an error, deliberately, because that is what lets the agent recover. A developer announcing a sandboxed execution system put the design goal plainly:

If a runaway command turns into a nice error for the agent then it becomes something that will self-resolve without fuss.

As reliability engineering that is correct. As cost behaviour it is an amplifier. Every self-resolution is another turn, and a turn late in a run carries the whole accumulated transcript plus the failed command's output as input tokens. A memory cap that kills a process ends the spend. A memory cap that returns a legible error converts an infrastructure failure into billed reasoning, and the better the agent is at recovering, the more of it there is. This is the same mechanism as a failed agent run being billed in full: the money goes to the path the error took, not to the work that succeeded.

A granted token budget is not a pre-call check

A Hacker News submission on 2026-10-15 describes an experiment in exactly the shape this ends in. Per the submission, a researcher gave an agent a refund task, "then left it alone for 15 days and gave it a 40M token spend budget". The results it reports are from a simulation rather than a provider invoice, so treat the number as the size of the allowance rather than as a bill anyone paid. The allowance is the interesting part regardless.

Forty million tokens handed over at the start of a fifteen-day unattended run is a quantity, not a ceiling. The difference is where the arithmetic happens. A quantity granted up front is checked by whatever decides to check it — often the agent itself, reading its own counter, which makes the control a function of the thing being controlled. A ceiling is checked before each call by something outside the loop, and refuses. Only the second one holds when the loop is the part that has gone wrong, which is the whole content of runaway agent loop: spend bounded by how long the loop runs unnoticed rather than by the size of the task.

Fifteen days is also the answer to the question what a runaway agent actually costs was written around. The kill switch and the audit trail both require someone who noticed, and the interval before anyone notices is the quantity that sets the bill.

Four things worth checking

1. Which destinations the egress policy allows, and what each one bills. Provider endpoints are the allowlist entries that cost money per request. If a gateway or a secondary provider is also allowed, that is a second billed destination and usually a second price table.
2. Whether resource limits inside the sandbox terminate or return an error. Terminate ends the spend. Return-an-error buys retries at the current transcript size, which is the largest it has been all run.
3. How many agents share one container. That number is the ceiling on how finely the boundary can attribute anything, and it is usually greater than one.
4. Whether the token budget is granted or enforced. Ask what code path reads it, and whether that path runs before the request or after the response.

Where Capsera sits

Capsera runs inside the sandbox rather than at its edge, which for this problem is the useful side of the line. capsera.init() patches the provider clients — Anthropic messages, OpenAI chat completions, OpenAI embeddings and Google Gemini, sync and async — so the call is seen in-process, before it reaches the boundary that was always going to let it through, and before any of it is billed. A per-agent budget with a blocking action is checked at that point and raises BudgetExceededError, so the refused call spends nothing. Attribution comes from the decorator scope held in a ContextVar, not from the socket, which is how eight agents behind one network policy stay separable.

Three limits to state. Budgets are scoped per agent, per team or globally; a per-run cost ceiling is a category concept we write about and not a shipped feature, so a long unattended run is bounded by its agents' envelopes rather than by the run. A call matching no budget proceeds. And the SDK's own emitter needs egress to api.capsera.ai — a strict allowlist that omits it will make the SDK fail open, which means your calls keep working and stop being counted, so put it on the list or expect a silent gap.

Two places to look elsewhere. If the sandboxed agent is a binary you did not write — a vendor's coding agent, something installed from a registry — there is no process to call init() in, and the only place left to put a ceiling is the request path: LiteLLM is MIT-licensed, free, covers 140+ providers and enforces hard budgets per key, team, organisation and model, and a proxy on the other side of the boundary is the correct shape for code you cannot instrument. If what you need is the content of the turns a contained agent spent its recovery budget on, Langfuse is open source, free and built for trace inspection; Capsera stores hashes and token counts and never prompt or response content. Which layer answers which question is set out in gateway vs observability vs governance.