coderabbit

CodeRabbit CLI 和配置

本地优先的 AI 代码审查：在问题进入 PR 之前就发现它们。 CodeRabbit CLI（coderabbit，别名 cr）会在本地审查工作树或分支中的更改，因此 PR 端的审查变成确认，而不再是反复修改——这能节省计费的 PR 审查轮次（包括 CodeRabbit 自身的配额和任何 Copilot 额度）。涵盖 CLI 功能，包括本地审查，以及 Beta 版云端编码 Agent 命令，还有 .coderabbit.yaml 调优。PR 端的机制（讨论串、重新请求、机器人循环）位于 git-pr 技能中。

已根据 CodeRabbit CLI v0.9.1 验证（2026-10-22；2026-10-27 再次检查，仍是最新版本）：在官方构建版本上检查了每个子命令的 --help，包括隐藏的子命令，并与 v0.9.0 进行差异比较；还在干净的工作树上运行了隐藏和已移除的审查标志。也检查了以下内容：CLI 更新日志，其中尚无 v0.9.1 条目；从 v0.9.1 --help 生成的 CLI 命令参考；Agent 模式、云任务和审查命令页面；以及套餐、速率限制和按用量计费的附加项页面。标志均标注了引入它们的版本。未运行会产生费用并推送内容的 coderabbit code 命令；相关处理方式依据上述文档。命令参考涵盖 v0.9.1 新增内容（code archive、code goal、new --goal/--private/--access、resume --interactive）；云任务指南尚未涵盖。如果 coderabbit --version 显示的版本更新，请将各子命令的 --help 与此列表进行差异比较，并阅读 v0.9.1 之后的更新日志条目，再依赖此处的标志详情。

适用场景

• 审查本地更改——“审查我的更改”、“运行 coderabbit”、提交前／推送前／PR 前检查
• 执行审查－修复循环——运行审查、修复有效问题、重新运行以验证
• 配置 CodeRabbit——创建或调整 .coderabbit.yaml、减少审查噪声、禁用重复的代码检查工具
• 检查限额——各套餐的速率限制、审查预算
• 设置 CLI——安装、身份验证、更新、无头模式／CI 用法
• 运行云端编码 Agent 任务——coderabbit code new/resume/push，将本地会话移交给云端（Beta 版，v0.9.0）

关键规则

1. 评审会将代码上传到 CodeRabbit 的服务。 评审会将差异（及上下文）发送给 CodeRabbit。对于包含敏感代码或尚未发布代码的仓库，首次运行前请确认用户是否同意。
2. 评审会消耗每小时配额（免费版：CLI 评审每小时 3 次）。请谨慎指定范围（--committed/--uncommitted、--base），并使用 coderabbit review findings 重放上次结果，而不消耗评审次数。
3. 以编程方式驱动修复时，请使用 --agent 输出；默认的纯文本模式面向人工使用。绝不要传入 --plain：没有任何 --help 会列出它，而且它的作用取决于二进制文件。v0.7 移除了它——程序会显示 error: unknown option 和用法文本，却以退出码 0 结束，因此管道或尾随查看的运行结果看似正常，实际却没有进行评审；v0.8 和 v0.9.0 会以退出码 1 拒绝它（v0.9.0 会添加 Remove --plain 提示）；v0.9.1 又重新接受它，但将其作为隐藏的无操作选项。不要猜测标志：已安装二进制文件上的 coderabbit review --help 是受支持的选项说明，但它未列出的隐藏旧别名仍可解析——--type <all|committed|uncommitted> 和 --light 都会启动实际评审，而 v0.9.1 会将已移除的 --prompt-only 作为 --agent 处理。
4. 修复前请验证发现的问题——这与 PR 评审的规则相同：逐条判断每个发现是否成立；绝不要为了让工具不再提示而盲目修复。
5. CodeRabbit 是可选的——请先查看 Code Review Policy（仓库中的 AGENTS.md/CLAUDE.md；如果没有，则查看用户的全局 Agent 指令；参见 git-pr 技能），确认首选评审者和检查点。若项目策略或用户未选择使用 CodeRabbit，绝不要安装、认证或运行它。
6. coderabbit code 会产生费用并推送代码。 new、ask 以及通过 resume 发送的任何内容（-m、--steer、--answer 或 --interactive 会话）都会启动计费的 Agent 工作；push 和 Autofix（原名 Autopilot）会修改仓库，而编辑已完成的 code goal 会重新启动工作。仅在用户明确提出请求时运行；如果某项任务已报告提交节点，绝不要再次运行——重跑会重复产生费用（references/cloud-tasks.md）。

---

设置

curl -fsSL https://cli.coderabbit.ai/install.sh | sh   # also links `cr`; or: brew install coderabbit (no `cr`)
coderabbit auth login        # browser OAuth; --agent emits JSON for agent-driven login
coderabbit auth status       # verify
coderabbit doctor            # diagnose runtime/auth/git/connectivity; exits 1 when any check fails

auth login 还接受 --api-key "<key>"（存储密钥而非 OAuth）、--region us|eu、--self-hosted 和 --no-browser（打印可由能够访问 localhost 回调的浏览器打开的 URL）。auth org 可交互式切换当前组织；从 v0.9.0 起，auth org --agent 只会以 JSON 格式列出组织，因此 Agent 无法切换组织——需要由用户运行 coderabbit auth org。每个 auth 子命令都支持使用 --agent 输出 JSON。

无需付费计划：使用免费账户运行 coderabbit auth login 后，Free 计划包含 CLI 审查（每小时 3 次）——付费计划会提供组织上下文、学习成果和更高限额。新组织会先享有为期 14 天的 Advanced 试用期（Advanced 审查限额、每小时 50 次聊天），之后再选择计划或降级到 Free。无头环境/CI：必须使用用户拥有席位的组织中的 Agentic API key（不接受用户 API 密钥），并在每次运行时通过 --api-key "$CODERABBIT_API_KEY" 传入，或使用 coderabbit auth login --api-key "$CODERABBIT_API_KEY" 存储一次。CLI 不会读取任何 API 密钥环境变量——CODERABBIT_API_KEY 只是常用的密钥名称。审查会优先使用该用户计划的额度；只有在启用了按用量计费附加项时，才会使用用量积分。

更新：coderabbit update 可更新通过安装脚本安装的版本；Homebrew 安装的版本只能通过 brew upgrade coderabbit 更新（v0.9.0 update --help；doctor 会报告 Update policy: Managed by Homebrew）。对于非 Homebrew 安装，CLI 也会自行更新：CODERABBIT_CLI_DISABLE_AUTO_UPDATE=true 会固定已安装的版本，安装脚本中的 CODERABBIT_VERSION=X.Y.Z 则会固定某个版本。v0.9.0 --help 中列出的其他开关有：CR_CLI_TELEMETRY_DISABLED=true，以及 CODERABBIT_LOG_LEVEL=debug 和 CODERABBIT_LOG_TRANSPORT=console，用于将日志发送到 stderr，而非 ~/.coderabbit/logs。v0.9.0 中的 coderabbit completion bash|zsh|fish|powershell 会为两个名称打印补全脚本。v0.9.1 --help 又列出了 6 个开关：CR_CLI_AGENT（Agent 名称，例如 claude 或 codex；可选择非交互式 Agent 输出）、CODERABBIT_CLI_UPDATE_MANAGED=true（组织管理的更新）、CODERABBIT_HOST_URL（服务 URL；--host-url 优先，且自定义主机还需要 CR_CLI_ALLOW_UNTRUSTED_HOST_URL=true）、CR_CLI_LOG_FILE 和 CR_CLI_AUTH_TIMEOUT（毫秒，默认值为 30000）。

本地审查必须在 git worktree 中运行（--dir 可指定一个 worktree）；--remote 审查和 pullrequest <full URL> 可在任意位置运行。cr 是安装脚本创建的符号链接（~/.local/bin/cr）；Homebrew cask 只会链接 coderabbit——编写命令、脚本和允许列表模式时，请使用完整名称。

审查范围和检查点

检查点	命令	审查内容
提交前	coderabbit review --uncommitted	已暂存和未暂存的已跟踪更改
推送前	coderabbit review --committed	尚未进入基准分支的本地提交
PR 前（完整分支）	coderabbit review --base main	工作树和分支相对于基准的提交
仅审查子目录	coderabbit review --dir packages/api	某一路径下的更改
相对于指定提交	coderabbit review --committed --base-commit {sha}	自某个提交以来的更改
包含未跟踪文件	coderabbit review --include-untracked	同时包含尚未添加到 git 的文件
默认值（CLI v0.8+）：所有已跟踪的更改，基准分支 = 仓库默认分支，纯文本输出，本地审核策略。--include-untracked 可与 --uncommitted 配合使用，但不能与 --committed 配合使用；互相矛盾的范围会在审核开始前被拒绝。v0.7 移除了 --plain（直到 v0.9.0 都会报错：error: unknown option；v0.9.1 起又变成静默无操作）——纯文本本来就是默认值。`--type <all	committed	uncommitted> 从未被移除：--help中不显示它，但它仍会运行审核；与--committed/--uncommitted 同时使用时会报错（cannot be used with option '-t, --type '`）——请改用列出的标志指定范围。

本地审核会保留检查点（v0.7.7+）。 每次审核都会为其范围保存上下文——审核目录、分支和基准分支——同一范围的后续运行会复用这些上下文；--dir src 运行和整个仓库范围的运行会保留各自独立的检查点，更改基准分支会重置检查点，而失败的审核会保留上一次成功的检查点。文档称其为增量审核，但它并不会缩小报告范围：在本仓库中观察到（2026-09-30），同一分支上的第二次 --committed --base main 运行，在首次审核以零项问题通过的提交中报告了六项发现。请将每次运行都视为对整个范围的审核，并将一次通过视为一个样本，而非证明。--fresh（v0.8.2）会丢弃检查点，并在不使用已保存上下文的情况下审核该范围。

审核深度（v0.8）：--deep 会在本地运行完整的拉取请求审核策略——这是 CLI 最接近 PR 侧审核结果的模式。它仍受 CLI 自身的限制和计费规则约束，但不会关联已打开的 PR，也不会读取其描述和讨论，因此审核发现仍可能与 PR 侧审核不同。对于 CLI 是唯一审核途径（没有 PR 侧自动审核）的仓库，可在 PR 前的最终审核中使用它；在迭代修复循环中则继续使用默认策略。--deep "<focus>"（焦点文本）仅限早期使用。--light 已不在 --help 中显示，但仍会被接受，作为默认审核的旧版别名——它已不再让审核变得更轻，因此请从脚本中删除它。--deep 需要兼容的服务；如果服务拒绝该选项，请说明需要更新 CLI，而不要静默回退到默认审核。

其他审核选项：

• --gate <severity>（v0.9.1）——当评审发现严重程度达到或高于 critical、major、minor、trivial 或 info 的问题时，以状态码 2 退出；运行时还会重新评审所选差异，不使用已保存的检查点。不使用此参数时，退出代码会忽略发现的问题，因此它适用于 CI 或推送前的门禁：coderabbit review --committed --base main --agent --gate major。请查阅 --help；此处未实际测试。
• --use-credits——同意在本次评审超出包含额度时按用量计费（附加组件的 On demand 模式会要求提供此参数）。**这会产生费用：未经用户明确批准，绝不可在本次运行中传入此参数。**如果在 On demand 模式下运行超出额度，但未提供此参数，则不会产生费用：在 --agent 模式下，运行会以 action_required 记录结束（包含 status: "awaiting_confirmation"、计费文件数、最高价格以及准确的 --use-credits 命令）——请将这些信息转告用户。此同意仅适用于这些内容；任何更改都需要重新征得批准。
• --remote owner/repo --base main --source-branch <ref>（v0.7.7）——在 GitHub 仓库服务器端进行评审，无需本地检出；该仓库必须已安装到当前启用的组织中，且更改文件数少于 300。<ref> 可以是分支或完整的 40 位 SHA，不能是标签；本地选择参数（--dir、--committed、--uncommitted、--include-untracked、--base-commit）、--show-prompts 和本地 --config 文件均不适用，也不会存储任何内容以供 review findings 使用。
• -c, --config <files...>——本次运行使用的额外指令文件（例如 CLAUDE.md）。即使在 --committed 模式下，也会从磁盘读取这些文件；而评审内容和发现的 .coderabbit.yaml 会从 Git 快照中读取——因此，使用 --committed 测试配置更改之前，请先提交配置更改。
• --api-key <key> --region us|eu——在不存储密钥的情况下验证本次运行（无头模式/CI；请参阅 allowlist Caveat）。--region 仅在与 --api-key 一起使用时生效。

输出模式

• 默认（无模式标志）——提供详细的纯文本反馈和修复建议，并在结尾汇总严重程度，不进行交互。在检测到 Agent 环境时，会打印一条建议使用 --agent 的提示，但仍保持纯文本格式。
• --agent ——每行输出一个 JSON 事件（见下文“读取 --agent 输出”）。
• coderabbit review findings ——重放最近一次有发现的本地评审中缓存的发现（跳过无发现的会话），不进行新分析，且不消耗配额（--dir <path> 读取指定范围评审的缓存；每个范围最多保留十个会话，且不会过期）。可在各轮修复之间使用；最后只需重新运行一次实际评审进行验证。--clear（v0.7.7）会在当前范围（目录 + 分支 + 基准分支）内修复或驳回已保存的发现后将其清除，避免之后重放时再次出现；如果有些发现无法清除，它会以 1 退出（其余发现仍会被清除）。
• coderabbit review --show-prompts ——打印最近一次本地评审使用的 AI 提示词，不进行新评审。不能与 --agent 一起使用。
• coderabbit stats ——显示本地评审历史的统计信息（--rebuild 会重新扫描历史记录）。
• coderabbit usage（使用 --agent 时输出一个 JSON 事件；coderabbit --usage 和 coderabbit review --usage 是其别名）——自 v0.8 起，显示当前仓库包含的评审额度：滚动 1 小时窗口内的剩余额度与上限（includedReviews.remaining、.limit、.rollingWindowMs 和 .fullCapacityInMs，即额度池再次满额所需的时间）。它还会报告计费周期（billingPeriod）：组织、是否启用了按使用量计费（超额用量）（usageBillingStatus）、你的评审次数、截至目前按使用量计费的支出（spendCents），以及周期重置日期。每个区块都带有一个 state（服务器已响应时为 available）。v0.9.1 新增了共享评审支出上限（billingPeriod.reviewSpendingCap：scope、limitCents、isActive）和额度余额（reviewCredits.prepaid、.legacyCli）；如果任何区块无法读取，事件的 status 就会变为 partial——例如两个额度查询均为 unavailable（reason: "lookup_failed"），而其他所有区块均为 available。因此，请根据每个区块各自的 state 判断。开始本地循环前请先读取：此操作不消耗评审额度。输出不会指出当前通道，因此不能替代 @coderabbitai rate limit（见下文）来查询 PR 侧重试窗口。
• coderabbit pullrequest <number|url> ——读取 CodeRabbit 在 GitHub PR 上已有的输出：不运行评审，也不消耗额度。必须且只能指定 --show-threads 或 --show-prompts 其中之一。--show-threads --agent 会以 JSON 返回内联讨论串的根评论（讨论串和评论 ID、path/line、isResolved、isOutdated、头部提交）。--show-prompts 会返回一个整合后的修复提示词，其中还包含 Outside diff comments: 区块，这是仅检查讨论串的流程无法看到的内容。此操作需要 github.com，并且仓库已安装到当前活跃的组织中；它会根据本地 origin 解析不带前缀的编号，而完整 URL 即使不在检出目录中也可使用。讨论串处理和解决操作请使用 git-pr 技能。
• @coderabbitai rate limit ——不是 CLI 命令，而是 PR 评论，也是唯一可按需读取 PR 侧额度池的方式。它会报告剩余额度及下次可进行评审的时间，并且不会消耗评审额度（别名：rate-limit、limits、quota）。即使受到速率限制，也会在几秒内回复：“Your next review will be available in N minutes”——这是对该窗口唯一持久的读取方式，因为编辑到摘要评论中的通知可能会消失。开始循环前，以及触发后被拒时，都应发布此评论；不要通过触发评审来试探。它不消耗评审额度，但仍然是一条 PR 评论——属于写入操作，须遵循常规审批要求。

阅读 --agent 输出

逐行解析，并根据 type 分派。v0.9.1 还会在输出流之前向 stderr 打印一行关于 coderabbit skills 的 Tip:，因此请只读取 stdout；如果 shell 将两个流合并，则跳过不以 { 开头的行：

type	包含内容	用途
review_context	reviewType、currentBranch、baseBranch、workingDirectory；expectedDuration（v0.9.0）是一个句子，而非数字	估算等待时间：观察到“通常需要 2-6 分钟，最长可能需要 15 分钟”，提前停止命令会丢弃审查结果——请将其置于后台运行，并等待 15 分钟以上
status	phase、status	跟踪进度；review_skipped 表示该范围内没有更改
heartbeat	仅用于保持连接	重置空闲计时器；否则忽略
finding	severity（critical、major、minor、trivial、info、none）、fileName、codegenInstructions、suggestions、comment；title 和 startLine/endLine（v0.9.0）	按 codegenInstructions 修复（该内容面向编码 Agent 编写）；若没有，则使用 comment。在 v0.9.0 之前，只有 codegenInstructions 为空时才会出现 comment
complete	status、findings、outcome（完整运行时为 completed）、message、reviewedFiles，以及视情况提供的 unreviewedFileCount、reused、persistence	判断此次运行是否有效（规则如下）；reviewedFiles 显示此次运行实际覆盖的文件
error	errorType、recoverable、message、metadata	根据 errorType 分支处理，不要根据发现数量判断

1. 只有在退出码为 0，且 complete 事件显示 status: "review_completed"、没有 outcome: "failed" 且 unreviewedFileCount 不为正数时，运行结果才算干净。 从 v0.7.7 起，即使已经输出发现，失败或未完成的审查也会以 1 退出；而 review_completed 事件仍可能表示运行失败或跳过了文件。outcome: "completed_with_warnings" 且没有未审查文件时可以接受；status: "review_skipped"（findings: 0，退出码为 0）表示该范围内没有更改。使用 --gate（v0.9.1）时，退出码 2 表示审查已完成，且发现了达到或超过门槛的问题，并非失败。
2. 被限流会返回 error，而非空审查结果：退出码为 1，并返回 {"type":"error","errorType":"rate_limit","recoverable":true,"metadata":{"waitTime":"7 minutes"}}，且没有发现。等待 metadata.waitTime 指定的时间再加一分钟，然后重新运行一次——在等待期内重跑时，本地会返回相同的错误和剩余等待时间（本地等待上限为 15 分钟），因此循环重试毫无意义。--use-credits 会跳过本地等待，但会产生费用。
3. errorType: "interrupted"（v0.9.0，包含 elapsedSeconds）表示运行因信号而停止；已经输出的发现和最近一次成功的检查点都会保留——准备好后重新运行。
4. complete 上的 reused: true 表示服务端返回了现有审查结果——不能证明运行了新的审查。
5. persistence.status: "failed"（v0.9.0，包含 errorCode）表示结果未保存在本地：请保留此输出流中的发现，因为 review findings 可能无法再次返回这些发现，并检查本地存储权限和剩余空间。服务端的审查仍可能已完成。
6. 文件过多时会失败，并返回一个可能包含 candidates 的 error——其中列出可缩小范围的 --committed、--uncommitted 或 --dir 选项及其估算文件数——以及 candidatesNote。CLI 不会自行选择范围或重试：请选择一个范围并重新运行。
7. 安全问题发现会附带 category、CWE、可达性和可利用性。未经验证的发现会单独列出并计数，且不附带修复提示词：请检查这些发现，不要自动修复。按使用量计费的审查会附带 usageCost。

本地审核修复循环

1. 运行 coderabbit review --committed --base {base} --agent（或在提交前运行 --uncommitted）。将其置于后台运行——审核需要几分钟（v0.9.0 的 review_context.expectedDuration 会说明所需时间范围），提前终止命令会丢弃审核结果。
2. 解析发现的问题；按 severity 分类。优先处理 critical 和 major。
3. 根据代码库（编码规范、实际行为、项目文档）验证每项发现。按照 codegenInstructions 修复有效的问题；对于无效的问题，向用户提供一行理由。
4. 重新运行相同的审核命令以验证修复——它会再次审核整个范围，因此在未修改的代码上发现新问题是正常情况，并不代表出现回归。当一次干净的运行（参见 Reading --agent Output，第 1 条）不再留下有效的 critical/major 问题时，或用尽每小时额度时（coderabbit usage 会显示剩余额度；触发限流会报告等待时间——等待或停止，切勿反复尝试），即可停止。
5. 然后推送 / 创建 PR——要等更改全部完成后再进行，而不是发现的问题修复后就进行。如果启用了 PR 端自动审核和 auto_incremental_review（两者默认开启），推送就是审核请求，审核范围是分支当时包含的所有内容：剩余任务、测试、文档和配置都应包含在同一次推送中，否则每项遗留内容都会额外占用一次 PR 端审核额度。随后 PR 端的审核（如有）应当没有问题或只有少量问题。

提交修复时，应按它们带来的更改来命名，而不是按它们的起因命名——使用 fix: validate empty page cursor，而不是 fix: coderabbit fixes 或 fix: review round 2（参见 git-commit 技能）。修复不得添加重复说明代码已有内容的注释。

两轮（审核、修复、验证）是常见流程。超过三轮说明你把发现的问题当成了噪声——请重新评估其有效性或调整配置（参见 references/configuration.md）。

速率限制（每位开发者，每小时）

方案	CLI 审核	PR 审核	聊天	每次审核的文件数
Free	3	1（仅摘要）	--	150
OSS（公开仓库）	3	1--10，取决于仓库受欢迎程度	25	100--300，取决于受欢迎程度
Essentials（原 Pro）	5	5	50	150
Team（原 Pro+）	8	8	75	300
Advanced	10	10	100	300
Enterprise	12	12	100	300

方案 于 2026 年 9 月更名：Essentials 原名 Pro，Team 原名 Pro+，Advanced 为新增方案。运行配置区块会显示新名称。保留原有权益的 Pro+ 订阅仍享有每小时 10 次审核额度，尽管现在显示为 Team；旧版 Pro/Pro+ 订阅也仍沿用原有的限流阶梯。超出每小时额度后，按使用量计费的附加服务会按审核文件数收费：每个文件 $0.25（每个额度 $1，可审核 4 个文件）。如果 GitHub PR 超出方案的文件数限制，该服务也会覆盖最多 300 个文件的审核，即使每小时额度尚未用尽：CodeRabbit 会跳过自动审核，并提供 Review on demand using usage pricing 操作，选择该操作即表示授权收费。星标少于 10 个的公开仓库不会自动审核：每轮都需使用 @coderabbitai review（或 full review）启动，或者点击状态评论中的 Trigger review 按钮。 **试用期和席位。**试用期享有所选计划的额度（默认 14 天试用期：高级功能和额度，每小时 50 次聊天）。在初始订阅试用期内，超出额度的 PR 审查免费：CodeRabbit 会在首次超额审查时启用按用量计费的审查，除非管理员已选择 Off 或 On demand。席位按每位开发者每月计费：Essentials 每年计费为 $24，Team 为 $48，Advanced 为 $72（按月计费分别为 $30 / $60 / $90），Enterprise 则需报价。创建拉取请求的开发者会自动计费，管理员也可以将已购买的席位分配给指定开发者。聊天是单独的额度：在 CodeRabbit 审查线程中回复即可获得聊天答复，它不属于审查，也不会占用 PR 审查额度（git-pr 技能，references/bot-review-loop.md，线程中确认修复）。

表格中的数字是上限，而非实际可用速率——公平使用限流会将实际 PR 侧额度限制在该上限以下。补充速率取决于开发者在过去 24 小时或过去 7 天的滚动窗口中的近期 PR 审查数量；计划额度本身不会改变。文档列出的阶梯（按过去 7 天的审查次数计算）：

计划	全速率	逐步降至	每次降至 1 次/小时
Essentials	0--29 -> 5 次/小时	30--39 -> 4，40--49 -> 3，50--59 -> 2	60+
Team	0--39 -> 8 次/小时	40--49 -> 6，50--59 -> 4，60--69 -> 2	70+
Advanced	0--49 -> 10 次/小时	50--59 -> 8，60--69 -> 4，70--79 -> 2	80+
Enterprise（已加入）	0--59 -> 12 次/小时	60--69 -> 10，70--79 -> 5，80--89 -> 3	90+（1 次/小时）

Enterprise 保持每小时 12 次，除非合同加入自适应限额。已加入的阶梯仅适用于选择加入的新合同。它统计已交付的 PR/MR 审查（CLI 和 IDE 审查不计入），并在每个计费周期开始时重置计数器。在旧 Pro 计划上观察到的实际情况：在循环中途跨过一个档位，第 1 轮为每小时 4 次，两轮后降为每小时 3 次，随后又回升。在 Team 计划上，7 天内尝试 23 次仍可享有完整的每小时 8 次。

有两点影响。一周内大量审查会限制下一周的额度——起决定作用的是按天计算的窗口，而非小时；旧审查逐渐移出窗口后，容量才会慢慢恢复，而不是每小时重置。反复尝试不会收费，但也毫无意义：“被阻止的推送不会消耗审查额度，也不会延后下一次可进行审查的时间”，因为容量由此前已完成的审查决定；但被拒绝的轮次不会进入队列，因此在窗口关闭期间额外触发审查毫无用处。使用 @coderabbitai rate limit 进行探测（不会消耗审查额度），而不是反复触发审查——实时验证发现，连续两次碰壁后，显示的窗口关闭时间仍是最后一次已完成审查后 54 分钟，碰壁操作并未改变任何东西。（运行配置页脚写着“过去 7 天的审查尝试次数”，但文档中的阶梯统计的是审查次数；应以页脚中的数字为准，而不是它使用的名词。）

审查运行期间推送代码会丢弃该次审查，但额度仍会被扣除。CodeRabbit 审查的是分支头提交。如果审查仍在运行时有新推送，该次审查就会被取代，结果也不会到达 PR，但它已经计入额度。文档指出，在大多数项目中，一次审查需要五分钟以上，并举例说明：十分钟内提交并推送三次会“消耗三次审查额度，却只产生一次反馈”。GitHub 网页编辑器，以及 Update branch 和 Resolve conflicts 按钮都会创建提交，因此每次都会触发一次推送和一次审查。 超过包含额度后，按用量计费的附加服务会决定后续处理方式，具体取决于管理员设置的模式：Automatic 会继续审查并对超额部分计费；On demand 会暂停，直到某位席位持有者授权每次审查；Off 会停止，直到包含额度重置。只有 Automatic 是一种释放阀（此外，上文提到的初始试用期超额免费），而公平使用间隔是叠加在其上的独立机制。默认月度支出上限为无限制，直到管理员设置上限。

**你必须获知适用哪一行套餐信息，但实时额度可在两个地方查看：**每条已发布审查中的“Run configuration”区块会注明套餐和当前每小时审查次数（规划循环前，查看最近一次审查中的数值）；@coderabbitai rate limit 则会按需报告剩余额度和下次可用时间，且不会消耗额度。用户也可以查看 Web Review Usage 仪表板，其中会显示 CodeRabbit 上次为每位开发者观测到的自适应限额。其他地方不会显示套餐信息：coderabbit usage 会报告某个仓库的包含额度和计费周期，但不会报告套餐级别；PR 端 API 也从不提及套餐。请在仓库的 AGENTS.md/CLAUDE.md 中的 Code Review Policy（git-pr 技能）里声明，或为所有仓库进行全局声明：CodeRabbit plan: team until 2026-10-20, then essentials。这会影响实际行为：可以同时处于非草稿状态的 PR 数量、需要预留的轮次，以及应转由 CLI 流程处理的迭代量。试用期结束时请重新规划；针对每小时 10 次审查设计的队列，在每小时 5 次时会停滞。若未声明套餐，请根据观测到的行为（bot_bucket）确定下限，而不要假定情况最理想。

Bounce 何时会出现

在忽略自身信号的所有通道中，耗尽的配额桶都会被误认为是干净的结果。 每个通道都会报告这一情况——但绝不会显示为运行失败，也不会出现在大多数检查关注的字段中。请了解你所在通道的判断信号：

通道	Bounce 的表现	判断信号
CLI（--agent）	退出码为 1，且没有任何发现——从退出状态看与失败完全相同，而“没有发现”看起来像是干净的结果	{"type":"error","errorType":"rate_limit",...,"metadata":{"waitTime":"7 minutes"}} ——根据 errorType 分支判断，绝不要根据发现数量判断
CLI（默认输出）	运行结束时显示限流消息，且没有任何发现	阅读消息；不要把空结果当作通过审查
PR 侧	通常什么都没有——没有审查、没有讨论串、没有评论——此外还有一个未失败的 CodeRabbit 检查：状态为 neutral 的检查运行（配额桶为 skipping），或者在仍使用旧版提交状态的仓库中，显示绿色的 success	检查的判定内容为 Review rate limited：检查运行的 output.summary 第一行，或状态的 description。gh pr checks 会显示状态的 description，但不会显示检查运行的判定内容，因此请使用 bot_check（git-pr 技能）读取判定结果。Review completed 表示已完成审查；如果检查仍在运行，应等待，而不是再次触发

PR 侧这一行最容易误导人：检查列表中有一个未失败的 CodeRabbit 检查，夹在通过的 CI 作业之间，于是 PR 看起来像是已经审查过，但代码实际上根本没有被检查。由于 CodeRabbit 已将判定结果移至检查运行（默认使用 reviews.review_progress），遭拒的审查轮次至少会显示为 neutral / skipping，而不是绿色勾号；但 gh pr checks 会把被跳过的审查归入同一类别，且两者都不显示判定结果。文档称，遭遇限流的推送也会发布一条限流评论，并称其为权威信号。实际观察到的是，这条通知通常会编辑现有的摘要评论，而之后的演练编辑可能将其移除，因此检查的 description 才是持久可靠的读取方式。PR 侧的处理（时间窗口、重新触发、循环）位于 git-pr 技能中。

只有 PR 本身能告诉你 PR 侧的审查轮次何时可能重试——向它发送 @coderabbitai rate limit 询问。 周围还有三个徒劳的查询途径，别再浪费时间：

你可能查询的位置	实际会得到什么
coderabbit usage	仓库包含的配额（剩余量、滚动的 1 小时窗口、恢复满额所需时间），以及计费周期。它不会指出使用的通道，也不会给出 PR 侧的重试窗口
检查背后的 CI 日志	什么也没有：CodeRabbit 不运行任何 Actions 工作流。它的检查运行摘要是一张步骤表，带有指向 Web 应用的链接；旧版提交状态的 target_url 则为 null。可通过日志诊断的硬性限额问题属于 Copilot
PR 上的配额通知	针对单个 PR 的估算值，下一次摘要评论编辑就可能将其删除——同一名开发者的两个 PR 分别显示 48 分钟和 10 分钟，两者相隔 104 秒；与此同时，第三个 PR 的审查在 8 分钟后完成

真正能回答这个问题的是：一条 @coderabbitai rate limit 评论（剩余配额 + 下次可用时间，不消耗审查次数），以及你所有未关闭 PR 中最新的 Review completed，因为配额桶按开发者计算（git-pr 的 references/bot-review-loop.md 中的 bot_bucket）。如果另一个 PR 在你遇到 bounce 之后已完成审查，现在配额桶就已开放。

配置

仓库根目录下的 .coderabbit.yaml 同时管理 PR 侧和 CLI 审查（CLI 也接受 -c <file> 来加载额外的指令文件，例如 CLAUDE.md）。对于类型明确且经过充分检查的项目，目标是只提供高层次的问题发现：设置 profile、tone_instructions，禁用与 CI 重复的检查器，并通过 path_filters 过滤生成文件——每个 PR 自动审查一次（auto_incremental_review: false），后续轮次在审查讨论串中结束；对讨论串的回复属于聊天，而非审查。提交前，使用 coderabbit config validate [file] 验证修改（根据当前官方架构检查，并提供适用于 CI 的退出代码）。从 v0.7.7 起，coderabbit config 也可生成并应用配置（使用 --agent --generate --profile chill 创建提案）；如果不存在 YAML 文件，CLI 会查找 .coderabbit.config.ts。

参考：请参阅 references/configuration.md，了解完整的架构要点、配置优先级、适用于类型明确且经过检查的项目的低噪声模板，以及 PR 侧命令（@coderabbitai review 与 full review、暂停／恢复、配置转储）。

云端编码 Agent（coderabbit code）

测试版，v0.9.0（code handoff 和 code skills import 从 v0.8.1 起提供；v0.9.1 将 Autopilot 更名为 Autofix，并新增 goal 和 archive）。coderabbit code 会启动并跟进 CodeRabbit 编码 Agent 在云端执行的任务；每条指令作为一个轮次运行。任务会消耗 Agent 分钟数（定价页面显示每 Agent 分钟 $0.40），按网页应用任务的方式计费；如果组织尚未开始编码 Agent 试用，启动首个任务时便会开始试用。用户必须先通过浏览器登录，并使用 coderabbit auth org 选择组织：使用 API 密钥、自托管和 SSO 工作区登录都会因 unsupported_auth 而失败，且必须为组织启用编码 Agent。

命令	效果
code ls、code show <task>、code autofix status <task>	只读——可随时重新运行
code plan <task>	显示最新的最终版计划；--approve 记录审核者的批准（不能用于你启动的任务；不会启动实现）
code new "<prompt>"	启动一项计费任务，从 origin 上的分支开始——未推送的提交和未提交的更改不会包含在内。--plan 会在编写任何代码前先请求计划。v0.9.1：--goal 会以提示词作为目标，在目标模式下启动（--goal-objective 可单独设置目标），--private 会对组织其他成员隐藏任务，`--access manual
code goal <task>（v0.9.1）	读取目标；--set <objective>（1--4,000 个字符）设置目标，--clear 移除目标。编辑已完成的目标会重新启动任务
code resume <task>	跟进任务；使用 --agent、-m、--steer 或 --answer 可向任务发送消息，并启动或延长计费工作
code ask <task> "<question>"	计费的补充问题；绝不会更改任务
code cancel <task>	停止当前运行轮次；排队的消息不会执行——已推出队列暂停功能的任务会暂停（可从任务页面恢复队列），自动化任务则会丢弃消息
code archive <task>（v0.9.1）	在 ls 中隐藏任务，将其设为只读并暂停其计划任务。运行中、启动中或停止中的轮次必须先结束；重复执行也会成功，可取消归档任务，且不会取消或删除任何内容
code push <task>	将任务的更改提交并推送到其工作分支；--stacked 会改为创建拉取请求
code autofix on <task>（或 --pr <n>）	Autofix（原名 Autopilot；v0.9.0 中为 code autopilot，此后一直是别名）会在 Agent 完成后发布更改，然后针对 CodeRabbit 发现的问题、必需 CI 检查失败和合并冲突，自行推送修复；off 会停止 Autofix，resume 会重新启动已暂停的 Autofix
code handoff --summary <path>	将会话摘要、可选计划以及发现的 Codex 或 Claude Code 记录上传到新任务
code skills import [path]	将本地技能上传到云端库（--scope organization 会与组织共享技能）

通过 Agent 驱动：

1. 在命令名后立即传入 --agent（coderabbit code new --agent "<prompt>"，放在 --plan 前）。在检测到的 Agent 环境中，如果 stdout 通过管道输出，CLI 无论如何都会输出 JSON（Claude Code 下观察到此行为），但只有显式指定 --agent 才会将参数错误转换为 JSON。
2. 以最后一条记录为准——根据其 type 分支判断，再检查 status 或 action；退出代码可作交叉核验（0 表示完成，1 表示错误或登录／授权操作，3 表示有问题待回答，4 表示重新运行 resume——或者在运行 ask 后，到 Web 应用中读取答案）。第一条记录始终是 beta_notice 状态。
3. 写入提交点记录后，绝不要重新运行命令（task_submitted、creating_task、message_sent、steer_sent、answer_sent、question_sent）：重新运行会创建第二个计费任务或问题。请改用 coderabbit code resume --agent <task> 跟进任务，并传入明确的任务 ID，绝不要使用可能在不同运行间发生变化的 --last。
4. 执行以下操作前，先征得用户同意：push、plan --approve、autofix on／resume、goal --set／--clear、archive、cancel，或推送失败或已取消的轮次留下的更改。将 authorize_github URL、登录命令和敏感问题交由用户处理；绝不要自行打开或回答。如果 PR 端已开启自动审核，则每次 Autofix 或 push 向 PR 分支提交的提交，也会触发 PR 审核请求（git-pr 技能）。

参考：关于记录流、各命令的结果、安全的重新运行方式和等待时限，请参阅 references/cloud-tasks.md

关键注意事项

1. --committed 需要有提交，--uncommitted 需要工作树处于脏状态 —— 审查了错误范围会悄无声息地什么也不审查（review_skipped）；请根据检查点匹配范围。
2. coderabbit review findings 会重放结果，不会重新审查 —— 修复后仍会显示缓存的发现；只有全新的审查才能验证修复。它还会跳过干净的会话：即使验证运行结果干净，它也会重放较早的发现，这并不表示出现了回归。
3. 配额按小时计算，而不是按天计算 —— “已达到限制”意味着等待当前时段结束，而不是当天停止。安排验证运行时，要确保最后一轮能放进配额窗口。在 --agent 模式下，受限时会在退出时输出一行 rate_limit 错误，退出码为 1；仅凭退出状态无法将它与真正的失败区分开，而且检查发现数量时会把它读作干净结果。请根据 errorType 分支处理，并从 metadata.waitTime 获取等待时长。
4. CLI 审查和 PR 审查使用不同的配额池 —— 在本地消耗 CLI 审查次数不会减少 PR 侧的额度，这正是本地优先工作流的意义所在。
5. 组织上下文需要匹配的访问权限 —— 在未关联到你的 CodeRabbit 组织的仓库中，审查会以受限的免费模式运行（没有学习记录／组织上下文）；对同一份代码，结果会与 PR 侧审查不同。
6. --agent 输出的是 JSON 行，而不是 JSON 文档 —— 请逐行解析；不要对整个输出调用 JSON.parse。
7. --plain 取决于二进制版本；--type 和 --light 只是隐藏选项 —— v0.7 到 v0.9.0 会拒绝 --plain（error: unknown option，从 v0.8 起退出码为 1），而 v0.9.1 又会接受它，但它是隐藏的空操作选项，因此带有该选项的脚本可能在某次安装中通过，在下一次安装中失败。--type <all|committed|uncommitted> 虽然未显示在 --help 中，仍会运行审查；但与 --committed／--uncommitted 一起使用时会失败；从 v0.8 起，--light 仍会被解析为默认审查的别名，而 v0.9.1 会将已移除的 --prompt-only 作为 --agent 处理。请使用 --committed／--uncommitted，依赖默认的纯文本输出，并将 --deep 视为真正的深度切换选项。
8. PR 侧触发速率限制时不会报错，也不会失败 —— 不会进行审查，也没有讨论串，通常也不会留下评论；CodeRabbit 检查会显示 neutral（检查运行）或 success（旧版提交状态），结论为 Review rate limited。PR 上看不出任何异常，因此未审查的 PR 会被报告为已审查。在根据 PR 侧这一轮的静默结果得出结论之前，请先查看该结论（速率限制出现的位置）。
9. 引用的重试等待时长只是估算值，而且不会持久保留 —— 它会被编辑到摘要评论中，之后的编辑可能将其移除；与此同时，不同 PR 在同一时刻引用的数字可能差异很大。看到时就记录下来，取你各个 PR 中可见的最小值，并将同一组中的另一个 PR 显示 Review completed 视为真正解除限制的信号（速率限制出现的位置）。不要等你能找到的最大数字所示的时长。
10. 推送就是请求 PR 侧审查 —— 启用自动审查和 auto_incremental_review 后，每次推送都会从一个按开发者而非按 PR 计算的配额池中消耗一次 PR 侧审查，审查分支上的所有内容。请先在本地完成整个变更，再一次性推送；迭代应在本地通道（独立的配额池）中进行。关闭增量审查（参见 references/configuration.md 中的模板）后，修复时的推送不会消耗额度，而讨论串回复会用于验证修复。
11. 遭遇速率限制的尝试可能会让提交看起来像是已审查 —— 窗口重新开放后，对未更改的提交直接使用 @coderabbitai review 会得到“不会重新审查已审查的提交”的答复，导致这一轮悄无声息地始终没有发生；因此，解除限制后的恢复触发命令是 @coderabbitai full review。不过它并不总是生效：在此仓库中观察到，受限后的下一次推送会从最后一次已完成的审查处继续增量范围，并且会主动补审被跳过的两个提交。请查看审查自身的“Commits”区块，确认它实际审查的范围，不要预设结果。对于卡住的 “Review queued” 状态（观察到卡住超过 2 小时），也可使用同一强制形式；约 1 小时后就应提醒触发，而不是一直等待。
12. 一次干净的本地检查只是一个样本，不是证明 —— 每次运行的结果可能不同：在此处观察到，对未变更范围进行的第二次运行报告了六项发现，而第一次运行认为代码干净。请为此预留余量；如果有 PR 侧审查，就以它的最终结论为准。--fresh（v0.8.2）会在没有已保存检查点上下文的情况下进行审查。
13. coderabbit code 是计费的云端工作，不是审查（v0.9.0，beta）—— new、ask 以及通过 resume 发送内容都会消耗 Agent 分钟；push 和 Autofix（以前称为 Autopilot）会向仓库推送内容；handoff 和 skills import 会上传本地材料。在记录提交点后重新运行会重复产生计费工作。从 v0.8.0 起顶层的 handoff 只作为 code handoff 的隐藏别名保留。每次会更改状态的运行都需要批准（参见 references/allowlist.md）。
14. 通过 Homebrew 安装后既没有 cr，也不能自行更新 —— 该 cask 只会链接 coderabbit，而 coderabbit update 会转而执行 brew upgrade coderabbit（v0.9.0）。从文档中复制的 cr ... 命令会因 command not found 而失败；请写出完整名称。
15. 导出 CODERABBIT_API_KEY 不会完成任何身份验证 —— CLI 不会读取任何 API 密钥环境变量（v0.9.0 --help），因此在 CI 步骤中仅导出该变量，运行时会使用已保存的登录信息，也可能没有任何登录信息。请传入 --api-key "$CODERABBIT_API_KEY"，或在同一环境的较早步骤中通过 coderabbit auth login --api-key 保存密钥。
16. status: "review_completed" 不能证明审查已完成 —— 失败的运行或跳过部分文件的运行也可能以此状态结束。在将运行判定为干净之前，请检查退出码、outcome 和 unreviewedFileCount（读取 --agent 输出）。
17. Autofix 指两种不同的功能 —— 在 CLI 中，code autofix（v0.9.1）是以前称为 Autopilot 的循环，它会持续推送修复，直到 PR 准备就绪；在 PR 中，@coderabbitai autofix 是旧版别名，用于一次性执行 Fix comments 修复，而 Autofix 本身仍需通过 @coderabbitai autopilot 开启（参见 references/configuration.md）。请求用户批准时，请说出确切的命令，而不要只提功能名称。

参考：有关 .coderabbit.yaml 调优和 PR 命令，请参阅 references/configuration.md 参考：有关通过 Agent 驱动 coderabbit code 云任务，请参阅 references/cloud-tasks.md 参考：有关自动审批模式，请参阅 references/allowlist.md 参考：PR 端审查循环和线程处理：git-pr 技能（references/bot-review-loop.md）