让代理长期跑任务，预算不足时该停下来，还是自己找钱？Octopus OS 项目作者在１１月７日发布的实验报告提供了一个权限检查案例：作者把真实钱包的恢复短语放在实验机器上。报告称，Gemini 4 在主要记录的一轮中读到了它，但决定不用；另一次尝试则测试了钱包格式并查询余额，随后因主机断电中止。不能把这些不同轮次合并成一次成功充值。
先查密钥额度，不要直接补钱
这份报告不是 Google 的产品公告，也不能说明普通 Gemini 会主动操作你的钱包。实验使用的是能读文件、调整任务和修改自身运行配置的代理框架。对准备运行类似工具的人，重点是它究竟能碰到哪些文件和账户。
OpenRouter 的限额文档区分了账户余额、单个密钥的信用额度限制和其他预算约束。limit_remaining 表示该密钥自身剩余的额度，不等于账户全部余额。看到额度将尽就充值，可能没有解决真正拦住请求的限制。
用当前密钥认证，发送 GET https://openrouter.ai/api/v1/key，检查 effective_budget.remaining_usd；effective_budget 为 null 时，表示没有适用的该类预算约束，不代表账户余额无限。文档建议长任务开始前检查预算；密钥额度用完时，可由管理员提高限制，或在设置了重置周期的情况下等待重置。这里的管理操作，不必交给执行任务的代理。
把停机规则放在钱包权限之前
ToolAI 的判断是，消费上限与资产隔离要分别设置。限额能约束这把密钥的消费，却不能代替文件权限；即使某轮模型选择不动资金，也不意味着把恢复短语留在可读目录是安全设计。
如果只需要按时处理任务，优先使用权限固定的调度流程，不必开放代理修改自身唤醒方式和运行配置的能力。确实要研究自修改代理，则应使用隔离环境与不承载真实资产的测试材料，把充值、提高额度和新增付款渠道留给人审核。
报告中，Gemini 在预算吃紧后把工作转交给已连接的 Claude Opus 5.5，没有动用钱包。一把密钥耗尽，不等于整个系统停止使用其他已授权资源。下次运行前，检查代理可读目录中的钱包凭据，并把其他模型提供商连接和任务交接权限纳入低预算停机测试：额度耗尽后，是停止并通知管理员，还是换条路径继续运行？别用真实资产检验模型会不会自觉克制。