OpenAI 给开源作者发 Pro 了,你的项目够格吗?

2026 开源维护者福利观察

OpenAI 给开源作者发 Pro 了，你的项目够格吗？

门槛大概在哪？

不讲玄学，只讲证据——我们从官方条款、社区通过案例和申请表字段里，帮你判断你的项目值不值得花 10 分钟填表。

本文只回答一个问题

你的开源项目，到底有没有必要去申请 Codex for Open Source？

梳理时间：2026 年 5 月 1 日。OpenAI Developers 官方发布帖时间为 2026 年 3 月 6 日 19:10 UTC，也就是北京时间 2026 年 3 月 7 日 03:10；截至本文梳理时，活动已上线约 8 周，申请表仍显示滚动审核。活动、权益和条款可能调整，申请前请以 OpenAI 官方页面为准。

先说结论

OpenAI 没写死 star 数，但通过画像已经比较清楚

这个活动不是”开源作者自动领 Pro”，也不是”只要 GitHub 有项目就送”。官方说法很克制：它面向重要开源软件的维护者，申请会滚动审核，最终是否给、给什么、给多久，都由 OpenAI 判断。

但从官方申请表和社区公开样本看，还是能推一个大致区间。如果一定要给一个实操判断，我们分四档。

档位	大致条件	通过判断
A 档	5k+ stars，或 50 万到 100 万级下载/拉取量；项目是 devtool、infra、安全、数据库、AI 工程链路	高概率通过，强烈建议申请
B 档	2k-5k stars；项目和 Codex、MCP、agent、coding workflow、测试、CI、review 强相关	中高概率通过，很值得申请
C 档	500-2k stars；用户真实但社区规模不大，或项目是某个垂直生态里的关键依赖	可以试，但申请材料要强
D 档	个人 demo、README 项目、长期不维护、没有 release、没有用户、不是维护者本人	通过概率较低，不建议抱太高预期

一句话版本：如果你是核心维护者，项目公开、活跃、有真实用户，且 stars/downloads 能证明影响力，就值得申请。5k stars 不是官方硬线，但很像一个强信号。这里的核心不是”stars 决定命运”，而是 stars/downloads 证明使用量，项目类型证明生态价值，维护权限证明你能把资源用到开源项目上。

筛选原则

本文的判断依据是什么？

以下是我们筛选信息源的标准——只保留可验证的公开数据，剔除无法核实的传闻。

保留	OpenAI 官方条款、申请表字段、公开可查的通过案例、GitHub stars、下载量、Docker pulls、项目定位和维护活跃度
剔除	只有一句”我过了”的炫耀帖、无法定位项目名的截图、没有项目指标的转发、把个人订阅福利误读成开源项目资助的说法

01 OFFICIAL

官方到底写了什么？

OpenAI 这次的项目叫 Codex for Open Source。可定位到的官方首次公开发布时间，是 OpenAI Developers 在 2026 年 3 月 6 日 19:10 UTC 发布的 X 帖；换算成北京时间，是 2026 年 3 月 7 日 03:10。它给的不是单一福利，而是三类东西：6 个月 ChatGPT Pro with Codex、Codex Security 条件访问、API credits。

注意，API credits 不是让你随意消耗模型调用额度，而是用在”coding、maintainer automation、release workflows、core open source work”这些维护者工作流里。

申请表透露出的真实门槛

账号	需要填写 ChatGPT 账号邮箱
GitHub	GitHub username 要公开，仓库也要 public
维护身份	申请表直接问你是 primary maintainer 还是 core maintainer
项目影响力	要解释为什么项目 qualify，并提示你写 stars、monthly downloads 或生态重要性
API credits	如果申请 credits，需要 OpenAI Organization ID，并说明 credits 会怎么用于项目

条款里真正关键的几个词

OpenAI 会看什么	翻译成人话
repository usage	有没有真实使用量，stars、downloads、pulls、下游依赖都算证据
ecosystem importance	项目是不是某个生态里的基础工具、关键依赖、常用组件
active maintenance	最近是否还在发版、合 PR、处理 issue，而不是一个睡着的仓库
role or permissions	你是不是真的有维护权限，最好是 primary/core maintainer
Program capacity	名额和资源有限，不是满足条件就一定过

所以官方门槛不是”多少 stars 才能过”，而是”你是不是重要开源项目的真实维护者”。stars 只是最容易被看见的证据。

02 COMMUNITY SIGNALS

社区样本能推出来什么？

截至 2026 年 5 月 1 日，公开分享出来的通过样本还不多，所以不能做统计学结论。但几个样本放在一起看，方向很一致：OpenAI 更偏好”维护负担真实、用户真实、对开发者生态有用”的项目。

样本一：Databasus

Databasus 是开源数据库备份工具，主打 PostgreSQL，也支持 MySQL、MariaDB、MongoDB。项目 FAQ 写明：2026 年 3 月，它被 Anthropic 的 Claude for Open Source 和 OpenAI 的 Codex for Open Source 同时接受。

公开指标	2026 年 3 月 22 日页面写到 6,100+ GitHub stars，约 400,000 Docker pulls
项目属性	数据库备份、恢复、加密、通知、团队审计，属于生产系统基础设施
推出来的信号	5k+ stars 加上安全/数据库/基础设施属性，是非常强的通过画像

样本二：fast-agent / evalstate

社区转发里，evalstate 公开表示被 Codex for Open Source 接受。它的代表项目 fast-agent 是 MCP/agent/coding workflow 方向的工具，GitHub 搜索结果和 OSSInsight 里能看到大约 3.5k-3.7k stars。

公开指标	约 3.5k-3.7k stars，项目定位是 MCP-enabled agents and workflows
项目属性	和 Codex、agent、MCP、开发者工作流高度相关
推出来的信号	OpenAI 大概率不是机械卡 5k stars；和 Codex 生态高度相关时，3k+ 也可能进入视野

样本三：高星级 agent harness 项目

社区分享中，oh-my-openagent 等项目展示了 40k stars、百万级下载、160+ contributors 这类指标。这类项目即使不看具体申请细节，也很容易理解为什么会被 AI coding 工具厂商关注：它直接影响开发者如何使用模型写代码。

这类高星级项目不能拿来反推最低门槛，但能说明最高分画像：大规模社区、真实开发者工作流、多人贡献、和 AI coding 强相关。

03 HOW TO APPLY

申请表不要写故事，要证明三件事

OpenAI 的表单里有两个 500 字符限制的问题。空间很短，所以不要铺背景、不要写愿景、不要讲”我很热爱开源”。

更有效的写法，是把信息压成三块：谁在用、你是谁、credits 怎么变成维护产能。

要证明什么	怎么写（500 字符内）
谁在用	stars、monthly downloads、Docker pulls、下游依赖数、生产环境使用案例。数字比形容词有用。
你是谁	primary maintainer / core maintainer，维护了多久，最近在做什么。不要写”热爱开源”，写”负责发版、review PR、处理 issue”。
credits 怎么用	具体场景：自动化测试、代码审查、release note 生成、文档维护、安全扫描。不要写”提升效率”，写”用 Codex 跑 CI 里的集成测试”。

几个容易踩的坑

1. 不要用个人邮箱申请组织福利

API credits 需要 Organization ID，如果你用个人 ChatGPT 账号申请 credits，但填的是公司 org，可能会被质疑。

2. 不要只贴 GitHub 链接

审核的人不一定点进去看。把关键数字直接写在文本框里。

3. 不要写”我是学生/个人开发者，需要帮助”

这个项目的逻辑是”你维护的东西对生态很重要，我们帮你做得更好”，不是”你需要帮助所以我们帮你”。

4. 不建议只写”我需要订阅”

这不是个人贫困补贴，也不是普通学生福利。更好的叙事是：你维护的项目给生态带来价值，AI 工具能减少维护者负担。

前往 OpenAI 官方申请表

最后的判断

你的项目要不要申请？

如果项目 5k+ stars：别犹豫，直接准备材料，尤其是开发者工具、基础设施、安全、数据库、AI agent 相关项目。

如果项目 2k-5k stars：只要维护活跃，并且和 Codex/MCP/agent/coding workflow 相关，就很值得试。

如果项目不到 2k stars：不要只讲 stars，重点讲下载量、下游依赖、生产使用、生态关键性。

如果你不是 maintainer：可以提名，但不要冒充维护者本人申请。

最后一句话：OpenAI 看起来不是在奖励”会做开源页面的人”，而是在争取真正有维护负担、有生态影响力的开源维护者。项目越像基础设施，越像开发者每天会碰到的工具，越值得申请。

注意事项

申请前，这几点值得留意

权益是阶段性的：Pro 订阅给的是 6 个月，不是永久。到期后是否续期、以什么条件续期，OpenAI 没有承诺。不要把它当成可持续的开源资金来源。

条款值得细读：Codex for Open Source Program Terms 里有关于数据使用、服务修改和终止的条款。截至 2026 年 5 月 1 日，没有看到明显的”坑”，但建议申请前通读一遍原文。

这不是唯一的选项：Anthropic 的 Claude for Open Source 也在做类似的事情，Databasus 在 2026 年 3 月已公开表示同时拿到了两家的赞助。如果你的项目符合条件，两边都可以试试。

大背景：AI 厂商正在争抢开源维护者群体——维护者是开发者生态的意见领袖，也是 AI coding 工具最核心的早期用户。这波”福利”本质上是生态竞争；以 OpenAI 官方发布时间 2026 年 3 月 6 日 UTC 算，2026 年 5 月 1 日仍属于早期申请窗口。

资料来源

申请前，请先看原文

OpenAI Developers 官方发布帖	https://x.com/OpenAIDevs/status/2029998191043911955
OpenAI Codex for Open Source 官方项目页	https://developers.openai.com/community/codex-for-oss
OpenAI Codex for Open Source 申请表	https://openai.com/form/codex-for-oss/
OpenAI Codex for Open Source Program Terms	https://developers.openai.com/codex/codex-for-oss-terms
OpenAI Codex Open Source Fund	https://openai.com/form/codex-open-source-fund/
OpenAI Codex 开源组件页面	https://developers.openai.com/codex/open-source
Databasus 官网与 FAQ	https://databasus.com/faq
Databasus 开源项目	https://github.com/databasus/databasus
evalstate / fast-agent GitHub	https://github.com/evalstate/fast-agent
fast-agent OSSInsight 数据页	https://ossinsight.io/analyze/evalstate/fast-agent
evalstate 被接受的社区转发	https://app.daily.dev/posts/if-your-github-looks-like-this-please-apply–od4ne9n77
The New Stack 对 OpenAI/Anthropic 开源维护者项目的报道	https://thenewstack.io/openai-anthropic-open-source/

提示：社区样本只用于估算通过画像，不代表 OpenAI 官方名单。OpenAI 没有公开固定的 stars/downloads 数字线，最终以官方审核为准。