Please make sure your browser sup­ports JavaScript and cook­ies and that you are not block­ing them from load­ing. For more in­for­ma­tion you can re­view our Terms of Service and Cookie Policy.

Today we’re chang­ing how code en­ters the Ladybird pro­ject.

We will no longer ac­cept pub­lic pull re­quests. From now on, code changes to the Ladybird code­base will only be in­tro­duced by pro­ject main­tain­ers.

Ladybird is mov­ing into a new phase. As we work to­ward our first al­pha re­lease, the pro­ject needs a tighter de­vel­op­ment process, a clearer se­cu­rity model, and a smaller set of peo­ple re­spon­si­ble for the code that en­ters the browser.

This is not a change we make lightly. Many valu­able con­tri­bu­tions have come from out­side the main­tainer group over the years, and we are grate­ful for them. Many of us also came up through open source by send­ing patches to pro­jects we cared about.

For decades, code con­tri­bu­tions have been how open source pro­jects learned who to trust. People would show up, do the work, take re­spon­si­bil­ity for their changes, and stick around. Over time, trust emerged from the work it­self.

AI tools have changed the eco­nom­ics of this very quickly. We use them our­selves every day, but a pull re­quest no longer tells us as much as it used to about the per­son sub­mit­ting it. A sub­stan­tial patch used to im­ply sub­stan­tial ef­fort, and that ef­fort was a rea­son­able proxy for good faith. That as­sump­tion no longer holds.

For a browser, this mat­ters. A browser runs un­trusted in­put from the en­tire in­ter­net on the user’s ma­chine, and one well-dis­guised vul­ner­a­bil­ity is all an at­tacker needs. We have al­ready seen pa­tient, well-re­sourced cam­paigns in open source to earn main­tainer trust and abuse it. What has changed is how much faster and cheaper it has be­come to pro­duce work that looks like a se­ri­ous con­tri­bu­tion.

At the same time, every change that en­ters Ladybird be­comes our re­spon­si­bil­ity. It has to fit the ar­chi­tec­ture, sur­vive fu­ture refac­tor­ing, in­ter­act cor­rectly with the rest of the browser, and be un­der­stood by the peo­ple main­tain­ing it.

Whether code was typed by hand is be­side the point. What mat­ters is who is re­spon­si­ble for it once it en­ters the browser. Ladybird is be­com­ing a browser for real users. The peo­ple in­tro­duc­ing changes to it must be the peo­ple who de­cide those changes be­long in the pro­ject, and who will an­swer for the con­se­quences.

As part of this change, we will close all cur­rently open pub­lic pull re­quests. We are grate­ful for the work peo­ple put into them, but keep­ing the ex­ist­ing queue open would keep that con­tri­bu­tion path open in prac­tice. There is no per­fect time to make this change, so we are mak­ing it now. Going for­ward, pull re­quests will only be avail­able to pro­ject main­tain­ers.

There will not be a sep­a­rate process for sub­mit­ting patches by other means. We do not want to cre­ate a shadow con­tri­bu­tion sys­tem through is­sues, com­ments, email, or forks. External code can of course ex­ist un­der the terms of the li­cense, but we will not treat forks or patch dumps as a re­view queue for up­stream Ladybird.

Ladybird re­mains open source. The source code will con­tinue to be pub­licly avail­able un­der an open source li­cense. Outside in­volve­ment still mat­ters: clear bug re­ports, re­duc­tions, web­site test­ing, stan­dards dis­cus­sion, de­sign dis­cus­sion, se­cu­rity re­ports, and tech­ni­cal feed­back all help move the pro­ject for­ward.

This is the right change for Ladybird now. We are prepar­ing to ship a browser to real users, and our de­vel­op­ment process has to match that re­spon­si­bil­ity.

This site re­quires JavaScript to func­tion prop­erly. Please en­able JavaScript in your browser set­tings.

C++

2026 – 06-042026 – 06-04

2 Minutes

C++: The Documentary pre­miered to­day on YouTube, and it was great to be on the live chat with Bjarne and many other key folks who par­tic­i­pated in C++’s his­tory. I’m hon­ored to have been one of hun­dreds of peo­ple who have played a part in ad­vanc­ing Bjarne’s won­der­ful pro­ject over the years.

If you haven’t watched this yet, make it a week­end goal. What a great syn­op­sis of a 40-year suc­cess story, from hum­ble be­gin­nings to global adop­tion to be­ing cur­rently (as of Q3 2025) the fastest-grow­ing of the top four lan­guages in the world… +90% users in the past 3.5 years.

People who ap­pear in the doc­u­men­tary:

Bjarne Stroustrup: Bell Labs, Designer and orig­i­nal im­ple­menter of C++

Alexander Stepanov: Designer of the Standard Template Library

Anders Hejlsberg: Creator of C#, TypeScript, and Turbo Pascal

Andrei Alexandrescu: Principal Research Scientist, Nvidia & C++ Author

Andrew Koenig: Bell Labs, Founding mem­ber of the C++ Standards Committee, Researcher, C++ Author & Educator

Barbara Moo: Bell Labs, Manager C++ Development Team & C++ Author

Brian Kernighan: Bell Labs, Computer Scientist, Co-author of “The C Programming Language”

Chris Lattner: Creator of Mojo, LLVM, Clang & Swift

Danilo Piparo: Particle Physicist, CERN, ROOT Framework Project Lead

Eric Lubin: Software Developer — Lead, Hudson River Trading

Gabriel Dos Reis: Software Engineer and Architect, Microsoft; C++ tools builder; Mathematician

Herb Sutter: Technical Fellow, Citadel Securities; Chair, Standard C++ Foundation; Chair Emeritus, ISO C++ Committee

John Romero: Video Game Developer, Co-Creator of Doom and Quake, Co-Founder id Software

Nina Ranns: Vice-Convener of the ISO C++ Committee

Chapters

00:00 Intro

01:50 Invention at AT&T Bell Labs

07:30 C with Classes

09:37 Early adop­tion of C with Classes

10:53 From C with Classes to C++ (and CFront)

12:32 Why is it called C++?

13:24 AT&T starts sell­ing soft­ware / Another team tries to take over C++

16:08 Early de­vel­op­ment of C++ at AT&T Bell Labs

19:10 “It was a buggy prod­uct” / Release 2.0.0

21:55 C++ spread­ing be­yond AT&T

24:50 Too many ver­sions of C++

26:03 Need for stan­dard­iza­tion

29:38 The STL by Alexander Stepanov

37:19 The first stan­dard: C++98

39:21 C++ at CERN in the 90s

40:34 C++ spread­ing to games and trad­ing

43:00 C++ win­ter of the early 2000s

45:34 Programming lan­guage wars (C#)

49:25 There’s a need for an ef­fi­cient pro­gram­ming lan­guage again

52:29 Modern C++ (C++11)

56:29 Is the stan­dards com­mit­tee mak­ing C++ too com­pli­cated?

1:00:45 C++ is ever­where

01:05:00 The fu­ture and chal­lenges for C++

01:08:31 Bjarne’s im­pact

Published by Herb Sutter

Herb Sutter is an au­thor and speaker, and a tech­ni­cal fel­low at Citadel Securities. He serves as chair of the Standard C++ Foundation and its con­fer­ence CppCon, and served as chair of the ISO C++ stan­dards com­mit­tee from 2002 to 2025. View all posts by Herb Sutter

Published 2026 – 06-042026 – 06-04

Post nav­i­ga­tion

The seven men and women aboard the ISSpublished at 16:35 BST

Pallab GhoshScience cor­re­spon­dent

Image source, Anadolu via Getty Images

Crew-12 mis­sion as­tro­nauts Jack Hathaway, Andrey Fedyaev, Jessica Meir and Sophie Adenot prepar­ing to launch to the ISS from Florida

The seven crew mem­bers cur­rently aboard the International Space Station rep­re­sent five coun­tries and a re­mark­able range of back­grounds.

Jessica Meir, 48, com­mands the Crew-12 mis­sion. Born in Caribou, Maine, to Israeli and Swedish im­mi­grant par­ents, she holds a doc­tor­ate in ma­rine bi­ol­ogy and once stud­ied how em­peror pen­guins hold their breath in Antarctica. She made his­tory in 2019 as part of the first all-fe­male space­walk. She is a mother and a pri­vate pi­lot, and is con­ver­sa­tional in both Swedish and Russian.

Jack Hathaway, 44, is Crew-12′s pi­lot and a US Navy Commander from South Windsor, Connecticut. He trained as a test pi­lot at the Empire Test Pilots’ School in the UK be­fore be­ing se­lected by NASA in 2021.

Sophie Adenot, 43, is a French colonel, he­li­copter test pi­lot and the sec­ond French woman ever to reach space, in­spired as a teenager by watch­ing Claudie Haigneré launch to the Mir space sta­tion. She speaks four lan­guages, is a cer­ti­fied yoga teacher and a trained sky­diver.

Chris Williams, 42, is a Nasa physi­cist and for­mer can­cer re­searcher at Harvard Medical School and Brigham and Women’s Hospital who piv­oted from study­ing the early uni­verse for his MIT doc­tor­ate to treat­ing tu­mours be­fore be­com­ing an as­tro­naut. He also vol­un­teered as a fire­fighter and EMT.

Sergey Kud-Sverchkov, 42, the sta­tion com­man­der, is a rocket en­gi­neer born in Baikonur — the very city from which so many space mis­sions have launched. He grad­u­ated with ho­n­ours from Moscow State Technical University and worked as an en­gi­neer at RSC Energia be­fore be­ing se­lected as a cos­mo­naut in 2010. He was awarded the Hero of the Russian Federation af­ter his first ISS mis­sion in 2020. He has also trained in un­der­ground cave sys­tems in Sardinia and stud­ied plan­e­tary ge­ol­ogy in the Dolomites as part of ESA’s as­tro­naut prepa­ra­tion pro­grammes.

Sergei Mikaev, 39, is on his first space­flight. Born in Irkutsk in Siberia, he rose to Major and com­man­der of a mil­i­tary avi­a­tion unit in Primorsky Territory — Russia’s re­mote far east, bor­der­ing China — be­fore be­ing se­lected as a cos­mo­naut in 2018. He is mar­ried with two chil­dren.

Andrey Fedyaev, 45, is a Russian cos­mo­naut and for­mer Air Force ma­jor from Serov in the Ural moun­tains, on his sec­ond space­flight. When he flew on Crew-6 in 2023, he be­came only the sec­ond Russian cos­mo­naut ever to launch aboard an American com­mer­cial space­craft. He is now on his sec­ond mis­sion, again fly­ing along­side Nasa col­leagues aboard Dragon.

Being the guy who wrote a book called Ultralearning, I get asked a lot of ques­tions about what I think schools should be do­ing bet­ter.

 Having never taught in a class­room or worked for even a sin­gle day in ed­u­ca­tion, it’s a ques­tion I’m to­tally un­qual­i­fied to an­swer. It’s a bit like ask­ing a guy to re­form an en­tire health care sys­tem be­cause he’s good at lift­ing weights.

But be­ing to­tally un­qual­i­fied has never stopped me be­fore, so I’ll try to ex­plain the an­swer I typ­i­cally give to this ques­tion, which is that I’m skep­ti­cal of dra­matic pro­pos­als to make school con­sid­er­ably more ef­fec­tive or ef­fi­cient for the av­er­age stu­dent.

To be clear, that’s not be­cause no im­prove­ment is pos­si­ble. We do know some about things that work that are in­con­sis­tently ap­plied: phon­ics should be taught, cog­ni­tive load should be man­aged, skills should be fully taught and prac­tice should be fun and am­ple.

But these an­swers aren’t the kind that sat­isfy the peo­ple who ask me these ques­tions. Instead, hav­ing had many of these con­ver­sa­tions, I feel like the per­son ask­ing al­ready “knows” what my re­sponse should be:

Isn’t it ob­vi­ous that school sucks? That we should be teach­ing crit­i­cal think­ing and prob­lem-solv­ing skills in­stead of use­less facts and the­o­ries? That school should be more like real life, with real-world pro­jects and ex­per­i­ments and col­lab­o­ra­tion? That there should be less of that stuffy work of sit­ting at a desk and mem­o­riz­ing things?

Isn’t it ob­vi­ous that school sucks? That we should be teach­ing crit­i­cal think­ing and prob­lem-solv­ing skills in­stead of use­less facts and the­o­ries? That school should be more like real life, with real-world pro­jects and ex­per­i­ments and col­lab­o­ra­tion? That there should be less of that stuffy work of sit­ting at a desk and mem­o­riz­ing things?

If you had asked me this ques­tion years ago, I prob­a­bly would have agreed with you. It took read­ing a lot of re­search to con­vince me that this in­tu­itively ap­peal­ing idea is ac­tu­ally bad. Below, I’d like to ex­plain why.

First, the Evidence

Before I get into the ex­pla­na­tion of why these kinds of seem­ingly-good strate­gies don’t work, I should be­gin by point­ing out that these ideas are not new. They have been tried, and they have been found want­ing.

Entire books have been writ­ten point­ing out the flaws in many of these strate­gies. I won’t be able to do the full de­bate jus­tice here, but, if you’re in­ter­ested, you can check out Daniel Willingham’s Why Don’t Students Like School? Greg Ashman’s The Power of Explicit Teaching and Direct Instruction or, if you want to learn more about the ac­tual de­bate be­tween pro­po­nents of both sides, try Constructivist Instruction: Success or Failure.

To briefly re­cap some of the ev­i­dence:

Project Follow Through was one of the largest ed­u­ca­tional ex­per­i­ments ever con­ducted. Run in the 1970s, it com­pared how dif­fer­ent teach­ing method­olo­gies im­pact stu­dent out­comes. Direct Instruction, a method of teach­ing that has stu­dents sit in desks and per­form ex­tremely struc­tured drills in uni­son, per­formed best.

Problem-based learn­ing tends to do worse than tra­di­tional school­ing in med­ical ed­u­ca­tion. An in­flu­en­tial meta-analy­sis by Albanese and Mitchell, for in­stance, found that stu­dents re­quired more time study­ing, had worse exam scores and or­dered more un­nec­es­sary tests com­pared to tra­di­tion­ally taught stu­dents.

Despite need­ing to re­learn this truth every few decades, the best way to teach kids how to read has been known for cen­turies: break down the sound-spelling cor­re­spon­dence, and do lots of prac­tice on it be­fore mov­ing up to au­then­tic texts. Approaches based on skip­ping these drills in fa­vor of “inspiring a love of read­ing” do worse.

Practice test­ing and dis­trib­uted prac­tice—ba­si­cally, hav­ing reg­u­lar quizzes spread out over a course—are the study­ing meth­ods with the best em­pir­i­cal sup­port. Fancy meth­ods like mnemon­ics and con­cept maps fare worse.

General prob­lem solv­ing abil­i­ties are nei­ther learned nor taught. While some prob­lem-solv­ing meth­ods have broader ap­plic­a­bil­ity than oth­ers (such as the sci­en­tific process of hy­poth­e­sis test­ing), stu­dents learn these meth­ods bet­ter when they’re ex­plic­itly taught rather than sim­ply giv­ing stu­dents pro­jects and hop­ing they’ll rein­vent them on their own.

In short, when­ever we have high-qual­ity ev­i­dence that rig­or­ously com­pares two teach­ing meth­ods, the re­search in­vari­ably fa­vors strong, di­rect in­struc­tion plus prac­tice.1 Or, in other words, the ex­act stereo­type of school­ing that so many of the peo­ple ask­ing me about school re­form de­spise.

Your Stereotype of School is an Endangered Species

This does­n’t mean ed­u­ca­tion could­n’t be bet­ter. My im­pres­sion upon first en­coun­ter­ing the Direct Instruction re­search was that I had never been taught this way in my en­tire life.

Clichés are of­ten out of date. I went to grade school in the nineties, when the lofty aims of pro­ject-based and dis­cov­ery learn­ing were the ed­u­ca­tional or­tho­doxy. I spent a lot of my school years do­ing time-con­sum­ing pro­jects that had us glu­ing and col­or­ing and ex­pected us to do our own re­search.

I’m pes­simistic about real re­form be­cause the changes needed to make schools more ef­fec­tive are of­ten op­po­site of what many peo­ple in­tu­itively feel. For schools to teach more ef­fec­tively, they should be more rig­or­ous about care­fully defin­ing the knowl­edge ob­jec­tives of the class, thor­oughly break­ing down com­plex skills into com­po­nents, and do­ing lots and lots and lots of prac­tice.

In short, a “better” school prob­a­bly looks more like the stereo­type of an old-fash­ioned school­house with kids sit­ting at desks, drilling facts and con­cepts that are pa­tiently ex­plained by a teacher. To the ex­tent that school be­comes more like free play, pro­ject-build­ing or act­ing like a sci­en­tist, it will prob­a­bly be worse.

Why It’s Hard to Improve Schools

Schools face a num­ber of prac­ti­cal con­straints that make thor­ough re­form dif­fi­cult. Students are un­mo­ti­vated. They range in back­ground knowl­edge and in­nate abil­ity. We care about sort­ing just as much as ed­u­cat­ing, so schools end up do­ing both.

But the real rea­son it’s hard to im­prove schools is sim­ply that there are fun­da­men­tal con­straints on how the brain learns that pre­vent rad­i­cal short­cuts.

The bor­ing truth is that ex­per­tise in most sub­jects is largely a mat­ter of hav­ing an enor­mous li­brary of knowl­edge and skill. For ex­am­ple, if you want to learn a lan­guage, you need to learn a lot of words. Any method that tries to skip over the fact that there are tens of thou­sands of words to learn is doomed to fail­ure. All skills are like this, it’s sim­ply that the “atoms” of learn­ing are usu­ally less ob­vi­ous than in lan­guages.

When stu­dents com­plain about all the bor­ing facts and skills they had to learn in school, my re­sponse is to claim that there is­n’t any other type! All skills are sim­ply an ac­cu­mu­la­tion of small bits of facts, pro­ce­dures and con­cepts.

Those small bits, in iso­la­tion, seem kind of triv­ial. But quan­tity has a qual­ity all its own, and with enough well-in­te­grated knowl­edge the re­sult is ex­per­tise that seems al­most mag­i­cal to those who don’t pos­sess it.

This means that im­prov­ing ed­u­ca­tion comes down to largely two dif­fer­ent op­tions:

First, you can in­crease the ef­fi­ciency of the sys­tem. Efficiency here looks like the kind of fac­tory re­design that in­creases prod­uct through­put—in­creas­ing the num­ber of words learned per day, op­ti­miz­ing cog­ni­tive load, boost­ing mnemonic ef­fi­ciency through spac­ing and re­trieval—with­out skip­ping over the fun­da­men­tal bot­tle­neck in cog­ni­tion.

Second, you can choose to learn dif­fer­ent things. Given the high de­gree of speci­ficity of most knowl­edge, the choice of what to learn can have pro­found con­se­quences. But if choos­ing a ped­a­gog­i­cal method is con­tentious, cur­ric­u­lar choice is even more so! For every “useless” sub­ject that re­form­ers want to dis­card, there are die-hard ad­vo­cates ar­gu­ing that we should be putting in even more.

I be­lieve in both of these things, and I’ve fo­cused much of my writ­ing ca­reer on how we can do them bet­ter, par­tic­u­larly out­side of the typ­i­cal class­room. But if you want lots of skills, there’s no way around learn­ing a lot of stuff—in­clud­ing a ton of stuff that feels too ob­scure to be broadly use­ful.

What About Ed Tech?

Thus far, I’ve mostly been tar­get­ing a cer­tain kind of ques­tioner: some­one who feels that school was maybe too bor­ing and im­prac­ti­cal, and who longs for the pos­si­bil­ity that ed­u­ca­tion could be more like play and less like study­ing.

There are re­form­ers of all stripes, and ed­u­ca­tional tech­nol­o­gists are an­other side of this de­bate. These are the peo­ple who cham­pion ef­forts to gam­ify learn­ing, care­fully match teach­ing to each stu­den­t’s abil­ity level, de­velop AI-based tu­tor­ing, put an iPad in every child’s hands and so on.

In the­ory, these ideas are pos­si­bly use­ful. Drills can be bor­ing, so wrap­ping them with gam­i­fi­ca­tion el­e­ments that re­ward progress and en­gage­ment might be help­ful. Skills can be too hard or too easy, so ad­just­ing dif­fi­culty au­to­mat­i­cally might be help­ful. AI-tutoring, too, might help with clos­ing Bloom’s fa­mous 2 sigma prob­lem.

But I’m more skep­ti­cal in prac­tice. As Kelsey Piper writes, a lot of ed-tech games have a fairly low den­sity of ac­tual use­ful learn­ing. I can at­test to this: ea­ger to give my son a head start on the pho­netic skills in­volved in read­ing, I tried a few dif­fer­ent iPad games with him. He mostly messed around ran­domly un­til he got the re­ward, largely ig­nor­ing the ed­u­ca­tional con­tent to fix­ate on the cute car­toon char­ac­ters.

Gamified learn­ing is a bit like wrap­ping med­i­cine in candy. Yes, it may help some stu­dents swal­low some in­struc­tion they oth­er­wise find bit­ter, but in prac­tice it’s easy to pull off the candy, con­sume it, and throw the med­i­cine away.

Individualized in­struc­tion aided by tech­nol­ogy does solve some of the prob­lems of dif­fer­ing abil­ity lev­els. But schools aren’t just solv­ing the cog­ni­tive prob­lems of learn­ing, they’re also work­ing on mo­ti­va­tional ones. A rig­or­ous, but achiev­able, stan­dard that ap­plies to every­one may be more sus­tain­able for mo­ti­va­tion than an in­di­vid­u­ally-tai­lored goal for each stu­dent.2

Similarly, while I’m hope­ful that AI ad­vances will make au­to­mated tu­tor­ing more use­ful, it’s still far away from the skill a teacher can pro­vide. As some­one who makes use of AI quite a bit in my own learn­ing, I can say that it’s still rel­a­tively weak at hav­ing a good model of an in­di­vid­u­al’s skill gaps and con­cep­tual weak­nesses. It’s very much at the “better than noth­ing”—not the “better than teach­ers”—stage right now.

So, while I’m hope­ful that there will be some im­prove­ments in tech­nol­ogy around the mar­gins, I’m skep­ti­cal of any­thing touted as a rad­i­cal over­haul in ed­u­ca­tional process or out­comes.

What About Ultralearning?

Does this line of think­ing rule out the meth­ods I de­scribe in Ultralearning? I don’t think so. The big dis­tinc­tion (and it is a big one) be­tween my aims for that book and the aims of ed­u­ca­tional re­form­ers is that I started with the as­sump­tion of a highly mo­ti­vated learner.

The peo­ple I doc­u­ment in that book all be­gan with the start­ing point that they were will­ing to work hard, even ob­ses­sively, on a pro­ject they were deeply mo­ti­vated to suc­ceed with. In such cases, the class­room struc­tures that fa­cil­i­tate mo­ti­va­tion can in­stead be­come ob­sta­cles: fixed home­work as­sign­ments, manda­tory lec­tures, exam dead­lines. These things keep un­in­ter­ested stu­dents go­ing, but they may hold back the ag­gres­sively cu­ri­ous.

For in­stance, I still be­lieve that full im­mer­sion is the best way to learn a lan­guage, pro­vided you also aug­ment that with a lot of the study­ing ap­proaches I de­scribe above, but it’s ob­vi­ously a high-ef­fort strat­egy. I’ve spo­ken to lots of peo­ple who have asked me for ad­vice on how to learn a lan­guage, but rel­a­tively few that took up Vat’s and my ac­tual strat­egy of avoid­ing speak­ing English.

Ultimately, I be­lieve en­hanced learn­ing is cer­tainly pos­si­ble, and a highly mo­ti­vated per­son can of­ten do bet­ter than the av­er­age, and some­times even the up­per end, of what is typ­i­cally seen in school. But such op­ti­mism about the pos­si­bil­ity of learn­ing does­n’t so eas­ily trans­fer to a sit­u­a­tion where mo­ti­va­tion is much lower.

Footnotes

Manu Kapur’s work on pro­duc­tive fail­ure does­n’t un­der­mine this find­ing, con­trary to some mis­in­ter­pre­ta­tions. Kapur’s re­search sim­ply finds that the tim­ing of in­struc­tion has some ef­fects. Sometimes, for cer­tain kinds of skills, in cer­tain kinds of en­vi­ron­ments, at­tempt­ing to solve a prob­lem first and fail­ing can be help­ful for later un­der­stand­ing the so­lu­tion pro­ce­dure that is fully taught.

Researcher Greg Ashman makes a good ar­gu­ment against com­mon pleas to in­di­vid­u­al­ize in­struc­tion in his book.

The open source AI code re­view agent.

English | 简体中文

What is Open Code Review?

Open Code Review is an AI-powered code re­view CLI tool. It orig­i­nated as Alibaba Group’s in­ter­nal of­fi­cial AI code re­view as­sis­tant — over the past two years, it has served tens of thou­sands of de­vel­op­ers and iden­ti­fied mil­lions of code de­fects. After thor­ough val­i­da­tion at mas­sive scale, we in­cu­bated it into an open source pro­ject for the com­mu­nity. Simply con­fig­ure a model end­point to get started.

It reads Git diffs, sends changed files to a con­fig­urable LLM via an agent with tool-use ca­pa­bil­i­ties, and gen­er­ates struc­tured re­view com­ments with line-level pre­ci­sion. The agent can read full file con­tents, search the code­base, in­spect other changed files for con­text, and pro­duce deep re­views — not just sur­face-level diff feed­back.

The Problem with General-Purpose Agents

If you’ve used gen­eral-pur­pose agents like Claude Code with Skills for code re­view, you’ve likely en­coun­tered these pain points:

Incomplete cov­er­age — On larger change­sets, agents tend to “cut cor­ners,” se­lec­tively re­view­ing only some files and miss­ing oth­ers.

Position drift — Reported is­sues fre­quently don’t match the ac­tual code lo­ca­tion, with line num­bers or file ref­er­ences drift­ing off tar­get.

Unstable qual­ity — Natural-language-driven Skills are hard to de­bug, and re­view qual­ity fluc­tu­ates sig­nif­i­cantly with mi­nor prompt vari­a­tions.

The root cause: a purely lan­guage-dri­ven ar­chi­tec­ture lacks hard con­straints on the re­view process.

Core Design: Deterministic Engineering × Agent Hybrid

Open Code Review’s core phi­los­o­phy is to com­bine de­ter­min­is­tic en­gi­neer­ing with an agent, each han­dling what it does best.

Deterministic Engineering — Hard Constraints

For re­view steps that must not go wrong, en­gi­neer­ing logic — not the lan­guage model — guar­an­tees cor­rect­ness:

Precise file se­lec­tion — Determines ex­actly which files need re­view and which should be fil­tered, en­sur­ing no im­por­tant change is missed.

Smart file bundling — Groups re­lated files into a sin­gle re­view unit (e.g., mes­sage_en.prop­er­ties and mes­sage_zh.prop­er­ties are bun­dled to­gether). Each bun­dle runs as a sub-agent with iso­lated con­text — a di­vide-and-con­quer strat­egy that stays sta­ble on very large change­sets and nat­u­rally sup­ports con­cur­rent re­view.

Fine-grained rule match­ing — Matches re­view rules to each file’s char­ac­ter­is­tics, keep­ing the mod­el’s at­ten­tion sharply fo­cused and elim­i­nat­ing in­for­ma­tion noise at the source. Compared to purely lan­guage-dri­ven rule guid­ance, tem­plate-en­gine-based rule match­ing is more sta­ble and pre­dictable.

External po­si­tion­ing and re­flec­tion mod­ules — Independent com­ment-po­si­tion­ing and com­ment-re­flec­tion mod­ules sys­tem­at­i­cally im­prove both the lo­ca­tion ac­cu­racy and con­tent ac­cu­racy of AI feed­back.

Agent — Dynamic Decision-Making

The agen­t’s strengths are con­cen­trated where they mat­ter most — dy­namic de­ci­sions and dy­namic con­text re­trieval:

Scenario-tuned prompts — Prompt tem­plates deeply op­ti­mized for code re­view, im­prov­ing ef­fec­tive­ness while re­duc­ing to­ken con­sump­tion.

Scenario-tuned toolset — Distilled from deep analy­sis of tool-call traces in large-scale pro­duc­tion data — in­clud­ing call fre­quency dis­tri­b­u­tions, per-tool rep­e­ti­tion rates, and the im­pact of new tools on the over­all call chain — re­sult­ing in a pur­pose-built toolset that is more sta­ble and pre­dictable for code re­view than a generic agent toolkit.

How to Use

CLI

Install

Via NPM (Recommended)

npm in­stall -g @alibaba-group/open-code-review

After in­stal­la­tion, the ocr com­mand is avail­able glob­ally.

From GitHub Release

Download the lat­est bi­nary from GitHub Releases:

# ma­cOS (Apple Silicon) curl -Lo ocr https://​github.com/​al­ibaba/​open-code-re­view/​re­leases/​lat­est/​down­load/​open­codere­view-dar­win-ar­m64 chmod +x ocr && sudo mv ocr /usr/local/bin/ocr

# ma­cOS (Intel) curl -Lo ocr https://​github.com/​al­ibaba/​open-code-re­view/​re­leases/​lat­est/​down­load/​open­codere­view-dar­win-amd64 chmod +x ocr && sudo mv ocr /usr/local/bin/ocr

# Linux (x86_64) curl -Lo ocr https://​github.com/​al­ibaba/​open-code-re­view/​re­leases/​lat­est/​down­load/​open­codere­view-linux-amd64 chmod +x ocr && sudo mv ocr /usr/local/bin/ocr

# Linux (ARM64) curl -Lo ocr https://​github.com/​al­ibaba/​open-code-re­view/​re­leases/​lat­est/​down­load/​open­codere­view-linux-ar­m64 chmod +x ocr && sudo mv ocr /usr/local/bin/ocr

# Windows (x86_64) — move ocr.exe to a di­rec­tory in your PATH curl -Lo ocr.exe https://​github.com/​al­ibaba/​open-code-re­view/​re­leases/​lat­est/​down­load/​open­codere­view-win­dows-amd64.exe

# Windows (ARM64) — move ocr.exe to a di­rec­tory in your PATH curl -Lo ocr.exe https://​github.com/​al­ibaba/​open-code-re­view/​re­leases/​lat­est/​down­load/​open­codere­view-win­dows-ar­m64.exe

From Source

git clone https://​github.com/​al­ibaba/​open-code-re­view.git cd open-code-re­view make build sudo cp dist/​open­codere­view /usr/local/bin/ocr

Quick Start

1. Configure LLM

You must con­fig­ure an LLM be­fore re­view­ing code.

# Option A: Interactive con­fig ocr con­fig set llm.url https://​api.an­thropic.com/​v1/​mes­sages ocr con­fig set llm.auth_­to­ken your-api-key-here ocr con­fig set llm.model claude-opus-4 – 6 ocr con­fig set llm.use_an­thropic true

# Option B: Environment vari­ables (highest pri­or­ity) ex­port OCR_LLM_URL=https://​api.an­thropic.com/​v1/​mes­sages ex­port OCR_LLM_TOKEN=your-api-key-here ex­port OCR_LLM_MODEL=claude-opus-4 – 6 ex­port OCR_USE_ANTHROPIC=true

Config is stored in ~/.opencodereview/config.json.

It is also com­pat­i­ble with Claude Code en­vi­ron­ment vari­ables (ANTHROPIC_BASE_URL, ANTHROPIC_AUTH_TOKEN, ANTHROPIC_MODEL) and parses ~/.zshrc / ~/.bashrc for those ex­ports.

Note for CC-Switch Users: If you are us­ing CC-Switch with rout­ing ser­vice en­abled, you can point llm.url to the CC-Switch proxy ad­dress with­out ad­di­tional con­fig­u­ra­tion:

For Claude provider: set llm.url to http://​127.0.0.1:15721 For CodeX provider: set llm.url to http://​127.0.0.1:15721/​v1 Set llm.model ac­cord­ing to your provider set­tings llm.auth_­to­ken can be any value ex­tra_­body set­tings still ap­ply

Note for CC-Switch Users: If you are us­ing CC-Switch with rout­ing ser­vice en­abled, you can point llm.url to the CC-Switch proxy ad­dress with­out ad­di­tional con­fig­u­ra­tion:

For Claude provider: set llm.url to http://​127.0.0.1:15721

For CodeX provider: set llm.url to http://​127.0.0.1:15721/​v1

Set llm.model ac­cord­ing to your provider set­tings

llm.auth_­to­ken can be any value

ex­tra_­body set­tings still ap­ply

2. Test Connectivity

ocr llm test

3. Review

cd your-pro­ject

# Workspace mode — re­view all staged, un­staged, and un­tracked changes ocr re­view

# Branch range — com­pare two refs ocr re­view –from main –to fea­ture-branch

# Single com­mit ocr re­view –commit abc123

Integrate with Coding Agents

OCR can be seam­lessly in­te­grated into AI cod­ing agents as a slash com­mand, en­abling code re­view di­rectly within your agent work­flow.

Option 1: Install as a Skill

Use npx to in­stall the OCR skill into your pro­ject:

npx skills add al­ibaba/​open-code-re­view –skill open-code-re­view

This in­stalls the open-code-re­view skill from the skills reg­istry, which teaches your cod­ing agent how to in­voke ocr for code re­view, clas­sify is­sues by pri­or­ity, and op­tion­ally ap­ply fixes.

Option 2: Install as a Claude Code Plugin

For Claude Code, in­stall the com­mand plu­gin through the fol­low­ing com­mand in Claude Code:

/plugin mar­ket­place add al­ibaba/​open-code-re­view /plugin in­stall open-code-re­view@open-code-re­view

This reg­is­ters the /open-code-review:review slash com­mand, which runs OCR and au­to­mat­i­cally fil­ters and fixes is­sues.

Option 3: Copy the Command File Directly

For a quick setup with­out any pack­age man­ager, sim­ply copy the com­mand file to use the /open-code-review slash com­mand in Claude Code.

Project-level (shared with team via git):

mkdir -p .claude/commands curl -o .claude/commands/open-code-review.md \ https://​raw.githubuser­con­tent.com/​al­ibaba/​open-code-re­view/​main/​plu­g­ins/​open-code-re­view/​com­mands/​re­view.md

User-level (personal global use across all pro­jects):

mkdir -p ~/.claude/commands curl -o ~/.claude/commands/open-code-review.md \ https://​raw.githubuser­con­tent.com/​al­ibaba/​open-code-re­view/​main/​plu­g­ins/​open-code-re­view/​com­mands/​re­view.md

Prerequisite: All in­te­gra­tion meth­ods re­quire the ocr CLI to be in­stalled and an LLM con­fig­ured. See Install and Configure LLM above.

Prerequisite: All in­te­gra­tion meth­ods re­quire the ocr CLI to be in­stalled and an LLM con­fig­ured. See Install and Configure LLM above.

CI/CD Integration

OCR can be in­te­grated into CI/CD pipelines to au­to­mate code re­view on Merge Requests / Pull Requests.

The core com­mand for CI in­te­gra­tion:

ocr re­view \ –from “origin/main” \ –to “origin/feature-branch” \ –format json

The –format json flag out­puts ma­chine-read­able re­sults suit­able for pars­ing in CI scripts.

See the ex­am­ples/ di­rec­tory for in­te­gra­tion ex­am­ples:

github_ac­tions/ — GitHub Actions in­te­gra­tion ex­am­ple

git­lab_ci/ — GitLab CI in­te­gra­tion ex­am­ple

Commands

ocr re­view Flags

Examples

# Preview which files will be re­viewed (no LLM calls) ocr re­view –preview ocr re­view -c abc123 -p

# Review work­space changes with de­fault set­tings ocr re­view

# Review branch diff with higher con­cur­rency ocr re­view –from main –to my-fea­ture –concurrency 4

# Review a spe­cific com­mit with ver­bose JSON out­put ocr re­view –commit abc123 –format json –audience agent

# Use cus­tom re­view rules ocr re­view –rule /path/to/my-rules.json

# Preview which rule ap­plies to a file ocr rules check src/​main/​java/​com/​ex­am­ple/​Foo.java ocr rules check –rule cus­tom.json src/​main/​re­sources/​map­per/​UserMap­per.xml

# View re­view ses­sion his­tory in browser ocr viewer ocr viewer –addr :3000

Viewer se­cu­rity

The viewer serves ses­sion JSONL con­tents (LLM re­quest mes­sages and re­sponses) over HTTP. It en­forces a Host-header al­lowlist on every re­quest: loop­back names (localhost, 127.0.0.0/8, ::1) and the con­crete bind host are al­ways al­lowed. Wildcard binds (–addr :3000, –addr 0.0.0.0:3000) and other non-loop­back Hostnames must be added via the OCR_VIEWER_ALLOWED_HOSTS en­vi­ron­ment vari­able (comma-separated):

OCR_VIEWER_ALLOWED_HOSTS=review.internal,ocr.lan ocr viewer –addr :3000

Long-running, fault-tol­er­ant SQL func­tions for teams that al­ready keep their state in Postgres and want to stop stitch­ing to­gether cron jobs, work­ers, queues, and sta­tus ta­bles to make back­ground work re­li­able. Define the work­flow in SQL, let pg_­durable check­point each step, and re­sume af­ter crashes, restarts, or failed steps.

Durable ex­e­cu­tion is now a stan­dard in­dus­try pat­tern, and pg_­durable brings it in­side Postgres with no ex­tra ser­vice in­fra­struc­ture re­quired. Part of our mis­sion to bring com­pute close to data.

Try pg_­durable now in Azure HorizonDB, Microsoft’s new PostgreSQL cloud ser­vice en­gi­neered for per­for­mance and built with pg_­durable in­side

Try pg_­durable now in Azure HorizonDB, Microsoft’s new PostgreSQL cloud ser­vice en­gi­neered for per­for­mance and built with pg_­durable in­side

Is this for me?

Who it’s for

Backend and data en­gi­neers who want work­flows to live next to the data they touch.

DBAs and SREs au­tomat­ing run­books that must sur­vive restarts and be au­ditable in SQL.

Teams build­ing data or AI pipelines that need durable ex­e­cu­tion per row, doc­u­ment, or batch.

The core idea

A pg_­durable func­tion is a graph of SQL steps that PostgreSQL ex­e­cutes and check­points as it goes. If the data­base crashes, restarts, or a step fails, ex­e­cu­tion re­sumes from the last durable check­point in­stead of mak­ing you re­con­struct state by hand.

Workloads this is use­ful for

Vector em­bed­ding pipelines: chunk, call an em­bed­ding API, and up­sert into pgvec­tor.

Ingest pipelines: stage, dedu­pli­cate, trans­form, and pub­lish large batches.

Scheduled main­te­nance: de­tect bloat, no­tify, wait for ap­proval, then run the next ac­tion.

Fan-out ag­gre­ga­tion: run in­de­pen­dent queries in par­al­lel, then join the re­sults.

External API work­flows: en­rich­ment, clas­si­fi­ca­tion, and web­hook-style calls from SQL.

What you’re prob­a­bly do­ing to­day in­stead

pg_cron plus a jobs table, sta­tus columns, retry coun­ters, and a polling worker.

An ex­ter­nal or­ches­tra­tor such as Airflow, Temporal, Step Functions, or Argo call­ing back into Postgres.

A queue plus work­ers plus a sep­a­rate state table to co­or­di­nate re­tries and par­tial com­ple­tion.

A plpgsql pro­ce­dure that works un­til a crash or long-run­ning trans­ac­tion forces you to start over.

Pain points it ad­dresses

A restart in the mid­dle of a long job means re­run­ning work that al­ready suc­ceeded.

One failed row or one failed API call turns into man­ual cleanup and un­cer­tain re­play.

Long trans­ac­tions hold locks, grow WAL, and make batch jobs frag­ile at larger scale.

Parallel work in the app tier cre­ates more places for par­tial-fail­ure bugs and drift.

The work­flow logic ends up spread across SQL, work­ers, queues, dash­boards, and sta­tus ta­bles.

What changes in your ar­chi­tec­ture

The work­flow de­f­i­n­i­tion moves into SQL and starts with df.start(…).

Retry state, progress track­ing, and check­point­ing move into Postgres in­stead of be­spoke app code.

Some app-tier work­ers, queue con­sumers, or sched­uler glue can dis­ap­pear en­tirely.

Operational vis­i­bil­ity comes from Postgres ta­bles such as df.in­stances, us­ing the same auth and backup model as your data.

When not to use it

The job is al­ready a sin­gle INSERT … SELECT or one or­di­nary SQL state­ment.

You need sub-mil­lisec­ond syn­chro­nous re­quest han­dling rather than durable back­ground ex­e­cu­tion.

You can­not in­stall ex­ten­sions or run a back­ground worker in your Postgres en­vi­ron­ment.

The work­flow mostly lives out­side Postgres and spans many het­ero­ge­neous sys­tems.

You need ar­bi­trary ap­pli­ca­tion logic that does not map cleanly to SQL steps, branch­ing, loops, or HTTP calls.

How it works

Define a work­flow in SQL us­ing com­pos­able op­er­a­tors such as ~> and |=>.

Start it with df.start() and get back an in­stance ID.

Let the run­time ex­e­cute each step durably with check­point­ing be­tween steps.

Query sta­tus and re­sults from PostgreSQL while the work­flow runs or af­ter it com­pletes.

Limitations

The model is in­ten­tion­ally SQL-shaped. If a step needs ar­bi­trary code, a non-HTTP SDK, or rich in-mem­ory con­trol flow, you may need to wrap that logic in a SQL func­tion, ex­pose it be­hind an HTTP end­point for df.http(), or use a gen­eral-pur­pose or­ches­tra­tor for that part of the sys­tem.

Features

Durable — Function state per­sists to PostgreSQL. Survives crashes, restarts, and failovers.

SQL-native — Define func­tions in SQL us­ing com­pos­able op­er­a­tors.

Database-aware — First-class prim­i­tives for sched­ul­ing, con­di­tions, and par­al­lel ex­e­cu­tion.

Zero in­fra­struc­ture — Runs as a PostgreSQL ex­ten­sion. No Redis, no Temporal, no ex­ter­nal ser­vices.

Quick Example

– A durable func­tion that processes data in steps SELECT df.start( ‘SELECT id FROM doc­u­ments WHERE processed = false LIMIT 100’ |=> ‘batch’ ~> ‘UPDATE doc­u­ments SET processed = true WHERE id = ANY($batch)’ );

Packages

Tagged re­leases pub­lish Debian pack­ages for PostgreSQL 17 and 18 on amd64 from the GitHub re­lease as­sets. Packages are named pg-durable-post­gresql-<PG ma­jor>_<pg_­durable ver­sion>-1_<arch>.deb and in­stall the ex­ten­sion li­brary, con­trol file, and SQL up­grade files into the match­ing PostgreSQL in­stal­la­tion di­rec­to­ries.

After in­stalling a pack­age, add pg_­durable to shared_pre­load­_li­braries, restart PostgreSQL, and cre­ate the ex­ten­sion in the con­fig­ured pg_­durable data­base:

CREATE EXTENSION pg_­durable;

The de­fault pg_­durable data­base is post­gres; see User Guide for back­ground worker con­fig­u­ra­tion and priv­i­lege setup.

Release as­sets also in­clude source archives for build­ing from source.

Development Installation

Prerequisites

PostgreSQL 17 or 18

Rust (nightly)

cargo-pgrx 0.16.1

GitHub Codespace

The main branch pre­build in­stalls PostgreSQL 17, builds pg_­durable, and pre­pares a lo­cal clus­ter un­der ~/.pgrx with the ex­ten­sion ready. PostgreSQL is not left run­ning, so start it when you be­gin work­ing.

# Start PostgreSQL ./scripts/pg-start.sh

# Connect ~/.pgrx/17.*/pgrx-install/bin/psql -h lo­cal­host -p 28817 -d post­gres

On a branch with­out a ready pre­build, run pg-start.sh — it will build and in­stall the ex­ten­sion on first run (expect a few min­utes):

./scripts/pg-start.sh

Other en­vi­ron­ments

Local and Dev Container

A VS Code Dev Container (.devcontainer/) pro­vides Rust, cargo-pgrx, and PostgreSQL 17 pre-in­stalled. For a bare lo­cal ma­chine, in­stall the tool­chain first by fol­low­ing the steps in .devcontainer/onCreateCommand.sh.

# Build, ini­tial­ize PostgreSQL, and in­stall the ex­ten­sion # This takes a while - go do some­thing else ./scripts/pg-start.sh

# Connect to the lo­cal pgrx PostgreSQL in­stance ~/.pgrx/17.*/pgrx-install/bin/psql -h lo­cal­host -p 28817 -d post­gres

pg-start.sh boot­straps new lo­cal data di­rec­to­ries with a post­gres su­pe­ruser and also cre­ates a match­ing su­pe­ruser role for the cur­rent OS user, so de­fault lo­cal psql us­age con­tin­ues to work. Use -U post­gres if you want to force the canon­i­cal boot­strap role ex­plic­itly.

Docker

# Build and test ./scripts/test-e2e-docker.sh –rebuild

# Optional: Deploy to ACR (for cus­tom PG17 im­age with pg_­durable baked-in) ./scripts/deploy-acr.sh

Multi-User Setup

CREATE EXTENSION pg_­durable does not grant any priv­i­leges to PUBLIC. After in­stalling the ex­ten­sion, the ad­min must ex­plic­itly grant ac­cess to ap­pli­ca­tion roles. Row-level se­cu­rity (RLS) en­sures each user can only see and man­age their own durable func­tion in­stances and nodes.

Grant priv­i­leges to an ap­pli­ca­tion role:

– Grant to spe­cific roles af­ter CREATE EXTENSION SELECT df.grant_us­age(‘ap­p_role’);

Alternatively, cre­ate an in­di­rec­tion role and grant mem­ber­ship to ap­pli­ca­tion roles:

– Create a shared role for pg_­durable ac­cess CREATE ROLE pg_­durable_user NOLOGIN; SELECT df.grant_us­age(‘pg_­durable_user’);

– Grant mem­ber­ship to ap­pli­ca­tion roles GRANT pg_­durable_user TO ap­p_back­end, etl_ser­vice;

See the User Guide — Privilege Grants sec­tion for the full list of in­di­vid­ual grants, re­vok­ing ac­cess, and hard­en­ing up­graded in­stalls.

See the User Guide — Privilege Grants sec­tion for the full list of in­di­vid­ual grants, re­vok­ing ac­cess, and hard­en­ing up­graded in­stalls.

Note: GRANT EXECUTE ON ALL FUNCTIONS only ap­plies to func­tions that ex­ist when the grant runs. After up­grad­ing pg_­durable with ALTER EXTENSION pg_­durable UPDATE, re-run df.grant_us­age(‘role’) (or re-is­sue the man­ual grants) so new func­tions are ac­ces­si­ble.

Note: GRANT EXECUTE ON ALL FUNCTIONS only ap­plies to func­tions that ex­ist when the grant runs. After up­grad­ing pg_­durable with ALTER EXTENSION pg_­durable UPDATE, re-run df.grant_us­age(‘role’) (or re-is­sue the man­ual grants) so new func­tions are ac­ces­si­ble.

Key points:

The back­ground worker role (pg_durable.worker_role GUC, de­fault: azuresu) must be a su­pe­ruser — it by­passes RLS to man­age all users’ in­stances

Users get SELECT + INSERT on df.in­stances / df.nodes, col­umn-level UPDATE (status, up­dat­ed_at) on in­stances for df.can­cel()

Identity col­umn (submitted_by) can­not be mod­i­fied by users

df.vars uses per-user scop­ing — each user has their own vari­able name­space via an owner col­umn and RLS. Superusers by­pass RLS but DSL func­tions still scope to the call­ing user via ex­plicit fil­ters. Avoid stor­ing se­crets in plain text

Continuous Integration

All pull re­quests must pass the fol­low­ing checks be­fore merg­ing:

Format Check — cargo fmt –check

Clippy & Tests — cargo clippy, unit tests (cargo pgrx test pg17), pg_regress tests, and E2E tests

The CI work­flow is de­fined in .github/workflows/ci.yml. It uses pgrx to down­load and man­age PostgreSQL.

pub­lic sec­tor

Means res­i­dents can skip the credit card and use ‘pay by bank’ for lo­cal au­thor­i­ties and ser­vices

The UK’s Government Digital Service (GDS) has re­placed Stripe with Dutch provider Adyen as its proces­sor for many pay­ments made through its GOV.UK Pay ser­vice.

Adyen will take over GOV.UK Pay card pay­ments for lo­cal au­thor­i­ties, po­lice forces and armed forces units from Stripe, as well as pay by bank ser­vices, un­der a three-year con­tract worth up to £25.3 mil­lion.

According to the ten­der no­tice pub­lished in February 2025, the con­tract cov­ers around 17 per­cent of pay­ments made through GOV.UK Pay but more than 70 percent of its or­ga­ni­za­tions and in­cludes the only op­tion al­low­ing users to start tak­ing pay­ments within one work­ing day. At that point the con­tract had an es­ti­mated max­i­mum value of £49 mil­lion, al­though with no guar­an­tees over vol­ume.

REG AD

In a blog­post about the con­tract award on 2 June, GDS said it will mi­grate around 1,000 ser­vices to the new sup­plier. “We will make mi­gra­tion as straight­for­ward as pos­si­ble while com­ply­ing with Know Your Customer leg­is­la­tion that pro­tects every­one from fraud,” wrote Alan Maddrell, se­nior con­tent de­signer for the ser­vice. “Most im­por­tantly, there will be no dis­cernible dif­fer­ence for pay­ing users and no loss in func­tion­al­ity.”

REG AD

He added that the change of sup­plier will help in­tro­duce new op­tions in­clud­ing pay by bank, which trans­fers money di­rectly be­tween bank ac­counts us­ing open bank­ing ser­vices and avoids the need to type in card de­tails. GDS will con­tinue to use WorldPay to process pay­ments for cen­tral gov­ern­ment, linked or­ga­ni­za­tions and NHS bod­ies.

GDS es­tab­lished GOV.UK Pay to save pub­lic ser­vices the ef­fort and cost of set­ting up on­line pay­ments them­selves. It does­n’t charge or­ga­ni­za­tions for the ser­vice be­yond pass­ing on trans­ac­tion fees.

According to its per­for­mance data page, GOV.UK Pay has processed 137.5 mil­lion trans­ac­tions since it was set up in 2016, worth around £9.2 bil­lion. It cur­rently pro­vides 1,718 ser­vices, in­clud­ing 662 for lo­cal gov­ern­ment and 256 for po­lice forces, to 608 or­gan­i­sa­tions rang­ing from 1079 (Tiverton) Squadron RAF Air Cadets to Yeovil Town Council. ®