单账号AI接口安全阀：Windows-Copilot-API令牌桶限流与请求串行化完整指南

Windows-Copilot-API 把 Windows Copilot 逆向成了免 API Key 的 OpenAI 兼容接口，让你无需账单即可调用 GPT-4 / GPT-5。但"免费"不等于"随便造"——它桥接的是一个登录账号，上游 Copilot 既不容忍并发会话、也不公布任何速率限制。本文带你拆解该项目如何靠令牌桶限流（Token Bucket）+ 请求串行化两道闸门，把单账号桥接服务变成一块可靠的安全阀。

为什么单账号需要"限流"这道安全阀 🛡️

微软没有为消费级 Copilot 公布速率限制，但实测中单个账号在约15 req/min以上就开始出现上游502拒绝。同时，Copilot 的聊天 socket 无法承受同一进程内的并发对话——并行请求要么报错要么挂起。

因此服务层设计了两个正交的阀门：

一个是"流量预算"，一个是"单车道放行"，配合起来才能把压力挡在账号的承受范围内。

令牌桶：给请求发"预算" 💰

server/ratelimit.py 中的TokenBucket是经典的令牌桶实现，逻辑非常直观：

• 桶容量为burst（默认 4），初始装满；
• 按rpm / 60的速度持续回充令牌，上限不超容量；
• 每个请求消耗1 个令牌，桶里有就放行；
• 桶空了立即拒绝，并算出还差多久攒够 1 个令牌，作为Retry-After秒数返回。

try_acquire()是非阻塞且线程安全的（内部持threading.Lock），所以高并发下计数不会乱。效果是：短时突发最多吸收burst个请求，长期均值被压在rpm——就像水龙头漏水，桶能兜住一阵急流，但兜不住持续猛灌。

请求串行化：并发排队，一个一个来 🔒

server/api.py 里有一把全局_upstream_lock：所有上游 Copilot 调用都在with _upstream_lock中执行，并发的 HTTP 请求会在锁后排队、逐个运行。

压测数据印证了这套设计（见 README.md 的 Concurrency & stress test 一节，工具为 tests/stress.py）：

特征是"墙钟时间逐轮翻倍、最小延迟不变"——典型的串行队列签名：一个请求立刻跑，其余排队等位。结论很明确：并发在途请求保持 1–4 个，这就是一座个人桥的合理水位。

一个巧妙的细节：限流检查发生在抢锁之前（server/api.py）。超额调用者会先收到快速 429，而不是在串行队列里白白堆积，避免了"队列越长、体验越差"的恶性循环。

看懂两种拒绝：429 还是 502？ 🚦

收到失败响应时，先分清是谁在拒绝你：

429响应体是标准 OpenAI 错误格式（type: "rate_limit_error"），客户端做指数退避（1s → 2s → 4s）基本都能恢复；官方openaiSDK 会自动遵循Retry-After，裸 HTTP 调用则需要自己加重试。

调参指南：两个环境变量就够 ⚙️

限流参数集中在 server/config.py，通过环境变量覆盖：

RATE_LIMIT_RPM=20 RATE_LIMIT_BURST=5 python app.py # 提高上限；RPM 设 0 表示关闭限流

默认 12 rpm 特意压在实测崩溃点（~15 rpm）之下，确保限流器先于上游"出手"。想探测自己账号的真实上限，可以关掉限流后用内置探针 tests/ratelimit.py 按真实墙钟速率压测——它会清晰区分 429（桥限流，说明阀门在工作）与 502（上游拒绝，说明该收手了）：

python tests/ratelimit.py --rpm 20 --minutes 3

写在最后

Windows-Copilot-API 的安全阀设计给个人开发者提供了一个可复用的范式：面对不公布限制的上游，先测出它的承受边界，再用令牌桶守住均值、用互斥锁守住并发，最后把拒绝标准化成 429 + Retry-After。三道工序各司其职，才能让"单账号免费用 GPT-4"这件事长期、稳定、不被封号地跑下去。🎯