What OpenClaw's $10 Million Token Estimate Tells Us About AI Agents
A $10 million AI bill sounds like a pricing story. But it's more interesting as a systems story: what happens when someone runs AI agents at a scale most teams can't afford, and what still stops those agents from working on their own.
OpenClaw creator Peter Steinberger said he spent roughly $10 million on AI tokens last month while speaking at Cloudflare's Connect conference, according to The Next Web's report, which cites The Register. He also added an important caveat: not all of that spending turned into useful work. The report doesn't break down the usage, the models involved, or who paid the bill, so the number is best treated as an estimate - not a "this is what it costs" reference point for building an AI agent.
Still, the comments are a decent window into the real constraints facing agent builders. Token budgets matter, but so do infrastructure, permissions, and whether anyone can review and correct what the agent produces. This article digs into what Steinberger's estimate can tell you - plus what it can't - and how to think about agent costs and control in a real project.
What the $10 million estimate actually tells us
Most AI providers meter model use in tokens - units that represent the text a model reads and generates. The pricing varies by provider, model, and the kind of token, so token usage is a convenient billing metric. But it doesn't automatically tell you what the system actually accomplished.
Steinberger's reported estimate is notable partly because it puts a big number next to something that's often discussed in vague terms. During an AI agents session with Cloudflare CTO Dane Knecht, Steinberger was described as having an almost unlimited token budget. His response was blunt: a significant share of the usage wasn't useful. That qualification matters more than the headline figure.
What the report doesn't say is just as important. We don't know whether this reflects one month of personal experimentation, work across multiple projects, or something else entirely. We also don't know whether Steinberger paid directly, whether OpenAI covered it, or whether another party picked up the tab. Steinberger joined OpenAI in February, but that alone doesn't prove who footed the bill. Without those details, treating the figure like a personal credit card statement - or a normal monthly cost for an AI company - would be misleading.
Even with all that uncertainty, one thing does come through: a large enough budget can expose inefficiencies that smaller budgets force you to hide. If you can afford to let an agent retry, explore alternatives, and call models repeatedly, you'll see where it gets stuck. But spending more doesn't automatically make the system efficient. A tool can burn through tokens and still produce work that needs serious human cleanup.
That's the part businesses should focus on. A demo might nail a task once and look impressive. A production system has to repeat the job often enough, with acceptable quality, predictable latency, and costs the business can live with. The question isn't only "what does a token cost?" It's "what does it cost to get a result a team can verify and trust?"
A practical way to evaluate an agent is to track three things at the same time:
- Total usage: model calls, input and output tokens, and any retries.
- Useful completion rate: how often the agent reaches a result that actually meets the task requirements.
- Human correction time: how much review, rework, and follow-up the result requires.
If usage climbs while useful completions don't, increasing the budget isn't the answer. You need to find where the work is getting wasted.
Why token spending does not equal useful output
An agent usually uses more tokens than a simple question-and-answer exchange. It might inspect context, plan a task, call a tool, evaluate the result, and try again. Some of that is necessary. Some of it is what you see when the task is fuzzy, the agent doesn't have enough context, or it can't reliably tell when it has succeeded.
So a big token total can mean very different things. One system might spend heavily because the task is genuinely complex, then deliver something valuable after review. Another system might churn because the instruction is unclear and it keeps circling. The meter counts usage; it doesn't count business value.
In practice, wasted usage tends to come from a few recurring causes:
- Unclear task boundaries: the agent is asked for a broad outcome without a precise definition of done.
- Repeated context: the same large chunk of instructions or documents gets sent with every request.
- Unproductive retries: the system loops because it lacks a stopping condition or can't recognize that it's failing.
- Tool failures: the model sends bad inputs to a tool, gets an error, and tries again without changing approach.
- Over-permissive autonomy: the agent can take actions before it has shown it can do so reliably.
None of that is solved by chasing the lowest token count. Optimizing only for fewer tokens can produce a brittle agent that fails more often - or forces more human intervention. What matters is the cost of a successful, accepted outcome. A "cheap" run that still needs a human to undo it isn't actually cheap in operational terms.
A simple way to measure agent economics
For a pilot, pick a small set of representative tasks and record a baseline. For each task, track model and tool costs, completion rate, time to completion, and minutes of human review. Then compare the results to the current process or to a simpler automation that doesn't use an agent.
After that, look hard at failure modes. If a task fails because the agent doesn't have access to the right systems, more prompting won't fix it. If the task fails because the request is ambiguous, clearer instructions - or a human confirmation step - may be cheaper than another model call. If the agent repeatedly misuses a tool, constrain what the tool interface allows before you add more autonomy.
Model choice belongs in this same conversation. A smaller or cheaper model may be enough for routing or classification, while a more capable model could be justified for synthesis or complex decisions. But using multiple models adds integration and monitoring overhead. It's something to test, not a universal rule.
For an initial production budget, set per-task or per-user limits, log usage by task, and alert when you see unusual spikes. That won't prevent every inefficient run, but it gives the team a way to catch a loop before it turns into an embarrassing invoice. The goal isn't to kill experimentation - it's to make it visible and keep it from quietly turning into an unbounded production process.
Why agents are moving toward the cloud - and need tighter controls
Steinberger argued that infrastructure hasn't caught up with the way people want to use agents. He questioned why an agent still needs to run on someone's computer instead of in the cloud. It's a fair question: a cloud-hosted agent can keep working when a laptop is closed, run on a schedule, and access services without depending on one person's desktop session.
But moving agents into the cloud changes the operating model - and the security boundary. A local agent often has access to files, browser sessions, and credentials that live on the workstation. A cloud agent needs its own identity, network access, storage, and secrets. It can be easier to keep running, but it can also become a persistent service with permissions that are easy to underestimate.
Cloud execution isn't automatically safer or more capable. You still have to decide what data it can read, what actions it can take, how credentials are protected, and who can inspect what it's doing. If an agent can send emails, edit records, or trigger transactions, the impact of a mistake is different from an agent that only drafts text.
Steinberger's suggestion was to use another agent to grant or deny permissions, so the "agent" negotiating happens inside guardrails. He said his experience is that agents often back down - or take a simpler route - when constrained. That can be a useful layer of control, but it's not a security guarantee. An agent deciding whether another agent should have access is still an AI system making a judgment call. It needs a defined policy, reliable logging, and a fallback when it isn't confident.
A permission model that works in practice should start with the task, not the agent's theoretical capabilities:
- Read access first: give the agent the information it needs to do the job, without write access by default.
- Limit the action surface: expose specific tools and operations instead of broad credentials or unrestricted shell access.
- Require approval for consequential actions: sending a message, changing a customer record, or spending money should require human confirmation.
- Use scoped credentials: keep credentials limited by purpose and duration, and rotate or revoke them when you're done.
- Keep an audit trail: record what the agent accessed, which tools it called, and which actions were approved.
Prompt injection is one reason those controls matter. The agent can encounter instructions hidden inside content it reads - like a web page or a document - and those instructions may try to redirect its behavior. Improving model and application design to reduce that risk is worthwhile, but it doesn't remove the need to bound permissions. The safest assumption is that an agent can see misleading input - and that any resulting mistake should have limited impact.
How much autonomy you allow should depend on the cost of failure. An agent that summarizes public information can usually get away with fewer approvals than one that edits financial records. Start with the smallest permission set that supports the task. Expand only after testing shows it's genuinely needed and the team can explain the added risk.
What this means for open source and everyday users
The discussion also touched on open-source maintainers who get frustrated by AI-generated code contributions. Steinberger argued that contributors should explain how they arrived at a solution. Seeing the reasoning behind a change would make him trust it more.
That hits a real problem with AI-assisted contributions: code can appear faster than the context maintainers need to review it. A pull request might compile and still be wrong for the project. It might introduce an unnecessary dependency, miss an edge case, or solve a different problem than the maintainers were trying to address. The reviewer still owns the consequences, even if a model wrote the first draft.
For contributors, the standard should be the same whether the code was written by a person, an agent, or both. Explain the problem, describe the approach, call out important trade-offs, and include tests that show the expected behavior. Don't treat a model's internal "private reasoning" as proof. What maintainers need is an inspectable explanation of what changed - and evidence it works.
Steinberger also questioned whether people will run hundreds of agents in a few years. His expectation was closer to one intelligence helping each person during the day: anticipating needs instead of multiplying bots endlessly. For many users, one assistant connected to a few relevant tools is easier to manage than a swarm of agents with overlapping responsibilities.
There's a trade-off there. A more proactive assistant can save time by anticipating what you want, but it also needs access to more context and it has more chances to act at the wrong moment. The value depends on whether the system's predictions are accurate - and whether the user can understand and override it when they're not.
For businesses, this argues for evaluating agents as part of a workflow, not as standalone demos. Who owns the agent? What systems does it access? How is its output reviewed? What happens when it fails? For open-source projects, require useful contribution context and tests. For individual users, start with low-risk tasks and pay attention to requested permissions - not just the convenience being promised.
The bigger lesson isn't that every team needs a massive token budget. It's that AI agents are limited by more than model capability. Cost, infrastructure, permissions, and review are all part of whether an agent can be useful in day-to-day work. Solve only one of those problems and you usually just move the bottleneck somewhere else.