Who Decided R-hat Had to Be 1.01?

Open a recent PyMC model with one awkward parameter and you may see a very specific warning:

That number feels oddly precise. Why 1.01? Why not 1.1, which many people learned from older books, blogs and Stan-era folklore? Why do some packages still use 1.05, while others are looser still? And if one nuisance parameter lands at 1.02, did the whole posterior suddenly become unusable?

This post is the answer, but in a format you can skim.

Convergence in 60 seconds

If you only remember one idea from this whole article, make it this one:

That matters because MCMC draws are only useful if the sampler is actually spending time in the right parts of the posterior. If different chains disagree about where the posterior is, or one chain is still drifting, any summary you compute from those draws can be misleading.

What R-hat asks

R-hat compares two things:

• within-chain variation: how variable each chain is by itself;
• between-chain variation: how different the chains are from one another.

If the chains are all sampling the same stationary target, those two stories should broadly agree. If not, between-chain variation stays inflated and R-hat rises above 1.

What R-hat does not guarantee

R-hat is useful, but humble.

• It does not prove the model is correct.
• It does not prove the sampler found every mode.
• It does not mean a parameter at 1.02 is either automatically fatal or automatically fine.
• It does not replace divergences, ESS, MCSE, rank plots or posterior predictive checks.

So yes, it is important. No, it is not magic.

The formula, without the pain

Suppose we have M chains and N post-warmup draws per chain. For some scalar posterior quantity, define:

• W: the average within-chain variance
• B: the between-chain variance based on the chain means
• V̂⁺: a pooled estimate of marginal variance

Then a familiar form of the diagnostic is:

If between-chain and within-chain information agree, R̂ approaches 1.

Why split R-hat became a thing

Classic R-hat could miss some forms of slow within-chain drift. Splitting each chain in half turns a temporal problem into a cross-chain disagreement problem.

The short history of acceptable numbers

The threshold story is easier to follow if you separate the statistic, the recommendation, and the package default.

1992: Gelman and Rubin introduce the idea

The original 1992 paper, Inference from Iterative Simulation Using Multiple Sequences, introduced the potential scale reduction factor, or PSRF, from which modern R-hat descends.

Important detail: they did not hand down 1.01 as a law.

They introduced a diagnostic that should be near one when multiple chains agree. The exact numeric cutoffs came later through practice, pedagogy and software.

1998: 1.2 and 1.1 become part of the culture

Brooks and Gelman extended the diagnostic toolkit in 1998. Around this era, 1.2 was a common practical threshold, with 1.1 later becoming the better-known conservative rule of thumb.

This is the period many older answers on forums, blogs and lecture notes still reflect.

2013: split-R-hat becomes mainstream

By the Bayesian Data Analysis third edition era, split-R-hat had become normal workflow in the Stan world.

That matters because the statistic itself was improving, even before the 1.01 recommendation arrived.

2018: Vats and Knudson challenge the old comfort zone

In Revisiting the Gelman-Rubin Diagnostic, Vats and Knudson linked Gelman-Rubin style diagnostics to effective sample size.

That changed the conversation. Instead of asking only whether 1.1 is close enough to 1, we could ask how much Monte Carlo precision we need for the quantity we actually care about.

That is a far better question.

19 March 2019: the real origin of the modern 1.01 recommendation

This is the key date.

Vehtari, Gelman, Simpson, Carpenter and Bürkner released the preprint that introduced the modern rank-normalised, folded, split R-hat and explicitly recommended:

• at least four chains, and
• only using the sample if R-hat < 1.01.

The later journal version appeared in Bayesian Analysis in 2021.

That paper also explains why the tighter threshold is useful. In their synthetic trend experiment, 1.01 detects much subtler non-stationarity than 1.1.

What changed in the statistic itself?

When people compare old 1.1 with new 1.01, they often talk as though only the cutoff changed. It did not. The statistic improved too.

So when the community moved towards 1.01, it was also moving towards a better diagnostic, not just a fussier threshold.

The Python ecosystem moved fast

The nice thing about open-source history is that it leaves timestamps behind.

ArviZ moved almost immediately

The chronology is unusually clean:

So modern R-hat entered the Python diagnostics ecosystem essentially in real time with the research.

But PyMC itself kept the old warnings for years

This is the part many people miss. PyMC 3.11.5 still had a tiered warning system that looked like this in spirit:

if rhat_max > 1.4:
    # sampler did not converge
elif rhat_max > 1.2:
    # warning
elif rhat_max > 1.05:
    # slight problems during sampling

So there was a transition period where:

• the better diagnostic existed,
• the 1.01 recommendation existed,
• but the PyMC warning policy was still from the older era.

The exact PyMC moment: PR #5516

If your question is specifically when did PyMC decide to warn at 1.01, the answer is wonderfully concrete.

PyMC PR #5516, update reported warnings after sampling, was opened on 23 February 2022 and merged on 4 March 2022.

Its logic was simple:

• warn if R-hat > 1.01;
• warn if ESS per chain < 100;
• tell users they should usually run at least four chains.

The open-source receipts

None of this is reconstructed from memory. The decision is on the record, in public, with timestamps.

What people were learning in the wild

The threshold story did not spread only through papers and pull requests. It spread through books, tutorials, YouTube, Reddit, mailing lists and package warnings.

Ben Lambert is a nice marker of the transition

Ben Lambert is a useful example because his teaching spans the old and new eras.

• In a 2015 Stan users discussion, Lambert described good convergence as R-hat < 1.1.
• His 2018 book, A Student’s Guide to Bayesian Statistics, arrived right before the 2019 diagnostic shift.
• Later, Lambert co-authored work on R-star, showing that convergence diagnostics kept evolving even after 1.01 became the new headline number.

Reddit and PyMC Discourse show the cultural lag

By 2021 the community was visibly between eras. A highly upvoted r/statistics answer put both numbers in the same sentence:

PyMC Discourse makes the same shift even more explicit. In 2020 a user was still seeing PyMC’s old 1.05 / 1.4 warnings, while a responder told them an R-hat around 1.04 was still high.

That is what a real standards transition looks like: papers move first, practitioners absorb the new advice, then package warnings catch up.

The standard still is not universal in 2026

That is the history settled, which leaves the more useful question. If 1.01 really had become a universal Bayesian convergence standard, major software would at least broadly agree on it. It does not.

So no, 1.01 did not become a universal standard in the literal sense. It became the best-supported modern conservative default in one important part of the ecosystem.

So what do you do when R-hat is 1.02 or 1.03?

Which brings us to the question every practitioner actually has. Sampling has finished, one parameter reads 1.03, and the warning has fired. Not all 1.03s are equally alarming.

Case 1: it is your key decision parameter

If the elevated R-hat belongs to a treatment effect, elasticity, ROI parameter, forecast quantity or any other estimate that directly drives the decision, investigate properly.

Case 2: it is a weakly identified nuisance parameter

That does not mean ignore it. But it may mean the business or scientific quantity you report is more stable than the nuisance coordinate itself.

Case 3: the model is non-identifiable in that parameterisation

Mixture models with label switching are the classic case. A label-dependent parameter can mix badly even when a label-invariant quantity is behaving well.

Case 4: longer runs make it disappear

Sometimes a slightly high R-hat is just finite-run Monte Carlo noise. If more sampling steadily pulls it down and the rest of the diagnostics are healthy, that is useful evidence.

There is a good worked example of this in the wild:

The right move is not blind acceptance or blind rejection. The right move is: investigate the quantity that matters.

One number is never enough

Treat 1.01 as a useful trigger, not a magical verdict.

Those six are the minimum for a model you intend to act on, and a posterior predictive check belongs alongside them to say whether the model fits the data at all.

That is the bigger shift in modern Bayesian workflow. The move from 1.1 to 1.01 matters, but the real lesson is that a single scalar diagnostic should never have been treated as the whole story anyway.

If you want to see that dashboard driving a real repair loop rather than a checklist, our companion piece on predicting the better prior before you refit walks through a hierarchical marketing mix model that fails every one of these checks, and what it takes to fix it.

We asked six AI systems the same question

As a side experiment, we asked six frontier models when 1.01 became the standard, while asking them not to invent exact pull request numbers or software versions if they did not know.

The answers were interesting because most models remembered the broad folklore but not the exact software history.

Evidence-audited ranking

Which is a good argument for being precise about what this article does and does not claim.

What we are not claiming

To keep the message honest:

• We are not saying 1.01 is too strict.
• We are not saying 1.03 is automatically acceptable.
• We are not saying nuisance parameters never matter.
• We are not saying users should overrule package warnings casually.
• We are not saying R-hat near 1 proves the posterior is fully explored.

What we are saying is simpler:

The full answer, in one paragraph

If you mean the published modern recommendation, the clean answer is 19 March 2019. If you mean the moment PyMC started warning at 1.01, the answer is 4 March 2022, when PR #5516 merged, shipping in PyMC 4.0.0 in June 2022. If you mean a universal Bayesian standard, that moment never happened.

And the closing point matters most: what counts as acceptable convergence depends on the parameter, the downstream quantity, the amount of Monte Carlo error you can tolerate, and the analyst’s judgement. As always, there is no escaping context.