ocr审查耗时问题

[Yan-nh]

最近在执行ocr审查时候，发现耗时非常慢。
比如一个100行的代码变动，ai coding估计就1min不到，但是ocr审查经常10min+以上，甚至有一直没等到结果的情况。
请问这是正常现象吗？
我尝试更换模型，glm和ds都会有这个现象，但如果我换成opus的模型，时间就较为正常。
我想问的是：
1.ocr的审查耗时，目前比较正常的时间范围是多少？
2.如果出现频繁耗时较长的情况，除了换底层模型外，有什么其他的建议？毕竟高级模型审查，有费用的担忧。。

[lizhengfeng101]

不太正常，可以关闭模型的思维链，以及设置 effort low，如果设置方面有疑问，可以拉取代码库问题下 AI

[ZombieSouls]

🐛 [Performance] macOS + Claude Code + GLM-5.3-Flash OCR Code Review 耗时异常 (8~40min)

环境配置

项目	值
OS	macOS 15.x
Chip	Apple M1 Max (32GB)
Claude Code	[填写版本号]
Model	GLM-5.3-Flash
Open Code Review	[填写 commit/tag]

问题描述

在上述配置下执行 Code Review，OCR + LLM 推理总耗时严重超标：

• 平均耗时: >8 分钟
• 峰值耗时: ~40 分钟
• 用户体验: 长时间无任何进度反馈，极易误判为进程挂起/死锁

耗时与 Token 消耗实测

以下为刚才单次评审的实际运行数据：

图1: 总耗时统计 (可见本次评审耗时 XX 分 XX 秒)

图2: Token 消耗明细 (Input: XX tokens, Output: XX tokens)

预期 vs 实际

指标	预期	实际
单次评审耗时	< 2 min	8 ~ 40 min
进度反馈	有阶段性输出	完全静默，UI界面在运行中显示状态是：aborted

补充信息

• 已确认网络连接正常
• 相同文件使用claude code直接code review, 耗时<3min

[ZombieSouls]

分享：

1. 当执行命令不加“ --effort low”参数时，会耗时很久---31m46s ：
   ocr review --audience agent --model "${ANTHROPIC_MODEL%[}"
   -B /Users/zombie/IdeaProjects/avc/dcpp/.superpowers/sdd/ocr-t13-final-bg.md
   --exclude '/WashComplementController.java,/IWashComplementService.java,/WashComplementServiceImpl.java,/WashComplementMapper.java,/WashComplementMapper.xml,/WashExamineMapper'
   
   --repo /Users/zombie/IdeaProjects/avc/dcpp
   --timeout 25
   -o /Users/zombie/IdeaProjects/avc/dcpp/.superpowers/sdd/ocr-t13-final-g3.txt

2. 加了重跑一次，耗时：14min

3. 指定effort等级有效，分析了ocr源码，还没发现其他调优参数；p.s. effort调最低会让我焦虑

[basil-k-aji-dev]

@ZombieSouls's measurement (31m46s → 14min with --effort low) is the key data point here, and the source explains it exactly.

1. Where the time goes: review rounds.

--effort is not a vague hint — it maps to one number, MAX_REVIEW_ROUNDS (internal/config/template/effort.go:35-37):

EffortLow:    {MaxReviewRounds: 1},
EffortMedium: {MaxReviewRounds: 2},   // the default
EffortHigh:   {MaxReviewRounds: 3},

The default is medium, i.e. two full review passes per group. Roughly halving the wall clock when you drop to one round is the expected shape, not a coincidence. So a 100-line change is never "one LLM call" by default.

There is no published normal range, and there cannot be a meaningful one — total time is rounds × groups × per-request latency, and that last term is the provider's, not OCR's. That is also why Opus felt fine while GLM/DS did not: the round count was identical, the per-request latency was not.

2. Knobs other than switching model.

• ocr config set effort low persists it, so you do not retype it. Verified — it writes {"effort":"low"} to ~/.opencodereview/config.json. You can still override per-run with --effort.
• --no-filter skips the post-review LLM filtering pass (agent.go:1789). That is a whole LLM call per group removed, at the cost of noisier output.
• --concurrency (default 8) — if you are reviewing many groups and your provider tolerates it, raising this shortens wall clock without changing cost.
• --max-tokens / --max-tokens-budget bound prompt size and total spend.

3. On @lizhengfeng101's "turn off the chain of thought" — the mechanism is llm.extra_body, which is merged into every request body (client.go:353):

ocr config set llm.extra_body '{"...":"..."}'

The exact field is your provider's, not OCR's, so use whatever that endpoint documents for disabling reasoning. One OCR-specific note: for the Anthropic protocol OCR reads extra_body.thinking.budget_tokens directly (client.go:1238), so that path is understood rather than just forwarded.

4. A correction on the command in that report — --timeout 25 is not what it looks like.

--timeout int   concurrent task timeout in minutes (default 15)

It bounds a concurrent task, not an LLM request. The per-HTTP-request deadline is the provider's timeout_sec (default 5 minutes when unset). So raising --timeout will not stop a slow provider call from timing out, and lowering it will not make anything faster. That mismatch is already tracked in #1155.

5. The "aborted" status was not a hang. The web viewer showing aborted while a review is still running is a known bug — #847, with #848 open against it. Worth knowing before you kill a run that is actually progressing.

So, concretely: set effort low in config, add --no-filter if you can tolerate extra comments, and put your provider's disable-reasoning field in llm.extra_body. If it is still 8+ minutes after that, the remaining time is per-request provider latency, and only the model/endpoint choice moves it.