OpenCodeReview Version
v1.7.13
Operating System
macOS (Apple Silicon)
Installation Method
npm (global)
LLM Provider
Anthropic (Claude)
Bug Description
我们在实际接入 open-code-review 的过程中，遇到一次大 MR 场景下的成本异常。
这次异常不是由消息重复消费导致，也不是 review 任务被重复重试导致。实际情况是：某个较大的私有 MR 进入 open-code-review 后，流程在超时前进行了大量搜索、读取文件和模型请求，产生了非常高的 token 消耗。
随后 open-code-review 超时/失败，外层调用方 fallback 到其他 review runner，最终 review 有结果，但 open-code-review 失败链路中的成本已经实际产生。
脱敏后的本地日志里，观察到：
- 覆盖文件数：约 308 个
- 内部工具调用：约 2612 次
- 单次失败的 open-code-review 尝试产生约 90,433,182 token（9000多万）
- 其中 input_tokens 约 89,543,960，output_tokens 约 889,222
- 该次尝试耗时约 1h12m，随后超时/失败并 fallback
- 失败发生在 open-code-review 编排/执行链路上；在失败前，模型调用成本已经产生
这类失败链路会产生较大实际成本；如果外层只统计最终 fallback 结果，很容易漏掉这部分消耗。
Steps to Reproduce
由于涉及私有仓库，无法提供原始 MR 或代码内容。脱敏后的复现条件如下：
- 准备一个较大的 MR，变更文件数达到数百级。
- 使用 open-code-review 对该 MR 执行 review。
- review 过程中允许 agent 式搜索、读取文件和生成评论。
- 在缺少 token / 请求数 / tool call / 执行时长护栏的情况下，流程可能持续展开。
- 最终 open-code-review 超时或非 0 退出。
- 如果外层调用方 fallback 到其他 runner，最终 review 可能成功，但前一次 open-code-review 的 token 成本已经产生。
Expected Behavior
希望 open-code-review 可以提供内置的成本与规模护栏，特别是大 MR 场景：
-
Review 前规模预检
- 变更文件数
- diff 行数
- 预计输入规模 / token 估算
- 超过阈值时拒绝、降级或要求确认
-
运行时预算护栏
- 单次 review 最大 token 数
- 单次 review 最大模型请求数
- 单次 review 最大工具调用数
- 最大执行时长
- 单文件 / 单 agent loop 最大展开次数
-
超限后的安全退出
- 达到预算上限后主动停止
- 尽可能返回部分结果
- 明确标记 partial / budget_exceeded / timeout 等状态
-
失败时也输出结构化 usage 信息
即使 open-code-review 超时或失败，也希望能输出一份结构化 usage manifest，包含：
- 模型请求数
- input_tokens / output_tokens / total_tokens
- 工具调用次数
- 覆盖文件数
- 耗时
- 退出原因
- 是否 partial
- 是否 budget exceeded
这样外层系统可以准确记录失败尝试产生的成本，而不是只看到 fallback 后的结果。
Logs / Error Output
reviewed_files: ~308
internal_tool_calls: ~2612
total_tokens: ~90,433,182
input_tokens: ~89,543,960
output_tokens: ~889,222
elapsed: ~1h12m
result: timeout / non-zero exit
follow-up behavior: caller fallback to another review runner
未观察到消息重复消费或任务重试风暴。问题主要出现在单次 open-code-review 运行过程中的 agent 式展开。
Additional Context
这个反馈主要是希望增强大 MR 场景下的成本可控性和失败链路可观测性。
建议支持类似以下配置，示例值仅供参考：
max_total_tokens: 1000000
max_model_requests: 300
max_tool_calls: 500
max_changed_files: 100
max_elapsed_seconds: 900
large_mr_policy: fail | warn | require_confirmation
emit_usage_manifest_on_failure: true
这些配置可以让实际接入方在大 MR 场景下更安全地启用 open-code-review，避免一次异常展开造成不可控成本。
OpenCodeReview Version
v1.7.13
Operating System
macOS (Apple Silicon)
Installation Method
npm (global)
LLM Provider
Anthropic (Claude)
Bug Description
我们在实际接入 open-code-review 的过程中，遇到一次大 MR 场景下的成本异常。
这次异常不是由消息重复消费导致，也不是 review 任务被重复重试导致。实际情况是：某个较大的私有 MR 进入 open-code-review 后，流程在超时前进行了大量搜索、读取文件和模型请求，产生了非常高的 token 消耗。
随后 open-code-review 超时/失败，外层调用方 fallback 到其他 review runner，最终 review 有结果，但 open-code-review 失败链路中的成本已经实际产生。
脱敏后的本地日志里，观察到：
这类失败链路会产生较大实际成本；如果外层只统计最终 fallback 结果，很容易漏掉这部分消耗。
Steps to Reproduce
由于涉及私有仓库，无法提供原始 MR 或代码内容。脱敏后的复现条件如下：
Expected Behavior
希望 open-code-review 可以提供内置的成本与规模护栏，特别是大 MR 场景：
Review 前规模预检
运行时预算护栏
超限后的安全退出
失败时也输出结构化 usage 信息
即使 open-code-review 超时或失败，也希望能输出一份结构化 usage manifest，包含：
这样外层系统可以准确记录失败尝试产生的成本，而不是只看到 fallback 后的结果。
Logs / Error Output
Additional Context
这个反馈主要是希望增强大 MR 场景下的成本可控性和失败链路可观测性。
建议支持类似以下配置，示例值仅供参考：
max_total_tokens: 1000000
max_model_requests: 300
max_tool_calls: 500
max_changed_files: 100
max_elapsed_seconds: 900
large_mr_policy: fail | warn | require_confirmation
emit_usage_manifest_on_failure: true
这些配置可以让实际接入方在大 MR 场景下更安全地启用 open-code-review，避免一次异常展开造成不可控成本。