企业官网建设流程全解析

Orca 报 GitHub is rate-limiting requests 但设置里 API Budget 正常怎么排查？

【免费下载链接】orcaOrca is the ADE for working with a fleet of parallel agents. Run any coding agent with your own subscription. Available on desktop, mobile and remote runtime.项目地址: https://gitcode.com/GitHub_Trending/orca48/orca

Orca 在 PR / Checks 面板刷新时会弹出 “GitHub is rate-limiting requests”，但打开 Settings → Git 里的GitHub API Budget，REST / Search / GraphQL 的剩余配额看起来还有余量。这两个数字不一致并不是显示错误：Orca 通过本机（或远端 Orca 主机）上的GitHub CLI（gh）访问 GitHub，而 Settings 里的 Budget 数字来自一个不受限流计费的探测端点，它有时会显示“还有余额”，但同一用户的真实 REST 调用已经返回remaining: 0。本文的任务就是在两者矛盾时，用一条真实 CLI 调用判定配额是否真的耗尽，并给出文档支持的恢复路径。

前提：你的环境装有gh且已登录（which gh可用）。Orca 继承的是该主机上gh的登录身份，所以排查时要用和 Orca 相同的机器与用户执行命令。

先明确该信哪个数字

GitHub 给每个已认证用户分配的是共享小时配额，同一账号下的所有工具共用一份：Orca 本身、终端里手动敲的gh、会调用gh的 Claude/Codex/Grok 等 agent、CI 脚本、浏览器扩展和其他 App。

Orca 关心的三个桶（文档给出的典型限额，针对已认证用户）：

主桶耗尽时 GitHub 返回 HTTP403，消息形如API rate limit exceeded。此时 Orca 会把它归类为 rate-limited，尽量保留最后一次已知的 PR 状态，并在短时间内停止再派生新的gh调用（熔断器按core/search/graphql桶分别触发），避免一次限流变成失败风暴。

文档给出的优先级：当数字互相矛盾时，按这个顺序采信——

1. PR / Checks 面板上的报错本身（一次真实请求失败了）
2. 终端里的真实 CLI 检查（见下节）
3. Settings 里的 Budget 数字（有用，但只是探测值）

另外注意区分：Accounts 里的Claude / Codex / Grok usage是 AI 供应商的用量限制，不是 GitHub 的 REST 配额，别把两者当成同一个数。

用终端确认真实配额状态

在与 Orca 相同的机器、相同的用户身份下执行：

# 探测（不消耗配额；可能比实际情况看起来更“健康”） gh api rate_limit --jq '.resources | {core, graphql, search}' # 真实 REST 调用 —— PR 刷新依赖的就是这种调用 gh api user -i 2>&1 | head -40

第一条只是探测，第二条才是判断依据。判定标准（文档明确给出的）：如果gh api user返回403，响应体带API rate limit exceeded，且响应头X-Ratelimit-Remaining: 0，则该账号的 REST 配额已被封到X-Ratelimit-Reset指定的时刻为止（Unix epoch 秒）。

只要这一条真实调用是 403，就说明 Settings 里的“正常”是探测端点的假象，按限流处理即可。

配额通常是被谁烧掉的

文档列出的常见消耗来源，对照自己的环境排查：

• 同时打开了多个 Orca 窗口或 electron-dev 构建（每个都可能刷新 PR / Tasks）；
• agent 在自动化gh调用（给 PR/issue 打 assign、轮询 checks、批量 GraphQL）；
• 重 Tasks / 多仓库 fan-out 的同时还在刷新 PR 面板；
• 其他 App 在使用同一个 GitHub 用户 token。

确认限流后怎么做

1. 等——等到报错里或X-Ratelimit-Reset里显示的整点重置。
2. 减少并发的 GitHub 客户端——关掉多余的 Orca 实例，暂停批量gh自动化。
3. 限流期间不要反复手刷 PR 面板；Orca 已经在自动退避了。
4. 脚本里尽量把 GraphQL 批量化，不要在个人账号上对大集合逐个 REST 轮询 PR。
5. 重置之后如果 PR 刷新仍失败，转入认证排查（下一节）。

重置后仍失败：检查认证

限流恢复后问题依旧时，按文档顺序检查认证：

gh auth status -h github.com gh api user --jq '{login, id}'

健康状态是：已登录、token 有效、gh api user返回你的 login。

文档特别提醒的两个坑：

• shell profile 里的GITHUB_TOKEN/GH_TOKEN。如果~/.bash_profile或~/.zshrc里 export 了这两个变量（例如export GITHUB_TOKEN=$(gh auth token)），gh会优先使用它们而不是 keyring，过期的环境变量 token 会产生令人困惑的认证或限流行为。处理方式是先取消设置再重新登录：

  unset GITHUB_TOKEN GH_TOKEN gh auth logout -h github.com gh auth login -h github.com

  重新登录后重启 Orca，让它取到新凭据。

• 远端 / SSH worktree。GitHub 认证是按主机的：笔记本上登录了gh，远端机器上并没有。SSH 到那台主机上执行gh auth login，或使用 Orca 的 remote-server GitHub budget view 查看该环境的配额。同理，Settings 里的 GitHub API Budget 只显示桌面客户端本机的gh身份；远端 Orca Server 要用远端的 advanced budget view 看服务器自己的gh身份。也就是说，如果你在远端主机上遇到限流，本地 Settings 里的“正常”数字本来就不代表那台主机的状态。

面板上的表现与最后的核对手段

限流或 GitHub 故障期间，PR 和 Checks 面板优先显示最后一次已知状态加一个短横幅，而不是把界面清空；硬性认证/权限失败则会显示明确的空状态文案提示你修登录或权限。

如果按上面步骤仍无法定位，文档给出的收尾路径是：

1. 用 Orca 所用的同一机器/用户，在终端执行gh pr view或gh api user复现一次；
2. 收集日志：Help → Open Logs；
3. 把归类后的报错文本（不要贴密钥）、打码后的gh auth status输出、以及“终端里gh是否同样失败”一并反馈。

完整参考见 Troubleshooting GitHub errors（权限/404/网络故障/gh缺失等其他报错也在这篇里）和 Settings reference 的 Git 一节。

【免费下载链接】orcaOrca is the ADE for working with a fleet of parallel agents. Run any coding agent with your own subscription. Available on desktop, mobile and remote runtime.项目地址: https://gitcode.com/GitHub_Trending/orca48/orca