codex怎么把额度给别人用

你可能遇到这种情况：同事临时要跑一个 Codex 任务，自己的额度还剩不少，就想把额度分给他；或者小团队想几个人合用一个订阅。这事能不能做、怎么做不算违规、账怎么算，官方口径里其实没有一句话讲透。这篇不背数字，只给判断路径和可执行动作：先分清「账号层共享」和「用量层借用」的区别，再决定走哪条路，最后把费用和责任的边界写下来。

先说结论：Codex 额度能不能给别人用，取决于你走的是哪条路。把登录凭据给出去，额度确实跟着过去了，但账号安全、支付方式、历史记录也一起交出去了。反过来，账号归你、消耗记你名下、只把任务或结果转给对方，这种方式账目清楚，但被超额消耗的风险得你自己扛。

下面按「先分清共享类型 → 再看合规路径 → 共享前谈好边界 → 事后怎么算账」这个顺序走，每一步都给判断标准和可执行动作。涉及具体价格、额度数值、重置节奏的地方，一律到站内对应页面核对当时的数字，本文不写死任何数。

先分清两件事：账号共享和用量借用

账号层共享

把登录凭据交给别人，额度、支付方式、历史记录、绑定的第三方应用一起过去，出问题很难切割。

用量层借用

账号始终归你，别人只是消耗记在你名下，账目清楚，但你要自己承担被超额消耗和 Key 外泄的风险。

核心判断标准只有一条：对方是不是长期、高频、需要独立管理自己的用量。如果是，别走借额度这条路，直接让他自己开一个入口，省下的磨合成本往往比额度本身值钱。什么情况下这套判断不适用？只要任务里带公司内部数据、客户代码或受版权保护的素材，任何形式的凭据共享都别做，走组织内的正式授权流程。

合规的几条路，按人数和时长选

1. 一个人临时用几天让对方在你旁边用你的机器跑，或者你把任务接过来跑完再把结果给对方。额度不离开你的账号，风险最低。
2. 小团队长期协作优先看有没有官方或平台侧的多人方案，比如团队档、席位制、组织账号。到 /coding-plans 翻编程套餐目录，确认有没有支持多人共用的档位，再决定是买席位还是各自开号。
3. 需要独立账单让对方自己开账号，你把自己这边的调用方式、提示词模板、常用参数整理成文档给他。共享的是方法，不是凭据。
4. 绝对不要做把 API Key 贴在群里、写进共享文档、提交到代码仓库。Key 一旦扩散，额度被谁用完你查不出来，也收不回来。

共享之前先谈好三件事

• 额度归属：这份额度算谁的预算。如果是团队预算，提前说清超出部分怎么分摊，别等账单出来再吵。
• 用量可见性：双方都要能看到消耗情况。到 /codex-radar 看额度与重置节奏，到 /usage 对一下真实用量水平，用数据说话而不是凭感觉。
• 退出机制：什么时候停、怎么停、停之前要不要提前打招呼。约定一个「消耗到某个比例就通知」的阈值，比事后追责有用。
• 记录习惯：每次共享前后记一行——谁用的、大概什么任务、什么时候开始和结束。一个共享表格就够，不用搞得很正式。

共用之后账怎么算清楚

共用本身不难，难的是账单出来之后怎么摊。先定口径再分摊，中途改口径最容易起争议。下面三种口径各有适用场景，选一种写下来，所有人确认之后再开始用。

单价和计费口径会变，别背数字。去 /official-api 看官方价目，去 /price-watch 看价格变动记录，再去 /tools/token-price-calculator 把你自己的用量换算成钱。三个页面配合看，比记任何一个数都靠谱。按人头摊的缺点是重度用户占便宜，如果团队里有人明显跑得多，这条口径就不适用，换按用量摊。

共享额度的风险不在技术，在于事前没说清、事后算不清。