Benchmark methodology · Sources checked

How to read Weave engineering benchmarks

Read the Weave Index without mixing the populations, units, or cost bases behind its metrics.

On this page

Dividing the Index's average AI cost per employee by its average code output per employee will not reproduce its cost-per-output ratio. The averages include employees with either spend or output; the ratio only includes engineers with both. The Weave Index publishes the definitions for each series so you can check who is included before combining the numbers.

Which people each metric includes

Scroll horizontally if needed →

MetricPopulation or denominatorUnit
AI cost per employeeEmployees with AI spend or engineering output in the monthMonthly attributed AI spend per employee
Code output per employeeAttributed employees with AI spend or code output in the monthEstimated expert hours per employee
Return on token spendEngineers with attributed AI spend and merged code output in the same monthTotal output divided by total attributed spend, in estimated expert hours per USD
AI cost per output hourThe same matched spend-and-output populationTotal attributed spend divided by total output, in USD per estimated expert hour
Token mix by model familyObserved token volume in the published monthShare of token volume, not share of people or organizations

The two spend-to-output ratios exclude ignored pull requests and spend that cannot be attributed to a person, such as organization-level overages. They do not cover the full company AI bill.

The matched cohort included 2,800 engineers in January 2026 and 9,151 in September 2026, according to the return on token spend methodology. The public snapshot does not list matched-cohort counts for the intervening months or monthly counts for the broader employee averages.

What an estimated expert hour measures

Weave measures output by estimating how long an expert engineer would need to complete a pull request. Silk 1 analyzes the change's intent, complexity, risk, and dependencies, and provides reasoning for the estimate. The code output measurement guide explains the scoring unit.

An estimate of three expert hours does not mean the author worked for three hours or saved three hours by using AI. It is a model's estimate of the work represented by that PR. You need other evidence to make a claim about time saved, payroll savings, or customer value.

How the spend-to-output ratios are calculated

Both ratios use the same monthly totals for the matched population:

  • AI cost per output hour: total attributed AI spend divided by total merged output, in USD per estimated expert hour.
  • Return on token spend: total merged output divided by total attributed AI spend, in estimated expert hours per USD.

For the hypothetical group in the AI ROI methodology's worked example, $1,200 of attributed spend and 300 estimated expert hours give $4 per output hour and 0.25 output hours per dollar. These are ratios of totals, not averages of each engineer's ratio. They are inverses when calculated from the same unrounded inputs; rounded chart values may not multiply to exactly one.

Despite its name, “return on token spend” is output per dollar, not a financial ROI percentage. The calculation does not assign a dollar value to the output or establish how much of it was caused by AI.

Missing records are not zeros

An engineer can have merged PRs but no observed spend because billing is not connected. Another can have spend but no observed output because their repositories are outside the connected scope. Requiring both signals keeps those missing records from entering the ratio as zeros.

That requirement also limits the result: the matched ratio describes engineers for whom both signals are observed. It does not describe all activity or all spending at their companies. The integration coverage page explains how account scope, repository access, and identity mapping affect those records.

Why the sample matters when comparing months

The Index summarizes Weave customer telemetry, not a randomized sample of the software industry. Its population changes over time. If a new customer with a different workload enters the sample, the aggregate can move even if every existing team's results stay the same. Changes in connected billing, repositories, and project mix can also affect the series.

The published series does not isolate those effects from changes within teams. For an internal before-and-after comparison, use the same people, repositories, cost sources, and follow-up windows where possible. Record staffing and workflow changes. Review the actual work and its quality before attributing an output change to AI.

Session results have their own definitions

The Q3 2026 report summary analyzes agent sessions rather than the employee populations above. It has its own eligibility rules and exclusions, including an excluded outlier.

A session not marked complete and merged may still produce work that merges later or lives outside connected repositories. It may also remain unclassified in the available data. Treating every such session as wasted would go beyond what the report observes. Comparisons with Q2 also need to account for each report's definitions, follow-up period, and exclusions.

Cite the metric you used

When quoting an Index number, link the metric page and include its unit, reporting period, population, and material exclusions. If you downloaded a CSV, include the snapshot date. Cite session findings to the report that defines them.

Only report uncertainty ranges or percentiles if the source analysis publishes them. A public average alone does not tell you where a particular team sits in the distribution.

Sources

Weave Index data and downloads

Each metric page includes its monthly series, calculation method, and a CSV download.

Browse the Weave Index