豆包api免费额度

很多人第一次接豆包 API，卡在同一个地方：听说有免费额度，但不知道是给网页版还是给接口，也不知道额度归哪个账号、多久恢复、用超了会不会自动扣钱。这篇不给你背数字，而是给一套自己查、自己试的顺序：先去哪页看当期规则，怎么用最小调用验证额度真的生效，什么情况下免费额度根本不适合你，最后给一份新用户上手的执行清单。

很多人第一次接豆包 API，卡在同一个地方：听说有免费额度，但不知道那是给网页版/App 的对话额度，还是给开发者接口的试用额度。这两个是两套体系，账号、入口、计量单位都不一样，拿一个的经验去套另一个，十有八九要踩坑。

这篇不替你背数字，而是给一套自己查、自己试的顺序：先去哪里看当期规则，怎么用一次最小调用验证额度真的生效，什么情况下这个免费额度根本不该当方案用，最后给一份新用户能照着做的上手清单。想先看模型清单和厂商条目，可以直接到 /official-api/providers/ 及 /models 核对当时的档位与规格。

先分清：免费额度是给「谁」的

写代码接 API 的人最常犯的错，是把「网页版能免费聊几句」当成「接口也能免费调」。前者面向普通用户，后者面向开发者账号，两者互不通用。接口侧的试用额度一般绑定在具体平台账号下，你得先开通对应服务、建好密钥，它才会在用量页里体现出来。光注册一个账号、没开通服务，等于零。

• 网页版/App 的免费对话额度和开发者 API 的试用额度，是两条独立的路，别互相换算。
• API 侧额度通常需要先开通服务、创建密钥后才生效，注册本身不代表能调通。
• 哪些模型参与试用、输入输出怎么计价，以厂商公开文档和站内资料为准，截图和群聊说法只能当线索。
• 站内 /official-api/providers/ 汇总了各家厂商条目，/models 是模型规格库，两处对照着看，比听转述靠谱。

想确认「我现在还有多少」，按这个顺序查

额度和余额是两回事：一个是你还能用多少量，一个是你账户里还有多少钱，换算口径不对就会得出错误结论。查的顺序建议从有结算效力的地方开始，再往辅助信息走，别一上来就翻二手帖子。

1. 第一步：看控制台登录你所用平台，找到用量或额度页面，确认当前可用量和你账号的绑定关系。
2. 第二步：对照规则到 /price-watch 看近期有没有规则调整，规则一变，之前的经验就作废。
3. 第三步：统一口径用 /tools/token-price-calculator 把可用量和预计花费换算成同一单位，再决定能不能撑住你的业务量。

新用户上手：用最小成本把链路跑通

别一上来就写完整业务逻辑。先用一次最小请求，确认三件事：能返回、计费正常、额度有变化。这三件事都成立，再谈正式开发。调试阶段的循环和重试是额度杀手，代码里得先把上限压死。

1. 发一条最小请求短输入、便宜档模型，跑通即可；确认返回正常，同时刷新用量页看额度是否有变化。
2. 记录单次消耗把这次调用的输入输出长度记下来，作为后面估算的基准，别凭感觉。
3. 折算预期用量用 /tools/model-cost-calculator 按你预期的调用频次折算，判断免费额度大概能撑多久。
4. 给代码设死上限最大输出长度、超时时间、重试次数都调到最低可用值，防止调试循环一次性把额度打光。
5. 设预算或提醒在账号侧配置用量提醒或预算告警，站内 /usage 可对照真实用量水平，别等账单到了才发现。

什么情况下免费额度不该当方案用

免费额度适合验证链路、跑小规模实验，但它不适合当生产依赖。并发一上来、稳定性要求一高，免费档的速率限制和规则存续期都会变成风险点，这时候该做的是按付费口径算预算，而不是继续薅。

还有一点容易被忽略：不同账号、不同平台之间的额度不能互相搬运或合并。你在 A 平台拿到的试用额度，解决不了 B 平台的调用需求，别把两个账号的经验混着用。