20131 20131
中文

Your agent doesn't know what it costs. Who's watching?

2026-10-08 — a coding agent that loops on a failing test doesn't feel the bill. It retries, spawns a helper, and retries again. Each step is locally reasonable. The total isn't. The money lives somewhere else: on your provider's billing plane, while the agent's process only sees requests going out.

Why spend limits are hard for agents

What you can measure honestly today

A cap that survives its own outage

Every control depends on something that can fail. If your spend limit has to ask a remote endpoint and that call times out, gets rate-limited, or returns garbage, there are two lazy answers: allow everything, or block everything. Both are wrong. The contract we design against: on external-intelligence failure the runtime falls back to deterministic local policy, graded by the action's reversibility and blast radius — never binary. A budget cap that disappears with its own network calls is not a cap; it is a suggestion with latency.

The part that does not exist yet

Observation tells you what happened. A team running several agents wants a limit that holds the next action until a human says yes, and one view across everyone's machines. We are deciding whether to build that as a Team plan. It does not exist today, there is no price, and nothing on this blog gets ahead of the code.

If you run coding agents and a runaway invoice is the incident you would rather prevent than reconstruct, join the <a href="/en/early-access/">Early Access waitlist</a> or write to <a href="mailto:[email protected]">[email protected]</a> with the limit shape you would actually use. Every email is read by a human. If nobody asks for this, it stays unbuilt — that is the honest experiment behind this page.