Measuring agent throughput: PRs merged, denial rate, and cost per PR

Measure coding agent throughput with two numbers read together: pull requests merged and denial rate, the share of pull requests closed without merging. Add cycle time from plan to merge and cost per merged pull request, and you have enough to tell whether agents are producing accepted work at a defensible price. Pull requests opened, the number most teams report first, is not enough on its own: an agent can open fifty pull requests a day that nobody merges, and that number will look like progress. This article defines each metric, says what a bad reading means, and shows how Ivy Tendril and a free calculator from Ivy track them.

The metrics

Metric	Definition	What a bad reading means
PRs opened	Pull requests created in the period	On its own, nothing. High and rising with flat merges means the agents produce work the team does not want
PRs merged	Pull requests merged in the period	Flat or falling while opened rises: review is the slowest step, or quality is dropping
Denial rate	PRs closed without merge, divided by all PRs closed (merged plus closed unmerged)	High: plans are wrong, verification is weak, or reviewers reject late. Near zero with low volume: only the safest work is being attempted
Cycle time	Time from plan creation to merge	Long: work waits at a human checkpoint. Find out which one
Cost per merged PR	Total tokens or dollars in the period, divided by PRs merged	Rising: retries, oversized plans, or an expensive model where a cheaper one would pass verification
Verification pass rate	Share of executions that pass tests, lint, and build on the first attempt	Low: plans are underspecified or the agent lacks context about the codebase

Two definitions need care. Denial rate uses PRs closed, not PRs opened, as the denominator, so that open pull requests still under review do not count as accepted or rejected. Cost per merged PR divides all spend, including spend on plans that were denied or abandoned, by merged pull requests only. That is deliberate: the cost of the denied work is part of the cost of the merged work.

Why PRs merged and denial rate are the honest pair

Any single metric can be improved by making a different metric worse.

• PRs opened goes up when you relax what gets executed. Denial rate goes up with it.
• PRs merged goes up when reviewers approve faster. Defects found after merge go up with it, and denial rate goes down for the wrong reason.
• Denial rate goes down when you execute only the safest plans. PRs merged goes down with it.

PRs merged and denial rate read together resist this. To raise merged without raising denial, you have to produce more work that the team accepts. To lower denial without lowering merged, you have to fix plans or verification rather than execute less. Neither number can be improved by ignoring the other.

The reason PRs opened is tempting is that it is the first thing an agent produces and the easiest to count. But an opened pull request is a request for someone's time. Counting requests as output rewards the agents for making work for reviewers. Counting merges rewards them for finishing it.

Ivy publishes its own data this way. The PRs-per-day vs denial-rate chart on the Why Ivy page is built from 1,946 pull requests across Ivy repositories from February to April 2026. Ivy reports that its team went from roughly 10 to more than 100 pull requests per day after adopting the plan, execute, verify, review workflow it calls a software factory. The volume number is shown next to denial rate because on its own it would prove nothing.

Cost per merged PR and verification pass rate

Once merged and denial are in place, cost per merged pull request tells you what the accepted work costs. This is the number a CTO is asked for, and it has to be in dollars or tokens per merged change, not per plan or per execution, so that retries and denied work are included.

Three things move cost per merged PR:

1. Retries. Each failed verification is a rerun. Verification pass rate is the leading indicator; when it falls, cost per merged PR rises a few days later. Verification gates covers what to check and why the plan gate matters most.
2. Plan size. Large plans cost more per execution and are denied more often, because a reviewer finds more to object to. Splitting a plan into smaller ones usually lowers both denial rate and cost per merged PR, at the price of more pull requests to review.
3. Model choice. A cheaper model that passes verification at the same rate is a direct saving. The only way to know is to track cost and pass rate per plan and compare across models on the same codebase.

For the wider shift from measuring developer activity to measuring accepted output, see In the loop, out of the loop: the KPI shift behind agentic engineering.

How Ivy Tendril tracks these numbers

Ivy Tendril is a local-first desktop application (macOS, Windows, Linux) that runs coding agents from plan to reviewed pull request, and it records the data for every metric above as a result of running the workflow. Nothing has to be instrumented separately.

• Dashboard. The Dashboard shows plan status across the lifecycle, cost KPIs, a trend chart over time, and git activity for the connected repositories. Plan status gives you PRs opened, merged, and denied; git activity gives you the merge history.
• Cost per plan and per job. Tokens and cost are tracked for every plan and for every job within a plan. A plan that needed three execution jobs before passing verification shows all three, so cost per merged PR includes the retries by construction. The Jobs surface shows each job's streaming output and tool calls alongside its cost.
• Per-agent and per-model comparison. Tendril runs Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode, and any other CLI agent, and the agent or model is chosen per plan. Cost and pass rate can therefore be compared across models on the same codebase without changing the workflow.
• Local data. Plans, logs, and cost records stay on the machine. The only external calls are to the model API you configure and to GitHub.

For teams not yet running Tendril, Ivy publishes a free, open-source PR Cost Calculator. It reads public GitHub data for a repository and computes 14-day rolling PRs merged and denial rate, so a team can record its baseline before changing anything. Run it on your repository today, and again a month after introducing agents.

How to start

1. Get the baseline. Run the PR Cost Calculator on your main repository and record 14-day PRs merged and denial rate.
2. Install Tendril: curl -sSf https://cdn.ivy.app/install-tendril.sh | sh (macOS, Linux) or irm https://cdn.ivy.app/install-tendril.ps1 | iex (Windows). Docs at installation.
3. Run plans for two weeks and read the Dashboard: merged, denied, cost per plan, trend.
4. Compute cost per merged PR by hand once, dividing total spend by merged count, so the team agrees on the definition before it becomes a reported number.

Tendril is free and source-available under the Functional Source License. Team features, on-prem hosting, SSO, and CI verification imports are on the Pro ($59 per user per month) and Enterprise plans.

Frequently asked questions

What is a good denial rate?

There is no universal target, and a rate of zero usually means nothing with any risk is being attempted. Track your own rate over time and treat a rise as a signal to look at plan quality and verification, not as a number to lower by executing less.

Should cost per merged PR include human review time?

Include it if you can measure it consistently. Most teams start with tokens or model spend because that is recorded automatically, then add reviewer time once the definition has settled. Mixing the two before agreeing on the method makes the number hard to compare month to month.

How do these metrics differ from DORA metrics?

They overlap. Cycle time from plan to merge is close to lead time for changes. Denial rate has no direct DORA equivalent, because DORA assumes a human wrote the change and asks whether it deployed. Denial rate asks whether the change was accepted at all, which becomes the more useful question when agents produce the candidates.