Agent.Space Share 和 Flex 解决的是两种不同的预算问题。如果你会稳定使用受支持的 OpenAI 模型，并希望获得跟随原生周期重置的固定额度，优先选 Share；如果你想按实际请求使用其他可用模型，优先选按量扣费的 Flex。
这并不是非此即彼的选择。比较常见的组合是：用 Share 承担稳定的 GPT 工作流，再用 Flex 处理偶发的其他模型任务。需要特别注意的是，调用哪个模型，就由该模型所属的资金类型扣除额度；Share 与 Flex 彼此独立，不会自动互相垫付。
本文依据 2026 年 8 月 28 日的 Agent.Space 产品规则整理。可用模型和公示价格可能变化，购买前请以实时的套餐与模型价格为准。
Share 与 Flex 快速对比
这张表用于帮助决策，不代表每个模型都会一直可用。当前支持范围仍应以线上模型选择器和价格页为准。
Agent.Space Share 是什么
Share 通过 Agent.Space 套餐提供固定 GPT 额度。它以相应 Agent 服务的额度为基准，并跟随该服务的原生用量周期重置。周期结束时，套餐额度会重新计算；没有用完的额度不会转成 Flex，也不会像现金余额一样一直累积。
因此，Share 更适合规律出现的任务，例如：
- 大多数工作日都会使用 Codex 开发；
- 多个项目都采用稳定的 OpenAI 模型工作流；
- 更愿意按套餐选择容量，而不是逐条计算请求成本。
Share 不是上游供应商账号，不是共享登录，也不是官方订阅转售。Agent.Space 围绕受支持的 Agent harness 与模型管理服务访问和资源匹配。如果你依赖完整的原生界面，或只有上游官方产品才提供的功能，仍需单独评估官方服务。
Agent.Space Flex 是什么
Flex 是用于 Agent.Space 当前其他可用模型的按量余额。它不会按套餐周期补充，而是根据所选模型的公示价格随请求扣除。因此，当模型选择或使用频率不稳定时，Flex 更容易控制。
充值购买的 Flex 不过期，但促销 Flex 不同：赠送额度可能有独立有效期。若要规划长期项目，不要只看到当前有赠送余额就默认它可以永久保留。
Flex 通常适合这些工作：
- 先用一个边界明确的任务测试某个模型，再决定是否长期采用；
- 针对不同任务使用 Kimi、GLM、MiniMax、DeepSeek、Claude、Grok 或其他当前受支持模型；
- 为偶发的非 OpenAI 请求准备一笔备用余额；
- 使用频率不规律，不想先承诺固定周期。
不要拿旧截图或写死的价格表估算当前成本。模型范围和价格会变化，应根据实时模型列表，以及你准备执行的真实任务规模来估算。
用五个问题完成选择
1. 任务必须使用哪个模型？
应该先回答这个问题，因为模型直接决定资金来源。受支持的 OpenAI 模型使用 Share，其他当前可用模型使用 Flex。若先购买额度，再强行让不匹配的模型使用它，最终只会遇到可以避免的请求失败。
如果任务依赖某个具体模型，比较套餐前先在线上选择器确认它是否可用。
2. 用量是稳定还是忽高忽低？
每天重复出现的工作，更容易用固定额度规划。一次性评估、短期突发任务，或经常变化的模型组合，通常更适合按量余额。
评估时看一个正常周期，不要只看最忙的一天。一次发布周的高峰不一定值得长期购买更大套餐；反过来，每天少量但持续的请求，也可能形成稳定的基础用量。
3. 更看重固定额度，还是逐次控制？
Share 在选择套餐时决定容量，Flex 则把选择细化到每次请求。脱离模型、使用方式和实时价格，很难简单断言哪一种一定更省钱。
如果优先考虑预算可预测性，可以先找覆盖正常周期的最小 Share 档位；如果更需要跨模型的精细控制，可以从有限的 Flex 余额开始，再根据真实请求记录决定是否充值。
4. 没用完的额度会怎样？
Share 额度会随周期重置，未使用部分不会转为 Flex。充值购买的 Flex 会继续保留，促销 Flex 则可能按活动规则过期。
这一点对季节性工作很重要。长时间不用时，固定套餐可能产生闲置；购买的 Flex 可以留到下个项目。相反，如果 GPT 工作流长期高频且稳定，固定容量通常比每次都做按量预算更省心。
5. 你愿意承担多少管理成本？
稳定的 GPT 工作流只用一个 Share 套餐会比较简单。Flex 提供更多模型选择，但也需要关注实时价格和逐次用量。两者一起用没有问题，不过团队必须清楚每种模型会扣哪一种额度。
Agent.Space Developer API 指南会进一步说明：已验证的服务端集成如何通过模型发现和请求记录确认这条边界。
什么情况下适合同时使用 Share 与 Flex
当工作中既有稳定主线，又有波动需求时，两种额度可以互补。
例如，团队可以用 Share 支付日常 Codex 开发，再用 Flex 让某个受支持的非 OpenAI 模型完成一次聚焦审查或研究任务。这样既能让常规工作保持可预测，也不用把所有任务都限制在同一模型家族。
但资金边界不会消失：某项 Share 额度不可用时，Agent.Space 不会悄悄改扣 Flex；Flex 模型也不会转而使用 Share。请求失败时，应先检查所选模型及其资金来源，而不是假设另一种余额会自动接管。
这和 Agent.Space 的整体结构一致：模型、Agent harness、Session、Workspace 与商业访问彼此独立。Agent.Space 如何工作解释了这些层级，以及为什么改变其中一项不会自动改变其他项。
常见的选择误区
- 把 Share 当成储值余额。 它是按周期提供的套餐额度，不会不断结转。
- 认为所有 Flex 都一样。 充值购买与促销赠送的 Flex 可能有不同有效期。
- 认为单价最低就一定最省。 较低的单位价格，并不保证完成任务时重试更少或总用量更低。
- 期待额度自动兜底。 即使两种额度同时存在，Share 与 Flex 仍然彼此独立。
- 根据跑分买额度，而不是根据工作流。 应从模型要求、任务频率和审查方式出发，而不是只看通用排行榜。
如果你是因为长任务而纠结额度，还需要把商业额度与项目延续性分开。余额负责支付请求，不决定运行之间能保留什么。持久化 Coding Agent Session会专门解释项目状态问题。
购买前检查清单
做决定前，先写下：
- 任务真正需要的模型或模型家族。
- 一个正常周期内预计会使用多少天。
- 工作是重复发生，还是由不规律的高峰组成。
- 是否能接受固定额度没有完全用完。
- 由谁关注实时价格、请求记录和余额归属。
稳定使用 OpenAI 模型时选 Share；需要按量使用其他可用模型时选 Flex；两种需求确实同时存在时再组合使用。开始后，再用实际使用数据复盘，不要一直依赖事前估算。
比较当前 Agent.Space 套餐与 Flex 价格，先确认需要的模型仍可用，再从能支持一个真实任务的最小选项开始。