Summary
On a run resumed from existing enhance checkpoints, the progress display reported an ETA about 25× too optimistic.
Evidence
Resuming with 130 of 1,351 units already checkpointed, the first progress line read:
Restored 130 already-processed units from checkpoints units=130
Enhancing 1221 units with agentic analysis (130 already done)
[Enhance] 131/1351 … (elapsed 24s, ETA ~3m40s, …)
The phase actually took 1h16m. The estimate divides total elapsed time by the cumulative completed-unit count, including checkpoint-restored units that consumed no time in this process — so immediately after resuming it infers an enormous throughput.
Suggested fix
Compute the rate from units processed in the current session rather than the cumulative count.
Observed on one full-pipeline run at production scale: a private TypeScript monorepo (Angular front end, NestJS back end), 1,351 analysis units from 866 source files, run with --verify and no --limit, ~6.5 hours wall clock. The engine was invoked directly (python -m openant scan …, Python 3.13); the Go CLI was not built, so none of this involves the Go↔Python envelope. Stage 1 detection and Stage 2 verification ran on Claude Opus 5; application context, enhancement and reporting on Claude Sonnet 5 — all seven phases routed through OpenRouter (anthropic/claude-opus-5, anthropic/claude-sonnet-5) via a locally-added openrouter provider adapter, on a build based on upstream 2ed78f6. Cost figures are expressed as proportions of the run total; absolute amounts are omitted deliberately, as is the identity of the scanned repository.
Summary
On a run resumed from existing enhance checkpoints, the progress display reported an ETA about 25× too optimistic.
Evidence
Resuming with 130 of 1,351 units already checkpointed, the first progress line read:
The phase actually took 1h16m. The estimate divides total elapsed time by the cumulative completed-unit count, including checkpoint-restored units that consumed no time in this process — so immediately after resuming it infers an enormous throughput.
Suggested fix
Compute the rate from units processed in the current session rather than the cumulative count.
Observed on one full-pipeline run at production scale: a private TypeScript monorepo (Angular front end, NestJS back end), 1,351 analysis units from 866 source files, run with
--verifyand no--limit, ~6.5 hours wall clock. The engine was invoked directly (python -m openant scan …, Python 3.13); the Go CLI was not built, so none of this involves the Go↔Python envelope. Stage 1 detection and Stage 2 verification ran on Claude Opus 5; application context, enhancement and reporting on Claude Sonnet 5 — all seven phases routed through OpenRouter (anthropic/claude-opus-5,anthropic/claude-sonnet-5) via a locally-addedopenrouterprovider adapter, on a build based on upstream2ed78f6. Cost figures are expressed as proportions of the run total; absolute amounts are omitted deliberately, as is the identity of the scanned repository.