[Feature]

[wnfilm]

想要什么功能 / What feature?

想反馈一个 quota / usage 消耗异常的问题，麻烦作者帮忙看一下。

我这边不确定根因在哪里，但从运维观察来看感觉不太正常：我们现在有 10 个 Windsurf Trial 账号，正常理解不应该这么快就接近限流或额度低水位。

目前看到几个现象：

1. 账号池状态正常

10 个 active Trial 账号
账号 error: 0
blockedModels: 0

Dashboard 里看到的剩余额度大概是：

daily remaining: 57% - 72%
weekly remaining: 77% - 85%

2. 最近 4 小时请求量和 usage 统计

usage_lines: 1085
fresh_input: 1,039,666
output: 1,112,100
cache_read: 12,651,008
cache_write: 3,534,719
cache_total: 16,185,727
all_total: 18,337,493

可以看到真正的 fresh input 并不是特别夸张，主要消耗集中在 cache_read 和 cache_write。

3. 日志里有很多类似：

in=415 out=251 cache_r=11217 cache_w=683
in=415 out=211 cache_r=63065 cache_w=435
in=415 out=110 cache_r=64425 cache_w=835

这说明缓存应该是生效的，fresh input 只有几百 token，但 cache_read 每次可能有几万 token。

4. 目前 usage 返回口径似乎是：

promptTotal = inputTokens + cacheReadTokens + cacheWriteTokens

然后返回：

prompt_tokens = promptTotal
input_tokens = promptTotal
total_tokens = promptTotal + outputTokens

这样会导致下游中转或计费系统把 cache_read / cache_write 也按普通 input token 统计，额度显示会消耗很快。

5. 我们更担心的是上游 Windsurf 官方是否也在类似地统计 cache_read / cache_write。

我们知道下游 usage 字段不会反向影响上游扣费，但如果上游本身也把 cache_read / cache_write 按较高权重计入 quota，那长上下文会话即使缓存命中，也会消耗得非常快。

目前我们不专业，不确定到底是哪一层的问题：

• 是 usage 返回口径问题？
• 是 Dashboard 展示问题？
• 是 cache_read / cache_write 本来就会被上游按额度扣？
• 是 policy_blocked / rate_limited 请求也消耗了额度？
• 还是 cascade reuse / generatorOffset 仍然存在某些重复统计？

但从现象看，10 个 Trial 账号不应该这么快出现明显限流/额度压力，所以想请作者帮忙确认一下。

建议是否可以增加一些诊断能力：

1. Dashboard 单独展示：

   • fresh_input
   • cache_read
   • cache_write
   • output
   • policy_blocked count
   • rate_limited count

2. 增加“请求前后官方 quota 变化”对比：

   • request before: daily/weekly remaining
   • request after: daily/weekly remaining
   • 本次 usage: fresh_input / cache_read / cache_write / output

3. 明确区分下游 usage 和上游真实 quota：

   • downstream reported usage
   • upstream reported usage
   • upstream quota delta

4. 对 policy_blocked 请求确认是否会消耗 quota，如果会，Dashboard 里最好单独显示。

5. usage 返回可以保留 cache 细节，不要只合并成 input_tokens：

   • fresh_input_tokens
   • cache_read_tokens
   • cache_write_tokens
   • output_tokens

6. 可选增加计费口径配置：

   • standard: cache_read/cache_write 包含在 prompt_tokens
   • fresh_only: input_tokens 只统计 fresh input
   • weighted: cache_read/cache_write 按折扣权重统计

核心问题不是缓存完全没生效，而是目前看起来 cache_read / cache_write 非常大，且可能被合并统计或真实计入 quota，导致长上下文请求消耗异常快。

麻烦作者帮忙确认一下：WindsurfAPI 当前 usage/cache 统计和 upstream quota 消耗之间是否存在口径问题，或者是否有重复统计 / 高估消耗的可能。

替代方案 / Alternatives considered

No response

是否愿意提 PR / Willing to submit a PR?

• 我想自己实现 / I'd like to implement this myself

[0a00]

很奇怪，我使用的是目前的最新版本，31个 Trial pro 账号，一共调用了200多次成功，现在调用任何模型都提示，账号队列超时: 所有可用账号暂时不可用

[wnfilm]

五个号加一个 ip 就可以了

[0a00]

五个号加一个 ip 就可以了

兄好，这个只是因为我一个ip用了30多个账号的问题么，一共成功请求了200多次，所有号，额度都是100% ，我刚换了一个ip ， 还是这样

[0a00]

v2.0.79 audit M-1 修了 sticky 检测漏 bright-data / oxylabs。

老的 STICKY_USER_RE 只看 username 里有没有 _sid_ / -session- / +ws_ 这种显式 session token。但 bright-data 和 oxylabs 的某些 plan 不在 username 里塞 session token，username 长这样：

brd-customer-hl_abc123-zone-residential
customer-myuser-cc-US-country-US

老 regex miss → 多个账号共享同一 LS 实例 + 同一 sessionId → 上游按 fingerprint 算限流即使 egress IP 不同也撞 30 分钟。这正是你和 0a00 报的现象。

新 regex 加 ^brd-customer- / customer-...-(cc|zone|country|state|city)- / -zone-XX / -cc-XX 这些已知模式。bare static-IP username 仍不分桶（避免内存爆）。

升级 docker compose pull && docker compose up -d --force-recreate 后多账号应该不再共享 LS 实例。

0a00 那条 31 号 200 次后队列超时是另一回事 — docker logs windsurfapi-windsurf-api-1 --tail 300 | grep -E "cooldown|rate_limit" 看每个 account 的 cooldown 状态贴一下我看根因。

[WARN] Account c6b80dae (iren.a.z.e.l.a.y.a.8.67@gmail.com) rate-limited on claude-opus-4-7-max for 29 min
[WARN] Account iren.a.z.e.l.a.y.a.8.67@gmail.com failed (rate_limit) on claude-opus-4-7-max, trying next
[WARN] Cascade error step {errorText=Reached message rate limit for this model. Please try again later. Resets in: 26m4s (trace ID: a08097c0ad5d684f026f8e8692fc7b98) trail=[{"type":34,"status":3,"textLen":0,"tools":""},{"type":14,"status":3,"textLen":0,"tools":""},{"type":17,"status":3,"textLen":0,"tools":""}]}
[WARN] Account 84ed692b (ir.e.n.a.z.e.laya867@gmail.com) rate-limited on claude-opus-4-7-max for 26 min
[WARN] Account ir.e.n.a.z.e.laya867@gmail.com failed (rate_limit) on claude-opus-4-7-max, trying next
[ERROR] Stream error after retries: Reached message rate limit for this model. Please try again later. Resets in: 26m4s (trace ID: a08097c0ad5d684f026f8e8692fc7b98)
[ERROR] Stream error after retries: claude-opus-4-7-max 账号队列超时: 所有可用账号暂时不可用，请 1484 秒后重试

全是这样

[dwgx]

v2.0.79 修了 sticky 检测漏 bright-data/oxylabs v2.0.84 加 fallback hint 你那 quota 100% 撞的是滑窗 rate limit 不是 quota max/xhigh 限频严 改 claude-sonnet-4.6 稳