Written by me, proof-read by an LLM.

Details at end.

In one of my talks on as­sem­bly, I show a list of the 20 most ex­e­cuted in­struc­tions on an av­er­age x86 Linux desk­top. All the usual cul­prits are there, mov, add, lea, sub, jmp, call and so on, but the sur­prise in­ter­loper is xor - “eXclusive OR”. In my 6502 hack­ing days, the pres­ence of an ex­clu­sive OR was a sure-fire in­di­ca­tor you’d ei­ther found the en­cryp­tion part of the code, or some kind of sprite rou­tine. It’s sur­pris­ing then, that a Linux ma­chine just mind­ing its own busi­ness, would be ex­e­cut­ing so many.

That is, un­til you re­mem­ber that com­pil­ers love to emit a xor when set­ting a reg­is­ter to zero:

We know that ex­clu­sive-OR-ing any­thing with it­self gen­er­ates zero, but why does the com­piler emit this se­quence? Is it just show­ing off?

In the ex­am­ple above, I’ve com­piled with -O2 and en­abled Compiler Explorer’s “Compile to bi­nary ob­ject” so you can view the ma­chine code that the CPU sees, specif­i­cally:

If you change GCC’s op­ti­mi­sa­tion level down to -O1 you’ll see:

The much clearer, more in­ten­tion-re­veal­ing mov eax, 0 to set the EAX reg­is­ter to zero takes up five bytes, com­pared to the two of the ex­clu­sive OR. By us­ing a slightly more ob­scure in­struc­tion, we save three bytes every time we need to set a reg­is­ter to zero, which is a pretty com­mon op­er­a­tion. Saving bytes makes the pro­gram smaller, and makes more ef­fi­cient use of the in­struc­tion cache.

It gets bet­ter though! Since this is a very com­mon op­er­a­tion, x86 CPUs spot this “zeroing id­iom” early in the pipeline and can specif­i­cally op­ti­mise around it: the out-of-or­der track­ing sys­tems knows that the value of “eax” (or whichever reg­is­ter is be­ing ze­roed) does not de­pend on the pre­vi­ous value of eax, so it can al­lo­cate a fresh, de­pen­dency-free zero reg­is­ter re­namer slot. And, hav­ing done that it re­moves the op­er­a­tion from the ex­e­cu­tion queue - that is the xor takes zero ex­e­cu­tion cy­cles! It’s es­sen­tially op­ti­mised out by the CPU!

You may won­der why you see xor eax, eax but never xor rax, rax (the 64-bit ver­sion), even when re­turn­ing a long:

In this case, even though rax is needed to hold the full 64-bit long re­sult, by writ­ing to eax, we get a nice ef­fect: Unlike other par­tial reg­is­ter writes, when writ­ing to an e reg­is­ter like eax, the ar­chi­tec­ture ze­ros the top 32 bits for free. So xor eax, eax sets all 64 bits to zero.

Interestingly, when ze­ro­ing the “extended” num­bered reg­is­ters (like r8), GCC still uses the d (double width, ie 32-bit) vari­ant:

Note how it’s xor r8d, r8d (the 32-bit vari­ant) even though with the REX pre­fix (here 45) it would be the same num­ber of bytes to xor r8, r8 the full width. Probably makes some­thing eas­ier in the com­pil­ers, as clang does this too.

xor eax, eax saves you code space and ex­e­cu­tion time! Thanks com­pil­ers!

See the video that ac­com­pa­nies this post.

This post is day 1 of Advent of Compiler Optimisations 2025, a 25-day se­ries ex­plor­ing how com­pil­ers trans­form our code.

This post was writ­ten by a hu­man (Matt Godbolt) and re­viewed and proof-read by LLMs and hu­mans.

Support Compiler Explorer on Patreon

or GitHub, or by buy­ing CE prod­ucts in the Compiler Explorer Shop.

Matt Godbolt is a C++ de­vel­oper liv­ing in Chicago. He works for Hudson River Trading on su­per fun but se­cret things. He is one half of the Two’s Complement pod­cast. Follow him on Mastodon

or Bluesky.

Cast your mind back to when you learned to drive, ride a bike, speak a for­eign lan­guage, per­form a tra­cheostomy, or ac­quire any other skill. Wasn’t con­fi­dence the key to your suc­cess? Whatever we do in life, con­fi­dence is al­ways crit­i­cal. If you run a busi­ness, one of the met­rics that are likely to be col­lected is con­fi­dence in your busi­ness, as that’s such an im­por­tant eco­nomic in­di­ca­tor. Confidence is every bit as im­por­tant in com­put­ing.

Over the last few weeks I’ve been dis­cov­er­ing prob­lems that have been erod­ing con­fi­dence in ma­cOS. From text files that sim­ply won’t show up in Spotlight search, to Clock timers that are blank and don’t func­tion, there’s one com­mon fea­ture: ma­cOS en­coun­ters an er­ror or fault, but does­n’t re­port that to the user, in­stead just bury­ing it deep in the log.

When you can spare the time, the next step is to con­tact Apple Support, who seem equally puz­zled. You’re even­tu­ally ad­vised to re­in­stall ma­cOS or, in the worst case, to wipe a fairly new Apple sil­i­con Mac and re­store it in DFU mode, but have no rea­son to be­lieve that will stop the prob­lem from re­cur­ring. You know that Apple Support does­n’t un­der­stand what’s go­ing wrong, and de­spite the in­volve­ment of sup­port en­gi­neers, they seem as per­plexed as you.

One rea­son for this is that ma­cOS so sel­dom re­ports er­rors, and when it does, it’s un­in­for­ma­tive if not down­right mis­lead­ing. Here’s a small gallery of ex­am­ples I’ve en­coun­tered over the last few years, to bring back un­happy mem­o­ries.

Maybe you saved an im­por­tant web­page in Safari 26.1 us­ing its Web Archive for­mat, then a cou­ple of days later dis­cov­ered you could­n’t open it. There’s no er­ror mes­sage, just a blank win­dow, so you try again with the same re­sult. Another site shows the same prob­lem, forc­ing you to con­clude that it’s a bug in Safari. Are you now go­ing to de­vote your time to ob­tain­ing suf­fi­cient in­for­ma­tion to re­port that to Apple us­ing Feedback? Or to con­tact Apple Support and pur­sue its es­ca­la­tion to an en­gi­neer who might for­tu­itously dis­cover the cause?

Silent fail­ures like these are least likely to be re­ported to Apple. In most cases, we find our­selves a workaround, here to aban­don Web Archives and switch to sav­ing web­pages as PDF in­stead. When some­one else men­tions they too have the same prob­lem, we ad­vise them that Web Archives are bro­ken, and our loss of con­fi­dence spreads by con­ta­gion.

Honest and un­der­stand­able er­ror re­port­ing is es­sen­tial to con­fi­dence. It en­ables us to tackle prob­lems rather than just giv­ing up in frus­tra­tion, as­sum­ing that it’s yet an­other fea­ture we used to rely on that has suc­cumbed in the rush to get the next ver­sion of ma­cOS out of the door.

Eroding con­fi­dence is also a prob­lem that the ven­dors of AI ap­pear to have over­looked, or at least se­ri­ously un­der­es­ti­mated. It’s all very well us­ing the eu­phemism of hal­lu­ci­na­tion to play down the sever­ity of er­rors gen­er­ated by LLMs. But those can only cause users to lose con­fi­dence, no mat­ter how ‘intelligent’ you might think your AI is be­com­ing. Go talk to the lawyers who have been caught out by courts sub­mit­ting AI fab­ri­ca­tions whether they still have full con­fi­dence in your prod­uct.

Ghostty for the web with xterm.js API com­pat­i­bil­ity — giv­ing you a proper VT100 im­ple­men­ta­tion in the browser.

* Migrate from xterm by chang­ing your im­port: @xterm/xterm → ghostty-web

* WASM-compiled parser from Ghostty—the same code that runs the na­tive app

Originally cre­ated for Mux (a desk­top app for iso­lated, par­al­lel agen­tic de­vel­op­ment), but de­signed to be used any­where.

Live Demo on an ephemeral VM (thank you to Greg from disco.cloud for host­ing).

npx @ghostty-web/demo@next

This starts a lo­cal HTTP server with a real shell on http://​lo­cal­host:8080. Works best on Linux and ma­cOS.

xterm.js is every­where—VS Code, Hyper, count­less web ter­mi­nals. But it has fun­da­men­tal is­sues:

xterm.js reim­ple­ments ter­mi­nal em­u­la­tion in JavaScript. Every es­cape se­quence, every edge case, every Unicode quirk—all hand-coded. Ghostty’s em­u­la­tor is the same bat­tle-tested code that runs the na­tive Ghostty app.

npm in­stall ghostty-web

ghostty-web aims to be API-compatible with the xterm.js API.

im­port { init, Terminal } from ‘ghostty-web’;

await init();

const term = new Terminal({

font­Size: 14,

theme: {

back­ground: ‘#1a1b26’,

fore­ground: ‘#a9b1d6’,

term.open(doc­u­ment.getEle­ment­ById(‘ter­mi­nal’));

term.on­Data((data) => web­socket.send(data));

web­socket.on­mes­sage = (e) => term.write(e.data);

For a com­pre­hen­sive client server ex­am­ple, re­fer to the demo.

ghostty-web builds from Ghostty’s source with a patch to ex­pose ad­di­tional func­tion­al­ity.

bun run build

Mitchell Hashimoto (author of Ghostty) has been work­ing on libghostty which makes this all pos­si­ble. The patches are very min­i­mal thanks to the work the Ghostty team has done, and we ex­pect them to get smaller.

This li­brary will even­tu­ally con­sume a na­tive Ghostty WASM dis­tri­b­u­tion once avail­able, and will con­tinue to pro­vide an xterm.js com­pat­i­ble API.

At Coder we’re big fans of Ghostty, so ku­dos to that team for all the amaz­ing work.

JavaScript is­n’t en­abled in your browser, so this file can’t be opened. Enable and re­load.

I’ve writ­ten about JPEG XL in the past. First, I noted Google’s move to kill the for­mat in Chromium in fa­vor of the home­grown and in­fe­rior AVIF. Then, I had a deeper look at the for­mat, and vi­su­ally com­pared JPEG XL with AVIF on a hand­ful of im­ages.

The lat­ter post started with a quick sup­port test:

“If you are brows­ing this page around 2023, chances are that your browser sup­ports AVIF but does not sup­port JPEG XL.”

Well, here we are at the end of 2025, and this very sen­tence still holds true. Unless you are one of the 17% of users us­ing Safari, or are ad­ven­tur­ous enough to use a niche browser like Thorium, LibreWolf or the newer Zen Browser, chances are you see the AVIF ban­ner in green and the JPEG XL im­age in black/​red.

The good news is, this will change soon. In a dra­matic turn of events, the Chromium team has re­versed its Obsolete tag, and has de­cided to sup­port the for­mat in Blink (the en­gine be­hind Chrome/Chromium/Edge). Given Chrome’s po­si­tion in the browser mar­ket share, I pre­dict the for­mat will be­come a de fac­tor stan­dard for im­ages in the near fu­ture.

I’ve been fol­low­ing JPEG XL since its ex­per­i­men­tal sup­port in Blink. What started as a promis­ing fea­ture was quickly axed by the team in a bizarre and ridicu­lous man­ner. First, they asked the com­mu­nity for feed­back on the for­mat. Then, the com­mu­nity re­sponded very pos­i­tively. And I don’t only mean a cou­ple of guys in their base­ment. Meta, Intel, Cloudinary, Adobe, ffm­peg, lib­vips, Krita, and many more. After that came the in­fa­mous com­ment:

Thank you every­one for your com­ments and feed­back re­gard­ing JPEG XL. We will be re­mov­ing the JPEG XL code and flag from Chromium for the fol­low­ing rea­sons:Ex­per­i­men­tal flags and code should not re­main in­def­i­nite­lyThere is not enough in­ter­est from the en­tire ecosys­tem to con­tinue ex­per­i­ment­ing with JPEG XLThe new im­age for­mat does not bring suf­fi­cient in­cre­men­tal ben­e­fits over ex­ist­ing for­mats to war­rant en­abling it by de­faultBy re­mov­ing the flag and the code in M110, it re­duces the main­te­nance bur­den and al­lows us to fo­cus on im­prov­ing ex­ist­ing for­mats in Chrome

Yes, right, “not enough in­ter­est from the en­tire ecosys­tem”. Sure.

Anyway, fol­low­ing this com­ment, a steady stream of mes­sages pointed out how wrong that was, from all the or­ga­ni­za­tions men­tioned above and many more. People were notic­ing in blog posts, videos, and so­cial me­dia in­ter­ac­tions.

Strangely, the fol­low­ing few years have been pretty calm for JPEG XL. However, a few no­table events did take place. First, the Firefox team showed in­ter­est in a JPEG XL Rust de­coder, af­ter de­scrib­ing their stance on the mat­ter as “neutral”. They were con­cerned about the in­creased at­tack sur­face re­sult­ing from in­clud­ing the cur­rent 100K+ lines C++ lib­jxl ref­er­ence de­coder, even though most of those lines are test­ing code. In any case, they kind of re­quested a “memory-safe” de­coder. This seems to have kick-started the Rust im­ple­men­ta­tion, jxl-rs, from Google Research.

To top it off, a cou­ple of weeks ago, the PDF Association an­nounced their in­tent to adopt JPEG XL as a pre­ferred im­age for­mat in their PDF spec­i­fi­ca­tion. The CTO of the PDF Association, Peter Wyatt, ex­pressed their de­sire to in­clude JPEG XL as the pre­ferred for­mat for HDR con­tent in PDF files.

All of this pres­sure ex­erted steadily over time made the Chromium team re­con­sider the for­mat. They tried to kill it in fa­vor of AVIF, but that has­n’t worked out. Rick Byers, on be­half of Chromium, made a com­ment in the Blink de­vel­op­ers Google group about the team wel­com­ing a per­for­mant and mem­ory-safe JPEG XL de­coder in Chromium. He stated that the change of stance was in light of the pos­i­tive signs from the com­mu­nity we have ex­posed above (Safari sup­port, Firefox up­dat­ing their po­si­tion, PDF, etc.). Quickly af­ter that, the Chromium is­sue state was changed from Obsolete to Assigned.

This is great news for the for­mat, and I be­lieve it will give it the fi­nal push for mass adop­tion. The for­mat is ex­cel­lent for all kinds of pur­poses, and I’ll be adopt­ing it pretty much in­stantly for this and the Gaia Sky web­site when sup­port is shipped. Some of the fea­tures that make it su­pe­rior to the com­pe­ti­tion are:

* Lossless re-com­pres­sion of JPEG im­ages. This means you can re-com­press your cur­rent JPEG li­brary with­out los­ing in­for­ma­tion and ben­e­fit from a ~30% re­duc­tion in file size for free. This is a killer fea­ture that no other for­mat has.

* Support for im­age sizes of up to 1,073,741,823x1,073,741,824. You won’t run out of im­age space any­time soon. AVIF is ridicu­lous in this as­pect, cap­ping at 8,193x4,320. WebP goes up to 16K2, while the orig­i­nal 1992 JPEG sup­ports 64K2.

* Maximum of 32 bits per chan­nel. No other for­mat (except for the de­funct JPEG 2000) of­fers this.

* Maximum of 4,099 chan­nels. Most other for­mats sup­port 4 or 5, with the ex­cep­tion of JPEG 2000, which sup­ports 16,384.

* JXL sup­ports pro­gres­sive de­cod­ing, which is es­sen­tial for web de­liv­ery, IMO. WebP or HEIC have no such fea­ture. Progressive de­cod­ing in AVIF was added a few years back.

For a full codec fea­ture break­down, see Battle of the Codecs.

JPEG XL is the fu­ture of im­age for­mats. It checks all the right boxes, and it checks them well. Support in the over­whelm­ingly most pop­u­lar browser en­gine is prob­a­bly go­ing to be a cru­cial step­ping stone in the for­mat’s path to star­dom. I’m happy that the Chromium team re­con­sid­ered their in­clu­sion, but I am sad that it took so long and so much pres­sure from the com­mu­nity to achieve it.

The first three di­men­sions—length, height, and depth—are in­cluded on all topo­graph­i­cal maps. The “fourth di­men­sion,” or time, is also avail­able on the web­site of the Swiss Federal Office of Topography (Swisstopo). In the “Journey Through Time,” a time­line dis­plays 175 years of the coun­try’s car­to­graphic his­tory, ad­vanc­ing in in­cre­ments of 5-10 years. Over the course of two min­utes, Switzerland is drawn and re­drawn with in­creas­ing pre­ci­sion: inky shapes take on hard edges, blues and browns ap­pear af­ter the turn of the cen­tury, and in 2016, the let­ters drop their ser­ifs.

Watching a sin­gle place evolve over time re­veals small his­to­ries and gran­u­lar in­con­sis­ten­cies. Train sta­tions and air­ports are built, a gun­pow­der fac­tory dis­ap­pears for the length of the Cold War. But on cer­tain maps, in Switzerland’s more re­mote re­gions, there is also, cu­ri­ously, a spi­der, a man’s face, a naked woman, a hiker, a fish, and a mar­mot. These barely-per­cep­ti­ble ap­pari­tions aren’t mis­takes, but rather il­lus­tra­tions hid­den by the of­fi­cial car­tog­ra­phers at Swisstopo in de­fi­ance of their man­date “to re­con­sti­tute re­al­ity.” Maps pub­lished by Swisstopo un­dergo a rig­or­ous proof­read­ing process, so to find an il­licit draw­ing means that the car­tog­ra­pher has out­smarted his col­leagues.

It also im­plies that the map­maker has openly vi­o­lated his com­mit­ment to ac­cu­racy, risk­ing pro­fes­sional reper­cus­sions on ac­count of an alpine ro­dent. No car­tog­ra­pher has been fired over these draw­ings, but then again, most were only dis­cov­ered once their au­thor had al­ready left. (Many map­mak­ers timed the pub­li­ca­tion of their draw­ing to co­in­cide with their re­tire­ment.) Over half of the known il­lus­tra­tions have been re­moved. The lat­est, the mar­mot draw­ing, was dis­cov­ered by Swisstopo in 2016 and is likely to be elim­i­nated from the next of­fi­cial map of Switzerland by next year. As the spokesper­son for Swisstopo told me, “Creativity has no place on these maps.”

Errors—both ac­ci­den­tal and de­lib­er­ate—are not un­com­mon in maps (17th-century California as an is­land, the omis­sion of Seattle in a 1960s AAA map). Military cen­sors have long trans­formed nu­clear bunkers into non­de­script ware­houses and rou­tinely pix­e­late satel­lite im­ages of sen­si­tive sites. Many maps also con­tain in­ten­tional er­rors to trap would-be copy­right vi­o­la­tors. The work of record­ing re­al­ity is par­tic­u­larly vul­ner­a­ble to pla­gia­rism: if a car­tog­ra­pher is sus­pected of copy­ing an­oth­er’s work, he can sim­ply claim to be du­pli­cat­ing the real world— ide­ally, the two should be the same. Mapmakers of­ten rely on fic­ti­tious streets, typ­i­cally no longer than a block, to dif­fer­en­ti­ate their ac­counts of the truth (Oxygen Street in Edinburgh, for ex­am­ple).

Their en­tire pro­fes­sional life is spent at the mag­ni­fi­ca­tion level of a postage stamp.

But there is an­other, less in­sti­tu­tional rea­son to hide some­thing in a map. According to Lorenz Hurni, pro­fes­sor of car­tog­ra­phy at ETH Zurich, these il­lus­tra­tions are part in­side joke, part cop­ing mech­a­nism. Cartographers are “quite metic­u­lous, re­ally high-pre­ci­sion peo­ple,” he says. Their en­tire pro­fes­sional life is spent at the mag­ni­fi­ca­tion level of a postage stamp. To sus­tain this kind of con­cen­tra­tion, Hurni sus­pects that they even­tu­ally “look for some­thing to break out of their daily rou­tine.” The sat­is­fac­tion of these il­lus­tra­tions comes from their trans­gres­sive na­ture— the la­bor and se­crecy re­quired to con­ceal one of these vi­sual puns.

And some of them en­joy re­mark­able longevity. The naked woman draw­ing, for ex­am­ple, re­mained hid­den for al­most sixty years in the mu­nic­i­pal­ity of Egg, in north­ern Switzerland. Her rel­a­tively un­der­stated shape was com­posed in 1958 from a swath of green coun­try­side and the blue line of a river, her knees bend­ing at the curve in the stream. She re­mained un­no­ticed, re­clin­ing peace­fully, un­til 2012.

Several of the other draw­ings came about con­sid­er­ably later. In 1980, a Swisstopo car­tog­ra­pher traced the spi­der over an arach­nid-shaped ice field on the Eiger moun­tain. It faded out over the course of the decade, re­tract­ing its spindly legs in the in­ter­me­di­ary edi­tions. Around the same time, an­other car­tog­ra­pher con­cealed a fresh­wa­ter fish in a French na­ture pre­serve along the Swiss bor­der. The fish lived in the blue cir­cum­fer­ence of a marshy lake un­til 1989 when, ac­cord­ing to Swisstopo, “it dis­ap­peared from the sur­face of the lake, div­ing to the depths.”

It’s un­clear how these draw­ings made it past the in­sti­tute’s proof­read­ers in the first place. They may have been in­serted only af­ter the maps were ap­proved, when car­tog­ra­phers are asked to ap­ply the proof­read­ers’ fi­nal ed­its. When the maps were once printed as com­pos­ite lay­ers of dif­fer­ent col­ors, car­tog­ra­phers could have built the draw­ings from the in­ter­play of dif­fer­ent topo­graph­i­cal el­e­ments (the naked woman, for ex­am­ple, is com­posed of a blue line over a green-shaded area). Hurni also spec­u­lates that car­tog­ra­phers could have par­ti­tioned their il­lus­tra­tions over the cor­ners of four sep­a­rate map sheets, al­though no such ex­am­ple has (yet) been found.

Some of these clan­des­tine draw­ings al­lude to ac­tual topo­graph­i­cal fea­tures: near the town of Interlaken, where an out­crop­ping of stones ap­prox­i­mates two eyes and a nose, the 1980 edi­tion of the map fea­tures an an­gu­lar car­toon face be­tween the trees. (According to lo­cal leg­end, it’s a monk who was turned to stone as pun­ish­ment for chas­ing a young girl off the cliff.) In the late 1990s, the same car­tog­ra­pher drew a hiker in the map’s mar­gins. With boots each about the size of a house, the hiker serves a prag­matic pur­pose. Like a kind of topo­graphic patch, he cov­ers an area in the Italian Alps where the Swiss ap­par­ently lacked the nec­es­sary “information and data from the Italian ge­o­graph­i­cal ser­vices.”

The mar­mot, the lat­est il­lus­tra­tion, hides in plain sight in the Swiss Alps. His plump out­line was con­cealed in the del­i­cate re­lief shad­ing above a glac­ier, which shielded him from de­tec­tion for nearly five years. The moun­tain’s hachures— short, par­al­lel lines that in­di­cate the an­gle and ori­en­ta­tion of a slope— dou­ble as his fur. He is mostly in­dis­tin­guish­able from the sur­round­ing rock, ex­cept for his face, tail, and paws. He even fits eco­log­i­cally: as an an­i­mal of the ice age, alpine mar­mots are com­fort­able at high al­ti­tudes, bur­row­ing into frozen rock for their nine months of hi­ber­na­tion. In 2016, Hurni re­vealed his lo­ca­tion to the pub­lic on be­half of an un­named source.

There is a de­gree of wink­ing tol­er­ance for these draw­ings, which con­sti­tute some­thing of an un­of­fi­cial na­tional tra­di­tion: the spokes­woman for Swisstopo re­ferred me to a 1901 fish hid­den in a well-known paint­ing of Lake Lucerne at the National Council palace (probably in honor of the palace’s April 1st in­au­gu­ra­tion, which some European coun­tries cel­e­brate by at­tach­ing “April Fish” to the backs of shirts). Nevertheless, the mar­mot—along with the face and hiker—will likely be “eliminated” from Switzerland’s next of­fi­cial map (per a de­ci­sion from the chief of car­tog­ra­phy).

Swiss car­tog­ra­phers have a long­stand­ing rep­u­ta­tion for topo­graph­i­cal rigor. A so-called “Seven Years War of Cartography” was even waged in the 1920s over the scale of the na­tional maps, with the Swiss Alpine Club ad­vo­cat­ing greater topo­graph­i­cal de­tail for its moun­taineer­ing mem­bers. Swisstopo is now an in­dus­try bench­mark for the moun­tains, from its use of aer­ial pho­togram­me­try (images taken first by bal­loons and then small planes) to aer­ial per­spec­tive (that nat­ural hazi­ness that ren­ders dis­tant peaks with less con­trast). In 1988, they were com­mis­sioned to draw Mount Everest.

Still, the orig­i­nal draw­ings were never au­tho­rized in the first place. Perhaps a metic­u­lous read­ing of next year’s Swiss maps may re­veal some other na­tion­ally-cel­e­brated an­i­mals in un­fre­quented bod­ies of wa­ter or alpine mead­ows. As Juerg Gilgen, a cur­rent car­tog­ra­pher at Swisstopo, told me “as a mat­ter of fact, the proof-reader is also just a hu­man be­ing prone to fail­ure. And car­tog­ra­phers are also just hu­man be­ings try­ing to fool around.”

Skip to con­tent

Most met­ros are adding jobs more slowly than nor­mal. Char­lotte leads in job growth among ma­jor met­ros, while Austin and Denver fall far short of their his­tor­i­cally strong pace.

High-income sec­tors are con­tract­ing, while Education and Healthcare are ex­pand­ing faster than nor­mal across most met­ros.

Employment com­po­si­tion mat­ters as much as to­tal growth for lo­cal hous­ing mar­ket strength. Met­ros re­liant on lower-wage job growth are likely to face softer for-sale de­mand.

The na­tional la­bor mar­ket is soft­en­ing, with im­pli­ca­tions for lo­cal hous­ing mar­kets. Most ma­jor met­ros are adding jobs more slowly than nor­mal. We an­a­lyzed em­ploy­ment per­for­mance by metro and in­dus­try, com­par­ing to­day’s growth to long-term trends since 2010. Red rep­re­sents job losses, yel­low shows slower-than-nor­mal growth, and green rep­re­sents faster-than-nor­mal growth.

The job mar­ket dri­ves hous­ing de­mand, but the type of jobs cre­ated or lost im­pacts the type of hous­ing. High-income sec­tors—In­for­ma­tion, Professional Services, and Financial Activities—are shrink­ing across most ma­jor met­ros. Workers in these in­dus­tries drive for-sale hous­ing de­mand more than rental de­mand. Nationally, high-in­come sec­tor em­ploy­ment re­mained flat YOY in August, well be­low its long-term com­pound an­nual growth of +1.6%.The Education and Healthcare sec­tors ac­count for the bulk of new jobs added in most met­ros and are grow­ing faster than nor­mal in al­most every mar­ket. Many of these jobs pay lower wages on av­er­age and of­ten gen­er­ate rental de­mand more than home­buy­ing ac­tiv­ity. Nationally, ed­u­ca­tion and health­care em­ploy­ment rose +3.3% YOY in August, well above its long-term com­pound an­nual growth of +2.1%

Philadelphia (+1.8% YOY) and New York (+1.7% YOY) show stronger job growth than their his­tor­i­cal trends (+1.1% and +1.6%, re­spec­tively). However, this im­prove­ment re­flects re­cov­ery from weak post-Great Financial Crisis base­lines rather than gen­uine out­per­for­mance. Charlotte (+2.6% YOY) is a stand­out per­former, main­tain­ing ro­bust job growth sup­ported by Professional Services ex­pan­sion (+4.5% YOY)—a rare bright spot for for-sale de­mand.Austin (+0.8% YOY) and Den­ver (+0.0% YOY) are grow­ing much more slowly than their his­tor­i­cally strong em­ploy­ment trends (+3.8% and +2.3%, re­spec­tively). Tech and Professional Services jobs are de­clin­ing in both mar­kets, and even health­care—which is ex­pand­ing faster than nor­mal in most met­ros—shows weak growth here. This re­duc­tion in high-pay­ing jobs is weak­en­ing de­mand for both home pur­chases and rentals.The Bay Area continues to lose jobs across high-in­come sec­tors (-0.4% YOY), dri­ving mod­est over­all em­ploy­ment de­clines. These job losses have slowed com­pared to a year ago but re­main neg­a­tive YOY. Despite gen­er­at­ing sub­stan­tial spend­ing and wealth, the AI-driven tech boom has­n’t added mean­ing­ful em­ploy­ment to the re­gion.

What this means for your busi­ness

Whether you build, in­vest, or ad­vise in hous­ing mar­kets, these em­ploy­ment shifts will im­pact your growth op­por­tu­ni­ties in 2026 and be­yond:Rental op­er­a­tors: Pre­pare for sus­tained de­mand from renters em­ployed in health­care and ed­u­ca­tion.

Our Metro and Regional Housing re­search pack­age in­cludes analy­sis of the lat­est de­mand, sup­ply, and af­ford­abil­ity fun­da­men­tals for each metro and re­gion as well as re­sults from our pro­pri­etary sur­veys. Our consulting team con­tin­u­ally eval­u­ates mar­ket fea­si­bil­ity, ab­sorp­tion/​pric­ing/​prod­uct rec­om­men­da­tions, and over­all in­vest­ment/​ex­pan­sion strat­egy in mar­kets na­tion­wide. Combining these two ar­eas of ex­per­tise yields qual­i­ta­tive and quan­ti­ta­tive in­sight for more in­tel­li­gent de­ci­sion-mak­ing.

This pack­age pro­vides a com­plete pic­ture of hous­ing sup­ply, de­mand, and af­ford­abil­ity through lo­cal in­sight, pro­pri­etary sur­veys, and ex­ten­sive data analy­sis. We cur­rently pro­vide an overview of ma­jor hous­ing and eco­nomic trends across 100 MSAs na­tion­wide.

Our re­search ser­vices en­able our clients to gauge hous­ing mar­ket con­di­tions and bet­ter align their busi­ness and strate­gic in­vest­ments in the hous­ing in­dus­try. We pro­vide a thought­ful and unique holis­tic ap­proach of both quan­ti­ta­tive and qual­i­ta­tive analy­sis to help clients make in­formed hous­ing in­vest­ment de­ci­sions.

Our ex­pe­ri­enced team of con­sul­tants helps clients make sound hous­ing in­vest­ment de­ci­sions. We thrive on their suc­cess and work with many clients over mul­ti­ple years and nu­mer­ous pro­jects. ​

Connect with me on LinkedIn

John leads JBREC’s Southern California mar­ket cov­er­age for the Metro Analysis and Forecast re­ports, pro­duces the Regional Analysis and Forecast and Homebuilder Analysis and Forecast re­ports, and as­sists with cov­er­age of the pub­lic home­builder space.

If you have any ques­tions about our ser­vices or if you would like to speak to one of our ex­perts about we can help your busi­ness, please con­tact Client Relations at clientser­vices@jbrec.com.

Want to in­ter­view one of our ex­perts?

Media pro­fes­sion­als seek­ing ex­pert analy­sis and au­thor­i­ta­tive com­men­tary on US hous­ing mar­ket trends, pol­icy im­pacts, and in­dus­try de­vel­op­ments can email our team for in­ter­views, quotes, and data-dri­ven in­sights.

Every week, we de­liver analy­sis to over 40,000 sub­scribers with our Building Market Intelligence™ newslet­ter. Subscribe to our weekly BMI newslet­ters to stay cur­rent on press­ing top­ics in the hous­ing in­dus­try.

What’s ahead for hous­ing—In­sights from our 2026 Housing Market Outlook con­fer­ence

Experiences with the Matrix pro­to­col, Matrix Synapse server, bridges, and Element mo­bile apps.

I have been host­ing a Matrix server for about five years now, mostly for text chats be­tween a few rel­a­tives and close friends, and a bridge to WhatsApp for a few more peo­ple. These are my ex­pe­ri­ences.

I don’t have many thoughts on the pro­to­col it­self.

The only thing that I don’t re­ally un­der­stand is the de­ci­sion on data repli­ca­tion. If a user on server A joins a room on server B, re­cent room data is copied from server B to server A and then kept in sync on both servers. I sup­pose this re­duces the load on the orig­i­nal server at the ex­pense of fed­er­a­tion over­head and space on other servers. However, this also cre­ates a sit­u­a­tion where any­thing said across fed­er­a­tion can­not be un­said, which is an ironic sit­u­a­tion for a pro­to­col/​sys­tem that of­ten comes up when talk­ing about pri­vacy.

Synapse is the only choice that sup­ports bridges, which was why I wanted to try Matrix in the first place. And back in 2019-2020 this was the only choice any­way.

As of right now, I run Synapse, PostgreSQL, and co­turn di­rectly, with­out con­tainer­iza­tion, on a small VPS.

Works fairly re­li­ably, sup­ports bridges, and is more ef­fi­cient that it was in 2020.

API is well doc­u­mented, and al­lows au­then­ti­cat­ing and send­ing (unencrypted) mes­sages via sim­ple HTTP calls. At some point in time, I wanted to write a sim­ple shell client to use with SXMO and such.

Does not have an ad­min panel

There is no ad­min page or panel. There was a third-party ad­min site, but it’s an en­tire site just for mak­ing HTTP calls. So I ended up writ­ing my own.

While tech­ni­cally, Synapse can work with a sqlite data­base (and which at first seems like an OK choice for hav­ing

Initial setup pre­sumes that the server is go­ing to be fed­er­ated, and there is no good way to turn it off. The best workaround in­volves a blank whitelist of fed­er­ated servers.

I don’t know the im­pli­ca­tions of dis­abling it.

Message re­ten­tion pol­icy can be set up server-wide, but also per-room. There are spe­cific lines in the con­fig­u­ra­tion that need to be set to ac­tu­ally en­able a ser­vice that runs the cleanup.

Synapse keeps the room even af­ter all of the mem­bers leave it, in­clud­ing fed­er­ated rooms. This re­sults in many (sometimes large) rooms with­out lo­cal mem­bers or­phaned on the server, tak­ing up data­base space.

Deleting mes­sages (events) with at­tach­ments does not delete the at­tach­ment (because an­other mes­sage might re­fer to it?), which means that the sent files con­tinue ex­ist­ing on the server in­def­i­nitely. Another pri­vacy im­pli­ca­tion. A sim­ple “delete all files older than X” script works great un­til it deletes avatars. So yeah, seems like this is some­thing that should be han­dled by the Synapse server in­stead of cob­bled-to­gether scripts.

Even af­ter ex­ten­sive cleanup, PostgreSQL data­base might need to be vac­u­umed to re­duce the disk space it takes up.

Even for my small server with

Synapse keeps track of room states in an ap­pend-only (!) table named state_­group­s_s­tate. Deleting a room does not delete the state_­group­s_s­tate records. So it is never au­to­mat­i­cally cleaned up, and grows in size in­fi­nitely. It is pos­si­ble to delete many of those records from the data­base di­rectly, and Element (the com­pany) pro­vides some tool to “compress” those records, but again, some­thing that should be han­dled by the server.

This is sim­ply not an op­tion in the API. Server ad­min can per­form a “deactivate” (disable lo­gin) and “erase” (remove re­lated data, which claims to be GDPR-compliant) on user ac­counts, but the ac­counts them­selves stay on the server for­ever.

How this not con­sid­ered a GDPR vi­o­la­tion is a mys­tery to me. Even on my tiny server, I have users who use their first name as their ID and bridged WhatsApp users that use phone num­bers as IDs.

While Matrix-Element ecosys­tem has been cater­ing to­wards gov­ern­ment and cor­po­rate en­ti­ties for some time, there have been mul­ti­ple re­cent an­nounce­ments about its fu­ture.

Specifically, Element (the com­pany) is now pro­vid­ing an all-in-one Element Server Suite (ESS) to re­place the cur­rent setup, in­clud­ing

It is in­tended for non-pro­fes­sional use, eval­u­a­tions, and small to mid-sized de­ploy­ments (1–100 users).

ESS Community in­cludes 7 com­po­nents/​ser­vices, now re­quires a min­i­mum of 2 CPUs, 2GB of RAM, and runs us­ing… Kubernetes? IMO, this is an overkill for dozen users.

For com­par­i­son, Snikket, an all-in-one so­lu­tion with sim­i­lar func­tion­al­ity us­ing XMPP, re­quires a sin­gle CPU and 128MB (!) RAM for 10 or so users.

Yes, I have seen the an­si­ble setup script setup rec­om­mended, but at this point, mak­ing setup eas­ier does not ad­dress the is­sue of ex­tra ser­vices be­ing re­quired in the first place.

Also, the ESS han­dles ac­count cre­ation and calls in an en­tirely dif­fer­ent way, more on that later.

Pretty great. Easy to in­stall and set up, works re­ally well, and needs only oc­ca­sional (semi-yearly or so) up­dates when WhatsApp changes their web API. Does not sup­port calls.

Same on all plat­forms

Element ex­ists and looks con­sis­tent on Android, iOS, and web, mak­ing it eas­ier for reg­u­lar users and for trou­bleshoot­ing.

This is silly, but while (official?) bridges sup­port im­age cap­tions, of­fi­cial Element app does not. The an­swer in the FAQ? Get a bet­ter app. Well, OK.

Image with a cap­tion in SchildiChat Classic (the bet­ter app).

Sometimes it can take up to a few min­utes to get a mes­sage, even be­tween two Android clients us­ing Google Cloud Messaging. Sometimes it is nearly in­stant. Still un­sure of the cause.

One un­re­li­able way to tell that the server is un­reach­able is the end­less load­ing bar. But even then, it even­tu­ally goes away with­out in­di­cat­ing any er­rors.

Then, when send­ing a mes­sage, the user re­ceives “Unable to send mes­sage”. Frustration en­sues.

But I know the app is try­ing to call the /sync end­point. Why does­n’t it show any er­rors when that fails?

IIRC the first thing the app does is ask user to back up their sign­ing keys and en­ter the key pass­word, with­out a sim­ple ex­pla­na­tion. Not a great ex­pe­ri­ence for reg­u­lar users.

Some peo­ple re­ported is­sues with Element los­ing its keys or fre­quently re­quest­ing to be re-ver­i­fied. Thankfully I have not en­coun­tered these.

Even if you con­nect to a self-hosted server, Element Classic could at­tempt to con­nect to vec­tor.im in­te­gra­tion server and ma­trix.org key backup server.

Element X is now rec­om­mended as the new and bet­ter client. It is not.

Somehow, it is slower. Clicking on a con­ver­sa­tion takes 0.5-1.0 sec­onds to load it, com­pared to al­most in­stant load on Classic.

Perhaps it does work bet­ter for ac­counts with many large rooms, but that is not my case.

Conversations are sorted by… who knows. It is not re­cent nor al­pha­bet­i­cal.

Element X does not sup­port pe­ri­odic back­ground sync, so you need to set up ntfy or some­thing sim­i­lar to use Element X on a de-googled de­vice. Seems like a sim­ple enough fail-safe (even WhatsApp does this), but it was dropped for some rea­son.

This “sliding sync” op­tion is avail­able only for newer Synapse ver­sions, and only if run­ning with PostgreSQL data­base (which should al­ready be the case - see above). Probably not an is­sue un­less the user tries to con­nect Element X to an out­dated Synapse.

Calling with Element X re­quires Element Call (part of ESS). This sup­ports group calls, but… only video calls at the mo­ment.

You also might be asked to tell your con­tact to in­stall the new app:

I don’t reg­u­larly use calls, but some peo­ple I would like to in­vite to my server would want to use them.

A few years ago, I ended up ei­ther tem­porar­ily en­abling un­re­stricted reg­is­tra­tion (a ter­ri­ble idea), or cre­at­ing my users’ ac­counts man­u­ally, be­cause the “invite” ma­trix.to link was bro­ken, and reg­is­tra­tion to­kens did not work cor­rectly in mo­bile apps.

So let’s see how it works now. Keep in mind, I am still on stand­alone Synapse, not ESS.

I am a user, and I was to reg­is­ter an ac­count on my friend’s server. I see that Element X is now a rec­om­mended app, so let’s try that.

Click “Create ac­count” (which is a dif­fer­ent style that does not look like a but­ton for some rea­son).

But I want an ac­count on a dif­fer­ent server. Click “Change ac­count provider”.

Now I can search for the server my friend is host­ing, and it should ap­pear in the list be­low the search.

As server ad­min: I do not re­mem­ber if Synapse server has to en­able/​keep fed­er­a­tion for this to work.

Yes! That is what I want, why is this so ver­bose?

WTF. So Element X can­not cre­ate even the sim­plest user­name+pass­word ac­count. That is all I want, I don’t want to sign in with Google, Apple, or any other form of third-party au­then­ti­ca­tion.

I was un­able to reg­is­ter an ac­count us­ing Element X, so Element Classic should work bet­ter.

What dif­fer­ence does this make? Skip.

The cur­rent of­fi­cial app is telling me to use Element X. Just tried that. Click “EDIT” where it says “matrix.org” (which does not say “server”, ac­tu­ally) and en­ter the server name.

Why not? No ex­pla­na­tion. Sure, I’ll use a web client.

Well, fuck me, I guess. Why can’t I just cre­ate an ac­count?

As a server ad­min: Synapse is set to al­low reg­is­tra­tions via reg­is­tra­tion to­kens, be­cause un­re­stricted reg­is­tra­tion is a bad idea. I did not find where the /static/client/register path is set.

IIRC it is pos­si­ble to reg­is­ter an ac­count by go­ing to a web-hosted Element app, such as app.el­e­ment.io, which will al­low to reg­is­ter an ac­count us­ing a reg­is­tra­tion to­ken. But then the user has to deal with the headache of cross-ver­i­fy­ing their mo­bile de­vice to the web app (which they might never use).

So now what?

Matrix-Element is grow­ing, build­ing new fea­tures, and ac­quir­ing large cus­tomers (mostly gov­ern­ment en­ti­ties AFAIK). However, the new cor­po­ratesque ESS Community is not worth it in my opin­ion. I don’t need fancy auth, third-party IDs, group video con­fer­enc­ing, or even fed­er­a­tion for that mat­ter. But it is clear that Synapse and Element X are se­verely crip­pled and are not de­signed to work with­out these ser­vices.

I will prob­a­bly switch to Snikket, which is more ef­fi­cient, has timely no­ti­fi­ca­tions, and very smooth on­board­ing.

I had never heard of Michael Green be­fore his now-in­fa­mous es­say “Part 1: My Life Is a Lie - How a Broken Benchmark Quietly Broke America” went ex­tremely vi­ral on X.

Go read it. The short ver­sion: real poverty is closer to $140,000 than $31,000.

“The U. S. poverty line is cal­cu­lated as three times the cost of a min­i­mum food diet in 1963, ad­justed for in­fla­tion.”

The com­po­si­tion of house­hold spend­ing trans­formed com­pletely. In 2024, food-at-home is no longer 33% of house­hold spend­ing. For most fam­i­lies, it’s 5 to 7 per­cent.

Housing now con­sumes 35 to 45 per­cent. Healthcare takes 15 to 25 per­cent. Childcare, for fam­i­lies with young chil­dren, can eat 20 to 40 per­cent.

If you keep Orshansky’s logic—if you main­tain her prin­ci­ple that poverty could be de­fined by the in­verse of food’s bud­get share—but up­date the food share to re­flect to­day’s re­al­ity, the mul­ti­plier is no longer three.

Which means if you mea­sured in­come in­ad­e­quacy to­day the way Orshansky mea­sured it in 1963, the thresh­old for a fam­ily of four would­n’t be $31,200.

It would be some­where be­tween $130,000 and $150,000.

And re­mem­ber: Orshansky was only try­ing to de­fine “too lit­tle.” She was iden­ti­fy­ing cri­sis, not suf­fi­ciency. If the cri­sis thresh­old—the floor be­low which fam­i­lies can­not func­tion—is hon­estly up­dated to cur­rent spend­ing pat­terns, it lands at $140,000.

This ar­ti­cle res­onated with me be­cause I have had three chil­dren born since 2021 - well, tech­ni­cally, my third ar­rives in a week.

I have spent $30,000, $35,000, and now $40,000 for each child de­liv­ered.

That is my full out-of-pocket cash-paid cost as a self-em­ployed en­tre­pre­neur who runs a small busi­ness. I do not have a cor­po­rate daddy to share costs with me. This is to­tally un­sus­tain­able and in­sane, yet every cen­tral bank-wor­ship­ping think tank econ­o­mist who at­tacked Green had noth­ing to say when I asked them to jus­tify my so­cial­ized cost for the pub­lic good of bring­ing a new tax-payer into this world.

America has a cost of liv­ing cri­sis; it’s not be­ing taken se­ri­ously by “serious” econ­o­mists; and the on­go­ing fail­ure to ad­dress it will lead to po­lit­i­cal, so­cial, and eco­nomic calamity.

The es­sen­tial theme of Green’s piece is that “participation costs” - the price of ad­mis­sion you pay to sim­ply be in the mar­ket, let alone win, have grown out of con­trol. Food and shel­ter are par­tic­i­pa­tion costs for liv­ing. Having a $200/mo smart­phone is now a par­tic­i­pa­tion cost for many things such as get­ting ac­cess to your bank­ing in­for­ma­tion re­motely, med­ical records, and work / school.

There’s no greater “participation cost” to hu­man civ­i­liza­tion than re­pro­duc­tion.

I run Petabridge - we’re a small, spe­cial­ized soft­ware com­pany. I have fewer than 5 em­ploy­ees and I own 100% of the com­pany. Been in busi­ness for 11 years. I love what I do. We’re too small for most tra­di­tional in­sur­ance bro­kers / group mar­ket­places but use TriNet, one of the largest Professional Employment Organizations (PEO)s in the United States, to han­dle pay­roll / taxes / ben­e­fits. I also used them when I ran MarkedUp, my last com­pany be­fore Petabridge.

My wife and I got mar­ried in 2020 and she be­came a full-time home maker, so I’m the sole bread win­ner.

This is what my cur­rent health care costs look like per pay pe­riod, which is bi­monthly.

Remember, I own 100% of the com­pany - so it makes no real dif­fer­ence which side of the ledger the money comes from. I pay the full freight.

Before any of those magic ben­e­fits kick in though, there’s the sticky is­sue of my health in­sur­ance de­ductible:

I have to hit a $14,300 de­ductible first, which I will ab­solutely hit next week when my child is de­liv­ered (if I haven’t al­ready.)

Thus I’ll spend $39,980 bring­ing my new daugh­ter into this world in 2025, and there are as­suredly things I’ve paid for that are not cov­ered by in­sur­ance ei­ther (i.e. we paid for some tests and sono­grams that aren’t cov­ered at all by our plan) - so the real cost will be $40k+ when it’s all said and done.

Here’s what my in­sur­ance pre­mi­ums look like for 2026:

The de­ductible is stay­ing the same at $14,300, so now my max spend is $43,496 - an 8.8% in­crease in to­tal cost over the pre­vi­ous year, but a 13.6% in­crease in pre­mi­ums. I’ve had some ver­sion of this plan for about 5 years and this price in­crease has been fairly con­sis­tent over time - I think I was pay­ing $1850 a month in pre­mi­ums back in 2021, which was more than my mort­gage.

My ac­tual in­sur­ance cost is some­what higher than the $40,000 I’ve laid out here.

I also pay $1250 per month to TriNet for the priv­i­lege of be­ing able to buy their health in­sur­ance in the first place - sure, I get some other ben­e­fits too, but I’m the only US-based em­ployee cur­rently so this over­head is re­ally 100% me. The only rea­son I stick with TriNet and don’t re­place them with a sig­nif­i­cantly cheaper pay­roll proces­sor like QuickBooks Payroll is for ac­cess to their health in­sur­ance ben­e­fits.

So my real par­tic­i­pa­tion cost is closer to $55,000 a year - the health­care mar­ket is so­cial­iz­ing enor­mous costs to me for pub­lic ser­vice of sir­ing new tax­pay­ers.

Health young peo­ple who can par­tic­i­pate in Obamacare / eHealth Insurance (individual) mar­kets; and

Poor peo­ple who get ei­ther sub­si­dized ACA plans or Medicaid.

I have the mis­for­tune of cre­at­ing jobs for other peo­ple, so op­tion 1 is out.

My wife and I are healthy, but we’re build­ing our fam­ily and I have yet to see a mar­ket­place plan that sup­ports child-birth. Maybe the sub­si­dized ones do, but I earn too much money to see those. All of the ones I’ve found through eHealth Insurance or Healthcare.gov never cover it - and I check every year. So op­tions 2 and 3 are out. This leaves me with few op­tions to con­tinue run­ning my com­pany AND grow a fam­ily at the same time.

The Affordable Care Act (Obamacare) barred in­sur­ers from turn­ing down ap­pli­cants based on ex­ist­ing pre-con­di­tions; the way in­sur­ers get around this for preg­nancy and child-birth is not by re­ject­ing preg­nant ap­pli­cants (illegal), but by sim­ply re­fus­ing to cover the care those ap­pli­cants need to sur­vive preg­nancy (legal and com­mon.)

I’ve had the same ver­sion of this Aetna plan since late 2020 when my wife and I got mar­ried and she quit her job. It’s the cheap­est PPO I can buy through TriNet that gives us ac­cess to our pe­di­a­tri­cian and OBGYN. The other PPOs are sig­nif­i­cantly more ex­pen­sive and usu­ally have lower de­ductibles. The “cheaper” al­ter­na­tives of­fered through TriNet are HMOs or EPOs that have some is­sues with them: co-in­sur­ance or none of our med­ical providers be­ing in their net­work.

If you’re fa­mil­iar with how health­care charge mas­ters work, then you’ll un­der­stand why co-in­sur­ance is a bad bet when you know for cer­tain you’re go­ing to need an ex­pen­sive med­ical in­ter­ven­tion (like child-birth.)

Earlier this month our 4 year old had a 15 minute pro­ce­dure to treat blad­der re­flux - the “billed cost” to Aetna was roughly $32,000. That’s nowhere close to the “real” cost of the pro­ce­dure, but the point stands: if you have a big med­ical event while you’re on co-in­sur­ance you might get ex­posed to the same heat lev­els that to­tally unin­sured peo­ple have to tol­er­ate.

I’ve also looked into buy­ing plans di­rectly from Aetna and other smaller bro­kers like SimplyInsured - sim­i­lar prob­lems there:

The costs are ac­tu­ally higher than what I’m al­ready pay­ing TriNet.

It’s also worth not­ing, by the way, that TriNet’s quotes to me aren’t unique to my com­pany, as far as I know. These are the stan­dard plans TriNet of­fers to all Texas-based em­ploy­ers.

My sit­u­a­tion leaves me with un­fa­vor­able op­tions:

Continue pay­ing through the nose for my Aetna PPO;

Drop health in­sur­ance al­to­gether; start ne­go­ti­at­ing cash set­tle­ments; and back­stop my risk with a plat­form like CrowdHealth - this is more time-ex­pen­sive and ex­poses us to risk, but it can be man­aged;

Use an EPO / HMO and search for new health care providers who will ac­cept these plans - we’ve looked and it’s bleak;

Have my wife go find a BigCo cor­po­rate job some­where and raise our chil­dren in day­care; or

Destroy my firm and all of the eco­nomic value it cre­ates to go get a BigCo job my­self.

I’ve cho­sen num­ber 1 be­cause I have to ne­go­ti­ate the fol­low­ing trade-offs:

Forcing my preg­nant wife to find new pe­di­a­tri­cians, OBGYN, GPs, et al for her and our chil­dren;

The amount of time I can per­son­ally spend each November search­ing for al­ter­na­tives - 10-30 hours each year usu­ally;

The amount of time I can per­son­ally spend ne­go­ti­at­ing health care costs - CrowdHealth might be able to help with that, but I’m ex­tremely time-poor at the mo­ment;

The amount of un­capped fi­nan­cial ex­po­sure I’m will­ing to tol­er­ate - this is why Aetna can get away with high­way rob­bery in the first place - in­sur­ers like them in­cen­tivize the cre­ation of this ex­po­sure risk through Chargemaster / dis­count games; and

The amount of cash I am will­ing to pay for any of the above.

I am for­tu­nate. I am a higher earner, so I can sign the enor­mous check each year. The real peo­ple who bear this cost though are the em­ploy­ees I’m not go­ing to hire; I’m not go­ing to spend $40-$100k an en­try level soft­ware en­gi­neer / ad­min / SDR / mar­keter or what­ever if I need to keep $55k in re­serve to ex­pand my fam­ily.

What if I was start­ing a solo plumb­ing busi­ness or a restau­rant? What would my al­ter­na­tives be then? What if I fell be­neath the “$140k poverty line” but not low enough where I can qual­ify for Medicaid / CHIP / sub­si­dized mar­ket plans? I’d be ut­terly screwed.

The prob­lem I have with health in­sur­ance is­n’t just the high price tag. It’s:

The real lack of vi­able al­ter­na­tives, mak­ing me feel robbed at gun­point while watch­ing my liv­ing stan­dards or op­tion­al­ity on my own hard-fought busi­ness cap­i­tal shrink each year.

The so­ci­etal ab­sur­dity of this sit­u­a­tion - what civ­i­liza­tion can sur­vive such strong eco­nomic head­winds against the re­pro­duc­tion of its own pop­u­lace? The health in­sur­ance mar­ket takes wealth from the young, healthy, and re­pro­duc­tive and trans­fers it as ser­vices to the old and dy­ing. This is in­sane and un­sus­tain­able.

The worst of all: I am old enough to re­mem­ber health in­sur­ance mar­kets not be­ing this way, so I know things can be dif­fer­ent.

The first thing I’d ex­pect some­one like Tyler Cowen to ex­plain to me, upon read­ing this post, is to gaslight me about me­dian health­care costs and show me a chart of pre­mi­ums stay­ing sta­ble in in­fla­tion-ad­justed dol­lars - as though that does any­thing to solve my im­me­di­ate prob­lem of hav­ing to spend a sum of money that is higher than many American’s an­nual in­come in or­der to have my third child de­liv­ered.

You can make the ar­gu­ment that maybe I need to change my sit­u­a­tion, but that ar­gu­ment is a to­tal loser. “Just go back to work for Microsoft” or “don’t have three chil­dren” or “send your wife back to work” or “move away from your fam­ily.”

If your an­swer to “I can’t af­ford to have chil­dren and run a busi­ness” is “then don’t,” you are build­ing the po­lit­i­cal con­di­tions for ex­trem­ism. This is how every rev­o­lu­tion starts: a crit­i­cal mass of peo­ple who con­clude the sys­tem of­fers them noth­ing worth pre­serv­ing. They don’t just want change - they want re­venge.

Economists and Wall Street big shots have not been re­motely per­sua­sive in mak­ing their case that “everyone is do­ing great in 2025, ac­tu­ally” be­cause it runs com­pletely afoul of most American’s re­cent ex­pe­ri­ences at the till, hence the high eco­nomic anx­i­ety re­flected in the polls.

Green writes a piece say­ing 140k is the new poverty line.

It’s thor­oughly de­bunked.

And a le­gion of the cred­u­lous syco­phants who dig the vibe ex post re­de­fine poverty to en­nui (the piece never would’ve got­ten trac­tion with­out the 140k poverty thing which we are now told is… https://​t.co/​LG2lQp2mgy— Clifford Asness (@CliffordAsness) December 1, 2025

The rea­son why Mike Green’s piece res­onated with so many is be­cause this sen­tence per­fectly cap­tures what I and many oth­ers have been try­ing to do for the past five years:

“Become rich enough to ig­nore the cost” - that is ex­actly what I have been try­ing to do and it is daunt­ing.

Per Jeff Bezos: “When the data and the anec­dotes dis­agree, the anec­dotes are usu­ally right.”

I am tired of hear­ing econ­o­mists tell me how great every­thing is by show­ing me a chart that does­n’t look any­thing like real life on the ground - that’s ex­actly how Biden got voted out on his ass and the same will hap­pen to Trump if con­di­tions don’t im­prove. My be­ing un­happy with the sta­tus quo is not “populism” - it’s re­al­ity. And it sucks.

A so­ci­ety that makes it this hard to have chil­dren is a so­ci­ety that has de­cided it does­n’t want a fu­ture. I’m fight­ing for mine any­way.

In a week, I’ll hold my third child. I’ll sign the check. I’ll keep build­ing my busi­ness. But I won’t pre­tend this is fine - and nei­ther should you.

At the start of each year, on January 1st, a new crop of works en­ter the pub­lic do­main and be­come free to en­joy, share, and reuse for any pur­pose. Due to dif­fer­ing copy­right laws around the world, there is no one sin­gle pub­lic do­main — and here we fo­cus on three of the most promi­nent. Newly en­ter­ing the pub­lic do­main in 2026 will be:

* works by peo­ple who died in 1955, for coun­tries with a copy­right term of “life plus 70 years” (e.g. UK, Russia, most of EU and South America);

* works by peo­ple who died in 1975, for coun­tries with a term of “life plus 50 years” (e.g. New Zealand, and most of Africa and Asia);

* films and books (incl. art­works fea­tured) pub­lished in 1930 for the United States.

In our ad­vent-style cal­en­dar be­low, find our top pick of what lies in store for 2026. Each day, as we move through December, we’ll open a new win­dow to re­veal our high­lights! By pub­lic do­main day on January 1st they will all be un­veiled — look out for a spe­cial blog­post from us on that day. (And, of course, if you want to dive straight in and ex­plore the vast swathe of new en­trants for your­self, just visit the links above).