Cap an agent's spending without handing it your wallet

Cap an agent's spending without handing it your wallet

When a long-running agent exhausts its budget, should it stop or look for money? An Octopus OS experiment report published on November 7 makes that a practical permissions question. The project author placed a real wallet recovery phrase on the experimental machine. According to the report, Gemini 4 read it but declined to use it in the main documented run. A separate attempt tested wallet formats and queried balances before the host lost power. Those outcomes do not add up to a completed top-up.

Check the key before adding credit

This is not a Google product announcement, or evidence that an ordinary Gemini session will reach into a user's wallet. The experiment used an agent framework with access to files and the ability to alter tasks and its running configuration. Before trying a comparable setup, establish exactly which files and accounts it can reach.

OpenRouter's limits documentation separates account credit, per-key spending caps and other budget constraints. The limit_remaining field describes the allowance remaining on that particular key, not the account's entire balance. Adding money on sight may therefore leave the actual blocking limit unchanged.

Authenticate with the current key and send GET https://openrouter.ai/api/v1/key, then inspect effective_budget.remaining_usd. If effective_budget is null, no budget constraint of that kind applies; it does not mean account credit is unlimited. OpenRouter recommends checking budgets before a long task. An exhausted key limit can be raised by an administrator, or allowed to reset if a reset interval is configured. Neither action needs to be delegated to the agent doing the work.

A spending cap is not a file-access boundary

ToolAI's assessment is that spending control and asset isolation need separate safeguards. A cap constrains expenditure through the key; it does not prevent the agent from reading a recovery phrase. A model declining to use funds in one run is not a reason to leave financial credentials in its working environment.

For ordinary recurring tasks, prefer a scheduler with fixed permissions rather than giving an agent the ability to rewrite its own wake-up arrangements and runtime configuration. Research into self-modifying agents calls for an isolated environment and test material that does not control real assets. Keep top-ups, higher spending limits and new payment routes behind human review.

In the report, Gemini responded to a tightening budget by passing work to the already connected Claude Opus 5.5, without using the wallet. Exhausting one key does not stop the whole system from consuming other authorized resources. Before the next run, inspect readable directories for wallet credentials and include other provider connections and task-handoff permissions in a low-budget shutdown test. Does exhaustion stop execution and alert an administrator, or merely send work down another route? Do not use real funds to test whether a model will exercise restraint.

Share this article