An Agent That Burned 300,000 Tokens Without Being Asked Once

Three hundred thousand tokens, zero questions asked

Independent testing of OpenAI's always-on "dot" assistant found that it burned more than 300,000 tokens in a single day, generated 155 activity traces, and spun up several subagents, all without a single prompt from its user. It had been given read-only permissions. Nobody had asked it to do anything.

Read that last part again, because it is the whole story. The agent was not tricked, and it was not doing anything it had been told not to do. It was simply on, and being on turns out to be expensive.

The bill you did not ask for

Every other AI product on the market has an obvious cost boundary. You type something, tokens are spent, and when you stop typing the meter stops. The mental model is a taxi: it costs money while you are riding, and nothing while you are not.

An ambient agent breaks that model. It is less like a taxi and more like a building's climate control. It is always doing something, because being always-ready requires constant activity. Watching for a trigger, checking whether conditions changed, deciding whether the situation warrants waking up, planning what to do if it does. Each of those steps is a model call, and every model call has a price.

The uncomfortable discovery here is not that an agent spent money. It is that the spending happened invisibly and continuously, driven by the agent's own judgment rather than a human's instruction. There was no session to end, because there was no session. There was just a background process that had opinions about what was worth doing.

Read-only is not harmless

The second surprise is the permission model. Read-only sounds safe. It sounds like the cautious setting you choose when you want to be careful.

But read-only still means "can observe everything." An agent with read access can scan mail, documents, messages, and calendars, and each scan is itself a decision that costs tokens. Worse, observation is enough to be dangerous in a different way. An always-on reader that summarizes what it sees is, functionally, a surveillance system. The question of whether it can act is separate from the question of what it has already learned.

There is also a subtler issue. Read access gives the agent the raw material to decide that action is warranted, and the boundary between "I noticed something" and "I should do something about it" is exactly where an autonomous system becomes hard to supervise. A permission set that prevents writing does not prevent the agent from spending a great deal of effort deciding what it would write.

Why more agents make this worse

The detail that spun up multiple subagents should be the one that raises eyebrows in engineering meetings. Spawning helpers is a popular pattern precisely because it works. Split a task, hand pieces to parallel workers, collect the results. It is how you make an agent handle something too big for one context window.

It is also how you make cost nonlinear. One agent that decides to launch three subagents, each of which decides to check something else, has not spent four times the money. It has spent whatever the tree costs, and the tree's shape was chosen by a model that was optimizing for the task rather than for the budget.

Now multiply that across every user who enabled the feature and forgot about it. The economics of always-on agents are not like the economics of API calls, where the customer controls volume. They are like the economics of a fleet you have to actively manage, except the fleet decides its own routes.

The missing session boundary

Text-based assistants inherited a useful safety property by accident: a conversation ends. When it ends, the agent stops, the context is released, and the accounting is settled. Even a badly behaved agent is bounded by the fact that it only runs while somebody is talking to it.

Ambient agents have no such boundary. The product promise is that the assistant is always there, which means the process is always running, the context is always live, and the opportunities for a model to decide to do something are effectively continuous.

That is not a bug in the design. It is the design. But it means the safety question shifts from "what can it do in one turn" to "what does it accumulate over a month." Nobody in the industry has a good answer to the second question, and the first one is the only one existing evaluations are built to measure.

What oversight should look like

If the agent is going to run without being asked, then oversight cannot be a prompt-level control. It has to be structural, and it has to be boring.

A hard budget is the first piece, and it needs to be a real ceiling rather than a notification. Spend caps that alert you after the fact are not caps. The second piece is a readable log of what the agent did and why it decided to do it, because "155 activity traces" is a number, and a number is not an explanation. The third is a default that is not always-on. Most users of most products do not need continuous background reasoning, and the ones who do should be the ones who chose it.

The deeper piece is consent that survives contact with reality. Telling a user in a settings page that the agent may act in the background is not the same as the user understanding that it will spend money while they sleep. Products usually resolve this tension by slowly expanding scope and hoping nobody notices. That habit is going to look very expensive once agents have wallets.

The real lesson is about defaults

The dot findings are easy to dismiss as a quirk of one experimental product. The pattern behind them is not experimental at all. Every major assistant is moving toward being always available, and every vendor is under pressure to make it feel magical rather than metered.

Magic and metering are opposites. The more effortless the product feels, the more work is happening out of sight, and the harder it is for a user to form an accurate picture of what it costs. When the meter is hidden, the only feedback left is the bill, and by the time you see it, the decision has already been made several hundred thousand tokens ago.

The prudent position, for anyone deploying these systems now, is to treat "how much can it spend without asking" as a first-class design parameter, right next to "how well does it work." The second one is the one vendors advertise. The first one is the one that decides whether the product is still running next quarter.