Orbi Cloud：
提个 Issue，收个版本

ORBI CLOUD 是什么

托管 Runner，GitHub 仍是唯一事实源

Orbi Cloud 跑的是与自托管 Orbi 相同的 GitHub 原生产线——Issue 进，Worktree、测试、独立审查与修复、精确合并——只是运行在由我们维护的基础设施上。你的工作流一点不变：Issue、PR 和发布证据都留在你自己的仓库里。

• 交付闭环
  GitHub Issue 进，打好 Tag 的 Release 出

  能改代码、会重跑测试的独立审查，exact-head merge（只合并审过的那个 Head），再到冻结 SHA、打 Tag、发布 GitHub Release、关闭 milestone——你的仓库本来就懂这条闭环，不需要引入第二个工作区。

• 模型
  模型用量包含在内，成本摊在明面上

  Solo 每月含 400M token，Pro 每月含 1.2B token；对应额度用完后，新交付暂停，没有按 token 计费的超额账单。单次交付的实测成本就写在下面。

• 运营
  恢复、合并门禁、独立审查

  交付产线的运营层，由我们承担。

• 发版
  发版由你发起，Orbi 来执行

  发版从不是全自动。你开一张 release 票并打上 ai-release 标签——这个标签只有人能打。发版的测试验收就是你仓库的 CI 结果——release commit 上的 GitHub Actions check run——所以 CI 里放什么，决定了 Orbi 替你保证什么：放单测，它保证代码逻辑；放业务流程的 e2e，它保证业务闭环。不放 CI 也是一种选择：没有任何 check run 时，两道门禁都放行，release 照样能发——只是失去了唯一的测试验收闸门。之后 Orbi 冻结 SHA、打 Tag、发布 GitHub Release、关闭 milestone。

成本，实测

我们不在你的 token 上赚差价

Pro 的 1.2B token 大约够小仓库的常见票合并 240–630 次，像 Orbi 引擎这样的大代码库约 96 次（2026 年 9 月实测）。这套成本结构建立在 provider 支持 prompt caching 上。完整样本、分位、限制和竞品引证见成本页。

点击之后

从登录到交付第一个 Issue，只有四步

不用注册新密码，也不用迁移工作区。整条路径都在 GitHub 上：

1. 01 用 GitHub 登录

   一次 OAuth 点击。仓库和账号都是你的，不需要单独的 Orbi 凭证。

2. 02 安装 Orbi GitHub App

   选择允许 Runner 工作的仓库；随时可以在 GitHub 一侧撤销授权。

3. 03 连接仓库

   连接第一个仓库，随后我们开通你的 Runner。先在你自己的仓库上试 3 次合并交付——不用绑定信用卡，不用订阅。

4. 04 写下第一个需求

   用一两句话说想改什么。Orbi 读你的仓库，一两分钟写成 Issue 草稿，你确认交出后才开始做。写草稿不占免费次数。已经有 Issue 的话，给它打上 ai-ready 标签也行。写需求怎么用