openclash 低成本api

很多人是先在路由器上跑 OpenClash，把家里和办公室的网络出口统一了，才回头想接 API 中转。这时候卡点通常有三个：不知道中转的计费口径跟自己算的对不对得上；预付、按量、订阅混在一起比不出高低；月底账单一来发现比预估多了一截，又不知道从哪儿查。这篇给一套判断标准和一份可执行的核对顺序，数字都让你去站内对应页面看当期值，不替你背。

很多人是先在路由器上跑 OpenClash，把家里和办公室的网络出口统一了，才回头想接 API 中转。这时候卡点通常有三个：不知道中转的计费口径跟自己算的对不对得上；预付、按量、订阅混在一起比不出高低；月底账单一来发现比预估多了一截，又不知道从哪儿查。

这篇给一套判断标准和一份可执行的核对顺序。OpenClash 本身只负责把出口统一，它不产生任何调用费用，所以成本问题一律回到你接的那家中转身上。所有具体数字都不在这里写死，你去站内对应页面看当期值，按你的实际用量自己算。

先定义清楚：OpenClash 场景下的「低成本」到底指什么

别一上来就翻单价表。低价和低总成本是两件事，中间隔着结算方式、余额规则和你的调用结构。先把「单价」和「结算方式」拆开看，再决定哪家值得试。

计价方向

按输入计费还是按输出计费，还是两者分开算，这决定了长上下文任务贵不贵

缓存命中价

同样的输入，命中缓存和未命中是不是两个价，差价有多大

倍率

中转在基础价上乘的系数，有的按模型分档，有的全局统一

门槛与有效期

有没有月最低消费、最低充值额，余额会不会过期作废

• 先去站内工具页把手上模型的单价换算成「一次典型调用多少钱」，拿这个数去比中转，比直接对单价表清楚得多
• 四个变量缺一项就没法横向比：计费方向、缓存价、倍率、门槛与有效期
• 量小的时候别纠结单价，先看最低充值门槛和余额有效期，这两项更容易让你白花钱
• 同一家的不同套餐可能倍率不同，比价时要确认你实际会走的那一档

三类计费方式摆一起看：预付、按量、订阅谁更适合你

三类没有绝对优劣，关键看你的最坏情况。对照方式很朴素：把上个月的调用记录拿出来，分别按三种模式算一遍总额，再看哪种在你「脚本跑飞那天」损失最小。具体单价一律到站内官方 API 价格页和中转站目录核对当时的数字，别照抄别人文章里的旧值。

团队多人共用同一个 Key 时，按量后付很难分摊到人。这种情况要么走订阅按人头分，要么先在自己这边做一层用量日志，否则月底谁也说不清是谁跑出来的。

降本的四个可执行动作（按见效快慢排序）

1. 按任务分级选模型把「必须用贵模型」和「随便一个便宜的就行」的任务分开，后者换掉能立刻见效。换之前先用站内成本换算工具算一遍同一任务的成本差，别凭感觉换。
2. 控制上下文长度长对话和长文档是成本增长最快的入口，历史全量带上等于每轮都在为旧内容付费。做法是定期裁剪历史，或改成摘要后带入，而不是每轮重发全文。
3. 给重试加硬上限脚本里没有重试上限是最常见的隐性浪费。超时、限速、格式错误各自重试几次要写死，连续失败就停并告警，别让它自己循环。
4. 设置预算告警在充值后台或调度脚本里设定日或周阈值，超了就降级或暂停。阈值参考往期用量均值再留一档余量，别等到月底才发现。

# 重试要有上限的示意结构，别照抄，按你脚本改写
retries=0
while [ $retries -lt 3 ]; do
  call_api && break
  retries=$((retries+1))
  sleep 2
done
[ $retries -ge 3 ] && echo "连续失败，停止并告警"

如果总调用量本来就很小，花半天做分级和裁剪省下来的钱可能还抵不上时间成本。这种情况优先做第四步就够，其他留到量涨上来再说。

月度核对：让每一笔扣费都能对上

顺序很重要：先导出平台侧账单明细，再导出自己这边的调用日志，两边按日期和调用量对齐，最后才去看差额落在哪一类。反着做容易被单个异常值带偏，越查越乱。

• 自己这边的日志至少记四个字段：时间、模型名、输入输出量、是否命中缓存
• 差额先分类再追问：缓存口径、倍率与汇率、重试导致的重复请求，三类分开查
• 长期稳定在某个比例的差额，通常是口径差异不是异常，记下来带进下月预估
• 具体怎么从用量倒推预估，照站内成本估算那篇的流程走一遍就行

如果差额忽大忽小、没有规律，先怀疑调用侧的重复请求和失败重试，而不是先去质疑平台。把日志按小时切开看，异常通常集中在某一小段时间里。