How Octopus Users Should Read OpenClaw creator burned through
Tom's Hardware reported a 30-day OpenClaw run that used about 603 billion tokens across 7.6 million API requests, generated by roughly 100 Codex instances. That works out to roughly 79,000 tokens per request before you even ask whether the work was converging. For Octopus readers, the point is not to gasp at the bill; it is to learn how a mobile coding workflow should show burn rate, progress, and stop conditions before an agent keeps spending just because nobody is watching closely.
TL;DR: Treat the OpenClaw bill as a control-system lesson. A useful Octopus session should show the goal, the last changed files, the latest test or log result, the approval waiting on the user, and a clear stop condition. If a mobile agent run cannot show those signals, the problem is not merely token price; the problem is that the workflow has no feedback loop.
What problem is real?
The real problem is unattended iteration. Agentic coding can burn budget in three boring ways: it resends too much context, repeats commands after weak failures, or explores adjacent code instead of narrowing the original task. A phone is actually a good place to catch that, because the user is usually approving the next step in small bursts. Octopus should make that approval moment useful: what changed, what failed, what the agent wants to do next, and why that next move is still worth the spend.
| Coverage area | Specific angle | Reader value |
|---|---|---|
| Cost signal | 603B tokens over 7.6M requests implies a large context and iteration footprint | Shows why request count alone is not enough; the user needs progress per request |
| Mobile checkpoint | Last diff, last command, latest test/log result, and pending approval | Lets the user decide whether the agent is converging or looping |
| Stop rule | Pause after repeated failures, unchanged files, or a next action with no observable result | Prevents a phone-launched session from turning into unattended spend |
| Escalation point | Move to desktop for repo-wide refactors, secrets, migrations, or broken local environments | Keeps mobile control useful without pretending every coding problem belongs on a phone |
How to use it
Before approving the next agent action from Octopus, ask for five visible pieces of state: the exact task, the file or module being touched, the command the agent wants to run, the expected observable result, and the stop rule if that result does not appear. That is not bureaucracy. It is the smallest scientific loop available in a coding workflow: hypothesis, intervention, observation, decision. If any one of those pieces is missing, the next request may still be interesting, but it is no longer controlled work.
The baseline
A normal desktop workflow already has friction that protects the user: you see the terminal, the editor, the changed files, and the failing test in the same visual field. Mobile removes some of that friction, which is useful when you only need to steer a known thread, but dangerous when the agent starts inventing work. So the phone view has to replace lost context with sharper summaries, not softer reassurance.
Phone-side checks: Continue only if the last step produced a changed file, a narrower error, a passing or more informative test, or a logged finding that changes the next action. Pause if the same failure appears twice, if the agent asks to broaden scope without evidence, or if the next command cannot be explained in one sentence.
Control points
The cleanest control point is the approval boundary. Approve a test rerun when the agent changed the suspected file. Approve a targeted search when the error message names a module. Do not approve a broad refactor just because the agent says the codebase is complex; of course it is complex, that is why the agent was hired. The user should be able to see whether each turn reduces uncertainty. If it does not, the run is spending context without buying knowledge.
Budget read: Do not judge the session by dollars alone. Judge it by progress per loop. A high-token request can be justified if it resolves a hard context problem; a cheap request is still waste if it repeats the same failing command with no new evidence.
When to continue
Continue from the phone when the thread is already narrow: a build is one error away from passing, a bug has a known reproduction, or the agent needs approval for a command that has an obvious expected result. That is the sweet spot for Octopus. You are not trying to do deep architecture review on a small screen; you are steering a bounded operation that would otherwise sit idle until you return to the desktop.
When to stop
Stop when the next action needs broad context you cannot inspect on the phone: a schema migration, a security-sensitive change, a dependency upgrade with unclear side effects, a repo-wide rename, or an environment problem where the agent is guessing. Those are desktop moments. The scientific move is not to keep sampling forever; it is to change the instrument when the current one cannot observe the thing you need to know.
What to ignore
Ignore the theatrical part of the headline. The useful lesson is operational: agents need budgets, checkpoints, and interruption points that are visible to the person approving the work. A mobile Codex workflow is mature when it can say, plainly, "this run is still converging" or "this run has become exploration." Everything else is just a bill arriving late.
FAQ
When should Octopus users care about a cost story like this?
Care when it changes how you approve work: the next action should have a target file or command, an expected result, and a stop condition before the agent spends another turn.
What is the safest mobile approval rule?
Approve steps that reduce uncertainty. Pause steps that broaden scope, repeat the same failure, or require context you cannot inspect on the phone.
When is the desktop still necessary?
Use the desktop for broad refactors, database or schema changes, security-sensitive edits, broken environments, and any task where you need to compare several files or logs at once.