AI Coding ROI Calculator

A credible ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in. Press Enter for the full definition. model starts from inputs you can defend later. Move the controls to match your team, then check the result against what you actually spend and ship.

Two inputs decide whether anyone believes this model. First, the hourly cost you put on developer time — fully loaded, not salary divided by 2,000, or the savings come out roughly twice as good as they are. Second, review time, which people leave out because it's harder to measure and, I suspect, because including it makes the number smaller. Leave it out anyway and the first finance person to open the model will find it.

State the costs you would rather not show. A business case that hides review time or model spend will not survive contact with finance.

• Sample size, repo type and task mix.
• Models, tool versions and seat cost used.
• Review time added by AI-generated changes.
• Where the result should not be generalized.

Cursor ships often, so here is the current state of the surfaces this page touches. Each row links to the source where you can confirm the detail.

At the accepted-change rate. In the model above, that percentage multiplies the value side and touches nothing on the cost side, so a change you rejected is worth nothing and costs nothing. In your actual week it cost a reviewer's attention.

The effect, really, runs backwards from what you would want. The lower your acceptance rate, the more generous the model becomes, because rejected work leaves the arithmetic instead of showing up as waste.

The workaround is to price rejection into the review-time slider rather than the acceptance one.

Set review time added to the reviewer hours you spend on everything the agent produced, not only on the parts you kept. The acceptance percentage then does the job it should, which is to scale the value of the work that survived.

Review time is the contested input, or it has been every time I have watched this argued. It is the only line an optimist will try to talk down towards zero, and it sits directly against the hours-saved figure, so a small edit there swings the result more than anything else on the panel does.

Only if your bill is seats alone. The model's cost side is seats times per-seat cost, while Cursor Teams billing is seat plus usage: each Standard or Premium seat includes monthly usage across a first-party model pool and a third-party API pool, and usage beyond those included pools continues on demand, billed in arrears. Cursor pricing explained has the current shape of it.

So put a blended number in the slider. Seat price plus your trailing month of on-demand usage, divided by seats. If you have not run a full month yet then you are estimating both halves, and the slide should say so rather than imply a measurement.

One more wrinkle, and it is a limit of the control rather than of the method. The tool-cost slider stops at $80 per seat. A Teams Premium seat is $96 per seat per month on annual billing and $120 month to month, so if you are modelling a Premium group the slider cannot reach the price. Model that group as its own run instead of folding it into an average that hides them.

Check both figures at cursor.com/pricing before anything goes into a budget. They move, and this page is a model rather than a price list.

Below roughly ten engineers, skip it. The output is dominated by two guesses, hourly cost and hours saved, and a two-week trial with a decision rule written down in advance will settle the question faster than a model that can be tuned to produce any answer you like.

Past fifty seats it flips, because the number stops being for you. Someone in finance is going to read it, and what survives that reading is not the ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in. Press Enter for the full definition. percentage. It is whether each input traces back to something you measured.

So save the inputs with the result. Seats, blended tool cost, hourly cost, hours saved, review time, acceptance rate, and the date you set them. A model whose assumptions cannot be reconstructed in three months is a screenshot, not a business case.

Saving them is not quite enough on its own. Put a name against each number as well, because the input that gets challenged six months out is usually the one whose owner has moved teams, and by then nobody can say whether it was measured or guessed.

Then run it again after a quarter with the acceptance rate you actually observed. That second run is the only version of this number I would act on twice, and it is usually the one nobody schedules.