In May 2025 I met Yo Shavit, who was working on national security policy at OpenAI and was thinking about how to prepare for a future in which models could seriously assist attackers in creating pandemics. We had a call, and when I shared notes with my team their main response was: "maybe start with not making models that can do that?"

Which is, in many ways, fair: by continuing to push the frontier in biological capabilities, OpenAI's actions were making things worse on many of the problems SecureBio is trying to solve. But OpenAI stopping wouldn't have resolved the problem: other firms were pushing quickly too, and the economic incentives strongly favored rapid capability advancement. Making the world more resilient to pandemics needed to be a high priority regardless, especially in light of models' increasing ability to help people with biology.

When I thought about what our initial conversations might turn into, however, my primary concerns were whether that might (a) compromise SecureBio's ability to independently assess and criticize OpenAI's work or (b) make the world less safe via reducing model developers' motivation to improve safeguards. I do think there's something to both of these, which I get into more below, but it seemed well worth it to talk with Yo about how we could work together.

I explained how we were building an early warning system to flag outbreaks, especially engineered ones that could otherwise spread widely before detection. I described how metagenomic sequencing lets you see what nucleic acid sequences (DNA and RNA) are present in a sample, without choosing in advance which sequences to look for, and how we were piloting this on wastewater and nasal swabs. Over the next few months we discussed opportunities to accelerate our work, he introduced us to OpenAI cofounder Wojciech Zaremba, and both Yo and Wojciech left OpenAI PBC (the for-profit) for the OpenAI Foundation (OAIF). We continued talking to them in these new roles, and these discussions, plus a lot of due diligence, led to the $17.2M OAIF grant which we announced today. I'm incredibly excited about this grant, which will allow us to expand our monitoring system, reduce our turnaround time substantially, [1] and generally reduce the risk that something could spread widely before detection.

In raising my three kids I think a lot about how to cultivate independence. I want them to grow into people who can handle unfamiliar situations, including interacting with strangers as needed, and I think this has been going well: people often comment on how competent and self-sufficient they are for their age (though I think they're still not that far along the spectrum compared to what's possible or historically normal).

In supporting this growth, sometimes they're strongly motivated to do something by themselves, and all I need to do is figure out the minimum they need from me. Which might be nothing! Other times, however, I'll give a small push.

In 2015 I made a little webapp that would use the NextBus API to show predictions for the MBTA:

A few years later they moved from NextBus to their own API, and it stopped working. Back in those days programming required effort, and since there were other apps that did almost what I wanted it wasn't worth it for me to update it. But now that we have genies (for better or worse) I had Claude one-shot the fix:

A decade ago I built jefftk.com/nextbus/ which is no more, but the code still exists at ~/code/nextbus . It was a thin wrapper around the MBTA nextbus API, but when they redid their API to no longer use nextbus it wasn't worth it for me anymore. Could you get it working again?

And it does:

Switching back to this as my daily driver, I especially like that it will show me how stale the prediction is, so I have a better sense of how much to trust it.

What set me off on wanting to revive this was being grumpy that the predictions API doesn't do a good job with inbound at Ball Square. Now that I have my own tooling, I'm working on this too: Claude wrote me a logger and in a week or so I can have it compare a few prediction approaches and implement.

A few days ago I took the kids to Canobie Lake amusement park. It's the closest one to Boston, and while it's not a serious roller coaster park I don't actually like roller coasters (and the kids aren't pushing for them yet). We went on a Wednesday, and going midweek was a good use of a vacation day: the lines are so much shorter.

I've done this a few times before, but this was my first time taking Nora (5y). Last year she was still highly dependent on naps, so we would have had a very short day. I did set expectations with the older two that bringing Nora might mean leaving early, but her stamina was impressive: we were there open (10:30am, though we got there ~10min earlier) to close (7pm). Very glad we brought her: she had so much fun, and her joy was infectious.

I had all three in bright colored broad brimmed hats with a strap under the chin. Normally when going out in the summer they can choose between hats or sunscreen, but for this trip I required the hats specifically because they are so much easier to pick out in a crowd.

When you have a lot of browser tabs open it can be very hard to tell them apart, especially if they're from the same site:

Since monitors are wide and websites are tall, we should very clearly put tabs on the side in a vertical stack. I was a heavy user of these in Firefox, and when I switched to Chrome I used their experimental --enable-vertical-tabs flag. When they removed it I wrote a post about how I love side tabs and switched back to Firefox:

White noise machines are widely used for sound masking, increasing privacy in offices and helping people sleep. The classic approach is a fan in a box, though in the past ten years people have mostly switched over to electronic ones. But a fan is really a great approach; you just need to put it to better use: have the fan clean the air.