openai 免费 api 额度

刚注册完 OpenAI 账号、想先跑通一次接口，最常见的卡点不是代码写错，而是不确定「到底有没有免费额度、能撑多久、超了会怎样」。网上说法互相打架，有人晒截图说送了一笔，有人一调用就报额度不足。这篇不背数字，只帮你把「有没有、在哪看、怎么验证、什么时候该转付费」这条链路走通。

刚注册完账号、想先跑通一次接口，最常见的卡点往往不是代码写错，而是不确定到底有没有免费额度、能撑多久、超了会怎样。网上的说法互相打架，有人晒截图说送了一笔，有人一调用就报额度不足，两边都没骗人，只是看的不是同一个地方。

这篇不背任何数字，只帮你把「有没有、在哪看、怎么验证、什么时候该转付费」这条链路走通。凡是要写进项目文档的数字，一律改成「去官方后台用量页看当期数值」这样的表述，这样文档不会过期，你也不会被人拿着旧截图来对质。

先定性：OpenAI API 侧到底有没有「免费额度」这回事

先把三个常被混为一谈的东西拆开：账号初始赠送额度、免费试用档的限速额度、以及订阅制产品里的用量。这三者归属不同的账，报错信息、查询入口、能不能叠加都不一样。混着看，结论必然是矛盾的。官方赠送类额度的存在与否、多少、有效期，会随注册时间、地区、是否绑定支付方式变化，属于典型的「会变的数字」，任何写死的说法都当过期信息处理。

• 账号初始赠送：挂在账号或组织下的 credits，是一次性的，用完不补；
• 免费试用档：常见的是限速与可用模型范围收窄，不一定附带白给额度，两者别划等号；
• 订阅产品用量：属于另一个产品体系，和 API 的计费账户不通，别拿它的截图来推 API。

什么情况下不适用：如果你的账号是通过第三方中转或云厂商托管通道接入的，额度规则归那家平台管，不适用官方口径。这类情况要去看你实际签约的平台后台，而不是官方文档。站内 /official-api/providers/openai 与 /official-api 可以作为对照参考，但先弄清自己走的是哪条通道。

别搜截图，去这几个地方看真实状态

搜到的教程截图一律当过期信息处理，唯一权威口径是官方后台的用量页与计费页。看清当前状态后再做判断，不要反过来：先有预期，再去找证据支持。拿不准某个名词时，先去 /ai-dict 对照，比如 credits、free tier、rate limit，这几个词经常被教程作者混着用。

验证动作很简单：用一个最小请求跑通，然后回后台看用量是否真的被扣减。扣了，说明你走的是按量计费路径；没扣但也没报错，可能走的是赠送额度；直接报额度不足，那就是两者都没有。这一步比读十篇教程都快。

怎么拿到、什么账号拿得到：一份自查清单

拿到与否，取决于几个变量：手机号与地区是否符合要求、是否必须绑定支付方式、新号赠送是否有时限。这些条件会变，所以别背条件，背检查顺序。按下面清单从上往下过，卡在哪一步就是那一步的问题，不用猜。

• 账号层面：地区、手机号验证是否通过，有没有提示需要补充材料；
• 支付层面：是否被要求绑定支付方式，绑了会不会从赠送档切到按量档；
• 时限层面：赠送类额度常见有领取或使用窗口，过期不补；
• 归属层面：额度挂在组织还是个人账号，团队共用时尤其要写清；
• 记录层面：把「谁持有账号、谁持有 key、额度归谁」写成一行记录。

团队场景要单独提一句。一家 5 人小团队如果共用一把 key，额度消耗会集中在一个人身上，后面追溯不清，谁也说不清是谁跑没的。不适用情况：如果公司要求走合规发票与统一结算，个人赠送额度这条路通常走不通，直接按企业通道申请更省事，别在个人号上折腾报销。

能用多少、受什么限制：把「额度」和「限速」分开看

额度是总量问题，限速是频率问题，报错信息不同、应对方式也不同。把两者混在一起排查，最常见的后果是：明明额度还够，却一直在改重试逻辑；或者明明是被限速，却去后台找额度。先看清报错属于哪一类，再动手。

不适用情况：做批量离线任务时，限速带来的重试开销可能比省下的钱更贵，这时免费反而更亏。判断标准很朴素：如果重试次数已经多到你要专门写一套调度逻辑，那就该考虑换通道，而不是继续优化重试。

上手验证顺序：从一次最小调用开始

先别急着接进正式项目。用一次性脚本跑通全链路，包括鉴权、报错处理、重试、日志，比省那点调用量重要得多。下面这套顺序按「先确认事实、再放大规模」来排，走得慢但不会返工。

1. 第一步：发一次极短请求只确认鉴权、模型名、返回格式都对，输入尽量短，别在这一步引入业务逻辑。
2. 第二步：回后台对上号看用量页有没有这次调用的记录，扣减了还是走了赠送档，报错是哪一类。
3. 第三步：逐步加长输入观察消耗增长是否线性、有没有意外的重复计费，顺便把日志字段固定下来。
4. 第四步：单独建 key给这次验证单独建一把 key，用完就删，避免和正式环境混在一起，出问题也好定位。

把用量日志按固定字段记下来，后续做预算与核对才有依据。token 量换算成钱，可以到 /tools/token-price-calculator 与 /tools/model-cost-calculator 这两个路径看当期口径，别自己凭感觉折算。

什么时候该停止薅、直接转付费

三个信号出现任意两个，就可以停止在免费档上折腾了：免费档延迟波动大到影响体验；限速导致的失败重试占比明显偏高；你在为一个内部小工具反复找白嫖入口，投入的时间已经超过它省下的成本。这三个信号都不需要精确数字，凭日常体感就能判断。

• 转付费前先算清一次典型任务消耗多少 token，到 /usage 与 /price-watch 看当期水平；
• 把预算上限和告警阈值先设好，避免切换后第一个月账单失控；
• 给正式与测试环境分 key，账单才能按环境拆开看；
• 纯学习、纯演示、玩具项目，继续用免费额度完全合理，不必强上付费。

不适用情况也要说清：如果你的任务是低频、非关键、失败了也无所谓，那免费档完全够用，此时转付费属于纯浪费。要不要转，取决于失败代价，不取决于额度本身还剩多少。站内 /guides/api-cost-first-budget 这条路径值得先读一遍，把预算思路理清再动手。

几个高频误会，踩过的都懂

最常见的误判是把「免费试用档可用」读成「永久免费」。试用档通常是限速加可用模型范围收窄，不等于白给额度；你能调用，不代表不花钱，也不代表没有上限。第二个高频误会是把订阅产品的用量当成 API 额度，两者账户体系不同，拿订阅截图去问 API 客服，只会得到一段标准回复。

• 看到教程写了具体金额就照抄预期，结果实际为零——数字会变，方法不会变；
• 把限速当成额度不足，去后台找不存在的余额；
• 把第三方中转的赠送活动当成官方口径，两边规则完全不同；
• 同一把 key 到处用，出问题时分不清是谁的调用。

额度会变、规则会变，唯一不变的是「先看官方后台、再用最小请求验证」这个顺序。