Consider Toto.

If you spend much time in American pub­lic bath­rooms, or rather if you’re sim­ply a par­tic­u­larly at­ten­tive pa­tron of American pub­lic bath­rooms, you’ll prob­a­bly have no­ticed Toto’s toi­lets at some point or an­other: they’re dis­tin­guished by a quite mem­o­rable serif-font “TOTO” logo. Toto toi­lets aren’t quite dom­i­nant in American bath­rooms, since they have healthy com­pe­ti­tion from our home­grown toi­let cham­pi­ons American Standard and Kohler—though Toto is do­ing bet­ter and bet­ter as Americans start to fall in love with the bidet-toi­let—but glob­ally Toto is the world’s largest man­u­fac­turer of toi­lets and bidets. And in its home coun­try of Japan, Toto is sim­ply every­where: 80 per­cent of Japanese homes con­tain a Toto bidet-toi­let.

And if you’re a long­time Toto share­holder—maybe an in­vestor with a par­tic­u­lar in­ter­est in bath­room fix­tures—this has been a won­der­fully lu­cra­tive year for you. Toto’s stock is up 60 per­cent year to date; in just the last few weeks, it’s risen by 30 per­cent. Toto is do­ing bet­ter than ever: its net profit, in the first quar­ter of 2026, was up 230 per­cent year over year.

But Toto’s re­mark­able year does­n’t have much to do with toi­lets or bidets. Toto might have been founded in the 1910s to “provide a healthy and civ­i­lized way of life” through af­ford­able toi­lets, and in the decades since might have be­come the global leader in the bath­room game. But Toto also does a lot of other things. Toto man­u­fac­tures not just bidets and toi­lets but also bath­room tiles, pre­fab­ri­cated bath­room mod­ules, faucets, mod­u­lar kitchens, pho­to­cat­alytic coat­ings for build­ings, and as­sis­tive equip­ment for the el­derly. And, most im­por­tantly, Toto has a very lu­cra­tive side­line in the fab­ri­ca­tion of mem­ory chips.

Since 1988, in a once-ob­scure cor­ner of the com­pany called the “advanced ce­ram­ics di­vi­sion,” Toto has been pro­duc­ing a very par­tic­u­lar com­po­nent called the elec­tro­sta­tic chuck, or the “e-chuck.” The e-chuck is a sort of high-pre­ci­sion ce­ramic plate, about the size of a steer­ing wheel, that uses elec­tro­sta­tic force to hold a sil­i­con wafer per­fectly flat and ther­mally sta­ble while mem­ory chips are etched into it with bom­bard­ments of plasma. Making these com­po­nents is ex­tra­or­di­nar­ily dif­fi­cult, since the ce­ramic body needs to have near-zero par­ti­cle gen­er­a­tion and be pol­ished to sub­mi­cron flat­ness: and this means that there are only a few com­pa­nies in the world that are ca­pa­ble of man­u­fac­tur­ing e-chucks re­li­ably. Almost all of them—Shinko Electric, NGK, Toto, Kyocera, Sumitomo Osaka Cement, Niterra—are based in Japan.

For most of its his­tory, the ad­vanced ce­ram­ics di­vi­sion was a round­ing er­ror on Toto’s bal­ance sheet: the money maker, as it had been since the 1910s, was the toi­let and bidet busi­ness. But we’re in a new era. Demand for AI is ex­plod­ing, mean­ing that de­mand for the high-band­width mem­ory that AI data cen­ters re­quire is ex­plod­ing, mean­ing that de­mand for mem­ory chips is ex­plod­ing, mean­ing that de­mand for e-chucks is ex­plod­ing. And so Toto’s ad­vanced ce­ram­ics di­vi­sion is sud­denly the com­pa­ny’s largest busi­ness, gen­er­at­ing the ma­jor­ity of its op­er­at­ing profit. Toto’s lead­er­ship, sud­denly awash in AI-driven rev­enue, an­nounced that they would dou­ble down by in­vest­ing hun­dreds of mil­lions in ex­panded elec­tro­sta­tic chuck pro­duc­tion: the toi­let com­pany had be­come, quite un­ex­pect­edly, a sup­plier to the semi­con­duc­tor sup­ply chain.

The Toto story is a fun and in­ter­est­ing il­lus­tra­tion of cor­po­rate di­ver­si­fi­ca­tion and how strange bets can pay off. But that type of di­ver­si­fi­ca­tion—a toi­let com­pany that also pro­duces pho­to­cat­alytic coat­ing and high-pre­ci­sion com­po­nents for semi­con­duc­tors—is­n’t re­ally unique to Toto. Practically every com­pany in Japan seems to do a thou­sand very dif­fer­ent things.

Consider, for ex­am­ple, Kyocera, an­other one of the e-chuck mak­ers. Kyocera was founded in 1959 as a pro­ducer of ce­ramic in­su­la­tors for cath­ode-ray tubes; to­day it man­u­fac­tures not only in­dus­trial ce­ram­ics but also print­ers, smart­phones, ball­point pens, kitchen knives, so­lar PV mod­ules, lens com­po­nents, in­dus­trial cut­ting tools, au­to­mo­tive cam­era mod­ules, elec­tron­ics com­po­nents, semi­con­duc­tor pack­ag­ing, bio­com­pat­i­ble tooth and joint re­place­ments, UV-LED cur­ing sys­tems, LCD sys­tems, med­ical prod­ucts, and lab-grown gem­stones. Or an­other e-chuck maker. Sumitomo Osaka Cement, as you might have been able to de­duce from the name, pro­duces ce­ment and ready-mixed con­crete; but it also pro­duces op­ti­cal com­po­nents, mea­sur­ing in­stru­ments, in­dus­trial ce­ram­ics, ar­ti­fi­cial ma­rine reefs, cos­met­ics and nanopar­ti­cle ma­te­ri­als.

And this de­gree of di­ver­si­fi­ca­tion ex­tends to many of Japan’s most fa­mous com­pa­nies. Yamaha, for ex­am­ple, man­u­fac­tures pi­anos, mo­tor­cy­cles, gui­tars, drums, boats, snow­mo­biles, ATVs, au­dio equip­ment, golf clubs, ten­nis rack­ets, home ap­pli­ances, spe­cialty met­als, mold­ing and bond­ing equip­ment for semi­con­duc­tors, and in­dus­trial ro­bots. Hitachi makes nu­clear re­ac­tors, power grids, rail­way sys­tems, el­e­va­tors, semi­con­duc­tor man­u­fac­tur­ing equip­ment, med­ical imag­ing de­vices, data stor­age, IT con­sult­ing, and in­dus­trial ma­chin­ery. Even a com­pany as sim­ple as Oji, Japan’s largest pa­per com­pany, has been drawn into the pro­duc­tion of dis­pos­able di­a­pers, func­tional films, ad­he­sives, cel­lu­lose nanofibers, and wood-based EUV pho­tore­sists; and it also op­er­ates a ho­tel, an air­port cater­ing busi­ness, a con­cert hall, and an in­sur­ance agency.

All of which is to say: Japanese com­pa­nies do a lot of things.

There are, of course, other coun­tries with com­pa­nies that “do lots of things”: much of Indian eco­nomic life, for ex­am­ple, is de­fined by the sprawl­ing ac­tiv­i­ties of a few large busi­ness clans—the Adanis, the Ambanis, the Tatas, the Birlas. But India is a rel­a­tively poor coun­try with a low level of eco­nomic spe­cial­iza­tion, and the sprawl­ing con­glom­er­ates that dom­i­nate its econ­omy fo­cus on rel­a­tively sim­ple things like ce­ment, steel, ports, and telecom­mu­ni­ca­tions. Japan, by con­trast, is a wealthy, de­vel­oped so­ci­ety—by one mea­sure, the most eco­nom­i­cally com­plex coun­try in the world. What’s strik­ing about Japanese com­pa­nies is not that they do lots of dif­fer­ent things but rather that they do them very well. There are all sorts of high-pre­ci­sion in­puts—the e-chuck be­ing just one ex­am­ple—that are pro­duced vir­tu­ally only by Japanese firms.

This is very dif­fer­ent from how most wealthy coun­tries op­er­ate. American firms, for ex­am­ple, tend to pri­or­i­tize fo­cus above all else: it would be bizarre for an American pa­per mill to also op­er­ate a con­cert hall and an air­port cater­ing busi­ness, or for American Standard or Kohler to some­how have some­thing to do with semi­con­duc­tors. Even a coun­try like Germany, which matches Japan in its depth of high-pre­ci­sion firms, has noth­ing like Japan’s cor­po­rate di­ver­si­fi­ca­tion. Only a few large con­glom­er­ates, like Siemens, have any­thing ap­proach­ing the lat­eral breadth of the Japanese firm. South Korea—whose eco­nomic sys­tem was not co­in­ci­den­tally mod­eled off the Japanese one—does have a few chae­bol con­glom­er­ates, like Samsung and SK, that truly do as many things as Japanese com­pa­nies. But these are econ­omy-dom­i­nat­ing, state-en­tan­gled megafirms, cul­ti­vated as na­tional cham­pi­ons by Korean in­dus­trial pol­icy. They look noth­ing like, say, Sumitomo Osaka Cement, which is hugely di­ver­si­fied de­spite be­ing rel­a­tively small. (“Look what they need to mimic a frac­tion of our power!”)

So why are Japanese com­pa­nies like this? Why do they do so many dif­fer­ent things? And how do they man­age to do so all those dif­fer­ent things so well?

Here is the an­swer I want to sug­gest: Japanese com­pa­nies ex­cel in lots of very dif­fer­ent do­mains be­cause it’s in­her­ent in how they’re struc­tured. The form of the cor­po­ra­tion that we know and love in the United States—specialized, mar­ket-ori­ented, gov­erned by share­hold­ers—is just one form that the cor­po­ra­tion can take; but it’s not the only way to co­or­di­nate cap­i­tal and la­bor in a suc­cess­ful and prof­itable way. The pro­tean cor­po­ra­tions of Japan are best un­der­stood as a dif­fer­ent species of thing al­to­gether: bet­ter at some things, worse at oth­ers, but still highly adapted to their par­tic­u­lar en­vi­ron­ment. And the things that they’re very good at turn out to be ex­tra­or­di­nar­ily help­ful for all sorts of things in which American com­pa­nies tend to strug­gle.

To see why, we need to learn a lit­tle bit about the eco­nom­ics of in­dus­trial or­ga­ni­za­tion.

In 1990, two econ­o­mists—Paul Milgrom and John Roberts, both of Stanford—published a pa­per called “The Economics of Modern Manufacturing.” You should for­give them for the rather bland ti­tle. It was a very in­ter­est­ing, and very in­flu­en­tial, pa­per.

Milgrom and Roberts started out by not­ing that man­u­fac­tur­ing was “undergoing a rev­o­lu­tion.” One par­a­digm of pro­duc­tion was get­ting swapped out for an­other. In the past, there had been the “Fordist” par­a­digm: the fac­to­ries that worked in this par­a­digm had long as­sem­bly lines of stan­dard­ized goods, large buffer in­ven­to­ries, nar­row and repet­i­tive jobs for their work­ers, and ded­i­cated sin­gle-pur­pose ma­chin­ery. But that ap­proach was be­ing su­per­seded by a new model: “a vi­sion of a flex­i­ble mul­ti­prod­uct firm that em­pha­sizes qual­ity and speedy re­sponse to mar­ket con­di­tions while uti­liz­ing tech­no­log­i­cally ad­vanced equip­ment and new forms of or­ga­ni­za­tion.” This was the “post-Fordist” vi­sion. In prac­tice, this meant shorter pro­duc­tion runs, rapid changeovers be­tween prod­ucts, smaller and more fre­quent de­liv­er­ies from sup­pli­ers, work­ers trained to op­er­ate mul­ti­ple ma­chines and di­ag­nose prob­lems on the fly, and qual­ity con­trol em­bed­ded at every stage of the process. It was an en­tirely dif­fer­ent way of pro­duc­ing things.

The ques­tion that Milgrom and Roberts wanted to an­swer was sim­ple: why did all of these changes come as a pack­age? Maybe it made sense for a spe­cific firm to adopt shorter pro­duc­tion runs; but why did it also make sense for them to do every­thing else in the “post-Fordist” cat­e­gory? Why did the changes seem to be so tightly clus­tered, with firms ei­ther hav­ing none of these prac­tices or hav­ing all of them?

The ex­pla­na­tion that Milgrom and Roberts of­fered was that the prac­tices were com­ple­men­tary. Adopting any one of the “post-Fordist” prac­tices raised the re­turns to adopt­ing oth­ers, such that adopt­ing only one of the prac­tices did­n’t make nearly as much sense as adopt­ing the en­tire set.

Milgrom and Roberts for­mal­ized their ar­gu­ment us­ing the math­e­mat­ics of su­per­mod­u­lar func­tions. But you don’t re­ally need to know any­thing about math to un­der­stand the idea in­tu­itively.

Here’s an il­lus­tra­tion. Let’s say you run a fac­tory. You de­cide that you want your lines to pro­duce fewer de­fec­tive goods: maybe you want to im­prove your yield from 95 per­cent to 98 per­cent. So you de­cide to in­vest in bet­ter train­ing for your work­ers: maybe train­ing now lasts six weeks in­stead of two weeks. This works, and now your yield is higher; but that change makes other things more at­trac­tive too. For ex­am­ple: now that your yield is higher, it makes sense for you to re­duce your in­ven­tory, since fewer de­fects mean you no longer need a large buffer of spare parts to re­place the bad ones. So now you’ve cut your in­ven­tory: but now it makes sense for you to shorten your pro­duc­tion runs and switch more fre­quently be­tween prod­ucts, since with­out a moun­tain of in­ven­tory to work through you can af­ford to change what the line is mak­ing. And if you’re switch­ing fre­quently be­tween prod­ucts, then it makes sense for you to in­vest in flex­i­ble, re­pro­gram­ma­ble ma­chin­ery in­stead of ded­i­cated, sin­gle-pur­pose equip­ment. So one rel­a­tively small tweak shifts the en­tire cal­cu­lus of what you do.

In short: each prac­tice makes the oth­ers more valu­able, and each prac­tice is valu­able be­cause it’s im­ple­mented along­side other com­ple­men­tary prac­tices. Doing just one of these things—in­vest­ing in flex­i­ble ma­chin­ery, for ex­am­ple—does­n’t re­ally make sense alone. The prac­tice needs to work well with all the other prac­tices that you have.

So the cor­rect way to think about or­ga­ni­za­tional prac­tices, Milgrom and Roberts sug­gested, was as bun­dles. A com­plete bun­dle of prac­tices was worth more than the sum of its parts; and each part was worth less in iso­la­tion than as part of a bun­dle. So there was a co­her­ent “Fordist” bun­dle of prac­tices, and a co­her­ent “post-Fordist” bun­dle. But there was­n’t much in be­tween.

“The Economics of Modern Manufacturing” turned out to be the cor­ner­stone pa­per for an en­tire par­a­digm of think­ing about firms and how they work. (Milgrom won the Nobel Prize in 2020, though mainly for his sep­a­rate work on the the­ory of auc­tions; you can watch a de­light­ful video where he’s woken up in the mid­dle of the night by his neigh­bor and core­cip­i­ent, Robert Wilson, be­cause he was sleep­ing and did­n’t an­swer the call from the Nobel com­mit­tee.)

Most im­por­tantly, the Milgrom-Roberts frame­work gave a strong an­swer to the ques­tion of why firms are the way they are, and why it’s so hard for them to change. A firm that uses one co­her­ent bun­dle can’t eas­ily move to an­other: chang­ing one prac­tice with­out chang­ing the oth­ers will typ­i­cally make the firm strictly worse off.

So if we want to know why Japanese com­pa­nies have one ap­par­ently un­usual prac­tice—why they’re so di­ver­si­fied into count­less un­re­lated in­dus­tries—we can’t re­ally an­swer the ques­tion in iso­la­tion. We need to ask which bun­dle of prac­tices they em­ploy.

And luck­ily for us, peo­ple have looked into this ques­tion. The cen­tral fig­ure here is the econ­o­mist Masahiko Aoki, who taught at Stanford along­side Milgrom and Roberts and worked closely with both of them. Through the pa­pers that their col­lab­o­ra­tion pro­duced—some by Milgrom and Roberts, oth­ers by Aoki alone—we can sketch a pic­ture of what the Japanese cor­po­ra­tion is, and why it works the way that it does.

The first thing we should note is that Japanese com­pa­nies do a lot of things dif­fer­ently from Western com­pa­nies.

The most im­por­tant of these, by far, is life­time em­ploy­ment. Japanese firms tend to hire only at the very bot­tom, pluck­ing new re­cruits straight from high school or uni­ver­sity; they have all of those new re­cruits start on the same day of the year (the first of April); and they gen­er­ally ex­pect to keep these em­ploy­ees un­til they re­tire. Mass lay­offs are es­sen­tially un­heard of. Even in times of acute dis­tress, a Japanese firm will go to great lengths to find its em­ploy­ees po­si­tions at smaller af­fil­i­ates rather than re­leas­ing them onto the la­bor mar­ket. And in­di­vid­ual per­for­mance is­n’t re­ally a huge cri­te­rion in some­one’s ca­reer. Promotions are based largely on se­nior­ity; pay dif­fer­en­tials be­tween ranks are mod­est; and bonuses are tied to the per­for­mance of the firm.

Because they work for the same com­pany for their life and so­cial­ize largely within that firm—nomikai drink­ing par­ties with col­leagues are part of every­day cor­po­rate life—Japan­ese work­ers are of­ten deeply at­tached to their com­pany. Some em­ploy­ees even wear lapel pins to in­di­cate their cor­po­rate loy­al­ties. (For a time em­ploy­ees also sang cor­po­rate an­thems, though that tra­di­tion has faded.) There are unions, but they’re or­ga­nized within the firm: rather than a “national au­towork­ers’ union” that or­ga­nizes in both Toyota and Honda, there is a “Toyota union” and a “Honda union” that don’t have much to do with each other.

And this means that Japanese com­pa­nies strive to avoid fi­nan­cial pres­sure from out­siders. Relationships with sup­pli­ers are long­stand­ing and en­trenched: many Japanese com­pa­nies have been work­ing with the same sup­pli­ers for 50 years or longer. Outside in­vestors seek­ing to in­ter­fere in this happy pic­ture will find few av­enues for in­flu­ence. A stan­dard Japanese fir­m’s board of di­rec­tors is com­posed al­most ex­clu­sively of the fir­m’s own se­nior man­agers; a large frac­tion of the fir­m’s eq­uity is held not by out­side in­vestors but cross-held by other Japanese firms; and most of the fir­m’s fi­nanc­ing comes from a sin­gle “main bank” that pro­vides loans and mon­i­tors per­for­mance.

And as a re­sult, Japanese com­pa­nies don’t re­ally try too hard to re­turn prof­its to share­hold­ers. Earnings are mostly rein­vested, and in­vestor div­i­dends are kept low. For a long time, Japanese firms would spend as much en­ter­tain­ing the man­agers of other firms as they would on div­i­dends to share­hold­ers.

The cru­cial thing, Aoki sug­gests, is that we un­der­stand all of these dis­tinc­tive fea­tures—life­time em­ploy­ment, no ben­e­fits for in­di­vid­ual per­for­mance, hos­til­ity to out­side fi­nanc­ing—as re­flect­ing a par­tic­u­lar bun­dle: a “J-firm” bun­dle, as he calls it, as op­posed to the “H-firm” bun­dle that you en­counter in the United States or Europe. The core dif­fer­ence, Aoki says, is that while in the H-mode pro­duc­tion is or­ga­nized ver­ti­cally, in the J-mode it’s or­ga­nized hor­i­zon­tally. (H is for hi­er­ar­chy; J is for Japanese.)

Consider, for ex­am­ple, the fa­mous “Toyota Production System,” the phi­los­o­phy that de­ter­mines how Toyota makes its cars. In a Toyota fac­tory, there’s a rope called the an­don cord that runs along the as­sem­bly line, within the reach of every worker. Anyone who spots a de­fect—like, say, a mis­aligned door seal, or a bolt torqued to the wrong spec­i­fi­ca­tion—can pull the cord and halt pro­duc­tion at any time; once they’ve pulled the cord, the work­ers and team lead­ers clos­est to the prob­lem will con­verge and try to solve it on the spot. In an H-firm fac­tory, by con­trast—you can think of a clas­sic Ford plant here—de­fects are re­ported to a line man­ager, who will make a re­port and send it up the chain of com­mand, and the higher-ups will solve the prob­lem.

The an­don method is re­ally the J-mode in minia­ture. Information flows lat­er­ally, au­thor­ity to act is widely dis­trib­uted, and the peo­ple clos­est to the prob­lems are the ones who fix it. And one re­sult of the Toyota-style ap­proach is that Japanese au­tomak­ers have pro­duced fewer de­fec­tive cars than their American com­peti­tors for a very long time.

But Aoki points out that the hor­i­zon­tal co­or­di­na­tion em­bod­ied by the an­don cord does­n’t work with­out other prac­tices as well. For ex­am­ple: hor­i­zon­tal co­or­di­na­tion re­quires that work­ers know each oth­er’s jobs, since a worker who spots a prob­lem in one area of the line can only act on it if he un­der­stands what that area is sup­posed to be do­ing. But in or­der to un­der­stand each oth­er’s jobs, work­ers can­not be spe­cial­ized: they have to ro­tate across dif­fer­ent work­place func­tions to the point where they’re fa­mil­iar with much of the plan­t’s op­er­a­tions. In or­der to ro­tate across dif­fer­ent work­place func­tions, they need broad train­ing; and it makes no sense to train them broadly if you don’t keep them for a very long time. And if you have gen­er­al­ist work­ers who are around for a long time, you can’t re­ward them based on how they do in one role, be­cause then they’d have no de­sire to leave that role for an­other role where they might do worse. Instead you have to pay them based on com­pany per­for­mance, and pro­mote them based on se­nior­ity. And you also have to give them an iron­clad com­mit­ment not to fire them if eco­nomic con­di­tions worsen: if they can get laid off at any mo­ment, why would they in­vest years of ef­fort in learn­ing all the idio­syn­cratic things that your firm does?

So now you have a firm that has lots of life­time em­ploy­ees who can’t be fired, and whose skills are tai­lored to what your firm needs rather than to a par­tic­u­lar oc­cu­pa­tional cat­e­gory trans­fer­able to any em­ployer. That works very well for your com­pa­ny’s em­ploy­ees; but it makes no sense to out­siders. So the sys­tem only makes sense if the com­pany is also in­su­lated from out­side pres­sure, whether from or­ga­nized la­bor or from or­ga­nized cap­i­tal. Thus the other fea­tures of Japanese cor­po­ra­tions: firm-level unions, in­sider-dom­i­nated boards, and broad hos­til­ity to out­side cap­i­tal.

So some­thing as ap­par­ently sim­ple as hor­i­zon­tal co­or­di­na­tion only makes com­plete sense once cou­pled with an en­tire bun­dle of dif­fer­ent things. That’s why at­tempts to in­stall the an­don cord and other as­pects of the Toyota sys­tem in American car fac­to­ries have gen­er­ally pro­duced mediocre re­sults. American au­tomak­ers no­ticed the su­pe­ri­or­ity of Japanese cars a long time ago, and tried to im­ple­ment the an­don cord: but it just did­n’t work with how their com­pa­nies were or­ga­nized. In 2007, work­ers at a Toyota plant in Kentucky pulled the an­don cord 2,000 times per week; work­ers at a Ford plant in Michigan pulled it just twice a week. You can’t get all the ben­e­fits of a sin­gle prac­tice with­out in­stalling the com­plete bun­dle.

And the com­plete Japanese bun­dle, I should say, ends up pro­duc­ing some­thing with en­tirely dif­fer­ent ob­jec­tives and in­ter­ests than the American bun­dle. The H-firm ex­ists to make money, or rather to re­turn money to share­hold­ers; but the J-firm, run by its em­ploy­ees and largely in­dif­fer­ent to the in­ter­ests of share­hold­ers, ex­ists sim­ply to con­tinue ex­ist­ing. That’s why Japanese com­pa­nies are so pro­tean and will­ing to change what they do. Nintendo was founded in 1889 as a maker of hand­made play­ing cards; in the 1960s, it was pushed out of the play­ing cards game by a wave of com­pe­ti­tion; and it spent sev­eral years ex­per­i­ment­ing with new mar­kets—taxi ser­vices and in­stant rice, though con­trary to the ru­mors not love ho­tels—be­fore find­ing its way to video games. Fujifilm, which faced a near-to­tal col­lapse of pho­to­graphic film in the 2000s, sim­ply used its ex­per­tise in chem­i­cal coat­ings and fine op­tics to pivot into cos­met­ics, phar­ma­ceu­ti­cals, LCD films, and semi­con­duc­tor process ma­te­ri­als.

And that ba­sic im­pulse to­ward sur­vival is why Japanese com­pa­nies are so in­sis­tent on di­ver­si­fi­ca­tion. If you’ve made a com­mit­ment to keep peo­ple em­ployed for life, then you need to cre­ate jobs for them if their cur­rent jobs stop mak­ing sense: in­deed, you might need to keep them em­ployed even if you can’t find any­thing for them to do. If you’re not very wor­ried about prof­itabil­ity, and have lots of well-trained gen­er­al­ist em­ploy­ees, then it makes per­fect sense to rein­vest your com­pa­ny’s earn­ings by ex­pand­ing into new in­dus­tries: do­ing so not only al­lows your com­pany to sur­vive longer—your com­pa­ny’s port­fo­lio of bets is now more di­ver­si­fied and thus lower-risk—but also en­sures that you’re able to keep your sur­plus work­ers busy in one way or an­other.

If bun­dles are self-re­in­forc­ing, then the bun­dle, once es­tab­lished, will be very hard to dis­lodge. The only way to get from one peak to an­other is to change many things at once: and that kind of whole­sale trans­for­ma­tion al­most never hap­pens un­der nor­mal con­di­tions. It only hap­pens dur­ing mo­ments of acute cri­sis which make nec­es­sary a whole­sale trans­for­ma­tion in how things are done.

In the case of the Japanese bun­dle, that mo­ment of acute cri­sis was the Second World War.

In the 1920s, the Japanese econ­omy looked, on a struc­tural level, quite American. It was al­ready an in­dus­trial so­ci­ety—not quite a lead­ing in­dus­trial power, but by far the wealth­i­est coun­try in Asia—and it al­ready had ship­yards, steel mills, stock ex­changes, and a grow­ing elec­tri­cal ma­chin­ery sec­tor. Heavy in­dus­try was dom­i­nated by a few fam­ily-owned con­glom­er­ates, the za­ibatsu; but they op­er­ated more or less as nor­mal firms, rais­ing cap­i­tal on pub­lic eq­uity mar­kets and op­er­at­ing un­der share­holder dis­ci­pline. Workers, for their part, moved freely be­tween firms and or­ga­nized la­bor unions.

But in the 1930s and ’40s, as Japan mo­bi­lized for to­tal war in Asia and the Pacific, that sys­tem was re­worked en­tirely. Total war re­quired the rapid ex­pan­sion of arms pro­duc­tion, which meant chan­nel­ing vir­tu­ally the en­tirety of eco­nomic pro­duc­tion into heavy in­dus­try. Japan be­came a “national de­fense state.” Capital was rerouted out of the eq­uity mar­kets and into the bank­ing sys­tem, where it could be al­lo­cated un­der state su­per­vi­sion; firms were in­structed to pri­or­i­tize em­ploy­ees over share­hold­ers in or­der to max­i­mize pro­duc­tion; wages were stan­dard­ized by se­nior­ity to sup­press bid­ding wars for skilled la­bor and keep work­ers in place. The econ­o­mist Yukio Noguchi calls this planned econ­omy “the 1940 sys­tem.” The en­tire point was to ori­ent every as­pect of eco­nomic life to­ward max­i­mum pro­duc­tion at all costs.

Of course, Japan was­n’t alone in that re­gard. Every ma­jor bel­liger­ent in the Second World War adopted some ver­sion of a pro­duc­tion-ori­ented planned econ­omy char­ac­ter­ized by some kind of fi­nan­cial re­pres­sion. But in Japan, the 1940 sys­tem out­lasted the war by decades. Japan was de­feated in 1945, and oc­cu­pied by the American mil­i­tary un­til 1952; but af­ter an abortive at­tempt to re­or­ga­nize Japanese eco­nomic life, the Americans de­cided that the Cold War in­stead de­manded the strength­en­ing and en­trench­ment of the Japanese sys­tem. (This was dubbed the “Reverse Course.”) And the 1940 sys­tem, in its essence, sur­vived: and the Japanese firms that emerged in the twen­ti­eth cen­tury were the re­sult.

And this sys­tem, as it turned out, was re­ally good at par­tic­u­lar things. Aoki’s key in­sight was that the J-mode had a com­par­a­tive ad­van­tage in en­vi­ron­ments of mod­er­ate volatil­ity: sit­u­a­tions where con­di­tions changed fre­quently enough that rigid cen­tral plans would be out­dated be­fore they were ex­e­cuted, but not so rad­i­cally that only top-down strate­gic in­ter­ven­tion could cope. In an en­vi­ron­ment of sta­ble, pre­dictable de­mand, the H-firm did fine; in an en­vi­ron­ment of ex­treme dis­rup­tion, where the whole prod­uct line had to be rethought, cen­tral­ized au­thor­ity was in­dis­pens­able, and the H-firm also did fine. But in be­tween—where the chal­lenge was to make con­stant small ad­just­ments in a chang­ing but rec­og­niz­able par­a­digm—the J-firm ex­celled.

And this was ex­actly what Japan needed. The post­war chal­lenge was catch-up growth: Japan had to grow fast, and to do that it had to ab­sorb and im­prove upon tech­nolo­gies that the West had al­ready pi­o­neered. J-mode firms—with their col­lab­o­ra­tive cul­tures, deep pools of broadly trained work­ers, cul­ture of in­cre­men­tal shop-floor re­fine­ment, and large pools of pa­tient cap­i­tal—were per­fectly suited to the task. They could throw enor­mous amounts of pa­tient cap­i­tal at a prob­lem, spend years re­fin­ing a process with­out any im­mi­nent ex­pec­ta­tion of profit, and keep hun­dreds of broadly trained work­ers it­er­at­ing on the shop floor un­til the qual­ity of the out­put was world-class. And since prof­itabil­ity was never the pri­mary ob­jec­tive, there was no pres­sure to aban­don a dif­fi­cult mar­ket for an eas­ier one.

And the re­sults truly were re­mark­able. By the 1960s, Japanese firms had be­gun to dis­place American ones in count­less man­u­fac­tur­ing sec­tors, from au­tomak­ing to tele­vi­sion man­u­fac­tur­ing. Soon Japanese man­u­fac­tur­ing was the envy of the world. Between 1946 and 1986, Japanese real per capita GDP grew ten­fold, one of the high­est rates of growth in recorded his­tory.

But catch-up growth, by de­f­i­n­i­tion, has to end: at some point you’ve caught up, and the chal­lenge at the fron­tier is not only to re­fine what’s al­ready known but to in­vent what is not known. And par­a­digm in­ven­tion is pre­cisely the sharp dis­con­ti­nu­ity for which the J-mode has no par­tic­u­lar gift. Consensus-driven, hor­i­zon­tally co­or­di­nated or­ga­ni­za­tions are very good at re­fin­ing what al­ready ex­ists: but they are very bad at de­cid­ing what should ex­ist.

That ba­sic weak­ness is why Japanese firms are so dom­i­nant in some do­mains and en­tirely ab­sent in oth­ers. Japan ex­cels in au­to­mo­tive man­u­fac­tur­ing, ma­chine tools, in­dus­trial ro­bot­ics, op­tics, and pre­ci­sion ma­te­ri­als: do­mains char­ac­ter­ized by in­cre­men­tal re­fine­ment. But they have very lit­tle to add in soft­ware, in­ter­net plat­forms, ar­ti­fi­cial in­tel­li­gence, or elec­tric ve­hi­cles. The ar­chi­tec­ture of the Japanese firm is built to per­fect a do­main through pro­gres­sive ad­vance­ment; it’s quite poorly suited to sharp dis­con­ti­nu­ity.

Consider Sony, which by the 2000s man­u­fac­tured the world’s best portable mu­sic play­ers, its best small cam­eras, its best mo­bile dis­plays, and its best lithium-ion bat­ter­ies: every com­po­nent of what would be­come the smart­phone. Purely on a ma­te­r­ial ba­sis one would ex­pect that Sony was the best-po­si­tioned com­pany in the world to make the smart­phone. But Sony did­n’t do it. It was Apple, an H-firm par ex­cel­lence, that reimag­ined the en­tire prod­uct cat­e­gory from the top down, largely be­cause Apple was or­ga­nized to give ex­tra­or­di­nary power to a sin­gle vi­sion­ary leader.

By the time that Aoki, Milgrom, and Roberts were writ­ing in the last few years of the twen­ti­eth cen­tury, the shine of the Japanese model had al­ready be­gun to fade. Asset prices in Japan had be­gun to de­flate in 1990, in­au­gu­rat­ing the coun­try’s “lost decades.” Firms that had bal­anced against their as­sets at in­flated prices now had more debt than they were worth, and the closely-af­fil­i­ated banks that had lent them the money were now buried in so much bad debt that mark­ing the loans to mar­ket value would have de­stroyed both the com­pa­nies and them­selves. Bankruptcies and mass lay­offs were im­pos­si­ble in the Japanese sys­tem: a wave of mass lay­offs or cor­po­rate re­struc­tur­ings would have un­der­mined the en­tire so­cial set­tle­ment that gov­erned Japanese life.

So debts weren’t called: banks and com­pa­nies sim­ply sol­diered on, “zombies” sus­pended in a state be­tween life and death. Japanese busi­ness was no longer the envy of any­one in par­tic­u­lar.

The Japanese bun­dle was ex­cep­tion­ally good, in­deed world-his­tor­i­cally good, at catch-up growth; but it was very bad at fig­ur­ing out what to do once it found it­self in trou­ble. Organizational bun­dles are re­mark­ably re­sis­tant to change, even as con­di­tions them­selves change.

This is ex­actly what those who tried to re­form Japanese cor­po­rate life in the last few decades have dis­cov­ered.

In the 1990s, Fujitsu and other elec­tron­ics firms ex­per­i­mented with per­for­mance-based pay: the idea had worked well at American firms and seemed like an ob­vi­ous way to make Japanese work­ers more pro­duc­tive and thus to get the econ­omy out of its slump. But per­for­mance-based pay did­n’t co­here at all with the rest of the Japanese sys­tem. Team co­op­er­a­tion broke down, be­cause out­put was mea­sured in­di­vid­u­ally and help­ing a col­league now hurt you in the rank­ings; se­nior en­gi­neers stopped men­tor­ing ju­niors, be­cause men­tor­ing was un­com­pen­sated and the men­tored ju­niors be­came fu­ture ri­vals; and man­agers strug­gled to keep their teams from dis­band­ing. By 2001 Fujitsu had aban­doned the prac­tice. The episode be­came so in­fa­mous that one for­mer Fujitsu ex­ec­u­tive wrote a book about it, ti­tled The Downfall of Performance-Based Pay at Fujitsu as Seen by an Insider.

This is ex­actly what the eco­nom­ics of in­dus­trial or­ga­ni­za­tion would pre­dict. High-powered in­di­vid­ual per­for­mance pay makes sense when jobs are nar­row, tasks are clearly mea­sur­able, and co­op­er­a­tion is inessen­tial; but it makes no sense within the bun­dle that de­fines the Japanese firm. The same goes for prac­ti­cally every in­sti­tu­tion: piece­meal changes to a co­her­ent bun­dle of or­ga­ni­za­tional prac­tices don’t re­ally work; they only make things work less well. A re­form that moves one co­or­di­nate but leaves the oth­ers in place pro­duces a kind of or­ga­ni­za­tional chimera, an en­tity that has lost the co­her­ence of its old bun­dle with­out gain­ing the ben­e­fits of the new one.

But the Japanese bun­dle, how­ever an­ti­quated it might seem, still does re­sult in some of the most re­mark­able com­pa­nies in the world. The type of deep process knowl­edge that has ac­creted within com­pa­nies like Kyocera and Toto is al­most im­pos­si­ble to repli­cate. The American bun­dle of prac­tices, with its em­pha­sis on prof­its, en­tre­pre­neur­ship, and fi­nan­cial­ized risk, is prob­a­bly the world’s best at in­no­va­tion and fron­tier dis­cov­ery. But as we are now dis­cov­er­ing with the global rush on mem­ory chips and other es­o­teric parts of the semi­con­duc­tor sup­ply chain, our en­tre­pre­neur­ial American sys­tem only works com­pletely if it’s paired with a very non-en­tre­pre­neur­ial sys­tem like the one that we find in Japan.

No posts

For the last few years, while fi­nally earn­ing my be­lated Bachelor’s Degree in the University of London’s World Class pro­gram, I’ve met some amaz­ing peo­ple from all across the world, com­plet­ing their de­grees af­ter hours while bal­anc­ing work, fam­i­lies, and other ex­tremely chal­leng­ing cir­cum­stances.

But few have cir­cum­stances as chal­leng­ing as Django’s.

Django is a Congolese refugee liv­ing in a camp in Western Uganda. He has no re­li­able elec­tric­ity in the camp and runs his lap­top on so­lar power; his in­ter­net ac­cess comes from Airtel min­utes, which he needs to ra­tion on a very lim­ited in­come. This makes com­plet­ing a re­mote Computer Science de­gree - with video lec­tures, as­sign­ments that need to be up­loaded on time and re­motely proc­tored ex­ams - at times seem nearly im­pos­si­ble.

Recently, Django found him­self in a new predica­ment.

His lap­top’s moth­er­board burned out af­ter ac­ci­den­tally con­nect­ing a USB ca­ble to a 12V bat­tery out­put, and the next se­mes­ter was set to start in a few weeks. He had tried to re­pair it to no avail: the lap­top con­tin­ued to over­heat and would not turn on.

I have a few old MacBooks that are in work­ing or­der, just sit­ting around the house. So I of­fered to send one to him.

Naively, I fig­ured that I’d just go to my lo­cal post of­fice, put it in a box with some bub­ble wrap, and he’d have it in a few days/​weeks. However, the process turned out to be far more com­pli­cated than ex­pected.

First at­tempt

I dusted off the lap­top, wiped the hard drive and re­in­stalled ma­cOS us­ing Apple’s in­struc­tions. I wiped the screen with a lint-free cloth wet­ted with only wa­ter, avoid­ing al­co­hol-based clean­ing prod­ucts. For the key­board, I used stan­dard mul­ti­pur­pose wipes to re­move my an­cient fin­ger grime.

I asked ChatGPT how to send the lap­top, and it gave me a spiel about find­ing a re­li­able freight ser­vice or courier. I asked whether it would be pos­si­ble to send via Australia Post (our na­tional mail ser­vice) any­way, since an out­let was down the road from my house. Apparently, I could, as long as the lithium bat­tery was in­stalled in the de­vice.

At the post of­fice, a friendly staff mem­ber con­firmed it could be sent, helped me pack­age it up se­curely, and it cost me $111.60 AUD.

I shared the track­ing num­ber with Django on April 1st. Six days later, he mes­saged to say it looked like the pack­age was ar­riv­ing soon.

However, a few hours later, I got a knock at my door. The pack­age had been re­turned to my house af­ter fail­ing to be processed at the dis­tri­b­u­tion cen­tre.

Turns out Australia Post won’t ship de­vices con­tain­ing lithium bat­ter­ies in­ter­na­tion­ally by air, af­ter all. I should have lis­tened to ChatGPT.

I searched for how to ac­tu­ally send a lap­top over­seas, and a few freight ser­vices with well-tuned SEO popped up. I found a ven­dor called Pack & Send with an of­fice a few km from my house.

I sub­mit­ted a quote re­quest on their web­site, and they called me back with a quote of $213 AUD.

I walked about 45 min­utes to the of­fice, in a neigh­bour­ing in­dus­trial sub­urb.

The woman at the front desk laughed at the pack­ag­ing job I had done at the Post Office and said she’d repack­age it prop­erly.

This was April 9th, which was about 6 weeks into the Strait of Hormuz cri­sis, which had thrown global freight routes into chaos, so she told me to ex­pect de­lays. She also men­tioned there would be ad­di­tional costs for Django in Uganda: cus­toms fees and taxes she could­n’t es­ti­mate, and that he would need a buffer of at least $50 – 100 on his end.

Since money was ex­tremely tight on Django’s end, I of­fered to send some for the buffer. Most Ugandan ser­vices ac­cept Airtel Money, which I knew could be trans­ferred eas­ily via the WorldRemit app. He re­ceived the money in about 5 min­utes.

Clearing Ugandan cus­toms

Over the next few days, the pack­age made its way through nine coun­tries be­fore reach­ing the Netherlands.

Then, on April 15th, Django re­ceived an email from an EHS Africa Logistics Agent with in­struc­tions on the next step: there was an agency fee of UGX 95,000 (~$35 AUD), then he’d need to reg­is­ter via the Uganda Revenue Authority (URA) Portal, com­plete a tax as­sess­ment, and pay any ap­plic­a­ble taxes. All of this had to be cleared within 5 work­ing days, or we would be pay­ing stor­age fees, the agent warned.

However, reg­is­tra­tion re­quired a Tax Identification Number (TIN), which Django, a refugee, does not have. Getting one re­quires phys­i­cally pre­sent­ing at a URA of­fice, and there was none nearby in his dis­trict.

Django sent an email to the EHS rep ask­ing if it could be com­pleted with­out a TIN, but re­ceived no re­ply. So he de­cided to sort it him­self.

Getting a TIN as a refugee

In his words:

Regarding the TIN, I first tried to do it on­line be­cause the URA web­site sug­gested that the process could be started elec­tron­i­cally. However, I dis­cov­ered that for refugees and non-cit­i­zens, it was not truly an on­line process. Ugandan cit­i­zens could com­plete every­thing on­line, but refugees could only be­gin the ap­pli­ca­tion on­line and then had to phys­i­cally ap­pear at a URA of­fice with doc­u­ments for ver­i­fi­ca­tion be­fore ap­proval.

Even start­ing the on­line part was dif­fi­cult. The ap­pli­ca­tion form was an old Excel macro form that could not prop­erly work on my phone. At that time, I did not yet have a com­puter, so there was prac­ti­cally no way for me to com­plete or up­load the form my­self.

I then went to a nearby or­ga­ni­za­tion that says it as­sists refugee youth. They told me they could help fill and sub­mit the form, but they asked me for the equiv­a­lent of about 20 USD just to com­plete the sub­mis­sion process, and they also told me the process could take around two weeks. At an­other point, I was even told an amount closer to 40 USD. The dif­fi­cult part was that this was not even the full ser­vice - af­ter pay­ing, I would still have to per­son­ally travel to a URA of­fice for phys­i­cal ver­i­fi­ca­tion.

Since I ur­gently needed the TIN for cus­toms clear­ance, I de­cided to do the rest my­self in­stead of wait­ing.

From my area in the refugee set­tle­ment, I first walked for about two hours to reach a trad­ing cen­ter “Bukere” where I could get a boda-boda mo­tor­cy­cle. From there, I trav­elled to the main road in “Kyegegwa” and boarded a pub­lic taxi/​bus to an­other town, “Mubende”, where there was a URA of­fice. The taxi con­stantly stopped along the road pick­ing up pas­sen­gers, so the trip took around three hours.

When I reached the town, I first went to a po­lice sta­tion to ask for di­rec­tions be­cause I did not know where the URA of­fice was lo­cated. A boda-boda rider was then called to take me there.

At the URA of­fice, I was told that I needed to re­turn all the way back to the refugee set­tle­ment and ob­tain a lo­cal au­tho­riza­tion let­ter from the camp lead­er­ship be­fore they could process my re­quest. That day was a Friday. I ex­plained re­peat­edly that I had trav­elled from very far away, us­ing money that had orig­i­nally been sent for the lap­top clear­ance process it­self, and that re­turn­ing on Monday would be ex­tremely dif­fi­cult for me. But they con­tin­ued in­sist­ing.

At some point, one man qui­etly pulled me aside and sug­gested that if I “gave some­thing,” they could help solve the prob­lem more eas­ily. I re­fused. After some time, an­other of­fi­cer fi­nally agreed to look at my doc­u­ments. However, af­ter open­ing the file, he told me that “the net­work was down” and that I should come back on Monday.

He then told me to walk around town for one or two hours and come back later to check whether the net­work had re­turned. I did ex­actly that. When I re­turned, he again told me the net­work was still un­avail­able. So I re­mained sit­ting there in the of­fice area for hours.

What made the sit­u­a­tion painful was that while I was be­ing told the net­work was not work­ing, I could clearly see other peo­ple ar­riv­ing, be­ing served nor­mally, and leav­ing. Many were speak­ing lo­cal lan­guages, while I was strug­gling to ex­plain my­self in English and re­peat­edly try­ing to con­vince them that I had nowhere else to go and no money for re­peated jour­neys.

After wait­ing sev­eral more hours, I ap­proached again and asked whether they could please try once more. At that point, the same of­fi­cer sud­denly re­opened the file and com­pleted the en­tire process in only a few min­utes. The ac­tual gen­er­a­tion and print­ing of the TIN cer­tifi­cate took less than ten min­utes.

What had taken nearly two full days of trav­el­ling, wait­ing, stress, ne­go­ti­a­tion, and in­di­rect re­quests for un­of­fi­cial pay­ments was fi­nally com­pleted in a mat­ter of min­utes.

When I fi­nally re­ceived the printed TIN cer­tifi­cate, I was hon­estly over­whelmed with re­lief and grat­i­tude. Before leav­ing, I found my­self in­di­vid­u­ally thank­ing al­most every­one in the of­fice - in­clud­ing some of the peo­ple who had ini­tially re­fused to help me - sim­ply be­cause, af­ter every­thing, I was deeply re­lieved that the process was fi­nally over.

- Django

With the TIN in hand, Django could fi­nally com­plete the Agent Appointment in the URA Portal and the tax work­sheet. Taxes to­talled UGX 127,657.76 (~$47 AUD), bring­ing the run­ning to­tal — in­clud­ing the failed Australia Post at­tempt — to ~$407 AUD, al­ready close to the lap­top’s value.

That was April 17th - three days be­fore the new se­mes­ter was due to start, with the lap­top still sit­ting in the Netherlands.

Laptop seizure

The pack­age next trav­elled to France → UK and fi­nally to Uganda. However, we re­ceived a no­tice that there were “delivery re­stric­tions”.

This caused the pack­age to re-route through: UK → UAE → Kenya → Uganda.

Finally, on May 6th, it was in Uganda. But there was a new prob­lem.

According to Ugandan reg­u­la­tions, used lap­tops can­not be im­ported un­less ac­com­pa­nied by an orig­i­nal pur­chase re­ceipt show­ing the ex­act pur­chase price. A cus­toms in­voice in­di­cat­ing an es­ti­mated value and not­ing that the lap­top is used was not suf­fi­cient. Customs tem­porar­ily seized it.

We were told FedEx were in con­tact with the au­thor­i­ties to re­solve the sit­u­a­tion and were await­ing of­fi­cial com­mu­ni­ca­tion from cus­toms spec­i­fy­ing the ad­di­tional pay­ment re­quired. However, EHS in­formed us their sys­tem was down, caus­ing fur­ther de­lays.

Meanwhile, Django man­aged to bor­row a lap­top for a small daily fee, so he could start the se­mes­ter while wait­ing.

After some con­vinc­ing, the au­thor­i­ties ac­cepted a con­fir­ma­tion that the lap­top was a used gift. The EHS rep­re­sen­ta­tive re­quested a top-up pay­ment of UGX 50,000 (~$18.50 AUD) to sub­mit the amend­ment.

Django paid on May 8th. A day later, the ship­ment was re­leased from cus­toms and marked ready for de­liv­ery.

The fi­nal tally:

Finding the lap­top in a hard­ware store

We re­ceived a no­ti­fi­ca­tion that the lap­top was out for de­liv­ery in Kampala, al­ready about a 4-hour drive from Django’s home. He fol­lowed up and was told it had gone to Mbale - east of Kampala, and even fur­ther from him. Then he was told to wait un­til Thursday, the 14th, an­other 4 days away.

Meanwhile, the track­ing showed an Attempt Failure.

So Django took mat­ters into his own hands. In his words:

Since the track­ing in­for­ma­tion was no longer re­li­able, I started trac­ing back through the dif­fer­ent phone num­bers that had pre­vi­ously called me re­gard­ing the ship­ment.

Some of those num­bers no longer an­swered. Eventually, I called a woman from an­other town who had ear­lier con­tacted me when the lap­top had tem­porar­ily passed through her hands. At that stage, the track­ing sys­tem had de­scribed the ship­ment as be­ing with a “third-party trusted de­liv­ery agent.”

She ex­plained that she no longer had pos­ses­sion of it and then gave me an­other phone num­ber to call.

I called the new num­ber, and the man told me that the ship­ment had al­ready been passed again to yet an­other de­liv­ery per­son. I asked him when I should ex­pect to re­ceive it, and he sim­ply replied, “They will call you.”

After some time, I called him back. He said that the de­liv­ery peo­ple were al­ready sup­posed to have con­tacted me by then. But in­stead of re­ceiv­ing a proper call, I only re­ceived a missed call from a new num­ber.

I im­me­di­ately called them back. The man who an­swered told me that he was “about to find any boda-boda rider” and sim­ply give him the lap­top to­gether with some trans­port money so that the rider could bring it to me.

I asked him where ex­actly he was and whether he per­son­ally knew the boda-boda rider he in­tended to trust with the ship­ment. His an­swer was es­sen­tially that he would just stop any pass­ing mo­tor­cy­cle rider and hand over the pack­age.

At first, I tried to ac­cept the sit­u­a­tion calmly. But af­ter a few min­utes, I sud­denly re­al­ized the re­al­ity of what was hap­pen­ing: my lap­top, which had al­ready crossed oceans and mul­ti­ple cus­toms stages, was now about to be handed to a com­pletely ran­dom mo­tor­cy­cle rider by a man whose full iden­tity I did not even know my­self.

That was the mo­ment I de­cided I could not con­tinue wait­ing pas­sively any­more.

I im­me­di­ately called him back and told him not to hand the pack­age to any­one else. I asked him to tell me ex­actly where he was so that I could come per­son­ally and col­lect it my­self.

The mo­ment I re­ceived the lo­ca­tion, I left im­me­di­ately. I did not even stop to change prop­erly; I was still wear­ing san­dals. I rushed to find a boda-boda mo­tor­cy­cle and be­gan trav­el­ling to­ward the lo­ca­tion as quickly as pos­si­ble.

About three hours later, I fi­nally ar­rived at the place where the lap­top was sup­pos­edly wait­ing for me.

But when I reached the petrol sta­tion that had been de­scribed to me over the phone, there was no ob­vi­ous de­liv­ery of­fice, no courier sign, and no per­son vis­i­bly wait­ing with a pack­age.

So I called the man again.

After sev­eral min­utes of walk­ing and phone com­mu­ni­ca­tion, I fi­nally reached a small hard­ware busi­ness they had de­scribed. This was not a de­liv­ery of­fice. It was an or­di­nary hard­ware shop filled with metal ma­te­ri­als, con­struc­tion tools, and iron equip­ment. Outside, peo­ple were weld­ing metal doors and iron struc­tures. There was noth­ing there sug­gest­ing elec­tron­ics, parcels, or courier ser­vices.

Then, to my com­plete sur­prise, the hard­ware shop owner climbed onto a shelf among the metal equip­ment and pulled out a card­board box that had been sit­ting there be­tween hard­ware items and iron ma­te­ri­als.

That box was my lap­top.

I re­mem­ber stand­ing there al­most un­able to process the sit­u­a­tion. A MacBook that had trav­elled in­ter­na­tion­ally, passed through cus­toms pro­ce­dures, taxes, agency clear­ances, and mul­ti­ple trans­port stages was now rest­ing qui­etly on a dusty hard­ware shelf be­side weld­ing equip­ment.

Before leav­ing, I asked him whether he even knew what was in­side the pack­age. He an­swered very ca­su­ally that he had no idea and that he did not need to know. I then asked whether he at least knew which com­pany had en­trusted him with the de­liv­ery. He replied that it was sim­ply “a friend” who had asked him to tem­porar­ily keep the box un­til some­one came to col­lect it.

So right there, in­side a hard­ware shop sur­rounded by iron bars, metal dust, and weld­ing sparks, I fi­nally opened the box.

And there it was.

The MacBook had sur­vived the en­tire jour­ney.

I switched it on briefly, and that was ac­tu­ally the mo­ment when the hard­ware shop owner him­self sud­denly be­came ex­cited. Until then, he had ap­par­ently not known what kind of item he had been stor­ing on his shelf. Seeing the Apple logo ap­pear on the screen, he im­me­di­ately smiled and said some­thing along the lines of, “Ah… a MacBook is a MacBook. Apple is still Apple.”

At that mo­ment, af­ter all the stress, un­cer­tainty, trav­el­ling, de­lays, calls, ne­go­ti­a­tions, and con­fu­sion, the at­mos­phere com­pletely changed.

We shook hands, laughed, and gen­uinely cel­e­brated the fact that the lap­top had fi­nally ar­rived safely.

Interestingly, even af­ter I had phys­i­cally re­ceived the lap­top, the elec­tronic track­ing sys­tem still had not prop­erly up­dated to show that the ship­ment had been de­liv­ered.

- Django

Mission ac­com­plished

On his way home, Django sent me this email:

Dear Lex,

I am very happy to let you know that I have fi­nally re­ceived the ship­ment safely. I turned it on, and every­thing ap­pears to be work­ing prop­erly.

At the mo­ment, I am still on my way back home and not yet fully set­tled, but I wanted to send this mes­sage im­me­di­ately to let you know that it has safely reached me.

Honestly, af­ter fi­nally re­ceiv­ing it, I felt that all the trou­ble and ef­fort were worth it. Earlier, we had talked about how ex­pen­sive the whole process seemed and how it might have been eas­ier to buy some­thing lo­cally in­stead. But once I held it in my hands, even the per­son help­ing me and I both reached the same con­clu­sion: an Apple is still an Apple.

This is my first Apple de­vice in my life, and now I truly un­der­stand why peo­ple speak so highly about it.

Thank you very much again, Lex. I truly ap­pre­ci­ate your kind­ness, pa­tience, and sup­port through­out this jour­ney.

Kind re­gards,

Django

Finally, on May 13th, af­ter ~36,000 km across 12 coun­tries over 42 days, the lap­top had ar­rived.

Due to fore­see­able com­pat­i­bil­ity and se­cu­rity is­sues, yt-dlp’s sup­port for Bun as an ejs-com­pat­i­ble JavaScript run­time is be­ing both lim­ited and dep­re­cated.

As of the next yt-dlp and/​or ejs re­lease, only Bun ver­sions 1.2.11 through 1.3.14 will be sup­ported. The ra­tio­nale for this change is twofold:

The min­i­mum re­quired ver­sion is be­ing raised from 1.0.31 to 1.2.11 be­cause build­ing the ejs pack­age with a ver­sion ear­lier than 1.2.0 re­sults in the ejs lock­file be­ing ig­nored, which is a sig­nif­i­cant se­cu­rity con­cern for users when con­sid­er­ing all of the re­cent npm sup­ply chain at­tacks. Additionally, the sup­port floor is be­ing bumped to 1.2.11 in­stead of 1.2.0 be­cause the ejs test suite can­not be run with ver­sions of Bun ear­lier than 1.2.11.

The min­i­mum re­quired ver­sion is be­ing raised from 1.0.31 to 1.2.11 be­cause build­ing the ejs pack­age with a ver­sion ear­lier than 1.2.0 re­sults in the ejs lock­file be­ing ig­nored, which is a sig­nif­i­cant se­cu­rity con­cern for users when con­sid­er­ing all of the re­cent npm sup­ply chain at­tacks. Additionally, the sup­port floor is be­ing bumped to 1.2.11 in­stead of 1.2.0 be­cause the ejs test suite can­not be run with ver­sions of Bun ear­lier than 1.2.11.

Bun was re­cently rewrit­ten in Rust us­ing Claude, and its de­vel­op­ment seems to have taken a turn to­wards be­ing fully vibe-coded. This is alarm­ing and dis­ap­point­ing for a num­ber of rea­sons, and frankly it seems like a fu­ture headache that we’d pre­fer to avoid. We are adding a sup­port ceil­ing of ver­sion 1.3.14, as that is the last re­lease built from the orig­i­nal zig code­base.

Bun was re­cently rewrit­ten in Rust us­ing Claude, and its de­vel­op­ment seems to have taken a turn to­wards be­ing fully vibe-coded. This is alarm­ing and dis­ap­point­ing for a num­ber of rea­sons, and frankly it seems like a fu­ture headache that we’d pre­fer to avoid. We are adding a sup­port ceil­ing of ver­sion 1.3.14, as that is the last re­lease built from the orig­i­nal zig code­base.

Bun sup­port will also be dep­re­cated. This means that while yt-dlp will con­tinue to sup­port this nar­rower range of Bun ver­sions for as long as they’re able to meet the needs of yt-dlp and ejs, we re­serve the right to com­pletely drop sup­port for Bun should it at any point be­come too bur­den­some to main­tain.

See the EJS wiki ar­ti­cle for more in­for­ma­tion about sup­ported JavaScript run­times, but note that it has not yet been up­dated to re­flect the changes an­nounced in this post.

Last month, we launched Project Glasswing, our col­lab­o­ra­tive ef­fort to se­cure the world’s most crit­i­cal soft­ware be­fore in­creas­ingly ca­pa­ble AI mod­els can be turned against it.

Since then, we and our ap­prox­i­mately 50 part­ners have used Claude Mythos Preview to find more than ten thou­sand high- or crit­i­cal-sever­ity vul­ner­a­bil­i­ties across the most sys­tem­i­cally im­por­tant soft­ware in the world. Progress on soft­ware se­cu­rity used to be lim­ited by how quickly we could find new vul­ner­a­bil­i­ties. Now it’s lim­ited by how quickly we can ver­ify, dis­close, and patch the large num­bers of vul­ner­a­bil­i­ties found by AI.

In this post, we dis­cuss what we’ve learned about this crit­i­cal chal­lenge for cy­ber­se­cu­rity in the first weeks of Project Glasswing. We fo­cus on the early pub­lic ev­i­dence of Mythos Preview’s per­for­mance, on the ini­tial re­sults of our ef­fort to scan thou­sands of open-source soft­ware pro­jects, and on what this progress means for cy­berde­fend­ers to­day. We also cover what to ex­pect next from Project Glasswing, and how we’re think­ing about re­leas­ing Mythos-class mod­els in the fu­ture.

Our early re­sults

Our ap­proach to dis­cussing Mythos Preview’s find­ings

The soft­ware in­dus­try’s long­stand­ing con­ven­tion is to dis­close new vul­ner­a­bil­i­ties 90 days af­ter they’re dis­cov­ered (or, if a patch is cre­ated be­fore the 90 days is up, around 45 days af­ter the patch be­comes avail­able). This al­lows time for end users to up­date their soft­ware be­fore a vul­ner­a­bil­ity can be ex­ploited by at­tack­ers. Our own Coordinated Vulnerability Disclosure pol­icy takes this ap­proach.

However, this means that dis­closed vul­ner­a­bil­i­ties are a lag­ging in­di­ca­tor of the ac­cel­er­at­ing fron­tier of AI mod­els’ cy­ber ca­pa­bil­i­ties: we’re not yet at the point where we can fully de­tail our part­ners’ find­ings with Mythos Preview with­out putting end users at risk. Instead, we pro­vide il­lus­tra­tive ex­am­ples of the mod­el’s per­for­mance, along with ag­gre­gate sta­tis­tics on our progress to date. Once patches for the vul­ner­a­bil­i­ties that Mythos Preview has dis­cov­ered are widely de­ployed, we’ll pro­vide much more de­tail about what we’ve learned.

Evidence from our part­ners and ex­ter­nal testers

Project Glasswing’s ini­tial part­ners build and main­tain soft­ware that is fun­da­men­tal to the func­tion­ing of the in­ter­net and other es­sen­tial in­fra­struc­ture. Fixing flaws in their code re­duces risk for the many other or­ga­ni­za­tions that rely on it, and there­fore re­duces risk for bil­lions of end users.

After one month, most part­ners have each found hun­dreds of crit­i­cal- or high-sever­ity vul­ner­a­bil­i­ties in their soft­ware. Collectively, they’ve found more than ten thou­sand. Several have told us that their rate of bug-find­ing has in­creased by more than a fac­tor of ten. For in­stance, Cloudflare has found 2,000 bugs (400 of which are high- or crit­i­cal-sever­ity) across their crit­i­cal-path sys­tems, with a false pos­i­tive rate that Cloudflare’s team con­sid­ers bet­ter than hu­man testers.

This tal­lies with ex­ter­nal testers’ ex­pe­ri­ence of Mythos Preview’s per­for­mance, and with re­cent ad­di­tional eval­u­a­tions of the model:

The UK’s AI Security Institute re­ports that Mythos Preview is the first model to solve both of their cy­ber ranges (simulations of mul­ti­step cy­ber­at­tacks) end to end;

Mozilla found and fixed 271 vul­ner­a­bil­i­ties in Firefox 150 while test­ing Mythos Preview—over ten times more than they found in Firefox 148 with Claude Opus 4.6;

XBOW, an in­de­pen­dent se­cu­rity plat­form, re­ports that Mythos Preview is a “significant step up over all ex­ist­ing mod­els” on its web ex­ploit bench­mark, and pro­vides “absolutely un­prece­dented pre­ci­sion” on a to­ken-for-to­ken ba­sis;

ExploitBench and ExploitGym, two re­cently re­leased aca­d­e­mic bench­marks for mea­sur­ing mod­els’ ex­ploit de­vel­op­ment ca­pa­bil­i­ties, show Mythos Preview as the strongest per­former. We dis­cuss what these bench­marks tell us about the model in more de­tail on our Frontier Red Team blog.

More gen­er­ally, we’re now see­ing that patched soft­ware is be­ing rolled out much more quickly. The lat­est Palo Alto Networks re­lease in­cluded over five times as many patches as usual. Microsoft has re­ported that the num­ber of new patches they’ll re­lease will “continue trend­ing larger for some time.” And Oracle is find­ing and fix­ing vul­ner­a­bil­i­ties across its prod­ucts and cloud mul­ti­ple times faster than be­fore.

Mythos Preview has also proved use­ful for other kinds of se­cu­rity work. For ex­am­ple, at one of our Glasswing part­ner banks, Mythos Preview helped to de­tect and pre­vent a fraud­u­lent $1.5 mil­lion wire trans­fer af­ter a threat ac­tor com­pro­mised a cus­tomer’s email ac­count and made spoof phone calls.

Open-source soft­ware

For the last few months, Anthropic has used Mythos Preview to scan more than 1,000 open-source pro­jects, which col­lec­tively un­der­pin much of the in­ter­net—and much of our own in­fra­struc­ture.

So far, Mythos Preview has found what it es­ti­mates are 6,202 high- or crit­i­cal-sever­ity vul­ner­a­bil­i­ties in these pro­jects (out of 23,019 in to­tal, in­clud­ing those it es­ti­mates as medium- or low-sever­ity).

1,752 of those high- or crit­i­cal-rated vul­ner­a­bil­i­ties have now been care­fully as­sessed by one of six in­de­pen­dent se­cu­rity re­search firms, or in a small num­ber of cases by our­selves. Of these, 90.6% (1,587) have proved to be valid true pos­i­tives, and 62.4% (1,094) were con­firmed as ei­ther high- or crit­i­cal-sever­ity. That means that even if Mythos Preview finds no fur­ther vul­ner­a­bil­i­ties, at our cur­rent post-triage true-pos­i­tive rates, it’s on track to have sur­faced nearly 3,900 high- or crit­i­cal-sever­ity vul­ner­a­bil­i­ties in open-source code—in ad­di­tion to those it has found for Project Glasswing’s part­ners. To be clear, we in­tend to con­tinue scan­ning open-source code for some time, so we ex­pect this num­ber to rise.

One ex­am­ple of an open-source vul­ner­a­bil­ity that Mythos Preview de­tected was in wolf­SSL, an open-source cryp­tog­ra­phy li­brary that’s known for its se­cu­rity and is used by bil­lions of de­vices world­wide. Mythos Preview con­structed an ex­ploit that would let an at­tacker forge cer­tifi­cates that would (for in­stance) al­low them to host a fake web­site for a bank or email provider. The web­site would look per­fectly le­git­i­mate to an end user, de­spite be­ing con­trolled by the at­tacker. We’ll re­lease our full tech­ni­cal analy­sis of this now-patched vul­ner­a­bil­ity (assigned CVE-2026 – 5194) in the com­ing weeks.

As we noted above, the bot­tle­neck in fix­ing bugs like these is the hu­man ca­pac­ity to triage, re­port, and de­sign and de­ploy patches for them. Finding them in the first place has be­come vastly more straight­for­ward with Mythos Preview. We’ve cre­ated a dash­board of the open-source vul­ner­a­bil­i­ties we’ve scanned, be­low, which shows the dif­fer­ent steps in our dis­clo­sure process and will track our progress over time. This shows vul­ner­a­bil­i­ties of all sever­ity lev­els, rather than only the sub­set ini­tially as­sessed as high- or crit­i­cal-sever­ity by Mythos Preview. Note the steep drop-off at each phase, re­flect­ing the amount of hu­man ef­fort re­quired to ver­ify and fix each of the vul­ner­a­bil­i­ties.

Our process for triag­ing vul­ner­a­bil­i­ties is in­ten­sive. First, we or one of the ex­ter­nal se­cu­rity firms we work with re­pro­duce the is­sue that Mythos has found and re-as­sess its sever­ity. Once we’ve con­firmed that a vul­ner­a­bil­ity is real, we check for whether there are al­ready fixes in place, and write a de­tailed re­port to the soft­ware’s main­tain­ers. We take con­sid­er­able care here: on top of the reg­u­lar chal­lenges of main­tain­ing open-source soft­ware, main­tain­ers have been fac­ing a del­uge of low-qual­ity, AI-generated bug re­ports. Indeed, sev­eral main­tain­ers have told us they’re cur­rently se­verely ca­pac­ity con­strained, and some have even asked us to slow down our rate of our dis­clo­sures be­cause they need more time to de­sign patches. (On av­er­age, a high- or crit­i­cal-sever­ity bug found by Mythos Preview takes two weeks to patch.)

On main­tain­ers’ re­quest, we some­times dis­close bugs di­rectly, with­out fur­ther as­sess­ment. We’ve now re­ported 1,129 such un­vet­ted bugs, of which Mythos Preview es­ti­mated that 175 were high- or crit­i­cal-sever­ity.

We es­ti­mate that we’ve dis­closed 530 high- or crit­i­cal-sever­ity bugs to main­tain­ers so far. This is based on Claude’s as­sess­ment of sever­ity in the case of di­rect dis­clo­sures, and main­tain­ers’ or our se­cu­rity part­ners’ as­sess­ment where avail­able. There are a fur­ther 827 con­firmed vul­ner­a­bil­i­ties (estimated as high- or crit­i­cal-sever­ity in the same man­ner) that we’re aim­ing to dis­close as quickly as pos­si­ble.

75 of the 530 high- or crit­i­cal-sever­ity bugs we’ve re­ported have now been patched, and 65 of those have been given pub­lic ad­vi­sories. The num­ber of patches is still rel­a­tively low for three rea­sons. First, we’re still early in the 90-day win­dow that’s set out in our Coordinated Vulnerability Disclosure pol­icy: we ex­pect many more patches to land soon. Second, we are likely to be un­der­count­ing patches be­cause some vul­ner­a­bil­i­ties are patched with­out a pub­lic ad­vi­sory: in those cases, we’re re­liant on scan­ning for the patches our­selves us­ing Claude. Third, the low vol­ume of patches re­flects a gen­uine prob­lem: even at our rel­a­tively slow pace of dis­clo­sures, Mythos Preview is adding to an al­ready-over­loaded se­cu­rity ecosys­tem.

The rel­a­tive ease of find­ing vul­ner­a­bil­i­ties com­pared with the dif­fi­culty of fix­ing them amounts to a ma­jor chal­lenge for cy­ber­se­cu­rity. Confronting this chal­lenge suc­cess­fully will make our soft­ware far safer than be­fore. Below we dis­cuss some ways that cy­ber de­fend­ers can adapt.

Adapting to a new phase of cy­ber­se­cu­rity

Models with sim­i­lar cy­ber­se­cu­rity skills to Mythos Preview will soon be more broadly avail­able. There is a clear need for a larger ef­fort across the soft­ware in­dus­try to man­age the vol­ume of find­ings that these mod­els will gen­er­ate.

Currently, there’s of­ten a long lag be­tween the dis­cov­ery of a vul­ner­a­bil­ity, the cre­ation of a patch for it, and the time when the patch is widely de­ployed by end users. This leaves open a sig­nif­i­cant win­dow for at­tack­ers to ex­ploit crit­i­cal soft­ware. Mythos-class mod­els sig­nif­i­cantly shrink the time and cost re­quired to find and ex­ploit vul­ner­a­bil­i­ties, mag­ni­fy­ing the risk as­so­ci­ated with these time lags. Ultimately, Mythos-class mod­els will en­able de­vel­op­ers to build far more se­cure soft­ware by catch­ing bugs be­fore they are de­ployed. But this in­terim pe­riod—while vul­ner­a­bil­i­ties are be­ing rapidly dis­cov­ered and slowly patched—pre­sents new risks.

Software de­vel­op­ers and users should act now to re­duce their ex­po­sure to these risks. The ad­vice be­low is not new, and many re­searchers (including at Anthropic) are cur­rently work­ing on bet­ter and more durable so­lu­tions. In the mean­time, it’s im­por­tant to get the ba­sics right:

Software de­vel­op­ers should shorten their patch cy­cles and make se­cu­rity fixes avail­able as quickly as pos­si­ble. The thought­ful use of pub­licly avail­able AI mod­els can help here; we’re build­ing tools and shar­ing our re­search to sup­port this (more de­tails be­low). Developers should also help their users stay up-to-date with their soft­ware by mak­ing it as easy as pos­si­ble to in­stall up­dates; to the ex­tent fea­si­ble, they should be more per­sis­tent with users who are still run­ning soft­ware with known vul­ner­a­bil­i­ties.

Network de­fend­ers should shorten their patch test­ing and de­ploy­ment time­lines. The crit­i­cal con­trols laid out by or­ga­ni­za­tions like the National Institute of Standards and Technology and the UK’s National Cyber Security Centre are now all the more im­por­tant, since they im­prove se­cu­rity with­out de­pend­ing on any sin­gle patch land­ing in time. These in­clude steps like hard­en­ing net­works’ de­fault con­fig­u­ra­tions, en­forc­ing multi-fac­tor au­then­ti­ca­tion, and keep­ing com­pre­hen­sive logs for de­tec­tion and re­sponse.

Tools for cy­berde­fense with pub­licly avail­able AI mod­els

Many gen­er­ally-avail­able mod­els can al­ready find large num­bers of soft­ware vul­ner­a­bil­i­ties, even if they can’t find the most so­phis­ti­cated vul­ner­a­bil­i­ties or ex­ploit them as ef­fec­tively as Claude Mythos Preview. Project Glasswing has al­ready spurred many other or­ga­ni­za­tions to take ac­tion on their own code­bases with these gen­er­ally-avail­able mod­els; we’re work­ing to make this much eas­ier to do.

To be­gin, we’ve re­leased Claude Security in pub­lic beta for Claude Enterprise cus­tomers. It’s a tool that helps teams scan their code­bases for vul­ner­a­bil­i­ties, and which can gen­er­ate pro­posed fixes for them. In the three weeks since launch, Claude Opus 4.7 has been used to patch over 2,100 vul­ner­a­bil­i­ties. (This is faster than the open-source patch­ing de­scribed above in large part be­cause en­ter­prises are fix­ing their own code, whereas open-source fixes usu­ally re­quire vol­un­teer main­tain­ers who work through co­or­di­nated dis­clo­sure.)

We’ve also be­gun our Cyber Verification Program, which al­lows se­cu­rity pro­fes­sion­als us­ing our mod­els for le­git­i­mate cy­ber­se­cu­rity pur­poses (such as vul­ner­a­bil­ity re­search, pen­e­tra­tion test­ing, and red-team­ing) to do so with­out cer­tain safe­guards de­signed to pre­vent cy­ber mis­use.

Now, we’re mak­ing the tools that we and our part­ners have used with Mythos Preview avail­able to qual­i­fy­ing cus­tomers’ se­cu­rity teams on re­quest. Our aim is to make it much eas­ier to get the best per­for­mance out of highly ca­pa­ble pub­lic mod­els with­out ex­ten­sive setup. This re­lease in­cludes:

The skills (custom in­struc­tions for re­peated work) that we and our part­ners have built and shared;

A har­ness that helps Claude map the code­base, spin up scan­ning sub­agents, triage its find­ings, and write re­ports;

A threat model builder, which maps a code­base to iden­tify po­ten­tial tar­gets for at­tack and pri­or­i­tizes the mod­el’s work ac­cord­ingly.

Cisco, one of our Project Glasswing part­ners, has also re­cently open-sourced its Foundry Security Spec to help other de­fend­ers build an eval­u­a­tion sys­tem sim­i­lar to the one they use them­selves.

Supporting the ecosys­tem

We’ve formed a part­ner­ship with the Open Source Security Foundation’s Alpha-Omega pro­ject, which will sup­port the foun­da­tion’s ef­forts to as­sist main­tain­ers in pro­cess­ing and triag­ing bug re­ports. We’re also con­tin­u­ing to pub­lish re­search into how fron­tier model ca­pa­bil­i­ties can best sup­port cy­berde­fend­ers.

We’ve also sup­ported the de­vel­op­ment of ExploitBench and ExploitGym, the two new bench­marks that al­low re­searchers to track fron­tier AI mod­els’ ex­ploit de­vel­op­ment ca­pa­bil­i­ties over time, as we dis­cuss here. We’re sup­port­ing the de­vel­op­ment of other high-qual­ity quan­ti­ta­tive bench­marks through our External Researcher Access Program. Finally, Claude for Open Source sup­ports main­tain­ers and con­trib­u­tors, and we’re com­mit­ting to scan any open-source pack­age that we adopt our­selves in the fu­ture.

What’s next for Project Glasswing

The speed of AI progress means that mod­els as ca­pa­ble as Mythos Preview will soon be de­vel­oped by many dif­fer­ent AI com­pa­nies. At pre­sent, no com­pany—in­clud­ing Anthropic—has de­vel­oped safe­guards strong enough to pre­vent such mod­els from be­ing mis­used and po­ten­tially caus­ing se­vere harm. That is why we have yet to re­lease Mythos-class mod­els to the pub­lic. But it’s also why we be­gan Project Glasswing: if a sim­i­larly ca­pa­ble model is re­leased with­out such safe­guards, it will soon be­come dra­mat­i­cally cheaper and eas­ier for al­most any­one in the world to ex­ploit flawed soft­ware.

Glasswing helps the most sys­tem­i­cally im­por­tant cy­ber de­fend­ers gain an asym­met­ric ad­van­tage. However, there is an ur­gent need for as many or­ga­ni­za­tions as pos­si­ble to shore up their cy­ber de­fenses. We hope that our gen­er­ally avail­able mod­els, and the new tools, re­sources, and re­search we’re pro­vid­ing to ac­com­pany them, will sup­port those or­ga­ni­za­tions to im­prove their cy­ber­se­cu­rity pos­ture.

Next, we will work with crit­i­cal part­ners—in­clud­ing US and al­lied gov­ern­ments—to ex­pand Project Glasswing to ad­di­tional part­ners. And in the near fu­ture, once we’ve de­vel­oped the far stronger safe­guards we need, we look for­ward to mak­ing Mythos-class mod­els avail­able through a gen­eral re­lease.

On the far side of these risks, there’s an en­cour­ag­ing world avail­able to us: one in which im­por­tant code is hard­ened far bet­ter than it is to­day, and in which hack­ing is far less preva­lent. There are many ob­sta­cles, but we’re nonethe­less con­fi­dent that Project Glasswing can help get us there.

Related con­tent

2028: Two sce­nar­ios for global AI lead­er­ship

Our views on the AI com­pe­ti­tion be­tween the US and China.

Read more

Teaching Claude why

New re­search on how we’ve re­duced agen­tic mis­align­ment.

Read more

Natural Language Autoencoders: Turning Claude’s thoughts into text

AI mod­els like Claude talk in words but think in num­bers. In this study, we train Claude to trans­late its thoughts into hu­man-read­able text.

Read more

Microsoft first started open­ing up ac­cess to Claude Code in December, invit­ing thou­sands of its own de­vel­op­ers to use Anthropic’s AI cod­ing tool daily. It was part of an ef­fort to get pro­ject man­agers, de­sign­ers, and other em­ploy­ees to ex­per­i­ment with cod­ing for the first time, and sources tell me that Claude Code has proved very pop­u­lar in­side Microsoft over the past six months. Perhaps a lit­tle too pop­u­lar, as Microsoft is now prepar­ing to walk back its Claude Code push.

I un­der­stand that Microsoft is plan­ning to re­move most of its Claude Code li­censes and push many of its de­vel­op­ers to use Copilot CLI in­stead. While Claude Code has been a pop­u­lar ad­di­tion, it has also un­der­mined Microsoft’s new GitHub Copilot CLI cod­ing tool — a com­mand line ver­sion of GitHub Copilot that runs out­side of de­vel­op­ment apps like Visual Studio Code.

I’m told that Microsoft’s Experiences + Devices team, which in­cludes the en­gi­neers re­spon­si­ble for Windows, Microsoft 365, Outlook, Microsoft Teams, and Surface, is wind­ing down its us­age of Claude Code by the end of June. Sources tell me that en­gi­neers are be­ing en­cour­aged to start tran­si­tion­ing their work­flows to GitHub Copilot CLI in the com­ing weeks, ahead of the cut­off.

Microsoft is telling em­ploy­ees that the de­ci­sion is about con­verg­ing on Copilot CLI as its main agen­tic com­mand line in­ter­face tool across Experiences + Devices, but sources tell me the de­ci­sion is also a fi­nan­cial one. The June 30th cut­off is the last day of Microsoft’s cur­rent fi­nan­cial year, and can­cel­ing Claude Code li­censes is an easy way to cut some op­er­at­ing ex­penses for when the new fi­nan­cial year starts in July.

“When we be­gan of­fer­ing both Copilot CLI and Claude Code, our goal was to learn quickly, bench­mark the tools in real en­gi­neer­ing work­flows, and un­der­stand what best sup­ported our teams,” says Rajesh Jha, ex­ec­u­tive vice pres­i­dent of Microsoft’s ex­pe­ri­ences and de­vices group, in an in­ter­nal memo seen by Notepad. “Claude Code was an im­por­tant part of that learn­ing… at the same time, Copilot CLI has given us some­thing es­pe­cially im­por­tant: a prod­uct we can help shape di­rectly with GitHub for Microsoft’s re­pos, work­flows, se­cu­rity ex­pec­ta­tions, and en­gi­neer­ing needs.”

The tran­si­tion away from Claude Code won’t be an easy one for en­gi­neers in­side Microsoft, though. Microsoft had been en­cour­ag­ing em­ploy­ees with­out any cod­ing ex­pe­ri­ence to ex­per­i­ment with Claude Code, al­low­ing de­sign­ers and pro­ject man­agers to pro­to­type ideas. Microsoft had also orig­i­nally ex­pected em­ploy­ees to use both Claude Code and GitHub Copilot, to com­pare the two and pro­vide feed­back.

Microsoft’s own de­vel­op­ers have fa­vored Claude Code over GitHub Copilot CLI in re­cent months in­stead, and there are still gaps be­tween the prod­ucts that will now need to be ad­dressed. Microsoft had re­port­edly con­sid­ered ac­quir­ing Cursor in re­cent months to help close the GitHub Copilot gap, but has started look­ing at dif­fer­ent AI star­tups to bol­ster its AI am­bi­tions and avoid po­ten­tial reg­u­la­tory scrutiny.

“We are part­ner­ing closely with GitHub and con­tinue to im­prove Copilot CLI for Microsoft en­gi­neers,” says Jha. “The GitHub team has al­ready shipped sig­nif­i­cant im­prove­ments based on Microsoft feed­back, and Experiences + Devices will re­main closely in­volved in shap­ing the prod­uct. This is a shared ac­count­abil­ity across GitHub and E+D lead­er­ship: to make Copilot CLI the best agen­tic cod­ing ex­pe­ri­ence for Microsoft en­gi­neers.”

Anthropic’s mod­els will re­main ac­ces­si­ble through Copilot CLI, along with in­ter­nal-only Microsoft mod­els and OpenAI’s range of mod­els. I un­der­stand that Microsoft is plan­ning to in­vest more in Copilot CLI so it’s deeply in­te­grated into Microsoft’s own en­gi­neer­ing work­flows. Microsoft is also en­cour­ag­ing de­vel­op­ers to file bug re­ports and feed­back on Copilot CLI ahead of Claude Code be­ing re­moved.

Microsoft quickly be­came one of Anthropic’s top cus­tomers ear­lier this year and has even re­port­edly been count­ing sell­ing Anthropic AI mod­els to­ward its own Azure sales quo­tas. Microsoft also signed a deal with Anthropic in November that al­lows Microsoft Foundry cus­tomers to get ac­cess to Claude Sonnet 4.5, Claude Opus 4.1, and Claude Haiku 4.5.

The de­ci­sion to can­cel Claude Code li­censes won’t have any im­pact on the Foundry deal, and Microsoft still con­tin­ues to fa­vor Anthropic’s Claude mod­els in­side Microsoft 365 apps and Copilot, where they’re more ca­pa­ble at cer­tain tasks than OpenAI’s coun­ter­parts. Microsoft also worked closely with Anthropic re­cently to bring the tech­nol­ogy be­hind Claude Cowork into Microsoft 365 Copilot.

The pres­sure is now on Microsoft’s GitHub team to im­prove Copilot CLI and try to sur­pass Claude Code in the process. Microsoft told me last year that 91 per­cent of its en­gi­neer­ing teams were us­ing GitHub Copilot, but Claude Code us­age over the past six months has def­i­nitely had an im­pact on that num­ber. Microsoft now wants to turn GitHub Copilot us­age around and have its own en­gi­neers once again im­prov­ing its own AI cod­ing tool.

The pad

Windows 11 is get­ting a ma­cOS-like speed boost. Microsoft is cur­rently test­ing a new speed boost fea­ture in Windows 11 that is de­signed to im­prove app launch times and make things like the Start menu feel more re­spon­sive. “Low Latency Profile” will ramp up CPU fre­quen­cies in short bursts to im­prove the speed of menus, fly­outs, apps, and more. It’s very sim­i­lar to what Linux and ma­cOS do, but that has­n’t stopped some from claim­ing Microsoft is sim­ply cheat­ing to speed up its op­er­at­ing sys­tem. In re­sponse, Scott Hanselman, vice pres­i­dent of tech­ni­cal staff for CoreAI, GitHub, and Windows, de­fended Microsoft’s speed boost changes, point­ing out that “your smart­phone al­ready does this” and Microsoft is­n’t cheat­ing. “Apple does this and y’all love it,” said Hanselman.

Microsoft’s Israel chief is leav­ing amid in­ves­ti­ga­tion al­le­ga­tions. Microsoft qui­etly an­nounced last week that its Israel gen­eral man­ager, Alon Haimovich, is step­ping down at the end of the month af­ter four years. Israeli news­pa­per Globes now re­ports that Haimovich is leav­ing amid an in­ter­nal in­ves­ti­ga­tion into Microsoft Israel’s work with the Israel Ministry of Defense. Microsoft blocked the Israeli mil­i­tary from some cloud and AI ser­vices last year af­ter The Guardian re­vealed its ser­vices were be­ing used for mass sur­veil­lance of Palestinians.

Discord adds a free Xbox Game Pass “starter edi­tion” for Nitro sub­scribers. Discord is launch­ing a new Nitro Rewards pro­gram this week that bun­dles a new Xbox Game Pass starter edi­tion. It in­cludes ac­cess to down­load more than 50 games on PC and Xbox, as well as 10 hours of Xbox Cloud Gaming stream­ing a month. Nitro Rewards also in­cludes dis­counts on Logitech and SteelSeries gear. It’s cer­tainly an in­ter­est­ing bun­dle from Xbox, par­tic­u­larly as Discord Nitro mem­bers won’t have to pay any­thing ex­tra for it. Netflix also teased the po­ten­tial for some kind of Game Pass deal ear­lier this year.

Forza Horizon 6 has been leaked and cracked a week be­fore its re­lease. Playground Games is get­ting ready to launch the next in­stall­ment of its Forza Horizon se­ries next week, and it has some­how leaked onto the in­ter­net early. Downloads of Forza Horizon 6 ap­peared on­line ear­lier this week, com­plete with a crack to make the game run lo­cally. There was spec­u­la­tion that the game leaked due to an un­en­crypted ver­sion be­ing avail­able on Steam, but Playground Games says the leak had noth­ing to do with a “pre-load is­sue.” It’s still not clear how the game was leaked so early.

Microsoft was wor­ried OpenAI would run off to Amazon and ‘shit-talk’ Azure. The on­go­ing Musk v. Altman trial is al­ready pro­vid­ing some rare in­sights into the com­mu­ni­ca­tions be­tween Microsoft’s top ex­ec­u­tives and OpenAI dur­ing the early days of their part­ner­ship. In January 2018, ahead of Microsoft’s first big OpenAI in­vest­ment, Microsoft CTO Kevin Scott was wor­ried about not in­vest­ing in OpenAI. “I guess the other thing to think about here is the PR down­side of us not fund­ing them, and hav­ing them storm off to Amazon in a huff and shit-talk us and Azure on the way out,” said Scott. That never quite hap­pened, but OpenAI did tell its em­ploy­ees last month that its deal with Microsoft had “also lim­ited our abil­ity to meet en­ter­prises where they are — for many that’s [Amazon] Bedrock.” Microsoft’s rene­go­ti­ated deal with OpenAI al­lows the AI startup to bring its mod­els, Codex, and other tools to AWS — Microsoft’s biggest cloud ri­val.

Did Microsoft just tease a new Xbox UI? Last week we got a closer look at the “consistent” Xbox UI that Microsoft is promis­ing across hand­helds, con­soles, and cloud gam­ing. It first ap­peared dur­ing an Xbox keynote at the Game Developers Conference in March, but thanks to a new video from Microsoft we can now clearly see where it dif­fers from the ex­ist­ing Xbox UI. The Xbox con­sole home­screen is slightly dif­fer­ent, with the user pro­file in the top right and three ad slots along the bot­tom in­stead of the usual four. The Xbox PC app also looks a lot more like the new Xbox Cloud Gaming in­ter­face. This im­age could just be a mockup, but it still speaks to Microsoft’s am­bi­tion to im­prove the Xbox UI across mul­ti­ple de­vices.

Microsoft to share more about Xbox Project Helix later this year. We first heard the next-gen Xbox co­de­name ear­lier this year, and Microsoft is now promis­ing more de­tails about Project Helix “later this year.” I’d be sur­prised if we hear any­thing sig­nif­i­cant about Project Helix dur­ing the Xbox show­case next month, though. The “later this year” promise may well co­in­cide with VP of next gen Jason Ronald’s pre­vi­ous com­ments about “rolling out new ways to play” clas­sic Xbox games.

Microsoft’s Xbox PC app hints at China ex­pan­sion for Game Pass. Microsoft ap­pears to be work­ing on ex­pand­ing its Xbox Game Pass sub­scrip­tion to China. References to “Project Saluki” have been dis­cov­ered in a re­cent up­date to the Xbox PC app this week, with Microsoft de­scrib­ing the co­de­name as a “China mar­ket ex­pan­sion for Game Pass, Rewards, and sub­scrip­tion tiers.” The Xbox PC app also ref­er­ences the co­de­name “Positron,” which is said to “enable Disc2Digital.” This may well be a re­turn of Microsoft’s plan to con­vert disc games into dig­i­tal li­censes. Microsoft was plan­ning to do this with the Xbox One, but a back­lash from pub­lish­ers and game re­sellers forced the com­pany to aban­don the plans.

Microsoft starts lay­offs at LinkedIn. Microsoft is re­port­edly cut­ting around 5 per­cent of its LinkedIn head­count this week, ap­prox­i­mately 875 roles. Reuters re­ports that Microsoft-owned LinkedIn will in­form staff of the cuts to­day. Microsoft con­firmed the lay­offs in a state­ment to Seeking Alpha. “As part of our reg­u­lar busi­ness plan­ning, we’ve im­ple­mented or­ga­ni­za­tional changes to best po­si­tion our­selves for fu­ture suc­cess,” said an un­named LinkedIn spokesper­son.

Microsoft used its own AI model to find se­cu­rity vul­ner­a­bil­i­ties. Microsoft’s MDASH multi-model agent is the leader on the CyberGym se­cu­rity eval­u­a­tion frame­work, and the com­pany has used it to dis­cover vul­ner­a­bil­i­ties in its own prod­ucts. 16 CVEs were ad­dressed in this week’s Patch Tuesday thanks to MDASH. You’ve also got to love that Microsoft uniron­i­cally named its lat­est AI model MDASH.

Windows Update will soon au­to­mat­i­cally roll back faulty dri­vers. Microsoft is work­ing on a new fea­ture for Windows Update that will re­move the has­sle of hav­ing to unin­stall faulty dri­vers. A new “Cloud-Initiated Driver Recovery” fea­ture is on the way that can re­place a faulty dri­ver in­stalled on a PC with a pre­vi­ously work­ing dri­ver through Windows Update. It should be ready in time for September, and it’s part of a num­ber of changes to Windows Update to make it less dis­rup­tive.

Microsoft’s Edge Copilot up­date uses AI to pull in­for­ma­tion from across your tabs. Microsoft is adding a new fea­ture to its Edge browser that will al­low its Copilot AI as­sis­tant to gather in­for­ma­tion from all of your open tabs. You’ll be able to ask the Copilot chat­bot ques­tions about what’s in your tabs, com­pare prod­ucts, or sum­ma­rize ar­ti­cles. It’s part of a big­ger up­date to Copilot in­te­gra­tion in Edge that sees the Copilot Mode be­ing re­tired in fa­vor of sim­ply en­abling or dis­abling these new AI-powered fea­tures.

I’m al­ways keen to hear from read­ers, so please drop a com­ment here, or you can reach me at notepad@thev­erge.com if you want to dis­cuss any­thing else. If you’ve heard about any of Microsoft’s se­cret pro­jects, you can reach me via email at notepad@thev­erge.com or speak to me con­fi­den­tially on the Signal mes­sag­ing app, where I’m tomwar­ren.01. I’m also tomwar­ren on Telegram, if you’d pre­fer to chat there.

Thanks for sub­scrib­ing to Notepad.

Follow top­ics and au­thors from this story to see more like this in your per­son­al­ized home­page feed and to re­ceive email up­dates.

Tom Warren

In Brief

Posted:

7:30 AM PDT · May 22, 2026

Phone provider Trump Mobile has con­firmed that it was ex­pos­ing cus­tomers’ names, email ad­dresses, mail­ing ad­dresses, cell num­bers, and or­der iden­ti­fiers to the open in­ter­net.

Chris Walker, a spokesper­son for the Trump-branded phone maker, told TechCrunch that the com­pany is in­ves­ti­gat­ing the ex­po­sure and has not found ev­i­dence that con­tent or fi­nan­cial in­for­ma­tion spilled on­line. The com­pany said there was no breach of Trump Mobile’s net­work, sys­tems, or in­fra­struc­ture.

Walker said that the ex­po­sure was linked to a third-party plat­form provider that sup­ports “certain Trump Mobile op­er­a­tions.” He did not name the provider.

The com­pa­ny’s ad­mis­sion came af­ter re­ports ear­lier this week that Trump Mobile cus­tomers’ data was pub­licly ac­ces­si­ble from the web.

On Wednesday, two YouTubers who or­dered Trump Mobile’s phone said a re­searcher alerted them that their per­sonal in­for­ma­tion was ex­posed on­line. The YouTubers Coffeezilla and pen­guinz0 said they tried to alert Trump Mobile of the ex­po­sure af­ter the re­searcher also tried but to no avail.

Walker said Trump Mobile is eval­u­at­ing whether it needs to no­tify cus­tomers of the ex­po­sure of their per­sonal data.

Topics

Subscribe for the in­dus­try’s biggest tech news

Latest in Security

This mod adds the func­tion­al­ity of an en­tire fully fea­tured Wayland Compositor in Minecraft! Launch apps and open win­dows com­pletely within your Minecraft world. Drag and drop data from one win­dow to an­other. Pin a video player to your hud. The choice is yours.

IMPORTANT: This mod only runs un­der Linux! MacOS or Windows are not sup­ported.

There are no new alerts at this time