Pando
OpenAI 开发的 Git 兼容版本控制后端，保留 Git 协议与对象模型，重新设计存储与并发层以支撑 AI 代理大规模并行提交
时间轴 (近 90 天)
OpenAI为Codex重做了Git服务端Pando，中位推送延迟降低近80%，每天承载约1PB数据。
Pando 的设计包括让各分支的处理相互独立。
OpenAI 自研了 Git 后端 Pando，用于其超大型单体仓库。
Pando 将中位推送延迟降低了近 80%。
Pando 每天承载近 PB 级别的 Git 数据传输。
业界应对单体仓库版本控制压力的方式大致分两类：虚拟文件系统（如 VFS for Git、Sapling 的部分思路）按需物化文件；重写服务端传输与存储（Pando 属于后者）。
Pando 会在多次 fetch 之间复用已存储的 packfile。
近 80% 的延迟降幅是在 OpenAI 自身工作负载下测得的中位数，迁移到其他团队能否复现取决于访问模式是否相似。
Pando目前主要服务于OpenAI内部。
OpenAI构建了Pando，一个兼容Git的后端系统，用于应对Codex等代理工具产生的大规模推送压力。
还有 8 条时间轴事件
全部知识事实 (18)
OpenAI内部使用一个巨型单体仓库（monorepo）管理大量代码。
60%待验证OpenAI为Codex重做了Git服务端Pando，中位推送延迟降低近80%，每天承载约1PB数据。
50%待验证Pando 将中位推送延迟降低了近 80%。
50%待验证Pando 每天承载近 PB 级别的 Git 数据传输。
50%待验证Pando 会在多次 fetch 之间复用已存储的 packfile。
50%待验证业界应对单体仓库版本控制压力的方式大致分两类：虚拟文件系统（如 VFS for Git、Sapling 的部分思路）按需物化文件；重写服务端传输与存储（Pando 属于后者）。
50%待验证Pando 的设计包括让各分支的处理相互独立。
50%待验证近 80% 的延迟降幅是在 OpenAI 自身工作负载下测得的中位数，迁移到其他团队能否复现取决于访问模式是否相似。
50%待验证OpenAI 自研了 Git 后端 Pando，用于其超大型单体仓库。
50%待验证Pando目前主要服务于OpenAI内部。
50%待验证OpenAI构建了Pando，一个兼容Git的后端系统，用于应对Codex等代理工具产生的大规模推送压力。
50%待验证Pando在Git协议层面保持兼容，现有工具链和客户端无需大幅修改即可继续工作。
50%待验证Pando针对推送路径进行了优化，可能涉及改进引用更新、减少锁竞争或重构对象存储的写入流程。
50%待验证OpenAI 工程团队开发了 Pando，一个 Git 兼容的后端，专门为 Codex 所能释放的开发规模而设计。
50%待验证Pando 选择 Git 兼容，承认了 Git 作为事实标准的地位，即便底层重构，接口层也不轻易动。
50%待验证短期内，Pando 是 OpenAI 内部基础设施的一部分，普通开发者接触不到。
50%待验证OpenAI 没有公开 Pando 的具体实现细节、性能数据或部署规模。
50%待验证Pando 的定位不是重造版本控制系统，而是保留 Git 兼容性并替换后端架构以承受大规模并发生成。
50%