Coding Plan售罄：按量API、本地模型与网关替代方案

从去年下半年开始，我身边做开发的朋友几乎每个月都要问一遍同一个问题：那家大模型平台的编程订阅套餐还能不能买到。轻量版直接下线了，专业版开放名额后几分钟内就被清空，连按次计费的档位都挂着"售罄"两个字。有人定了闹钟蹲点，有人开了十几个浏览器标签同时刷新，还有人干脆去二手渠道加价收，结果发现账号绑定和权益继承又是一堆麻烦事。这篇文章不打算讨论任何抢购技巧，因为抢购本身解决不了根本问题——你真正缺的不是某个特定平台的额度，而是一套在额度断供时依然能跑通工作流的方案。

我把过去大半年在团队里折腾过的几套替代路线完整拆一遍：为什么这类套餐会反复售罄、停售背后的成本账怎么算、按量付费 API 和订阅包到底差多少钱、本地开源模型在什么情况下才值得上、编辑器里的配置怎么改才能随时切换供应商。整篇围绕Coding Plan的供应紧张展开，涉及Lite 停售与Pro 缺货的具体应对，也给出可以直接抄走的配置和测算表。不管你是刚入行想省钱的个人开发者，还是团队里负责采购和工具链的人，都能从里面找到能落地的部分。

1. 抢不到套餐这件事，本质是供需错配

1.1 三档套餐的定位差异，决定了谁先消失

很多人把订阅套餐当成"无限量自助餐"，这是个根本性的误解。编程订阅套餐的定价模型通常是按月收一个固定费用，然后给一个相对模糊的"高频使用权"，同时在后台用并发数、每分钟请求数、每日上限这些软硬限制兜底。这种产品设计的初衷是覆盖典型的交互式编程场景——补全、解释代码、改一个小函数、写一段注释。

问题在于，过去一年里使用方式发生了剧烈变化。Agent 类工具开始大规模普及，一个任务动辄七八轮甚至几十轮往返，每一轮都要把整个项目上下文重新塞进去。有人统计过，同样写一个功能，用聊天窗口问三次消耗的 token，可能还不到 Agent 自动跑一轮的十分之一。当一批用户把原本给交互式场景设计的额度拿来跑自动化任务时，后端的算力消耗曲线会瞬间抬起来。

轻量版最先扛不住，原因很直接：它的定价最低，但用户拿到的并发和请求额度相对其付费额是偏高的，属于典型的"高占用低成本"档位。平台每卖出一份轻量版，单位算力收入是覆盖不了 Agent 工作流带来的消耗的。与其涨价得罪用户，不如直接停售，这是商业上最省事的处理方式。专业版还有空间，因为定价足够高，能覆盖一部分重负载用户，但它同样会遇到总量控制的问题，所以才出现了"开放名额即清空"的现象。至于按次计费的那一档，售罄更像是容量调配的结果——平台需要把有限的推理资源优先保障给高价值客户和稳定付费的企业账户。

把这个逻辑想清楚之后你会发现，等它补货意义不大。就算你今天抢到了专业版，下个月是否续订、权益是否会调整、额度口径会不会变，全都不确定。工具链建立在别人的库存状态上，本身就是脆弱架构。

1.2 挤兑为什么会周期性出现

供应紧张不是随机事件，它跟几个可预测的因素强相关。

第一个因素是版本发布节奏。每当有新的模型版本上线，或者某个热门编辑器插件更新了大版本，短时间内涌入的新用户会把并发池打满。我观察到好几次"突然抢不到"的时间点，往前推一周基本都能找到对应的产品动作。

第二个因素是工作日的时间分布。上午十点到下午四点是用量高峰，这个时段限流报错的比例明显高于深夜。如果你的工作流允许错峰，把大批量任务挪到晚上跑，成功率会好不少。

第三个因素是账户等级。新注册账户的初始并发限额通常很低，很多人在评估阶段就撞上限流，误以为平台的额度不够用，实际上是自己的账户还没积累使用记录。这类限制一般在持续使用一段时间、完成实名或企业认证之后会逐步放开。

注意：不要相信任何非官方渠道的"内部名额""加价转让"。这类交易在服务条款层面基本都不受保护，账号权益跟实名主体绑定，转手之后大概率是钱货两空。

1.3 把需求拆成可量化指标，才能对症下药

在找替代方案之前，先老老实实算清楚自己一个月到底消耗多少。我的做法是拿一周的真实使用记录做样本，按下面几个维度统计：

这套统计跑一周就有结论了。我团队里的实测结果是：纯补全类请求的输入 token 均值只有 600-900，因为补全只会带当前文件和少量相邻上下文；而 Agent 类任务的输入均值能到 5000-20000，因为要把历史对话、工具返回结果、相关文件全部带上。这两类负载的成本差了将近一个数量级，用同一个套餐额度去覆盖，必然有一类会被另一类挤死。

2. 替代方案全景：六条路线怎么选

2.1 路线一：按量付费 API 直连，最稳妥的兜底

订阅套餐缺货的时候，按量付费的 API 几乎永远在线，因为它不存在"库存"概念，用多少付多少。这条路线的优点是确定性极高：没有并发抢购，没有名额限制，价格透明，账单可预测性反而比订阅制更好——你完全知道自己这个月花在哪了。

具体做法是拿一个 OpenAI 兼容协议的客户端，把 base_url 和 api_key 指到目标平台就行。绝大多数主流编辑器和插件都支持自定义端点，改动量通常在三个配置项以内。

export OPENAI_BASE_URL="https://your-endpoint.example.com/v1" export OPENAI_API_KEY="sk-your-key-here"

需要提醒的是，不同平台对 OpenAI 协议的兼容程度不一样。有的平台只实现了/v1/chat/completions，没实现/v1/completions，如果你的插件用后者做补全就会 404；有的平台支持stream但流式返回的字段格式略有差异，导致客户端解析失败；还有的平台对max_tokens有上限约束，传超了直接报参数错误。这些坑在第一次接入时基本都会遇到，后面第 5 节会整理成速查表。

我个人更推荐把按量付费当作底座，而不是临时救急。原因是它的成本结构跟使用量线性相关，你把优化做好，账单就下来了；订阅制则是固定成本，用少了浪费，用多了被限流。对于使用量波动大的独立开发者，按量付费几乎总是更划算。

2.2 路线二：多平台组合，把鸡蛋分开放

只依赖一家供应商，无论它是订阅还是按量，都还是在赌它的稳定性。我现在的做法是同时接两到三家，主用一家、备用一家、兜底一家。

分层的逻辑不是随便排列，而是按任务价值分配。高价值的复杂任务——架构设计、跨文件重构、疑难 bug 定位——用能力最强的那一档；日常补全和注释生成这种高频低价值请求，用便宜甚至免费的小模型，延迟还更低；中间那一档放常规的代码解释和单文件修改。

这种分层的关键是要有一个统一的入口。如果在编辑器里手动切换供应商，一天切十几次，很快就烦了。正确做法是在本地跑一个轻量网关，客户端永远只连网关，网关根据请求特征决定转发到哪家。这个话题在 4.2 节会详细展开。

选备用供应商的时候有几个容易被忽略的点。第一是模型能力要大致对齐，如果你的主力和备用模型在代码能力上差一代，切换之后输出质量会断崖式下降，等于没有备份。第二是接口形态要一致，最好都支持 OpenAI 兼容协议，否则网关里要写两套适配逻辑。第三是计费方式要能接受，有些平台要求预充值才能用，有些按自然月结算，混着用会让财务处理变麻烦。

2.3 路线三：本地开源模型，什么情况下才值得上

这两年开源模型的代码能力进步很大，但"能在本地跑"和"能在本地跑得比云端好用"完全是两件事。我不建议一上来就折腾本地部署，除非你满足下面至少两个条件：一是对代码外发有硬性合规要求，代码不能出内网；二是使用量足够大，大到云端账单已经明显超过硬件折旧；三是有闲置的显卡资源，边际成本接近零。

显存需求是最先要算清楚的。粗略的估算方式是：模型参数量乘以每参数字节数，再加上 KV cache 和框架开销。

表里的数字只是权重占用，实际还要往上加。KV cache 的显存跟上下文长度成正比，一条 32K 的上下文在 32B 模型上能吃掉好几 GB。所以 24GB 显存的消费级卡跑 32B 的 INT4 模型，短上下文没问题，长上下文会直接 OOM。

吞吐方面要有心理准备。单张消费级卡跑 7B 模型，生成速度大概在每秒几十个 token，看着还行，但前提是只有你一个人在用，且 batch size 为 1。一旦并发上来，每个请求的延迟会成倍增加。做代码补全这种要求毫秒级响应的场景，本地小模型勉强能接受；做 Agent 这种需要长链条推理的场景，本地 7B 模型基本不可用，因为它的指令遵循和工具调用能力还撑不住多轮任务。

说白了，本地部署最适合的场景是"代码补全 + 简单的代码解释"，也就是那些对智能程度要求不高、但对延迟和隐私要求很高的请求。真正复杂的任务还是得走云端。

2.4 路线四：在编辑器插件层做抽象

这一层经常被忽略，但它其实是整个方案里最容易落地的一环。主流编辑器生态里有不少插件支持配置多个模型供应商，并且允许你用不同的 profile 应对不同场景。配好之后，切换供应商只是点一下下拉菜单的事。

我的配置思路是建三套 profile：一套默认连主力按量 API，一套连备用平台，一套连本地服务。补全功能绑定到本地或便宜的云端小模型，聊天和 Agent 绑定到主力模型。这样即使主力平台临时不可用，补全功能完全不受影响，你还能继续写代码，只是复杂任务暂时做不了。

这套方案的局限在于，它只解决了"手动切换"的问题，解决不了"自动容灾"的问题。如果主力平台在你提交任务之后才挂掉，插件不会自动重试到备用。要做到自动容灾，还是得靠网关。

3. 成本核算：订阅换按量到底贵多少

3.1 测算模型的参数说明

很多人在订阅断供之后第一反应是"按量付费太贵了用不起"，但这个判断往往是凭感觉。我拿真实数据算过几轮，结论跟直觉不太一样。

先明确计价口径。绝大多数平台的按量计费是输入输出分别定价，输出单价通常是输入的 2 到 4 倍。如果支持上下文缓存，命中缓存的部分会有大幅折扣，有的平台折扣能到一折。下面用的量级是：输入 4 元每百万 token，输出 12 元每百万 token，缓存命中按输入价的 20% 计。这个量级在当下的市场里属于中等偏下，实际各平台差异不小，具体以官方价目为准。

计算公式很简单：

单次请求成本 = 输入 token 数 × 输入单价 ÷ 1,000,000 + 输出 token 数 × 输出单价 ÷ 1,000,000

关键是 token 数从哪来。别估，去日志里拉。如果你的客户端没有日志，可以在网关层加一行记录，把usage字段落盘，跑三天就有样本了。

3.2 三种典型工作流的月成本对比

我拿团队里三种典型用法各跑了一周，按 22 个工作日折算成月成本。

第一种：纯补全型。一天 200 次补全，输入均值 800 token，输出均值 60 token。

单次成本 = 800 × 4 ÷ 1e6 + 60 × 12 ÷ 1e6 = 0.0032 + 0.00072 ≈ 0.0039 元

日成本 ≈ 0.78 元，月成本 ≈ 17 元。

第二种：对话问答型。一天 50 次对话，输入均值 3000 token，输出均值 800 token。

单次成本 = 3000 × 4 ÷ 1e6 + 800 × 12 ÷ 1e6 = 0.012 + 0.0096 ≈ 0.0216 元

日成本 ≈ 1.08 元，月成本 ≈ 24 元。

第三种：Agent 自动化型。一天 30 个任务，每个任务平均 8 轮，每轮输入 6000 token（含累积历史），输出 500 token。

单轮成本 = 6000 × 4 ÷ 1e6 + 500 × 12 ÷ 1e6 = 0.024 + 0.006 = 0.03 元

单任务成本 ≈ 0.24 元，日成本 ≈ 7.2 元，月成本 ≈ 158 元。

把三种加起来，一个重度使用者一个月大概 200 元出头。对比订阅套餐的定价区间，这个数字说明什么？说明对于纯补全和普通对话的用户，按量付费反而更便宜；只有 Agent 重度用户才会觉得贵。

还有一个隐藏变量：缓存。Agent 场景的输入里，系统提示词和项目上下文是高度重复的，如果平台支持自动前缀缓存，实际输入成本能砍掉一半以上。我在一个中型仓库上实测，缓存命中率稳定在 60% 左右，Agent 那部分月成本从 158 元降到了 90 元上下。

3.3 省钱的关键不在选平台，在改习惯

同样是用按量付费，不同人的账单能差三倍，差距主要来自几个使用习惯。

控制上下文长度。不要无脑把整个项目塞进去。让工具只带当前文件、直接依赖和被引用的类型定义，比全量扔进去省 80% 的输入 token，效果反而更好，因为无关文件会稀释注意力。

善用分层模型。补全和注释用最便宜的小模型，写复杂逻辑才切到大模型。很多编辑器插件支持按任务类型配置不同模型，配一次省一辈子。

批量任务错峰跑。有些平台在非高峰时段有折扣，或者你的自建队列可以在夜间跑批。把大批量重构、文档生成这类不着急的任务挪到晚上，账单能降一截。

及时清理会话。Agent 任务的上下文是累积的，跑到第十轮的时候输入里塞了九轮历史。如果前面的历史已经没用了，主动截断或者开新会话，成本立刻下来。

提示：算成本之前先看自己的实际分布。我见过有人为了省 Agent 的钱去买便宜模型，结果因为输出质量差反复重试，总成本反而更高。重试一次的代价是双倍 token 加双倍时间，这个账要算进去。

4. 实操：把编辑器接上按量付费 API

4.1 客户端配置的通用步骤

不管你用什么编辑器，接入自定义端点的流程基本是三步：填入端点地址和密钥、指定模型名称、跑一次连通性测试。

第一步，拿到端点和密钥。端点地址通常形如https://xxx.example.com/v1，注意结尾要不要带/v1，各平台不一样，带错了会 404。密钥一般是一串以固定前缀开头的字符，复制的时候注意别带上前后空格，这个坑我踩过不止一次，报错信息是 401 但密钥看起来完全正确，排查半小时才发现末尾多了个换行。

第二步，指定模型名称。这里的坑在于，模型名称必须跟平台文档里列出的完全一致，大小写、连字符、版本后缀都不能错。很多插件会提供一个下拉列表，但列表里的名字可能是插件内置的旧版本，跟你平台上的实际可用列表对不上。稳妥做法是调一次模型列表接口确认。

curl -s "https://your-endpoint.example.com/v1/models" \ -H "Authorization: Bearer $OPENAI_API_KEY" | head -c 2000

第三步，发一条最小的测试请求。

curl -s "https://your-endpoint.example.com/v1/chat/completions" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $OPENAI_API_KEY" \ -d '{ "model": "your-model-name", "messages": [{"role": "user", "content": "用一句话解释什么是二分查找"}], "max_tokens": 100 }'

返回里如果有choices[0].message.content且内容合理，说明链路通了。如果返回 200 但content是空的，大概率是max_tokens设太小被推理 token 吃光了，调大再试。

4.2 本地跑一个轻量网关做路由

网关的价值在于把"选哪家供应商"这个决策从人手里拿走。我写过一个两百行左右的版本，逻辑很简单：读配置里的供应商列表，按请求的上下文长度和类型打分，选一个发出去，失败自动重试下一个。

核心逻辑大概长这样：

import time from fastapi import FastAPI, Request from fastapi.responses import JSONResponse import httpx app = FastAPI() PROVIDERS = [ {"name": "main", "base": "https://a.example.com/v1", "key": "sk-a", "max_ctx": 128000, "weight": 3}, {"name": "backup","base": "https://b.example.com/v1", "key": "sk-b", "max_ctx": 32000, "weight": 2}, {"name": "local", "base": "http://127.0.0.1:8080/v1","key": "sk-local","max_ctx": 8000, "weight": 1}, ] def rough_tokens(messages): # 粗略估算：中文约 1.5 字符/token，英文约 4 字符/token total = 0 for m in messages: total += len(m.get("content", "")) / 1.7 return int(total) def pick(ctx_len): pool = [p for p in PROVIDERS if p["max_ctx"] >= ctx_len] pool.sort(key=lambda p: p["weight"], reverse=True) return pool or PROVIDERS[:1] @app.post("/v1/chat/completions") async def relay(req: Request): body = await req.json() ctx = rough_tokens(body.get("messages", [])) last_err = None for p in pick(ctx): try: async with httpx.AsyncClient(timeout=120) as client: r = await client.post( p["base"] + "/chat/completions", headers={"Authorization": f"Bearer {p['key']}", "Content-Type": "application/json"}, json=body, ) if r.status_code == 200: return JSONResponse(r.json()) last_err = f"{p['name']} -> {r.status_code}" if r.status_code in (429, 500, 502, 503, 504): continue # 可重试 return JSONResponse(r.json(), status_code=r.status_code) except Exception as e: last_err = f"{p['name']} -> {type(e).__name__}" continue return JSONResponse({"error": {"message": f"all providers failed: {last_err}"}}, status_code=503)

uvicorn gateway:app --host 127.0.0.1 --port 9000

然后把编辑器的端点指向http://127.0.0.1:9000/v1，密钥随便填一个非空字符串。这套东西的价值不在于代码本身，而在于它给了你一个统一的可观测点——所有请求都经过这里，日志、耗时、失败率、token 消耗全都落在一处。

有个细节要注意：429（限流）和5xx要重试，但400（参数错误）和401（鉴权失败）绝对不能重试，因为换个供应商还是同样的错，重试只会白白增加延迟。我在代码里显式区分了这两类，早期版本没区分，结果密钥配错的时候循环打了几十个请求，日志全被刷爆。

4.3 上线前的验证和压测

配置改完之后不要直接投入生产，先做几组验证。

连通性验证：发一条最短的请求，确认延迟在可接受范围内。跨地域调用的网络往返经常能到几百毫秒，这个延迟叠加到补全场景上体感很明显。补全的理想延迟是 300 毫秒以内，超过 800 毫秒就会打断编码节奏。

长上下文验证：故意发一个接近上限的请求，看会不会被拒。有些平台宣称支持 128K，但实际请求超过 32K 就报错，或者虽然接受了但输出质量崩掉。

并发验证：用脚本同时发 10 个请求，看成功率。个人账户的并发限制往往比想象中低，尤其是新注册的。如果失败率高，说明要么需要提额，要么得在网关层加排队。

成本验证：跑一天真实工作流，把网关日志里的 token 汇总一下，乘以单价，跟预期对比。如果差得远，回去检查是不是有异常长的上下文或者意外的重试风暴。

5. 常见问题与排查实录

5.1 报错速查表

5.2 我踩过的几个坑

坑一：把补全和对话配成同一个模型。早期图省事，所有功能都指向最贵的那个模型。结果补全请求虽然单次便宜，但频次极高，一天几千次，成本反超对话。后来把补全切到小模型，账单直接降了六成，而且补全延迟从 600 毫秒降到 180 毫秒，体验更好。这个教训是：高频低价值请求和低频高价值请求必须分开计价。

坑二：忽略重试风暴。网关刚上线那阵，主力供应商偶尔 503，重试逻辑写得粗糙，没有退避，结果一个失败请求瞬间放大成几十个，把备用供应商也打限流了。后来加了指数退避和熔断，同一个供应商连续失败三次就暂时摘除，冷却一分钟再放回来。

坑三：以为缓存会自动生效。有些平台的上下文缓存需要请求里带特定字段才会启用，默认是关的。我一开始没注意，跑了一个月全价输入，后来看文档才发现。启用之后同样的工作流输入成本降了一半多。具体怎么开启各家不一样，有的自动识别前缀，有的需要显式标记，接入前一定要翻一遍计费文档。

坑四：密钥写进了配置文件然后提交。这个不用多说，是老生常谈但依然高频。正确做法是环境变量或者本地密钥管理，配置文件里只留占位符，提交前跑一次密钥扫描。

坑五：本地模型的上下文窗口被高估。文档写支持 32K，实际跑 20K 就开始胡说八道，输出质量断崖下跌。这不是 bug，是量化之后长上下文的能力衰减。本地模型要按标称窗口的一半来用，留足余量。

6. 一套能长期用的组合，以及我的实际体会

折腾了大半年之后，我现在的稳定配置是这样的：本地跑一个量化后的中等规模模型专门做补全和简单解释，延迟低、零成本、隐私可控；主力按量 API 负责复杂任务和 Agent，通过网关接入；再挂一家备用平台，只在主力失败时自动接管。订阅套餐如果哪天能正常买到，我会买一份做补充，但绝不把它当成唯一依赖。

这个组合的核心思路是把"可用性"和"能力"解耦。补全这种高频刚需，用确定性最高的本地方案保证永远在线；复杂推理这种低频高价值需求，用按量付费保证随时能买到；容灾靠网关自动切换，不靠人盯。整套东西搭起来花了我大概两个周末，之后基本没再因为额度问题停过工。

有几个判断我想强调一下。第一，不要为了省钱去用明显能力不足的模型做核心任务，重试的成本远高于省下来的那点钱。第二，网关这一层看着像过度设计，但它是唯一能让你的工具链跟具体供应商解绑的手段，值得投入。第三，成本优化的最大杠杆在上下文管理，不在选平台，把无关文件从提示里剔掉的效果，比换一家便宜 30% 的供应商还明显。

最后分享一个小技巧：给自己的网关加一个每日 token 预算，超过阈值就自动降级到便宜模型并打日志提醒。这个机制救过我一次——某天一个循环脚本失控，反复调用，如果没有预算上限，按那个速率跑一晚上账单会很不好看。加了这个之后，我再没担心过意外超支的问题。