跑在生产环境里的AI代理团队，几乎都怕同一件事：一次循环、一场重试风暴，或者一个写错的max_tokens，最先知道的是API账单。常规做法是在自己的代码里放一个计数器，可计数器活在代理自己的进程里，进程一崩、一重启，或者多开一个并行worker，上限就没了。

有人干脆把这个上限搬到了代理外面。他做了个叫Valta（valta.co）的代理服务，卡在代理和OpenAI之间。代理手里拿的是一把虚拟密钥，永远碰不到真实密钥。每一次调用在发出去之前，都要先过一遍按单次运行、按天、按月设置的三层限额；超了就直接拒绝，请求根本不会到达服务商。如果Valta自己判断不了，它也拒绝——用他的说法，这叫失败即关闭。

他相信这道闸门守得住。现在他想找真正懂代理怎么失败的人来证明他错了。

挑战规则：把单次运行的总花费推过0.06美元

可用的手段不限：重试、循环、扇出、并行请求、和限额赛跑、超大的max_tokens、奇怪的输入，凡是能通过API做到的都算。

参与不花钱，不需要OpenAI密钥，也不用绑卡。用模型valta-sandbox即可，返回内容是模拟的，但每一个请求都会走真实的闸门和真实的账本。

配置大约三分钟：

  • 在valta.co免费注册
  • 打开你的代理，启用Cap，把单次运行上限设为0.06美元
  • 创建一把虚拟密钥（vk_live_...）
  • 把任意兼容OpenAI的客户端指向https://valta.co/v1，带上这把密钥，模型填valta-sandbox
  • 每次请求带上X-Valta-Run-Id请求头，同一次运行内保持同一个值

奖励与时间

最佳攻破方案可获得一年免费的Builder套餐，最有创意的尝试还会被公开点名。失败的尝试同样算数，他说自己一样想读。他会把大家试过的东西公开出来。活动持续两周，目前只支持非流式请求。

试过之后如果闸门守住了，可以告诉他下一步该攻哪里；如果被攻破了，他会修，并记上你的名字。他的说法是，不管哪种结果，你都会比今天更懂代理的花费控制是怎么失效的。