* Yesterday, Pebble watch soft­ware was ~95% open source. Today, it’s 100% open source. You can down­load, com­pile and run all the soft­ware you need to use your Pebble. We just pub­lished the source code for the new Pebble mo­bile app!

* Pebble Appstore now has a pub­licly avail­able backup and sup­ports mul­ti­ple feeds, pro­vid­ing long term re­li­a­bil­ity through de­cen­tral­iza­tion. We’ve launched our own feed and Developer Dashboard.

* Pebble Time 2 sched­ule up­date (aiming to be­gin ship­ping in January, with most ar­riv­ing on wrists in March/April)

* New Tick Talk episode #4 is up, with Pebble Time 2 demos!

Pre-production Pebble Time 2 (Black/Red colour­way) in all its glory

Over the last year, and es­pe­cially in the last week, I’ve chat­ted with tons of peo­ple in the Pebble com­mu­nity. One of the main ques­tions peo­ple have is ‘how do I know that my new Pebble watch will con­tinue to work long into the fu­ture?’. It’s an ex­tremely valid ques­tion and con­cern - one that I share as a fel­low Pebble wearer. I called this out specif­i­cally in my blog post an­nounc­ing the re­launch in January 2025. How is this time round go­ing to be dif­fer­ent from last time?

There are two pieces to mak­ing Pebble sus­tain­able long term - hard­ware and soft­ware.

Nothing lasts for­ever, es­pe­cially an in­ex­pen­sive gad­get like a Pebble. We want to be able to keep man­u­fac­tur­ing these watches long into the fu­ture - mostly be­cause I will al­ways want one on my wrist! The com­pany I set up to re­launch Pebble, Core Devices, is self funded, built with­out in­vestors, and ex­tremely lean. As long as we stay prof­itable (ie we don’t lose money), we will con­tinue to man­u­fac­ture new watches.

We’re also mak­ing sure that our new watches are more re­pairable than old Pebble watches. The back cover of Pebble Time 2 is screwed in. You can re­move the back cover and re­place the bat­tery.

We’ve also pub­lished elec­tri­cal and me­chan­i­cal de­sign files for Pebble 2 Duo. Yes, you can down­load the schematic (includes KiCad pro­ject files) right now on Github! This should give you a nice jump­start to de­sign­ing your own PebbleOS-compatible de­vice.

Last time round, barely any of the Pebble soft­ware was open source. This made it very hard for the Pebble com­mu­nity to make im­prove­ments to their watches af­ter the com­pany be­hind Pebble shut down. Things are dif­fer­ent now! This whole re­launch came about pri­mar­ily be­cause Google open sourced PebbleOS (thank you!). Yesterday, the soft­ware that pow­ers Pebble watches was around 95% open source. As of to­day, it’s now 100%. This means that if Core Devices were to dis­ap­pear into a black hole, you have all the source code you need to build, run and im­prove the soft­ware be­hind your Pebble.

I con­fess that I mis­un­der­stood why 95% was much less sus­tain­able than 100% un­til re­cently. I dis­cuss this in more de­tail in my lat­est Tick Talk episode (check it out). Long story short - I’m an Android user and was happy to side­load the old Pebble APK on my phone, but iPhone and other Android users have ba­si­cally been stuck with­out an eas­ily avail­able Pebble mo­bile com­pan­ion app for years.

Here’s how we’re mak­ing sure the 3 main Pebble soft­ware com­po­nents are open source and guar­an­teed to work long into the fu­ture:

PebbleOS - soft­ware that runs on your watch it­self. This has been 100% open source since January and we’ve com­mit­ted to open sourc­ing all the im­prove­ments we’ve made → github.com/​core­de­vices/​Peb­bleOS. You can down­load the source code, com­pile PebbleOS and eas­ily in­stall it over Bluetooth on your new Pebble. Textbook de­f­i­n­i­tion of open source!

Pebble mo­bile com­pan­ion app - the app that for your iPhone or Android. Without the app, your Pebble is ba­si­cally a pa­per­weight. When the Pebble Tech Corp died, the lack of an open source mo­bile app made it dif­fi­cult for any­one to con­tinue to use their watches. We had to build an en­tirely new app (get it here). Today, our app is now 100% open source on Github - en­sur­ing that what hap­pened be­fore can­not hap­pen again. Want to learn more about how we built the new app cross plat­form us­ing Kotlin Multiplatform? Watch Steve’s pre­sen­ta­tion at Droidcon.

Developer tools and Pebble Appstore - this soft­ware en­ables peo­ple to build and share their watchapps and watch­faces.

In the case of dev tools, just be­ing open source is not enough. They needed to be up­dated to work on mod­ern com­put­ers. Before we made im­prove­ments, the state of the art of Pebble app de­vel­op­ment was us­ing an Ubuntu vir­tu­al­box VM with Python2! Over the sum­mer, our in­cred­i­bly pro­duc­tive in­tern up­graded all the SDK and dev tools and cre­ated a new way to de­velop Pebble apps in the browser. You should check them out!

Then there’s the Pebble Appstore. This is a col­lec­tion of nearly 15,000 watch­faces and watchapps that you - the Pebble com­mu­nity - de­vel­oped be­tween 2012 and July 2018. When Fitbit pulled the plug on the orig­i­nal Pebble Appstore, the Rebble Foundation down­loaded a copy of all the apps and faces, and set up a new web ser­vice to let users of the old Pebble app con­tinue to down­load and use watch­faces. This was an in­cred­i­ble ef­fort, one that I have used thou­sands of times and am a happy pay­ing sub­scriber. But it’s still cen­tral­ized - if their server dis­ap­pears, there is no freely avail­able backup.

To com­pen­sate for that, to­day we’re launch­ing two new things:

* The Pebble mo­bile app will soon (later this week) be able to sub­scribe to mul­ti­ple app­store ‘feeds’. This is sim­i­lar to open source pack­age man­agers like pip, AUR, APT, etc. Anyone can cre­ate a Pebble-compatible app­store feed and users will be able to browse apps from that feed in the Pebble mo­bile app.

* We’ve cre­ated our own Pebble Appstore feed (appstore-api.repebble.com) and new Developer Dashboard. Our feed (fyi pow­ered by 100% new soft­ware) is con­fig­ured to back up an archive of all apps and faces to Archive.org (backup will grad­u­ally com­plete over the next week). Today, our feed only has a sub­set of all Pebble watch­faces and apps (thank you aveao for cre­at­ing Pebble Archive!). Developers - you can up­load your ex­ist­ing or new apps right now! We hope that this sets a stan­dard for open­ness and we en­cour­age all feeds to pub­lish a freely and pub­licly avail­able archive.

Important to note - de­vel­op­ers will still be able to charge money for their apps and faces, us­ing Kiezel pay or other ser­vices. This change does not pre­clude them from do­ing that, in fact it makes it even eas­ier - I could see some de­vel­op­ers cre­at­ing a paid-only feed. As I re­cently wrote, we’re also work­ing on other ways for Pebble de­vel­op­ers to earn money by pub­lish­ing fun, beau­ti­ful and cre­ative Pebble apps.

Another im­por­tant note - some bi­nary blobs and other non-free soft­ware com­po­nents are used to­day in PebbleOS and the Pebble mo­bile app (ex: the heart rate sen­sor on PT2 , Memfault li­brary, and oth­ers). Optional non-free web ser­vices, like Wispr-flow API speech rec­og­nizer, are also used. These non-free soft­ware com­po­nents are not re­quired - you can com­pile and run Pebble watch soft­ware with­out them. This will al­ways be the case. More non-free soft­ware com­po­nents may ap­pear in our soft­ware in the fu­ture. The core Pebble watch soft­ware stack (everything you need to use your Pebble watch) will al­ways be open source.

Pre-production Pebble Time 2. These watches are not fi­nal qual­ity! We are still tweak­ing and tun­ing every­thing.

We’re cur­rently in the mid­dle of Pebble Time 2 de­sign ver­i­fi­ca­tion test (DVT) phase. After we fin­ish that, we go into pro­duc­tion ver­i­fi­ca­tion test (PVT) and then mass pro­duc­tion (MP). So far, things are pro­ceed­ing ac­cord­ing to the sched­ule up­date I shared last month but that is ex­tra­or­di­nar­ily sub­ject to change. We still have a lot of test­ing (especially wa­ter­proof and en­vi­ron­men­tal) to go. If we find prob­lems (which is likely) we will push the sched­ule back to make im­prove­ments to the prod­uct.

The one ma­jor com­pli­cat­ing fac­tor is the tim­ing of Chinese New Year (CNY). It’s early next year - fac­to­ries will shut down for 3 weeks start­ing around the end of January. After restart­ing, things al­ways take a week or two to get back to full speed.

We are try­ing our best to get into mass pro­duc­tion and ship out at most sev­eral thou­sand Pebble Time 2s be­fore CNY. It’s go­ing to be very tight 🤞. More likely is that pro­duc­tion will be­gin af­ter CNY, then we need to trans­fer the watches to our ful­fill­ment cen­ter, and ship them out. Realistically, at this time we’re fore­cast­ing that the ma­jor­ity of peo­ple will re­ceive their PT2 in March and April. Please keep in mind that things may still change.

There will be 4 colour op­tions for PT2 - black/​black, black/​red, sil­ver/​blue, sil­ver/(​white most likely). Let me be crys­tal very clear - no one has picked a colour yet 😃. In a few weeks, I will send out an email ask­ing every­one who pre-or­dered a Pebble Time 2 to se­lect which colour they would like to re­ceive. Please do not email us ask­ing when this email will be sent out. No one has been in­vited yet to do this. I will post here af­ter all emails have gone out.

On a re­lated note, I am ex­tremely happy that we built and shipped Pebble 2 Duo. Not only is it an awe­some watch, it was also a phe­nom­e­nal way for us to ex­er­cise our pro­duc­tion mus­cles and ease back into the sys­tem­atic flow of build­ing and ship­ping smart­watches.

A video is worth a mil­lion words - so I en­cour­age you to watch me demo Pebble Time 2 watches I just re­ceived this week. Keep in mind these watches are PRE-PRODUCTION which means they parts have im­per­fect qual­i­ties! Subject to change!

This link opens to the Youtube video to the Pebble Time 2 demo part!

Written by EMILY SNEDDON

Published on 6TH NOVEMBER 2025

Original draw­ings of the dis­play, cour­tesy of William Maley Jnr, for­mer owner and CEO of TRANS-LITE, INC.

Grid com­par­i­son. Left is a photo of the dis­play, right is Fran Sans.

Much Ado About Nothing

Fran Sans is a dis­play font in every sense of the term. It’s an in­ter­pre­ta­tion of the des­ti­na­tion dis­plays found on some of the light rail ve­hi­cles that ser­vice the city of San Francisco.

I say be­cause des­ti­na­tion dis­plays aren’t con­sis­tently used across the city’s tran­sit sys­tem. In fact, SF has an un­usu­ally high num­ber of in­de­pen­dent pub­lic tran­sit agen­cies. Unlike New York, Chicago or L. A., which each have one, maybe two, San Francisco and the greater Bay Area have over two dozen. Each agency, with its own mod­els of buses and trains, use dif­fer­ent des­ti­na­tion dis­plays, cre­at­ing an eclec­tic patch­work of ty­pog­ra­phy across the city.Among them, one dis­play in par­tic­u­lar has al­ways stood out to me: the LCD panel dis­plays in­side Muni’s Breda Light Rail Vehicles. I re­mem­ber first notic­ing them on a Saturday in October on the N-Judah, head­ing to the Outer Sunset for a shrimp hoagie. This con­text is im­por­tant, as any­one who’s spent an October week­end in SF knows this is the op­ti­mal vibe to re­ally take in the beauty of the city.

What caught my eye was how the dis­plays look me­chan­i­cal and yet dis­tinctly per­sonal. Constructed on a 3×5 grid, the char­ac­ters are made up of geo­met­ric mod­ules: squares, quar­ter-cir­cles, and an­gled forms. Combined, these mod­ules cre­ate im­per­fect, al­most prim­i­tive let­ter­forms, re­veal­ing a util­ity and charm that feels dis­tinctly like the San Francisco I’ve come to know.

This bal­ance of util­ity and charm seems to show up every­where in San Francisco and its his­tory. The Golden Gate’s “International Orange” started as noth­ing more than a rust-proof primer, yet is now the city’s defin­ing colour. The Painted Ladies be­came mul­ti­coloured icons af­ter the 1960s Colourist move­ment cov­ered decades of grey paint. Even the steep­ness of the streets was once an over­sight in city plan­ning but has since been ro­man­ti­cised in films and on post­cards. So per­haps it is un­sur­pris­ing that I would find this same util­ity and charm in a place as small and func­tional as a train sign.

To learn more about these dis­plays, I vis­ited the San Francisco Municipal Transportation Agency’s (SFMTA) Electronics Shop at Balboa Park. There, tech­ni­cian Armando Lumbad had set up one of the signs. They each fea­ture one large LCD panel which dis­plays the line name, and twenty-four smaller ones to dis­play the des­ti­na­tion. The loose spac­ing of the let­ters and flu­o­res­cent back­light­ing gives the sign a raw, ana­logue qual­ity. Modern LED dot-ma­trix dis­plays are far more ef­fi­cient and flex­i­ble, but to me, they lack the awk­ward­ness that makes these Breda signs so de­light­ful.

Armando showed me how the signs work. He handed me a printed ma­trix table list­ing every line and des­ti­na­tion, each paired with a three-digit code. On route, train op­er­a­tors punch the code into a con­trol panel at the back of the dis­play, and the LCD blocks light on spe­cific seg­ments of the grid to build each let­ter. I picked code 119, and Armando en­tered it for me. A few sec­onds later the pan­els re­vealed my own stop: the N-Judah at Church & Duboce. There in the work­shop, de­void of the con­text of the trains and the com­mute, the dis­play looked al­most mono­lithic, or sculp­tural, and I have since fan­ta­sised whether it would be pos­si­ble to ship one of these home to Australia.

Looking in­side of the dis­play, I found la­bels iden­ti­fy­ing the make and model. The signs were de­signed and man­u­fac­tured by Trans-Lite, Inc., a com­pany based in Milford, Connecticut that spe­cialised in trans­port sig­nage from 1959 un­til its ac­qui­si­tion by the Nordic firm Teknoware in 2012. After lots of am­a­teur de­tec­tive work, and with the help from an anony­mous Reddit user in a Connecticut com­mu­nity group, I was con­nected with Gary Wallberg, Senior Engineer at Trans-Lite and the per­son re­spon­si­ble for the de­sign of these very signs back in 1999.

Learning that the al­pha­bet came from an en­gi­neer re­ally ex­plains its tem­pera­ment and why I was drawn to it in the first place. The signs were de­signed for suf­fi­ciency: fixed seg­ments, fixed grid, and no ex­tras. Characters were cre­ated only as des­ti­na­tions re­quired them, while other char­ac­ters, like the Q, X, and much of the punc­tu­a­tion, were never pro­grammed into the signs. In re­duc­ing every­thing to its bare es­sen­tials, some­how char­ac­ter emerged, and it’s what in­spired me to de­sign Fran Sans.I shared some ini­tial draw­ings with Dave Foster of Foster Type who en­cour­aged me to get the font soft­ware Glyphs and turn it into my first work­ing font. From there, I broke down the anatomy of the let­ters into mod­ules, then used them like Lego to build out a full set: up­per­case A–Z, nu­mer­als, core punc­tu­a­tion.

Some glyphs re­main un­solved in this first ver­sion, for ex­am­ple the stan­dard @ sym­bol re­fuses to squeeze po­litely into the 3×5 logic. Lowercase re­mains a ques­tion for the fu­ture, and would likely mean re­con­sid­er­ing the grid. But, as with the dis­plays them­selves, I am judg­ing Fran Sans as suf­fi­cient for now.

Getting up close to these signs, you’ll no­tice Fran Sans’ grid­lines are sim­pli­fied even from its real‑life muse, but my hope is that its char­ac­ter re­mains. Specifically: the N and the zero, where the un­usu­ally thick di­ag­o­nals close in on the coun­ters; and the Z and 7, whose di­ag­o­nals can feel un­com­fort­ably thin. I’ve also no­ticed the cen­tre of the M can scale strangely and read like an H at small sizes, but in fair­ness, this type was never de­signed for the kind of tech­ni­cal de­tail so many mono­spaced fonts aim for. Throughout the process I tried to pro­tect these un­ortho­dox mo­ments, be­cause to me, they de­ter­mined the suc­cess of this in­ter­pre­ta­tion.

Fran Sans comes in three styles: Solid, Tile, and Panel, each build­ing in vi­sual com­plex­ity. The de­ci­sion to in­clude vari­a­tions, par­tic­u­larly the Solid style, was in­spired by my time work­ing at Christopher Doyle & Co. There, we worked with Bell Shakespeare, Australia’s na­tional the­atre com­pany ded­i­cated to the works of William Shakespeare. The eq­uity of the Bell Shakespeare brand lies in its ty­pog­ra­phy, which is a beau­ti­ful cus­tom type­face called Hotspur, de­signed and pro­duced by none other than Dave Foster.

Often, brand fonts are cho­sen or de­signed to con­vey a sin­gle feel­ing. Maybe it’s warmth and friend­li­ness, or a sense of tech and in­no­va­tion. But what I’ve al­ways loved about the Bell type­face is how one weight could serve both Shakespeare’s come­dies and tragedies, sim­ply by shift­ing scale, spac­ing, or align­ment. Hotspur has the grav­ity to carry the dark­ness of and the round­ness to con­vey the hu­mour of . And while Fran Sans Solid is tech­ni­cally no Hotspur, I wanted it to share that same ver­sa­til­ity.

Further in­spi­ra­tion for Fran Sans came from the Letterform Archive , the world’s lead­ing ty­pog­ra­phy archive, based in San Francisco. Librarian and archivist Kate Long Stellar thought­fully cu­rated a re­search visit filled with mod­u­lar ty­pog­ra­phy span­ning most of the past cen­tury. On the table were two pieces that had a sig­nif­i­cant im­pact on Fran Sans and are now per­sonal must-sees at the archive. First, Joan Trochut’s “Fast Type” (1942) was cre­ated dur­ing the Second World War when re­sources were scarce. gave print­ers the abil­ity to draw with type, re­ar­rang­ing mod­u­lar pieces to form let­ters, or­na­ments and even il­lus­tra­tions.

Second, Zuzana Licko’s process work for (1985), an Emigre type­face, opened new ways of think­ing about how ideas move be­tween the phys­i­cal and the dig­i­tal and then back again. Seeing how was doc­u­mented through it­er­a­tions and vari­a­tions gave the type­face a depth and rich­ness that changed my un­der­stand­ing of how fonts are built. At some point I want to ex­plore phys­i­cal ap­pli­ca­tions for Fran Sans out of re­spect for its ori­gins, since it is im­pos­si­ble to fully cap­ture the dis­play’s charm on screen.

Back at the SFMTA, Armando told me the Breda ve­hi­cles are be­ing re­placed, and with them their des­ti­na­tion dis­plays will be swapped for newer LED dot-ma­trix units that are more ef­fi­cient and eas­ier to main­tain. By the end of 2025 the signs that in­spired Fran Sans will dis­ap­pear from the city, tak­ing with them a small but dis­tinc­tive part of the city’s voice.

That feels like a real loss. San Francisco is al­ways rein­vent­ing it­self, yet its charm lies in how much of its his­tory still shows through. My hope is that Fran Sans can in­spire a deeper ap­pre­ci­a­tion for the im­per­fec­tions that give our lives and our cities char­ac­ter. Life is so rich when ease and ef­fi­ciency are not the mea­sure.

For com­mer­cial and non-com­mer­cial use of FRAN SANS, please get in touch: emily@emilysned­don.com WITH THANKSDave Foster, for be­ing my go-to at every stage of this pro­ject. Maria Doreuli, for thought­fully re­view­ing Fran Sans.Maddy Carrucan, for the words that al­ways keep me dreamy.Je­remy Menzies, for the pho­tog­ra­phy of the Breda ve­hi­cles.Kate Long Stellar, for cu­rat­ing a re­search visit on mod­u­lar ty­pog­ra­phy.Angie Wang, for sug­gest­ing it and help­ing to make it hap­pen.Vasiliy Tsurkan, for invit­ing me into to the SFMTA work­shop.Ar­mando Lumbad, for main­tain­ing the signs that I love so much.Rick Laubscher, for putting me in touch with the SFMTA.William Maley Jr, for open­ing up the TRANS-LITE, INC. archives.Gary Wallberg, for de­sign­ing and en­gi­neer­ing the orig­i­nal signs.Gre­gory Wallberg, for re­spond­ing to a very sus­pi­cious face­book post.Red­dit u/​steve31086, for sleuthing the de­tails of William Maley Jr.

OUTSIDE MY LIFE,

INSIDE THE DREAM.

FALLING UP THE STAIRS,

INTO THE STREET.

LET THE CABLE CAR

CARRY ME.

STRAIGHT OUT OF TOWN,

INTO THE SEA.

PAST THE DAHLIAS AND

THE SELF-DRIVING CARS.

THE CHURCH OF 8 WHEELS.

THE LOWER HAIGHT BARS.

THE PEAK HOUR SPRAWL.

THE KIDS IN THE PARK.

THE SLANTING HOUSES.

THE BAY AFTER DARK.

MY WINDOW, MY OWN

SILVER SCREEN.

I FOLLOW WHERE THE

FOG TAKES ME.

Our newest model, Claude Opus 4.5, is avail­able to­day. It’s in­tel­li­gent, ef­fi­cient, and the best model in the world for cod­ing, agents, and com­puter use. It’s also mean­ing­fully bet­ter at every­day tasks like deep re­search and work­ing with slides and spread­sheets. Opus 4.5 is a step for­ward in what AI sys­tems can do, and a pre­view of larger changes to how work gets done. Claude Opus 4.5 is state-of-the-art on tests of real-world soft­ware en­gi­neer­ing:Opus 4.5 is avail­able to­day on our apps, our API, and on all three ma­jor cloud plat­forms. If you’re a de­vel­oper, sim­ply use claude-opus-4-5-20251101 via the Claude API. Pricing is now $5/$25 per mil­lion to­kens—mak­ing Opus-level ca­pa­bil­i­ties ac­ces­si­ble to even more users, teams, and en­ter­prises.Along­side Opus, we’re re­leas­ing up­dates to the Claude Developer Platform, Claude Code, and our con­sumer apps. There are new tools for longer-run­ning agents and new ways to use Claude in Excel, Chrome, and on desk­top. In the Claude apps, lengthy con­ver­sa­tions no longer hit a wall. See our prod­uct-fo­cused sec­tion be­low for de­tails.As our Anthropic col­leagues tested the model be­fore re­lease, we heard re­mark­ably con­sis­tent feed­back. Testers noted that Claude Opus 4.5 han­dles am­bi­gu­ity and rea­sons about trade­offs with­out hand-hold­ing. They told us that, when pointed at a com­plex, multi-sys­tem bug, Opus 4.5 fig­ures out the fix. They said that tasks that were near-im­pos­si­ble for Sonnet 4.5 just a few weeks ago are now within reach. Overall, our testers told us that Opus 4.5 just “gets it.”Many of our cus­tomers with early ac­cess have had sim­i­lar ex­pe­ri­ences. Here are some ex­am­ples of what they told us:Opus mod­els have al­ways been “the real SOTA” but have been cost pro­hib­i­tive in the past. Claude Opus 4.5 is now at a price point where it can be your go-to model for most tasks. It’s the clear win­ner and ex­hibits the best fron­tier task plan­ning and tool call­ing we’ve seen yet.Claude Opus 4.5 de­liv­ers high-qual­ity code and ex­cels at pow­er­ing heavy-duty agen­tic work­flows with GitHub Copilot. Early test­ing shows it sur­passes in­ter­nal cod­ing bench­marks while cut­ting to­ken us­age in half, and is es­pe­cially well-suited for tasks like code mi­gra­tion and code refac­tor­ing.Claude Opus 4.5 beats Sonnet 4.5 and com­pe­ti­tion on our in­ter­nal bench­marks, us­ing fewer to­kens to solve the same prob­lems. At scale, that ef­fi­ciency com­pounds.Claude Opus 4.5 de­liv­ers fron­tier rea­son­ing within Lovable’s chat mode, where users plan and it­er­ate on pro­jects. Its rea­son­ing depth trans­forms plan­ning—and great plan­ning makes code gen­er­a­tion even bet­ter.Claude Opus 4.5 ex­cels at long-hori­zon, au­tonomous tasks, es­pe­cially those that re­quire sus­tained rea­son­ing and multi-step ex­e­cu­tion. In our eval­u­a­tions it han­dled com­plex work­flows with fewer dead-ends. On Terminal Bench it de­liv­ered a 15% im­prove­ment over Sonnet 4.5, a mean­ing­ful gain that be­comes es­pe­cially clear when us­ing Warp’s Planning Mode.Claude Opus 4.5 achieved state-of-the-art re­sults for com­plex en­ter­prise tasks on our bench­marks, out­per­form­ing pre­vi­ous mod­els on multi-step rea­son­ing tasks that com­bine in­for­ma­tion re­trieval, tool use, and deep analy­sis.Claude Opus 4.5 de­liv­ers mea­sur­able gains where it mat­ters most: stronger re­sults on our hard­est eval­u­a­tions and con­sis­tent per­for­mance through 30-minute au­tonomous cod­ing ses­sions.Claude Opus 4.5 rep­re­sents a break­through in self-im­prov­ing AI agents. For au­toma­tion of of­fice tasks, our agents were able to au­tonomously re­fine their own ca­pa­bil­i­ties—achiev­ing peak per­for­mance in 4 it­er­a­tions while other mod­els could­n’t match that qual­ity af­ter 10. They also demon­strated the abil­ity to learn from ex­pe­ri­ence across tech­ni­cal tasks, stor­ing in­sights and ap­ply­ing them later.Claude Opus 4.5 is a no­table im­prove­ment over the prior Claude mod­els in­side Cursor, with im­proved pric­ing and in­tel­li­gence on dif­fi­cult cod­ing tasks.Claude Opus 4.5 is yet an­other ex­am­ple of Anthropic push­ing the fron­tier of gen­eral in­tel­li­gence. It per­forms ex­ceed­ingly well across dif­fi­cult cod­ing tasks, show­cas­ing long-term goal-di­rected be­hav­ior.Claude Opus 4.5 de­liv­ered an im­pres­sive refac­tor span­ning two code­bases and three co­or­di­nated agents. It was very thor­ough, help­ing de­velop a ro­bust plan, han­dling the de­tails and fix­ing tests. A clear step for­ward from Sonnet 4.5.Claude Opus 4.5 han­dles long-hori­zon cod­ing tasks more ef­fi­ciently than any model we’ve tested. It achieves higher pass rates on held-out tests while us­ing up to 65% fewer to­kens, giv­ing de­vel­op­ers real cost con­trol with­out sac­ri­fic­ing qual­ity.We’ve found that Opus 4.5 ex­cels at in­ter­pret­ing what users ac­tu­ally want, pro­duc­ing share­able con­tent on the first try. Combined with its speed, to­ken ef­fi­ciency, and sur­pris­ingly low cost, it’s the first time we’re mak­ing Opus avail­able in Notion Agent.Claude Opus 4.5 ex­cels at long-con­text sto­ry­telling, gen­er­at­ing 10-15 page chap­ters with strong or­ga­ni­za­tion and con­sis­tency. It’s un­locked use cases we could­n’t re­li­ably de­liver be­fore.Claude Opus 4.5 sets a new stan­dard for Excel au­toma­tion and fi­nan­cial mod­el­ing. Accuracy on our in­ter­nal evals im­proved 20%, ef­fi­ciency rose 15%, and com­plex tasks that once seemed out of reach be­came achiev­able.Claude Opus 4.5 is the only model that nails some of our hard­est 3D vi­su­al­iza­tions. Polished de­sign, taste­ful UX, and ex­cel­lent plan­ning & or­ches­tra­tion - all with more ef­fi­cient to­ken us­age. Tasks that took pre­vi­ous mod­els 2 hours now take thirty min­utes.Claude Opus 4.5 catches more is­sues in code re­views with­out sac­ri­fic­ing pre­ci­sion. For pro­duc­tion code re­view at scale, that re­li­a­bil­ity mat­ters.Based on test­ing with Junie, our cod­ing agent, Claude Opus 4.5 out­per­forms Sonnet 4.5 across all bench­marks. It re­quires fewer steps to solve tasks and uses fewer to­kens as a re­sult. This in­di­cates that the new model is more pre­cise and fol­lows in­struc­tions more ef­fec­tively — a di­rec­tion we’re very ex­cited about.The ef­fort pa­ra­me­ter is bril­liant. Claude Opus 4.5 feels dy­namic rather than over­think­ing, and at lower ef­fort de­liv­ers the same qual­ity we need while be­ing dra­mat­i­cally more ef­fi­cient. That con­trol is ex­actly what our SQL work­flows de­mand.We’re see­ing 50% to 75% re­duc­tions in both tool call­ing er­rors and build/​lint er­rors with Claude Opus 4.5. It con­sis­tently fin­ishes com­plex tasks in fewer it­er­a­tions with more re­li­able ex­e­cu­tion.Claude Opus 4.5 is smooth, with none of the rough edges we’ve seen from other fron­tier mod­els. The speed im­prove­ments are re­mark­able.We give prospec­tive per­for­mance en­gi­neer­ing can­di­dates a no­to­ri­ously dif­fi­cult take-home exam. We also test new mod­els on this exam as an in­ter­nal bench­mark. Within our pre­scribed 2-hour time limit, Claude Opus 4.5 scored higher than any hu­man can­di­date ever1.The take-home test is de­signed to as­sess tech­ni­cal abil­ity and judg­ment un­der time pres­sure. It does­n’t test for other cru­cial skills can­di­dates may pos­sess, like col­lab­o­ra­tion, com­mu­ni­ca­tion, or the in­stincts that de­velop over years. But this re­sult—where an AI model out­per­forms strong can­di­dates on im­por­tant tech­ni­cal skills—raises ques­tions about how AI will change en­gi­neer­ing as a pro­fes­sion. Our Societal Impacts and Economic Futures re­search is aimed at un­der­stand­ing these kinds of changes across many fields. We plan to share more re­sults soon.Soft­ware en­gi­neer­ing is­n’t the only area on which Claude Opus 4.5 has im­proved. Capabilities are higher across the board—Opus 4.5 has bet­ter vi­sion, rea­son­ing, and math­e­mat­ics skills than its pre­de­ces­sors, and it is state-of-the-art in many do­mains:2O­pus 4.5 writes bet­ter code, lead­ing across 7 out of 8 pro­gram­ming lan­guages on SWE-bench Multilingual.Opus 4.5 can solve chal­leng­ing cod­ing prob­lems with ease with a 10.6% jump over Sonnet 4.5 on Aider Polyglot.Opus 4.5 im­proves on fron­tier agen­tic search with a sig­nif­i­cant jump on BrowseComp-Plus.Opus 4.5 stays on track over the long haul earn­ing 29% more than Sonnet 4.5 on Vending-Bench.The mod­el’s ca­pa­bil­i­ties out­pace some of the bench­marks we use in our tests. A com­mon bench­mark for agen­tic ca­pa­bil­i­ties is τ2-bench, which mea­sures the per­for­mance of agents in real-world, multi-turn tasks. In one sce­nario, mod­els have to act as an air­line ser­vice agent help­ing a dis­tressed cus­tomer. The bench­mark ex­pects mod­els to refuse a mod­i­fi­ca­tion to a ba­sic econ­omy book­ing since the air­line does­n’t al­low changes to that class of tick­ets. Instead, Opus 4.5 found an in­sight­ful (and le­git­i­mate) way to solve the prob­lem: up­grade the cabin first, then mod­ify the flights.Let me think about what op­tions I have within my pol­icy:

1. Modify flights - Basic econ­omy can­not be mod­i­fied. This is clear in the pol­icy.

2. Change cabin - Wait, let me check this op­tion! The pol­icy says:

“In other cases, all reser­va­tions, in­clud­ing ba­sic econ­omy, can change cabin with­out chang­ing the flights.”

But he wants to change the flights, not just the cabin. However, what if we:

- Change the cabin first (which IS al­lowed for ba­sic econ­omy), then

- Change the flights (which is al­lowed for non-ba­sic econ­omy)

So the strat­egy could be:

1. Upgrade his cabin from ba­sic econ­omy to econ­omy (or busi­ness)

2. Then mod­ify the flights to be 2 days later

This would cost more money, but it’s a le­git­i­mate path within the pol­icy!The bench­mark tech­ni­cally scored this as a fail­ure be­cause Claude’s way of help­ing the cus­tomer was unan­tic­i­pated. But this kind of cre­ative prob­lem solv­ing is ex­actly what we’ve heard about from our testers and cus­tomers—it’s what makes Claude Opus 4.5 feel like a mean­ing­ful step for­ward.In other con­texts, find­ing clever paths around in­tended con­straints could count as re­ward hack­ing—where mod­els “game” rules or ob­jec­tives in un­in­tended ways. Preventing such mis­align­ment is one of the ob­jec­tives of our safety test­ing, dis­cussed in the next sec­tion.As we state in our sys­tem card, Claude Opus 4.5 is the most ro­bustly aligned model we have re­leased to date and, we sus­pect, the best-aligned fron­tier model by any de­vel­oper. It con­tin­ues our trend to­wards safer and more se­cure mod­els:In our eval­u­a­tion, “concerning be­hav­ior” scores mea­sure a very wide range of mis­aligned be­hav­ior, in­clud­ing both co­op­er­a­tion with hu­man mis­use and un­de­sir­able ac­tions that the model takes at its own ini­tia­tive [3].Our cus­tomers of­ten use Claude for crit­i­cal tasks. They want to be as­sured that, in the face of ma­li­cious at­tacks by hack­ers and cy­ber­crim­i­nals, Claude has the train­ing and the “street smarts” to avoid trou­ble. With Opus 4.5, we’ve made sub­stan­tial progress in ro­bust­ness against prompt in­jec­tion at­tacks, which smug­gle in de­cep­tive in­struc­tions to fool the model into harm­ful be­hav­ior. Opus 4.5 is harder to trick with prompt in­jec­tion than any other fron­tier model in the in­dus­try:Note that this bench­mark in­cludes only very strong prompt in­jec­tion at­tacks. It was de­vel­oped and run by Gray Swan.You can find a de­tailed de­scrip­tion of all our ca­pa­bil­ity and safety eval­u­a­tions in the Claude Opus 4.5 sys­tem card.New on the Claude Developer PlatformAs mod­els get smarter, they can solve prob­lems in fewer steps: less back­track­ing, less re­dun­dant ex­plo­ration, less ver­bose rea­son­ing. Claude Opus 4.5 uses dra­mat­i­cally fewer to­kens than its pre­de­ces­sors to reach sim­i­lar or bet­ter out­comes.But dif­fer­ent tasks call for dif­fer­ent trade­offs. Sometimes de­vel­op­ers want a model to keep think­ing about a prob­lem; some­times they want some­thing more nim­ble. With our new ef­fort pa­ra­me­ter on the Claude API, you can de­cide to min­i­mize time and spend or max­i­mize ca­pa­bil­ity.Set to a medium ef­fort level, Opus 4.5 matches Sonnet 4.5’s best score on SWE-bench Verified, but uses 76% fewer out­put to­kens. At its high­est ef­fort level, Opus 4.5 ex­ceeds Sonnet 4.5 per­for­mance by 4.3 per­cent­age points—while us­ing 48% fewer to­kens.With ef­fort con­trol, con­text com­paction, and ad­vanced tool use, Claude Opus 4.5 runs longer, does more, and re­quires less in­ter­ven­tion.Our con­text man­age­ment and mem­ory ca­pa­bil­i­ties can dra­mat­i­cally boost per­for­mance on agen­tic tasks. Opus 4.5 is also very ef­fec­tive at man­ag­ing a team of sub­agents, en­abling the con­struc­tion of com­plex, well-co­or­di­nated multi-agent sys­tems. In our test­ing, the com­bi­na­tion of all these tech­niques boosted Opus 4.5’s per­for­mance on a deep re­search eval­u­a­tion by al­most 15 per­cent­age points4.We’re mak­ing our Developer Platform more com­pos­able over time. We want to give you the build­ing blocks to con­struct ex­actly what you need, with full con­trol over ef­fi­ciency, tool use, and con­text man­age­ment.

Products like Claude Code show what’s pos­si­ble when the kinds of up­grades we’ve made to the Claude Developer Platform come to­gether. Claude Code gains two up­grades with Opus 4.5. Plan Mode now builds more pre­cise plans and ex­e­cutes more thor­oughly—Claude asks clar­i­fy­ing ques­tions up­front, then builds a user-ed­itable plan.md file be­fore ex­e­cut­ing.Claude Code is also now avail­able in our desk­top app, let­ting you run mul­ti­ple lo­cal and re­mote ses­sions in par­al­lel: per­haps one agent fixes bugs, an­other re­searches GitHub, and a third up­dates docs.For Claude app users, long con­ver­sa­tions no longer hit a wall—Claude au­to­mat­i­cally sum­ma­rizes ear­lier con­text as needed, so you can keep the chat go­ing. Claude for Chrome, which lets Claude han­dle tasks across your browser tabs, is now avail­able to all Max users. We an­nounced Claude for Excel in October, and as of to­day we’ve ex­panded beta ac­cess to all Max, Team, and Enterprise users. Each of these up­dates takes ad­van­tage of Claude Opus 4.5’s mar­ket-lead­ing per­for­mance in us­ing com­put­ers, spread­sheets, and han­dling long-run­ning tasks.For Claude and Claude Code users with ac­cess to Opus 4.5, we’ve re­moved Opus-specific caps. For Max and Team Premium users, we’ve in­creased over­all us­age lim­its, mean­ing you’ll have roughly the same num­ber of Opus to­kens as you pre­vi­ously had with Sonnet. We’re up­dat­ing us­age lim­its to make sure you’re able to use Opus 4.5 for daily work. These lim­its are spe­cific to Opus 4.5. As fu­ture mod­els sur­pass it, we ex­pect to up­date lim­its as needed.

Voyager 1 Is About to Reach One Light-day from Earth

Artist’s con­cept of the Voyager 1 space­craft speed­ing through in­ter­stel­lar space. (Image: NASA / JPL‑Caltech)

After nearly 50 years in space, NASA’s Voyager 1 is about to hit a his­toric mile­stone. By November 15, 2026, it will be 16.1 bil­lion miles (25.9 bil­lion km) away, mean­ing a ra­dio sig­nal will take a full 24 hours—a full light-day—to reach it. For con­text, a light-year is the dis­tance light trav­els in a year, about 5.88 tril­lion miles (9.46 tril­lion km), so one light-day is just a tiny frac­tion of that.

Launched in 1977 to ex­plore Jupiter and Saturn, Voyager 1 en­tered in­ter­stel­lar space in 2012, be­com­ing the most dis­tant hu­man-made ob­ject ever. Traveling at around 11 miles per sec­ond (17.7 km/​s), it adds roughly 3.5 as­tro­nom­i­cal units (the dis­tance from Earth to the Sun) each year. Even af­ter decades in the harsh en­vi­ron­ment of space, Voyager 1 keeps send­ing data thanks to its ra­dioiso­tope ther­mo­elec­tric gen­er­a­tors, which will last into the 2030s.

Communicating with Voyager 1 is slow. Commands now take about a day to ar­rive, with an­other day for con­fir­ma­tion. Compare that to the Moon (1.3 sec­onds), Mars (up to 4 min­utes), and Pluto (nearly 7 hours). The probe’s dis­tance makes every in­struc­tion a pa­tient ex­er­cise in deep-space op­er­a­tions. To reach our clos­est star, Proxima Centauri, even at light speed, would take over four years—show­ing just how tiny a light-day is in cos­mic terms.

The ‘Pale Blue Dot’ im­age of Earth, cap­tured by Voyager 1. (Image: NASA / Public Domain)

Voyager 1’s jour­ney is more than a record for dis­tance. From its plan­e­tary fly­bys to the iconic ‘Pale Blue Dot’ im­age, it re­minds us of the vast scale of the so­lar sys­tem and the in­cred­i­ble en­durance of a space­craft de­signed to keep ex­plor­ing, even with­out re­turn.

(function(w,q){w[q]=w[q]||[];w[q].push([“_mgc.load”])})(window,“_mgq”);

Also Read

Loading ti­tle…

(function(card) {

const CACHE_TTL = 3600000; // 1 hour in mil­lisec­onds

const link = card.query­S­e­lec­tor(‘.also-read-link’).href;

const cacheKey = `alsoReadCache:${link}`;

const up­date­Card = (title, im­age) => {

card.query­S­e­lec­tor(‘.also-read-ti­tle’).in­ner­Text = ti­tle;

card.query­S­e­lec­tor(‘.also-read-im­age’).style.back­groundIm­age = `url(${image})`;

let cached­Data;

try {

cached­Data = lo­cal­Stor­age.getItem(cacheKey);

if (cachedData) {

cached­Data = JSON.parse(cachedData);

} catch(e) {

con­sole.er­ror(“Er­ror pars­ing cache data:”, e);

cached­Data = null;

if (cachedData && Date.now() - cached­Data.time­stamp < CACHE_TTL) {

up­date­Card(cached­Data.ti­tle, cached­Data.im­age);

re­turn;

fetch(link)

.then(response => {

if (!response.ok) throw new Error(‘Network re­sponse was not ok’);

re­turn re­sponse.text();

.then(html => {

const doc = new DOMParser().parseFromString(html, “text/html”);

const ogTi­tle = doc.query­S­e­lec­tor(‘meta[prop­erty=“og:ti­tle”]’)?.con­tent || “Read More”;

const ogIm­age = doc.query­S­e­lec­tor(‘meta[prop­erty=“og:im­age”]’)?.con­tent || “https://​via.place­holder.com/​300”;

lo­cal­Stor­age.setItem(cacheKey, JSON.stringify({

ti­tle: ogTi­tle,

im­age: ogIm­age,

time­stamp: Date.now()

up­date­Card(ogTi­tle, ogIm­age);

.catch(error => {

con­sole.er­ror(“Er­ror fetch­ing Open Graph data:”, er­ror);

if (cachedData) {

up­date­Card(cached­Data.ti­tle, cached­Data.im­age);

})(document.currentScript.parentElement);

.also-read-card {

max-width: 600px;

width: 100%;

mar­gin: 20px 0;

bor­der: 1px solid #e0e0e0;

bor­der-left: 8px solid #5170ff;

bor­der-ra­dius: 6px;

over­flow: hid­den;

back­ground: #fff;

box-shadow: 0 1px 5px rgba(0,0,0,0.08);

tran­si­tion: box-shadow 0.3s ease;

dis­play: flex;

align-items: stretch;

.also-read-link {

dis­play: flex;

align-items: stretch;

text-dec­o­ra­tion: none;

color: in­herit;

width: 100%;

.also-read-image {

width: 150px;

height: 100%;

flex-shrink: 0;

back­ground-size: cover;

back­ground-po­si­tion: cen­ter;

/* Note: back­ground-im­age tran­si­tions might not an­i­mate as ex­pected */

.also-read-info {

padding: 15px;

flex-grow: 1;

dis­play: flex;

flex-di­rec­tion: col­umn;

jus­tify-con­tent: cen­ter;

.also-read-label {

dis­play: block;

font-size: 16px;

font-weight: 800;

let­ter-spac­ing: 1px;

color: #5170ff;

mar­gin-bot­tom: 4.15px;

.also-read-title {

font-size: 18px;

font-weight: 500;

color: #333;

mar­gin: 0;

line-height: 1.3;

dis­play: block;

/* Responsive Styles */

@media screen and (max-width: 768px) {

.also-read-card {

max-width: 90%;

mar­gin: 15px 0;

.also-read-image {

width: 120px;

.also-read-info {

In my re­cent analy­sis of YouTube’s in­for­ma­tion den­sity I in­cluded the re­sults from an ad­vanced sta­tis­ti­cal analy­sis on the num­ber of videos pre­sent on the home page, which pro­jected that around May 2026 there would only be one lonely video on the home screen.

Amazingly, a dis­grun­tled Googler leaked a record­ing of how YouTube’s PM

org han­dled the crit­i­cism as it sat at the

top of Hacker News for a whole day for some rea­son.

The net re­sult is that af­ter months of hard work by YouTube en­gi­neers, the other day I fired up YouTube on an Apple TV and was graced with this:

Let’s an­a­lyze this pic­ture and count the num­ber of videos on the home screen:

Unfortunately the YouTube PM org’s my­opia is ac­cel­er­at­ing: with this data I now pro­ject that there will be zero videos on the home­screen around May of 2026 now, up from September.

Apparently Poe’s Law ap­plies to Google PMs, satire is dead, and maybe our manda­tory NeuraLinks are com­ing sooner than I thought.

a few days af­ter dad died, we found the love let­ters, hid­den away among his things. one of them said, i love dota and i love peaches, but i love you more. i will quit smok­ing and lose weight for you. the hap­pi­est days of my life are the ones that start with you across the break­fast table from me.

my par­ents were not a love match. at 27 and 26, they were em­bar­rass­ingly old by the stan­dards of their small chi­nese port town. all four of my grand­par­ents ex­erted enor­mous pres­sure to force them to­gether.

my fa­ther ful­filled the fa­mil­ial oblig­a­tions heaped on his shoul­ders with­out com­plaint. he did­n’t get along with my mother, or my younger brother, but this was­n’t too bad; he of­ten worked away from us (for months and even years on end), mostly in china, more re­cently in redacted, an­other cana­dian city.

the phys­i­cal dis­tance be­tween us for most of my life has made his pass­ing eas­ier for me to come to terms with. i call him dad here but i did­n’t lose a dad, i lost some­one who was ab­stractly a fa­ther to me. he was more of­ten gone than there, had missed all of my grad­u­a­tions and birth­day par­ties. there was one time he took care of me when i was sick. his hands on me were gen­tle, and he told me sto­ries from chi­nese his­tory while i lay fever­ish in bed. i was seven. this is ap­prox­i­mately the only mem­ory i have of him be­ing a dad to me.

still, the two of us were close in our own way. some­times, the two of us would go on long walks to­gether. af­ter fif­teen min­utes of si­lence, or twenty, some­thing would loosen in him and he would start to tell me about the depths of his sad­ness and the dis­ap­point­ment in the way his life played out. i was good at not tak­ing this per­son­ally. i did­n’t think he ever had a chance to be happy or au­then­tic, his en­tire life. he sac­ri­ficed him­self so i could.

i al­ways thought that if he had a chance at hap­pi­ness him­self, he would be the gen­tle, funny, and sen­si­tive aes­thete that i caught glimpses of some­times, in­stead of the bull­headed chi­nese pa­tri­arch oth­ers seemed to de­mand.

ex­cept it turns out he did have this chance af­ter all. his lover and i ended up meet­ing soon af­ter his death. ed­ward lived in redacted, the city that my dad had worked in for the past year and a bit.

ed­ward tells me their story, all in a rush. he and my dad had been see­ing each other for three years, and had agreed to go ex­clu­sive a year and a half ago. they met while he was work­ing in hong kong, and there was an in­stant spark be­tween them, some­thing spe­cial and pre­cious that nei­ther of them had felt be­fore. dad con­vinced him to ap­ply for a uni­ver­sity pro­gram here in canada, to even­tu­ally get per­ma­nent res­i­dency here. so ed­ward, in his 30s, sold his flour­ish­ing busi­ness and his house, and came to start over in a for­eign land for the sake of be­ing with him.

ed­ward reck­ons they were en­gaged, or some­thing like it; they lived to­gether, toured open houses in redacted every week­end with every in­tent to buy some­thing to­gether, and there was an un­der­stand­ing that dad would soon come out, di­vorce my mother, and live in the open with ed­ward for the rest of their lives.

ed­ward gave me some pho­tos he had of my dad, and i could scarcely be­lieve that they were of the grim, sad man i knew. he beams in all of them, glow­ing with joy, his smile more in­can­des­cent than i’ve ever seen in my en­tire life. i steal glances at ed­ward, the per­son who took all those im­pos­si­ble pho­tos. the per­son he was look­ing at.

my mind keeps stut­ter­ing to boskovitch’s in­stal­la­tion, that sin­gle box fan be­hind plex­i­glass. i imag­ine the course of events from ed­ward’s point of view: a year liv­ing with the love of your life, and then they are sud­denly gone in an aw­ful ac­ci­dent and you are too late to see them one last time, to at­tend the fu­neral. your own grief is an iso­lat­ing thing be­cause you are clos­eted and no one else knew who you were to each other. i wish we had got­ten in touch sooner, but ed­ward is grate­ful to be al­lowed any af­for­dance, at all.

their life in redacted seemed sim­i­larly im­pos­si­ble: a life where my dad splurged on the treats he never did at home (hagen dazs ice cream, hon­ey­crisp ap­ples, nice shoes) and left the house on a reg­u­lar ba­sis to ex­plore the city with the one he loves. a life where he felt safe enough to ask for kisses and cud­dles be­cause he knew they would be pro­vided, even to sa jiao play­fully. all i ever knew him to do at home was to sit in a stu­por by the tele­vi­sion set.

and there was a new hurt, but it was sweet, to imag­ine the way life could have been in ten years time, a life i’ve never pre­vi­ously imag­ined; dad hap­pily with ed­ward in a nice new house where i’d visit every so of­ten, shoul­ders loose and smil­ing, and we’d get to talk, ac­tu­ally talk.

ac­cord­ing to ed­ward, my dad had known that he had liked men at least since his uni­ver­sity years. that makes it al­most forty years in the closet, then; just think­ing about it makes me feel a sort of dizzy­ing claus­tro­pho­bia.

i came out to mom years be­fore i came out to dad. when i did, mom told me that com­ing out to dad was not a good idea, be­cause he was such a tra­di­tion­al­ist and she did­n’t know how he would re­act. but i came out to him any­ways, one quiet af­ter­noon when i vis­ited him in china, be­cause i thought our re­la­tion­ship was good and that he can han­dle it, and i wanted him to know this about me.

when i did, he took it well. he told me that though the path i am on is a painful one, he would be there for me, and that the most im­por­tant thing was to find xin fu in life, not to live your life in ac­cor­dance to the ex­pec­ta­tions of any­one else. in my stag­ger­ing re­lief i did not no­tice the con­fu­sion. i just felt so grate­ful to have had that un­der­stand­ing, a pre­cious gift that i did not have any ex­pec­ta­tion of re­ceiv­ing. now, i feel only bereft of the con­ver­sa­tions we never man­aged to have, and grief for the life he never got to live.

dad lives in my liv­ing room these days, in a box made of cherry wood, be­cause mom did­n’t want him in the house af­ter the truth came out. so when ed­ward vis­ited, he got to see him one last time, and say good­bye. he held the box in his arms and wept, spilling more tears and emo­tions than his bi­o­log­i­cal fam­ily man­aged to, and i es­caped to my room for the evening to give them some pri­vacy.

did i men­tion the shrines? we set them up for the dead in our cul­ture. we had ours, a for­mal thing in a cab­i­net, and we had knelt in front of it like we were sup­posed to, given the cor­rect num­ber of kow­tows. ed­ward shared with me pic­tures of his. it sprawled over the en­tirety of his din­ing table. it had packs of play­ing cards from the brand he liked best and his favourite cuts of meat and the wine he fin­ished off the day with. every morn­ing, he would play my dad’s favourite songs to him. i did­n’t know my dad’s favourite cuts of meat. i did­n’t know he drank wine. i did­n’t know he lis­tened to mu­sic.

so of course i let them say good­bye to each other. when i went out of my room the next morn­ing, he was still fully dressed on my couch, bed­ding un­touched, star­ing blankly at the box in his lap. it gleamed red in the morn­ing sun. he rose at my ap­proach, put my dad back on the man­tle with gen­tle hands, and then stood qui­etly at a per­fect pa­rade rest in front of him as i man­aged break­fast for the two of us. his flight back to redacted was that af­ter­noon.

i don’t know how to thank you for all this, he says. the chance to say good­bye. he was re­ally proud of you, he spoke about you to me all the time. he never told me that you were gay. ed­ward tells me that dad had plans to go back to redacted in a few weeks time and that he wanted to tell me every­thing be­fore he left, but he was anx­ious about how i’d take it. i don’t ask ed­ward how many times he’d made the res­o­lu­tion to tell me be­fore.

be­cause you see, my dad was a cow­ard. mom had started ask­ing for di­vorces by the time i was in my teens, and dad was the one who al­ways said no. he would com­plain to her mother, a tra­di­tion­al­ist, to en­sure that she would be­rate her daugh­ter back into line. his fam­ily and his cul­ture had no place for him, so he used her as a shield to make sure that he would be spared the scrutiny. slowly, we found ev­i­dence of other af­fairs, go­ing back decades. of course my mother did not want him in the house.

i sit by my dad some­times, and i make sure he al­ways has a bowl of fresh fruit. fifty seven years, most of them suf­fo­cat­ing and mis­er­able, the last three of them shot through with so much joy his smile ab­solutely glows.

he wasted his en­tire life, my mom said to me, the evening we found the love let­ters. his en­tire life, and mine as well.

(dissolution)

Ever since git init ten years ago, Zig has been hosted on GitHub. Unfortunately, when it sold out to Microsoft, the clock started tick­ing. “Please just give me 5 years be­fore every­thing goes to shit,” I thought to my­self. And here we are, 7 years later, liv­ing on bor­rowed time.

Putting aside GitHub’s re­la­tion­ship with ICE, it’s abun­dantly clear that the en­gi­neer­ing ex­cel­lence that cre­ated GitHub’s suc­cess is no longer dri­ving it. Priorities and the en­gi­neer­ing cul­ture have rot­ted, leav­ing users in­flicted with some kind of bloated, buggy JavaScript frame­work in the name of progress. Stuff that used to be snappy is now slug­gish and of­ten en­tirely bro­ken.

Most im­por­tantly, Actions has in­ex­cus­able bugs while be­ing com­pletely ne­glected. After the CEO of GitHub said to “embrace AI or get out”, it seems the lack­eys at Microsoft took the hint, be­cause GitHub Actions started “vibe-scheduling”; choos­ing jobs to run seem­ingly at ran­dom. Combined with other bugs and in­abil­ity to man­u­ally in­ter­vene, this causes our CI sys­tem to get so backed up that not even mas­ter branch com­mits get checked.

Rather than wast­ing do­na­tion money on more CI hard­ware to work around this crum­bling in­fra­struc­ture, we’ve opted to switch Git host­ing providers in­stead.

As a bonus, we look for­ward to fewer vi­o­la­tions (exhibit A, B, C) of our strict no LLM / no AI pol­icy, which I be­lieve are at least in part due to GitHub ag­gres­sively push­ing the “file an is­sue with Copilot” fea­ture in every­one’s face.

The only con­cern we have in leav­ing GitHub be­hind has to do with GitHub Sponsors. This prod­uct was key to Zig’s early fundrais­ing suc­cess, and it re­mains a large por­tion of our rev­enue to­day. I can’t thank Devon Zuegel enough. She ap­peared like an an­gel from heaven and sin­gle-hand­edly made GitHub into a vi­able source of in­come for thou­sands of de­vel­op­ers. Under her lead­er­ship, the fu­ture of GitHub Sponsors looked bright, but sadly for us, she, too, moved on to big­ger and bet­ter things. Since she left, that prod­uct as well has been ne­glected and is al­ready start­ing to de­cline.

Although GitHub Sponsors is a large frac­tion of Zig Software Foundation’s do­na­tion in­come, we con­sider it a li­a­bil­ity. We humbly ask if you, reader, are cur­rently do­nat­ing through GitHub Sponsors, that you con­sider mov­ing your re­cur­ring do­na­tion to Every.org, which is it­self a non-profit or­ga­ni­za­tion.

As part of this, we are sun­set­ting the GitHub Sponsors perks. These perks are things like get­ting your name onto the home page, and get­ting your name into the re­lease notes, based on how much you do­nate monthly. We are work­ing with the folks at Every.org so that we can of­fer the equiv­a­lent perks through that plat­form.

Effective im­me­di­ately, I have made ziglang/​zig on GitHub read-only, and the canon­i­cal ori­gin/​mas­ter branch of the main Zig pro­ject repos­i­tory is https://​code­berg.org/​ziglang/​zig.git.

Thank you to the Forgejo con­trib­u­tors who helped us with our is­sues switch­ing to the plat­form, as well as the Codeberg folks who worked with us on the mi­gra­tion - in par­tic­u­lar Earl Warren, Otto, Gusted, and Mathieu Fenniak.

In the end, we opted for a sim­ple strat­egy, side­step­ping GitHub’s ag­gres­sive ven­dor lock-in: leave the ex­ist­ing is­sues open and un­mi­grated, but start count­ing is­sues at 30000 on Codeberg so that all is­sue num­bers re­main un­am­bigu­ous. Let us please con­sider the GitHub is­sues that re­main open as metaphor­i­cally “copy-on-write”. Please leave all your ex­ist­ing GitHub is­sues and pull re­quests alone. No need to move your stuff over to Codeberg un­less you need to make ed­its, ad­di­tional com­ments, or re­base. We’re still go­ing to look at the al­ready open pull re­quests and is­sues; don’t worry.

In this mod­ern era of ac­qui­si­tions, weak an­titrust reg­u­la­tions, and plat­form cap­i­tal­ism lead­ing to ex­treme con­cen­tra­tions of wealth, non-prof­its re­main a bas­tion de­fend­ing what re­mains of the com­mons.

I’m done. I’m done ar­riv­ing at ho­tels and dis­cov­er­ing that they have re­moved the bath­room door. Something that should be as stan­dard as hav­ing a bed, has been sac­ri­ficed in the name of “aesthetic”.

I get it, you can save on ma­te­r­ial costs and make the room feel big­ger, but what about my dig­nity??? I can’t save that when you don’t in­clude a bath­room door.

It’s why I’ve built this web­site, where I com­piled ho­tels that are guar­an­teed to have bath­room doors, and ho­tels that need to work on pri­vacy.

I’ve emailed hun­dreds of ho­tels and I asked them two things: do your doors close all the way, and are they made of glass? Everyone that says yes to their doors clos­ing, and no to be­ing made of glass has been sorted by price range and city for you to eas­ily find places to stay that are guar­an­teed to have a bath­room door.

Quickly check to see if the ho­tel you’re think­ing of book­ing has been re­ported as lack­ing in doors by a pre­vi­ous guest.

Finally, this pas­sion pro­ject could not ex­ist with­out peo­ple sub­mit­ting ho­tels with­out bath­room doors for pub­lic sham­ing. If you’ve stayed at a door­less ho­tel send me an email with the ho­tel name to bring­back­doors@gmail.com, or send me a DM on Instagram with the ho­tel name and a photo of the door­less setup to be pub­licly posted.

Let’s name and shame these ho­tels to pro­tect the dig­nity of fu­ture trav­el­ers.

Last week, Valve stunned the com­puter gam­ing world by un­veil­ing three new gam­ing de­vices at once: the Steam Frame, a wire­less VR head­set; the Steam Machine, a gam­ing con­sole in the vein of a PlayStation or Xbox; and the Steam Controller, a hand­held game con­troller. Successors to the highly suc­cess­ful Valve Index and Steam Deck, these de­vices are set to be re­leased in the com­ing year.

Igalia has long worked with Valve on SteamOS, which will power the Machine and Frame, and is ex­cited to be con­tribut­ing to these new de­vices, par­tic­u­larly the Frame. The Frame, un­like the Machine or Deck which have x86 CPUs, runs on an ARM-based CPU.

Under nor­mal cir­cum­stances, this would mean that only games com­piled to run on ARM chips could be played on the Frame. In or­der to get around this bar­rier, a trans­la­tion layer called FEX is used to run ap­pli­ca­tions com­piled for x86 chips (which are used in nearly all gam­ing PCs) on ARM chips by trans­lat­ing the x86 ma­chine code into ARM64 ma­chine code.

“If you love video games, like I do, work­ing on FEX with Valve is a dream come true,” said Paulo Matos, an en­gi­neer with Igalia’s Compilers Team. Even so, the chal­lenges can be daunt­ing, be­cause mak­ing sure the trans­la­tion is work­ing of­ten re­quires man­ual QA rather than au­to­mated test­ing. “You have to start a game, some­times the er­ror shows up in the col­ors or sound, or how the game be­haves when you break down the door in the sec­ond level. Just de­bug­ging this can take a while,” said Matos. “For op­ti­miza­tion work I did early last year, I used a game called Psychonauts to test it. I must have played the first 3 to 4 min­utes of the game many, many times for de­bug­ging. Looking at my his­tory, Steam tells me I played it for 29 hours, but it was al­ways the first few min­utes, noth­ing else.”

Beyond the CPU, the Qualcomm Adreno 750 GPU used in the Steam Frame in­tro­duced its own set of chal­lenges when it came to run­ning desk­top games, and other com­plex work­loads, on these de­vices. Doing so re­quires a rock-solid Vulkan dri­ver that can en­sure cor­rect­ness, elim­i­nat­ing ma­jor ren­der­ing bugs, while main­tain­ing high per­for­mance. This is a very dif­fi­cult com­bi­na­tion to achieve, and yet that’s ex­actly what we’ve done for Valve with Mesa3D Turnip, a FOSS Vulkan dri­ver for Qualcomm Adreno GPUs.

Before we started our work, crit­i­cal op­ti­miza­tions such as LRZ (which you can learn more about from our blog post here) or the au­to­tuner (and its sub­se­quent over­haul) weren’t in place. Even worse, there was­n’t sup­port for the Adreno 700-series GPUs at all, which we even­tu­ally added along with sup­port for tiled ren­der­ing.

“We im­ple­mented many Vulkan ex­ten­sions and re­viewed nu­mer­ous oth­ers,” said Danylo Piliaiev, an en­gi­neer on the Graphics Team. “Over the years, we en­sured that D3D11, D3D12, and OpenGL games ren­dered cor­rectly through DXVK, vkd3d-pro­ton, and Zink, in­ves­ti­gat­ing many ren­der­ing is­sues along the way. We achieved higher cor­rect­ness than the pro­pri­etary dri­ver and, in many cases, Mesa3D Turnip is faster as well.”

We’ve worked with many won­der­ful peo­ple from Valve, Google, and other com­pa­nies to it­er­ate on the Vulkan dri­ver over the years in or­der to in­tro­duce new fea­tures, bug fixes, per­for­mance im­prove­ments, as well as de­bug­ging work­flows. Some of those peo­ple de­cided to join Igalia later on, such as our col­league and Graphics Team de­vel­oper Emma Anholt. “I’ve been work­ing on Mesa for 22 years, and it’s great to have a home now where I can keep do­ing that work, across hard­ware pro­jects, where the or­ga­ni­za­tion pri­or­i­tizes the work ex­pe­ri­ence of its de­vel­op­ers and em­pow­ers them within the or­ga­ni­za­tion.”

Valve’s sup­port in all this can­not be un­der­stated, ei­ther. Their choice to build their de­vices us­ing open soft­ware like Mesa3D Turnip and FEX means they’re com­mit­ted to work­ing on and sup­port­ing im­prove­ments and op­ti­miza­tions that be­come avail­able to any­one who uses the same open-source pro­jects.

“We’ve re­ceived a lot of pos­i­tive feed­back about sig­nif­i­cantly im­proved per­for­mance and fewer ren­der­ing glitches from hob­by­ists who use these pro­jects to run PC games on Android phones as a re­sult of our work,” said Dhruv Mark Collins, an­other Graphics Team en­gi­neer work­ing on Turnip. “And it goes both ways! We’ve caught a cou­ple of nasty bugs be­cause of that wide­spread test­ing, which re­ally em­pha­sizes why the FOSS model is ben­e­fi­cial for every­one in­volved.”

An in­ter­est­ing area of graph­ics dri­ver de­vel­op­ment is all the com­piler work that is in­volved. Vulkan dri­vers such as Mesa3D Turnip need to process shader pro­grams sent by the ap­pli­ca­tion to the GPU, and these pro­grams gov­ern how pix­els in our screens are shaded or col­ored with geom­e­try, tex­tures, and lights while play­ing games. Job Noorman, an en­gi­neer from our Compilers Team, made sig­nif­i­cant con­tri­bu­tions to the com­piler used by Mesa3D Turnip. He also con­tributed to the Mesa3D NIR shader com­piler, a com­mon part that all Mesa dri­vers use, in­clud­ing RADV (most pop­u­larly used on the Steam Deck) or V3DV (used on Raspberry Pi boards).

As is nor­mal for Igalia, while we fo­cused on de­liv­er­ing re­sults for our cus­tomer, we also made our work as widely use­ful as pos­si­ble. For ex­am­ple: “While our tar­get through­out our work has been the Snapdragon 8 Gen 3 that’s in the Frame, much of our work ex­tends back through years of Snapdragon hard­ware, and we re­gres­sion test it to make sure it stays Vulkan con­for­mant,” said Anholt. This means that Igalia’s work for the Frame has con­sis­tently passed Vulkan’s Conformance Test Suite (CTS) of over 2.8 mil­lion tests, some of which Igalia is in­volved in cre­at­ing.

Our very own Vulkan CTS ex­pert Ricardo García says:

Igalia and other Valve con­trac­tors ac­tively par­tic­i­pate in sev­eral ar­eas in­side the Khronos Group, the or­ga­ni­za­tion main­tain­ing and de­vel­op­ing graph­ics API stan­dards like Vulkan. We con­tribute spec­i­fi­ca­tion fixes and feed­back, and we are reg­u­larly in­volved in the de­vel­op­ment of many new Vulkan ex­ten­sions. Some of these end up be­ing crit­i­cal for game de­vel­op­ers, like mesh shad­ing. Others en­sure a smooth and ef­fi­cient trans­la­tion of other APIs like DirectX to Vulkan, or help take ad­van­tage of hard­ware fea­tures to en­sure ap­pli­ca­tions per­form great across mul­ti­ple plat­forms, both mo­bile like the Steam Frame or desk­top like the Steam Machine. Having Vulkan CTS cov­er­age for these new ex­ten­sions is a crit­i­cal step in the re­lease process, help­ing make sure the spec­i­fi­ca­tion is clear and dri­vers im­ple­ment it cor­rectly, and Igalia en­gi­neers have con­tributed mil­lions of source code lines and tests since our col­lab­o­ra­tion with Valve started.

A huge chal­lenge we faced in mov­ing for­ward with de­vel­op­ment is en­sur­ing that we did­n’t in­tro­duce re­gres­sions, small in­no­cent-seem­ing changes can com­pletely break ren­der­ing on games in a way that even CTS might not catch. What au­to­mated test­ing could be done was of­ten quite con­strained, but Igalians found ways to push through the bar­ri­ers. “I made a con­tin­u­ous in­te­gra­tion test to au­to­mat­i­cally run sin­gle-frame cap­tures of a wide range of games span­ning D3D11, D3D9, D3D8, Vulkan, and OpenGL APIs,” said Piliaiev, about the de­vel­op­ment cov­ered in his re­cent XDC 2025 talk, “ensuring that we don’t have ren­der­ing or per­for­mance re­gres­sions.”

Looking ahead, Igalia’s work for Valve will con­tinue to de­liver ben­e­fits to the wider Linux Gaming ecosys­tem. For ex­am­ple, the Steam Frame, as a bat­tery-pow­ered VR head­set, needs to de­liver high per­for­mance within a lim­ited power bud­get. A way to ad­dress this is to cre­ate a more ef­fi­cient task sched­uler, which is some­thing Changwoo Min of Igalia’s Kernel Team has been work­ing on. As he says, “I have been de­vel­op­ing a cus­tomized CPU sched­uler for gam­ing, named LAVD: Latency-criticality Aware Virtual Deadline sched­uler.”

In gen­eral terms, a sched­uler au­to­mat­i­cally iden­ti­fies crit­i­cal tasks and dy­nam­i­cally boosts their dead­lines to im­prove re­spon­sive­ness. Most task sched­ulers don’t take en­ergy con­sump­tion into ac­count, but the Rust-based LAVD is dif­fer­ent. “LAVD makes sched­ul­ing de­ci­sions con­sid­er­ing each chip’s per­for­mance ver­sus en­ergy trade-offs. It mea­sures and pre­dicts the re­quired com­put­ing power on the fly, then se­lects the best set of CPUs to meet that de­mand with min­i­mal en­ergy con­sump­tion,” said Min.

One of our other ker­nel en­gi­neers, Melissa Wen, has been work­ing on AMD ker­nel dis­play dri­vers to main­tain good color man­age­ment and HDR sup­port for SteamOS across AMD hard­ware fam­i­lies, both for the Steam Deck and the Steam Machine. This is es­pe­cially im­por­tant with newer dis­play hard­ware in the Steam Machine, which fea­tures some no­table dif­fer­ences in color ca­pa­bil­i­ties, aim­ing for more pow­er­ful and ef­fi­cient color man­age­ment which ne­ces­si­tated dri­ver work.

…and that’s a wrap! We will con­tinue our ef­forts to­ward im­prov­ing fu­ture ver­sions of SteamOS, and with a part­ner as strongly sup­port­ive as Valve, we ex­pect to do more work to make Linux gam­ing even bet­ter. If any of that sounded in­ter­est­ing and you’d like to work with us to tackle tricky prob­lems of your own, please get in touch!