月跑27.6万次Agent请求只花430美元：LeanStack的工程实践

当"我用零成本跑Agent"的帖子满天飞时，通常有两种情况：要么流量少得可怜，要么真实成本藏在了别处。LeanStack团队把他们2026年9月15日到10月15日的完整网关日志摊开，给出了一个不删减的答案。

一个月的真实数据

一个月内，LeanStack的66个定时Agent任务产生了276,814次模型请求，消耗了99亿输入token和3.85亿输出token。其中72亿输入token来自缓存命中，占比约73%。总账单是430美元的固定订阅费，按token计费的API支出为零。

这个数字建立在特定的架构选择之上。没有架构，430美元跑不出这个量。

核心架构：一个网关，多条路由

整个方案最关键的决定，是在所有Agent和所有模型供应商之间放了一个本地网关。每个Agent、脚本和编码工具都只跟这一个本地端点通信，由网关决定请求的实际去向。

这个设计带来四个难以替代的好处。所有请求写入同一份日志，包含供应商、模型、状态码、耗时和token用量（含缓存token）。路由策略集中在一处，把工作负载从付费路由切到免费路由只需改一行配置。当某条路由被限流或失败时，网关可以自动尝试备选。多个路由运行在固定费率套餐登录态上，而非按量计费的API密钥——这就是每token成本为零的来源。

LeanStack的核心建议是：在优化任何东西之前，先给Agent放一个网关。看不见的账单没法优化。

什么是路由（Route）？ 在这类网关架构中，路由是一组（供应商 + 认证方式 + 模型）的绑定配置。例如「通过固定套餐登录态调用 Claude Sonnet」是一条路由，「通过 OpenRouter 免费 SKU 调用某个预览模型」是另一条。网关在收到请求后，按预设的优先级、任务类型或权重选择一条路由发出，并把结果回写给调用方。路由的价值在于把「用哪个模型、走哪条计费通道」这个决策从每个 Agent 内部剥离出来，集中管理。正因为路由是一等抽象，切换成本降到一行配置——把后台任务的默认路由从付费 API 改成固定套餐或免费层，不需要改动任何 Agent 代码。同时，当某条路由返回 429 或 5xx 时，网关可以按策略顺延到备选路由，而不是让调用方直接失败。

按任务分层路由

不是每个Agent步骤都需要前沿模型。LeanStack的粗略规则是：重量级推理和编码走固定套餐上最强的模型；后台和定时任务走免费或廉价路由；实验性任务走预览版和免费SKU，并接受它们的不稳定。

按计费类型看，输入token的分布如下：固定订阅登录态（Claude、xAI、Cursor、ChatGPT、Google Antigravity）承载约78%；一个10美元/月的编码套餐承载约11%；免费模型层（OpenRouter免费及预览SKU、NVIDIA免费层、本地免费路由）承载约10%；Google API密钥承载约2%。

按供应商看，请求量和token量呈现出明显的错位。OpenRouter的两条路由合计超过11.5万次请求，但token占比很小；而Anthropic和xAI各承载了约30亿输入token，请求量却只有2-3万次。免费层吸收请求量，固定套餐吸收上下文深度——这正是分层路由的意义。

缓存贡献了73%的输入token

99亿输入token中有72亿是缓存读取，约73%。Agent在几乎每次调用时都会重发相同的系统提示词、工具定义和对话历史。只要供应商和客户端支持prompt caching，一个稳定的提示词前缀就是最便宜的优化手段。

具体做法：把系统提示词和工具schema放在最前面并且不要重排，把时间戳、运行ID等变化内容放在末尾；长运行Agent尽量复用对话而不是重新开始；按路由监控缓存token数，有些路由日志显示零缓存，可能是没有上报也可能是没生效——只有网关日志能告诉你答案。

Prompt Caching（提示词缓存） 是主流模型供应商提供的一种计费机制：如果两次请求的开头部分（前缀）完全一致，供应商可以复用上次已计算的 KV 缓存，只对新增部分做完整计算，并对命中的缓存 token 收取远低于普通输入 token 的费用，部分供应商的缓存读取价格可低至普通输入的十分之一。命中条件通常要求前缀逐字节相同且顺序稳定，一旦在开头插入时间戳或重排工具定义，后续所有 token 都无法命中。这就是为什么文章强调「把变化内容放在末尾」。缓存命中率会直接体现在账单上：99 亿输入 token 里有 72 亿是缓存读取，按普通输入价计费会贵出一个数量级。需要注意不同供应商对缓存 TTL、最小前缀长度和上报字段的定义不一，这也是「有些路由日志显示零缓存」的可能原因。

实际账单构成

每月固定支出：Claude套餐200美元，Cursor套餐200美元，ChatGPT套餐20美元，编码套餐10美元，合计430美元。按token计费的API支出为零。

这个方案成立的前提是固定套餐允许在限额内大量使用。限额是真实存在的，这也是它不适用于所有人的原因。

免费路由的表现最能说明问题。27.6万次请求中有71,953次未成功返回，包括22,111次HTTP 429限流。其余包括模型更名或退役导致的404、上游5xx错误、请求错误和客户端断连。部分免费路由的成功率远低于一半。

护栏与失败处理

固定套餐的风险不是意外账单，而是额度耗尽或任务中途被限流。如果混入了按量计费的密钥，风险则变成夜间失控的循环调用。无论哪种情况，护栏是一样的：每个Agent设置每日预算（请求数或token数），触发后硬停止而非仅告警；限制每个Agent可用的路由，后台任务不应能自行升级到最贵的模型；不要把按量计费密钥作为静默兜底——免费路由失败时回退到另一个免费或固定路由，或者直接大声失败，绝不要悄悄溢出到按量计费。

失败带来的经验也很直接：免费层的不可靠是设计使然，从第一天就要为重试和回退做预算，不要把任何面向用户的东西放在单条免费路由上；模型名称频繁变动，预览版和隐身模型随时出现和消失，需要定期审查路由表；限流决定一切，把负载分散到多条路由和供应商是高频方案能活下去的关键；没有逐请求的状态日志，四分之一的失败只会被感知为"Agent有点不稳定"。

为什么按量计费密钥作为兜底最危险？ 固定套餐的风险是有上限的——额度耗尽就停止。而按量计费密钥的风险是无上限的：一旦 Agent 陷入循环、误判任务完成条件，或在夜间无人值守时反复重试，账单会随调用次数线性膨胀，且没有任何硬性刹车。更隐蔽的是，当免费路由因为限流或 404 失败时，如果框架默认「回退到任意可用路由」，就会静默地把流量倾倒到按量计费通道，表面上一切正常，直到月底账单出现。正确做法是让回退目标限定在同类免费或固定套餐路由内，找不到就显式抛出错误，让失败可见。同时每个 Agent 应设置基于请求数或 token 数的每日硬预算，触发后直接终止该 Agent 而非只发告警，因为告警在无人值守时段形同虚设。

什么场景不适合这套方案

月调用量只有几百次时，按量付费几乎肯定比430美元的套餐更便宜。面向客户的生产工作负载不该用套餐登录态和免费层，它们有服务条款限制、速率限制且没有SLA。需要数据处理协议、审计追踪或共享账单的团队也不适用，个人套餐就是个人的。最后，不想做持续维护的人也不适合——路由表、退役模型、额度调度和回退策略都需要长期关注。

LeanStack团队正在把这套方案整理成一份29美元的playbook，目前还在测试需求阶段。他们强调所有数字都来自网关日志，没有估算。

为什么面向客户的生产负载不能用个人套餐？ 个人版订阅（如 Claude Pro、ChatGPT Plus）的服务条款通常限定为个人交互式使用，不支持程序化批量调用、转售或作为产品后端。把这套登录态接入面向客户的产品，除了条款风险，还面临速率限制、无 SLA、无审计追踪、无数据处理协议等问题。此外，套餐额度是按账号共享的，一旦被自动化负载打满，开发者自己的日常使用也会被波及。因此这套方案的合理解释是「个人或小团队的内部工具链成本优化」，而不是通用的生产部署范本。需要合规、可审计或多方共享账单的团队，应该走企业合同和按量计费 API 路线。