Progressive overload with RIR: how the Kaizer engine works

Progressive overload with RIR is a simple idea with annoying arithmetic. Simple: if your client had reps left, the load can go up; if they hit failure, it cannot. Annoying: for twenty clients, three exercises per session and four sessions a week, that is two hundred and forty calculations someone has to do every week. This article shows exactly what that calculation is, with one client and one bench press, the way the Kaizer engine does it.

A program on fixed percentages of 1RM assumes the client's max is the same on Monday as it was six weeks ago, when it was tested. It is not: it rises with training and falls with a week of bad sleep. RIR corrects that session by session. Helms and colleagues (2016) proposed the reps-in-reserve-based rating of perceived exertion precisely because it connects what the client felt to a percentage of their current max, without testing it.

The relation that bridges the two is well known: a set ending with a given number of equivalent reps (done plus in reserve) corresponds to a fraction of 1RM. Eight reps to failure sit around 80%; twelve, around 70%. The NSCA charts summarise it as coefficients, and that table is what the Kaizer engine uses in both directions: to estimate the max from what the client did and to go from the max down to the load they are due.

Take a client with bench press at three sets of 8, RIR 2 prescribed, minimum increment 2.5 kg. They log 60 kg on all three sets, 8 reps each, and when the exercise ends the app asks how many they had left: they answer 4. Easier than planned.

Step one: the engine summarises the session. It averages the weight of the completed sets (60 kg), averages the reps rounding down (8) and takes the exercise's RIR (4). Step two: it adds reps and RIR, 12 equivalent reps, and looks up the coefficient in the table: 0.70. The estimated 1RM is 60 divided by 0.70, that is 85.7 kg. If the client had earlier executions of the exercise within the last 56 days, the engine would average the 1RM of the last three, so a single exceptional session does not move the whole prescription. It is their first time, so 85.7 kg rules alone.

Step three: the following week prescribes 8 reps at RIR 2, that is 10 equivalent, coefficient 0.75. The raw weight is 85.7 times 0.75: 64.3 kg. Step four: 64.3 kg does not exist on the floor. The engine compares it with the previous week's actual weight, 60 kg, divides the 4.3 kg gap by the 2.5 kg increment and keeps whole increments, rounding down: one. Week 2 lands on 62.5 kg for 8 at RIR 2. The 1.8 kg left over is discarded, not carried.

Step five: if week 3's template asks for RIR 1, that is 9 equivalent, coefficient 0.77, raw 66.0 kg. The reference is now week 2's target, 62.5 kg. A 3.5 kg gap, one whole increment: 65 kg for 8 at RIR 1. The weight goes up twice without anyone opening a spreadsheet, and it goes up because the client said they had four left, not because the calendar said so.

Change one input: the client reports RIR 3 instead of 4. Now it is 11 equivalent reps, coefficient 0.725, 1RM 82.8 kg. Week 2's raw weight is 82.8 times 0.75: 62.1 kg. The gap to the 60 kg reference is 2.1 kg, less than a 2.5 kg increment. The weight does not move.

This is where most programs stall and where the engine does double progression: since the weight stays at 60 kg, the rep target goes up. It takes the previous week's total effort, 8 done plus 3 in reserve, adds one and subtracts the template RIR: 8 + 3 + 1 − 2 = 10. Week 2 lands on 60 kg for 10 at RIR 2. The client still progresses, in reps, until the arithmetic justifies the next plate.

That is not a concession, it is what the evidence suggests. Plotkin and colleagues (2022) compared, in PeerJ, eight weeks of load progression against rep progression in trained subjects and found comparable hypertrophy gains. Progressing in reps counts as progressing; what does not count is repeating the same week six times.

RIR is an estimate and estimates have error. Steele and colleagues (2017) showed that the ability to predict how many reps remain to failure is not perfect and improves with experience; a beginner tends to underestimate what they have left. The engine does not correct for that, and it is worth knowing how it behaves at the edge: if the client does not report RIR, or the question is turned off for them, the calculation uses 0. It assumes the set went to failure, the 1RM comes out lower and so does the next load. It is the most conservative reading, not the most optimistic.

That is why the controls sit with the coach. The RIR question switches on or off globally and client by client. So does automatic progression. And any week you edit by hand leaves the engine for good: the load moves on its own in the weeks you did not touch and stops the moment you touch them. What the engine does not do, and will not do, is decide a deload, cut sets or read that the client is coming back from an injury. That is the half that is still yours.

Everything above, the whole coefficient table, the three-session averaging rule, the secondary-exercise case and the limits of the method, is written on the page on how load adaptation works, with the date it was checked against the code. If a number in this article does not match that page, the page wins.

Progressive overload with RIR does not need faith. It needs someone to do the arithmetic every week, for every client, and you to keep the decision of when not to.