GUIDE
The AI Cost of Analyzing Pull Requests
What it would cost in LLM tokens to analyze GitHub or Azure Repos pull request activity with AI instead of SQL aggregation.
What this covers
Lead time for changes — one of the 4 DORA metrics — is computed from pull request timestamps: when a PR opened, when it merged. moasy.tech does that with a direct aggregation query (average, median, sample size) over synced PR data. An LLM-based alternative would read each PR event and reason about it — is this the right merge to measure lead time from, does it correlate with a deploy — instead of a plain calculation.
The math
A 5-engineer team merges roughly 27 pull requests a month. Each analysis call costs an estimated USD 0.0125 (cheap-tier model) to USD 0.125 (frontier-tier model) — see the full method for how that per-event cost is built.
| Teams | PRs merged/mo | Estimated AI cost/mo |
|---|---|---|
| 1 | 27 | USD 0.34 – 3.38 |
| 5 | 135 | USD 1.69 – 16.88 |
| 7 | 189 | USD 2.36 – 23.63 |
How moasy.tech does it instead
Lead time for changes is a direct Postgres aggregation over merged PR timestamps — average, median and sample size, recalculated as new PRs sync in, at zero per-computation cost. See the full implementation on the DORA Metrics feature page, or the full cost comparison, with a calculator, for every integration category combined.
Questions about this estimate
Does this include open, unmerged PRs?
The volume assumption (27/mo for 5 engineers) counts merged PRs, matching how moasy.tech's own lead-time calculation is scoped. Open and abandoned PRs would add to the total if an AI-based tool chose to process them too.
Why is the PR category cheaper than the deploy category?
Purely volume — this estimate assumes fewer merged PRs per month than deploys, since elite CI/CD teams often deploy more than once per merge (redeploys, config-only changes). See the deploy cost breakdown for that category on its own.