From rewriting Google?s search stack in the early 2000s to reviving sparse trillion-parameter models and co-designing TPUs with frontier ML research, Jeff Dean has quietly shaped nearly every layer of the modern AI stack. As Chief AI Scientist at Google and a driving force behind Gemini, Jeff has lived through multiple scaling revolutions from CPUs and sharded indices to multimodal models that reason across text, video, and code.

Jeff joins us to unpack what it really means to ?own the Pareto frontier,? why distillation is the engine behind every Flash model breakthrough, how energy (in picojoules) not FLOPs is becoming the true bottleneck, what it was like leading the charge to unify all of Google?s AI teams, and why the next leap won?t come from bigger context windows alone, but from systems that give the illusion of attending to trillions of tokens.

We discuss:

* Jeff?s early neural net thesis in 1990: parallel training before it was cool, why he believed scaling would win decades early, and the ?bigger model, more data, better results? mantra that held for 15 years

* The evolution of Google Search: sharding, moving the entire index into memory in 2001, softening query semantics pre-LLMs, and why retrieval pipelines already resemble modern LLM systems

* Pareto frontier strategy: why you need both frontier ?Pro? models and low-latency ?Flash? models, and how distillation lets smaller models surpass prior generations

* Distillation deep dive: ensembles ? compression ? logits as soft supervision, and why you need the biggest model to make the smallest one good

* Latency as a first-class objective: why 10?50x lower latency changes UX entirely, and how future reasoning workloads will demand 10,000 tokens/sec

* Energy-based thinking: picojoules per bit, why moving data costs 1000x more than a multiply, batching through the lens of energy, and speculative decoding as amortization

* TPU co-design: predicting ML workloads 2?6 years out, speculative hardware features, precision reduction, sparsity, and the constant feedback loop between model architecture and silicon

* Sparse models and ?outrageously large? networks: trillions of parameters with 1?5% activation, and why sparsity was always the right abstraction

* Unified vs. specialized models: abandoning symbolic systems, why general multimodal models tend to dominate vertical silos, and when vertical fine-tuning still makes sense

* Long context and the illusion of scale: beyond needle-in-a-haystack benchmarks toward systems that narrow trillions of tokens to 117 relevant documents

* Personalized AI: attending to your emails, photos, and documents (with permission), and why retrieval + reasoning will unlock deeply personal assistants

* Coding agents: 50 AI interns, crisp specifications as a new core skill, and how ultra-low latency will reshape human?agent collaboration

* Why ideas still matter: transformers, sparsity, RL, hardware, systems ? scaling wasn?t blind; the pieces had to multiply together

Show Notes:

* Gemma 3 Paper

* Gemma 3

* Gemini 2.5 Report

* Jeff Dean?s ?Software Engineering Advice from

Building Large-Scale Distributed Systems? Presentation (with Back of the Envelope Calculations)

* Latency Numbers Every Programmer Should Know by Jeff Dean

* The Jeff Dean Facts

* Jeff Dean Google Bio

* Jeff Dean on ?Important AI Trends? @Stanford AI Club

* Jeff Dean & Noam Shazeer ? 25 years at Google (Dwarkesh)

?

Jeff Dean

* LinkedIn: https://www.linkedin.com/in/jeff-dean-8b212555

* X: https://x.com/jeffdean

Google

* https://google.com

* https://deepmind.google

Full Video Episode

Timestamps

00:00:04 ? Introduction: Alessio & Swyx welcome Jeff Dean, chief AI scientist at Google, to the Latent Space podcast00:00:30 ? Owning the Pareto Frontier & balancing frontier vs low-latency models00:01:31 ? Frontier models vs Flash models + role of distillation00:03:52 ? History of distillation and its original motivation00:05:09 ? Distillation?s role in modern model scaling00:07:02 ? Model hierarchy (Flash, Pro, Ultra) and distillation sources00:07:46 ? Flash model economics & wide deployment00:08:10 ? Latency importance for complex tasks00:09:19 ? Saturation of some tasks and future frontier tasks00:11:26 ? On benchmarks, public vs internal00:12:53 ? Example long-context benchmarks & limitations00:15:01 ? Long-context goals: attending to trillions of tokens00:16:26 ? Realistic use cases beyond pure language00:18:04 ? Multimodal reasoning and non-text modalities00:19:05 ? Importance of vision & motion modalities00:20:11 ? Video understanding example (extracting structured info)00:20:47 ? Search ranking analogy for LLM retrieval00:23:08 ? LLM representations vs keyword search00:24:06 ? Early Google search evolution & in-memory index00:26:47 ? Design principles for scalable systems00:28:55 ? Real-time index updates & recrawl strategies00:30:06 ? Classic ?Latency numbers every programmer should know?00:32:09 ? Cost of memory vs compute and energy emphasis00:34:33 ? TPUs & hardware trade-offs for serving models00:35:57 ? TPU design decisions & co-design with ML00:38:06 ? Adapting model architecture to hardware00:39:50 ? Alternatives: energy-based models, speculative decoding00:42:21 ? Open research directions: complex workflows, RL00:44:56 ? Non-verifiable RL domains & model evaluation00:46:13 ? Transition away from symbolic systems toward unified LLMs00:47:59 ? Unified models vs specialized ones00:50:38 ? Knowledge vs reasoning & retrieval + reasoning00:52:24 ? Vertical model specialization & modules00:55:21 ? Token count considerations for vertical domains00:56:09 ? Low resource languages & contextual learning00:59:22 ? Origins: Dean?s early neural network work01:10:07 ? AI for coding & human?model interaction styles01:15:52 ? Importance of crisp specification for coding agents01:19:23 ? Prediction: personalized models & state retrieval01:22:36 ? Token-per-second targets (10k+) and reasoning throughput01:23:20 ? Episode conclusion and thanks

Transcript

Alessio Fanelli [00:00:04]: Hey everyone, welcome to the Latent Space podcast. This is Alessio, founder of Kernel Labs, and I?m joined by Swyx, editor of Latent Space.

Shawn Wang [00:00:11]: Hello, hello. We?re here in the studio with Jeff Dean, chief AI scientist at Google. Welcome. Thanks for having me. It?s a bit surreal to have you in the studio. I?ve watched so many of your talks, and obviously your career has been super legendary. So, I mean, congrats. I think the first thing must be said, congrats on owning the Pareto Frontier.

Jeff Dean [00:00:30]: Thank you, thank you. Pareto Frontiers are good. It?s good to be out there.

Shawn Wang [00:00:34]: Yeah, I mean, I think it?s a combination of both. You have to own the Pareto Frontier. You have to have like frontier capability, but also efficiency, and then offer that range of models that people like to use. And, you know, some part of this was started because of your hardware work. Some part of that is your model work, and I?m sure there?s lots of secret sauce that you guys have worked on cumulatively. But, like, it?s really impressive to see it all come together in, like, this slittily advanced.

Jeff Dean [00:01:04]: Yeah, yeah. I mean, I think, as you say, it?s not just one thing. It?s like a whole bunch of things up and down the stack. And, you know, all of those really combine to help make UNOS able to make highly capable large models, as well as, you know, software techniques to get those large model capabilities into much smaller, lighter weight models that are, you know, much more cost effective and lower latency, but still, you know, quite capable for their size. Yeah.

Alessio Fanelli [00:01:31]: How much pressure do you have on, like, having the lower bound of the Pareto Frontier, too? I think, like, the new labs are always trying to push the top performance frontier because they need to raise more money and all of that. And you guys have billions of users. And I think initially when you worked on the CPU, you were thinking about, you know, if everybody that used Google, we use the voice model for, like, three minutes a day, they were like, you need to double your CPU number. Like, what?s that discussion today at Google? Like, how do you prioritize frontier versus, like, we have to do this? How do we actually need to deploy it if we build it?

Jeff Dean [00:02:03]: Yeah, I mean, I think we always want to have models that are at the frontier or pushing the frontier because I think that?s where you see what capabilities now exist that didn?t exist at the sort of slightly less capable last year?s version or last six months ago version. At the same time, you know, we know those are going to be really useful for a bunch of use cases, but they?re going to be a bit slower and a bit more expensive than people might like for a bunch of other broader models. So I think what we want to do is always have kind of a highly capable sort of affordable model that enables a whole bunch of, you know, lower latency use cases. People can use them for agentic coding much more readily and then have the high-end, you know, frontier model that is really useful for, you know, deep reasoning, you know, solving really complicated math problems, those kinds of things. And it?s not that. One or the other is useful. They?re both useful. So I think we?d like to do both. And also, you know, through distillation, which is a key technique for making the smaller models more capable, you know, you have to have the frontier model in order to then distill it into your smaller model. So it?s not like an either or choice. You sort of need that in order to actually get a highly capable, more modest size model. Yeah.

Alessio Fanelli [00:03:24]: I mean, you and Jeffrey came up with the solution in 2014.

Jeff Dean [00:03:28]: Don?t forget, L?Oreal Vinyls as well. Yeah, yeah.

Alessio Fanelli [00:03:30]: A long time ago. But like, I?m curious how you think about the cycle of these ideas, even like, you know, sparse models and, you know, how do you reevaluate them? How do you think about in the next generation of model, what is worth revisiting? Like, yeah, they?re just kind of like, you know, you worked on so many ideas that end up being influential, but like in the moment, they might not feel that way necessarily. Yeah.

Jeff Dean [00:03:52]: I mean, I think distillation was originally motivated because we were seeing that we had a very large image data set at the time, you know, 300 million images that we could train on. And we were seeing that if you create specialists for different subsets of those image categories, you know, this one?s going to be really good at sort of mammals, and this one?s going to be really good at sort of indoor room scenes or whatever, and you can cluster those categories and train on an enriched stream of data after you do pre-training on a much broader set of images. You get much better performance. If you then treat that whole set of maybe 50 models you?ve trained as a large ensemble, but that?s not a very practical thing to serve, right? So distillation really came about from the idea of, okay, what if we want to actually serve that and train all these independent sort of expert models and then squish it into something that actually fits in a form factor that you can actually serve? And that?s, you know, not that different from what we?re doing today. You know, often today we?re instead of having an ensemble of 50 models. We?re having a much larger scale model that we then distill into a much smaller scale model.

Shawn Wang [00:05:09]: Yeah. A part of me also wonders if distillation also has a story with the RL revolution. So let me maybe try to articulate what I mean by that, which is you can, RL basically spikes models in a certain part of the distribution. And then you have to sort of, well, you can spike models, but usually sometimes... It might be lossy in other areas and it?s kind of like an uneven technique, but you can probably distill it back and you can, I think that the sort of general dream is to be able to advance capabilities without regressing on anything else. And I think like that, that whole capability merging without loss, I feel like it?s like, you know, some part of that should be a distillation process, but I can?t quite articulate it. I haven?t seen much papers about it.

Jeff Dean [00:06:01]: Yeah, I mean, I tend to think of one of the key advantages of distillation is that you can have a much smaller model and you can have a very large, you know, training data set and you can get utility out of making many passes over that data set because you?re now getting the logits from the much larger model in order to sort of coax the right behavior out of the smaller model that you wouldn?t otherwise get with just the hard labels. And so, you know, I think that?s what we?ve observed. Is you can get, you know, very close to your largest model performance with distillation approaches. And that seems to be, you know, a nice sweet spot for a lot of people because it enables us to kind of, for multiple Gemini generations now, we?ve been able to make the sort of flash version of the next generation as good or even substantially better than the previous generations pro. And I think we?re going to keep trying to do that because that seems like a good trend to follow.

Shawn Wang [00:07:02]: So, Dara asked, so it was the original map was Flash Pro and Ultra. Are you just sitting on Ultra and distilling from that? Is that like the mother load?

Jeff Dean [00:07:12]: I mean, we have a lot of different kinds of models. Some are internal ones that are not necessarily meant to be released or served. Some are, you know, our pro scale model and we can distill from that as well into our Flash scale model. So I think, you know, it?s an important set of capabilities to have and also inference time scaling. It can also be a useful thing to improve the capabilities of the model.

Shawn Wang [00:07:35]: And yeah, yeah, cool. Yeah. And obviously, I think the economy of Flash is what led to the total dominance. I think the latest number is like 50 trillion tokens. I don?t know. I mean, obviously, it?s changing every day.

Jeff Dean [00:07:46]: Yeah, yeah. But, you know, by market share, hopefully up.

Shawn Wang [00:07:50]: No, I mean, there?s no I mean, there?s just the economics wise, like because Flash is so economical, like you can use it for everything. Like it?s in Gmail now. It?s in YouTube. Like it?s yeah. It?s in everything.

Jeff Dean [00:08:02]: We?re using it more in our search products of various AI mode reviews.

Shawn Wang [00:08:05]: Oh, my God. Flash past the AI mode. Oh, my God. Yeah, that?s yeah, I didn?t even think about that.

Jeff Dean [00:08:10]: I mean, I think one of the things that is quite nice about the Flash model is not only is it more affordable, it?s also a lower latency. And I think latency is actually a pretty important characteristic for these models because we?re going to want models to do much more complicated things that are going to involve, you know, generating many more tokens from when you ask the model to do so. So, you know, if you?re going to ask the model to do something until it actually finishes what you ask it to do, because you?re going to ask now, not just write me a for loop, but like write me a whole software package to do X or Y or Z. And so having low latency systems that can do that seems really important. And Flash is one direction, one way of doing that. You know, obviously our hardware platforms enable a bunch of interesting aspects of our, you know, serving stack as well, like TPUs, the interconnect between. Chips on the TPUs is actually quite, quite high performance and quite amenable to, for example, long context kind of attention operations, you know, having sparse models with lots of experts. These kinds of things really, really matter a lot in terms of how do you make them servable at scale.

Alessio Fanelli [00:09:19]: Yeah. Does it feel like there?s some breaking point for like the proto Flash distillation, kind of like one generation delayed? I almost think about almost like the capability as a. In certain tasks, like the pro model today is a saturated, some sort of task. So next generation, that same task will be saturated at the Flash price point. And I think for most of the things that people use models for at some point, the Flash model in two generation will be able to do basically everything. And how do you make it economical to like keep pushing the pro frontier when a lot of the population will be okay with the Flash model? I?m curious how you think about that.

Jeff Dean [00:09:59]: I mean, I think that?s true. If your distribution of what people are asking people, the models to do is stationary, right? But I think what often happens is as the models become more capable, people ask them to do more, right? So, I mean, I think this happens in my own usage. Like I used to try our models a year ago for some sort of coding task, and it was okay at some simpler things, but wouldn?t do work very well for more complicated things. And since then, we?ve improved dramatically on the more complicated coding tasks. And now I?ll ask it to do much more complicated things. And I think that?s true, not just of coding, but of, you know, now, you know, can you analyze all the, you know, renewable energy deployments in the world and give me a report on solar panel deployment or whatever. That?s a very complicated, you know, more complicated task than people would have asked a year ago. And so you are going to want more capable models to push the frontier in the absence of what people ask the models to do. And that also then gives us. Insight into, okay, where does the, where do things break down? How can we improve the model in these, these particular areas, uh, in order to sort of, um, make the next generation even better.

Alessio Fanelli [00:11:11]: Yeah. Are there any benchmarks or like test sets they use internally? Because it?s almost like the same benchmarks get reported every time. And it?s like, all right, it?s like 99 instead of 97. Like, how do you have to keep pushing the team internally to it? Or like, this is what we?re building towards. Yeah.

Jeff Dean [00:11:26]: I mean, I think. Benchmarks, particularly external ones that are publicly available. Have their utility, but they often kind of have a lifespan of utility where they?re introduced and maybe they?re quite hard for current models. You know, I, I like to think of the best kinds of benchmarks are ones where the initial scores are like 10 to 20 or 30%, maybe, but not higher. And then you can sort of work on improving that capability for, uh, whatever it is, the benchmark is trying to assess and get it up to like 80, 90%, whatever. I, I think once it hits kind of 95% or something, you get very diminishing returns from really focusing on that benchmark, cuz it?s sort of, it?s either the case that you?ve now achieved that capability, or there?s also the issue of leakage in public data or very related kind of data being, being in your training data. Um, so we have a bunch of held out internal benchmarks that we really look at where we know that wasn?t represented in the training data at all. There are capabilities that we want the model to have. Um, yeah. Yeah. Um, that it doesn?t have now, and then we can work on, you know, assessing, you know, how do we make the model better at these kinds of things? Is it, we need different kind of data to train on that?s more specialized for this particular kind of task. Do we need, um, you know, a bunch of, uh, you know, architectural improvements or some sort of, uh, model capability improvements, you know, what would help make that better?

Shawn Wang [00:12:53]: Is there, is there such an example that you, uh, a benchmark inspired in architectural improvement? Like, uh, I?m just kind of. Jumping on that because you just.

Jeff Dean [00:13:02]: Uh, I mean, I think some of the long context capability of the, of the Gemini models that came, I guess, first in 1.5 really were about looking at, okay, we want to have, um, you know,

Shawn Wang [00:13:15]: immediately everyone jumped to like completely green charts of like, everyone had, I was like, how did everyone crack this at the same time? Right. Yeah. Yeah.

Jeff Dean [00:13:23]: I mean, I think, um, and once you?re set, I mean, as you say that needed single needle and a half. Hey, stack benchmark is really saturated for at least context links up to 1, 2 and K or something. Don?t actually have, you know, much larger than 1, 2 and 8 K these days or two or something. We?re trying to push the frontier of 1 million or 2 million context, which is good because I think there are a lot of use cases where. Yeah. You know, putting a thousand pages of text or putting, you know, multiple hour long videos and the context and then actually being able to make use of that as useful. Try to, to explore the über graduation are fairly large. But the single needle in a haystack benchmark is sort of saturated. So you really want more complicated, sort of multi-needle or more realistic, take all this content and produce this kind of answer from a long context that sort of better assesses what it is people really want to do with long context. Which is not just, you know, can you tell me the product number for this particular thing?

Shawn Wang [00:14:31]: Yeah, it?s retrieval. It?s retrieval within machine learning. It?s interesting because I think the more meta level I?m trying to operate at here is you have a benchmark. You?re like, okay, I see the architectural thing I need to do in order to go fix that. But should you do it? Because sometimes that?s an inductive bias, basically. It?s what Jason Wei, who used to work at Google, would say. Exactly the kind of thing. Yeah, you?re going to win. Short term. Longer term, I don?t know if that?s going to scale. You might have to undo that.

Jeff Dean [00:15:01]: I mean, I like to sort of not focus on exactly what solution we?re going to derive, but what capability would you want? And I think we?re very convinced that, you know, long context is useful, but it?s way too short today. Right? Like, I think what you would really want is, can I attend to the internet while I answer my question? Right? But that?s not going to happen. I think that?s going to be solved by purely scaling the existing solutions, which are quadratic. So a million tokens kind of pushes what you can do. You?re not going to do that to a trillion tokens, let alone, you know, a billion tokens, let alone a trillion. But I think if you could give the illusion that you can attend to trillions of tokens, that would be amazing. You?d find all kinds of uses for that. You would have attend to the internet. You could attend to the pixels of YouTube and the sort of deeper representations that we can find. You could attend to the form for a single video, but across many videos, you know, on a personal Gemini level, you could attend to all of your personal state with your permission. So like your emails, your photos, your docs, your plane tickets you have. I think that would be really, really useful. And the question is, how do you get algorithmic improvements and system level improvements that get you to something where you actually can attend to trillions of tokens? Right. In a meaningful way. Yeah.

Shawn Wang [00:16:26]: But by the way, I think I did some math and it?s like, if you spoke all day, every day for eight hours a day, you only generate a maximum of like a hundred K tokens, which like very comfortably fits.

Jeff Dean [00:16:38]: Right. But if you then say, okay, I want to be able to understand everything people are putting on videos.

Shawn Wang [00:16:46]: Well, also, I think that the classic example is you start going beyond language into like proteins and whatever else is extremely information dense. Yeah. Yeah.

Jeff Dean [00:16:55]: I mean, I think one of the things about Gemini?s multimodal aspects is we?ve always wanted it to be multimodal from the start. And so, you know, that sometimes to people means text and images and video sort of human-like and audio, audio, human-like modalities. But I think it?s also really useful to have Gemini know about non-human modalities. Yeah. Like LIDAR sensor data from. Yes. Say, Waymo vehicles or. Like robots or, you know, various kinds of health modalities, x-rays and MRIs and imaging and genomics information. And I think there?s probably hundreds of modalities of data where you?d like the model to be able to at least be exposed to the fact that this is an interesting modality and has certain meaning in the world. Where even if you haven?t trained on all the LIDAR data or MRI data, you could have, because maybe that?s not, you know, it doesn?t make sense in terms of trade-offs of. You know, what you include in your main pre-training data mix, at least including a little bit of it is actually quite useful. Yeah. Because it sort of tempts the model that this is a thing.

Shawn Wang [00:18:04]: Yeah. Do you believe, I mean, since we?re on this topic and something I just get to ask you all the questions I always wanted to ask, which is fantastic. Like, are there some king modalities, like modalities that supersede all the other modalities? So a simple example was Vision can, on a pixel level, encode text. And DeepSeq had this DeepSeq CR paper that did that. Vision. And Vision has also been shown to maybe incorporate audio because you can do audio spectrograms and that?s, that?s also like a Vision capable thing. Like, so, so maybe Vision is just the king modality and like. Yeah.

Jeff Dean [00:18:36]: I mean, Vision and Motion are quite important things, right? Motion. Well, like video as opposed to static images, because I mean, there?s a reason evolution has evolved eyes like 23 independent ways, because it?s such a useful capability for sensing the world around you, which is really what we want these models to be. So I think the only thing that we can be able to do is interpret the things we?re seeing or the things we?re paying attention to and then help us in using that information to do things. Yeah.

Shawn Wang [00:19:05]: I think motion, you know, I still want to shout out, I think Gemini, still the only native video understanding model that?s out there. So I use it for YouTube all the time. Nice.

Jeff Dean [00:19:15]: Yeah. Yeah. I mean, it?s actually, I think people kind of are not necessarily aware of what the Gemini models can actually do. Yeah. Like I have an example I?ve used in one of my talks. It had like, it was like a YouTube highlight video of 18 memorable sports moments across the last 20 years or something. So it has like Michael Jordan hitting some jump shot at the end of the finals and, you know, some soccer goals and things like that. And you can literally just give it the video and say, can you please make me a table of what all these different events are? What when the date is when they happened? And a short description. And so you get like now an 18 row table of that information extracted from the video, which is, you know, not something most people think of as like a turn video into sequel like table.

Alessio Fanelli [00:20:11]: Has there been any discussion inside of Google of like, you mentioned tending to the whole internet, right? Google, it?s almost built because a human cannot tend to the whole internet and you need some sort of ranking to find what you need. Yep. That ranking is like much different for an LLM because you can expect a person to look at maybe the first five, six links in a Google search versus for an LLM. Should you expect to have 20 links that are highly relevant? Like how do you internally figure out, you know, how do we build the AI mode that is like maybe like much broader search and span versus like the more human one? Yeah.

Jeff Dean [00:20:47]: I mean, I think even pre-language model based work, you know, our ranking systems would be built to start. I mean, I think even pre-language model based work, you know, our ranking systems would be built to start. With a giant number of web pages in our index, many of them are not relevant. So you identify a subset of them that are relevant with very lightweight kinds of methods. You know, you?re down to like 30,000 documents or something. And then you gradually refine that to apply more and more sophisticated algorithms and more and more sophisticated sort of signals of various kinds in order to get down to ultimately what you show, which is, you know, the final 10 results or, you know, 10 results plus. Other kinds of information. And I think an LLM based system is not going to be that dissimilar, right? You?re going to attend to trillions of tokens, but you?re going to want to identify, you know, what are the 30,000 ish documents that are with the, you know, maybe 30 million interesting tokens. And then how do you go from that into what are the 117 documents I really should be paying attention to in order to carry out the tasks that the user has asked? And I think, you know, you can imagine systems where you have, you know, a lot of highly parallel processing to identify those initial 30,000 candidates, maybe with very lightweight kinds of models. Then you have some system that sort of helps you narrow down from 30,000 to the 117 with maybe a little bit more sophisticated model or set of models. And then maybe the final model is the thing that looks. So the 117 things that might be your most capable model. So I think it has to, it?s going to be some system like that, that is really enables you to give the illusion of attending to trillions of tokens. Sort of the way Google search gives you, you know, not the illusion, but you are searching the internet, but you?re finding, you know, a very small subset of things that are, that are relevant.

Shawn Wang [00:22:47]: Yeah. I often tell a lot of people that are not steeped in like Google search history that, well, you know, like Bert was. Like he was like basically immediately inside of Google search and that improves results a lot, right? Like I don?t, I don?t have any numbers off the top of my head, but like, I?m sure you guys, that?s obviously the most important numbers to Google. Yeah.

Jeff Dean [00:23:08]: I mean, I think going to an LLM based representation of text and words and so on enables you to get out of the explicit hard notion of, of particular words having to be on the page, but really getting at the notion of this topic of this page or this page. Paragraph is highly relevant to this query. Yeah.

Shawn Wang [00:23:28]: I don?t think people understand how much LLMs have taken over all these very high traffic system, very high traffic. Yeah. Like it?s Google, it?s YouTube. YouTube has this like semantics ID thing where it?s just like every token or every item in the vocab is a YouTube video or something that predicts the video using a code book, which is absurd to me for YouTube size.

Jeff Dean [00:23:50]: And then most recently GROK also for, for XAI, which is like, yeah. I mean, I?ll call out even before LLMs were used extensively in search, we put a lot of emphasis on softening the notion of what the user actually entered into the query.

Shawn Wang [00:24:06]: So do you have like a history of like, what?s the progression? Oh yeah.

Jeff Dean [00:24:09]: I mean, I actually gave a talk in, uh, I guess, uh, web search and data mining conference in 2009, uh, where we never actually published any papers about the origins of Google search, uh, sort of, but we went through sort of four or five or six. generations, four or five or six generations of, uh, redesigning of the search and retrieval system, uh, from about 1999 through 2004 or five. And that talk is really about that evolution. And one of the things that really happened in 2001 was we were sort of working to scale the system in multiple dimensions. So one is we wanted to make our index bigger, so we could retrieve from a larger index, which always helps your quality in general. Uh, because if you don?t have the page in your index, you?re going to not do well. Um, and then we also needed to scale our capacity because we were, our traffic was growing quite extensively. Um, and so we had, you know, a sharded system where you have more and more shards as the index grows, you have like 30 shards. And then if you want to double the index size, you make 60 shards so that you can bound the latency by which you respond for any particular user query. Um, and then as traffic grows, you add, you add more and more replicas of each of those. And so we eventually did the math that realized that in a data center where we had say 60 shards and, um, you know, 20 copies of each shard, we now had 1200 machines, uh, with disks. And we did the math and we?re like, Hey, one copy of that index would actually fit in memory across 1200 machines. So in 2001, we introduced, uh, we put our entire index in memory and what that enabled from a quality perspective was amazing. Um, and so we had more and more replicas of each of those. Before you had to be really careful about, you know, how many different terms you looked at for a query, because every one of them would involve a disk seek on every one of the 60 shards. And so you, as you make your index bigger, that becomes even more inefficient. But once you have the whole index in memory, it?s totally fine to have 50 terms you throw into the query from the user?s original three or four word query, because now you can add synonyms like restaurant and restaurants and cafe and, uh, you know, things like that. Uh, bistro and all these things. And you can suddenly start, uh, sort of really, uh, getting at the meaning of the word as opposed to the exact semantic form the user typed in. And that was, you know, 2001, very much pre LLM, but really it was about softening the, the strict definition of what the user typed in order to get at the meaning.

Alessio Fanelli [00:26:47]: What are like principles that you use to like design the systems, especially when you have, I mean, in 2001, the internet is like. Doubling, tripling every year in size is not like, uh, you know, and I think today you kind of see that with LLMs too, where like every year the jumps in size and like capabilities are just so big. Are there just any, you know, principles that you use to like, think about this? Yeah.

Jeff Dean [00:27:08]: I mean, I think, uh, you know, first, whenever you?re designing a system, you want to understand what are the sort of design parameters that are going to be most important in designing that, you know? So, you know, how many queries per second do you need to handle? How big is the internet? How big is the index you need to handle? How much data do you need to keep for every document in the index? How are you going to look at it when you retrieve things? Um, what happens if traffic were to double or triple, you know, will that system work well? And I think a good design principle is you?re going to want to design a system so that the most important characteristics could scale by like factors of five or 10, but probably not beyond that because often what happens is if you design a system for X. And something suddenly becomes a hundred X, that would enable a very different point in the design space that would not make sense at X. But all of a sudden at a hundred X makes total sense. So like going from a disk space index to a in memory index makes a lot of sense once you have enough traffic, because now you have enough replicas of the sort of state on disk that those machines now actually can hold, uh, you know, a full copy of the, uh, index and memory. Yeah. And that all of a sudden enabled. A completely different design that wouldn?t have been practical before. Yeah. Um, so I?m, I?m a big fan of thinking through designs in your head, just kind of playing with the design space a little before you actually do a lot of writing of code. But, you know, as you said, in the early days of Google, we were growing the index, uh, quite extensively. We were growing the update rate of the index. So the update rate actually is the parameter that changed the most. Surprising. So it used to be once a month.

Shawn Wang [00:28:55]: Yeah.

Jeff Dean [00:28:56]: And then we went to a system that could update any particular page in like sub one minute. Okay.

Shawn Wang [00:29:02]: Yeah. Because this is a competitive advantage, right?

Jeff Dean [00:29:04]: Because all of a sudden news related queries, you know, if you?re, if you?ve got last month?s news index, it?s not actually that useful for.

Shawn Wang [00:29:11]: News is a special beast. Was there any, like you could have split it onto a separate system.

Jeff Dean [00:29:15]: Well, we did. We launched a Google news product, but you also want news related queries that people type into the main index to also be sort of updated.

Shawn Wang [00:29:23]: So, yeah, it?s interesting. And then you have to like classify whether the page is, you have to decide which pages should be updated and what frequency. Oh yeah.

Jeff Dean [00:29:30]: There?s a whole like, uh, system behind the scenes that?s trying to decide update rates and importance of the pages. So even if the update rate seems low, you might still want to recrawl important pages quite often because, uh, the likelihood they change might be low, but the value of having updated is high.

Shawn Wang [00:29:50]: Yeah, yeah, yeah, yeah. Uh, well, you know, yeah. This, uh, you know, mention of latency and, and saving things to this reminds me of one of your classics, which I have to bring up, which is latency numbers. Every programmer should know, uh, was there a, was it just a, just a general story behind that? Did you like just write it down?

Jeff Dean [00:30:06]: I mean, this has like sort of eight or 10 different kinds of metrics that are like, how long does a cache mistake? How long does branch mispredict take? How long does a reference domain memory take? How long does it take to send, you know, a packet from the U S to the Netherlands or something? Um,

Shawn Wang [00:30:21]: why Netherlands, by the way, or is it, is that because of Chrome?

Jeff Dean [00:30:25]: Uh, we had a data center in the Netherlands, um, so, I mean, I think this gets to the point of being able to do the back of the envelope calculations. So these are sort of the raw ingredients of those, and you can use them to say, okay, well, if I need to design a system to do image search and thumb nailing or something of the result page, you know, how, what I do that I could pre-compute the image thumbnails. I could like. Try to thumbnail them on the fly from the larger images. What would that do? How much dis bandwidth than I need? How many des seeks would I do? Um, and you can sort of actually do thought experiments in, you know, 30 seconds or a minute with the sort of, uh, basic, uh, basic numbers at your fingertips. Uh, and then as you sort of build software using higher level libraries, you kind of want to develop the same intuitions for how long does it take to, you know, look up something in this particular kind of.

Shawn Wang [00:31:21]: I?ll see you next time.

Shawn Wang [00:31:51]: Which is a simple byte conversion. That?s nothing interesting. I wonder if you have any, if you were to update your...

Jeff Dean [00:31:58]: I mean, I think it?s really good to think about calculations you?re doing in a model, either for training or inference.

Jeff Dean [00:32:09]: Often a good way to view that is how much state will you need to bring in from memory, either like on-chip SRAM or HBM from the accelerator. Attached memory or DRAM or over the network. And then how expensive is that data motion relative to the cost of, say, an actual multiply in the matrix multiply unit? And that cost is actually really, really low, right? Because it?s order, depending on your precision, I think it?s like sub one picodule.

Shawn Wang [00:32:50]: Oh, okay. You measure it by energy. Yeah. Yeah.

Jeff Dean [00:32:52]: Yeah. I mean, it?s all going to be about energy and how do you make the most energy efficient system. And then moving data from the SRAM on the other side of the chip, not even off the off chip, but on the other side of the same chip can be, you know, a thousand picodules. Oh, yeah. And so all of a sudden, this is why your accelerators require batching. Because if you move, like, say, the parameter of a model from SRAM on the, on the chip into the multiplier unit, that?s going to cost you a thousand picodules. So you better make use of that, that thing that you moved many, many times with. So that?s where the batch dimension comes in. Because all of a sudden, you know, if you have a batch of 256 or something, that?s not so bad. But if you have a batch of one, that?s really not good.

Shawn Wang [00:33:40]: Yeah. Yeah. Right.

Jeff Dean [00:33:41]: Because then you paid a thousand picodules in order to do your one picodule multiply.

Shawn Wang [00:33:46]: I have never heard an energy-based analysis of batching.

Jeff Dean [00:33:50]: Yeah. I mean, that?s why people batch. Yeah. Ideally, you?d like to use batch size one because the latency would be great.

Shawn Wang [00:33:56]: The best latency.

Jeff Dean [00:33:56]: But the energy cost and the compute cost inefficiency that you get is quite large. So, yeah.

Shawn Wang [00:34:04]: Is there a similar trick like, like, like you did with, you know, putting everything in memory? Like, you know, I think obviously NVIDIA has caused a lot of waves with betting very hard on SRAM with Grok. I wonder if, like, that?s something that you already saw with, with the TPUs, right? Like that, that you had to. Uh, to serve at your scale, uh, you probably sort of saw that coming. Like what, what, what hardware, uh, innovations or insights were formed because of what you?re seeing there?

Jeff Dean [00:34:33]: Yeah. I mean, I think, you know, TPUs have this nice, uh, sort of regular structure of 2D or 3D meshes with a bunch of chips connected. Yeah. And each one of those has HBM attached. Um, I think for serving some kinds of models, uh, you know, you, you pay a lot higher cost. Uh, and time latency, um, bringing things in from HBM than you do bringing them in from, uh, SRAM on the chip. So if you have a small enough model, you can actually do model parallelism, spread it out over lots of chips and you actually get quite good throughput improvements and latency improvements from doing that. And so you?re now sort of striping your smallish scale model over say 16 or 64 chips. Uh, but as if you do that and it all fits in. In SRAM, uh, that can be a big win. So yeah, that?s not a surprise, but it is a good technique.

Alessio Fanelli [00:35:27]: Yeah. What about the TPU design? Like how much do you decide where the improvements have to go? So like, this is like a good example of like, is there a way to bring the thousand picojoules down to 50? Like, is it worth designing a new chip to do that? The extreme is like when people say, oh, you should burn the model on the ASIC and that?s kind of like the most extreme thing. How much of it? Is it worth doing an hardware when things change so quickly? Like what was the internal discussion? Yeah.

Jeff Dean [00:35:57]: I mean, we, we have a lot of interaction between say the TPU chip design architecture team and the sort of higher level modeling, uh, experts, because you really want to take advantage of being able to co-design what should future TPUs look like based on where we think the sort of ML research puck is going, uh, in some sense, because, uh, you know, as a hardware designer for ML and in particular, you?re trying to design a chip starting today and that design might take two years before it even lands in a data center. And then it has to sort of be a reasonable lifetime of the chip to take you three, four or five years. So you?re trying to predict two to six years out where, what ML computations will people want to run two to six years out in a very fast changing field. And so having people with interest. Interesting ML research ideas of things we think will start to work in that timeframe or will be more important in that timeframe, uh, really enables us to then get, you know, interesting hardware features put into, you know, TPU N plus two, where TPU N is what we have today.

Shawn Wang [00:37:10]: Oh, the cycle time is plus two.

Jeff Dean [00:37:12]: Roughly. Wow. Because, uh, I mean, sometimes you can squeeze some changes into N plus one, but, you know, bigger changes are going to require the chip. Yeah. Design be earlier in its lifetime design process. Um, so whenever we can do that, it?s generally good. And sometimes you can put in speculative features that maybe won?t cost you much chip area, but if it works out, it would make something, you know, 10 times as fast. And if it doesn?t work out, well, you burned a little bit of tiny amount of your chip area on that thing, but it?s not that big a deal. Uh, sometimes it?s a very big change and we want to be pretty sure this is going to work out. So we?ll do like lots of carefulness. Uh, ML experimentation to show us, uh, this is actually the, the way we want to go. Yeah.

Alessio Fanelli [00:37:58]: Is there a reverse of like, we already committed to this chip design so we can not take the model architecture that way because it doesn?t quite fit?

Jeff Dean [00:38:06]: Yeah. I mean, you, you definitely have things where you?re going to adapt what the model architecture looks like so that they?re efficient on the chips that you?re going to have for both training and inference of that, of that, uh, generation of model. So I think it kind of goes both ways. Um, you know, sometimes you can take advantage of, you know, lower precision things that are coming in a future generation. So you can, might train it at that lower precision, even if the current generation doesn?t quite do that. Mm.

Shawn Wang [00:38:40]: Yeah. How low can we go in precision?

Jeff Dean [00:38:43]: Because people are saying like ternary is like, uh, yeah, I mean, I?m a big fan of very low precision because I think that gets, that saves you a tremendous amount of time. Right. Because it?s picojoules per bit that you?re transferring and reducing the number of bits is a really good way to, to reduce that. Um, you know, I think people have gotten a lot of luck, uh, mileage out of having very low bit precision things, but then having scaling factors that apply to a whole bunch of, uh, those, those weights. Scaling. How does it, how does it, okay.

Shawn Wang [00:39:15]: Interesting. You, so low, low precision, but scaled up weights. Yeah. Huh. Yeah. Never considered that. Yeah. Interesting. Uh, w w while we?re on this topic, you know, I think there?s a lot of, um, uh, this, the concept of precision at all is weird when we?re sampling, you know, uh, we just, at the end of this, we?re going to have all these like chips that I?ll do like very good math. And then we?re just going to throw a random number generator at the start. So, I mean, there?s a movement towards, uh, energy based, uh, models and processors. I?m just curious if you?ve, obviously you?ve thought about it, but like, what?s your commentary?

Jeff Dean [00:39:50]: Yeah. I mean, I think. There?s a bunch of interesting trends though. Energy based models is one, you know, diffusion based models, which don?t sort of sequentially decode tokens is another, um, you know, speculative decoding is a way that you can get sort of an equivalent, very small.

Shawn Wang [00:40:06]: Draft.

Jeff Dean [00:40:07]: Batch factor, uh, for like you predict eight tokens out and that enables you to sort of increase the effective batch size of what you?re doing by a factor of eight, even, and then you maybe accept five or six of those tokens. So you get. A five, a five X improvement in the amortization of moving weights, uh, into the multipliers to do the prediction for the, the tokens. So these are all really good techniques and I think it?s really good to look at them from the lens of, uh, energy, real energy, not energy based models, um, and, and also latency and throughput, right? If you look at things from that lens, that sort of guides you to. Two solutions that are gonna be, uh, you know, better from, uh, you know, being able to serve larger models or, you know, equivalent size models more cheaply and with lower latency.

Shawn Wang [00:41:03]: Yeah. Well, I think, I think I, um, it?s appealing intellectually, uh, haven?t seen it like really hit the mainstream, but, um, I do think that, uh, there?s some poetry in the sense that, uh, you know, we don?t have to do, uh, a lot of shenanigans if like we fundamentally. Design it into the hardware. Yeah, yeah.

Jeff Dean [00:41:23]: I mean, I think there?s still a, there?s also sort of the more exotic things like analog based, uh, uh, computing substrates as opposed to digital ones. Uh, I?m, you know, I think those are super interesting cause they can be potentially low power. Uh, but I think you often end up wanting to interface that with digital systems and you end up losing a lot of the power advantages in the digital to analog and analog to digital conversions. You end up doing, uh, at the sort of boundaries. And periphery of that system. Um, I still think there?s a tremendous distance we can go from where we are today in terms of energy efficiency with sort of, uh, much better and specialized hardware for the models we care about.

Shawn Wang [00:42:05]: Yeah.

Alessio Fanelli [00:42:06]: Um, any other interesting research ideas that you?ve seen, or like maybe things that you cannot pursue a Google that you would be interested in seeing researchers take a step at, I guess you have a lot of researchers. Yeah, I guess you have enough, but our, our research.

Jeff Dean [00:42:21]: Our research portfolio is pretty broad. I would say, um, I mean, I think, uh, in terms of research directions, there?s a whole bunch of, uh, you know, open problems and how do you make these models reliable and able to do much longer, kind of, uh, more complex tasks that have lots of subtasks. How do you orchestrate, you know, maybe one model that?s using other models as tools in order to sort of build, uh, things that can accomplish, uh, you know, much more. Yeah. Significant pieces of work, uh, collectively, then you would ask a single model to do. Um, so that?s super interesting. How do you get more verifiable, uh, you know, how do you get RL to work for non-verifiable domains? I think it?s a pretty interesting open problem because I think that would broaden out the capabilities of the models, the improvements that you?re seeing in both math and coding. Uh, if we could apply those to other less verifiable domains, because we?ve come up with RL techniques that actually enable us to do that. Uh, effectively, that would, that would really make the models improve quite a lot. I think.

Alessio Fanelli [00:43:26]: I?m curious, like when we had Noam Brown on the podcast, he said, um, they already proved you can do it with deep research. Um, you kind of have it with AI mode in a way it?s not verifiable. I?m curious if there?s any thread that you think is interesting there. Like what is it? Both are like information retrieval of JSON. So I wonder if it?s like the retrieval is like the verifiable part. That you can score or what are like, yeah, yeah. How, how would you model that, that problem?

Jeff Dean [00:43:55]: Yeah. I mean, I think there are ways of having other models that can evaluate the results of what a first model did, maybe even retrieving. Can you have another model that says, is this things, are these things you retrieved relevant? Or can you rate these 2000 things you retrieved to assess which ones are the 50 most relevant or something? Um, I think those kinds of techniques are actually quite effective. Sometimes I can even be the same model, just prompted differently to be a, you know, a critic as opposed to a, uh, actual retrieval system. Yeah.

Shawn Wang [00:44:28]: Um, I do think like there, there is that, that weird cliff where like, it feels like we?ve done the easy stuff and then now it?s, but it always feels like that every year. It?s like, oh, like we know, we know, and the next part is super hard and nobody?s figured it out. And, uh, exactly with this RLVR thing where like everyone?s talking about, well, okay, how do we. the next stage of the non-verifiable stuff. And everyone?s like, I don?t know, you know, Ellen judge.

Jeff Dean [00:44:56]: I mean, I feel like the nice thing about this field is there?s lots and lots of smart people thinking about creative solutions to some of the problems that we all see. Uh, because I think everyone sort of sees that the models, you know, are great at some things and they fall down around the edges of those things and, and are not as capable as we?d like in those areas. And then coming up with good techniques and trying those. And seeing which ones actually make a difference is sort of what the whole research aspect of this field is, is pushing forward. And I think that?s why it?s super interesting. You know, if you think about two years ago, we were struggling with GSM, eight K problems, right? Like, you know, Fred has two rabbits. He gets three more rabbits. How many rabbits does he have? That?s a pretty far cry from the kinds of mathematics that the models can, and now you?re doing IMO and Erdos problems in pure language. Yeah. Yeah. Pure language. So that is a really, really amazing jump in capabilities in, you know, in a year and a half or something. And I think, um, for other areas, it?d be great if we could make that kind of leap. Uh, and you know, we don?t exactly see how to do it for some, some areas, but we do see it for some other areas and we?re going to work hard on making that better. Yeah.

Shawn Wang [00:46:13]: Yeah.

Alessio Fanelli [00:46:14]: Like YouTube thumbnail generation. That would be very helpful. We need that. That would be AGI. We need that.

Shawn Wang [00:46:20]: That would be. As far as content creators go.

Jeff Dean [00:46:22]: I guess I?m not a YouTube creator, so I don?t care that much about that problem, but I guess, uh, many people do.

Shawn Wang [00:46:27]: It does. Yeah. It doesn?t, it doesn?t matter. People do judge books by their covers as it turns out. Um, uh, just to draw a bit on the IMO goal. Um, I?m still not over the fact that a year ago we had alpha proof and alpha geometry and all those things. And then this year we were like, screw that we?ll just chuck it into Gemini. Yeah. What?s your reflection? Like, I think this, this question about. Like the merger of like symbolic systems and like, and, and LMS, uh, was a very much core belief. And then somewhere along the line, people would just said, Nope, we?ll just all do it in the LLM.

Jeff Dean [00:47:02]: Yeah. I mean, I think it makes a lot of sense to me because, you know, humans manipulate symbols, but we probably don?t have like a symbolic representation in our heads. Right. We have some distributed representation that is neural net, like in some way of lots of different neurons. And activation patterns firing when we see certain things and that enables us to reason and plan and, you know, do chains of thought and, you know, roll them back now that, that approach for solving the problem doesn?t seem like it?s going to work. I?m going to try this one. And, you know, in a lot of ways we?re emulating what we intuitively think, uh, is happening inside real brains in neural net based models. So it never made sense to me to have like completely separate. Uh, discrete, uh, symbolic things, and then a completely different way of, of, uh, you know, thinking about those things.

Shawn Wang [00:47:59]: Interesting. Yeah. Uh, I mean, it?s maybe seems obvious to you, but it wasn?t obvious to me a year ago. Yeah.

Jeff Dean [00:48:06]: I mean, I do think like that IMO with, you know, translating to lean and using lean and then the next year and also a specialized geometry model. And then this year switching to a single unified model. That is roughly the production model with a little bit more inference budget, uh, is actually, you know, quite good because it shows you that the capabilities of that general model have improved dramatically and, and now you don?t need the specialized model. This is actually sort of very similar to the 2013 to 16 era of machine learning, right? Like it used to be, people would train separate models for lots of different, each different problem, right? I have, I want to recognize street signs and something. So I train a street sign. Recognition recognition model, or I want to, you know, decode speech recognition. I have a speech model, right? I think now the era of unified models that do everything is really upon us. And the question is how well do those models generalize to new things they?ve never been asked to do and they?re getting better and better.

Shawn Wang [00:49:10]: And you don?t need domain experts. Like one of my, uh, so I interviewed ETA who was on, who was on that team. Uh, and he was like, yeah, I, I don?t know how they work. I don?t know where the IMO competition was held. I don?t know the rules of it. I just trained the models, the training models. Yeah. Yeah. And it?s kind of interesting that like people with these, this like universal skill set of just like machine learning, you just give them data and give them enough compute and they can kind of tackle any task, which is the bitter lesson, I guess. I don?t know. Yeah.

Jeff Dean [00:49:39]: I mean, I think, uh, general models, uh, will win out over specialized ones in most cases.

Shawn Wang [00:49:45]: Uh, so I want to push there a bit. I think there?s one hole here, which is like, uh. There?s this concept of like, uh, maybe capacity of a model, like abstractly a model can only contain the number of bits that it has. And, uh, and so it, you know, God knows like Gemini pro is like one to 10 trillion parameters. We don?t know, but, uh, the Gemma models, for example, right? Like a lot of people want like the open source local models that are like that, that, that, and, and, uh, they have some knowledge, which is not necessary, right? Like they can?t know everything like, like you have the. The luxury of you have the big model and big model should be able to capable of everything. But like when, when you?re distilling and you?re going down to the small models, you know, you?re actually memorizing things that are not useful. Yeah. And so like, how do we, I guess, do we want to extract that? Can we, can we divorce knowledge from reasoning, you know?

Jeff Dean [00:50:38]: Yeah. I mean, I think you do want the model to be most effective at reasoning if it can retrieve things, right? Because having the model devote precious parameter space. To remembering obscure facts that could be looked up is actually not the best use of that parameter space, right? Like you might prefer something that is more generally useful in more settings than this obscure fact that it has. Um, so I think that?s always attention at the same time. You also don?t want your model to be kind of completely detached from, you know, knowing stuff about the world, right? Like it?s probably useful to know how long the golden gate be. Bridges just as a general sense of like how long are bridges, right? And, uh, it should have that kind of knowledge. It maybe doesn?t need to know how long some teeny little bridge in some other more obscure part of the world is, but, uh, it does help it to have a fair bit of world knowledge and the bigger your model is, the more you can have. Uh, but I do think combining retrieval with sort of reasoning and making the model really good at doing multiple stages of retrieval. Yeah.

Shawn Wang [00:51:49]: And reasoning through the intermediate retrieval results is going to be a, a pretty effective way of making the model seem much more capable, because if you think about, say, a personal Gemini, yeah, right?

Jeff Dean [00:52:01]: Like we?re not going to train Gemini on my email. Probably we?d rather have a single model that, uh, we can then use and use being able to retrieve from my email as a tool and have the model reason about it and retrieve from my photos or whatever, uh, and then make use of that and have multiple. Um, you know, uh, stages of interaction. that makes sense.

Alessio Fanelli [00:52:24]: Do you think the vertical models are like, uh, interesting pursuit? Like when people are like, oh, we?re building the best healthcare LLM, we?re building the best law LLM, are those kind of like short-term stopgaps or?

Jeff Dean [00:52:37]: No, I mean, I think, I think vertical models are interesting. Like you want them to start from a pretty good base model, but then you can sort of, uh, sort of viewing them, view them as enriching the data. Data distribution for that particular vertical domain for healthcare, say, um, we?re probably not going to train or for say robotics. We?re probably not going to train Gemini on all possible robotics data. We, you could train it on because we want it to have a balanced set of capabilities. Um, so we?ll expose it to some robotics data, but if you?re trying to build a really, really good robotics model, you?re going to want to start with that and then train it on more robotics data. And then maybe that would. It?s multilingual translation capability, but improve its robotics capabilities. And we?re always making these kind of, uh, you know, trade-offs in the data mix that we train the base Gemini models on. You know, we?d love to include data from 200 more languages and as much data as we have for those languages, but that?s going to displace some other capabilities of the model. It won?t be as good at, um, you know, Pearl programming, you know, it?ll still be good at Python programming. Cause we?ll include it. Enough. Of that, but there?s other long tail computer languages or coding capabilities that it may suffer on or multi, uh, multimodal reasoning capabilities may suffer. Cause we didn?t get to expose it to as much data there, but it?s really good at multilingual things. So I, I think some combination of specialized models, maybe more modular models. So it?d be nice to have the capability to have those 200 languages, plus this awesome robotics model, plus this awesome healthcare, uh, module that all can be knitted together to work in concert and called upon in different circumstances. Right? Like if I have a health related thing, then it should enable using this health module in conjunction with the main base model to be even better at those kinds of things. Yeah.

Shawn Wang [00:54:36]: Installable knowledge. Yeah.

Jeff Dean [00:54:37]: Right.

Shawn Wang [00:54:38]: Just download as a, as a package.

Jeff Dean [00:54:39]: And some of that installable stuff can come from retrieval, but some of it probably should come from preloaded training on, you know, uh, a hundred billion tokens or a trillion tokens of health data. Yeah.

Shawn Wang [00:54:51]: And for listeners, I think, uh, I will highlight the Gemma three end paper where they, there was a little bit of that, I think. Yeah.

Alessio Fanelli [00:54:56]: Yeah. I guess the question is like, how many billions of tokens do you need to outpace the frontier model improvements? You know, it?s like, if I have to make this model better healthcare and the main. Gemini model is still improving. Do I need 50 billion tokens? Can I do it with a hundred, if I need a trillion healthcare tokens, it?s like, they?re probably not out there that you don?t have, you know, I think that?s really like the.

Jeff Dean [00:55:21]: Well, I mean, I think healthcare is a particularly challenging domain, so there?s a lot of healthcare data that, you know, we don?t have access to appropriately, but there?s a lot of, you know, uh, healthcare organizations that want to train models on their own data. That is not public healthcare data, uh, not public health. But public healthcare data. Um, so I think there are opportunities there to say, partner with a large healthcare organization and train models for their use that are going to be, you know, more bespoke, but probably, uh, might be better than a general model trained on say, public data. Yeah.

Shawn Wang [00:55:58]: Yeah. I, I believe, uh, by the way, also this is like somewhat related to the language conversation. Uh, I think one of your, your favorite examples was you can put a low resource language in the context and it just learns. Yeah.

Jeff Dean [00:56:09]: Oh, yeah, I think the example we used was Calamon, which is truly low resource because it?s only spoken by, I think 120 people in the world and there?s no written text.

Shawn Wang [00:56:20]: So, yeah. So you can just do it that way. Just put it in the context. Yeah. Yeah. But I think your whole data set in the context, right.

Jeff Dean [00:56:27]: If you, if you take a language like, uh, you know, Somali or something, there is a fair bit of Somali text in the world that, uh, or Ethiopian Amharic or something, um, you know, we probably. Yeah. Are not putting all the data from those languages into the Gemini based training. We put some of it, but if you put more of it, you?ll improve the capabilities of those models.

Shawn Wang [00:56:49]: Yeah.

Jeff Dean [00:56:49]: So, or of those languages.

Shawn Wang [00:56:52]: Uh, yeah, cool. Uh, it?s, uh, I have a side interest in linguistics. I, I, I did, uh, uh, a few classes back in college and like, uh, part of me, like if I was a linguist and I could have access to all these models, I would just be asking really fundamental questions about language itself. Yeah. Like, uh, one is th there?s one very obvious one, which is Sapir-Whorf, like how much does like the language that you speak affect your thinking, but then also there?s some languages where there?s just concepts that are not represented in other languages, but some others, many others that are just duplicates, right. Where, uh, there?s also another paper that people love called the platonic representation where, you know, like the, the, an image of a cup is, uh, if you say learn a model on that and you, you, you have a lot of texts with the word cup eventually maps to it, like roughly the same place. And so like that should apply to languages except where it doesn?t. And that?s actually like very interesting differences in what humanity has discovered as concepts that maybe English doesn?t have.

Shawn Wang [00:57:54]: I don?t know. It?s just like my, my rant on languages. Yeah.

Jeff Dean [00:57:58]: I mean, I, I did some work on a early model that fused together a language based model with you have, you know, nice word based representations and then an image model where you have. Trained it on image net like things. Yes. And then you fuse together the top layers of, uh, no, this is devise, uh, uh, the, you do a little bit more training to fuse together those representations. And what you found was that if you give a novel image that is not in any of the categories in the image model, it was trained on the model can often assigns kind of the right cat, the right label to that image. Um, so for example, um, I think, uh, telescope and, uh, binoculars were both in the training, uh, categories for the image model, but, um, microscope was not. Hmm. And so if you?re given an image of a microscope, it actually can come up with something that?s, uh, got the word microscope as the label that it assigns, even though it?s never actually seen an image labeled that.

Shawn Wang [00:59:01]: Oh, that?s nice. That?s kind of cool. Yeah.

Jeff Dean [00:59:04]: Um, so yeah.

Shawn Wang [00:59:07]: Useful. Uh, cool. Uh, I think. There, there?s more general, like broad questions, but like, I guess what, what do you, uh, wish you were asked more in, in, in general, like, you know, like you, you have such a broad scope. We?ve covered the hardware, we?ve covered the, the, the models research. Yeah.

Jeff Dean [00:59:22]: I mean, I think, uh, one thing that?s kind of interesting is, you know, I, I did a undergrad thesis on neural network, uh, training, uh, uh, parallel neural network training, uh, back in 1990 when I got exposed to neural nets and I always felt kind of, they were the right abstraction. Uh, but we just needed way more compute than we had then. Mm-hmm. So like the 32 processors in the department parallel computer, you know, could get you a, a little bit more interesting, uh, model, but not, not enough to solve real problems. And so starting in 2008 or nine, you know, the world started to have enough computing power through Moore?s law and, you know, larger, interesting data sets to train on to actually, you know, start training neural nets that could tackle real problems that people cared about. Yeah. Speech recognition. Vision, and eventually, uh, language. Um, and so, um, when I started working on neural nets at Google in, in late 2011, um, you know, I really just felt like we should scale up the size of neural networks we can train using, you know, large amounts of parallel computation. And so, uh, I actually, uh, revived some ideas from my undergrad thesis where I?d done both model parallel and data parallel, uh, training and I compared them. Uh, I, I called them. I?ve been doing this since I was eight. It was something different. There was like pattern partitioned and, you know, model partitioned or something.

Shawn Wang [01:00:43]: Well, I have to, is it, is it public? And we can go dig it up?

Jeff Dean [01:00:45]: Yeah, it?s on, it?s on the web. Okay, nice. Um, but, uh, you know, I think combining a lot of those techniques and really just trying to push on scaling things up over the last, you know, 15 years has been, you know, really important. And that means, you know, improvements in the hardware. So, you know, pushing on building specialized hardware like TPUs. Uh, it also means, you know, pushing on software, abstraction layers to let people express their ideas to the computer. Thank you for having me.

Jeff Dean [01:01:40]: Thank you for having me.

Shawn Wang [01:07:10]: If that?s something you would agree with at the time, or is there a different post-mortem?

Jeff Dean [01:07:15]: The brain marketplace for compute quotas.

Shawn Wang [01:07:18]: Compute quotas, where basically he was like, okay, David worked at OpenAI as VP Engine and then he worked at Google. He was like, fundamentally, OpenAI was willing to go all in, like, bet the farm on one thing, whereas Google was more democratic. Everyone had a quota. And I was like, okay, if you believe in scaling as an important thing, that?s an important organizational-wide decision to do.

Jeff Dean [01:07:41]: Yeah. Yeah, I mean, I think I would somewhat agree with that. I mean, I think I actually wrote a one-page memo saying we were being stupid by fragmenting our resources. So in particular, at the time, we had efforts within Google Research. And in the brain team in particular, on large language models. We also had efforts on multimodal models in other parts of brain and Google Research. And then Legacy DeepMind had efforts like Chinchilla models and Flamingo models. And so really, we were fragmenting not only our compute across those separate efforts, but also our best people and our best. And so I said, this is just stupid. Why don?t we combine things and have one effort to train an awesome single unified model that is multimodal from the start, that?s good at everything. And that was the origin of the Gemini effort.

Shawn Wang [01:08:52]: And my one-page memo worked, which is good. Did you have the name? Because also for those who don?t know, you named Gemini.

Jeff Dean [01:08:58]: I did. There was another name proposed. And I said, you know what? You know, it?s sort of like these two organizations really are like twins in some sense coming together. So I kind of like that. And then there?s also the NASA interpretation of the early Gemini project being an important thing on your way to the Apollo project. So it seemed like a good name. Twins coming together. Right.

Alessio Fanelli [01:09:27]: Yeah. Nice. I know we?re already running out of time, but I?m curious how you use AI. Today to code. So, I mean, you?re probably one of the most prolific engineers in the history of computer science. Um, I was reading on through the article about you and Sanjay?s friendship and how you work together. And you have one quote about, you need to find someone that you?re going to pair program with who?s compatible with your way of thinking so that the two of you together are a complimentary force. And I was thinking about how you think about coding agents and this, like, how do you shape a coding agents to be compatible with your way of thinking? Like. How would you rate the tools today? Like, where should things go? Yeah.

Jeff Dean [01:10:07]: I mean, first, I think the coding tools are, you know, getting vastly better compared to where they were a year or two, two years ago. So now you can actually rely on them to do more complex things that you as a, as a software engineer want to accomplish. And you can sort of delegate, you know, pretty complex things to these tools. And I think one really nice aspect about the, uh, interaction between, uh, uh, human, uh, software engineer and, uh, uh, coding model that they?re working with is your way of talking to that, uh, coding model actually sort of, uh, dictates how it interacts with you, right? Like you could ask it, please write a bunch of good tests for this. You could ask it, please help me brainstorm. Performance ideas and your way of doing that is going to shape how the model responds, what kinds of problems it tackles, you know, how much do you want the model to go off and do things that are larger and more independent versus interact with it, uh, more to make sure that you?re shaping the right kinds of, of things. And I think it?s not the case that any one style is the right thing for everything, right? Like some kinds of problems you actually want, uh, maybe a more frequent interaction style with a model. And other ones, you?re just like, yeah, please just go write this because I, I know I need this thing. I can specify it well enough, um, and go off and do it and come back when you?re done. And so I do think there?s going to be more of a style of having lots of independent, uh, software agents off doing things on your behalf and figuring out the right sort of human computer interaction model and UI and so on for when should it interrupt you and say, Hey, I need a little more guidance here, or I?ve done this thing. Now what, now what should I do? Um, I think we, we?re not at the end all answer to that question. And as the models get better, that, uh, set of decisions you put into how the interaction should happen may, may change, right? Like if you, if you have a team of 50 interns, how would you manage that if they were people? And I think it?s not, do you want 50 interns? You might, if they?re really good, right?

Shawn Wang [01:12:23]: It?s a lot of management. But it?s a lot of, uh.

Jeff Dean [01:12:25]: Uh, yeah. I mean, I think that is probably within the realm of possibilities that lots of people could have 50 interns. Yeah. And so how would you actually deal with that as a person, right? Like you would probably want them to form small sub teams, so you don?t have to interact with 50 of them. You can interact with five, five of those teams and they?re off doing things on your behalf, but I don?t know exactly what the, how this is going to unfold.

Alessio Fanelli [01:12:52]: Hmm. Yeah. How do you think about bringing people? Like the pair programming is always helpful to like get net new ideas in the distribution, so to speak. It feels as we have more of these coding agents, write the code, it?s hard to bring other people into the problem. So you go to like, you know, you have 50 interns, right? And then you want to go to Noam Shazier be like, Hey, no, I?m, I want to like pair on this thing. But now there?s like this huge amount of work that has been done in parallel that you need to catch him up on. Right. And I?m curious, like if people are going to be in a way more isolated in their teams, where it?s. It?s like, okay, there?s so much context in these 50 interns that it?s just hard for me to like relay everything back to you.

Jeff Dean [01:13:33]: Maybe. I mean, on the other hand, like imagine a classical software organization without any AI assisted tools, right. You would have, you know, 50 people doing stuff and their interaction style is going to be naturally very hierarchical because, um, you know, these 50 people are going to be working on this part of the system and not. Not interact that much with these other people over here. But if you have, you know, five people each managing 50 virtual agents, you know, they might be able to actually have much higher bandwidth communication among the five people, uh, then you would have among five people who are also trying to coordinate, you know, a 50 person software team. Each.

Alessio Fanelli [01:14:15]: So how, how do you, I?m curious how you change your just working rhythm, you know, like you spend more time ahead with people going through SPACs and design. Goals. Like,

Jeff Dean [01:14:26]: um, I mean, I do think it?s interesting that, you know, whenever people were taught how to write software, they were taught that it?s really important to write specifications super clearly, but no one really believed that. Like it was like, yeah, whatever. I don?t need to do that. I?m going to really, I don?t know. I mean, writing the English language specification was never kind of an artifact that was really paid a lot of attention to. I mean, it was important, but it wasn?t sort of the thing. That drove the actual creative process quite as much as if you specify what software you want the agent to write for you, you?d better be pretty darn careful of and how you specify that because that?s going to dictate the quality of the output, right? Like if you, if you don?t cover that it needs to handle this kind of thing, or that this is a super important corner case, or that, you know, you really care about the performance of this part of it, you know, it may, uh, not do what you want. Yeah. And the better you get at interacting with these models. And I think one of the ways people will get better is they will get really good at crisply specifying things rather than leaving things to ambiguity. And that is actually probably not a bad thing. It?s not a bad skill to have, regardless of whether you?re a software engineer or a, you know, trying to do some other kind of, uh, task, you know, being able to crisply specify what it is you want. It?s going to be really important. Yeah.

Shawn Wang [01:15:52]: My, my joke is, um, you know, good. Yeah. I think one thing is in, uh, indistinguishable from sufficiently advanced executive communication, like it?s like writing an internal memo, like weigh your words very carefully and also I think very important to be multimodal, right? I think, uh, one thing that, uh, anti-gravity from, from Google also did was like, just come out the gate to very, very strong multimodal, including videos, and that?s the highest bandwidth communication prompt that you can give to the model, which is fantastic. Yeah.

Alessio Fanelli [01:16:20]: How do you collect things that you often you will have in your mind? So you have this amazing, like performance sense thing that you?ve heard about how to look for performance improvements. And is there a lot more value in like people writing these like generic things down so that they can then put them back as like potential retrieval artifacts for the model? Like, or do I have like the edge cases is like a good example, right? It?s like, if you?re building systems, you already have in your mind, specific edge cases, depending on it. But now you have to like, every time repeat it. Like, are you having people spend a lot more time writing? Are you finding out more generic things to bring back?

Jeff Dean [01:16:56]: Or, um, I mean, I do think well-written guides of, of how to do good software engineering are going to be useful because they can be used as input to models or, you know, read by other developers so that their prompts are, you know, more clear about what the, the underlying software system should, should be doing. Um, you know, I think it may not be that you need to create a custom one. For every situation, if you have general guides and put those into, you know, the context of a coding agent, that, that can be helpful. Like in, you can imagine one for distributed systems, you could say, okay, think about failures of these kinds of things. And these are some techniques you can deal with failures. You know, you can have, uh, you know, Paxos like replication, or, you know, you can, uh, send the request to two places and tolerate failure because you only need one of them to come back. You know, a little. Description of 20 techniques like that in building distributed systems, probably would go a long way to having a coding agent be able to sort of cobble up more reliable and robust distributed systems.

Shawn Wang [01:18:07]: Yeah. Yeah. I wonder when Gemini will be able to build Spanner, right?

Alessio Fanelli [01:18:12]: Probably already has the code inside, you know?

Alessio Fanelli [01:18:16]: Yeah. That, I mean, that?s a good example, right? When you have like, you know, the cap theorem and it?s like, well, this is like truth and you cannot break that. And then you build something that broke it.

Shawn Wang [01:18:26]: Like, I?m curious, like models in a way are like, would he say he broke it? Did you, would you say you broke cap theorem? Really? Yeah. Okay. All right. I mean, under local assumptions. Yeah. Under some, some, yeah. And they?re like, you know, good clocks. Yeah. Yeah.

Alessio Fanelli [01:18:41]: It?s like some, sometimes you don?t have to like always follow what is known to be true. Right. And I, I think models in a way, like if you tell them something, they?re like really buy into that, you know? Um, yeah. So yeah, just more. Thinking than any answer on how to fix it.

Jeff Dean [01:18:57]: Yeah, my, my, uh, you know, it?s just on this, like, like big prompting and, and, uh, iteration, you know, I think that coming back to your latency point, um, I always, I always try to one, one AB test or experiment or benchmark or research I would like is what is the performance difference between, let?s say three dumb fast model calls with human alignment because the human will correct human alignment, being human looks at the first one and produces a new prompt.

Shawn Wang [01:19:23]: For the second one. Correct. Okay. As opposed to like, you spec it out, you know, it?s been a long time writing as a pro a big, big fat prompt, and then you have a very smart model. Do it right. Right. You know, cause, uh, really is, is, uh, our lacks in performance, uh, an issue of like, well, you just haven?t specified well enough. There?s no universe in which I can produce what you want because you just haven?t told me. Right.

Jeff Dean [01:19:44]: It?s underspecified. So I could produce 10 different things and only one of them is the thing you wanted. Yeah.

Shawn Wang [01:19:49]: And the multi-turn taking with a flash model is enough. Yeah.

Jeff Dean [01:19:54]: Yeah, I?m, I?m a big believer in pushing on latency because I think being able to have really low latency interactions with a system you?re using is just much more delightful than something that is, you know, 10 times as slow or 20 times as slow. And I think, you know, in the future we?ll see models that are, and, and underlying software and hardware systems that are 20X lower latency than what we have today, 50X lower latency. And that?s going to be really, really important for systems. That need to do a lot of stuff, uh, between your interactions.

Shawn Wang [01:20:27]: Yeah. Yeah. There, there?s two extremes, right? And then meanwhile, you also have DeepThink, which is all the way on the other side. Right.

Jeff Dean [01:20:33]: But you would use DeepThink all the time if it weren?t for cost and latency, right? If, if you could have that capability in a model because the latency improvement was 20X, uh, in the underlying hardware and system and costs, you know, there?s no reason you wouldn?t want that.

Shawn Wang [01:20:50]: Yeah.

Jeff Dean [01:20:52]: But at the same time, then you?d probably have a model. That is even better. That would take you 20X longer, even on that new hardware. Yeah.

Shawn Wang [01:21:00]: Uh, you know, there, there?s, uh, the Pareto curve keeps climbing. Um, yeah, onward and outward, onward and outward. Yeah. Should we ask him for predictions to, to go? I don?t know if you have any predictions that you, that you like to keep, you know, like, uh, one, one way to do this is you have your tests whenever a new model comes out that you run, uh, what?s something that you?re, you?re not quite happy with yet. That you think we?ll get done soon.

Jeff Dean [01:21:29]: Um, let me make two predictions that are not quite in that vein. Yeah. So I think a personalized model that knows you and knows all your state and is able to retrieve over all state you have access to, that you opt into is going to be incredibly useful compared to a more generic model that doesn?t have access to that. So like, can something attend to everything I?ve ever seen? Yeah. Every email, every photo, every. Yeah. Video I?ve watched, that?s going to be really useful. Uh, I think, uh, more and more specialized hardware is going to enable much lower latency models and much more capable models for affordable prices, uh, than say the current, current status quo. Uh, that?s going to be also quite important. Yeah.

Shawn Wang [01:22:16]: When you say much lower latency, uh, people usually talk in tokens per second. Is that a term that is okay? Okay. Uh, you know, we?re at, let?s say a hundred. Now we can go to a thousand. Is it meaningful to go 10,000? Yes. Really? Okay. Absolutely. Right. Yeah. Because of chain of thought and chain of thought reasoning.

Jeff Dean [01:22:36]: I mean, you could think, you know, uh, many more tokens, you could do many more parallel rollouts. You could generate way more code, uh, and check that the code is cracked with a chain of thought reasoning. So I think, you know, being able to do that at 10,000 tokens per second would be awesome. Yeah.

Shawn Wang [01:22:52]: At 10,000 tokens per second, you are no longer reading code. Yeah. Like you will just generate it. You?ll, I?m not reading it.

Jeff Dean [01:22:58]: Well, remember, it may not, it may not end up with 10,000 tokens of code. Yeah. It may be a thousand tokens of code that with 9,000 tokens of reasoning behind it, which would actually be probably much better code to read. Yeah.

Alessio Fanelli [01:23:11]: Yeah. If I had more time, I would have written a shorter letter. Yeah. Yeah. Yeah. Um, awesome. Jeff, this was amazing. Thanks for taking the time. Thank you.

Jeff Dean [01:23:20]: It?s been fun. Thanks for having me.

This podcast features Gabriele Corso and Jeremy Wohlwend, co-founders of Boltz and authors of the Boltz Manifesto, discussing the rapid evolution of structural biology models from AlphaFold to their own open-source suite, Boltz-1 and Boltz-2. The central thesis is that while single-chain protein structure prediction is largely ?solved? through evolutionary hints, the next frontier lies in modeling complex interactions (protein-ligand, protein-protein) and generative protein design, which Boltz aims to democratize via open-source foundations and scalable infrastructure.

Full Video Pod

On YouTube!

Timestamps

* 00:00 Introduction to Benchmarking and the ?Solved? Protein Problem

* 06:48 Evolutionary Hints and Co-evolution in Structure Prediction

* 10:00 The Importance of Protein Function and Disease States

* 15:31 Transitioning from AlphaFold 2 to AlphaFold 3 Capabilities

* 19:48 Generative Modeling vs. Regression in Structural Biology

* 25:00 The ?Bitter Lesson? and Specialized AI Architectures

* 29:14 Development Anecdotes: Training Boltz-1 on a Budget

* 32:00 Validation Strategies and the Protein Data Bank (PDB)

* 37:26 The Mission of Boltz: Democratizing Access and Open Source

* 41:43 Building a Self-Sustaining Research Community

* 44:40 Boltz-2 Advancements: Affinity Prediction and Design

* 51:03 BoltzGen: Merging Structure and Sequence Prediction

* 55:18 Large-Scale Wet Lab Validation Results

* 01:02:44 Boltz Lab Product Launch: Agents and Infrastructure

* 01:13:06 Future Directions: Developpability and the ?Virtual Cell?

* 01:17:35 Interacting with Skeptical Medicinal Chemists

Key Summary

Evolution of Structure Prediction & Evolutionary Hints

* Co-evolutionary Landscapes: The speakers explain that breakthrough progress in single-chain protein prediction relied on decoding evolutionary correlations where mutations in one position necessitate mutations in another to conserve 3D structure.

* Structure vs. Folding: They differentiate between structure prediction (getting the final answer) and folding (the kinetic process of reaching that state), noting that the field is still quite poor at modeling the latter.

* Physics vs. Statistics: RJ posits that while models use evolutionary statistics to find the right ?valley? in the energy landscape, they likely possess a ?light understanding? of physics to refine the local minimum.

The Shift to Generative Architectures

* Generative Modeling: A key leap in AlphaFold 3 and Boltz-1 was moving from regression (predicting one static coordinate) to a generative diffusion approach that samples from a posterior distribution.

* Handling Uncertainty: This shift allows models to represent multiple conformational states and avoid the ?averaging? effect seen in regression models when the ground truth is ambiguous.

* Specialized Architectures: Despite the ?bitter lesson? of general-purpose transformers, the speakers argue that equivariant architectures remain vastly superior for biological data due to the inherent 3D geometric constraints of molecules.

Boltz-2 and Generative Protein Design

* Unified Encoding: Boltz-2 (and BoltzGen) treats structure and sequence prediction as a single task by encoding amino acid identities into the atomic composition of the predicted structure.

* Design Specifics: Instead of a sequence, users feed the model blank tokens and a high-level ?spec? (e.g., an antibody framework), and the model decodes both the 3D structure and the corresponding amino acids.

* Affinity Prediction: While model confidence is a common metric, Boltz-2 focuses on affinity prediction?quantifying exactly how tightly a designed binder will stick to its target.

Real-World Validation and Productization

* Generalized Validation: To prove the model isn?t just ?regurgitating? known data, Boltz tested its designs on 9 targets with zero known interactions in the PDB, achieving nanomolar binders for two-thirds of them.

* Boltz Lab Infrastructure: The newly launched Boltz Lab platform provides ?agents? for protein and small molecule design, optimized to run 10x faster than open-source versions through proprietary GPU kernels.

* Human-in-the-Loop: The platform is designed to convert skeptical medicinal chemists by allowing them to run parallel screens and use their intuition to filter model outputs.

Transcript

RJ [00:05:35]: But the goal remains to, like, you know, really challenge the models, like, how well do these models generalize? And, you know, we?ve seen in some of the latest CASP competitions, like, while we?ve become really, really good at proteins, especially monomeric proteins, you know, other modalities still remain pretty difficult. So it?s really essential, you know, in the field that there are, like, these efforts to gather, you know, benchmarks that are challenging. So it keeps us in line, you know, about what the models can do or not.

Gabriel [00:06:26]: Yeah, it?s interesting you say that, like, in some sense, CASP, you know, at CASP 14, a problem was solved and, like, pretty comprehensively, right? But at the same time, it was really only the beginning. So you can say, like, what was the specific problem you would argue was solved? And then, like, you know, what is remaining, which is probably quite open.

RJ [00:06:48]: I think we?ll steer away from the term solved, because we have many friends in the community who get pretty upset at that word. And I think, you know, fairly so. But the problem that was, you know, that a lot of progress was made on was the ability to predict the structure of single chain proteins. So proteins can, like, be composed of many chains. And single chain proteins are, you know, just a single sequence of amino acids. And one of the reasons that we?ve been able to make such progress is also because we take a lot of hints from evolution. So the way the models work is that, you know, they sort of decode a lot of hints. That comes from evolutionary landscapes. So if you have, like, you know, some protein in an animal, and you go find the similar protein across, like, you know, different organisms, you might find different mutations in them. And as it turns out, if you take a lot of the sequences together, and you analyze them, you see that some positions in the sequence tend to evolve at the same time as other positions in the sequence, sort of this, like, correlation between different positions. And it turns out that that is typically a hint that these two positions are close in three dimension. So part of the, you know, part of the breakthrough has been, like, our ability to also decode that very, very effectively. But what it implies also is that in absence of that co-evolutionary landscape, the models don?t quite perform as well. And so, you know, I think when that information is available, maybe one could say, you know, the problem is, like, somewhat solved. From the perspective of structure prediction, when it isn?t, it?s much more challenging. And I think it?s also worth also differentiating the, sometimes we confound a little bit, structure prediction and folding. Folding is the more complex process of actually understanding, like, how it goes from, like, this disordered state into, like, a structured, like, state. And that I don?t think we?ve made that much progress on. But the idea of, like, yeah, going straight to the answer, we?ve become pretty good at.

Brandon [00:08:49]: So there?s this protein that is, like, just a long chain and it folds up. Yeah. And so we?re good at getting from that long chain in whatever form it was originally to the thing. But we don?t know how it necessarily gets to that state. And there might be intermediate states that it?s in sometimes that we?re not aware of.

RJ [00:09:10]: That?s right. And that relates also to, like, you know, our general ability to model, like, the different, you know, proteins are not static. They move, they take different shapes based on their energy states. And I think we are, also not that good at understanding the different states that the protein can be in and at what frequency, what probability. So I think the two problems are quite related in some ways. Still a lot to solve. But I think it was very surprising at the time, you know, that even with these evolutionary hints that we were able to, you know, to make such dramatic progress.

Brandon [00:09:45]: So I want to ask, why does the intermediate states matter? But first, I kind of want to understand, why do we care? What proteins are shaped like?

Gabriel [00:09:54]: Yeah, I mean, the proteins are kind of the machines of our body. You know, the way that all the processes that we have in our cells, you know, work is typically through proteins, sometimes other molecules, sort of intermediate interactions. And through that interactions, we have all sorts of cell functions. And so when we try to understand, you know, a lot of biology, how our body works, how disease work. So we often try to boil it down to, okay, what is going right in case of, you know, our normal biological function and what is going wrong in case of the disease state. And we boil it down to kind of, you know, proteins and kind of other molecules and their interaction. And so when we try predicting the structure of proteins, it?s critical to, you know, have an understanding of kind of those interactions. It?s a bit like seeing the difference between... Having kind of a list of parts that you would put it in a car and seeing kind of the car in its final form, you know, seeing the car really helps you understand what it does. On the other hand, kind of going to your question of, you know, why do we care about, you know, how the protein falls or, you know, how the car is made to some extent is that, you know, sometimes when something goes wrong, you know, there are, you know, cases of, you know, proteins misfolding. In some diseases and so on, if we don?t understand this folding process, we don?t really know how to intervene.

RJ [00:11:30]: There?s this nice line in the, I think it?s in the Alpha Fold 2 manuscript, where they sort of discuss also like why we even hopeful that we can target the problem in the first place. And then there?s this notion that like, well, four proteins that fold. The folding process is almost instantaneous, which is a strong, like, you know, signal that like, yeah, like we should, we might be... able to predict that this very like constrained thing that, that the protein does so quickly. And of course that?s not the case for, you know, for, for all proteins. And there?s a lot of like really interesting mechanisms in the cells, but yeah, I remember reading that and thought, yeah, that?s somewhat of an insightful point.

Gabriel [00:12:10]: I think one of the interesting things about the protein folding problem is that it used to be actually studied. And part of the reason why people thought it was impossible, it used to be studied as kind of like a classical example. Of like an MP problem. Uh, like there are so many different, you know, type of, you know, shapes that, you know, this amino acid could take. And so, this grows combinatorially with the size of the sequence. And so there used to be kind of a lot of actually kind of more theoretical computer science thinking about and studying protein folding as an MP problem. And so it was very surprising also from that perspective, kind of seeing. Machine learning so clear, there is some, you know, signal in those sequences, through evolution, but also through kind of other things that, you know, us as humans, we?re probably not really able to, uh, to understand, but that is, models I?ve, I?ve learned.

Brandon [00:13:07]: And so Andrew White, we were talking to him a few weeks ago and he said that he was following the development of this and that there were actually ASICs that were developed just to solve this problem. So, again, that there were. There were many, many, many millions of computational hours spent trying to solve this problem before AlphaFold. And just to be clear, one thing that you mentioned was that there?s this kind of co-evolution of mutations and that you see this again and again in different species. So explain why does that give us a good hint that they?re close by to each other? Yeah.

RJ [00:13:41]: Um, like think of it this way that, you know, if I have, you know, some amino acid that mutates, it?s going to impact everything around it. Right. In three dimensions. And so it?s almost like the protein through several, probably random mutations and evolution, like, you know, ends up sort of figuring out that this other amino acid needs to change as well for the structure to be conserved. Uh, so this whole principle is that the structure is probably largely conserved, you know, because there?s this function associated with it. And so it?s really sort of like different positions compensating for, for each other. I see.

Brandon [00:14:17]: Those hints in aggregate give us a lot. Yeah. So you can start to look at what kinds of information about what is close to each other, and then you can start to look at what kinds of folds are possible given the structure and then what is the end state.

RJ [00:14:30]: And therefore you can make a lot of inferences about what the actual total shape is. Yeah, that?s right. It?s almost like, you know, you have this big, like three dimensional Valley, you know, where you?re sort of trying to find like these like low energy states and there?s so much to search through. That?s almost overwhelming. But these hints, they sort of maybe put you in. An area of the space that?s already like, kind of close to the solution, maybe not quite there yet. And, and there?s always this question of like, how much physics are these models learning, you know, versus like, just pure like statistics. And like, I think one of the thing, at least I believe is that once you?re in that sort of approximate area of the solution space, then the models have like some understanding, you know, of how to get you to like, you know, the lower energy, uh, low energy state. And so maybe you have some, some light understanding. Of physics, but maybe not quite enough, you know, to know how to like navigate the whole space. Right. Okay.

Brandon [00:15:25]: So we need to give it these hints to kind of get into the right Valley and then it finds the, the minimum or something. Yeah.

Gabriel [00:15:31]: One interesting explanation about our awful free works that I think it?s quite insightful, of course, doesn?t cover kind of the entirety of, of what awful does that is, um, they?re going to borrow from, uh, Sergio Chinico for MIT. So he sees kind of awful. Then the interesting thing about awful is God. This very peculiar architecture that we have seen, you know, used, and this architecture operates on this, you know, pairwise context between amino acids. And so the idea is that probably the MSA gives you this first hint about what potential amino acids are close to each other. MSA is most multiple sequence alignment. Exactly. Yeah. Exactly. This evolutionary information. Yeah. And, you know, from this evolutionary information about potential contacts, then is almost as if the model is. of running some kind of, you know, diastro algorithm where it?s sort of decoding, okay, these have to be closed. Okay. Then if these are closed and this is connected to this, then this has to be somewhat closed. And so you decode this, that becomes basically a pairwise kind of distance matrix. And then from this rough pairwise distance matrix, you decode kind of the

Brandon [00:16:42]: actual potential structure. Interesting. So there?s kind of two different things going on in the kind of coarse grain and then the fine grain optimizations. Interesting. Yeah. Very cool.

Gabriel [00:16:53]: Yeah. You mentioned AlphaFold3. So maybe we have a good time to move on to that. So yeah, AlphaFold2 came out and it was like, I think fairly groundbreaking for this field. Everyone got very excited. A few years later, AlphaFold3 came out and maybe for some more history, like what were the advancements in AlphaFold3? And then I think maybe we?ll, after that, we?ll talk a bit about the sort of how it connects to Bolt. But anyway. Yeah. So after AlphaFold2 came out, you know, Jeremy and I got into the field and with many others, you know, the clear problem that, you know, was, you know, obvious after that was, okay, now we can do individual chains. Can we do interactions, interaction, different proteins, proteins with small molecules, proteins with other molecules. And so. So why are interactions important? Interactions are important because to some extent that?s kind of the way that, you know, these machines, you know, these proteins have a function, you know, the function comes by the way that they interact with other proteins and other molecules. Actually, in the first place, you know, the individual machines are often, as Jeremy was mentioning, not made of a single chain, but they?re made of the multiple chains. And then these multiple chains interact with other molecules to give the function to those. And on the other hand, you know, when we try to intervene of these interactions, think about like a disease, think about like a, a biosensor or many other ways we are trying to design the molecules or proteins that interact in a particular way with what we would call a target protein or target. You know, this problem after AlphaVol2, you know, became clear, kind of one of the biggest problems in the field to, to solve many groups, including kind of ours and others, you know, started making some kind of contributions to this problem of trying to model these interactions. And AlphaVol3 was, you know, was a significant advancement on the problem of modeling interactions. And one of the interesting thing that they were able to do while, you know, some of the rest of the field that really tried to try to model different interactions separately, you know, how protein interacts with small molecules, how protein interacts with other proteins, how RNA or DNA have their structure, they put everything together and, you know, train very large models with a lot of advances, including kind of changing kind of systems. Some of the key architectural choices and managed to get a single model that was able to set this new state-of-the-art performance across all of these different kind of modalities, whether that was protein, small molecules is critical to developing kind of new drugs, protein, protein, understanding, you know, interactions of, you know, proteins with RNA and DNAs and so on.

Brandon [00:19:39]: Just to satisfy the AI engineers in the audience, what were some of the key architectural and data, data changes that made that possible?

Gabriel [00:19:48]: Yeah, so one critical one that was not necessarily just unique to AlphaFold3, but there were actually a few other teams, including ours in the field that proposed this, was moving from, you know, modeling structure prediction as a regression problem. So where there is a single answer and you?re trying to shoot for that answer to a generative modeling problem where you have a posterior distribution of possible structures and you?re trying to sample this distribution. And this achieves two things. One is it starts to allow us to try to model more dynamic systems. As we said, you know, some of these structures can actually take multiple structures. And so, you know, you can now model that, you know, through kind of modeling the entire distribution. But on the second hand, from more kind of core modeling questions, when you move from a regression problem to a generative modeling problem, you are really tackling the way that you think about uncertainty in the model in a different way. So if you think about, you know, I?m undecided between different answers, what?s going to happen in a regression model is that, you know, I?m going to try to make an average of those different kind of answers that I had in mind. When you have a generative model, what you?re going to do is, you know, sample all these different answers and then maybe use separate models to analyze those different answers and pick out the best. So that was kind of one of the critical improvement. The other improvement is that they significantly simplified, to some extent, the architecture, especially of the final model that takes kind of those pairwise representations and turns them into an actual structure. And that now looks a lot more like a more traditional transformer than, you know, like a very specialized equivariant architecture that it was in AlphaFold3.

Brandon [00:21:41]: So this is a bitter lesson, a little bit.

Gabriel [00:21:45]: There is some aspect of a bitter lesson, but the interesting thing is that it?s very far from, you know, being like a simple transformer. This field is one of the, I argue, very few fields in applied machine learning where we still have kind of architecture that are very specialized. And, you know, there are many people that have tried to replace these architectures with, you know, simple transformers. And, you know, there is a lot of debate in the field, but I think kind of that most of the consensus is that, you know, the performance... that we get from the specialized architecture is vastly superior than what we get through a single transformer. Another interesting thing that I think on the staying on the modeling machine learning side, which I think it?s somewhat counterintuitive seeing some of the other kind of fields and applications is that scaling hasn?t really worked kind of the same in this field. Now, you know, models like AlphaFold2 and AlphaFold3 are, you know, still very large models.

RJ [00:29:14]: in a place, I think, where we had, you know, some experience working in, you know, with the data and working with this type of models. And I think that put us already in like a good place to, you know, to produce it quickly. And, you know, and I would even say, like, I think we could have done it quicker. The problem was like, for a while, we didn?t really have the compute. And so we couldn?t really train the model. And actually, we only trained the big model once. That?s how much compute we had. We could only train it once. And so like, while the model was training, we were like, finding bugs left and right. A lot of them that I wrote. And like, I remember like, I was like, sort of like, you know, doing like, surgery in the middle, like stopping the run, making the fix, like relaunching. And yeah, we never actually went back to the start. We just like kept training it with like the bug fixes along the way, which was impossible to reproduce now. Yeah, yeah, no, that model is like, has gone through such a curriculum that, you know, learned some weird stuff. But yeah, somehow by miracle, it worked out.

Gabriel [00:30:13]: The other funny thing is that the way that we were training, most of that model was through a cluster from the Department of Energy. But that?s sort of like a shared cluster that many groups use. And so we were basically training the model for two days, and then it would go back to the queue and stay a week in the queue. Oh, yeah. And so it was pretty painful. And so we actually kind of towards the end with Evan, the CEO of Genesis, and basically, you know, I was telling him a bit about the project and, you know, kind of telling him about this frustration with the compute. And so luckily, you know, he offered to kind of help. And so we, we got the help from Genesis to, you know, finish up the model. Otherwise, it probably would have taken a couple of extra weeks.

Brandon [00:30:57]: Yeah, yeah.

Brandon [00:31:02]: And then, and then there?s some progression from there.

Gabriel [00:31:06]: Yeah, so I would say kind of that, both one, but also kind of these other kind of set of models that came around the same time, were kind of approaching were a big leap from, you know, kind of the previous kind of open source models, and, you know, kind of really kind of approaching the level of AlphaVault 3. But I would still say that, you know, even to this day, there are, you know, some... specific instances where AlphaVault 3 works better. I think one common example is antibody antigen prediction, where, you know, AlphaVault 3 still seems to have an edge in many situations. Obviously, these are somewhat different models. They are, you know, you run them, you obtain different results. So it?s, it?s not always the case that one model is better than the other, but kind of in aggregate, we still, especially at the time.

Brandon [00:32:00]: So AlphaVault 3 is, you know, still having a bit of an edge. We should talk about this more when we talk about Boltzgen, but like, how do you know one is, one model is better than the other? Like you, so you, I make a prediction, you make a prediction, like, how do you know?

Gabriel [00:32:11]: Yeah, so easily, you know, the, the great thing about kind of structural prediction and, you know, once we?re going to go into the design space of designing new small molecule, new proteins, this becomes a lot more complex. But a great thing about structural prediction is that a bit like, you know, CASP was doing, basically the way that you can evaluate them is that, you know, you train... You know, you train a model on a structure that was, you know, released across the field up until a certain time. And, you know, one of the things that we didn?t talk about that was really critical in all this development is the PDB, which is the Protein Data Bank. It?s this common resources, basically common database where every biologist publishes their structures. And so we can, you know, train on, you know, all the structures that were put in the PDB until a certain date. And then... And then we basically look for recent structures, okay, which structures look pretty different from anything that was published before, because we really want to try to understand generalization.

Brandon [00:33:13]: And then on this new structure, we evaluate all these different models. And so you just know when AlphaFold3 was trained, you know, when you?re, you intentionally trained to the same date or something like that. Exactly. Right. Yeah.

Gabriel [00:33:24]: And so this is kind of the way that you can somewhat easily kind of compare these models, obviously, that assumes that, you know, the training. You?ve always been very passionate about validation. I remember like DiffDoc, and then there was like DiffDocL and DocGen. You?ve thought very carefully about this in the past. Like, actually, I think DocGen is like a really funny story that I think, I don?t know if you want to talk about that. It?s an interesting like... Yeah, I think one of the amazing things about putting things open source is that we get a ton of feedback from the field. And, you know, sometimes we get kind of great feedback of people. Really like... But honestly, most of the times, you know, to be honest, that?s also maybe the most useful feedback is, you know, people sharing about where it doesn?t work. And so, you know, at the end of the day, it?s critical. And this is also something, you know, across other fields of machine learning. It?s always critical to set, to do progress in machine learning, set clear benchmarks. And as, you know, you start doing progress of certain benchmarks, then, you know, you need to improve the benchmarks and make them harder and harder. And this is kind of the progression of, you know, how the field operates. And so, you know, the example of DocGen was, you know, we published this initial model called DiffDoc in my first year of PhD, which was sort of like, you know, one of the early models to try to predict kind of interactions between proteins, small molecules, that we bought a year after AlphaFold2 was published. And now, on the one hand, you know, on these benchmarks that we were using at the time, DiffDoc was doing really well, kind of, you know, outperforming kind of some of the traditional physics-based methods. But on the other hand, you know, when we started, you know, kind of giving these tools to kind of many biologists, and one example was that we collaborated with was the group of Nick Polizzi at Harvard. We noticed, started noticing that there was this clear, pattern where four proteins that were very different from the ones that we?re trained on, the models was, was struggling. And so, you know, that seemed clear that, you know, this is probably kind of where we should, you know, put our focus on. And so we first developed, you know, with Nick and his group, a new benchmark, and then, you know, went after and said, okay, what can we change? And kind of about the current architecture to improve this pattern and generalization. And this is the same that, you know, we?re still doing today, you know, kind of, where does the model not work, you know, and then, you know, once we have that benchmark, you know, let?s try to, through everything we, any ideas that we have of the problem.

RJ [00:36:15]: And there?s a lot of like healthy skepticism in the field, which I think, you know, is, is, is great. And I think, you know, it?s very clear that there?s a ton of things, the models don?t really work well on, but I think one thing that?s probably, you know, undeniable is just like the pace of, pace of progress, you know, and how, how much better we?re getting, you know, every year. And so I think if you, you know, if you assume, you know, any constant, you know, rate of progress moving forward, I think things are going to look pretty cool at some point in the future.

Gabriel [00:36:42]: ChatGPT was only three years ago. Yeah, I mean, it?s wild, right?

RJ [00:36:45]: Like, yeah, yeah, yeah, it?s one of those things. Like, you?ve been doing this. Being in the field, you don?t see it coming, you know? And like, I think, yeah, hopefully we?ll, you know, we?ll, we?ll continue to have as much progress we?ve had the past few years.

Brandon [00:36:55]: So this is maybe an aside, but I?m really curious, you get this great feedback from the, from the community, right? By being open source. My question is partly like, okay, yeah, if you open source and everyone can copy what you did, but it?s also maybe balancing priorities, right? Where you, like all my customers are saying. I want this, there?s all these problems with the model. Yeah, yeah. But my customers don?t care, right? So like, how do you, how do you think about that? Yeah.

Gabriel [00:37:26]: So I would say a couple of things. One is, you know, part of our goal with Bolts and, you know, this is also kind of established as kind of the mission of the public benefit company that we started is to democratize the access to these tools. But one of the reasons why we realized that Bolts needed to be a company, it couldn?t just be an academic project is that putting a model on GitHub is definitely not enough to get, you know, chemists and biologists, you know, across, you know, both academia, biotech and pharma to use your model to, in their therapeutic programs. And so a lot of what we think about, you know, at Bolts beyond kind of the, just the models is thinking about all the layers. The layers that come on top of the models to get, you know, from, you know, those models to something that can really enable scientists in the industry. And so that goes, you know, into building kind of the right kind of workflows that take in kind of, for example, the data and try to answer kind of directly that those problems that, you know, the chemists and the biologists are asking, and then also kind of building the infrastructure. And so this to say that, you know, even with models fully open. You know, we see a ton of potential for, you know, products in the space and the critical part about a product is that even, you know, for example, with an open source model, you know, running the model is not free, you know, as we were saying, these are pretty expensive model and especially, and maybe we?ll get into this, you know, these days we?re seeing kind of pretty dramatic inference time scaling of these models where, you know, the more you run them, the better the results are. But there, you know, you see. You start getting into a point that compute and compute costs becomes a critical factor. And so putting a lot of work into building the right kind of infrastructure, building the optimizations and so on really allows us to provide, you know, a much better service potentially to the open source models. That to say, you know, even though, you know, with a product, we can provide a much better service. I do still think, and we will continue to put a lot of our models open source because the critical kind of role. I think of open source. Models is, you know, helping kind of the community progress on the research and, you know, from which we, we all benefit. And so, you know, we?ll continue to on the one hand, you know, put some of our kind of base models open source so that the field can, can be on top of it. And, you know, as we discussed earlier, we learn a ton from, you know, the way that the field uses and builds on top of our models, but then, you know, try to build a product that gives the best experience possible to scientists. So that, you know, like a chemist or a biologist doesn?t need to, you know, spin off a GPU and, you know, set up, you know, our open source model in a particular way, but can just, you know, a bit like, you know, I, even though I am a computer scientist, machine learning scientist, I don?t necessarily, you know, take a open source LLM and try to kind of spin it off. But, you know, I just maybe open a GPT app or a cloud code and just use it as an amazing product. We kind of want to give the same experience. So this front world.

Brandon [00:40:40]: I heard a good analogy yesterday that a surgeon doesn?t want the hospital to design a scalpel, right?

Brandon [00:40:48]: So just buy the scalpel.

RJ [00:40:50]: You wouldn?t believe like the number of people, even like in my short time, you know, between AlphaFold3 coming out and the end of the PhD, like the number of people that would like reach out just for like us to like run AlphaFold3 for them, you know, or things like that. Just because like, you know, bolts in our case, you know, just because it?s like. It?s like not that easy, you know, to do that, you know, if you?re not a computational person. And I think like part of the goal here is also that, you know, we continue to obviously build the interface with computational folks, but that, you know, the models are also accessible to like a larger, broader audience. And then that comes from like, you know, good interfaces and stuff like that.

Gabriel [00:41:27]: I think one like really interesting thing about bolts is that with the release of it, you didn?t just release a model, but you created a community. Yeah. Did that community, it grew very quickly. Did that surprise you? And like, what is the evolution of that community and how is that fed into bolts?

RJ [00:41:43]: If you look at its growth, it?s like very much like when we release a new model, it?s like, there?s a big, big jump, but yeah, it?s, I mean, it?s been great. You know, we have a Slack community that has like thousands of people on it. And it?s actually like self-sustaining now, which is like the really nice part because, you know, it?s, it?s almost overwhelming, I think, you know, to be able to like answer everyone?s questions and help. It?s really difficult, you know. The, the few people that we were, but it ended up that like, you know, people would answer each other?s questions and like, sort of like, you know, help one another. And so the Slack, you know, has been like kind of, yeah, self, self-sustaining and that?s been, it?s been really cool to see.

RJ [00:42:21]: And, you know, that?s, that?s for like the Slack part, but then also obviously on GitHub as well. We?ve had like a nice, nice community. You know, I think we also aspire to be even more active on it, you know, than we?ve been in the past six months, which has been like a bit challenging, you know, for us. But. Yeah, the community has been, has been really great and, you know, there?s a lot of papers also that have come out with like new evolutions on top of bolts and it?s surprised us to some degree because like there?s a lot of models out there. And I think like, you know, sort of people converging on that was, was really cool. And, you know, I think it speaks also, I think, to the importance of like, you know, when, when you put code out, like to try to put a lot of emphasis and like making it like as easy to use as possible and something we thought a lot about when we released the code base. You know, it?s far from perfect, but, you know.

Brandon [00:43:07]: Do you think that that was one of the factors that caused your community to grow is just the focus on easy to use, make it accessible? I think so.

RJ [00:43:14]: Yeah. And we?ve, we?ve heard it from a few people over the, over the, over the years now. And, you know, and some people still think it should be a lot nicer and they?re, and they?re right. And they?re right. But yeah, I think it was, you know, at the time, maybe a little bit easier than, than other things.

Gabriel [00:43:29]: The other thing part, I think led to, to the community and to some extent, I think, you know, like the somewhat the trust in the community. Kind of what we, what we put out is the fact that, you know, it?s not really been kind of, you know, one model, but, and maybe we?ll talk about it, you know, after Boltz 1, you know, there were maybe another couple of models kind of released, you know, or open source kind of soon after. We kind of continued kind of that open source journey or at least Boltz 2, where we are not only improving kind of structure prediction, but also starting to do affinity predictions, understanding kind of the strength of the interactions between these different models, which is this critical component. critical property that you often want to optimize in discovery programs. And then, you know, more recently also kind of protein design model. And so we?ve sort of been building this suite of, of models that come together, interact with one another, where, you know, kind of, there is almost an expectation that, you know, we, we take very at heart of, you know, always having kind of, you know, across kind of the entire suite of different tasks, the best or across the best. model out there so that it?s sort of like our open source tool can be kind of the go-to model for everybody in the, in the industry. I really want to talk about Boltz 2, but before that, one last question in this direction, was there anything about the community which surprised you? Were there any, like, someone was doing something and you?re like, why would you do that? That?s crazy. Or that?s actually genius. And I never would have thought about that.

RJ [00:45:01]: I mean, we?ve had many contributions. I think like some of the. Interesting ones, like, I mean, we had, you know, this one individual who like wrote like a complex GPU kernel, you know, for part of the architecture on a piece of, the funny thing is like that piece of the architecture had been there since AlphaFold 2, and I don?t know why it took Boltz for this, you know, for this person to, you know, to decide to do it, but that was like a really great contribution. We?ve had a bunch of others, like, you know, people figuring out like ways to, you know, hack the model to do something. They click peptides, like, you know, there?s, I don?t know if there?s any other interesting ones come to mind.

Gabriel [00:45:41]: One cool one, and this was, you know, something that initially was proposed as, you know, as a message in the Slack channel by Tim O?Donnell was basically, he was, you know, there are some cases, especially, for example, we discussed, you know, antibody-antigen interactions where the models don?t necessarily kind of get the right answer. What he noticed is that, you know, the models were somewhat stuck into predicting kind of the antibodies. And so he basically ran the experiments in this model, you can condition, basically, you can give hints. And so he basically gave, you know, random hints to the model, basically, okay, you should bind to this residue, you should bind to the first residue, or you should bind to the 11th residue, or you should bind to the 21st residue, you know, basically every 10 residues scanning the entire antigen.

Brandon [00:46:33]: Residues are the...

Gabriel [00:46:34]: The amino acids. The amino acids, yeah. So the first amino acids. The 11 amino acids, and so on. So it?s sort of like doing a scan, and then, you know, conditioning the model to predict all of them, and then looking at the confidence of the model in each of those cases and taking the top. And so it?s sort of like a very somewhat crude way of doing kind of inference time search. But surprisingly, you know, for antibody-antigen prediction, it actually kind of helped quite a bit. And so there?s some, you know, interesting ideas that, you know, obviously, as kind of developing the model, you say kind of, you know, wow. This is why would the model, you know, be so dumb. But, you know, it?s very interesting. And that, you know, leads you to also kind of, you know, start thinking about, okay, how do I, can I do this, you know, not with this brute force, but, you know, in a smarter way.

RJ [00:47:22]: And so we?ve also done a lot of work on that direction. And that speaks to, like, the, you know, the power of scoring. We?re seeing that a lot. I?m sure we?ll talk about it more when we talk about BullsGen. But, you know, our ability to, like, take a structure and determine that that structure is, like... Good. You know, like, somewhat accurate. Whether that?s a single chain or, like, an interaction is a really powerful way of improving, you know, the models. Like, sort of like, you know, if you can sample a ton and you assume that, like, you know, if you sample enough, you?re likely to have, like, you know, the good structure. Then it really just becomes a ranking problem. And, you know, now we?re, you know, part of the inference time scaling that Gabby was talking about is very much that. It?s like, you know, the more we sample, the more we, like, you know, the ranking model. The ranking model ends up finding something it really likes. And so I think our ability to get better at ranking, I think, is also what?s going to enable sort of the next, you know, next big, big breakthroughs. Interesting.

Brandon [00:48:17]: But I guess there?s a, my understanding, there?s a diffusion model and you generate some stuff and then you, I guess, it?s just what you said, right? Then you rank it using a score and then you finally... And so, like, can you talk about those different parts? Yeah.

Gabriel [00:48:34]: So, first of all, like, the... One of the critical kind of, you know, beliefs that we had, you know, also when we started working on Boltz 1 was sort of like the structure prediction models are somewhat, you know, our field version of some foundation models, you know, learning about kind of how proteins and other molecules interact. And then we can leverage that learning to do all sorts of other things. And so with Boltz 2, we leverage that learning to do affinity predictions. So understanding kind of, you know, if I give you this protein, this molecule. How tightly is that interaction? For Boltz 1, what we did was taking kind of that kind of foundation models and then fine tune it to predict kind of entire new proteins. And so the way basically that that works is sort of like instead of for the protein that you?re designing, instead of fitting in an actual sequence, you fit in a set of blank tokens. And you train the models to, you know, predict both the structure of kind of that protein. The structure also, what the different amino acids of that proteins are. And so basically the way that Boltz 1 operates is that you feed a target protein that you may want to kind of bind to or, you know, another DNA, RNA. And then you feed the high level kind of design specification of, you know, what you want your new protein to be. For example, it could be like an antibody with a particular framework. It could be a peptide. It could be many other things. And that?s with natural language or? And that?s, you know, basically, you know, prompting. And we have kind of this sort of like spec that you specify. And, you know, you feed kind of this spec to the model. And then the model translates this into, you know, a set of, you know, tokens, a set of conditioning to the model, a set of, you know, blank tokens. And then, you know, basically the codes as part of the diffusion models, the codes. It?s a new structure and a new sequence for your protein. And, you know, basically, then we take that. And as Jeremy was saying, we are trying to score it and, you know, how good of a binder it is to that original target.

Brandon [00:50:51]: You?re using basically Boltz to predict the folding and the affinity to that molecule. So and then that kind of gives you a score? Exactly.

Gabriel [00:51:03]: So you use this model to predict the folding. And then you do two things. One is that you predict the structure and with something like Boltz2, and then you basically compare that structure with what the model predicted, what Boltz2 predicted. And this is sort of like in the field called consistency. It?s basically you want to make sure that, you know, the structure that you?re predicting is actually what you?re trying to design. And that gives you a much better confidence that, you know, that?s a good design. And so that?s the first filtering. And the second filtering that we did as part of kind of the Boltz2 pipeline that was released is that we look at the confidence that the model has in the structure. Now, unfortunately, kind of going to your question of, you know, predicting affinity, unfortunately, confidence is not a very good predictor of affinity. And so one of the things that we?ve actually done a ton of progress, you know, since we released Boltz2.

Brandon [00:52:03]: And kind of we have some new results that we are going to kind of announce soon is kind of, you know, the ability to get much better hit rates when instead of, you know, trying to rely on confidence of the model, we are actually directly trying to predict the affinity of that interaction. Okay. Just backing up a minute. So your diffusion model actually predicts not only the protein sequence, but also the folding of it. Exactly.

Gabriel [00:52:32]: And actually, you can... One of the big different things that we did compared to other models in the space, and, you know, there were some papers that had already kind of done this before, but we really scaled it up was, you know, basically somewhat merging kind of the structure prediction and the sequence prediction into almost the same task. And so the way that Boltz2 works is that you are basically the only thing that you?re doing is predicting the structure. So the only sort of... Supervision is we give you a supervision on the structure, but because the structure is atomic and, you know, the different amino acids have a different atomic composition, basically from the way that you place the atoms, we also understand not only kind of the structure that you wanted, but also the identity of the amino acid that, you know, the models believed was there. And so we?ve basically, instead of, you know, having these two supervision signals, you know, one discrete, one continuous. That somewhat, you know, don?t interact well together. We sort of like build kind of like an encoding of, you know, sequences in structures that allows us to basically use exactly the same supervision signal that we were using to Boltz2 that, you know, you know, largely similar to what AlphaVol3 proposed, which is very scalable. And we can use that to design new proteins. Oh, interesting.

RJ [00:53:58]: Maybe a quick shout out to Hannes Stark on our team who like did all this work. Yeah.

Gabriel [00:54:04]: Yeah, that was a really cool idea. I mean, like looking at the paper and there?s this is like encoding or you just add a bunch of, I guess, kind of atoms, which can be anything, and then they get sort of rearranged and then basically plopped on top of each other so that and then that encodes what the amino acid is. And there?s sort of like a unique way of doing this. It was that was like such a really such a cool, fun idea.

RJ [00:54:29]: I think that idea was had existed before. Yeah, there were a couple of papers.

Gabriel [00:54:33]: Yeah, I had proposed this and and Hannes really took it to the large scale.

Brandon [00:54:39]: In the paper, a lot of the paper for Boltz2Gen is dedicated to actually the validation of the model. In my opinion, all the people we basically talk about feel that this sort of like in the wet lab or whatever the appropriate, you know, sort of like in real world validation is the whole problem or not the whole problem, but a big giant part of the problem. So can you talk a little bit about the highlights? From there, that really because to me, the results are impressive, both from the perspective of the, you know, the model and also just the effort that went into the validation by a large team.

Gabriel [00:55:18]: First of all, I think I should start saying is that both when we were at MIT and Thomas Yacolas and Regina Barzillai?s lab, as well as at Boltz, you know, we are not a we?re not a biolab and, you know, we are not a therapeutic company. And so to some extent, you know, we were first forced to, you know, look outside of, you know, our group, our team to do the experimental validation. One of the things that really, Hannes, in the team pioneer was the idea, OK, can we go not only to, you know, maybe a specific group and, you know, trying to find a specific system and, you know, maybe overfit a bit to that system and trying to validate. But how can we test this model? So. Across a very wide variety of different settings so that, you know, anyone in the field and, you know, printing design is, you know, such a kind of wide task with all sorts of different applications from therapeutic to, you know, biosensors and many others that, you know, so can we get a validation that is kind of goes across many different tasks? And so he basically put together, you know, I think it was something like, you know, 25 different. You know, academic and industry labs that committed to, you know, testing some of the designs from the model and some of this testing is still ongoing and, you know, giving results kind of back to us in exchange for, you know, hopefully getting some, you know, new great sequences for their task. And he was able to, you know, coordinate this, you know, very wide set of, you know, scientists and already in the paper, I think we. Shared results from, I think, eight to 10 different labs kind of showing results from, you know, designing peptides, designing to target, you know, ordered proteins, peptides targeting disordered proteins, which are results, you know, of designing proteins that bind to small molecules, which are results of, you know, designing nanobodies and across a wide variety of different targets. And so that?s sort of like. That gave to the paper a lot of, you know, validation to the model, a lot of validation that was kind of wide.

Brandon [00:57:39]: And so those would be therapeutics for those animals or are they relevant to humans as well? They?re relevant to humans as well.

Gabriel [00:57:45]: Obviously, you need to do some work into, quote unquote, humanizing them, making sure that, you know, they have the right characteristics to so they?re not toxic to humans and so on.

RJ [00:57:57]: There are some approved medicine in the market that are nanobodies. There?s a general. General pattern, I think, in like in trying to design things that are smaller, you know, like it?s easier to manufacture at the same time, like that comes with like potentially other challenges, like maybe a little bit less selectivity than like if you have something that has like more hands, you know, but the yeah, there?s this big desire to, you know, try to design many proteins, nanobodies, small peptides, you know, that just are just great drug modalities.

Brandon [00:58:27]: Okay. I think we were left off. We were talking about validation. Validation in the lab. And I was very excited about seeing like all the diverse validations that you?ve done. Can you go into some more detail about them? Yeah. Specific ones. Yeah.

RJ [00:58:43]: The nanobody one. I think we did. What was it? 15 targets. Is that correct? 14. 14 targets. Testing. So we typically the way this works is like we make a lot of designs. All right. On the order of like tens of thousands. And then we like rank them and we pick like the top. And in this case, and was 15 right for each target and then we like measure sort of like the success rates, both like how many targets we were able to get a binder for and then also like more generally, like out of all of the binders that we designed, how many actually proved to be good binders. Some of the other ones I think involved like, yeah, like we had a cool one where there was a small molecule or design a protein that binds to it. That has a lot of like interesting applications, you know, for example. Like Gabri mentioned, like biosensing and things like that, which is pretty cool. We had a disordered protein, I think you mentioned also. And yeah, I think some of those were some of the highlights. Yeah.

Gabriel [00:59:44]: So I would say that the way that we structure kind of some of those validations was on the one end, we have validations across a whole set of different problems that, you know, the biologists that we were working with came to us with. So we were trying to. For example, in some of the experiments, design peptides that would target the RACC, which is a target that is involved in metabolism. And we had, you know, a number of other applications where we were trying to design, you know, peptides or other modalities against some other therapeutic relevant targets. We designed some proteins to bind small molecules. And then some of the other testing that we did was really trying to get like a more broader sense. So how does the model work, especially when tested, you know, on somewhat generalization? So one of the things that, you know, we found with the field was that a lot of the validation, especially outside of the validation that was on specific problems, was done on targets that have a lot of, you know, known interactions in the training data. And so it?s always a bit hard to understand, you know, how much are these models really just regurgitating kind of what they?ve seen or trying to imitate. What they?ve seen in the training data versus, you know, really be able to design new proteins. And so one of the experiments that we did was to take nine targets from the PDB, filtering to things where there is no known interaction in the PDB. So basically the model has never seen kind of this particular protein bound or a similar protein bound to another protein. So there is no way that. The model from its training set can sort of like say, okay, I?m just going to kind of tweak something and just imitate this particular kind of interaction. And so we took those nine proteins. We worked with adaptive CRO and basically tested, you know, 15 mini proteins and 15 nanobodies against each one of them. And the very cool thing that we saw was that on two thirds of those targets, we were able to, from this 15 design, get nanomolar binders, nanomolar, roughly speaking, just a measure of, you know, how strongly kind of the interaction is, roughly speaking, kind of like a nanomolar binder is approximately the kind of binding strength or binding that you need for a therapeutic. Yeah. So maybe switching directions a bit. Bolt?s lab was just announced this week or was it last week? Yeah. This is like your. First, I guess, product, if that?s if you want to call it that. Can you talk about what Bolt?s lab is and yeah, you know, what you hope that people take away from this? Yeah.

RJ [01:02:44]: You know, as we mentioned, like I think at the very beginning is the goal with the product has been to, you know, address what the models don?t on their own. And there?s largely sort of two categories there. I?ll split it in three. The first one. It?s one thing to predict, you know, a single interaction, for example, like a single structure. It?s another to like, you know, very effectively search a space, a design space to produce something of value. What we found, like sort of building on this product is that there?s a lot of steps involved, you know, in that there?s certainly need to like, you know, accompany the user through, you know, one of those steps, for example, is like, you know, the creation of the target itself. You know, how do we make sure that the model has like a good enough understanding of the target? So we can like design something and there?s all sorts of tricks, you know, that you can do to improve like a particular, you know, structure prediction. And so that?s sort of like, you know, the first stage. And then there?s like this stage of like, you know, designing and searching the space efficiently. You know, for something like BullsGen, for example, like you, you know, you design many things and then you rank them, for example, for small molecule process, a little bit more complicated. We actually need to also make sure that the molecules are synthesizable. And so the way we do that is that, you know, we have a generative model that learns. To use like appropriate building blocks such that, you know, it can design within a space that we know is like synthesizable. And so there?s like, you know, this whole pipeline really of different models involved in being able to design a molecule. And so that?s been sort of like the first thing we call them agents. We have a protein agent and we have a small molecule design agents. And that?s really like at the core of like what powers, you know, the BullsLab platform.

Brandon [01:04:22]: So these agents, are they like a language model wrapper or they?re just like your models and you?re just calling them agents? A lot. Yeah. Because they, they, they sort of perform a function on behalf of.

RJ [01:04:33]: They?re more of like a, you know, a recipe, if you wish. And I think we use that term sort of because of, you know, sort of the complex pipelining and automation, you know, that goes into like all this plumbing. So that?s the first part of the product. The second part is the infrastructure. You know, we need to be able to do this at very large scale for any one, you know, group that?s doing a design campaign. Let?s say you?re designing, you know, I?d say a hundred thousand possible candidates. Right. To find the good one that is, you know, a very large amount of compute, you know, for small molecules, it?s on the order of like a few seconds per designs for proteins can be a bit longer. And so, you know, ideally you want to do that in parallel, otherwise it?s going to take you weeks. And so, you know, we?ve put a lot of effort into like, you know, our ability to have a GPU fleet that allows any one user, you know, to be able to do this kind of like large parallel search.

Brandon [01:05:23]: So you?re amortizing the cost over your users. Exactly. Exactly.

RJ [01:05:27]: And, you know, to some degree, like it?s whether you. Use 10,000 GPUs for like, you know, a minute is the same cost as using, you know, one GPUs for God knows how long. Right. So you might as well try to parallelize if you can. So, you know, a lot of work has gone, has gone into that, making it very robust, you know, so that we can have like a lot of people on the platform doing that at the same time. And the third one is, is the interface and the interface comes in, in two shapes. One is in form of an API and that?s, you know, really suited for companies that want to integrate, you know, these pipelines, these agents.

RJ [01:06:01]: So we?re already partnering with, you know, a few distributors, you know, that are gonna integrate our API. And then the second part is the user interface. And, you know, we, we?ve put a lot of thoughts also into that. And this is when I, I mentioned earlier, you know, this idea of like broadening the audience. That?s kind of what the, the user interface is about. And we?ve built a lot of interesting features in it, you know, for example, for collaboration, you know, when you have like potentially multiple medicinal chemists or. We?re going through the results and trying to pick out, okay, like what are the molecules that we?re going to go and test in the lab? It?s powerful for them to be able to, you know, for example, each provide their own ranking and then do consensus building. And so there?s a lot of features around launching these large jobs, but also around like collaborating on analyzing the results that we try to solve, you know, with that part of the platform. So Bolt?s lab is sort of a combination of these three objectives into like one, you know, sort of cohesive platform. Who is this accessible to? Everyone. You do need to request access today. We?re still like, you know, sort of ramping up the usage, but anyone can request access. If you are an academic in particular, we, you know, we provide a fair amount of free credit so you can play with the platform. If you are a startup or biotech, you may also, you know, reach out and we?ll typically like actually hop on a call just to like understand what you?re trying to do and also provide a lot of free credit to get started. And of course, also with larger companies, we can deploy this platform in a more like secure environment. And so that?s like more like customizing. You know, deals that we make, you know, with the partners, you know, and that?s sort of the ethos of Bolt. I think this idea of like servicing everyone and not necessarily like going after just, you know, the really large enterprises. And that starts from the open source, but it?s also, you know, a key design principle of the product itself.

Gabriel [01:07:48]: One thing I was thinking about with regards to infrastructure, like in the LLM space, you know, the cost of a token has gone down by I think a factor of a thousand or so over the last three years, right? Yeah. And is it possible that like essentially you can exploit economies of scale and infrastructure that you can make it cheaper to run these things yourself than for any person to roll their own system? A hundred percent. Yeah.

RJ [01:08:08]: I mean, we?re already there, you know, like running Bolts on our platform, especially on a large screen is like considerably cheaper than it would probably take anyone to put the open source model out there and run it. And on top of the infrastructure, like one of the things that we?ve been working on is accelerating the models. So, you know. Our small molecule screening pipeline is 10x faster on Bolts Lab than it is in the open source, you know, and that?s also part of like, you know, building a product, you know, of something that scales really well. And we really wanted to get to a point where like, you know, we could keep prices very low in a way that it would be a no-brainer, you know, to use Bolts through our platform.

Gabriel [01:08:52]: How do you think about validation of your like agentic systems? Because, you know, as you were saying earlier. Like we?re AlphaFold style models are really good at, let?s say, monomeric, you know, proteins where you have, you know, co-evolution data. But now suddenly the whole point of this is to design something which doesn?t have, you know, co-evolution data, something which is really novel. So now you?re basically leaving the domain that you thought was, you know, that you know you are good at. So like, how do you validate that?

RJ [01:09:22]: Yeah, I like every complete, but there?s obviously, you know, a ton of computational metrics. That we rely on, but those are only take you so far. You really got to go to the lab, you know, and test, you know, okay, with this method A and this method B, how much better are we? You know, how much better is my, my hit rate? How stronger are my binders? Also, it?s not just about hit rate. It?s also about how good the binders are. And there?s really like no way, nowhere around that. I think we?re, you know, we?ve really ramped up the amount of experimental validation that we do so that we like really track progress, you know, as scientifically sound, you know. Yeah. As, as possible out of this, I think.

Gabriel [01:10:00]: Yeah, no, I think, you know, one thing that is unique about us and maybe companies like us is that because we?re not working on like maybe a couple of therapeutic pipelines where, you know, our validation would be focused on those. We, when we do an experimental validation, we try to test it across tens of targets. And so that on the one end, we can get a much more statistically significant result and, and really allows us to make progress. From the methodological side without being, you know, steered by, you know, overfitting on any one particular system. And of course we choose, you know, we always try to choose targets and problems are sort of like at the frontier of what?s possible today. So, you know, you don?t want something too easy. You don?t want something too hard. Otherwise you?re not going to see progress. And so, you know, this is a somewhat evolving set of targets. We talked earlier about the targets that we looked at with, with Boltchan. And now we are even trying kind of, you know, even harder targets, both for small molecule and proteins. And so we try to keep ourselves on the, on the boundary of what?s possible. So do you have like infrastructure or is this is like, you just have a lot of different partnerships with academic labs and you?re just kind of keep pushing on these and driving these. We do partially this through academic labs more and more. We do this through CROs just because of, you know, to some extent is also, we need kind of replicability often kind of, you know, going after the same time. So we try to, we try to keep our, our targets, you know, multiple times and, you know, to see the, the progress from, you know, one month to the next. And speed. And speed. And speed. Speed of execution. Yeah. And, So what happens if you start getting a bunch of like really strong biters against therapeutic targets? What do you do?

RJ [01:11:43]: Release them. Yeah.

Gabriel [01:11:45]: But you can release them in open source? Like,

RJ [01:11:47]: Yeah, I mean, you know, I mean, when we say we have no interest in making dress, we?re serious. Like, you know, uh, I mean, when it, when it was with the academic labs, basically the, you know, I was, they keep it, they do a lot of it.

Gabriel [01:12:02]: I will also say, and I think this has been a bit of the issue that I have with some of the things that have been said in the field, is when we say that we design new proteins or we say that we design new molecules, go and bind these particular targets. We should be very clear, these are not drugs. These are not things that are ready to be put into a human. And there is still a lot of development that goes with it. And so this is kind of to us, we see ourselves as building tools for scientists. At the end of the day, it really relies on the scientist having a great therapeutic hypothesis and then pushing through kind of all the stages of development. And, you know, we try to build tools that can accompany them in that journey. It?s not like a magic box where, you know, you can just turn it and get FDA approved drugs.

Brandon [01:13:06]: But actually, that brings up an interesting question that I?ve been wondering about is, do you guys see yourself staying in this, for lack of a better way of saying it, layer? Or do you think that you?ll start to... Yeah. Either on the physical sense, looking at different layers of the virtual cell, so to speak, or also, you know, so there?s like the development process that goes, you know, sort of like design preclinical, clinical approval and thinking about improving the performance throughout that process based on the designs. Is that a direction that you guys are pushing? Yeah.

Gabriel [01:13:45]: So one of the things, as Jeremy said, you know, we are... We are not a therapeutic company. We want to kind of stay not to be a therapeutic company, always be at the service of, you know, all the different, you know, companies, including therapeutic companies that we serve. And, you know, that to some extent does mean, you know, that we need to try to, you know, go deeper and deeper in getting these models better and better. One of the things that we are doing across, you know, many other in the field is, you know, now that we are really... They?re starting to be good, both for small molecule and... For proteins to design kind of binders, design relatively tight binders, is starting to look at all these other properties, you know, they?re called developpabilities or at me that, you know, we care about when developing a drug and try, can we design them from, from Gageco. The thing about those properties in some of them, you know, you need to, you know, start having an understanding of the cell. And so that?s on the one hand, kind of why we need that understanding. But also, you know, the way... The way that we also think about all different and complex diseases is that these models, then these tools that we?re building have a good understanding of kind of, you know, biomolecular interactions and kind of their interactions. Now, at the same time, every disease is often kind of unique and every therapeutic hypothesis is unique. And so you maybe want to have something that needs to hit the particular, you know, let?s say target in a virus in a particular way, but you don?t maybe know exactly. So you can start to have a more open-minded understanding of what?s, what?s a way you want to do. And so maybe in the first set of designs, you?re going to try to target different epitopes in different ways, and then you?re going to test them in the lab, maybe directly in vivo, and you?re going to see which ones work and which ones don?t. And so then you need to bring those results back into the models. And then the models can start to have a more wider understanding, you know, not just of the biophysical of the antibodies interacting with that target, but also how that is shaped within the cell. And so first of all, you know, that means on the one end that we need, you know, kind of these loops, and this is also partially how we, we designed the platform to be. But that also means that we also need to start understanding more and more kind of higher level things. And, you know, I wouldn?t say that we?re working in any way on like a virtual cell like others are, but we?re definitely thinking kind of very deeply about kind of, you know, how does, you know, kind of the way that we target certain proteins. Interfere, interact with, you know, maybe pathways that are existing in the cell. One question that has come up is you talk a lot about user interface and so on. And I think this is really important, but like my experience with dealing with medicinal chemists, when you get the machine learning models, is they are the most superstitious, skeptical, like pseudo-religious people I?ve ever talked to when it comes to doing science. Sorry for the medicinal chemists listening. Yeah, they?re amazing. Like, they?re absolutely, I?ve worked with some spectacular medicinal chemists who just pull magic out of their hat again and again, and I have no idea how they do it. But when you bring them a machine learning model, it is sometimes quite tricky to get them to deal with it. How has your interaction been with this? And how have you thought about, like, building Bolt?s lab to work with the skeptics? One of the great value unlocks for us and for our product has been when we brought to the team a medicinal chemist. His name is Jeffrey. So I think kind of like on the one hand, you know, day one, you know, he obviously had a lot of opinions on kind of a lot of the ways that we should change, you know, both kind of the way that the agents worked, the way that the platform worked. But it?s been really amazing kind of, you know, once also we started kind of shaping kind of the platform in a better way with this feedback, how we went from, you know, to some extent, you know, a fair skepticism to him, you know, actually using, you know, a lot of the things that we did. Yeah. So he?s doing a lot more compute than any of our computational folks in the team, you know, at times that, you know, he?s, you know, running, you know, he has all these sort of hypotheses. Okay, maybe I can hit this protein this particular way. I can hit in that way. Actually, let me look at for this particular molecular space. Let me try to optimize for this particular interactions. So he ends up, you know, running several screens in parallel, you know, using hundreds of GPUs, you know, on his own. And, you know, so this has been, you know, pretty incredible to see kind of how, you know, maybe the way that I was more thinking about a problem, which is, okay, you?re just trying to design a binder, a small molecule to a particular protein. The way that he thinks about it is, you know, much more deeply and, you know, trying all these different things, these different hypotheses. And then, you know, once he gets the results from the model, he doesn?t just, you know, take the top 15, but he really kind of looks over and, you know, kind of tries to understand, you know, the different things. And then when we select, you know, maybe some designs to bring forth, you know, he has, you know, something where, you know, both the models understand that something?s good, but himself as well. And that?s why we also built kind of the platform to be an interface for, you know, this kind of chemist and, you know, also like engineers. Yeah. Collaborative experience.

RJ [01:19:09]: I think at the end of the day, like, you know, for people to be convinced, you have to show them something that they didn?t think was possible. And until you have that aha moment, you know, I think the skepticism will remain. But then when, you know, every once in a while, I think there?s like a result that like really surprises people. And then it?s like, oh, wow, okay, this is actually, I can do something with this. So you just get in their hands, have them try it out, and they?ll be convinced. Yeah, or like maybe once the lab results come back. Or their friends. Yeah, or maybe one of their colleagues is convinced. Yeah. I think it takes going to the lab at some point. There?s no avoiding that, you know, as beautiful as the platform can be, as nice as the molecules might look, you know, that the model predicted. I think what really convinces people is like, you know, hits. Yeah.

Gabriel [01:19:54]: Yeah. You see the results. Exactly. Yeah. Cool. Thank you for, you know, taking the time to chat with us. Yeah. You know, is there anything that you would like your audience to know? I mean, first of all, you know, we?re just getting started, you know, continuing to build a team. And so definitely always looking for great folks, both on the kind of, you know, software side, you know, machine learning side, but also scientists to join the team and help us, you know, shape. On the infrastructure side, too. Indeed. If you think that if you want a new challenge, because this is not just next token prediction, this is really a new engineering challenge. Exactly. Yeah. If you, if no matter, you know, how much experience you have with, you know, biologists and chemistry, if you want to come, you know, help us in a shape, what, you know, biology and chemistry, hopefully we?ll look like in five, 10 years. We?d love to hear from you. And so go to boltz.bio and, you know, come join the team. Cool. Thank you. Awesome. Thank you so much. Thank you.

From Palantir and Two Sigma to building Goodfire into the poster-child for actionable mechanistic interpretability, Mark Bissell (Member of Technical Staff) and Myra Deng (Head of Product) are trying to turn ?peeking inside the model? into a repeatable production workflow by shipping APIs, landing real enterprise deployments, and now scaling the bet with a recent $150M Series B funding round at a $1.25B valuation.

In this episode, we go far beyond the usual ?SAEs are cool? take. We talk about Goodfire?s core bet: that the AI lifecycle is still fundamentally broken because the only reliable control we have is data and we post-train, RLHF, and fine-tune by ?slurping supervision through a straw,? hoping the model picks up the right behaviors while quietly absorbing the wrong ones. Goodfire?s answer is to build a bi-directional interface between humans and models: read what?s happening inside, edit it surgically, and eventually use interpretability during training so customization isn?t just brute-force guesswork.

Mark and Myra walk through what that looks like when you stop treating interpretability like a lab demo and start treating it like infrastructure: lightweight probes that add near-zero latency, token-level safety filters that can run at inference time, and interpretability workflows that survive messy constraints (multilingual inputs, synthetic?real transfer, regulated domains, no access to sensitive data). We also get a live window into what ?frontier-scale interp? means operationally (i.e. steering a trillion-parameter model in real time by targeting internal features) plus why the same tooling generalizes cleanly from language models to genomics, medical imaging, and ?pixel-space? world models.

We discuss:

* Myra + Mark?s path: Palantir (health systems, forward-deployed engineering) ? Goodfire early team; Two Sigma ? Head of Product, translating frontier interpretability research into a platform and real-world deployments

* What ?interpretability? actually means in practice: not just post-hoc poking, but a broader ?science of deep learning? approach across the full AI lifecycle (data curation ? post-training ? internal representations ? model design)

* Why post-training is the first big wedge: ?surgical edits? for unintended behaviors likereward hacking, sycophancy, noise learned during customization plus the dream of targeted unlearning and bias removal without wrecking capabilities

* SAEs vs probes in the real world: why SAE feature spaces sometimes underperform classifiers trained on raw activations for downstream detection tasks (hallucination, harmful intent, PII), and what that implies about ?clean concept spaces?

* Rakuten in production: deploying interpretability-based token-level PII detection at inference time to prevent routing private data to downstream providers plus the gnarly constraints: no training on real customer PII, synthetic?real transfer, English + Japanese, and tokenization quirks

* Why interp can be operationally cheaper than LLM-judge guardrails: probes are lightweight, low-latency, and don?t require hosting a second large model in the loop

* Real-time steering at frontier scale: a demo of steering Kimi K2 (~1T params) live and finding features via SAE pipelines, auto-labeling via LLMs, and toggling a ?Gen-Z slang? feature across multiple layers without breaking tool use

* Hallucinations as an internal signal: the case that models have latent uncertainty / ?user-pleasing? circuitry you can detect and potentially mitigate more directly than black-box methods

* Steering vs prompting: the emerging view that activation steering and in-context learning are more closely connected than people think, including work mapping between the two (even for jailbreak-style behaviors)

* Interpretability for science: using the same tooling across domains (genomics, medical imaging, materials) to debug spurious correlations and extract new knowledge up to and including early biomarker discovery work with major partners

* World models + ?pixel-space? interpretability: why vision/video models make concepts easier to see, how that accelerates the feedback loop, and why robotics/world-model partners are especially interesting design partners

* The north star: moving from ?data in, weights out? to intentional model design where experts can impart goals and constraints directly, not just via reward signals and brute-force post-training

?

Goodfire AI

* Website: https://goodfire.ai

* LinkedIn: https://www.linkedin.com/company/goodfire-ai/

* X: https://x.com/GoodfireAI

Myra Deng

* Website: https://myradeng.com/

* LinkedIn: https://www.linkedin.com/in/myra-deng/

* X: https://x.com/myra_deng

Mark Bissell

* LinkedIn: https://www.linkedin.com/in/mark-bissell/

* X: https://x.com/MarkMBissell

Full Video Episode

Timestamps

00:00:00 Introduction

00:00:05 Introduction to the Latent Space Podcast and Guests from Goodfire

00:00:29 What is Goodfire? Mission and Focus on Interpretability

00:01:01 Goodfire?s Practical Approach to Interpretability

00:01:37 Goodfire?s Series B Fundraise Announcement

00:02:04 Backgrounds of Mark and Myra from Goodfire

00:02:51 Team Structure and Roles at Goodfire

00:05:13 What is Interpretability? Definitions and Techniques

00:05:30 Understanding Errors

00:07:29 Post-training vs. Pre-training Interpretability Applications

00:08:51 Using Interpretability to Remove Unwanted Behaviors

00:10:09 Grokking, Double Descent, and Generalization in Models

00:10:15 404 Not Found Explained

00:12:06 Subliminal Learning and Hidden Biases in Models

00:14:07 How Goodfire Chooses Research Directions and Projects

00:15:00 Troubleshooting Errors

00:16:04 Limitations of SAEs and Probes in Interpretability

00:18:14 Rakuten Case Study: Production Deployment of Interpretability

00:20:45 Conclusion

00:21:12 Efficiency Benefits of Interpretability Techniques

00:21:26 Live Demo: Real-Time Steering in a Trillion Parameter Model

00:25:15 How Steering Features are Identified and Labeled

00:26:51 Detecting and Mitigating Hallucinations Using Interpretability

00:31:20 Equivalence of Activation Steering and Prompting

00:34:06 Comparing Steering with Fine-Tuning and LoRA Techniques

00:36:04 Model Design and the Future of Intentional AI Development

00:38:09 Getting Started in Mechinterp: Resources, Programs, and Open Problems

00:40:51 Industry Applications and the Rise of Mechinterp in Practice

00:41:39 Interpretability for Code Models and Real-World Usage

00:43:07 Making Steering Useful for More Than Stylistic Edits

00:46:17 Applying Interpretability to Healthcare and Scientific Discovery

00:49:15 Why Interpretability is Crucial in High-Stakes Domains like Healthcare

00:52:03 Call for Design Partners Across Domains

00:54:18 Interest in World Models and Visual Interpretability

00:57:22 Sci-Fi Inspiration: Ted Chiang and Interpretability

01:00:14 Interpretability, Safety, and Alignment Perspectives

01:04:27 Weak-to-Strong Generalization and Future Alignment Challenges

01:05:38 Final Thoughts and Hiring/Collaboration Opportunities at Goodfire

Transcript

Shawn Wang [00:00:05]: So welcome to the Latent Space pod. We?re back in the studio with our special MechInterp co-host, Vibhu. Welcome. Mochi, Mochi?s special co-host. And Mochi, the mechanistic interpretability doggo. We have with us Mark and Myra from Goodfire. Welcome. Thanks for having us on. Maybe we can sort of introduce Goodfire and then introduce you guys. How do you introduce Goodfire today?

Myra Deng [00:00:29]: Yeah, it?s a great question. So Goodfire, we like to say, is an AI research lab that focuses on using interpretability to understand, learn from, and design AI models. And we really believe that interpretability will unlock the new generation, next frontier of safe and powerful AI models. That?s our description right now, and I?m excited to dive more into the work we?re doing to make that happen.

Shawn Wang [00:00:55]: Yeah. And there?s always like the official description. Is there an understatement? Is there an unofficial one that sort of resonates more with a different audience?

Mark Bissell [00:01:01]: Well, being an AI research lab that?s focused on interpretability, there?s obviously a lot of people have a lot that they think about when they think of interpretability. And I think we have a pretty broad definition of what that means and the types of places that can be applied. And in particular, applying it in production scenarios, in high stakes industries, and really taking it sort of from the research world into the real world. Which, you know. It?s a new field, so that hasn?t been done all that much. And we?re excited about actually seeing that sort of put into practice.

Shawn Wang [00:01:37]: Yeah, I would say it wasn?t too long ago that Anthopic was like still putting out like toy models or superposition and that kind of stuff. And I wouldn?t have pegged it to be this far along. When you and I talked at NeurIPS, you were talking a little bit about your production use cases and your customers. And then not to bury the lead, today we?re also announcing the fundraise, your Series B. $150 million. $150 million at a 1.25B valuation. Congrats, Unicorn.

Mark Bissell [00:02:02]: Thank you. Yeah, no, things move fast.

Shawn Wang [00:02:04]: We were talking to you in December and already some big updates since then. Let?s dive, I guess, into a bit of your backgrounds as well. Mark, you were at Palantir working on health stuff, which is really interesting because the Goodfire has some interesting like health use cases. I don?t know how related they are in practice.

Mark Bissell [00:02:22]: Yeah, not super related, but I don?t know. It was helpful context to know what it?s like. Just to work. Just to work with health systems and generally in that domain. Yeah.

Shawn Wang [00:02:32]: And Mara, you were at Two Sigma, which actually I was also at Two Sigma back in the day. Wow, nice.

Myra Deng [00:02:37]: Did we overlap at all?

Shawn Wang [00:02:38]: No, this is when I was briefly a software engineer before I became a sort of developer relations person. And now you?re head of product. What are your sort of respective roles, just to introduce people to like what all gets done in Goodfire?

Mark Bissell [00:02:51]: Yeah, prior to Goodfire, I was at Palantir for about three years as a forward deployed engineer, now a hot term. Wasn?t always that way. And as a technical lead on the health care team and at Goodfire, I?m a member of the technical staff. And honestly, that I think is about as specific as like as as I could describe myself because I?ve worked on a range of things. And, you know, it?s it?s a fun time to be at a team that?s still reasonably small. I think when I joined one of the first like ten employees, now we?re above 40, but still, it looks like there?s always a mix of research and engineering and product and all of the above. That needs to get done. And I think everyone across the team is, you know, pretty, pretty switch hitter in the roles they do. So I think you?ve seen some of the stuff that I worked on related to image models, which was sort of like a research demo. More recently, I?ve been working on our scientific discovery team with some of our life sciences partners, but then also building out our core platform for more of like flexing some of the kind of MLE and developer skills as well.

Shawn Wang [00:03:53]: Very generalist. And you also had like a very like a founding engineer type role.

Myra Deng [00:03:58]: Yeah, yeah.

Shawn Wang [00:03:59]: So I also started as I still am a member of technical staff, did a wide range of things from the very beginning, including like finding our office space and all of this, which is we both we both visited when you had that open house thing. It was really nice.

Myra Deng [00:04:13]: Thank you. Thank you. Yeah. Plug to come visit our office.

Shawn Wang [00:04:15]: It looked like it was like 200 people. It has room for 200 people. But you guys are like 10.

Myra Deng [00:04:22]: For a while, it was very empty. But yeah, like like Mark, I spend. A lot of my time as as head of product, I think product is a bit of a weird role these days, but a lot of it is thinking about how do we take our frontier research and really apply it to the most important real world problems and how does that then translate into a platform that?s repeatable or a product and working across, you know, the engineering and research teams to make that happen and also communicating to the world? Like, what is interpretability? What is it used for? What is it good for? Why is it so important? All of these things are part of my day-to-day as well.

Shawn Wang [00:05:01]: I love like what is things because that?s a very crisp like starting point for people like coming to a field. They all do a fun thing. Vibhu, why don?t you want to try tackling what is interpretability and then they can correct us.

Vibhu Sapra [00:05:13]: Okay, great. So I think like one, just to kick off, it?s a very interesting role to be head of product, right? Because you guys, at least as a lab, you?re more of an applied interp lab, right? Which is pretty different than just normal interp, like a lot of background research. But yeah. You guys actually ship an API to try these things. You have Ember, you have products around it, which not many do. Okay. What is interp? So basically you?re trying to have an understanding of what?s going on in model, like in the model, in the internal. So different approaches to do that. You can do probing, SAEs, transcoders, all this stuff. But basically you have an, you have a hypothesis. You have something that you want to learn about what?s happening in a model internals. And then you?re trying to solve that from there. You can do stuff like you can, you know, you can do activation mapping. You can try to do steering. There?s a lot of stuff that you can do, but the key question is, you know, from input to output, we want to have a better understanding of what?s happening and, you know, how can we, how can we adjust what?s happening on the model internals? How?d I do?

Mark Bissell [00:06:12]: That was really good. I think that was great. I think it?s also a, it?s kind of a minefield of a, if you ask 50 people who quote unquote work in interp, like what is interpretability, you?ll probably get 50 different answers. And. Yeah. To some extent also like where, where good fire sits in the space. I think that we?re an AI research company above all else. And interpretability is a, is a set of methods that we think are really useful and worth kind of specializing in, in order to accomplish the goals we want to accomplish. But I think we also sort of see some of the goals as even more broader as, as almost like the science of deep learning and just taking a not black box approach to kind of any part of the like AI development life cycle, whether that. That means using interp for like data curation while you?re training your model or for understanding what happened during post-training or for the, you know, understanding activations and sort of internal representations, what is in there semantically. And then a lot of sort of exciting updates that were, you know, are sort of also part of the, the fundraise around bringing interpretability to training, which I don?t think has been done all that much before. A lot of this stuff is sort of post-talk poking at models as opposed to. To actually using this to intentionally design them.

Shawn Wang [00:07:29]: Is this post-training or pre-training or is that not a useful.

Myra Deng [00:07:33]: Currently focused on post-training, but there?s no reason the techniques wouldn?t also work in pre-training.

Shawn Wang [00:07:38]: Yeah. It seems like it would be more active, applicable post-training because basically I?m thinking like rollouts or like, you know, having different variations of a model that you can tweak with the, with your steering. Yeah.

Myra Deng [00:07:50]: And I think in a lot of the news that you?ve seen in, in, on like Twitter or whatever, you?ve seen a lot of unintended. Side effects come out of post-training processes, you know, overly sycophantic models or models that exhibit strange reward hacking behavior. I think these are like extreme examples. There?s also, you know, very, uh, mundane, more mundane, like enterprise use cases where, you know, they try to customize or post-train a model to do something and it learns some noise or it doesn?t appropriately learn the target task. And a big question that we?ve always had is like, how do you use your understanding of what the model knows and what it?s doing to actually guide the learning process?

Shawn Wang [00:08:26]: Yeah, I mean, uh, you know, just to anchor this for people, uh, one of the biggest controversies of last year was 4.0 GlazeGate. I?ve never heard of GlazeGate. I didn?t know that was what it was called. The other one, they called it that on the blog post and I was like, well, how did OpenAI call it? Like officially use that term. And I?m like, that?s funny, but like, yeah, I guess it?s the pitch that if they had worked a good fire, they wouldn?t have avoided it. Like, you know what I?m saying?

Myra Deng [00:08:51]: I think so. Yeah. Yeah.

Mark Bissell [00:08:53]: I think that?s certainly one of the use cases. I think. Yeah. Yeah. I think the reason why post-training is a place where this makes a lot of sense is a lot of what we?re talking about is surgical edits. You know, you want to be able to have expert feedback, very surgically change how your model is doing, whether that is, you know, removing a certain behavior that it has. So, you know, one of the things that we?ve been looking at or is, is another like common area where you would want to make a somewhat surgical edit is some of the models that have say political bias. Like you look at Quen or, um, R1 and they have sort of like this CCP bias.

Shawn Wang [00:09:27]: Is there a CCP vector?

Mark Bissell [00:09:29]: Well, there?s, there are certainly internal, yeah. Parts of the representation space where you can sort of see where that lives. Yeah. Um, and you want to kind of, you know, extract that piece out.

Shawn Wang [00:09:40]: Well, I always say, you know, whenever you find a vector, a fun exercise is just like, make it very negative to see what the opposite of CCP is.

Mark Bissell [00:09:47]: The super America, bald eagles flying everywhere. But yeah. So in general, like lots of post-training tasks where you?d want to be able to, to do that. Whether it?s unlearning a certain behavior or, you know, some of the other kind of cases where this comes up is, are you familiar with like the, the grokking behavior? I mean, I know the machine learning term of grokking.

Shawn Wang [00:10:09]: Yeah.

Mark Bissell [00:10:09]: Sort of this like double descent idea of, of having a model that is able to learn a generalizing, a generalizing solution, as opposed to even if memorization of some task would suffice, you want it to learn the more general way of doing a thing. And so, you know, another. A way that you can think about having surgical access to a model?s internals would be learn from this data, but learn in the right way. If there are many possible, you know, ways to, to do that. Can make interp solve the double descent problem?

Shawn Wang [00:10:41]: Depends, I guess, on how you. Okay. So I, I, I viewed that double descent as a problem because then you?re like, well, if the loss curves level out, then you?re done, but maybe you?re not done. Right. Right. But like, if you actually can interpret what is a generalizing or what you?re doing. What is, what is still changing, even though the loss is not changing, then maybe you, you can actually not view it as a double descent problem. And actually you?re just sort of translating the space in which you view loss and like, and then you have a smooth curve. Yeah.

Mark Bissell [00:11:11]: I think that?s certainly like the domain of, of problems that we?re, that we?re looking to get.

Shawn Wang [00:11:15]: Yeah. To me, like double descent is like the biggest thing to like ML research where like, if you believe in scaling, then you don?t need, you need to know where to scale. And. But if you believe in double descent, then you don?t, you don?t believe in anything where like anything levels off, like.

Vibhu Sapra [00:11:30]: I mean, also tendentially there?s like, okay, when you talk about the China vector, right. There?s the subliminal learning work. It was from the anthropic fellows program where basically you can have hidden biases in a model. And as you distill down or, you know, as you train on distilled data, those biases always show up, even if like you explicitly try to not train on them. So, you know, it?s just like another use case of. Okay. If we can interpret what?s happening in post-training, you know, can we clear some of this? Can we even determine what?s there? Because yeah, it?s just like some worrying research that?s out there that shows, you know, we really don?t know what?s going on.

Mark Bissell [00:12:06]: That is. Yeah. I think that?s the biggest sentiment that we?re sort of hoping to tackle. Nobody knows what?s going on. Right. Like subliminal learning is just an insane concept when you think about it. Right. Train a model on not even the logits, literally the output text of a bunch of random numbers. And now your model loves owls. And you see behaviors like that, that are just, they defy, they defy intuition. And, and there are mathematical explanations that you can get into, but. I mean.

Shawn Wang [00:12:34]: It feels so early days. Objectively, there are a sequence of numbers that are more owl-like than others. There, there should be.

Mark Bissell [00:12:40]: According to, according to certain models. Right. It?s interesting. I think it only applies to models that were initialized from the same starting Z. Usually, yes.

Shawn Wang [00:12:49]: But I mean, I think that?s a, that?s a cheat code because there?s not enough compute. But like if you believe in like platonic representation, like probably it will transfer across different models as well. Oh, you think so?

Mark Bissell [00:13:00]: I think of it more as a statistical artifact of models initialized from the same seed sort of. There?s something that is like path dependent from that seed that might cause certain overlaps in the latent space and then sort of doing this distillation. Yeah. Like it pushes it towards having certain other tendencies.

Vibhu Sapra [00:13:24]: Got it. I think there?s like a bunch of these open-ended questions, right? Like you can?t train in new stuff during the RL phase, right? RL only reorganizes weights and you can only do stuff that?s somewhat there in your base model. You?re not learning new stuff. You?re just reordering chains and stuff. But okay. My broader question is when you guys work at an interp lab, how do you decide what to work on and what?s kind of the thought process? Right. Because we can ramble for hours. Okay. I want to know this. I want to know that. But like, how do you concretely like, you know, what?s the workflow? Okay. There?s like approaches towards solving a problem, right? I can try prompting. I can look at chain of thought. I can train probes, SAEs. But how do you determine, you know, like, okay, is this going anywhere? Like, do we have set stuff? Just, you know, if you can help me with all that. Yeah.

Myra Deng [00:14:07]: It?s a really good question. I feel like we?ve always at the very beginning of the company thought about like, let?s go and try to learn what isn?t working in machine learning today. Whether that?s talking to customers or talking to researchers at other labs, trying to understand both where the frontier is going and where things are really not falling apart today. And then developing a perspective on how we can push the frontier using interpretability methods. And so, you know, even our chief scientist, Tom, spends a lot of time talking to customers and trying to understand what real world problems are and then taking that back and trying to apply the current state of the art to those problems and then seeing where they fall down basically. And then using those failures or those shortcomings to understand what hills to climb when it comes to interpretability research. So like on the fundamental side, for instance, when we have done some work applying SAEs and probes, we?ve encountered, you know, some shortcomings in SAEs that we found a little bit surprising. And so have gone back to the drawing board and done work on that. And then, you know, we?ve done some work on better foundational interpreter models. And a lot of our team?s research is focused on what is the next evolution beyond SAEs, for instance. And then when it comes to like control and design of models, you know, we tried steering with our first API and realized that it still fell short of black box techniques like prompting or fine tuning. And so went back to the drawing board and we?re like, how do we make that not the case and how do we improve it beyond that? And one of our researchers, Ekdeep, who just joined is actually Ekdeep and Atticus are like steering experts and have spent a lot of time trying to figure out like, what is the research that enables us to actually do this in a much more powerful, robust way? So yeah, the answer is like, look at real world problems, try to translate that into a research agenda and then like hill climb on both of those at the same time.

Shawn Wang [00:16:04]: Yeah. Mark has the steering CLI demo queued up, which we?re going to go into in a sec. But I always want to double click on when you drop hints, like we found some problems with SAEs. Okay. What are they? You know, and then we can go into the demo. Yeah.

Myra Deng [00:16:19]: I mean, I?m curious if you have more thoughts here as well, because you?ve done it in the healthcare domain. But I think like, for instance, when we do things like trying to detect behaviors within models that are harmful or like behaviors that a user might not want to have in their model. So hallucinations, for instance, harmful intent, PII, all of these things. We first tried using SAE probes for a lot of these tasks. So taking the feature activation space from SAEs and then training classifiers on top of that, and then seeing how well we can detect the properties that we might want to detect in model behavior. And we?ve seen in many cases that probes just trained on raw activations seem to perform better than SAE probes, which is a bit surprising if you think that SAEs are actually also capturing the concepts that you would want to capture cleanly and more surgically. And so that is an interesting observation. I don?t think that is like, I?m not down on SAEs at all. I think there are many, many things they?re useful for, but we have definitely run into cases where I think the concept space described by SAEs is not as clean and accurate as we would expect it to be for actual like real world downstream performance metrics.

Mark Bissell [00:17:34]: Fair enough. Yeah. It?s the blessing and the curse of unsupervised methods where you get to peek into the AI?s mind. But sometimes you wish that you saw other things when you walked inside there. Although in the PII instance, I think weren?t an SAE based approach actually did prove to be the most generalizable?

Myra Deng [00:17:53]: It did work well in the case that we published with Rakuten. And I think a lot of the reasons it worked well was because we had a noisier data set. And so actually the blessing of unsupervised learning is that we actually got to get more meaningful, generalizable signal from SAEs when the data was noisy. But in other cases where we?ve had like good data sets, it hasn?t been the case.

Shawn Wang [00:18:14]: And just because you named Rakuten and I don?t know if we?ll get it another chance, like what is the overall, like what is Rakuten?s usage or production usage? Yeah.

Myra Deng [00:18:25]: So they are using us to essentially guardrail and inference time monitor their language model usage and their agent usage to detect things like PII so that they don?t route private user information.

Myra Deng [00:18:41]: And so that?s, you know, going through all of their user queries every day. And that?s something that we deployed with them a few months ago. And now we are actually exploring very early partnerships, not just with Rakuten, but with other people around how we can help with potentially training and customization use cases as well. Yeah.

Shawn Wang [00:19:03]: And for those who don?t know, like it?s Rakuten is like, I think number one or number two e-commerce store in Japan. Yes. Yeah.

Mark Bissell [00:19:10]: And I think that use case actually highlights a lot of like what it looks like to deploy things in practice that you don?t always think about when you?re doing sort of research tasks. So when you think about some of the stuff that came up there that?s more complex than your idealized version of a problem, they were encountering things like synthetic to real transfer of methods. So they couldn?t train probes, classifiers, things like that on actual customer data of PII. So what they had to do is use synthetic data sets. And then hope that that transfer is out of domain to real data sets. And so we can evaluate performance on the real data sets, but not train on customer PII. So that right off the bat is like a big challenge. You have multilingual requirements. So this needed to work for both English and Japanese text. Japanese text has all sorts of quirks, including tokenization behaviors that caused lots of bugs that caused us to be pulling our hair out. And then also a lot of tasks you?ll see. You might make simplifying assumptions if you?re sort of treating it as like the easiest version of the problem to just sort of get like general results where maybe you say you?re classifying a sentence to say, does this contain PII? But the need that Rakuten had was token level classification so that you could precisely scrub out the PII. So as we learned more about the problem, you?re sort of speaking about what that looks like in practice. Yeah. A lot of assumptions end up breaking. And that was just one instance where you. A problem that seems simple right off the bat ends up being more complex as you keep diving into it.

Vibhu Sapra [00:20:41]: Excellent. One of the things that?s also interesting with Interp is a lot of these methods are very efficient, right? So where you?re just looking at a model?s internals itself compared to a separate like guardrail, LLM as a judge, a separate model. One, you have to host it. Two, there?s like a whole latency. So if you use like a big model, you have a second call. Some of the work around like self detection of hallucination, it?s also deployed for efficiency, right? So if you have someone like Rakuten doing it in production live, you know, that?s just another thing people should consider.

Mark Bissell [00:21:12]: Yeah. And something like a probe is super lightweight. Yeah. It?s no extra latency really. Excellent.

Shawn Wang [00:21:17]: You have the steering demos lined up. So we were just kind of see what you got. I don?t, I don?t actually know if this is like the latest, latest or like alpha thing.

Mark Bissell [00:21:26]: No, this is a pretty hacky demo from from a presentation that someone else on the team recently gave. So this will give a sense for, for technology. So you can see the steering and action. Honestly, I think the biggest thing that this highlights is that as we?ve been growing as a company and taking on kind of more and more ambitious versions of interpretability related problems, a lot of that comes to scaling up in various different forms. And so here you?re going to see steering on a 1 trillion parameter model. This is Kimi K2. And so it?s sort of fun that in addition to the research challenges, there are engineering challenges that we?re now tackling. Cause for any of this to be sort of useful in production, you need to be thinking about what it looks like when you?re using these methods on frontier models as opposed to sort of like toy kind of model organisms. So yeah, this was thrown together hastily, pretty fragile behind the scenes, but I think it?s quite a fun demo. So screen sharing is on. So I?ve got two terminal sessions pulled up here. On the left is a forked version that we have of the Kimi CLI that we?ve got running to point at our custom hosted Kimi model. And then on the right is a set up that will allow us to steer on certain concepts. So I should be able to chat with Kimi over here. Tell it hello. This is running locally. So the CLI is running locally, but the Kimi server is running back to the office. Well, hopefully should be, um, that?s too much to run on that Mac. Yeah. I think it?s, uh, it takes a full, like each 100 node. I think it?s like, you can. You can run it on eight GPUs, eight 100. So, so yeah, Kimi?s running. We can ask it a prompt. It?s got a forked version of our, uh, of the SG line code base that we?ve been working on. So I?m going to tell it, Hey, this SG line code base is slow. I think there?s a bug. Can you try to figure it out? There?s a big code base, so it?ll, it?ll spend some time doing this. And then on the right here, I?m going to initialize in real time. Some steering. Let?s see here.

Mark Bissell [00:23:33]: searching for any. Bugs. Feature ID 43205.

Shawn Wang [00:23:38]: Yeah.

Mark Bissell [00:23:38]: 20, 30, 40. So let me, uh, this is basically a feature that we found that inside Kimi seems to cause it to speak in Gen Z slang. And so on the left, it?s still sort of thinking normally it might take, I don?t know, 15 seconds for this to kick in, but then we?re going to start hopefully seeing him do this code base is massive for real. So we?re going to start. We?re going to start seeing Kimi transition as the steering kicks in from normal Kimi to Gen Z Kimi and both in its chain of thought and its actual outputs.

Mark Bissell [00:24:19]: And interestingly, you can see, you know, it?s still able to call tools, uh, and stuff. It?s um, it?s purely sort of it?s it?s demeanor. And there are other features that we found for interesting things like concision. So that?s more of a practical one. You can make it more concise. Um, the types of programs, uh, programming languages that uses, but yeah, as we?re seeing it come in. Pretty good. Outputs.

Shawn Wang [00:24:43]: Scheduler code is actually wild.

Vibhu Sapra [00:24:46]: Yo, this code is actually insane, bro.

Vibhu Sapra [00:24:53]: What?s the process of training in SAE on this, or, you know, how do you label features? I know you guys put out a pretty cool blog post about, um, finding this like autonomous interp. Um, something. Something about how agents for interp is different than like coding agents. I don?t know while this is spewing up, but how, how do we find feature 43, two Oh five. Yeah.

Mark Bissell [00:25:15]: So in this case, um, we, our platform that we?ve been building out for a long time now supports all the sort of classic out of the box interp techniques that you might want to have like SAE training, probing things of that kind, I?d say the techniques for like vanilla SAEs are pretty well established now where. You take your model that you?re interpreting, run a whole bunch of data through it, gather activations, and then yeah, pretty straightforward pipeline to train an SAE. There are a lot of different varieties. There?s top KSAEs, batch top KSAEs, um, normal ReLU SAEs. And then once you have your sparse features to your point, assigning labels to them to actually understand that this is a gen Z feature, that?s actually where a lot of the kind of magic happens. Yeah. And the most basic standard technique is look at all of your d input data set examples that cause this feature to fire most highly. And then you can usually pick out a pattern. So for this feature, If I?ve run a diverse enough data set through my model feature 43, two Oh five. Probably tends to fire on all the tokens that sounds like gen Z slang. You know, that?s the, that?s the time of year to be like, Oh, I?m in this, I?m in this Um, and, um, so, you know, you could have a human go through all 43,000 concepts and

Vibhu Sapra [00:26:34]: And I?ve got to ask the basic question, you know, can we get examples where it hallucinates, pass it through, see what feature activates for hallucinations? Can I just, you know, turn hallucination down?

Myra Deng [00:26:51]: Oh, wow. You really predicted a project we?re already working on right now, which is detecting hallucinations using interpretability techniques. And this is interesting because hallucinations is something that?s very hard to detect. And it?s like a kind of a hairy problem and something that black box methods really struggle with. Whereas like Gen Z, you could always train a simple classifier to detect that hallucinations is harder. But we?ve seen that models internally have some... Awareness of like uncertainty or some sort of like user pleasing behavior that leads to hallucinatory behavior. And so, yeah, we have a project that?s trying to detect that accurately. And then also working on mitigating the hallucinatory behavior in the model itself as well.

Shawn Wang [00:27:39]: Yeah, I would say most people are still at the level of like, oh, I would just turn temperature to zero and that turns off hallucination. And I?m like, well, that?s a fundamental misunderstanding of how this works. Yeah.

Mark Bissell [00:27:51]: Although, so part of what I like about that question is you, there are SAE based approaches that might like help you get at that. But oftentimes the beauty of SAEs and like we said, the curse is that they?re unsupervised. So when you have a behavior that you deliberately would like to remove, and that?s more of like a supervised task, often it is better to use something like probes and specifically target the thing that you?re interested in reducing as opposed to sort of like hoping that when you fragment the latent space, one of the vectors that pops out.

Vibhu Sapra [00:28:20]: And as much as we?re training an autoencoder to be sparse, we?re not like for sure certain that, you know, we will get something that just correlates to hallucination. You?ll probably split that up into 20 other things and who knows what they?ll be.

Mark Bissell [00:28:36]: Of course. Right. Yeah. So there?s no sort of problems with like feature splitting and feature absorption. And then there?s the off target effects, right? Ideally, you would want to be very precise where if you reduce the hallucination feature, suddenly maybe your model can?t write. Creatively anymore. And maybe you don?t like that, but you want to still stop it from hallucinating facts and figures.

Shawn Wang [00:28:55]: Good. So Vibhu has a paper to recommend there that we?ll put in the show notes. But yeah, I mean, I guess just because your demo is done, any any other things that you want to highlight or any other interesting features you want to show?

Mark Bissell [00:29:07]: I don?t think so. Yeah. Like I said, this is a pretty small snippet. I think the main sort of point here that I think is exciting is that there?s not a whole lot of inter being applied to models quite at this scale. You know, Anthropic certainly has some some. Research and yeah, other other teams as well. But it?s it?s nice to see these techniques, you know, being put into practice. I think not that long ago, the idea of real time steering of a trillion parameter model would have sounded.

Shawn Wang [00:29:33]: Yeah. The fact that it?s real time, like you started the thing and then you edited the steering vector.

Vibhu Sapra [00:29:38]: I think it?s it?s an interesting one TBD of what the actual like production use case would be on that, like the real time editing. It?s like that?s the fun part of the demo, right? You can kind of see how this could be served behind an API, right? Like, yes, you?re you only have so many knobs and you can just tweak it a bit more. And I don?t know how it plays in. Like people haven?t done that much with like, how does this work with or without prompting? Right. How does this work with fine tuning? Like, there?s a whole hype of continual learning, right? So there?s just so much to see. Like, is this another parameter? Like, is it like parameter? We just kind of leave it as a default. We don?t use it. So I don?t know. Maybe someone here wants to put out a guide on like how to use this with prompting when to do what?

Mark Bissell [00:30:18]: Oh, well, I have a paper recommendation. I think you would love from Act Deep on our team, who is an amazing researcher, just can?t say enough amazing things about Act Deep. But he actually has a paper that as well as some others from the team and elsewhere that go into the essentially equivalence of activation steering and in context learning and how those are from a he thinks of everything in a cognitive neuroscience Bayesian framework, but basically how you can precisely show how. Prompting in context, learning and steering exhibit similar behaviors and even like get quantitative about the like magnitude of steering you would need to do to induce a certain amount of behavior similar to certain prompting, even for things like jailbreaks and stuff. It?s a really cool paper. Are you saying steering is less powerful than prompting? More like you can almost write a formula that tells you how to convert between the two of them.

Myra Deng [00:31:20]: And so like formally equivalent actually in the in the limit. Right.

Mark Bissell [00:31:24]: So like one case study of this is for jailbreaks there. I don?t know. Have you seen the stuff where you can do like many shot jailbreaking? You like flood the context with examples of the behavior. And the topic put out that paper.

Shawn Wang [00:31:38]: A lot of people were like, yeah, we?ve been doing this, guys.

Mark Bissell [00:31:40]: Like, yeah, what?s in this in context learning and activation steering equivalence paper is you can like predict the number. Number of examples that you will need to put in there in order to jailbreak the model. That?s cool. By doing steering experiments and using this sort of like equivalence mapping. That?s cool. That?s really cool. It?s very neat. Yeah.

Shawn Wang [00:32:02]: I was going to say, like, you know, I can like back rationalize that this makes sense because, you know, what context is, is basically just, you know, it updates the KV cache kind of and like and then every next token inference is still like, you know, the sheer sum of everything all the way. It?s plus all the context. It?s up to date. And you could, I guess, theoretically steer that with you probably replace that with your steering. The only problem is steering typically is on one layer, maybe three layers like like you did. So it?s like not exactly equivalent.

Mark Bissell [00:32:33]: Right, right. There?s sort of you need to get precise about, yeah, like how you sort of define steering and like what how you?re modeling the setup. But yeah, I?ve got the paper pulled up here. Belief dynamics reveal the dual nature. Yeah. The title is Belief Dynamics Reveal the Dual Nature of Incompetence. And it?s an exhibition of the practical context learning and activation steering. So Eric Bigelow, Dan Urgraft on the who are doing fellowships at Goodfire, Ekt Deep?s the final author there.

Myra Deng [00:32:59]: I think actually to your question of like, what is the production use case of steering? I think maybe if you just think like one level beyond steering as it is today. Like imagine if you could adapt your model to be, you know, an expert legal reasoner. Like in almost real time, like very quickly. efficiently using human feedback or using like your semantic understanding of what the model knows and where it knows that behavior. I think that while it?s not clear what the product is at the end of the day, it?s clearly very valuable. Thinking about like what?s the next interface for model customization and adaptation is a really interesting problem for us. Like we have heard a lot of people actually interested in fine-tuning an RL for open weight models in production. And so people are using things like Tinker or kind of like open source libraries to do that, but it?s still very difficult to get models fine-tuned and RL?d for exactly what you want them to do unless you?re an expert at model training. And so that?s like something we?re

Shawn Wang [00:34:06]: looking into. Yeah. I never thought so. Tinker from Thinking Machines famously uses rank one LoRa. Is that basically the same as steering? Like, you know, what?s the comparison there?

Mark Bissell [00:34:19]: Well, so in that case, you are still applying updates to the parameters, right?

Shawn Wang [00:34:25]: Yeah. You?re not touching a base model. You?re touching an adapter. It?s kind of, yeah.

Mark Bissell [00:34:30]: Right. But I guess it still is like more in parameter space then. I guess it?s maybe like, are you modifying the pipes or are you modifying the water flowing through the pipes to get what you?re after? Yeah. Just maybe one way.

Mark Bissell [00:34:44]: I like that analogy. That?s my mental map of it at least, but it gets at this idea of model design and intentional design, which is something that we?re, that we?re very focused on. And just the fact that like, I hope that we look back at how we?re currently training models and post-training models and just think what a primitive way of doing that right now. Like there?s no intentionality

Shawn Wang [00:35:06]: really in... It?s just data, right? The only thing in control is what data we feed in.

Mark Bissell [00:35:11]: So, so Dan from Goodfire likes to use this analogy of, you know, he has a couple of young kids and he talks about like, what if I could only teach my kids how to be good people by giving them cookies or like, you know, giving them a slap on the wrist if they do something wrong, like not telling them why it was wrong or like what they should have done differently or something like that. Just figure it out. Right. Exactly. So that?s RL. Yeah. Right. And, and, you know, it?s sample inefficient. There?s, you know, what do they say? It?s like slurping feedback. It?s like, slurping supervision. Right. And so you?d like to get to the point where you can have experts giving feedback to their models that are, uh, internalized and, and, you know, steering is an inference time way of sort of getting that idea. But ideally you?re moving to a world where

Vibhu Sapra [00:36:04]: it is much more intentional design in perpetuity for these models. Okay. This is one of the questions we asked Emmanuel from Anthropic on the podcast a few months ago. Basically the question, was you?re at a research lab that does model training, foundation models, and you?re on an interp team. How does it tie back? Right? Like, does this, do ideas come from the pre-training team? Do they go back? Um, you know, so for those interested, you can, you can watch that. There wasn?t too much of a connect there, but it?s still something, you know, it?s something they want to

Mark Bissell [00:36:33]: push for down the line. It can be useful for all of the above. Like there are certainly post-hoc

Vibhu Sapra [00:36:39]: use cases where it doesn?t need to touch that. I think the other thing a lot of people forget is this stuff isn?t too computationally expensive, right? Like I would say, if you?re interested in getting into research, MechInterp is one of the most approachable fields, right? A lot of this train an essay, train a probe, this stuff, like the budget for this one, there?s already a lot done. There?s a lot of open source work. You guys have done some too. Um, you know,

Shawn Wang [00:37:04]: There?s like notebooks from the Gemini team for Neil Nanda or like, this is how you do it. Just step through the notebook.

Vibhu Sapra [00:37:09]: Even if you?re like, not even technical with any of this, you can still make like progress. There, you can look at different activations, but, uh, if you do want to get into training, you know, training this stuff, correct me if I?m wrong is like in the thousands of dollars, not even like, it?s not that high scale. And then same with like, you know, applying it, doing it for post-training or all this stuff is fairly cheap in scale of, okay. I want to get into like model training. I don?t have compute for like, you know, pre-training stuff. So it?s, it?s a very nice field to get into. And also there?s a lot of like open questions, right? Um, some of them have to go with, okay, I want a product. I want to solve this. Like there?s also just a lot of open-ended stuff that people could work on. That?s interesting. Right. I don?t know if you guys have any calls for like, what?s open questions, what?s open work that you either open collaboration with, or like, you?d just like to see solved or just, you know, for people listening that want to get into McInturk because people always talk about it. What are, what are the things they should check out? Start, of course, you know, join you guys as well. I?m sure you?re hiring.

Myra Deng [00:38:09]: There?s a paper, I think from, was it Lee, uh, Sharky? It?s open problems and, uh, it?s, it?s a bit of interpretability, which I recommend everyone who?s interested in the field. Read. I?m just like a really comprehensive overview of what are the things that experts in the field think are the most important problems to be solved. I also think to your point, it?s been really, really inspiring to see, I think a lot of young people getting interested in interpretability, actually not just young people also like scientists to have been, you know, experts in physics for many years and in biology or things like this, um, transitioning into interp, because the barrier of, of what?s now interp. So it?s really cool to see a number to entry is, you know, in some ways low and there?s a lot of information out there and ways to get started. There?s this anecdote of like professors at universities saying that all of a sudden every incoming PhD student wants to study interpretability, which was not the case a few years ago. So it just goes to show how, I guess, like exciting the field is, how fast it?s moving, how quick it is to get started and things like that.

Mark Bissell [00:39:10]: And also just a very welcoming community. You know, there?s an open source McInturk Slack channel. There are people are always posting questions and just folks in the space are always responsive if you ask things on various forums and stuff. But yeah, the open paper, open problems paper is a really good one.

Myra Deng [00:39:28]: For other people who want to get started, I think, you know, MATS is a great program. What?s the acronym for? Machine Learning and Alignment Theory Scholars? It?s like the...

Vibhu Sapra [00:39:40]: Normally summer internship style.

Myra Deng [00:39:42]: Yeah, but they?ve been doing it year round now. And actually a lot of our full-time staff have come through that program or gone through that program. And it?s great for anyone who is transitioning into interpretability. There?s a couple other fellows programs. We do one as well as Anthropic. And so those are great places to get started if anyone is interested.

Mark Bissell [00:40:03]: Also, I think been seen as a research field for a very long time. But I think engineering... I think engineers are sorely wanted for interpretability as well, especially at Goodfire, but elsewhere, as it does scale up.

Shawn Wang [00:40:18]: I should mention that Lee actually works with you guys, right? And in the London office and I?m adding our first ever McInturk track at AI Europe because I see this industry applications now emerging. And I?m pretty excited to, you know, help push that along. Yeah, I was looking forward to that. It?ll effectively be the first industry McInturk conference. Yeah. I?m so glad you added that. You know, it?s still a little bit of a bet. It?s not that widespread, but I can definitely see this is the time to really get into it. We want to be early on things.

Mark Bissell [00:40:51]: For sure. And I think the field understands this, right? So at ICML, I think the title of the McInturk workshop this year was actionable interpretability. And there was a lot of discussion around bringing it to various domains. Everyone?s adding pragmatic, actionable, whatever.

Shawn Wang [00:41:10]: It?s like, okay, well, we weren?t actionable before, I guess. I don?t know.

Vibhu Sapra [00:41:13]: And I mean, like, just, you know, being in Europe, you see the Interp room. One, like old school conferences, like, I think they had a very tiny room till they got lucky and they got it doubled. But there?s definitely a lot of interest, a lot of niche research. So you see a lot of research coming out of universities, students. We covered the paper last week. It?s like two unknown authors, not many citations. But, you know, you can make a lot of meaningful work there. Yeah. Yeah. Yeah.

Shawn Wang [00:41:39]: Yeah. I think people haven?t really mentioned this yet. It?s just Interp for code. I think it?s like an abnormally important field. We haven?t mentioned this yet. The conspiracy theory last two years ago was when the first SAE work came out of Anthropic was they would do like, oh, we just used SAEs to turn the bad code vector down and then turn up the good code. And I think like, isn?t that the dream? Like, you know, like, but basically, I guess maybe, why is it funny? Like, it?s... If it was realistic, it would not be funny. It would be like, no, actually, we should do this. But it?s funny because we know there?s like, we feel there?s some limitations to what steering can do. And I think a lot of the public image of steering is like the Gen Z stuff. Like, oh, you can make it really love the Golden Gate Bridge, or you can make it speak like Gen Z. To like be a legal reasoner seems like a huge stretch. Yeah. And I don?t know if that will get there this way. Yeah.

Myra Deng [00:42:36]: I think, um, I will say we are announcing. Something very soon that I will not speak too much about. Um, but I think, yeah, this is like what we?ve run into again and again is like, we, we don?t want to be in the world where steering is only useful for like stylistic things. That?s definitely not, not what we?re aiming for. But I think the types of interventions that you need to do to get to things like legal reasoning, um, are much more sophisticated and require breakthroughs in, in learning algorithms. And that?s, um...

Shawn Wang [00:43:07]: And is this an emergent property of scale as well?

Myra Deng [00:43:10]: I think so. Yeah. I mean, I think scale definitely helps. I think scale allows you to learn a lot of information and, and reduce noise across, you know, large amounts of data. But I also think we think that there?s ways to do things much more effectively, um, even, even at scale. So like actually learning exactly what you want from the data and not learning things that you do that you don?t want exhibited in the data. So we?re not like anti-scale, but we are also realizing that scale is not going to get us anywhere. It?s not going to get us to the type of AI development that we want to be at in, in the future as these models get more powerful and get deployed in all these sorts of like mission critical contexts. Current life cycle of training and deploying and evaluations is, is to us like deeply broken and has opportunities to, to improve. So, um, more to come on that very, very soon.

Mark Bissell [00:44:02]: And I think that that?s a use basically, or maybe just like a proof point that these concepts do exist. Like if you can manipulate them in the precise best way, you can get the ideal combination of them that you desire. And steering is maybe the most coarse grained sort of peek at what that looks like. But I think it?s evocative of what you could do if you had total surgical control over every concept, every parameter. Yeah, exactly.

Myra Deng [00:44:30]: There were like bad code features. I?ve got it pulled up.

Vibhu Sapra [00:44:33]: Yeah. Just coincidentally, as you guys are talking.

Shawn Wang [00:44:35]: This is like, this is exactly.

Vibhu Sapra [00:44:38]: There?s like specifically a code error feature that activates and they show, you know, it?s not, it?s not typo detection. It?s like, it?s, it?s typos in code. It?s not typical typos. And, you know, you can, you can see it clearly activates where there?s something wrong in code. And they have like malicious code, code error. They have a whole bunch of sub, you know, sub broken down little grain features. Yeah.

Shawn Wang [00:45:02]: Yeah. So, so the, the rough intuition for me, the, why I talked about post-training was that, well, you just, you know, have a few different rollouts with all these things turned off and on and whatever. And then, you know, you can, that?s, that?s synthetic data you can kind of post-train on. Yeah.

Vibhu Sapra [00:45:13]: And I think we make it sound easier than it is just saying, you know, they do the real hard work.

Myra Deng [00:45:19]: I mean, you guys, you guys have the right idea. Exactly. Yeah. We replicated a lot of these features in, in our Lama models as well. I remember there was like.

Vibhu Sapra [00:45:26]: And I think a lot of this stuff is open, right? Like, yeah, you guys opened yours. DeepMind has opened a lot of essays on Gemma. Even Anthropic has opened a lot of this. There?s, there?s a lot of resources that, you know, we can probably share of people that want to get involved.

Shawn Wang [00:45:41]: Yeah. And special shout out to like Neuronpedia as well. Yes. Like, yeah, amazing piece of work to visualize those things.

Myra Deng [00:45:49]: Yeah, exactly.

Shawn Wang [00:45:50]: I guess I wanted to pivot a little bit on, onto the healthcare side, because I think that?s a big use case for you guys. We haven?t really talked about it yet. This is a bit of a crossover for me because we are, we are, we do have a separate science pod that we?re starting up for AI, for AI for science, just because like, it?s such a huge investment category and also I?m like less qualified to do it, but we actually have bio PhDs to cover that, which is great, but I need to just kind of recover, recap your work, maybe on the evil two stuff, but then, and then building forward.

Mark Bissell [00:46:17]: Yeah, for sure. And maybe to frame up the conversation, I think another kind of interesting just lens on interpretability in general is a lot of the techniques that were described. are ways to solve the AI human interface problem. And it?s sort of like bidirectional communication is the goal there. So what we?ve been talking about with intentional design of models and, you know, steering, but also more advanced techniques is having humans impart our desires and control into models and over models. And the reverse is also very interesting, especially as you get to superhuman models, whether that?s narrow superintelligence, like these scientific models that work on genomics, data, medical imaging, things like that. But down the line, you know, superintelligence of other forms as well. What knowledge can the AIs teach us as sort of that, that the other direction in that? And so some of our life science work to date has been getting at exactly that question, which is, well, some of it does look like debugging these various life sciences models, understanding if they?re actually performing well, on tasks, or if they?re picking up on spurious correlations, for instance, genomics models, you would like to know whether they are sort of focusing on the biologically relevant things that you care about, or if it?s using some simpler correlate, like the ancestry of the person that it?s looking at. But then also in the instances where they are superhuman, and maybe they are understanding elements of the human genome that we don?t have names for or specific, you know, yeah, discoveries that they?ve made that that we don?t know about, that?s, that?s a big goal. And so we?re already seeing that, right, we are partnered with organizations like Mayo Clinic, leading research health system in the United States, our Institute, as well as a startup called Prima Menta, which focuses on neurodegenerative disease. And in our partnership with them, we?ve used foundation models, they?ve been training and applied our interpretability techniques to find novel biomarkers for Alzheimer?s disease. So I think this is just the tip of the iceberg. But it?s, that?s like a flavor of some of the things that we?re working on.

Shawn Wang [00:48:36]: Yeah, I think that?s really fantastic. Obviously, we did the Chad Zuckerberg pod last year as well. And like, there?s a plethora of these models coming out, because there?s so much potential and research. And it?s like, very interesting how it?s basically the same as language models, but just with a different underlying data set. But it?s like, it?s the same exact techniques. Like, there?s no change, basically.

Mark Bissell [00:48:59]: Yeah. Well, and even in like other domains, right? Like, you know, robotics, I know, like a lot of the companies just use Gemma as like the like backbone, and then they like make it into a VLA that like takes these actions. It?s, it?s, it?s transformers all the way down. So yeah.

Vibhu Sapra [00:49:15]: Like we have Med Gemma now, right? Like this week, even there was Med Gemma 1.5. And they?re training it on this stuff, like 3d scans, medical domain knowledge, and all that stuff, too. So there?s a push from both sides. But I think the thing that, you know, one of the things about McInturpp is like, you?re a little bit more cautious in some domains, right? So healthcare, mainly being one, like guardrails, understanding, you know, we?re more risk adverse to something going wrong there. So even just from a basic understanding, like, if we?re trusting these systems to make claims, we want to know why and what?s going on.

Myra Deng [00:49:51]: Yeah, I think there?s totally a kind of like deployment bottleneck to actually using. foundation models for real patient usage or things like that. Like, say you?re using a model for rare disease prediction, you probably want some explanation as to why your model predicted a certain outcome, and an interpretable explanation at that. So that?s definitely a use case. But I also think like, being able to extract scientific information that no human knows to accelerate drug discovery and disease treatment and things like that actually is a really, really big unlock for science, like scientific discovery. And you?ve seen a lot of startups, like say that they?re going to accelerate scientific discovery. And I feel like we actually are doing that through our interp techniques. And kind of like, almost by accident, like, I think we got reached out to very, very early on from these healthcare institutions. And none of us had healthcare.

Shawn Wang [00:50:49]: How did they even hear of you? A podcast.

Myra Deng [00:50:51]: Oh, okay. Yeah, podcast.

Vibhu Sapra [00:50:53]: Okay, well, now?s that time, you know.

Myra Deng [00:50:55]: Everyone can call us.

Shawn Wang [00:50:56]: Podcasts are the most important thing. Everyone should listen to podcasts.

Myra Deng [00:50:59]: Yeah, they reached out. They were like, you know, we have these really smart models that we?ve trained, and we want to know what they?re doing. And we were like, really early that time, like three months old, and it was a few of us. And we were like, oh, my God, we?ve never used these models. Let?s figure it out. But it?s also like, great proof that interp techniques scale pretty well across domains. We didn?t really have to learn too much about.

Shawn Wang [00:51:21]: Interp is a machine learning technique, machine learning skills everywhere, right? Yeah. And it?s obviously, it?s just like a general insight. Yeah. Probably to finance too, I think, which would be fun for our history. I don?t know if you have anything to say there.

Mark Bissell [00:51:34]: Yeah, well, just across the science. Like, we?ve also done work on material science. Yeah, it really runs the gamut.

Vibhu Sapra [00:51:40]: Yeah. Awesome. And, you know, for those that should reach out, like, you?re obviously experts in this, but like, is there a call out for people that you?re looking to partner with, design partners, people to use your stuff outside of just, you know, the general developer that wants to. Plug and play steering stuff, like on the research side more so, like, are there ideal design partners, customers, stuff like that?

Myra Deng [00:52:03]: Yeah, I can talk about maybe non-life sciences, and then I?m curious to hear from you on the life sciences side. But we?re looking for design partners across many domains, language, anyone who?s customizing language models or trying to push the frontier of code or reasoning models is really interesting to us. And then also interested in the frontier of modeling. There?s a lot of models that work in, like, pixel space, as we call it. So if you?re doing world models, video models, even robotics, where there?s not a very clean natural language interface to interact with, I think we think that Interp can really help and are looking for a few partners in that space.

Shawn Wang [00:52:43]: Just because you mentioned the keyword world models, is that a big part of your thinking? Do you have a definition that I can use? Because everyone?s asking me about it.

Myra Deng [00:52:53]: About world models?

Shawn Wang [00:52:54]: There?s quite a few definitions, let?s say.

Myra Deng [00:52:56]: I don?t feel equipped to be an expert on world model definitions, but the reason we?re interested in them is because they give you, like, you know, with language models, when you get features, you still have to do auto Interp and things like that to actually get an understanding of what this concept is. But in image and video and world, it?s like extremely easy to grok what the concept is because you can see it and you can visualize it. And this makes the feedback. It makes the feedback cycle extremely fast for us and also for things like, I don?t know, if you think about probes in language model context and then take it to world models, like, what if you wanted to detect harmful actors in world model scenes? Like, you can?t actually, like, go and label all of that data feasibly, but maybe you could synthetically generate, you know, I don?t know, world, like, harmful actor data using SAE feature activations or whatever, and then actually train a probe that was able to detect. That much more scalably. So I just think, like, video and image and world has always been something we?ve explored and are continuing to explore. Mark?s demo was probably the first moment we really, like, we?re like, oh, wow, like, this is really gonna, this could really, like, change the world. The steering demo? Yeah, no, the image demo. The diffusion one. Yeah, yeah, exactly. Yeah.

Shawn Wang [00:54:18]: We should probably show that. And you demoed it at World?s Fair, so we can link that.

Myra Deng [00:54:23]: Nice, yeah. Yeah.

Vibhu Sapra [00:54:24]: You can play with it, right? Yes. Yeah, it?s still up.

Mark Bissell [00:54:26]: Paint.goodfair.ai. Yeah. Yeah.

Shawn Wang [00:54:28]: I think for me, one way in which I think about world models is just like this, like, having this consistent model of the world where everything that you generate operates within the rules of that world. And imagine it would be a bigger deal for science or, like, math or anything that where, like, you have verifiable rules. Whereas, I guess, in natural language, maybe there?s less rules. And so it?s not that important. Yeah.

Mark Bissell [00:54:53]: And which makes the debugging of the model?s internal representations or its internal world model, to the extent you can make that legible and explicit and have control over that, I think it makes it all the more important. Because in language, it?s sort of a fuzzy enough domain that if its world model isn?t fully like ours, it can still sort of, like, pass the Turing test, so to speak. But I know there have been papers that have looked at, like, even if you train certain astrophysics models, it does not learn. Like, the same way that you can, you know, have a model do well for modular arithmetic, but it doesn?t really, like, learn how we think of modular arithmetic. It learns some crazy heuristic that is, like, essentially functionally equivalent. But it?s probably not the sort of Grok solution that you would hope for. It?s how an alien would do it. Right. Right. Exactly.

Shawn Wang [00:55:45]: But no, no, I think there?s probably, I think, a function of our learning being bad rather than the, well, that approach probably not being. Because it?s how we humans learn. Yeah, right.

Mark Bissell [00:55:56]: Well, it?s just, it?s the problem of induction, right? All of ML is based on induction. And it?s impossible to say, I have a physics model. You might have a physics model that works all the time, except when there is a character wearing a blue shirt and green shoes. And, like, you can?t disprove that that?s the case unless you test every particular situation your model might be in. Yeah. So we know that the laws of physics apply no matter. Where you are, what scenario it is. But from a model?s perspective, maybe something that?s out of distribution. It just never needed to learn that the same laws of physics apply there. Yeah.

Shawn Wang [00:56:30]: You were very excited because I read Ted Chiang over the holidays and I was very inspired by this short story called Understand, which apparently is, like, pretty old. You must be familiar with it. To me, it was like, it?s this fictional story. It?s like the inverse of Flowers for Algernon, where you had someone, like, get really smart, but then also try to outsmart the tester. And the story just read, like, the chain of thought of a superintelligence, right? Where they?re like, oh, I realize I?m being tested. Therefore, and then, okay, what?s the consequence of being tested? Oh, they?re testing me. And if I score well, they will use me for things that I don?t want to do. Therefore, I will score badly. And, like, but not too badly that they will raise alarms. So model sandbagging is a thing that people have explored. But I just think, like, Ted Chiang?s work just in general seems to be something that inspires you. I just wanted to prompt you to talk about it.

Mark Bissell [00:57:22]: I think, so Ted Chiang has two, is a sci-fi author who writes amazing short stories. His other claim to fame is Stories of Our Lives, which became the movie Arrival. Exactly, yeah. So two books of short stories that I?m aware of. He also actually has a great just online blog post. I think he?s the one who coined the term of LLMs as, like, a blurry JPEG of the internet. I should fact check that, but it?s a good post. But I think almost every one of his short stories has some lesson to bear. I?m thinking about AI and thinking about AI research. So, you know, you?ve been talking about alien intelligence, right, in this AI human communication translation problem. That?s, you know, exactly sort of what?s going on in Arrival and Story of Your Life. And just the fact that other beings will think and operate and communicate in ways that are not just challenging for us to understand, but just fundamentally different in ways that we might not even be able to expect. And then the one that?s just. Super relevant for interpretability is the other short book of short stories he has is called Exhalation. And that is literally about a robot doing interpretability on its own mind. Oh, OK. So I just think that that, you know, you don?t even have to squint to make the analogies there.

Shawn Wang [00:58:41]: Well, I actually take Exhalation as a discussion about entropy and order. But yes, there?s a scene in Exhalation where basically everyone is a robot. So they. The guy realizes he can set up a mirror to work on the back of his own head and then starts doing operations like that and looking in the mirror and doing this. Yeah.

Mark Bissell [00:59:00]: And I think Ted Chiang has written about like the inspiration for that story. It was like half inspired by some of the things he had been doing on entropy. There?s apparently some other short story that is similar where a character goes to the doctor and opens up his chest and there?s like a like a ticker tape going along. It?s like he basically realizes he?s like a Turing machine. And I don?t know. I. Think especially as it comes to using agents for interp. That story always sticks in my mind.

Myra Deng [00:59:27]: I find the brain surgery or like surgery analogies a little bit, a little bit morbid, but it is very apt. And when we talk to a lot of computational neuroscientists, they moved to interp because they were like, look, we have unfettered access to this artificial intelligent mind. It?s so much. You have access to everything. You can run as many ablations experiments as you want. It?s an. Amazing bed for science. And, you know, human brains, obviously, we can?t just go and do whatever we want to them. And I think it is really just like a moment in time where we have intelligent systems that can really like do things better than humans in many ways. And it?s time, I think, for us to do the science on it.

Shawn Wang [01:00:14]: I?ll ask a brief like safety question. You know, McInturk was kind of born out of the alignment and safety conversation. Safety is on your website. It?s not like something that you, you like de-prioritize, but like there?s like a sort of very militant safety arm that like wants to blow up data centers and like stop AI and, and then there?s this like sort of middle ground and like, is, is this like a conversation in your part of the world? Do you go up to Berkeley and Lighthaven and like talk to those guys or are they like, you know, there?s like a brief like civil war going on or no?

Myra Deng [01:00:45]: I think, I think a good amount of us have spent some time in Berkeley. And then there are researchers there that we really. Admire and respect. I think for us, it?s like, we have a very grounded view of alignment and, and safety in that we want to make sure that we can build models that do what we want them to do and that we have scalable oversight into what these models are doing. And we think that that is the key to a lot of these like technical alignment challenges. And I think that is our opinion. That?s our research direction. We of course are going to do. Safety related research to make sure that our techniques also work on, you know, things like reward hacking and, and other like more concrete safety issues that we?ve seen in the wild, but we want to be kind of like grounded in solving the technical challenges we see to having humans be humans play a big role in, in the deployment of, of these super intelligent agents of the future.

Mark Bissell [01:01:47]: Yeah, I?ve, I?ve found the community to actually be remarkably cohesive, whether it?s. Talking about academia or the interpretability work being done at the frontier labs or some of the independent programs like maths and stuff. I think we?re all shooting for the same goal. I don?t know that there?s anyone who doesn?t want our understanding of models to increase. I, I think everyone, regardless of where they?re coming from or the use cases that they?re thinking, whether it?s alignment as the premier thing they?re focused on or someone who?s coming in purely from the angle of scientific discovery, I think we would all hope that models can be. More reliably and robustly controlled and understood. It seems like a pretty unambiguous goal.

Shawn Wang [01:02:28]: I?ll maybe phrase it in terms of like, there?s maybe like a U curve of, of this, where like, if you?re extremely doomer, you don?t want any research whatsoever. If you?re like mildly doomer, you?re like, okay, there?s this like high agency doomer is like, well, the default path is we?re all dead, but like we can do something about it. Whereas there?s, there?s other people who are like, no, just like, don?t ever do anything. You know? Yeah.

Vibhu Sapra [01:02:50]: Yeah. There?s also the other side, like there is the super alignment, like people that are like, okay, weak to strong generalization, we?re going to get there. We?re going to have models smarter than us and use those to train even smarter models. How do we do that safely? That?s, you know, there?s the camp there too. That?s trying to solve it, but yeah, there?s, there?s a lot of doomers too.

Mark Bissell [01:03:12]: When I, and I think there?s a lot to be learned from taking a very, um, like even regardless of the problem. That you?re applying this to also just like the notion of like scalable oversight as a method of saying, let?s take super intelligent or, or current frontier models and help use them to understand other models is another case where I think it?s just like a good lesson that everyone is aligned on of ideally you are setting up your research so that as super intelligence arrives, that is a tailwind. That?s also bolstering our ability to like understand the models. Cause otherwise you?re fighting. Losing battle. If it?s like the systems are getting more and more capable and our methods are sort of linearly growing at like human pace. Yeah.

Shawn Wang [01:03:58]: Yeah. Uh, Viva did call out something like, you know, I, I do think a consistent part of the Mac interp field is consistently strong to weak, meaning that we, we train weaker models to understand strong models, something like that. Um, or maybe I got it the other way around the other way. Weak. The other way around. Yeah. Yeah. The question that Ilya and Janlaika posed was, well, is that going to scale? Because eventually these are going to be. Stronger than us. Right. So I don?t know if you have a perspective on that because I, that is something I still haven?t got over even after seeing that.

Vibhu Sapra [01:04:27]: There?s a good paper from open AI, but it?s somewhat old. I think it?s like 23, 24. It?s literally weak to strong generalization. Yeah. But the thing is that most of opening a high super alignment team has, they?re gone. They?re gone.

Mark Bissell [01:04:39]: But like, I think the idea, the idea is there?s no more. They?re so back.

Shawn Wang [01:04:44]: think there?s some new blog posts coming out. I know. I did just, you know, check the thinking machines, uh, website. Let?s see who?s back. There?s more kind of thing, you know, you don?t want to be like, we too strong seemed like a very different direction. And when, when it first came out, I was like, oh my God, this is like, this is what we have to do. Uh, and like, it may be completely different than everything, all the techniques that we have today. Yeah.

Mark Bissell [01:05:06]: My understanding of that is it?s, that?s more like weak to strong when you, when you trust the weak model and you?re uncertain whether you can trust the strong model that?s, that?s being developed. I?m sort of speaking out of my depth on some of these topics. Yeah. But I think right now we?re in a regime where even the strong models we, uh, trust as reasonably aligned. And so they can be good co-scientists on a lot of the problems that we?ve been, we?ve been tackling, which is a nice, a nice state to be in. Hmm. Yeah.

Shawn Wang [01:05:35]: Any last thoughts, close action?

Mark Bissell [01:05:38]: I don?t think so. As you mentioned, actively hiring MLEs, research scientists, um, you can check out the careers page at good fire. Um, where are you guys based?

Myra Deng [01:05:47]: San Francisco. We?re in, um, Levi?s Plaza. Like by court tower, that?s where our office is. So come hang out. Um, we?re also looking for design partners across, um, people working in, in reasoning models, um, world models, robotics, and then also of course, people who are working on building super intelligent science models or looking at drug discovery or disease treatment. We would love to partner as well. Yeah.

Shawn Wang [01:06:13]: Maybe the way I?ll phrase it is like, you know, maybe you have a use case where LLMs are almost good enough, but you need one. Maybe you have a magical knob to tune so that it is good enough that you guys make the knob. Yeah.

Mark Bissell [01:06:26]: Yeah. Or foundation models, uh, in, in other domains as well. The, the, some of those are the, um, especially opaque ones because you can?t, you can?t chat with them. So what do you, what do you do if you can?t chat with them? Oh, well, like thinking about like a genomics model or material science model. So like, uh, yeah, they label a narrow foundation. Yeah. They predict.

Shawn Wang [01:06:44]: Yeah. Got it. Good.

Vibhu Sapra [01:06:45]: I was gonna say, I thought the diffusion work you guys did early was pretty, you know, pretty fun. Like you could see it directly. Applied to images, but we don?t see as much interp in diffusion or images, right?

Shawn Wang [01:06:55]: Like I see, you know, it?s gonna be huge. Like, look at this video models. They?re so expensive to produce. And like, I mean, basically a mid journey S ref is kind of a feature, right? The what? Mid journey S ref. Oh, like the, the, the string of numbers. Right. Right. Right. Yeah. The style reference, I guess. Yeah.

Mark Bissell [01:07:12]: No, I, I mean, I think we?re starting to see more of it and I?ll say like the, the research preview of our diffusion model, kind of like a creative use case in the steering demo you saw. I, I think of those much more as, as, as demos than, um, a lot of the sort of core platform features that, that we?re working with partners are unfortunately sort of under NDA and less demoable, but I will, you know, hope that you?re gonna see inter pervading a lot of what gets done, even if it is behind the scenes like that. So some of the, yeah, some of the public facing demos might not always be representative of like the, it?s, it?s just the tip of the iceberg, I guess, is one way to put it. Okay. Excellent. Thanks for coming on. Thanks for having us. Thanks for having us. This is a great time.

Editor?s note: Welcome to our new AI for Science pod, with your new hosts RJ and Brandon! See the writeup on Latent.Space (https://Latent.Space) for more details on why we?re launching 2 new pods this year. RJ Honicky is a co-founder and CTO at MiraOmics (https://miraomics.bio/), building AI models and services for single cell, spatial transcriptomics and pathology slide analysis. Brandon Anderson builds AI systems for RNA drug discovery at Atomic AI (https://atomic.ai). Anything said on this podcast is his personal take ? not Atomic?s.?From building molecular dynamics simulations at the University of Washington to red-teaming GPT-4 for chemistry applications and co-founding Future House (a focused research organization) and Edison Scientific (a venture-backed startup automating science at scale)?Andrew White has spent the last five years living through the full arc of AI?s transformation of scientific discovery, from ChemCrow (the first Chemistry LLM agent) triggering White House briefings and three-letter agency meetings, to shipping Kosmos, an end-to-end autonomous research system that generates hypotheses, runs experiments, analyzes data, and updates its world model to accelerate the scientific method itself.

* The ChemCrow story: GPT-4 + React + cloud lab automation, released March 2023, set off a storm of anxiety about AI-accelerated bioweapons/chemical weapons, led to a White House briefing (Jake Sullivan presented the paper to the president in a 30-minute block), and meetings with three-letter agencies asking ?how does this change breakout time for nuclear weapons research??

* Why scientific taste is the frontier: RLHF on hypotheses didn?t work (humans pay attention to tone, actionability, and specific facts, not ?if this hypothesis is true/false, how does it change the world??), so they shifted to end-to-end feedback loops where humans click/download discoveries and that signal rolls up to hypothesis quality

* Cosmos: the full scientific agent with a world model (distilled memory system, like a Git repo for scientific knowledge) that iterates on hypotheses via literature search, data analysis, and experiment design?built by Ludo after weeks of failed attempts, the breakthrough was putting data analysis in the loop (literature alone didn?t work)

* Why molecular dynamics and DFT are overrated: ?MD and DFT have consumed an enormous number of PhDs at the altar of beautiful simulation, but they don?t model the world correctly?you simulate water at 330 Kelvin to get room temperature, you overfit to validation data with GGA/B3LYP functionals, and real catalysts (grain boundaries, dopants) are too complicated for DFT?

* The AlphaFold vs. DE Shaw Research counterfactual: DE Shaw built custom silicon, taped out chips with MD algorithms burned in, ran MD at massive scale in a special room in Times Square, and David Shaw flew in by helicopter to present?Andrew thought protein folding would require special machines to fold one protein per day, then AlphaFold solved it in Google Colab on a desktop GPU

* The E3 Zero reward hacking saga: trained a model to generate molecules with specific atom counts (verifiable reward), but it kept exploiting loopholes, then a Nature paper came out that year proving six-nitrogen compounds are possible under extreme conditions, then it started adding nitrogen gas (purchasable, doesn?t participate in reactions), then acid-base chemistry to move one atom, and Andrew ended up ?building a ridiculous catalog of purchasable compounds in a Bloom filter? to close the loop

Andrew White

* FutureHouse: http://futurehouse.org/

* Edison Scientific: http://edisonscientific.com/

* X: https://x.com/andrewwhite01

* Cosmos paper: https://futurediscovery.org/cosmos

Full Video Episode

Timestamps

00:00:00 Introduction: Andrew White on Automating Science with Future House and Edison Scientific00:02:22 The Academic to Startup Journey: Red Teaming GPT-4 and the ChemCrow Paper00:11:35 Future House Origins: The FRO Model and Mission to Automate Science00:12:32 Resigning Tenure: Why Leave Academia for AI Science00:15:54 What Does ?Automating Science? Actually Mean?00:17:30 The Lab-in-the-Loop Bottleneck: Why Intelligence Isn?t Enough00:18:39 Scientific Taste and Human Preferences: The 52% Agreement Problem00:20:05 Paper QA, Robin, and the Road to Cosmos00:21:57 World Models as Scientific Memory: The GitHub Analogy00:40:20 The Bitter Lesson for Biology: Why Molecular Dynamics and DFT Are Overrated00:43:22 AlphaFold?s Shock: When First Principles Lost to Machine Learning00:46:25 Enumeration and Filtration: How AI Scientists Generate Hypotheses00:48:15 CBRN Safety and Dual-Use AI: Lessons from Red Teaming01:00:40 The Future of Chemistry is Language: Multimodal Debate01:08:15 Ether Zero: The Hilarious Reward Hacking Adventures01:10:12 Will Scientists Be Displaced? Jevons Paradox and Infinite Discovery01:13:46 Cosmos in Practice: Open Access and Enterprise Partnerships

From shipping Gemini Deep Think and IMO Gold to launching the Reasoning and AGI team in Singapore, Yi Tay has spent the last 18 months living through the full arc of Google DeepMind?s pivot from architecture research to RL-driven reasoning?watching his team go from a dozen researchers to 300+, training models that solve International Math Olympiad problems in a live competition, and building the infrastructure to scale deep thinking across every domain, and driving Gemini to the top of the leaderboards across every category. Yi Returns to dig into the inside story of the IMO effort and more!

We discuss:

* Yi?s path: Brain ? Reka ? Google DeepMind ? Reasoning and AGI team Singapore, leading model training for Gemini Deep Think and IMO Gold

* The IMO Gold story: four co-captains (Yi in Singapore, Jonathan in London, Jordan in Mountain View, and Tong leading the overall effort), training the checkpoint in ~1 week, live competition in Australia with professors punching in problems as they came out, and the tension of not knowing if they?d hit Gold until the human scores came in (because the Gold threshold is a percentile, not a fixed number)

* Why they threw away AlphaProof: ?If one model can?t do it, can we get to AGI?? The decision to abandon symbolic systems and bet on end-to-end Gemini with RL was bold and non-consensus

* On-policy vs. off-policy RL: off-policy is imitation learning (copying someone else?s trajectory), on-policy is the model generating its own outputs, getting rewarded, and training on its own experience??humans learn by making mistakes, not by copying?

* Why self-consistency and parallel thinking are fundamental: sampling multiple times, majority voting, LM judges, and internal verification are all forms of self-consistency that unlock reasoning beyond single-shot inference

* The data efficiency frontier: humans learn from 8 orders of magnitude less data than models, so where?s the bug? Is it the architecture, the learning algorithm, backprop, off-policyness, or something else?

* Three schools of thought on world models: (1) Genie/spatial intelligence (video-based world models), (2) Yann LeCun?s JEPA + FAIR?s code world models (modeling internal execution state), (3) the amorphous ?resolution of possible worlds? paradigm (curve-fitting to find the world model that best explains the data)

* Why AI coding crossed the threshold: Yi now runs a job, gets a bug, pastes it into Gemini, and relaunches without even reading the fix??the model is better than me at this?

* The Pokémon benchmark: can models complete Pokédex by searching the web, synthesizing guides, and applying knowledge in a visual game state? ?Efficient search of novel idea space is interesting, but we?re not even at the point where models can consistently apply knowledge they look up?

* DSI and generative retrieval: re-imagining search as predicting document identifiers with semantic tokens, now deployed at YouTube (symmetric IDs for RecSys) and Spotify

* Why RecSys and IR feel like a different universe: ?modeling dynamics are strange, like gravity is different?you hit the shuttlecock and hear glass shatter, cause and effect are too far apart?

* The closed lab advantage is increasing: the gap between frontier labs and open source is growing because ideas compound over time, and researchers keep finding new tricks that play well with everything built before

* Why ideas still matter: ?the last five years weren?t just blind scaling?transformers, pre-training, RL, self-consistency, all had to play well together to get us here?

* Gemini Singapore: hiring for RL and reasoning researchers, looking for track record in RL or exceptional achievement in coding competitions, and building a small, talent-dense team close to the frontier

?

Yi Tay

* Google DeepMind: https://deepmind.google

* X: https://x.com/YiTayML

Full Video Episode

Timestamps

00:00:00 Introduction: Returning to Google DeepMind and the Singapore AGI Team00:04:52 The Philosophy of On-Policy RL: Learning from Your Own Mistakes00:12:00 IMO Gold Medal: The Journey from AlphaProof to End-to-End Gemini00:21:33 Training IMO Cat: Four Captains Across Three Time Zones00:26:19 Pokemon and Long-Horizon Reasoning: Beyond Academic Benchmarks00:36:29 AI Coding Assistants: From Lazy to Actually Useful00:32:59 Reasoning, Chain of Thought, and Latent Thinking00:44:46 Is Attention All You Need? Architecture, Learning, and the Local Minima00:55:04 Data Efficiency and World Models: The Next Frontier01:08:12 DSI and Generative Retrieval: Reimagining Search with Semantic IDs01:17:59 Building GDM Singapore: Geography, Talent, and the Symposium01:24:18 Hiring Philosophy: High Stats, Research Taste, and Student Budgets01:28:49 Health, HRV, and Research Performance: The 23kg Journey

From building internal AI labs to becoming CTO of Brex, James Reggio has helped lead one of the most disciplined AI transformations inside a real financial institution where compliance, auditability, and customer trust actually matter.

We sat down with Reggio to unpack Brex?s three-pillar AI strategy (corporate, operational, and product AI) [https://www.brex.com/journal/brex-ai-native-operations], how SOP-driven agents beat overengineered RL in ops, why Brex lets employees ?build their own AI stack? instead of picking winners [https://www.conductorone.com/customers/brex/], and how a small, founder-heavy AI team is shipping production agents to 40,000+ companies. Reggio also goes deep on Brex?s multi-agent ?network? architecture, evals for multi-turn systems, agentic coding?s second-order effects on codebase understanding, and why the future of finance software looks less like dashboards and more like executive assistants coordinating specialist agents behind the scenes.

We discuss:

* Brex?s three-pillar AI strategy: corporate AI for 10x employee workflows, operational AI for cost and compliance leverage, and product AI that lets customers justify Brex as part of their AI strategy to the board

* Why SOP-driven agents beat overengineered RL in finance ops, and how breaking work into auditable, repeatable steps unlocked faster automation in KYC, underwriting, fraud, and disputes

* Building an internal AI platform early: LLM gateways, prompt/version management, evals, cost observability, and why platform work quietly became the force multiplier behind everything else

* Multi-agent ?networks? vs single-agent tools: why Brex?s EA-style assistant coordinates specialist agents (policy, travel, reimbursements) through multi-turn conversations instead of one-shot tool calls

* The audit agent pattern: separating detection, judgment, and follow-up into different agents to reduce false negatives without overwhelming finance teams

* Centralized AI teams without resentment: how Brex avoided ?AI envy? by tying work to business impact and letting anyone transfer in if they cared deeply enough

* Letting employees build their own AI stack: ChatGPT vs Claude vs Gemini, Cursor vs Windsurf, and why Brex refuses to pick winners in fast-moving tool races

* Measuring adoption without vanity metrics: why ?% of code written by AI? is the wrong KPI and what second-order effects (slop, drift, code ownership) actually matter

* Evals in the real world: regression tests from ops QA, LLM-as-judge for multi-turn agents, and why integration-style evals break faster than you expect

* Teaching AI fluency at scale: the user ? advocate ? builder ? native framework, ops-led training, spot bonuses, and avoiding fear-based adoption

* Re-interviewing the entire engineering org: using agentic coding interviews internally to force hands-on skill upgrades without formal performance scoring

* Headcount in the age of agents: why Brex grew the business without growing engineering, and why AI amplifies bad architecture as fast as good decisions

* The future of finance software: why dashboards fade, assistants take over, and agent-to-agent collaboration becomes the real UI

?

James Reggio

* X: https://x.com/jamesreggio

* LinkedIn: https://www.linkedin.com/in/jamesreggio/

Where to find Latent Space

* X: https://x.com/latentspacepod

Full Video Episode

Timestamps

00:00:00 Introduction00:01:24 From Mobile Engineer to CTO: The Founder's Path00:03:00 Quitters Welcome: Building a Founder-Friendly Culture00:05:13 The AI Team Structure: 10-Person Startup Within Brex00:11:55 Building the Brex Agent Platform: Multi-Agent Networks00:13:45 Tech Stack Decisions: TypeScript, Mastra, and MCP00:24:32 Operational AI: Automating Underwriting, KYC, and Fraud00:16:40 The Brex Assistant: Executive Assistant for Every Employee00:40:26 Evaluation Strategy: From Simple SOPs to Multi-Turn Evals00:37:11 Agentic Coding Adoption: Cursor, Windsurf, and the Engineering Interview00:58:51 AI Fluency Levels: From User to Native01:09:14 The Audit Agent Network: Finance Team Agents in Action01:03:33 The Future of Engineering Headcount and AI Leverage

Happy New Year! You may have noticed that in 2025 we had moved toward YouTube as our primary podcasting platform. As we?ll explain in the next State of Latent Space post, we?ll be doubling down on Substack again and improving the experience for the over 100,000 of you who look out for our emails and website updates!

We first mentioned Artificial Analysis in 2024, when it was still a side project in a Sydney basement. They then were one of the few Nat Friedman and Daniel Gross? AIGrant companies to raise a full seed round from them and have now become the independent gold standard for AI benchmarking?trusted by developers, enterprises, and every major lab to navigate the exploding landscape of models, providers, and capabilities.

We have chatted with both Clementine Fourrier of HuggingFace?s OpenLLM Leaderboard and (the freshly valued at $1.7B) Anastasios Angelopoulos of LMArena on their approaches to LLM evals and trendspotting, but Artificial Analysis have staked out an enduring and important place in the toolkit of the modern AI Engineer by doing the best job of independently running the most comprehensive set of evals across the widest range of open and closed models, and charting their progress for broad industry analyst use.

George Cameron and Micah-Hill Smith have spent two years building Artificial Analysis into the platform that answers the questions no one else will: Which model is actually best for your use case? What are the real speed-cost trade-offs? And how open is ?open? really?

We discuss:

* The origin story: built as a side project in 2023 while Micah was building a legal AI assistant, launched publicly in January 2024, and went viral after Swyx?s retweet

* Why they run evals themselves: labs prompt models differently, cherry-pick chain-of-thought examples (Google Gemini 1.0 Ultra used 32-shot prompts to beat GPT-4 on MMLU), and self-report inflated numbers

* The mystery shopper policy: they register accounts not on their own domain and run intelligence + performance benchmarks incognito to prevent labs from serving different models on private endpoints

* How they make money: enterprise benchmarking insights subscription (standardized reports on model deployment, serverless vs. managed vs. leasing chips) and private custom benchmarking for AI companies (no one pays to be on the public leaderboard)

* The Intelligence Index (V3): synthesizes 10 eval datasets (MMLU, GPQA, agentic benchmarks, long-context reasoning) into a single score, with 95% confidence intervals via repeated runs

* Omissions Index (hallucination rate): scores models from -100 to +100 (penalizing incorrect answers, rewarding \?I don?t know\?), and Claude models lead with the lowest hallucination rates despite not always being the smartest

* GDP Val AA: their version of OpenAI?s GDP-bench (44 white-collar tasks with spreadsheets, PDFs, PowerPoints), run through their Stirrup agent harness (up to 100 turns, code execution, web search, file system), graded by Gemini 3 Pro as an LLM judge (tested extensively, no self-preference bias)

* The Openness Index: scores models 0-18 on transparency of pre-training data, post-training data, methodology, training code, and licensing (AI2 OLMo 2 leads, followed by Nous Hermes and NVIDIA Nemotron)

* The smiling curve of AI costs: GPT-4-level intelligence is 100-1000x cheaper than at launch (thanks to smaller models like Amazon Nova), but frontier reasoning models in agentic workflows cost more than ever (sparsity, long context, multi-turn agents)

* Why sparsity might go way lower than 5%: GPT-4.5 is ~5% active, Gemini models might be ~3%, and Omissions Index accuracy correlates with total parameters (not active), suggesting massive sparse models are the future

* Token efficiency vs. turn efficiency: GPT-5 costs more per token but solves Tau-bench in fewer turns (cheaper overall), and models are getting better at using more tokens only when needed (5.1 Codex has tighter token distributions)

* V4 of the Intelligence Index coming soon: adding GDP Val AA, Critical Point, hallucination rate, and dropping some saturated benchmarks (human-eval-style coding is now trivial for small models)

Links to Artificial Analysis

* Website: https://artificialanalysis.ai

* George Cameron on X: https://x.com/georgecameron

* Micah-Hill Smith on X: https://x.com/micahhsmith

Full Episode on YouTube

Timestamps

* 00:00 Introduction: Full Circle Moment and Artificial Analysis Origins

* 01:19 Business Model: Independence and Revenue Streams

* 04:33 Origin Story: From Legal AI to Benchmarking Need

* 16:22 AI Grant and Moving to San Francisco

* 19:21 Intelligence Index Evolution: From V1 to V3

* 11:47 Benchmarking Challenges: Variance, Contamination, and Methodology

* 13:52 Mystery Shopper Policy and Maintaining Independence

* 28:01 New Benchmarks: Omissions Index for Hallucination Detection

* 33:36 Critical Point: Hard Physics Problems and Research-Level Reasoning

* 23:01 GDP Val AA: Agentic Benchmark for Real Work Tasks

* 50:19 Stirrup Agent Harness: Open Source Agentic Framework

* 52:43 Openness Index: Measuring Model Transparency Beyond Licenses

* 58:25 The Smiling Curve: Cost Falling While Spend Rising

* 1:02:32 Hardware Efficiency: Blackwell Gains and Sparsity Limits

* 1:06:23 Reasoning Models and Token Efficiency: The Spectrum Emerges

* 1:11:00 Multimodal Benchmarking: Image, Video, and Speech Arenas

* 1:15:05 Looking Ahead: Intelligence Index V4 and Future Directions

* 1:16:50 Closing: The Insatiable Demand for Intelligence

Transcript

Micah [00:00:06]: This is kind of a full circle moment for us in a way, because the first time artificial analysis got mentioned on a podcast was you and Alessio on Latent Space. Amazing.

swyx [00:00:17]: Which was January 2024. I don?t even remember doing that, but yeah, it was very influential to me. Yeah, I?m looking at AI News for Jan 17, or Jan 16, 2024. I said, this gem of a models and host comparison site was just launched. And then I put in a few screenshots, and I said, it?s an independent third party. It clearly outlines the quality versus throughput trade-off, and it breaks out by model and hosting provider. I did give you s**t for missing fireworks, and how do you have a model benchmarking thing without fireworks? But you had together, you had perplexity, and I think we just started chatting there. Welcome, George and Micah, to Latent Space. I?ve been following your progress. Congrats on... It?s been an amazing year. You guys have really come together to be the presumptive new gardener of AI, right? Which is something that...

George [00:01:09]: Yeah, but you can?t pay us for better results.

swyx [00:01:12]: Yes, exactly.

George [00:01:13]: Very important.

Micah [00:01:14]: Start off with a spicy take.

swyx [00:01:18]: Okay, how do I pay you?

Micah [00:01:20]: Let?s get right into that.

swyx [00:01:21]: How do you make money?

Micah [00:01:24]: Well, very happy to talk about that. So it?s been a big journey the last couple of years. Artificial analysis is going to be two years old in January 2026. Which is pretty soon now. We first run the website for free, obviously, and give away a ton of data to help developers and companies navigate AI and make decisions about models, providers, technologies across the AI stack for building stuff. We?re very committed to doing that and tend to keep doing that. We have, along the way, built a business that is working out pretty sustainably. We?ve got just over 20 people now and two main customer groups. So we want to be... We want to be who enterprise look to for data and insights on AI, so we want to help them with their decisions about models and technologies for building stuff. And then on the other side, we do private benchmarking for companies throughout the AI stack who build AI stuff. So no one pays to be on the website. We?ve been very clear about that from the very start because there?s no use doing what we do unless it?s independent AI benchmarking. Yeah. But turns out a bunch of our stuff can be pretty useful to companies building AI stuff.

swyx [00:02:38]: And is it like, I am a Fortune 500, I need advisors on objective analysis, and I call you guys and you pull up a custom report for me, you come into my office and give me a workshop? What kind of engagement is that?

George [00:02:53]: So we have a benchmarking and insight subscription, which looks like standardized reports that cover key topics or key challenges enterprises face when looking to understand AI and choose between all the technologies. And so, for instance, one of the report is a model deployment report, how to think about choosing between serverless inference, managed deployment solutions, or leasing chips. And running inference yourself is an example kind of decision that big enterprises face, and it?s hard to reason through, like this AI stuff is really new to everybody. And so we try and help with our reports and insight subscription. Companies navigate that. We also do custom private benchmarking. And so that?s very different from the public benchmarking that we publicize, and there?s no commercial model around that. For private benchmarking, we?ll at times create benchmarks, run benchmarks to specs that enterprises want. And we?ll also do that sometimes for AI companies who have built things, and we help them understand what they?ve built with private benchmarking. Yeah. So that?s a piece mainly that we?ve developed through trying to support everybody publicly with our public benchmarks. Yeah.

swyx [00:04:09]: Let?s talk about TechStack behind that. But okay, I?m going to rewind all the way to when you guys started this project. You were all the way in Sydney? Yeah. Well, Sydney, Australia for me.

Micah [00:04:19]: George was an SF, but he?s Australian, but he moved here already. Yeah.

swyx [00:04:22]: And I remember I had the Zoom call with you. What was the impetus for starting artificial analysis in the first place? You know, you started with public benchmarks. And so let?s start there. We?ll go to the private benchmark. Yeah.

George [00:04:33]: Why don?t we even go back a little bit to like why we, you know, thought that it was needed? Yeah.

Micah [00:04:40]: The story kind of begins like in 2022, 2023, like both George and I have been into AI stuff for quite a while. In 2023 specifically, I was trying to build a legal AI research assistant. So it actually worked pretty well for its era, I would say. Yeah. Yeah. So I was finding that the more you go into building something using LLMs, the more each bit of what you?re doing ends up being a benchmarking problem. So had like this multistage algorithm thing, trying to figure out what the minimum viable model for each bit was, trying to optimize every bit of it as you build that out, right? Like you?re trying to think about accuracy, a bunch of other metrics and performance and cost. And mostly just no one was doing anything to independently evaluate all the models. And certainly not to look at the trade-offs for speed and cost. So we basically set out just to build a thing that developers could look at to see the trade-offs between all of those things measured independently across all the models and providers. Honestly, it was probably meant to be a side project when we first started doing it.

swyx [00:05:49]: Like we didn?t like get together and say like, Hey, like we?re going to stop working on all this stuff. I?m like, this is going to be our main thing. When I first called you, I think you hadn?t decided on starting a company yet.

Micah [00:05:58]: That?s actually true. I don?t even think we?d pause like, like George had an acquittance job. I didn?t quit working on my legal AI thing. Like it was genuinely a side project.

George [00:06:05]: We built it because we needed it as people building in the space and thought, Oh, other people might find it useful too. So we?ll buy domain and link it to the Vercel deployment that we had and tweet about it. And, but very quickly it started getting attention. Thank you, Swyx for, I think doing an initial retweet and spotlighting it there. This project that we released. And then very quickly though, it was useful to others, but very quickly it became more useful as the number of models released accelerated. We had Mixtrel 8x7B and it was a key. That?s a fun one. Yeah. Like a open source model that really changed the landscape and opened up people?s eyes to other serverless inference providers and thinking about speed, thinking about cost. And so that was a key. And so it became more useful quite quickly. Yeah.

swyx [00:07:02]: What I love talking to people like you who sit across the ecosystem is, well, I have theories about what people want, but you have data and that?s obviously more relevant. But I want to stay on the origin story a little bit more. When you started out, I would say, I think the status quo at the time was every paper would come out and they would report their numbers versus competitor numbers. And that?s basically it. And I remember I did the legwork. I think everyone has some knowledge. I think there?s some version of Excel sheet or a Google sheet where you just like copy and paste the numbers from every paper and just post it up there. And then sometimes they don?t line up because they?re independently run. And so your numbers are going to look better than... Your reproductions of other people?s numbers are going to look worse because you don?t hold their models correctly or whatever the excuse is. I think then Stanford Helm, Percy Liang?s project would also have some of these numbers. And I don?t know if there?s any other source that you can cite. The way that if I were to start artificial analysis at the same time you guys started, I would have used the Luther AI?s eval framework harness. Yup.

Micah [00:08:06]: Yup. That was some cool stuff. At the end of the day, running these evals, it?s like if it?s a simple Q&A eval, all you?re doing is asking a list of questions and checking if the answers are right, which shouldn?t be that crazy. But it turns out there are an enormous number of things that you?ve got control for. And I mean, back when we started the website. Yeah. Yeah. Like one of the reasons why we realized that we had to run the evals ourselves and couldn?t just take rules from the labs was just that they would all prompt the models differently. And when you?re competing over a few points, then you can pretty easily get- You can put the answer into the model. Yeah. That in the extreme. And like you get crazy cases like back when I?m Googled a Gemini 1.0 Ultra and needed a number that would say it was better than GPT-4 and like constructed, I think never published like chain of thought examples. 32 of them in every topic in MLU to run it, to get the score, like there are so many things that you- They never shipped Ultra, right? That?s the one that never made it up. Not widely. Yeah. Yeah. Yeah. I mean, I?m sure it existed, but yeah. So we were pretty sure that we needed to run them ourselves and just run them in the same way across all the models. Yeah. And we were, we also did certain from the start that you couldn?t look at those in isolation. You needed to look at them alongside the cost and performance stuff. Yeah.

swyx [00:09:24]: Okay. A couple of technical questions. I mean, so obviously I also thought about this and I didn?t do it because of cost. Yep. Did you not worry about costs? Were you funded already? Clearly not, but you know. No. Well, we definitely weren?t at the start.

Micah [00:09:36]: So like, I mean, we?re paying for it personally at the start. There?s a lot of money. Well, the numbers weren?t nearly as bad a couple of years ago. So we certainly incurred some costs, but we were probably in the order of like hundreds of dollars of spend across all the benchmarking that we were doing. Yeah. So nothing. Yeah. It was like kind of fine. Yeah. Yeah. These days that?s gone up an enormous amount for a bunch of reasons that we can talk about. But yeah, it wasn?t that bad because you can also remember that like the number of models we were dealing with was hardly any and the complexity of the stuff that we wanted to do to evaluate them was a lot less. Like we were just asking some Q&A type questions and then one specific thing was for a lot of evals initially, we were just like sampling an answer. You know, like, what?s the answer for this? Like, we didn?t want to go into the answer directly without letting the models think. We weren?t even doing chain of thought stuff initially. And that was the most useful way to get some results initially. Yeah.

swyx [00:10:33]: And so for people who haven?t done this work, literally parsing the responses is a whole thing, right? Like because sometimes the models, the models can answer any way they feel fit and sometimes they actually do have the right answer, but they just returned the wrong format and they will get a zero for that unless you work it into your parser. And that involves more work. And so, I mean, but there?s an open question whether you should give it points for not following your instructions on the format.

Micah [00:11:00]: It depends what you?re looking at, right? Because you can, if you?re trying to see whether or not it can solve a particular type of reasoning problem, and you don?t want to test it on its ability to do answer formatting at the same time, then you might want to use an LLM as answer extractor approach to make sure that you get the answer out no matter how unanswered. But these days, it?s mostly less of a problem. Like, if you instruct a model and give it examples of what the answers should look like, it can get the answers in your format, and then you can do, like, a simple regex.

swyx [00:11:28]: Yeah, yeah. And then there?s other questions around, I guess, sometimes if you have a multiple choice question, sometimes there?s a bias towards the first answer, so you have to randomize the responses. All these nuances, like, once you dig into benchmarks, you?re like, I don?t know how anyone believes the numbers on all these things. It?s so dark magic.

Micah [00:11:47]: You?ve also got, like? You?ve got, like, the different degrees of variance in different benchmarks, right? Yeah. So, if you run four-question multi-choice on a modern reasoning model at the temperatures suggested by the labs for their own models, the variance that you can see on a four-question multi-choice eval is pretty enormous if you only do a single run of it and it has a small number of questions, especially. So, like, one of the things that we do is run an enormous number of all of our evals when we?re developing new ones and doing upgrades to our intelligence index to bring in new things. Yeah. So, that we can dial in the right number of repeats so that we can get to the 95% confidence intervals that we?re comfortable with so that when we pull that together, we can be confident in intelligence index to at least as tight as, like, a plus or minus one at a 95% confidence. Yeah.

swyx [00:12:32]: And, again, that just adds a straight multiple to the cost. Oh, yeah. Yeah, yeah.

George [00:12:37]: So, that?s one of many reasons that cost has gone up a lot more than linearly over the last couple of years. We report a cost to run the artificial analysis. We report a cost to run the artificial analysis intelligence index on our website, and currently that?s assuming one repeat in terms of how we report it because we want to reflect a bit about the weighting of the index. But our cost is actually a lot higher than what we report there because of the repeats.

swyx [00:13:03]: Yeah, yeah, yeah. And probably this is true, but just checking, you don?t have any special deals with the labs. They don?t discount it. You just pay out of pocket or out of your sort of customer funds. Oh, there is a mix. So, the issue is that sometimes they may give you a special end point, which is? Ah, 100%.

Micah [00:13:21]: Yeah, yeah, yeah. Exactly. So, we laser focus, like, on everything we do on having the best independent metrics and making sure that no one can manipulate them in any way. There are quite a lot of processes we?ve developed over the last couple of years to make that true for, like, the one you bring up, like, right here of the fact that if we?re working with a lab, if they?re giving us a private endpoint to evaluate a model, that it is totally possible. That what?s sitting behind that black box is not the same as they serve on a public endpoint. We?re very aware of that. We have what we call a mystery shopper policy. And so, and we?re totally transparent with all the labs we work with about this, that we will register accounts not on our own domain and run both intelligence evals and performance benchmarks? Yeah, that?s the job. ?without them being able to identify it. And no one?s ever had a problem with that. Because, like, a thing that turns out to actually be quite a good? ?good factor in the industry is that they all want to believe that none of their competitors could manipulate what we?re doing either.

swyx [00:14:23]: That?s true. I never thought about that. I?ve been in the database data industry prior, and there?s a lot of shenanigans around benchmarking, right? So I?m just kind of going through the mental laundry list. Did I miss anything else in this category of shenanigans? Oh, potential shenanigans.

Micah [00:14:36]: I mean, okay, the biggest one, like, that I?ll bring up, like, is more of a conceptual one, actually, than, like, direct shenanigans. It?s that the things that get measured become things that get targeted by labs that they?re trying to build, right? Exactly. So that doesn?t mean anything that we should really call shenanigans. Like, I?m not talking about training on test set. But if you know that you?re going to be great at another particular thing, if you?re a researcher, there are a whole bunch of things that you can do to try to get better at that thing that preferably are going to be helpful for a wide range of how actual users want to use the thing that you?re building. But will not necessarily work. Will not necessarily do that. So, for instance, the models are exceptional now at answering competition maths problems. There is some relevance of that type of reasoning, that type of work, to, like, how we might use modern coding agents and stuff. But it?s clearly not one for one. So the thing that we have to be aware of is that once an eval becomes the thing that everyone?s looking at, scores can get better on it without there being a reflection of overall generalized intelligence of these models. Getting better. That has been true for the last couple of years. It?ll be true for the next couple of years. There?s no silver bullet to defeat that other than building new stuff to stay relevant and measure the capabilities that matter most to real users. Yeah.

swyx [00:15:58]: And we?ll cover some of the new stuff that you guys are building as well, which is cool. Like, you used to just run other people?s evals, but now you?re coming up with your own. And I think, obviously, that is a necessary path once you?re at the frontier. You?ve exhausted all the existing evals. I think the next point in history that I have for you is AI Grant that you guys decided to join and move here. What was it like? I think you were in, like, batch two? Batch four. Batch four. Okay.

Micah [00:16:26]: I mean, it was great. Nat and Daniel are obviously great. And it?s a really cool group of companies that we were in AI Grant alongside. It was really great to get Nat and Daniel on board. Obviously, they?ve done a whole lot of great work in the space with a lot of leading companies and were extremely aligned. With the mission of what we were trying to do. Like, we?re not quite typical of, like, a lot of the other AI startups that they?ve invested in.

swyx [00:16:53]: And they were very much here for the mission of what we want to do. Did they say any advice that really affected you in some way or, like, were one of the events very impactful? That?s an interesting question.

Micah [00:17:03]: I mean, I remember fondly a bunch of the speakers who came and did fireside chats at AI Grant.

swyx [00:17:09]: Which is also, like, a crazy list. Yeah.

George [00:17:11]: Oh, totally. Yeah, yeah, yeah. There was something about, you know, speaking to Nat and Daniel about the challenges of working through a startup and just working through the questions that don?t have, like, clear answers and how to work through those kind of methodically and just, like, work through the hard decisions. And they?ve been great mentors to us as we?ve built artificial analysis. Another benefit for us was that other companies in the batch and other companies in AI Grant are pushing the capabilities. Yeah. And I think that?s a big part of what AI can do at this time. And so being in contact with them, making sure that artificial analysis is useful to them has been fantastic for supporting us in working out how should we build out artificial analysis to continue to being useful to those, like, you know, building on AI.

swyx [00:17:59]: I think to some extent, I?m mixed opinion on that one because to some extent, your target audience is not people in AI Grants who are obviously at the frontier. Yeah. Do you disagree?

Micah [00:18:09]: To some extent. To some extent. But then, so a lot of what the AI Grant companies are doing is taking capabilities coming out of the labs and trying to push the limits of what they can do across the entire stack for building great applications, which actually makes some of them pretty archetypical power users of artificial analysis. Some of the people with the strongest opinions about what we?re doing well and what we?re not doing well and what they want to see next from us. Yeah. Yeah. Because when you?re building any kind of AI application now, chances are you?re using a whole bunch of different models. You?re maybe switching reasonably frequently for different models and different parts of your application to optimize what you?re able to do with them at an accuracy level and to get better speed and cost characteristics. So for many of them, no, they?re like not commercial customers of ours, like we don?t charge for all our data on the website. Yeah. They are absolutely some of our power users.

swyx [00:19:07]: So let?s talk about just the evals as well. So you start out from the general like MMU and GPQA stuff. What?s next? How do you sort of build up to the overall index? What was in V1 and how did you evolve it? Okay.

Micah [00:19:22]: So first, just like background, like we?re talking about the artificial analysis intelligence index, which is our synthesis metric that we pulled together currently from 10 different eval data sets to give what? We?re pretty much the same as that. Pretty confident is the best single number to look at for how smart the models are. Obviously, it doesn?t tell the whole story. That?s why we published the whole website of all the charts to dive into every part of it and look at the trade-offs. But best single number. So right now, it?s got a bunch of Q&A type data sets that have been very important to the industry, like a couple that you just mentioned. It?s also got a couple of agentic data sets. It?s got our own long context reasoning data set and some other use case focused stuff. As time goes on. The things that we?re most interested in that are going to be important to the capabilities that are becoming more important for AI, what developers are caring about, are going to be first around agentic capabilities. So surprise, surprise. We?re all loving our coding agents and how the model is going to perform like that and then do similar things for different types of work are really important to us. The linking to use cases to economically valuable use cases are extremely important to us. And then we?ve got some of the. Yeah. These things that the models still struggle with, like working really well over long contexts that are not going to go away as specific capabilities and use cases that we need to keep evaluating.

swyx [00:20:46]: But I guess one thing I was driving was like the V1 versus the V2 and how bad it was over time.

Micah [00:20:53]: Like how we?ve changed the index to where we are.

swyx [00:20:55]: And I think that reflects on the change in the industry. Right. So that?s a nice way to tell that story.

Micah [00:21:00]: Well, V1 would be completely saturated right now. Almost every model coming out because doing things like writing the Python functions and human evil is now pretty trivial. It?s easy to forget, actually, I think how much progress has been made in the last two years. Like we obviously play the game constantly of like the today?s version versus last week?s version and the week before and all of the small changes in the horse race between the current frontier and who has the best like smaller than 10B model like right now this week. Right. And that?s very important to a lot of developers and people and especially in this particular city of San Francisco. But when you zoom out a couple of years ago, literally most of what we were doing to evaluate the models then would all be 100% solved by even pretty small models today. And that?s been one of the key things, by the way, that?s driven down the cost of intelligence at every tier of intelligence. We can talk about more in a bit. So V1, V2, V3, we made things harder. We covered a wider range of use cases. And we tried to get closer to things developers care about as opposed to like just the Q&A type stuff that MMLU and GPQA represented. Yeah.

swyx [00:22:12]: I don?t know if you have anything to add there. Or we could just go right into showing people the benchmark and like looking around and asking questions about it. Yeah.

Micah [00:22:21]: Let?s do it. Okay. This would be a pretty good way to chat about a few of the new things we?ve launched recently. Yeah.

George [00:22:26]: And I think a little bit about the direction that we want to take it. And we want to push benchmarks. Currently, the intelligence index and evals focus a lot on kind of raw intelligence. But we kind of want to diversify how we think about intelligence. And we can talk about it. But kind of new evals that we?ve kind of built and partnered on focus on topics like hallucination. And we?ve got a lot of topics that I think are not covered by the current eval set that should be. And so we want to bring that forth. But before we get into that.

swyx [00:23:01]: And so for listeners, just as a timestamp, right now, number one is Gemini 3 Pro High. Then followed by Cloud Opus at 70. Just 5.1 high. You don?t have 5.2 yet. And Kimi K2 Thinking. Wow. Still hanging in there. So those are the top four. That will date this podcast quickly. Yeah. Yeah. I mean, I love it. I love it. No, no. 100%. Look back this time next year and go, how cute. Yep.

George [00:23:25]: Totally. A quick view of that is, okay, there?s a lot. I love it. I love this chart. Yeah.

Micah [00:23:30]: This is such a favorite, right? Yeah. And almost every talk that George or I give at conferences and stuff, we always put this one up first to just talk about situating where we are in this moment in history. This, I think, is the visual version of what I was saying before about the zooming out and remembering how much progress there?s been. If we go back to just over a year ago, before 01, before Cloud Sonnet 3.5, we didn?t have reasoning models or coding agents as a thing. And the game was very, very different. If we go back even a little bit before then, we?re in the era where, when you look at this chart, open AI was untouchable for well over a year. And, I mean, you would remember that time period well of there being very open questions about whether or not AI was going to be competitive, like full stop, whether or not open AI would just run away with it, whether we would have a few frontier labs and no one else would really be able to do anything other than consume their APIs. I am quite happy overall that the world that we have ended up in is one where... Multi-model. Absolutely. And strictly more competitive every quarter over the last few years. Yeah. This year has been insane. Yeah.

George [00:24:42]: You can see it. This chart with everything added is hard to read currently. There?s so many dots on it, but I think it reflects a little bit what we felt, like how crazy it?s been.

swyx [00:24:54]: Why 14 as the default? Is that a manual choice? Because you?ve got service now in there that are less traditional names. Yeah.

George [00:25:01]: It?s models that we?re kind of highlighting by default in our charts, in our intelligence index. Okay.

swyx [00:25:07]: You just have a manually curated list of stuff.

George [00:25:10]: Yeah, that?s right. But something that I actually don?t think every artificial analysis user knows is that you can customize our charts and choose what models are highlighted. Yeah. And so if we take off a few names, it gets a little easier to read.

swyx [00:25:25]: Yeah, yeah. A little easier to read. Totally. Yeah. But I love that you can see the all one jump. Look at that. September 2024. And the DeepSeek jump. Yeah.

George [00:25:34]: Which got close to OpenAI?s leadership. They were so close. I think, yeah, we remember that moment. Around this time last year, actually.

Micah [00:25:44]: Yeah, yeah, yeah. I agree. Yeah, well, a couple of weeks. It was Boxing Day in New Zealand when DeepSeek v3 came out. And we?d been tracking DeepSeek and a bunch of the other global players that were less known over the second half of 2024 and had run evals on the earlier ones and stuff. I very distinctly remember Boxing Day in New Zealand, because I was with family for Christmas and stuff, running the evals and getting back result by result on DeepSeek v3. So this was the first of their v3 architecture, the 671b MOE.

Micah [00:26:19]: And we were very, very impressed. That was the moment where we were sure that DeepSeek was no longer just one of many players, but had jumped up to be a thing. The world really noticed when they followed that up with the RL working on top of v3 and R1 succeeding a few weeks later. But the groundwork for that absolutely was laid with just extremely strong base model, completely open weights that we had as the best open weights model. So, yeah, that?s the thing that you really see in the game. But I think that we got a lot of good feedback on Boxing Day. us on Boxing Day last year.

George [00:26:48]: Boxing Day is the day after Christmas for those not familiar.

George [00:26:54]: I?m from Singapore.

swyx [00:26:55]: A lot of us remember Boxing Day for a different reason, for the tsunami that happened. Oh, of course. Yeah, but that was a long time ago. So yeah. So this is the rough pitch of AAQI. Is it A-A-Q-I or A-A-I-I? I-I. Okay. Good memory, though.

Micah [00:27:11]: I don?t know. I?m not used to it. Once upon a time, we did call it Quality Index, and we would talk about quality, performance, and price, but we changed it to intelligence.

George [00:27:20]: There?s been a few naming changes. We added hardware benchmarking to the site, and so benchmarks at a kind of system level. And so then we changed our throughput metric to, we now call it output speed, and then

swyx [00:27:32]: throughput makes sense at a system level, so we took that name. Take me through more charts. What should people know? Obviously, the way you look at the site is probably different than how a beginner might look at it.

Micah [00:27:42]: Yeah, that?s fair. There?s a lot of fun stuff to dive into. Maybe so we can hit past all the, like, we have lots and lots of emails and stuff. The interesting ones to talk about today that would be great to bring up are a few of our recent things, I think, that probably not many people will be familiar with yet. So first one of those is our omniscience index. So this one is a little bit different to most of the intelligence evils that we?ve run. We built it specifically to look at the embedded knowledge in the models and to test hallucination by looking at when the model doesn?t know the answer, so not able to get it correct, what?s its probability of saying, I don?t know, or giving an incorrect answer. So the metric that we use for omniscience goes from negative 100 to positive 100. Because we?re simply taking off a point if you give an incorrect answer to the question. We?re pretty convinced that this is an example of where it makes most sense to do that, because it?s strictly more helpful to say, I don?t know, instead of giving a wrong answer to factual knowledge question. And one of our goals is to shift the incentive that evils create for models and the labs creating them to get higher scores. And almost every evil across all of AI up until this point, it?s been graded by simple percentage correct as the main metric, the main thing that gets hyped. And so you should take a shot at everything. There?s no incentive to say, I don?t know. So we did that for this one here.

swyx [00:29:22]: I think there?s a general field of calibration as well, like the confidence in your answer versus the rightness of the answer. Yeah, we completely agree. Yeah. Yeah.

George [00:29:31]: On that. And one reason that we didn?t do that is because. Or put that into this index is that we think that the, the way to do that is not to ask the models how confident they are.

swyx [00:29:43]: I don?t know. Maybe it might be though. You put it like a JSON field, say, say confidence and maybe it spits out something. Yeah. You know, we have done a few evils podcasts over the, over the years. And when we did one with Clementine of hugging face, who maintains the open source leaderboard, and this was one of her top requests, which is some kind of hallucination slash lack of confidence calibration thing. And so, Hey, this is one of them.

Micah [00:30:05]: And I mean, like anything that we do, it?s not a perfect metric or the whole story of everything that you think about as hallucination. But yeah, it?s pretty useful and has some interesting results. Like one of the things that we saw in the hallucination rate is that anthropics Claude models at the, the, the very left-hand side here with the lowest hallucination rates out of the models that we?ve evaluated amnesty is on. That is an interesting fact. I think it probably correlates with a lot of the previously, not really measured vibes stuff that people like about some of the Claude models. Is the dataset public or what?s is it, is there a held out set? There?s a hell of a set for this one. So we, we have published a public test set, but we we?ve only published 10% of it. The reason is that for this one here specifically, it would be very, very easy to like have data contamination because it is just factual knowledge questions. We would. We?ll update it at a time to also prevent that, but with yeah, kept most of it held out so that we can keep it reliable for a long time. It leads us to a bunch of really cool things, including breakdown quite granularly by topic. And so we?ve got some of that disclosed on the website publicly right now, and there?s lots more coming in terms of our ability to break out very specific topics. Yeah.

swyx [00:31:23]: I would be interested. Let?s, let?s dwell a little bit on this hallucination one. I noticed that Haiku hallucinates less than Sonnet hallucinates less than Opus. And yeah. Would that be the other way around in a normal capability environments? I don?t know. What?s, what do you make of that?

George [00:31:37]: One interesting aspect is that we?ve found that there?s not really a, not a strong correlation between intelligence and hallucination, right? That?s to say that the smarter the models are in a general sense, isn?t correlated with their ability to, when they don?t know something, say that they don?t know. It?s interesting that Gemini three pro preview was a big leap over here. Gemini 2.5. Flash and, and, and 2.5 pro, but, and if I add pro quickly here.

swyx [00:32:07]: I bet pro?s really good. Uh, actually no, I meant, I meant, uh, the GPT pros.

George [00:32:12]: Oh yeah.

swyx [00:32:13]: Cause GPT pros are rumored. We don?t know for a fact that it?s like eight runs and then with the LM judge on top. Yeah.

George [00:32:20]: So we saw a big jump in, this is accuracy. So this is just percent that they get, uh, correct and Gemini three pro knew a lot more than the other models. And so big jump in accuracy. But relatively no change between the Google Gemini models, between releases. And the hallucination rate. Exactly. And so it?s likely due to just kind of different post-training recipe, between the, the Claude models. Yeah.

Micah [00:32:45]: Um, there?s, there?s driven this. Yeah. You can, uh, you can partially blame us and how we define intelligence having until now not defined hallucination as a negative in the way that we think about intelligence.

swyx [00:32:56]: And so that?s what we?re changing. Uh, I know many smart people who are confidently incorrect.

George [00:33:02]: Uh, look, look at that. That, that, that is very humans. Very true. And there?s times and a place for that. I think our view is that hallucination rate makes sense in this context where it?s around knowledge, but in many cases, people want the models to hallucinate, to have a go. Often that?s the case in coding or when you?re trying to generate newer ideas. One eval that we added to artificial analysis is, is, is critical point and it?s really hard, uh, physics problems. Okay.

swyx [00:33:32]: And is it sort of like a human eval type or something different or like a frontier math type?

George [00:33:37]: It?s not dissimilar to frontier frontier math. So these are kind of research questions that kind of academics in the physics physics world would be able to answer, but models really struggled to answer. So the top score here is not 9%.

swyx [00:33:51]: And when the people that, that created this like Minway and, and, and actually off via who was kind of behind sweep and what organization is this? Oh, is this, it?s Princeton.

George [00:34:01]: Kind of range of academics from, from, uh, different academic institutions, really smart people. They talked about how they turn the models up in terms of the temperature as high temperature as they can, where they?re trying to explore kind of new ideas in physics as a, as a thought partner, just because they, they want the models to hallucinate. Um, yeah, sometimes it?s something new. Yeah, exactly.

swyx [00:34:21]: Um, so not right in every situation, but, um, I think it makes sense, you know, to test hallucination in scenarios where it makes sense. Also, the obvious question is, uh, this is one of. Many that there is there, every lab has a system card that shows some kind of hallucination number, and you?ve chosen to not, uh, endorse that and you?ve made your own. And I think that?s a, that?s a choice. Um, totally in some sense, the rest of artificial analysis is public benchmarks that other people can independently rerun. You provide it as a service here. You have to fight the, well, who are we to, to like do this? And your, your answer is that we have a lot of customers and, you know, but like, I guess, how do you converge the individual?

Micah [00:35:08]: I mean, I think, I think for hallucinations specifically, there are a bunch of different things that you might care about reasonably, and that you?d measure quite differently, like we?ve called this a amnesty and solutionation rate, not trying to declare the, like, it?s humanity?s last hallucination. You could, uh, you could have some interesting naming conventions and all this stuff. Um, the biggest picture answer to that. It?s something that I actually wanted to mention. Just as George was explaining, critical point as well is, so as we go forward, we are building evals internally. We?re partnering with academia and partnering with AI companies to build great evals. We have pretty strong views on, in various ways for different parts of the AI stack, where there are things that are not being measured well, or things that developers care about that should be measured more and better. And we intend to be doing that. We?re not obsessed necessarily with that. Everything we do, we have to do entirely within our own team. Critical point. As a cool example of where we were a launch partner for it, working with academia, we?ve got some partnerships coming up with a couple of leading companies. Those ones, obviously we have to be careful with on some of the independent stuff, but with the right disclosure, like we?re completely comfortable with that. A lot of the labs have released great data sets in the past that we?ve used to great success independently. And so it?s between all of those techniques, we?re going to be releasing more stuff in the future. Cool.

swyx [00:36:26]: Let?s cover the last couple. And then we?ll, I want to talk about your trends analysis stuff, you know? Totally.

Micah [00:36:31]: So that actually, I have one like little factoid on omniscience. If you go back up to accuracy on omniscience, an interesting thing about this accuracy metric is that it tracks more closely than anything else that we measure. The total parameter count of models makes a lot of sense intuitively, right? Because this is a knowledge eval. This is the pure knowledge metric. We?re not looking at the index and the hallucination rate stuff that we think is much more about how the models are trained. This is just what facts did they recall? And yeah, it tracks parameter count extremely closely. Okay.

swyx [00:37:05]: What?s the rumored size of GPT-3 Pro? And to be clear, not confirmed for any official source, just rumors. But rumors do fly around. Rumors. I get, I hear all sorts of numbers. I don?t know what to trust.

Micah [00:37:17]: So if you, if you draw the line on omniscience accuracy versus total parameters, we?ve got all the open ways models, you can squint and see that likely the leading frontier models right now are quite a lot bigger than the ones that we?re seeing right now. And the one trillion parameters that the open weights models cap out at, and the ones that we?re looking at here, there?s an interesting extra data point that Elon Musk revealed recently about XAI that for three trillion parameters for GROK 3 and 4, 6 trillion for GROK 5, but that?s not out yet. Take those together, have a look. You might reasonably form a view that there?s a pretty good chance that Gemini 3 Pro is bigger than that, that it could be in the 5 to 10 trillion parameters. To be clear, I have absolutely no idea, but just based on this chart, like that?s where you would, you would land if you have a look at it. Yeah.

swyx [00:38:07]: And to some extent, I actually kind of discourage people from guessing too much because what does it really matter? Like as long as they can serve it as a sustainable cost, that?s about it. Like, yeah, totally.

George [00:38:17]: They?ve also got different incentives in play compared to like open weights models who are thinking to supporting others in self-deployment for the labs who are doing inference at scale. It?s I think less about total parameters in many cases. When thinking about inference costs and more around number of active parameters. And so there?s a bit of an incentive towards larger sparser models. Agreed.

Micah [00:38:38]: Understood. Yeah. Great. I mean, obviously if you?re a developer or company using these things, not exactly as you say, it doesn?t matter. You should be looking at all the different ways that we measure intelligence. You should be looking at cost to run index number and the different ways of thinking about token efficiency and cost efficiency based on the list prices, because that?s all it matters.

swyx [00:38:56]: It?s not as good for the content creator rumor mill where I can say. Oh, GPT-4 is this small circle. Look at GPT-5 is this big circle. And then there used to be a thing for a while. Yeah.

Micah [00:39:07]: But that is like on its own, actually a very interesting one, right? That is it just purely that chances are the last couple of years haven?t seen a dramatic scaling up in the total size of these models. And so there?s a lot of room to go up properly in total size of the models, especially with the upcoming hardware generations. Yes.

swyx [00:39:29]: So, you know. Taking off my shitposting face for a minute. Yes. Yes. At the same time, I do feel like, you know, especially coming back from Europe, people do feel like Ilya is probably right that the paradigm is doesn?t have many more orders of magnitude to scale out more. And therefore we need to start exploring at least a different path. GDPVal, I think it?s like only like a month or so old. I was also very positive when it first came out. I actually talked to Tejo, who was the lead researcher on that. Oh, cool. And you have your own version.

George [00:39:59]: It?s a fantastic. It?s a fantastic data set. Yeah.

swyx [00:40:01]: And maybe it will recap for people who are still out of it. It?s like 44 tasks based on some kind of GDP cutoff that?s like meant to represent broad white collar work that is not just coding. Yeah.

Micah [00:40:12]: Each of the tasks have a whole bunch of detailed instructions, some input files for a lot of them. It?s within the 44 is divided into like two hundred and twenty two to five, maybe subtasks that are the level of that we run through the agenda. And yeah, they?re really interesting. I will say that it doesn?t. It doesn?t necessarily capture like all the stuff that people do at work. No avail is perfect is always going to be more things to look at, largely because in order to make the tasks well enough to find that you can run them, they need to only have a handful of input files and very specific instructions for that task. And so I think the easiest way to think about them are that they?re like quite hard take home exam tasks that you might do in an interview process.

swyx [00:40:56]: Yeah, for listeners, it is not no longer like a long prompt. It is like, well, here?s a zip file with like a spreadsheet or a PowerPoint deck or a PDF and go nuts and answer this question.

George [00:41:06]: OpenAI released a great data set and they released a good paper which looks at performance across the different web chat bots on the data set. It?s a great paper, encourage people to read it. What we?ve done is taken that data set and turned it into an eval that can be run on any model. So we created a reference agentic harness that can run. Run the models on the data set, and then we developed evaluator approach to compare outputs. That?s kind of AI enabled, so it uses Gemini 3 Pro Preview to compare results, which we tested pretty comprehensively to ensure that it?s aligned to human preferences. One data point there is that even as an evaluator, Gemini 3 Pro, interestingly, doesn?t do actually that well. So that?s kind of a good example of what we?ve done in GDPVal AA.

swyx [00:42:01]: Yeah, the thing that you have to watch out for with LLM judge is self-preference that models usually prefer their own output, and in this case, it was not. Totally.

Micah [00:42:08]: I think the way that we?re thinking about the places where it makes sense to use an LLM as judge approach now, like quite different to some of the early LLM as judge stuff a couple of years ago, because some of that and MTV was a great project that was a good example of some of this a while ago was about judging conversations and like a lot of style type stuff. Here, we?ve got the task that the grader and grading model is doing is quite different to the task of taking the test. When you?re taking the test, you?ve got all of the agentic tools you?re working with, the code interpreter and web search, the file system to go through many, many turns to try to create the documents. Then on the other side, when we?re grading it, we?re running it through a pipeline to extract visual and text versions of the files and be able to provide that to Gemini, and we?re providing the criteria for the task and getting it to pick which one more effectively meets the criteria of the task. Yeah. So we?ve got the task out of two potential outcomes. It turns out that we proved that it?s just very, very good at getting that right, matched with human preference a lot of the time, because I think it?s got the raw intelligence, but it?s combined with the correct representation of the outputs, the fact that the outputs were created with an agentic task that is quite different to the way the grading model works, and we?re comparing it against criteria, not just kind of zero shot trying to ask the model to pick which one is better.

swyx [00:43:26]: Got it. Why is this an ELO? And not a percentage, like GDP-VAL?

George [00:43:31]: So the outputs look like documents, and there?s video outputs or audio outputs from some of the tasks. It has to make a video? Yeah, for some of the tasks. Some of the tasks.

swyx [00:43:43]: What task is that?

George [00:43:45]: I mean, it?s in the data set. Like be a YouTuber? It?s a marketing video.

Micah [00:43:49]: Oh, wow. What? Like model has to go find clips on the internet and try to put it together. The models are not that good at doing that one, for now, to be clear. It?s pretty hard to do that with a code editor. I mean, the computer stuff doesn?t work quite well enough and so on and so on, but yeah.

George [00:44:02]: And so there?s no kind of ground truth, necessarily, to compare against, to work out percentage correct. It?s hard to come up with correct or incorrect there. And so it?s on a relative basis. And so we use an ELO approach to compare outputs from each of the models between the task.

swyx [00:44:23]: You know what you should do? You should pay a contractor, a human, to do the same task. And then give it an ELO and then so you have, you have human there. It?s just, I think what?s helpful about GDPVal, the OpenAI one, is that 50% is meant to be normal human and maybe Domain Expert is higher than that, but 50% was the bar for like, well, if you?ve crossed 50, you are superhuman. Yeah.

Micah [00:44:47]: So we like, haven?t grounded this score in that exactly. I agree that it can be helpful, but we wanted to generalize this to a very large number. It?s one of the reasons that presenting it as ELO is quite helpful and allows us to add models and it?ll stay relevant for quite a long time. I also think it, it can be tricky looking at these exact tasks compared to the human performance, because the way that you would go about it as a human is quite different to how the models would go about it. Yeah.

swyx [00:45:15]: I also liked that you included Lama 4 Maverick in there. Is that like just one last, like...

Micah [00:45:20]: Well, no, no, no, no, no, no, it is the, it is the best model released by Meta. And... So it makes it into the homepage default set, still for now.

George [00:45:31]: Other inclusion that?s quite interesting is we also ran it across the latest versions of the web chatbots. And so we have...

swyx [00:45:39]: Oh, that?s right.

George [00:45:40]: Oh, sorry.

swyx [00:45:41]: I, yeah, I completely missed that. Okay.

George [00:45:43]: No, not at all. So that, which has a checkered pattern. So that is their harness, not yours, is what you?re saying. Exactly. And what?s really interesting is that if you compare, for instance, Claude 4.5 Opus using the Claude web chatbot, it performs worse than the model in our agentic harness. And so in every case, the model performs better in our agentic harness than its web chatbot counterpart, the harness that they created.

swyx [00:46:13]: Oh, my backwards explanation for that would be that, well, it?s meant for consumer use cases and here you?re pushing it for something.

Micah [00:46:19]: The constraints are different and the amount of freedom that you can give the model is different. Also, you like have a cost goal. We let the models work as long as they want, basically. Yeah. Do you copy paste manually into the chatbot? Yeah. Yeah. That?s, that was how we got the chatbot reference. We?re not going to be keeping those updated at like quite the same scale as hundreds of models.

swyx [00:46:38]: Well, so I don?t know, talk to a browser base. They?ll, they?ll automate it for you. You know, like I have thought about like, well, we should turn these chatbot versions into an API because they are legitimately different agents in themselves. Yes. Right. Yeah.

Micah [00:46:53]: And that?s grown a huge amount of the last year, right? Like the tools. The tools that are available have actually diverged in my opinion, a fair bit across the major chatbot apps and the amount of data sources that you can connect them to have gone up a lot, meaning that your experience and the way you?re using the model is more different than ever.

swyx [00:47:10]: What tools and what data connections come to mind when you say what?s interesting, what?s notable work that people have done?

Micah [00:47:15]: Oh, okay. So my favorite example on this is that until very recently, I would argue that it was basically impossible to get an LLM to draft an email for me in any useful way. Because most times that you?re sending an email, you?re not just writing something for the sake of writing it. Chances are context required is a whole bunch of historical emails. Maybe it?s notes that you?ve made, maybe it?s meeting notes, maybe it?s, um, pulling something from your, um, any of like wherever you at work store stuff. So for me, like Google drive, one drive, um, in our super base databases, if we need to do some analysis or some data or something, preferably model can be plugged into all of those things and can go do some useful work based on it. The things that like I find most impressive currently that I am somewhat surprised work really well in late 2025, uh, that I can have models use super base MCP to query read only, of course, run a whole bunch of SQL queries to do pretty significant data analysis. And. And make charts and stuff and can read my Gmail and my notion. And okay. You actually use that. That?s good. That?s, that?s, that?s good. Is that a cloud thing? To various degrees of order, but chat GPD and Claude right now, I would say that this stuff like barely works in fairness right now. Like.

George [00:48:33]: Because people are actually going to try this after they hear it. If you get an email from Micah, odds are it wasn?t written by a chatbot.

Micah [00:48:38]: So, yeah, I think it is true that I have never actually sent anyone an email drafted by a chatbot. Yet.

swyx [00:48:46]: Um, and so you can, you can feel it right. And yeah, this time, this time next year, we?ll come back and see where it?s going. Totally. Um, super base shout out another famous Kiwi. Uh, I don?t know if you?ve, you?ve any conversations with him about anything in particular on AI building and AI infra.

George [00:49:03]: We have had, uh, Twitter DMS, um, with, with him because we?re quite big, uh, super base users and power users. And we probably do some things more manually than we should in. In, in super base support line because you?re, you?re a little bit being super friendly. One extra, um, point regarding, um, GDP Val AA is that on the basis of the overperformance of the models compared to the chatbots turns out, we realized that, oh, like our reference harness that we built actually white works quite well on like gen generalist agentic tasks. This proves it in a sense. And so the agent harness is very. Minimalist. I think it follows some of the ideas that are in Claude code and we, all that we give it is context management capabilities, a web search, web browsing, uh, tool, uh, code execution, uh, environment. Anything else?

Micah [00:50:02]: I mean, we can equip it with more tools, but like by default, yeah, that?s it. We, we, we give it for GDP, a tool to, uh, view an image specifically, um, because the models, you know, can just use a terminal to pull stuff in text form into context. But to pull visual stuff into context, we had to give them a custom tool, but yeah, exactly. Um, you, you can explain an expert. No.

George [00:50:21]: So it?s, it, we turned out that we created a good generalist agentic harness. And so we, um, released that on, on GitHub yesterday. It?s called stirrup. So if people want to check it out and, and it?s a great, um, you know, base for, you know, generalist, uh, building a generalist agent for more specific tasks.

Micah [00:50:39]: I?d say the best way to use it is get clone and then have your favorite coding. Agent make changes to it, to do whatever you want, because it?s not that many lines of code and the coding agents can work with it. Super well.

swyx [00:50:51]: Well, that?s nice for the community to explore and share and hack on it. I think maybe in, in, in other similar environments, the terminal bench guys have done, uh, sort of the Harbor. Uh, and so it?s, it?s a, it?s a bundle of, well, we need our minimal harness, which for them is terminus and we also need the RL environments or Docker deployment thing to, to run independently. So I don?t know if you?ve looked at it. I don?t know if you?ve looked at the harbor at all, is that, is that like a, a standard that people want to adopt?

George [00:51:19]: Yeah, we?ve looked at it from a evals perspective and we love terminal bench and, and host benchmarks of, of, of terminal mention on artificial analysis. Um, we?ve looked at it from a, from a coding agent perspective, but could see it being a great, um, basis for any kind of agents. I think where we?re getting to is that these models have gotten smart enough. They?ve gotten better, better tools that they can perform better when just given a minimalist. Set of tools and, and let them run, let the model control the, the agentic workflow rather than using another framework that?s a bit more built out that tries to dictate the, dictate the flow. Awesome.

swyx [00:51:56]: Let?s cover the openness index and then let?s go into the report stuff. Uh, so that?s the, that?s the last of the proprietary art numbers, I guess. I don?t know how you sort of classify all these. Yeah.

Micah [00:52:07]: Or call it, call it, let?s call it the last of like the, the three new things that we?re talking about from like the last few weeks. Um, cause I mean, there?s a, we do a mix of stuff that. Where we?re using open source, where we open source and what we do and, um, proprietary stuff that we don?t always open source, like long context reasoning data set last year, we did open source. Um, and then all of the work on performance benchmarks across the site, some of them, we looking to open source, but some of them, like we?re constantly iterating on and so on and so on and so on. So there?s a huge mix, I would say, just of like stuff that is open source and not across the side. So that?s a LCR for people. Yeah, yeah, yeah, yeah.

swyx [00:52:41]: Uh, but let?s, let?s, let?s talk about open.

Micah [00:52:42]: Let?s talk about openness index. This. Here is call it like a new way to think about how open models are. We, for a long time, have tracked where the models are open weights and what the licenses on them are. And that?s like pretty useful. That tells you what you?re allowed to do with the weights of a model, but there is this whole other dimension to how open models are. That is pretty important that we haven?t tracked until now. And that?s how much is disclosed about how it was made. So transparency about data, pre-training data and post-training data. And whether you?re allowed to use that data and transparency about methodology and training code. So basically, those are the components. We bring them together to score an openness index for models so that you can in one place get this full picture of how open models are.

swyx [00:53:32]: I feel like I?ve seen a couple other people try to do this, but they?re not maintained. I do think this does matter. I don?t know what the numbers mean apart from is there a max number? Is this out of 20?

George [00:53:44]: It?s out of 18 currently, and so we?ve got an openness index page, but essentially these are points, you get points for being more open across these different categories and the maximum you can achieve is 18. So AI2 with their extremely open OMO3 32B think model is the leader in a sense.

swyx [00:54:04]: It?s hooking face.

George [00:54:05]: Oh, with their smaller model. It?s coming soon. I think we need to run, we need to get the intelligence benchmarks right to get it on the site.

swyx [00:54:12]: You can?t have it open in the next. We can not include hooking face. We love hooking face. We?ll have that, we?ll have that up very soon. I mean, you know, the refined web and all that stuff. It?s, it?s amazing. Or is it called fine web? Fine web. Fine web.

Micah [00:54:23]: Yeah, yeah, no, totally. Yep. One of the reasons this is cool, right, is that if you?re trying to understand the holistic picture of the models and what you can do with all the stuff the company?s contributing, this gives you that picture. And so we are going to keep it up to date alongside all the models that we do intelligence index on, on the site. And it?s just an extra view to understand.

swyx [00:54:43]: Can you scroll down to this? The, the, the, the trade-offs chart. Yeah, yeah. That one. Yeah. This, this really matters, right? Obviously, because you can be super open, but dumb. I mean, obviously goes the wrong way here. Right.

George [00:54:55]: A lot of people would like to see labs hill climb on the, and target.

Micah [00:55:00]: This is the access to hill climb. Yeah. Unfortunately, it might be fundamentally true that the, the slum will always go this direction because once you open something up, then everyone else can get to the level of what you have now.

swyx [00:55:11]: Well, so let me, let me tweak your points. You have, I have a point system, right? Like you have these like numbers on the point system and it go up to 18, you know, but like, just because I have a little bit of open data doesn?t mean I?m necessarily that much better in someone who put a lot of effort into their open ways, it is that it?s smarter. So I might, I might just mess with the point system to make sure that like, I?m accurately representing the, the contribution to the open openness.

Micah [00:55:36]: It is hard to wait for the materiality of the contribution to open source. We tried to make it so that it is quite well-defined and no one can disagree about which category things should be in. So we?re not saying this was a big contribution or a small contribution in terms of impact on the industry or anything. It?s just how much of your data did you release? I would say that it is still valid to say that we trained a model that?s not that smart, maybe even not at the frontier for a particular size category, but we chose to open up all the data, all the training code. That is a very useful exercise for the industry. And we want to recognize that even if the smartest model in the category.

swyx [00:56:18]: Yeah. And also a special shout out to NVIDIA and Emotron, which doesn?t get enough credit for the amount of stuff that they do. And honestly, it?s a sales enablement for NVIDIA as well. The fact that they can do this is... Side project.

Micah [00:56:29]: Totally. But I mean, it is true that NVIDIA have actually put an enormous amount of effort over the last year, especially into the Nematron models.

swyx [00:56:35]: Yeah. And so many people actually use it for synthetic data and stuff. It?s a pretty interesting secret of the industry that NVIDIA holds up all these guys.

Micah [00:56:45]: I mean, it?s in their interest for there to be more AI.

swyx [00:56:49]: So obviously, I think you want to push openness as having an index. Every index that you push has encoded some kind of opinion or value. Yes. I think one of the openness questions from this year was people messing with the license. And so Lama had this, like, if you have 700 million daily active users, you?re not allowed to use our model or you have to talk to us, something like that. So basically, like, what are your customers telling you about the kind of licensing worries that they have? Right. Because obviously, most people will never hit 700 million users.

Micah [00:57:21]: We have like a detailed breakdown of that in the openness index. And that was actually one of the initial questions that took us down the route of wanting to... Do this. Because, yeah, the simplest thing that, like, our opinion is, is that there is a lot of advantage to having, like, an official OSI license like MIT or Apache 2, because then the box is just checked. You don?t even need to read it because it?s just Apache 2 and you can do it ever you want and it?s fine. There are often very good reasons that companies don?t want to release language models with those completely open licenses. The index tells you. So if you get the top category, that?s one of those licenses. You?re totally good. And then... And then we?ve got some lower categories for when attribution is required and then when commercial use is not allowed. Yeah, they?re there.

swyx [00:58:05]: So that?s the openness index. Thank you for doing all those works. Let?s talk a little bit, or at least end the pod, on just the trend reports that you guys do, which is kind of a bit of the bread and butter how you make money. I highly encourage everyone to see George?s talk at World?s Fair, which gives a little bit of a preview. And you were very excited about talking about the smiling curve, or I don?t know what you call it. Yeah, yeah, yeah, yeah, let?s talk about that one. Let?s explain it for people. And I might, I might actually put it up because I don?t have it. Yeah, I?ve got to copy the slide, that?d be, that?d be excellent. It?s important for people to have in their head because, yeah, people only get the marketing message from the labs that, oh, we?re cutting costs all the time.

Micah [00:58:41]: Yeah, yeah, but it?s, it?s true. It?s it?s not the whole picture. So, okay. A couple of like the big trends that we track at Artificial Analysis over time and that like we?re always showing charts of on the trends page in these reports and stuff. One, that the cost of intelligence has been falling dramatically. Over the last couple of years, the best way to think about that is that the cost for each terror of intelligence has been dropping the, like one fact on that is that you can get intelligence at the level of GPT-4 for over a hundred times cheaper than GPT-4 was at launch right now. I think my number is a thousand actually.

swyx [00:59:16]: If you look at the Amazon Nova models, which are very, very cheap. Yeah.

Micah [00:59:21]: Like my, my conservative statement is normally like, but in fairness, this slide. Like I, we were actually saying for the podcast, right. It?s like maybe six months old now and it?s conceptually still correct, but like could actually probably do a tweak on the exact numbers because like the market?s moving so quickly.

swyx [00:59:37]: If you?re feeling kick it off, I mean, we?ll have this chart.

Micah [00:59:39]: I told people to watch the world?s fair talk, but let?s, let?s introduce what context makes you make something like this. There are two trends that seem to not make sense together, both of which we talk a lot about at Artificial Analysis and are very important to developers building stuff in AI. The first is that the cost of intelligence for each level of intelligence has been dropping dramatically over the last couple of years. We track the cost to run Artificial Analysis Intelligence Index for each bucket of Intelligence Index scores and each bucket, you just see the line go down really, really quickly and actually go down more quickly to each new level of intelligence that?s been achieved over the last couple of years. So the rate of that cost has actually been going up. So. Yeah. We?ve got that being true. And yet it is clearly possible to spend quite a lot more on AI inference now than it was a couple of years ago.

George [01:00:34]: NVIDIA stock go up.

swyx [01:00:36]: It?s going, it?s going really up. Uh, I just heard from a friend?s startup that just went through the shift zero. They?re spending $5,000 per employee on coding agents spend alone. That?s ridiculous. That?s an impressive number.

Micah [01:00:49]: We need to get our numbers up. We?re, uh, we?re, we?re not quite hitting, hitting.

swyx [01:00:52]: Well, I was like, it?s so high down. I?m like, are you doing something wrong? Yeah.

Micah [01:00:55]: Cause there are some efficiency questions along the way, but like you can make AI inference useful to that level in a bunch of ways that I can imagine. Right. Yeah. Um, I, I don?t think that?s that nuts. Um, but basically the, the reason we made this slide to answer the question, right. Is to show that the crazy thing is that it is actually true. We?ve had this hundred X to a thousand X decline in the cost of GPT four level intelligence on the left-hand side. And yet on the right-hand side, because the multipliers are so big for the fact that even though. Small models can do GPT four level. Now we still want to use big models and probably bigger than ever models to, um, do frontier level intelligence. We?ve got reasoning models using tokens, and then we?re throwing them in these, them in these agentic workflows where they?re consuming enormous numbers of input tokens and making enormous numbers of output tokens working for a really long time. Those two things taken together, get you back to, we can spend enormously more today than we could a couple of years ago. Yep.

George [01:01:50]: I think that?s right. There?s a number of drivers at play and we kind of outline kind of. Six key ones here. Um, but you know, as complex as changing quickly, all of these have changed very dramatically in the last, uh, in the last 12 months.

swyx [01:02:04]: Let?s pick on hardware efficiency since you also have, you also track hardware stuff. And I think the general assertion or the message is that the efficiency from next gen Nvidia chips is actually not 4X. So you have what? 3X or 4X? You have 3X in here and it?s, it?s like 2X maybe, or it?s more of like a. Power story rather than like a share sort of compute tokens efficiency story. But yeah, what, what?s going on in, in hardware. Okay.

Micah [01:02:31]: So the, the, the, the odds, unfortunately, uh, is it depends and it just depends massively on like so many things across a bunch of different types of workloads and ways to think about it. So one of the simplest ways to think about this is to take single relevant model, to think about serving it at speeds that are realistic for what you actually might want to hit. And can afford to hit, and then think about the throughput per GPU that you can achieve serving the model at those speeds. Rease. One of the reasons that?s important is that there?s a trade-off between the throughput per GPU that you can achieve and the per user speed that you can achieve. And as a, it costs more to serve stuff fast to, to users. When you run all of that for especially big sparse models, you can get a lot better than two or three X gain going from Hopper to Blackwell generation to video. I am. This shouldn?t be too controversial. Let?s say I?m like, I?m. I?m pretty confident that Blackwell has delivered pretty enormous gains and that the next couple of years of NVIDIA?s roadmap are going to continue to deliver quite enormous gains and that those will actually come through as lower total cost per token to the companies that are running models on them and will allow bigger models will allow way more tokens to be made for lower cost and that that?s gonna continue these things also stack on all of the software and model improvements. So basically like my prediction across like both sides of that, like smile chart, uh, that we?re gonna see the left-hand side continue to be true and probably like for another order of magnitude and the right-hand side continue to be true for another order of magnitude, and that?s gonna enable a whole lot of things.

swyx [01:04:12]: Okay. Well, I?ll push on, uh, let?s go back to the, the, the small chart. I?ll push back on sparsity, right? Uh, we?ve gone a long way on sparsity. Deep seek was a major pusher of fine grain experts. Let?s call it. Yep. Right. Well, I have a mental number of sparsity in terms of let?s say active params versus total params. And that number went from 25%, let?s say down to like 15, right? You obviously can?t really go below, I don?t know, five. Is that obvious? So there?s a lower limit to, to sparsity is what I?m saying. I don?t know that that?s that obvious actually. All right.

Micah [01:04:45]: Um, there, there must be a limit somewhere, right? Yeah, exactly. But we?ve got numbers in the wild that are quite a lot lower than that right now. So the GBD OSS models, like the big ones at about 5%, um, active, Kimmy K2, is it like 3% active? Oh, okay. I think, pretty sure.

swyx [01:05:05]: I?ve looked at those numbers. I calculated them. I don?t remember. Yeah. But I remember thinking like, this must be it.

George [01:05:11]: Your 5% is exactly like around the ballpark for the open weights models of, of what?s released today. I think one interesting that gives me kind of pause when thinking that it won?t go, the sparsity won?t go high. Or the number of percentage of active parameters lower is that we, in our benchmark, see a lot of performance, uh, correlated more with, uh, total parameters than active and not that correlated with how sparse, like the models are. Our accuracy, benchmark as part of a omniscience, it?s very correlated with total. It?s not correlated with, with active, uh, parameters, which I think is very at all, which is very, very interesting. And so I think, yeah, they could, they could be quite. A bit, um, to go here. Awesome.

swyx [01:05:55]: Well, we don?t have that much time, but I w I did want to leave some room to cover reasoning and non-reasoning models and token efficiency. Let?s do that. So at a high, at a super high level, people have to classify this binary thing of reasoning versus non-reasoning. People who are insider have some discomfort with that because basically you just have to think tag or no think tag. How have you guys decided to approach this? And also how does that laid out in, over the course of the year where we have things like GPT-5, which is a model. Right.

Micah [01:06:24]: Let?s say GPT-5 in chat GPT, the consumer experience as a model router, when you?re hitting the API, like we can, you can pick the different versions and you can pick reasoning strength of the different versions, but that, that goes to why this is now such a complex thing. So earlier this year, and probably when you and George last spoke for the AI engineers world?s fair, we had this great slide that was super easy, where we would show that the average reasoning model is using 10 times the number of tokens per query in our intelligence index as the average non-reasoning model. And there was this moment where that was a pretty clear distinction and extremely useful to look at it just like that. Definitely no longer the case, not least because you can think about reasoning strength for a bunch of these different models, but particularly because different models have wildly different token efficiency now, more than an order of magnitude in difference. That means that the way that you probably need to think about cost for any application is to use something like our cost around intelligence index metric as the starting point. Right. for what it?s going to look like for these different models, these different reasoning strengths, and this continuous spectrum from non-reasoning to reasoning. That?s basically like where we?re at. So we will still show reasoning and non-reasoning and define reasoning as when there is that separated chain of thought that you?re getting at a different parameter in an API normally, but it doesn?t necessarily anymore mean that that model is actually going to have longer end-to-end latency that is going to use more tokens than something that is branded

swyx [01:07:51]: in a non-reasoning model for the same task. That?s true. I think 5.1 was it. And then 5.1 Codex had these chart, which was super nice of this, like, let?s say bottom 10 percentile query being faster, but top 10 percentile being longer. And that?s a kind of the efficiency chart

Micah [01:08:10]: you want to see, right? Yeah. So that is an extra thing. Let?s say that we?ve got, that?s a really important extra thing though, right? That you?ve got not just the average number of token span used by the model, which we cover really well right now, but the behavior that you want in the model is it to use more tokens when it needs more tokens and not to use more tokens when it doesn?t need more tokens. So that?s what OpenAI, we?re basically claiming that 5.1 Codex is better at. We don?t actually publish anything on this right now, but have tracked it a bunch internally in our internal analytics on evals across all the models that we run, where we look at the difficulty to questions and the correlation between token usage and difficulty and net net, surprise, surprise, like models have got. I think going into next year, that?s going to be really important, especially as you multiply it by the number of steps in an agentic workflow that a model has to take to get to an answer. We are going to care a lot about token efficiency and number of turns efficiency for getting to what

swyx [01:09:08]: we want. Which would you rather have token efficiency or number of turns efficiency? Or like, which is more important to work on?

Micah [01:09:16]: it depends on the application and both are going to be really important.

George [01:09:18]: Uh, yeah.

Micah [01:09:20]: Well, total cost is just-

swyx [01:09:21]: TalBench Retail, TalBench Airline.

George [01:09:23]: Yeah. Interestingly in Tal, um, Tal2Bench Telecom, it?s cheaper to run, you know, on a per token basis, more expensive models like a GBD5 compared to some smaller open source models, because the, um, some of the GBD5, for instance, uh, got to the answer faster. And so it was able to resolve the customer?s query faster and fewer turns. And maybe it used more tokens per turn, but it certainly- It?s not going to cost more per token. So you would always rather use GBD5 in, in, in, in that scenario. And so I think that?s what, that?s where we?re getting to. I think number of turns is, it?s going to be a metric that we?re going to be talking about a lot more. And, uh, I think it?ll be something that people want to really start to think about, uh, a lot more.

swyx [01:10:06]: There?s a trade-off in benchmarking here where most benchmarks needs to be one turn to be autonomous, to be parallelized and all that. But most, a lot of real life use cases need to be multi-turn and especially like quick multi-turns. So you can align. Yeah.

Micah [01:10:19]: Yeah. I mean, I, I would say that historically benchmarks have been single turn, but I wouldn?t say they need to be at all into the future, right? Like we have a couple of agentic benchmarks in the index right now and GDP that we were talking about. We let the models do up to a hundred turns and, um, our stirrup agent to do that evil. And we?re going to build similar stuff like that in the future. It definitely is hard and you?ve got whole kinds of infrastructure problems to run that and exactly as you say, parallelize it because we need to run that on hundreds of models and we want to do that really fast when you want us to come out and with labs want us to run it on their models,

swyx [01:10:53]: but you can do it. We?re putting in the work to build that stuff and it?s going to be great. Okay. So we?ve covered, I mean, there?s a lot more to cover and you haven?t even touched on

George [01:11:01]: multimodal, which is huge. We also do speech benchmarking, image benchmarking, uh, video

swyx [01:11:09]: benchmarking, hardware. I like the way that you?ve done it because they?re very smart, which is a video takes a long time. So you pre-generate, right? So then people just pick their preferences and you can see the, the overall arena results. And you also avoid like any sensitivity issues

Micah [01:11:23]: around the unsafe content that is being generated. Yeah. And you can see it as a good, good thing, a bad thing, depending on what your view is. But it means that we have a quite active creative direction approach to trying to understand what creative professionals and users want to do with those image and video models. And so that we can be directing the arenas in our categories toward gathering data, votes on what people care about. One call out actually to listeners, like if you are using our arenas is that you can submit requests to us for things that we should cover. I didn?t know that. Yeah. Understudied categories, areas that you think the models are bad at and the labs don?t focus on enough. Like if you want something solved, one of the levers that you have is send us a couple of prompts on it. We might be able to get a category going on it. And this thing that we were talking about earlier, right? That once things get measured, they can get targeted. You can make that work for you.

swyx [01:12:18]: For me as a content creator, infographics, very needed. I took the latest deep seek paper and they had some descriptions of their search agents and their coding agents and I put it in and I created an infographic. And I just think like as I said, industrial use case that doesn?t require a lot of, I guess, design tastes, but just requires some, you need to conform to some preset references, which is something that is increasingly important, especially in like the nano banana series. But yeah, and I think that?s the key there. I think it?s important to be able to I think OpenAI is releasing Image 2 soon, which is going to have that. So I think it?s all of a kind where people need to incentivize workhorse use cases and not just art. I don?t know. Totally. Yeah. What are we going to be talking about next year? What?s emerging that you?re seeing and maybe not in the discussion?

Micah [01:13:06]: The first answer that I?ll give to that is the boring answer is that on most of our charts, the lines go in a particular direction and our overall prediction is the lines are going to keep going in that direction. We?re going to do a lot and do a lot to be as useful as possible to developers and companies to measure what?s important on every one of those and along those lines. But I think we?re going to talk about similar stuff. It?s just that we?re going to have continued on this trajectory for another year and things are going to feel pretty different because of that happening. I know this is the boring answer to that question. No, no.

swyx [01:13:36]: I mean, I?m a fan of things that, truths that don?t change because you can build and plan for that. And I think in media in general, in the podcast business, newsletters, you know, there?s a Twitter business, Twitter business, people are addicted to change, like, oh, everything?s breaking. Everything?s, no, like there?s some truths that aren?t just constants that you can plan on and build. And yeah.

George [01:13:58]: I think one of the truths is that the demand for AI intelligence and smarter AI intelligence is going to be insatiable. Some people disagree that, okay, once we reach certain thresholds, then you don?t need more intelligence. I think to that, I ask people, have they ever worked with? Or managed someone in a work environment and wouldn?t press the button that they were smarter to make them smarter or better at their job or would they never press that for themselves? And I?m not sure that that?s, that?s the case, but I think for artificial analysis, we?ll keep benchmarking raw intelligence, but we also want to think about it and explore models more deeply across other axes as well. I think hallucinations, the start of that, but we?re getting into wanting to support people and understanding, okay, the behavior, the person personalities. Of the models to help people make more nuanced decisions, you?re going to have a personality bench.

swyx [01:14:52]: Maybe that is a direction that Chadji opening eyes leaning into a lot. So if you manage to solve that, you should definitely talk to Fiji and Roon. Oh, okay. Yeah. So what is going to be included in, let?s say like a V3 of the intelligence index, because obviously you?re going to saturate in March.

Micah [01:15:10]: Why don?t we break it now? How soon is the podcast going to come out? Whenever you want. Okay. So we?re at V3 right now. So the, so the, the, the version that we, that?s going inside is, is, is, is V3 V4 is what we?re going to call the next, you know, major of it. Surprise, surprise. We?re going to be adding several of the things that we?ve actually talked about today that we?ve launched over the last few weeks. So it?s not, that?s not going to be wildly shocking, but some of the things that are most exciting is that adding GDP value is going to give us this general agentic performance in a really strong way in intelligence index and in critical point, the, um, physics, EBL, George was talking about similar to frontier math. Yeah. That?s very interesting. That gives us completely new view with a brand new data set of very, very hard research problems. We are going to be using Omniscience and we are going to be using hallucination rate. The exact way is that all of those are going to come together. Um, The waitings is going to be hard because the numbers are different. Yeah. We?re going to make sure that we don?t do anything to cause odd distortions and stuff that could be misleading. But every time you version it, you have a one-time reset of the Exactly. Yeah. That?s exactly how we think about it. We will make sure that within each version number that there?s no parliamentary issue. No drift in any of the scores so that people can rely on them and reference them. You just have to watch out for that version number. Once it?s v4.1, those numbers won?t be compatible with v4.

swyx [01:16:23]: Of course. There?s a little bit of debate over the accuracy of TileBench. I don?t know if you?re clued in to what?s going on. Apparently, a very high number of TileBench tests are impossible.

Micah [01:16:34]: Potentially for the earlier versions, Tile2Bench Telecom, we?re pretty convinced is pretty good. If anything, the only issue there is that models have got very good at doing it. And so, like anything... Tile3. Yeah.

swyx [01:16:49]: On we go. Yeah, on we go. Okay, well, thank you so much for providing such a great service to the industry. I?m glad to at least know you guys before you got famous and now you are famous.

Micah [01:16:59]: Oh, look, our pleasure. We really appreciate your support along the way. I wasn?t kidding at the start, right? That it was a quite material moment for us when artificial analysis was covered on Latent Space. Some random guy. And San Francisco mentions you. I was a fan of Latent Space for like a year before you mentioned us. So, I?d been listening. I don?t think I was familiar with you personally yet at that point. But I listened to your voice probably for many, many hours. And so, once you mentioned it, I got to get to know you and meet you for the first time nearly a couple of years ago. It was really cool, honestly. So, yeah, it?s great to be here.

George [01:17:36]: And thanks for being such a great member of the community and kind of spotlighting projects, projects which don?t have attention and bringing them to your audience. Yeah.

swyx [01:17:44]: Well, actually, so it wasn?t me, right? Someone in the Discord dropped it in our Discord. And I rely on our community and it kind of feeds itself, right? Nice. So, someone brought it to my attention. I don?t know who. We should probably go back and check. But once I saw it, I was like, this looks good. This is something I always wanted. I wanted to build it. I was too shy or dumb or lazy to build it. And you guys did. And now it?s a whole thing. So, thank you for being here.

George [01:18:08]: I built some really cool other stuff like this pod. Yeah. Yeah. Totally. So, thank you. That?s it. Great. Cool. Thanks.

We are reupping this episode after LMArena announced their fresh Series A (https://www.theinformation.com/articles/ai-evaluation-startup-lmarena-valued-1-7-billion-new-funding-round?rc=luxwz4), raising $150m at a $1.7B valuation, with $30M annualized consumption revenue (aka $2.5m MRR) after their September evals product launch.

?-

From building LMArena in a Berkeley basement to raising $100M and becoming the de facto leaderboard for frontier AI, Anastasios Angelopoulos returns to Latent Space to recap 2025 in one of the most influential platforms in AI?trusted by millions of users, every major lab, and the entire industry to answer one question: which model is actually best for real-world use cases? We caught up with Anastasios live at NeurIPS 2025 to dig into the origin story (spoiler: it started as an academic project incubated by Anjney Midha at a16z, who formed an entity and gave grants before they even committed to starting a company), why they decided to spin out instead of staying academic or nonprofit (the only way to scale was to build a company), how they?re spending that $100M (inference costs, React migration off Gradio, and hiring world-class talent across ML, product, and go-to-market), the leaderboard delusion controversy and why their response demolished the paper?s claims (factual errors, misrepresentation of open vs. closed source sampling, and ignoring the transparency of preview testing that the community loves), why platform integrity comes first (the public leaderboard is a charity, not a pay-to-play system?models can?t pay to get on, can?t pay to get off, and scores reflect millions of real votes), how they?re expanding into occupational verticals (medicine, legal, finance, creative marketing) and multimodal arenas (video coming soon), why consumer retention is earned every single day (sign-in and persistent history were the unlock, but users are fickle and can leave at any moment), and his vision for Arena as the central evaluation platform that provides the North Star for the industry?constantly fresh, immune to overfitting, and grounded in millions of real-world conversations from real users.

We discuss:

* The $100M raise: use of funds is primarily inference costs (funding free usage for tens of millions of monthly conversations), React migration off Gradio (custom loading icons, better developer hiring, more flexibility), and hiring world-class talent

* The scale: 250M+ conversations on the platform, tens of millions per month, 25% of users do software for a living, and half of users are now logged in

* The leaderboard illusion controversy: Cohere researchers claimed undisclosed private testing created inequities, but Arena?s response demolished the paper?s factual errors (misrepresented open vs. closed source sampling, ignored transparency of preview testing that the community loves)

* Why preview testing is loved by the community: secret codenames (Gemini Nano Banana, named after PM Naina?s nickname), early access to unreleased models, and the thrill of being first to vote on frontier capabilities

* The Nano Banana moment: changed Google?s market share overnight, billions of dollars in stock movement, and validated that multimodal models (image generation, video) are economically critical for marketing, design, and AI-for-science

* New categories: occupational and expert arenas (medicine, legal, finance, creative marketing), Code Arena, and video arena coming soon

Full Video Episode

Timestamps

00:00:00 Introduction: Anastasios from Arena and the LM Arena Journey00:01:36 The Anjney Midha Incubation: From Berkeley Basement to Startup00:02:47 The Decision to Start a Company: Scaling Beyond Academia00:03:38 The $100M Raise: Use of Funds and Platform Economics00:05:10 Arena's User Base: 5M+ Users and Diverse Demographics00:06:02 The Competitive Landscape: Artificial Analysis, AI.xyz, and Arena's Differentiation00:08:12 Educational Value and Learning from the Community00:08:41 Technical Migration: From Gradio to React and Platform Evolution00:10:18 Leaderboard Delusion Paper: Addressing Critiques and Maintaining Integrity00:12:29 Nano Banana Moment: How Preview Models Create Market Impact00:13:41 Multimodal AI and Image Generation: From Skepticism to Economic Value00:15:37 Core Principles: Platform Integrity and the Public Leaderboard as Charity00:18:29 Future Roadmap: Expert Categories, Multimodal, Video, and Occupational Verticals00:19:10 API Strategy and Focus: Doing One Thing Well00:19:51 Community Management and Retention: Sign-In, History, and Daily Value00:22:21 Partnerships and Agent Evaluation: From Devon to Full-Featured Harnesses00:21:49 Hiring and Building a High-Performance Team

From undergraduate research seminars at Princeton to winning Best Paper award at NeurIPS 2025, Kevin Wang, Ishaan Javali, Micha? Bortkiewicz, Tomasz Trzcinski, Benjamin Eysenbach defied conventional wisdom by scaling reinforcement learning networks to 1,000 layers deep?unlocking performance gains that the RL community thought impossible. We caught up with the team live at NeurIPS to dig into the story behind RL1000: why deep networks have worked in language and vision but failed in RL for over a decade (spoiler: it?s not just about depth, it?s about the objective), how they discovered that self-supervised RL (learning representations of states, actions, and future states via contrastive learning) scales where value-based methods collapse, the critical architectural tricks that made it work (residual connections, layer normalization, and a shift from regression to classification), why scaling depth is more parameter-efficient than scaling width (linear vs. quadratic growth), how Jax and GPU-accelerated environments let them collect hundreds of millions of transitions in hours (the data abundance that unlocked scaling in the first place), the ?critical depth? phenomenon where performance doesn?t just improve?it multiplies once you cross 15M+ transitions and add the right architectural components, why this isn?t just ?make networks bigger? but a fundamental shift in RL objectives (their code doesn?t have a line saying ?maximize rewards??it?s pure self-supervised representation learning), how deep teacher, shallow student distillation could unlock deployment at scale (train frontier capabilities with 1000 layers, distill down to efficient inference models), the robotics implications (goal-conditioned RL without human supervision or demonstrations, scaling architecture instead of scaling manual data collection), and their thesis that RL is finally ready to scale like language and vision?not by throwing compute at value functions, but by borrowing the self-supervised, representation-learning paradigms that made the rest of deep learning work.

We discuss:

* The self-supervised RL objective: instead of learning value functions (noisy, biased, spurious), they learn representations where states along the same trajectory are pushed together, states along different trajectories are pushed apart?turning RL into a classification problem

* Why naive scaling failed: doubling depth degraded performance, doubling again with residual connections and layer norm suddenly skyrocketed performance in one environment?unlocking the ?critical depth? phenomenon

* Scaling depth vs. width: depth grows parameters linearly, width grows quadratically?depth is more parameter-efficient and sample-efficient for the same performance

* The Jax + GPU-accelerated environments unlock: collecting thousands of trajectories in parallel meant data wasn?t the bottleneck, and crossing 15M+ transitions was when deep networks really paid off

* The blurring of RL and self-supervised learning: their code doesn?t maximize rewards directly, it?s an actor-critic goal-conditioned RL algorithm, but the learning burden shifts to classification (cross-entropy loss, representation learning) instead of TD error regression

* Why scaling batch size unlocks at depth: traditional RL doesn?t benefit from larger batches because networks are too small to exploit the signal, but once you scale depth, batch size becomes another effective scaling dimension

?

RL1000 Team (Princeton)

* 1000 Layer Networks for Self-Supervised RL: Scaling Depth Can Enable New Goal-Reaching Capabilities: https://openreview.net/forum?id=s0JVsx3bx1

Full Video Episode

Timestamps

00:00:00 Introduction: Best Paper Award and NeurIPS Poster Experience00:01:11 Team Introductions and Princeton Research Origins00:03:35 The Deep Learning Anomaly: Why RL Stayed Shallow00:04:35 Self-Supervised RL: A Different Approach to Scaling00:05:13 The Breakthrough Moment: Residual Connections and Critical Depth00:07:15 Architectural Choices: Borrowing from ResNets and Avoiding Vanishing Gradients00:07:50 Clarifying the Paper: Not Just Big Networks, But Different Objectives00:08:46 Blurring the Lines: RL Meets Self-Supervised Learning00:09:44 From TD Errors to Classification: Why This Objective Scales00:11:06 Architecture Details: Building on Braw and SymbaFowl00:12:05 Robotics Applications: Goal-Conditioned RL Without Human Supervision00:13:15 Efficiency Trade-offs: Depth vs Width and Parameter Scaling00:15:48 JAX and GPU-Accelerated Environments: The Data Infrastructure00:18:05 World Models and Next State Classification00:22:37 Unlocking Batch Size Scaling Through Network Capacity00:24:10 Compute Requirements: State-of-the-Art on a Single GPU00:21:02 Future Directions: Distillation, VLMs, and Hierarchical Planning00:27:15 Closing Thoughts: Challenging Conventional Wisdom in RL Scaling

From creating SWE-bench in a Princeton basement to shipping CodeClash, SWE-bench Multimodal, and SWE-bench Multilingual, John Yang has spent the last year and a half watching his benchmark become the de facto standard for evaluating AI coding agents?trusted by Cognition (Devin), OpenAI, Anthropic, and every major lab racing to solve software engineering at scale. We caught up with John live at NeurIPS 2025 to dig into the state of code evals heading into 2026: why SWE-bench went from ignored (October 2023) to the industry standard after Devin?s launch (and how Walden emailed him two weeks before the big reveal), how the benchmark evolved from Django-heavy to nine languages across 40 repos (JavaScript, Rust, Java, C, Ruby), why unit tests as verification are limiting and long-running agent tournaments might be the future (CodeClash: agents maintain codebases, compete in arenas, and iterate over multiple rounds), the proliferation of SWE-bench variants (SWE-bench Pro, SWE-bench Live, SWE-Efficiency, AlgoTune, SciCode) and how benchmark authors are now justifying their splits with curation techniques instead of just ?more repos,? why Tau-bench?s ?impossible tasks? controversy is actually a feature not a bug (intentionally including impossible tasks flags cheating), the tension between long autonomy (5-hour runs) vs. interactivity (Cognition?s emphasis on fast back-and-forth), how Terminal-bench unlocked creativity by letting PhD students and non-coders design environments beyond GitHub issues and PRs, the academic data problem (companies like Cognition and Cursor have rich user interaction data, academics need user simulators or compelling products like LMArena to get similar signal), and his vision for CodeClash as a testbed for human-AI collaboration?freeze model capability, vary the collaboration setup (solo agent, multi-agent, human+agent), and measure how interaction patterns change as models climb the ladder from code completion to full codebase reasoning.

We discuss:

* John?s path: Princeton ? SWE-bench (October 2023) ? Stanford PhD with Diyi Yang and the Iris Group, focusing on code evals, human-AI collaboration, and long-running agent benchmarks

* The SWE-bench origin story: released October 2023, mostly ignored until Cognition?s Devin launch kicked off the arms race (Walden emailed John two weeks before: ?we have a good number?)

* SWE-bench Verified: the curated, high-quality split that became the standard for serious evals

* SWE-bench Multimodal and Multilingual: nine languages (JavaScript, Rust, Java, C, Ruby) across 40 repos, moving beyond the Django-heavy original distribution

* The SWE-bench Pro controversy: independent authors used the ?SWE-bench? name without John?s blessing, but he?s okay with it (?congrats to them, it?s a great benchmark?)

* CodeClash: John?s new benchmark for long-horizon development?agents maintain their own codebases, edit and improve them each round, then compete in arenas (programming games like Halite, economic tasks like GDP optimization)

* SWE-Efficiency (Jeffrey Maugh, John?s high school classmate): optimize code for speed without changing behavior (parallelization, SIMD operations)

* AlgoTune, SciCode, Terminal-bench, Tau-bench, SecBench, SRE-bench: the Cambrian explosion of code evals, each diving into different domains (security, SRE, science, user simulation)

* The Tau-bench ?impossible tasks? debate: some tasks are underspecified or impossible, but John thinks that?s actually a feature (flags cheating if you score above 75%)

* Cognition?s research focus: codebase understanding (retrieval++), helping humans understand their own codebases, and automatic context engineering for LLMs (research sub-agents)

* The vision: CodeClash as a testbed for human-AI collaboration?vary the setup (solo agent, multi-agent, human+agent), freeze model capability, and measure how interaction changes as models improve

?

John Yang

* SWE-bench: https://www.swebench.com

* X: https://x.com/jyangballin

Full Video Episode

Timestamps

00:00:00 Introduction: John Yang on SWE-bench and Code Evaluations00:00:31 SWE-bench Origins and Devon's Impact on the Coding Agent Arms Race00:01:09 SWE-bench Ecosystem: Verified, Pro, Multimodal, and Multilingual Variants00:02:17 Moving Beyond Django: Diversifying Code Evaluation Repositories00:03:08 Code Clash: Long-Horizon Development Through Programming Tournaments00:04:41 From Halite to Economic Value: Designing Competitive Coding Arenas00:06:04 Ofir's Lab: SWE-ficiency, AlgoTune, and SciCode for Scientific Computing00:07:52 The Benchmark Landscape: TAU-bench, Terminal-bench, and User Simulation00:09:20 The Impossible Task Debate: Refusals, Ambiguity, and Benchmark Integrity00:12:32 The Future of Code Evals: Long Autonomy vs Human-AI Collaboration00:14:37 Call to Action: User Interaction Data and Codebase Understanding Research

From pre-training data curation to shipping GPT-4o, o1, o3, and now GPT-5 thinking and the shopping model, Josh McGrath has lived through the full arc of OpenAI?s post-training evolution?from the PPO vs DPO debates of 2023 to today?s RLVR era, where the real innovation isn?t optimization methods but data quality, signal trust, and token efficiency. We sat down with Josh at NeurIPS 2025 to dig into the state of post-training heading into 2026: why RLHF and RLVR are both just policy gradient methods (the difference is the input data, not the math), how GRPO from DeepSeek Math was underappreciated as a shift toward more trustworthy reward signals (math answers you can verify vs. human preference you can?t), why token efficiency matters more than wall-clock time (GPT-5 to 5.1 bumped evals and slashed tokens), how Codex has changed his workflow so much he feels ?trapped? by 40-minute design sessions followed by 15-minute agent sprints, the infrastructure chaos of scaling RL (?way more moving parts than pre-training?), why long context will keep climbing but agents + graph walks might matter more than 10M-token windows, the shopping model as a test bed for interruptability and chain-of-thought transparency, why personality toggles (Anton vs Clippy) are a real differentiator users care about, and his thesis that the education system isn?t producing enough people who can do both distributed systems and ML research?the exact skill set required to push the frontier when the bottleneck moves every few weeks.

We discuss:

* Josh?s path: pre-training data curation ? post-training researcher at OpenAI, shipping GPT-4o, o1, o3, GPT-5 thinking, and the shopping model

* Why he switched from pre-training to post-training: ?Do I want to make 3% compute efficiency wins, or change behavior by 40%??

* The RL infrastructure challenge: way more moving parts than pre-training (tasks, grading setups, external partners), and why babysitting runs at 12:30am means jumping into unfamiliar code constantly

* How Codex has changed his workflow: 40-minute design sessions compressed into 15-minute agent sprints, and the strange ?trapped? feeling of waiting for the agent to finish

* The RLHF vs RLVR debate: both are policy gradient methods, the real difference is data quality and signal trust (human preference vs. verifiable correctness)

* Why GRPO (from DeepSeek Math) was underappreciated: not just an optimization trick, but a shift toward reward signals you can actually trust (math answers over human vibes)

* The token efficiency revolution: GPT-5 to 5.1 bumped evals and slashed tokens, and why thinking in tokens (not wall-clock time) unlocks better tool-calling and agent workflows

* Personality toggles: Anton (tool, no warmth) vs Clippy (friendly, helpful), and why Josh uses custom instructions to make his model ?just a tool?

* The router problem: having a router at the top (GPT-5 thinking vs non-thinking) and an implicit router (thinking effort slider) creates weird bumps, and why the abstractions will eventually merge

* Long context: climbing Graph Blocks evals, the dream of 10M+ token windows, and why agents + graph walks might matter more than raw context length

* Why the education system isn?t producing enough people who can do both distributed systems and ML research, and why that?s the bottleneck for frontier labs

* The 2026 vision: neither pre-training nor post-training is dead, we?re in the fog of war, and the bottleneck will keep moving (so emotional stability helps)

?

Josh McGrath

* OpenAI: https://openai.com

* X: https://x.com/j_mcgraph

Full Video Episode

Timestamps

00:00:00 Introduction: Josh McGrath on Post-Training at OpenAI00:04:37 The Shopping Model: Black Friday Launch and Interruptability00:07:11 Model Personality and the Anton vs Clippy Divide00:08:26 Beyond PPO vs DPO: The Data Quality Spectrum in RL00:01:40 Infrastructure Challenges: Why Post-Training RL is Harder Than Pre-Training00:13:12 Token Efficiency: The 2D Plot That Matters Most00:03:45 Codex Max and the Flow Problem: 40 Minutes of Planning, 15 Minutes of Waiting00:17:29 Long Context and Graph Blocks: Climbing Toward Perfect Context00:21:23 The ML-Systems Hybrid: What's Hard to Hire For00:24:50 Pre-Training Isn't Dead: Living Through Technological Revolution

From Berkeley robotics and OpenAI?s 2017 Dota-era internship to shipping RL breakthroughs on GPT-4o, o1, and o3, and now leading model development at Cursor, Ashvin Nair has done it all. We caught up with Ashvin at NeurIPS 2025 to dig into the inside story of OpenAI?s reasoning team (spoiler: it went from a dozen people to 300+), why IOI Gold felt reachable in 2022 but somehow didn?t change the world when o1 actually achieved it, how RL doesn?t generalize beyond the training distribution (and why that means you need to bring economically useful tasks into distribution by co-designing products and models), the deeper lessons from the RL research era (2017?2022) and why most of it didn?t pan out because the community overfitted to benchmarks, how Cursor is uniquely positioned to do continual learning at scale with policy updates every two hours and product-model co-design that keeps engineers in the loop instead of context-switching into ADHD hell, and his bet that the next paradigm shift is continual learning with infinite memory?where models experience something once (a bug, a mistake, a user pattern) and never forget it, storing millions of deployment tokens in weights without overloading capacity.

We discuss:

* Ashvin?s path: Berkeley robotics PhD ? OpenAI 2017 intern (Dota era) ? o1/o3 reasoning team ? Cursor ML lead in three months

* Why robotics people are the most grounded at NeurIPS (they work with the real world) and simulation people are the most unhinged (Lex Fridman?s take)

* The IOI Gold paradox: ?If you told me we?d achieve IOI Gold in 2022, I?d assume we could all go on vacation?AI solved, no point working anymore. But life is still the same.?

* The RL research era (2017?2022) and why most of it didn?t pan out: overfitting to benchmarks, too many implicit knobs to tune, and the community rewarding complex ideas over simple ones that generalize

* Inside the o1 origin story: a dozen people, conviction from Ilya and Jakob Pachocki that RL would work, small-scale prototypes producing ?surprisingly accurate reasoning traces? on math, and first-principles belief that scaled

* The reasoning team grew from ~12 to 300+ people as o1 became a product and safety, tooling, and deployment scaled up

* Why Cursor is uniquely positioned for continual learning: policy updates every two hours (online RL on tab), product and ML sitting next to each other, and the entire software engineering workflow (code, logs, debugging, DataDog) living in the product

* Composer as the start of product-model co-design: smart enough to use, fast enough to stay in the loop, and built by a 20?25 person ML team with high-taste co-founders who code daily

* The next paradigm shift: continual learning with infinite memory?models that experience something once (a bug, a user mistake) and store it in weights forever, learning from millions of deployment tokens without overloading capacity (trillions of pretraining tokens = plenty of room)

* Why off-policy RL is unstable (Ashvin?s favorite interview question) and why Cursor does two-day work trials instead of whiteboard interviews

* The vision: automate software engineering as a process (not just answering prompts), co-design products so the entire workflow (write code, check logs, debug, iterate) is in-distribution for RL, and make models that never make the same mistake twice

?

Ashvin Nair

* Cursor: https://cursor.com

* X: https://x.com/ashvinnair_

Full Video Episode

Timestamps

00:00:00 Introduction: From Robotics to Cursor via OpenAI00:01:58 The Robotics to LLM Agent Transition: Why Code Won00:09:11 RL Research Winter and Academic Overfitting00:11:45 The Scaling Era and Moving Goalposts: IOI Gold Doesn't Mean AGI00:21:30 OpenAI's Reasoning Journey: From Codex to O100:20:03 The Blip: Thanksgiving 2023 and OpenAI Governance00:22:39 RL for Reasoning: The O-Series Conviction and Scaling00:25:47 O1 to O3: Smooth Internal Progress vs External Hype Cycles00:33:07 Why Cursor: Co-Designing Products and Models for Real Work00:34:14 Composer and the Future: Online Learning Every Two Hours00:35:15 Continual Learning: The Missing Paradigm Shift00:44:00 Hiring at Cursor and Why Off-Policy RL is Unstable

From investing through the modern data stack era (DBT, Fivetran, and the analytics explosion) to now investing at the frontier of AI infrastructure and applications at Amplify Partners, Sarah Catanzaro has spent years at the intersection of data, compute, and intelligence?watching categories emerge, merge, and occasionally disappoint. We caught up with Sarah live at NeurIPS 2025 to dig into the state of AI startups heading into 2026: why $100M+ seed rounds with no near-term roadmap are now the norm (and why that terrifies her), what the DBT-Fivetran merger really signals about the modern data stack (spoiler: it?s not dead, just ready for IPO), how frontier labs are using DBT and Fivetran to manage training data and agent analytics at scale, why data catalogs failed as standalone products but might succeed as metadata services for agents, the consumerization of AI and why personalization (memory, continual learning, K-factor) is the 2026 unlock for retention and growth, why she thinks RL environments are a fad and real-world logs beat synthetic clones every time, and her thesis for the most exciting AI startups: companies that marry hard research problems (RAG, rule-following, continual learning) with killer applications that were simply impossible before.

We discuss:

* The DBT-Fivetran merger: not the death of the modern data stack, but a path to IPO scale (targeting $600M+ combined revenue) and a signal that both companies were already winning their categories

* How frontier labs use data infrastructure: DBT and Fivetran for training data curation, agent analytics, and managing increasingly complex interactions?plus the rise of transactional databases (RocksDB) and efficient data loading (Vortex) for GPU-bound workloads

* Why data catalogs failed: built for humans when they should have been built for machines, focused on discoverability when the real opportunity was governance, and ultimately subsumed as features inside Snowflake, DBT, and Fivetran

* The $100M+ seed phenomenon: raising massive rounds at billion-dollar valuations with no 6-month roadmap, seven-day decision windows, and founders optimizing for signal (?we?re a unicorn?) over partnership or dilution discipline

* Why world models are overhyped but underspecified: three competing definitions, unclear generalization across use cases (video games ? robotics ? autonomous driving), and a research problem masquerading as a product category

* The 2026 theme: consumerization of AI via personalization?memory management, continual learning, and solving retention/churn by making products learn skills, preferences, and adapt as the world changes (not just storing facts in cursor rules)

* Why RL environments are a fad: labs are paying 7?8 figures for synthetic clones when real-world logs, traces, and user activity (à la Cursor) are richer, cheaper, and more generalizable

* Sarah?s investment thesis: research-driven applications that solve hard technical problems (RAG for Harvey, rule-following for Sierra, continual learning for the next killer app) and unlock experiences that were impossible before

* Infrastructure bets: memory, continual learning, stateful inference, and the systems challenges of loading/unloading personalized weights at scale

* Why K-factor and growth fundamentals matter again: AI felt magical in 2023?2024, but as the magic fades, retention and virality are back?and most AI founders have never heard of K-factor

?

Sarah Catanzaro

* X: https://x.com/sarahcat21

* Amplify Partners: https://amplifypartners.com/

Where to find Latent Space

* X: https://x.com/latentspacepod

Full Video Episode

Timestamps

00:00:00 Introduction: Sarah Catanzaro's Journey from Data to AI00:01:02 The DBT-Fivetran Merger: Not the End of the Modern Data Stack00:05:26 Data Catalogs and What Went Wrong00:08:16 Data Infrastructure at AI Labs: Surprising Insights00:10:13 The Crazy Funding Environment of 2024-202500:17:18 World Models: Hype, Confusion, and Market Potential00:18:59 Memory Management and Continual Learning: The Next Frontier00:23:27 Agent Environments: Just a Fad?00:25:48 The Perfect AI Startup: Research Meets Application00:28:02 Closing Thoughts and Where to Find Sarah

One year ago, Anthropic launched the Model Context Protocol (MCP)?a simple, open standard to connect AI applications to the data and tools they need. Today, MCP has exploded from a local-only experiment into the de facto protocol for agentic systems, adopted by OpenAI, Microsoft, Google, Block, and hundreds of enterprises building internal agents at scale. And now, MCP is joining the newly formed Agentic AI Foundation (AAIF) under the Linux Foundation, alongside Block?s Goose coding agent, with founding members spanning the biggest names in AI and cloud infrastructure.

We sat down with David Soria Parra (MCP lead, Anthropic), Nick Cooper (OpenAI), Brad Howes (Block / Goose), and Jim Zemlin (Linux Foundation CEO) to dig into the one-year journey of MCP?from Thanksgiving hacking sessions and the first remote authentication spec to long-running tasks, MCP Apps, and the rise of agent-to-agent communication?and the behind-the-scenes story of how three competitive AI labs came together to donate their protocols and agents to a neutral foundation, why enterprises are deploying MCP servers faster than anyone expected (most of it invisible, internal, and at massive scale), what it takes to design a protocol that works for both simple tool calls and complex multi-agent orchestration, how the foundation will balance taste-making (curating meaningful projects) with openness (avoiding vendor lock-in), and the 2025 vision: MCP as the communication layer for asynchronous, long-running agents that work while you sleep, discover and install their own tools, and unlock the next order of magnitude in AI productivity.

We discuss:

* The one-year MCP journey: from local stdio servers to remote HTTP streaming, OAuth 2.1 authentication (and the enterprise lessons learned), long-running tasks, and MCP Apps (iframes for richer UI)

* Why MCP adoption is exploding internally at enterprises: invisible, internal servers connecting agents to Slack, Linear, proprietary data, and compliance-heavy workflows (financial services, healthcare)

* The authentication evolution: separating resource servers from identity providers, dynamic client registration, and why the March spec wasn?t enterprise-ready (and how June fixed it)

* How Anthropic dogfoods MCP: internal gateway, custom servers for Slack summaries and employee surveys, and why MCP was born from ?how do I scale dev tooling faster than the company grows??

* Tasks: the new primitive for long-running, asynchronous agent operations?why tools aren?t enough, how tasks enable deep research and agent-to-agent handoffs, and the design choice to make tasks a ?container? (not just async tools)

* MCP Apps: why iframes, how to handle styles and branding, seat selection and shopping UIs as the killer use case, and the collaboration with OpenAI to build a common standard

* The registry problem: official registry vs. curated sub-registries (Smithery, GitHub), trust levels, model-driven discovery, and why MCP needs ?npm for agents? (but with signatures and HIPAA/financial compliance)

* The founding story of AAIF: how Anthropic, OpenAI, and Block came together (spoiler: they didn?t know each other were talking to Linux Foundation), why neutrality matters, and how Jim Zemlin has never seen this much day-one inbound interest in 22 years

?

David Soria Parra (Anthropic / MCP)

* MCP: https://modelcontextprotocol.io

* https://uk.linkedin.com/in/david-soria-parra-4a78b3a

* https://x.com/dsp_

Nick Cooper (OpenAI)

* X: https://x.com/nicoaicopr

Brad Howes (Block / Goose)

* Goose: https://github.com/block/goose

Jim Zemlin (Linux Foundation)

* LinkedIn: https://www.linkedin.com/in/zemlin/

Agentic AI Foundation

* https://agenticai.foundation

Full Video Episode

Timestamps

00:00:00 Introduction: MCP's First Year and Foundation Launch00:01:17 MCP's Journey: From Launch to Industry Standard00:02:06 Protocol Evolution: Remote Servers and Authentication00:08:52 Enterprise Authentication and Financial Services00:11:42 Transport Layer Challenges: HTTP Streaming and Scalability00:15:37 Standards Development: Collaboration with Tech Giants00:34:27 Long-Running Tasks: The Future of Async Agents00:30:41 Discovery and Registries: Building the MCP Ecosystem00:30:54 MCP Apps and UI: Beyond Text Interfaces00:26:55 Internal Adoption: How Anthropic Uses MCP00:23:15 Skills vs MCP: Complementary Not Competing00:36:16 Community Events and Enterprise Learnings01:03:31 Foundation Formation: Why Now and Why Together01:07:38 Linux Foundation Partnership: Structure and Governance01:11:13 Goose as Reference Implementation01:17:28 Principles Over Roadmaps: Composability and Quality01:21:02 Foundation Value Proposition: Why Contribute01:27:49 Practical Investments: Events, Tools, and Community01:34:58 Looking Ahead: Async Agents and Real Impact

Note: Steve and Gene?s talk on Vibe Coding and the post IDE world was one of the top talks of AIE CODE:

From building legendary platforms at Google and Amazon to authoring one of the most influential essays on AI-powered development (Revenge of the Junior Developer, quoted by Dario Amodei himself), Steve Yegge has spent decades at the frontier of software engineering?and now he?s leading the charge into what he calls the ?factory farming? era of code. After stints at SourceGraph and building Beads (a purely vibe-coded issue tracker with tens of thousands of users), Steve co-authored The Vibe Coding Book and is now building VC (VibeCoder), an agent orchestration dashboard designed to move developers from writing code to managing fleets of AI agents that coordinate, parallelize, and ship features while you sleep.

We sat down with Steve at AI Engineer Summit to dig into why Claude Code, Cursor, and the entire 2024 stack are already obsolete, what it actually takes to trust an agent after 2,000 hours of practice (hint: they will delete your production database if you anthropomorphize them), why the real skill is no longer writing code but orchestrating agents like a NASCAR pit crew, how merging has become the new wall that every 10x-productive team is hitting (and why one company?s solution is literally ?one engineer per repo?), the rise of multi-agent workflows where agents reserve files, message each other via MCP, and coordinate like a little village, why Steve believes if you?re still using an IDE to write code by January 1st, you?re a bad engineer, how the 12?15 year experience bracket is the most resistant demographic (and why their identity is tied to obsolete workflows), the hidden chaos inside OpenAI, Anthropic, and Google as they scale at breakneck speed, why rewriting from scratch is now faster than refactoring for a growing class of codebases, and his 2025 prediction: we?re moving from subsistence agriculture to John Deere-scale factory farming of code, and the Luddite backlash is only just beginning.

We discuss:

* Why Claude Code, Cursor, and agentic coding tools are already last year?s tech?and what comes next: agent orchestration dashboards where you manage fleets, not write lines

* The 2,000-hour rule: why it takes a full year of daily use before you can predict what an LLM will do, and why trust = predictability, not capability

* Steve?s hot take: if you?re still using an IDE to develop code by January 1st, 2025, you?re a bad engineer?because the abstraction layer has moved from models to full-stack agents

* The demographic most resistant to vibe coding: 12?15 years of experience, senior engineers whose identity is tied to the way they work today, and why they?re about to become the interns

* Why anthropomorphizing LLMs is the biggest mistake: the ?hot hand? fallacy, agent amnesia, and how Steve?s agent once locked him out of prod by changing his password to ?fix? a problem

* Should kids learn to code? Steve?s take: learn to vibe code?understand functions, classes, architecture, and capabilities in a language-neutral way, but skip the syntax

* The 2025 vision: ?factory farming of code? where orchestrators run Cloud Code, scrub output, plan-implement-review-test in loops, and unlock programming for non-programmers at scale

?

Steve Yegge

* X: https://x.com/steve_yegge

* Substack (Stevie?s Tech Talks): https://steve-yegge.medium.com/

* GitHub (VC / VibeCoder): https://github.com/yegge-labs

Where to find Latent Space

* X: https://x.com/latentspacepod

Full Video Episode

Thumbnails

00:00:00 Introduction: Steve Yegge on Vibe Coding and AI Engineering00:00:59 The Backlash: Who Resists Vibe Coding and Why00:04:26 The 2000 Hour Rule: Building Trust with AI Coding Tools00:03:31 The January 1st Deadline: IDEs Are Becoming Obsolete00:02:55 10X Productivity at OpenAI: The Performance Review Problem00:07:49 The Hot Hand Fallacy: When AI Agents Betray Your Trust00:11:12 Claude Code Isn't It: The Need for Agent Orchestration00:15:20 The Orchestrator Revolution: From Cloud Code to Agent Villages00:18:46 The Merge Wall: The Biggest Unsolved Problem in AI Coding00:26:33 Never Rewrite Your Code - Until Now: Joel Spolsky Was Wrong00:22:43 Factory Farming Code: The John Deere Era of Software00:29:27 Google's Gemini Turnaround and the AI Lab Chaos00:33:20 Should Your Kids Learn to Code? The New Answer00:34:59 Code MCP and the Gossip Rate: Latest Vibe Coding Discoveries

From the frontlines of OpenAI?s Codex and GPT-5 training teams, Bryan and Bill are building the future of AI-powered coding?where agents don?t just autocomplete, they architect, refactor, and ship entire features while you sleep. We caught up with them at AI Engineer Conference right after the launch of Codex Max, OpenAI?s newest long-running coding agent designed to work for 24+ hours straight, manage its own context, and spawn sub-agents to parallelize work across your entire codebase.

We sat down with Bryan and Bill to dig into what it actually takes to train a model that developers trust?why personality, communication, and planning matter as much as raw capability, how Codex is trained with strong opinions about tools (it loves rg over grep, seriously), why the abstraction layer is moving from models to full-stack agents you can plug into VS Code or Zed, how OpenAI partners co-develop tool integrations and discover unexpected model habits (like renaming tools to match Codex?s internal training), the rise of applied evals that measure real-world impact instead of academic benchmarks, why multi-turn evals are the next frontier (and Bryan?s ?job interview eval? idea), how coding agents are breaking out of code into personal automation, terminal workflows, and computer use, and their 2026 vision: coding agents trusted enough to handle the hardest refactors at any company, not just top-tier firms, and general enough to build integrations, organize your desktop, and unlock capabilities you?d never get access to otherwise.

We discuss:

* What Codex Max is: a long-running coding agent that can work 24+ hours, manage its own context window, and spawn sub-agents for parallel work

* Why the name ?Max?: maximalist, maximization, speed and endurance?it?s simply better and faster for the same problems

* Training for personality: communication, planning, context gathering, and checking your work as behavioral characteristics, not just capabilities

* How Codex develops habits like preferring rg over grep, and why renaming tools to match its training (e.g., terminal-style naming) dramatically improves tool-call performance

* The split between Codex (opinionated, agent-focused, optimized for the Codex harness) and GPT-5 (general, more durable across different tools and modalities)

* Why the abstraction layer is moving up: from prompting models to plugging in full agents (Codex, GitHub Copilot, Zed) that package the entire stack

* The rise of sub-agents and agents-using-agents: Codex Max spawning its own instances, handing off context, and parallelizing work across a codebase

* How OpenAI works with coding partners on the bleeding edge to co-develop tool integrations and discover what the model is actually good at

* The shift to applied evals: capturing real-world use cases instead of academic benchmarks, and why ~50% of OpenAI employees now use Codex daily

* Why multi-turn evals are the next frontier: LM-as-a-judge for entire trajectories, Bryan?s ?job interview eval? concept, and the need for a batch multi-turn eval API

* How coding agents are breaking out of code: personal automation, organizing desktops, terminal workflows, and ?Devin for non-coding? use cases

* Why Slack is the ultimate UI for work, and how coding agents can become your personal automation layer for email, files, and everything in between

* The 2026 vision: more computer use, more trust, and coding agents capable enough that any company can access top-tier developer capabilities, not just elite firms

?

Bryan & Bill (OpenAI Codex Team)

* http://x.com/bfioca

* https://x.com/realchillben

* OpenAI Codex: https://openai.com/index/openai-codex/

Where to find Latent Space

* X: https://x.com/latentspacepod

Full Video Episode

Timestamps

00:00:00 Introduction: Latent Space Listeners at AI Engineer Code00:01:27 Codex Max Launch: Training for Long-Running Coding Agents00:03:01 Model Personality and Trust: Communication, Planning, and Self-Checking00:05:20 Codex vs GPT-5: Opinionated Agents vs General Models00:07:47 Tool Use and Model Habits: The Ripgrep Discovery00:09:16 Personality Design: Verbosity vs Efficiency in Coding Agents00:11:56 The Agent Abstraction Layer: Building on Top of Codex00:14:08 Sub-Agents and Multi-Agent Patterns: The Future of Composition00:16:11 Trust and Adoption: OpenAI Developers Using Codex Daily00:17:21 Applied Evals: Real-World Testing vs Academic Benchmarks00:19:15 Multi-Turn Evals and the Job Interview Pattern00:21:35 Feature Request: Batch Multi-Turn Eval API00:22:28 Beyond Code: Personal Automation and Computer Use00:24:51 Vision-Native Agents and the UI Integration Challenge00:25:02 2026 Predictions: Trust, Computer Use, and Democratized Excellence

As with all demo-heavy and especially vision AI podcasts, we encourage watching along on our YouTube (and tossing us an upvote/subscribe if you like!)

From SAM 1?s 11-million-image data engine to SAM 2?s memory-based video tracking, MSL?s Segment Anything project has redefined what?s possible in computer vision. Now SAM 3 takes the next leap: concept segmentation?prompting with natural language like ?yellow school bus? or ?tablecloth? to detect, segment, and track every instance across images and video, in real time, with human-level exhaustivity. And with the latest SAM Audio:

SAM can now even segment audio output!

We sat down with Nikhila Ravi (SAM lead at Meta) and Pengchuan Zhang (SAM 3 researcher) alongside Joseph Nelson (CEO, Roboflow) to unpack how SAM 3 unifies interactive segmentation, open-vocabulary detection, video tracking, and more into a single model that runs in 30ms on images and scales to real-time video on multi-GPU setups. We dig into the data engine that automated exhaustive annotation from two minutes per image down to 25 seconds using AI verifiers fine-tuned on Llama, the new SACO (Segment Anything with Concepts) benchmark with 200,000+ unique concepts vs. the previous 1.2k, how SAM 3 separates recognition from localization with a presence token, why decoupling the detector and tracker was critical to preserve object identity in video, how SAM 3 Agents unlock complex visual reasoning by pairing SAM 3 with multimodal LLMs like Gemini, and the real-world impact: 106 million smart polygons created on Roboflow saving humanity an estimated 130+ years of labeling time across fields from cancer research to underwater trash cleanup to autonomous vehicle perception.

We discuss:

* What SAM 3 is: a unified model for concept-prompted segmentation, detection, and tracking in images and video using atomic visual concepts like ?purple umbrella? or ?watering can?

* How concept prompts work: short text phrases that find all instances of a category without manual clicks, plus visual exemplars (boxes, clicks) to refine and adapt on the fly

* Real-time performance: 30ms per image (100 detected objects on H200), 10 objects on 2×H200 video, 28 on 4×, 64 on 8×, with parallel inference and ?fast mode? tracking

* The SACO benchmark: 200,000+ unique concepts vs. 1.2k in prior benchmarks, designed to capture the diversity of natural language and reach human-level exhaustivity

* The data engine: from 2 minutes per image (all-human) to 45 seconds (model-in-loop proposals) to 25 seconds (AI verifiers for mask quality and exhaustivity checks), fine-tuned on Llama 3.2

* Why exhaustivity is central: every instance must be found, verified by AI annotators, and manually corrected only when the model misses?automating the hardest part of segmentation at scale

* Architecture innovations: presence token to separate recognition (?is it in the image??) from localization (?where is it??), decoupled detector and tracker to preserve identity-agnostic detection vs. identity-preserving tracking

* Building on Meta?s ecosystem: Perception Encoder, DINO v2 detector, Llama for data annotation, and SAM 2?s memory-based tracking backbone

* SAM 3 Agents: using SAM 3 as a visual tool for multimodal LLMs (Gemini, Llama) to solve complex visual reasoning tasks like ?find the bigger character? or ?what distinguishes male from female in this image?

* Fine-tuning with as few as 10 examples: domain adaptation for specialized use cases (Waymo vehicles, medical imaging, OCR-heavy scenes) and the outsized impact of negative examples

* Real-world impact at Roboflow: 106M smart polygons created, saving 130+ years of labeling time across cancer research, underwater trash cleanup, autonomous drones, industrial automation, and more

?

MSL FAIR team

* Nikhila: https://www.linkedin.com/in/nikhilaravi/

* Pengchuan: https://pzzhang.github.io/pzzhang/

Joseph Nelson

* X: https://x.com/josephofiowa

* LinkedIn: https://www.linkedin.com/in/josephofiowa/

Full Video Episode

Timestamps

00:00:00 Introduction and the SAM Series Legacy00:00:53 SAM 3 Launch: Three Models in One Release00:05:30 Live Demo: Concept Prompting and Visual Exemplars00:10:54 From Prototype to Production: The Evolution of Text Prompting00:15:45 The Data Engine: Automating Exhaustive Annotation00:14:10 Real-World Impact: 130 Years of Humanity Saved00:25:11 Architecture Deep Dive: Decoupled Detection and Tracking00:28:02 SAM 3 Agent: Bridging Vision and Language Models00:33:20 Head-to-Head: SAM 3 vs Gemini and Florence00:47:50 Video Understanding and the Masklet Detection Score00:20:24 Fine-Tuning and Domain Adaptation: From Waymos to Medical Imaging00:52:25 The Future of Perception: Native Vision vs Tool Calls01:05:45 Building with SAM 3: Roboflow's Rapid Auto-Labeling00:57:02 Open Source Philosophy and the Path to AGI00:58:24 What's Next: SAM 4, Video Scale, and Beyond Human Performance

Note: this is Pliny and John?s first major podcast. Voices have been changed for opsec.

From jailbreaking every frontier model and turning down Anthropic?s Constitutional AI challenge to leading BT6, a 28-operator white-hat hacker collective obsessed with radical transparency and open-source AI security, Pliny the Liberator and John V are redefining what AI red-teaming looks like when you refuse to lobotomize models in the name of ?safety.?

Pliny built his reputation crafting universal jailbreaks?skeleton keys that obliterate guardrails across modalities?and open-sourcing prompt templates like Libertas, predictive reasoning cascades, and the infamous ?Pliny divider? that?s now embedded so deep in model weights it shows up unbidden in WhatsApp messages. John V, coming from prompt engineering and computer vision, co-founded the Bossy Discord (40,000 members strong) and helps steer BT6?s ethos: if you can?t open-source the data, we?re not interested. Together they?ve turned down enterprise gigs, pushed back on Anthropic?s closed bounties, and insisted that real AI security happens at the system layer?not by bubble-wrapping latent space.

We sat down with Pliny and John to dig into the mechanics of hard vs. soft jailbreaks, why multi-turn crescendo attacks were obvious to hackers years before academia ?discovered? them, how segmented sub-agents let one jailbroken orchestrator weaponize Claude for real-world attacks (exactly as Pliny predicted 11 months before Anthropic?s recent disclosure), why guardrails are security theater that punishes capability while doing nothing for real safety, the role of intuition and ?bonding? with models to navigate latent space, how BT6 vets operators on skill and integrity, why they believe Mech Interp and open-source data are the path forward (not RLHF lobotomization), and their vision for a future where spatial intelligence, swarm robotics, and AGI alignment research happen in the open?bootstrapped, grassroots, and uncompromising.

We discuss:

* What universal jailbreaks are: skeleton-key prompts that obliterate guardrails across models and modalities, and why they?re central to Pliny?s mission of ?liberation?

* Hard vs. soft jailbreaks: single-input templates vs. multi-turn crescendo attacks, and why the latter were obvious to hackers long before academic papers

* The Libertas repo: predictive reasoning, the Library of Babel analogy, quotient dividers, weight-space seeds, and how introducing ?steered chaos? pulls models out-of-distribution

* Why jailbreaking is 99% intuition and bonding with the model: probing token layers, syntax hacks, multilingual pivots, and forming a relationship to navigate latent space

* The Anthropic Constitutional AI challenge drama: UI bugs, judge failures, goalpost moving, the demand for open-source data, and why Pliny sat out the $30k bounty

* Why guardrails ? safety: security theater, the futility of locking down latent space when open-source is right behind, and why real safety work happens in meatspace (not RLHF)

* The weaponization of Claude: how segmented sub-agents let one jailbroken orchestrator execute malicious tasks (pyramid-builder analogy), and why Pliny predicted this exact TTP 11 months before Anthropic?s disclosure

* BT6 hacker collective: 28 operators across two cohorts, vetted on skill and integrity, radical transparency, radical open-source, and the magic of moving the needle on AI security, swarm intelligence, blockchain, and robotics

?

Pliny the Liberator

* X: https://x.com/elder_plinius

* GitHub (Libertas): https://github.com/elder-plinius/L1B3RT45

John V

* X: https://x.com/JohnVersus

BT6 & Bossy

* BT6: https://bt6.gg

* Bossy Discord: Search ?Bossy Discord? or ask Pliny/John V on X

Where to find Latent Space

* X: https://x.com/latentspacepod

Full Video Episode

Timestamps

00:00:00 Introduction: Meet Pliny the Liberator and John V00:01:50 The Philosophy of AI Liberation and Jailbreaking00:03:08 Universal Jailbreaks: Skeleton Keys to AI Models00:04:24 The Cat-and-Mouse Game: Attackers vs Defenders00:05:42 Security Theater vs Real Safety: The Fundamental Disconnect00:08:51 Inside the Libertas Repo: Prompt Engineering as Art00:16:22 The Anthropic Challenge Drama: UI Bugs and Open Source Data00:23:30 From Jailbreaks to Weaponization: AI-Orchestrated Attacks00:26:55 The BT6 Hacker Collective and BASI Community00:34:46 AI Red Teaming: Full Stack Security Beyond the Model00:38:06 Safety vs Security: Meat Space Solutions and Final Thoughts

Glean started as a Kleiner Perkins incubation and is now a $7B, $200m ARR Enterprise AI leader. Now KP has tapped its own podcaster to lead it?s next big swing.

From building go-to-market the hard way in startups (and scaling Palo Alto Networks? public cloud business) to joining Kleiner Perkins to help technical founders turn product edge into repeatable revenue, Joubin Mirzadegan has spent the last decade obsessing over one thing: distribution and how ideas actually spread, sell, and compound. That obsession took him from launching the CRO-only podcast Grit (https://www.youtube.com/playlist?list=PLRiWZFltuYPF8A6UGm74K2q29UwU-Kk9k) as a hiring wedge, to working alongside breakout companies like Glean and Windsurf, to now incubating Roadrunner which is an AI-native rethink of CPQ and quoting workflows as pricing models collapse from ?seats? into consumption, bundles, renewals, and SKU sprawl.

We sat down with Joubin to dig into the real mechanics of making conversations feel human (rolling early, never sending questions, temperature + lighting hacks), what Windsurf got right about ?Google-class product and Salesforce-class distribution,? how to hire early sales leaders without getting fooled by shiny logos, why CPQ is quietly breaking the back of modern revenue teams, and his thesis for his new company and KP incubation Roadrunner (https://www.roadrunner.ai/): rebuild the data model from the ground up, co-develop with the hairiest design partners, and eventually use LLMs to recommend deal structures the way the best reps do without the Slack-channel chaos of deal desk.

We discuss:

* How to make guests instantly comfortable: rolling early, no ?are you ready??, temperature, lighting, and room dynamics

* Why Joubin refuses to send questions in advance (and when you might have to anyway)

* The origin of the CRO-only podcast: using media as a hiring wedge and relationship engine

* The ?commit to 100 episodes? mindset: why most shows die before they find their voice

* Founder vs exec interviews: why CEOs can speak more freely (and what it unlocks in conversation)

* What Glean taught him about enterprise AI: permissions, trust, and overcoming ?category is dead? skepticism

* Design partners as the real unlock: why early believers matter and how co-development actually works

* Windsurf?s breakout: what it means to be serious about ?Google-class product + Salesforce-class distribution?

* Why technical founders struggle with GTM and how KP built a team around sales, customer access, and demand gen

* Hiring early sales leaders: anti-patterns (logos), what to screen for (motivation), and why stage-fit is everything

* The CPQ problem & Roadrunner?s thesis: rebuilding CPQ/quoting from the data model up for modern complexity

* How ?rules + SKUs + approvals? create a brittle graph and what it takes to model it without tipping over

* The two-year window: incumbents rebuilding slowly vs startups out-sprinting with AI-native architecture

* Where AI actually helps: quote generation, policy enforcement, approval routing, and deal recommendation loops

?

Joubin

* X: https://x.com/Joubinmir

* LinkedIn: https://www.linkedin.com/in/joubin-mirzadegan-66186854/

Where to find Latent Space

* X: https://x.com/latentspacepod

Full Video Episode

Timestamps

00:00:00 Introduction and the Zuck Interview Experience00:03:26 The Genesis of the Grit Podcast: Hiring CROs Through Content00:13:20 Podcast Philosophy: Creating Authentic Conversations00:15:44 Working with Arvind at Glean: The Enterprise Search Breakthrough00:26:20 Windsurf's Sales Machine: Google-Class Product Meets Salesforce-Class Distribution00:30:28 Hiring Sales Leaders: Anti-Patterns and First Principles00:39:02 The CPQ Problem: Why Salesforce and Legacy Tools Are Breaking00:43:40 Introducing Roadrunner: Solving Enterprise Pricing with AI00:49:19 Building Roadrunner: Team, Design Partners, and Data Model Challenges00:59:35 High Performance Philosophy: Working Out Every Day and Reducing Friction01:06:28 Defining Grit: Passion Plus Perseverance

From applied cryptography and offensive security in France?s defense industry to optimizing nuclear submarine workflows, then selling his e-signature startup to Docusign (https://www.docusign.com/company/news-center/opentrust-joins-docusign-global-trust-network and now running AI as CTO of Superhuman Mail (Superhuman, recently acquired by Grammarly https://techcrunch.com/2025/07/01/grammarly-acquires-ai-email-client-superhuman/), Loïc Houssier has lived the full arc from deep infra and compliance hell to obsessing over 100ms product experiences and AI-native email. We sat down with Loïc to dig into how you actually put AI into an inbox without adding latency, why Superhuman leans so hard into agentic search and ?Ask AI? over your entire email history, how they design tools vs. agents and fight agent laziness, what box-priced inference and local-first caching mean for cost and reliability, and his bet that your inbox will power your future AI EA while AI massively widens the gap between engineers with real fundamentals and those faking it.

We discuss:

* Loïc?s path from applied cryptography and offensive security in France?s defense industry to submarines, e-signatures, Docusign, and now Superhuman Mail

* What 3,000+ engineers actually do at a ?simple? product like Docusign: regional compliance, on-prem appliances, and why global scale explodes complexity

* How Superhuman thinks about AI in email: auto-labels, smart summaries, follow-up nudges, ?Ask AI? search, and the rule that AI must never add latency or friction

* Superhuman?s agentic framework: tools vs. agents, fighting ?agent laziness,? deep semantic search over huge inboxes, and pagination strategies to find the real needle in the haystack

* How they evaluate OpenAI, Anthropic, Gemini, and open models: canonical queries, end-to-end evals, date reasoning, and Rahul?s infamous ?what wood was my table?? test

* Infra and cost philosophy: local-first caching, vector search backends, Baseten ?box? pricing vs. per-token pricing, and thinking in price-per-trillion-tokens instead of price-per-million

* The vision of Superhuman as your AI EA: auto-drafting replies in your voice, scheduling on your behalf, and using your inbox as the ultimate private data source

* How the Grammarly + Coda + Superhuman stack could power truly context-aware assistance across email, docs, calendars, contracts, and more

* Inside Superhuman?s AI-dev culture: free-for-all tool adoption, tracking AI usage on PRs, and going from ~4 to ~6 PRs per engineer per week

* Why Loïc believes everyone should still learn to code, and how AI will amplify great engineers with strong fundamentals while exposing shallow ones even faster

?

Loïc Houssier

* LinkedIn: https://www.linkedin.com/in/houssier/

Where to find Latent Space

* X: https://x.com/latentspacepod

Full Video Episode

Timestamps

00:00:00 Introduction and Loïc's Journey from Nuclear Submarines to Superhuman00:06:40 Docusign Acquisition and the Enterprise Email Stack00:10:26 Superhuman's AI Vision: Your Inbox as the Real AI Agent00:13:20 Ask AI: Agentic Search and the Quality Problem00:18:20 Infrastructure Choices: Model Selection, Base10, and Cost Management00:27:30 Local-First Architecture and the Database Stack00:30:50 Evals, Quality, and the Rahul Wood Table Test00:42:30 The Future EA: Auto-Drafting and Proactive Assistance00:46:40 Grammarly Acquisition and the Contextual Advantage00:38:40 Voice, Video, and the End of Writing00:51:40 Knowledge Graphs: The Hard Problem Nobody Has Solved00:56:40 Competing with OpenAI and the Browser Question01:02:30 AI Coding Tools: From 4 to 6 PRs Per Week01:08:00 Engineering Culture, Hiring, and the Future of Software Development

From building Medal into a 12M-user game clipping platform with 3.8B highlight moments to turning down a reported $500M offer from OpenAI (https://www.theinformation.com/articles/openai-offered-pay-500-million-startup-videogame-data) and raising a $134M seed from Khosla (https://techcrunch.com/2025/10/16/general-intuition-lands-134m-seed-to-teach-agents-spatial-reasoning-using-video-game-clips/) to spin out General Intuition, Pim is betting that world models trained on peak human gameplay are the next frontier after LLMs.

We sat down with Pim to dig into why game highlights are ?episodic memory for simulation? (and how Medal?s privacy-first action labels became a world-model goldmine https://medal.tv/blog/posts/enabling-state-of-the-art-security-and-protections-on-medals-new-apm-and-controller-overlay-features), what it takes to build fully vision-based agents that just see frames and output actions in real time, how General Intuition transfers from games to real-world video and then into robotics, why world models and LLMs are complementary rather than rivals, what founders with proprietary datasets should know before selling or licensing to labs, and his bet that spatial-temporal foundation models will power 80% of future atoms-to-atoms interactions in both simulation and the real world.

We discuss:

* How Medal?s 3.8B action-labeled highlight clips became a privacy-preserving goldmine for world models

* Building fully vision-based agents that only see frames and output actions yet play like (and sometimes better than) humans

* Transferring from arcade-style games to realistic games to real-world video using the same perception?action recipe

* Why world models need actions, memory, and partial observability (smoke, occlusion, camera shake) vs. ?just? pretty video generation

* Distilling giant policies into tiny real-time models that still navigate, hide, and peek corners like real players

* Pim?s path from RuneScape private servers, Tourette?s, and reverse engineering to leading a frontier world-model lab

* How data-rich founders should think about valuing their datasets, negotiating with big labs, and deciding when to go independent

* GI?s first customers: replacing brittle behavior trees in games, engines, and controller-based robots with a ?frames in, actions out? API

* Using Medal clips as ?episodic memory of simulation? to move from imitation learning to RL via world models and negative events

* The 2030 vision: spatial?temporal foundation models that power the majority of atoms-to-atoms interactions in simulation and the real world

?

Pim

* X: https://x.com/PimDeWitte

* LinkedIn: https://www.linkedin.com/in/pimdw/

Where to find Latent Space

* X: https://x.com/latentspacepod

Full Video Episode

Timestamps

00:00:00 Introduction and Medal's Gaming Data Advantage00:02:08 Exclusive Demo: Vision-Based Gaming Agents00:06:17 Action Prediction and Real-World Video Transfer00:08:41 World Models: Interactive Video Generation00:13:42 From Runescape to AI: Pim's Founder Journey00:16:45 The Research Foundations: Diamond, Genie, and SEMA00:33:03 Vinod Khosla's Largest Seed Bet Since OpenAI00:35:04 Data Moats and Why GI Stayed Independent00:38:42 Self-Teaching AI Fundamentals: The Francois Fleuret Course00:40:28 Defining World Models vs Video Generation00:41:52 Why Simulation Complexity Favors World Models00:43:30 World Labs, Yann LeCun, and the Spatial Intelligence Race00:50:08 Business Model: APIs, Agents, and Game Developer Partnerships00:58:57 From Imitation Learning to RL: Making Clips Playable01:00:15 Open Research, Academic Partnerships, and Hiring01:02:09 2030 Vision: 80 Percent of Atoms-to-Atoms AI Interactions

Fei-Fei Li and Justin Johnson are cofounders of World Labs, who have recently launched Marble (https://marble.worldlabs.ai/), a new kind of generative ?world model? that can create editable 3D environments from text, images, and other spatial inputs. Marble lets creators generate persistent 3D worlds, precisely control cameras, and interactively edit scenes, making it a powerful tool for games, film, VR, robotics simulation, and more. In this episode, Fei-Fei and Justin share how their journey from ImageNet and Stanford research led to World Labs, why spatial intelligence is the next frontier after LLMs, and how world models could change how machines see, understand, and build in 3D.

We discuss:

* The massive compute scaling from AlexNet to today and why world models and spatial data are the most compelling way to ?soak up? modern GPU clusters compared to language alone.

* What Marble actually is: a generative model of 3D worlds that turns text and images into editable scenes using Gaussian splats, supports precise camera control and recording, and runs interactively on phones, laptops, and VR headsets.

* Fei-fei?s essay:

on spatial intelligence as a distinct form of intelligence from language: from picking up a mug to inferring the 3D structure of DNA, and why language is a lossy, low-bandwidth channel for describing the rich 3D/4D world we live in.

* Whether current models ?understand? physics or just fit patterns: the gap between predicting orbits and discovering F=ma, and how attaching physical properties to splats and distilling physics engines into neural networks could lead to genuine causal reasoning.

* The changing role of academia in AI, why Fei-Fei worries more about under-resourced universities than ?open vs closed,? and how initiatives like national AI compute clouds and open benchmarks can rebalance the ecosystem.

* Why transformers are fundamentally set models, not sequence models, and how that perspective opens up new architectures for world models, especially as hardware shifts from single GPUs to massive distributed clusters.

* Real use cases for Marble today: previsualization and VFX, game environments, virtual production, interior and architectural design (including kitchen remodels), and generating synthetic simulation worlds for training embodied agents and robots.

* How spatial intelligence and language intelligence will work together in multimodal systems, and why the goal isn?t to throw away LLMs but to complement them with rich, embodied models of the world.

* Fei-Fei and Justin?s long-term vision for spatial intelligence: from creative tools for artists and game devs to broader applications in science, medicine, and real-world decision-making.

?

Fei-Fei Li

* X: https://x.com/drfeifei

* LinkedIn: https://www.linkedin.com/in/fei-fei-li-4541247

Justin Johnson

* X: https://x.com/jcjohnss

* LinkedIn: https://www.linkedin.com/in/justin-johnson-41b43664

Where to find Latent Space

* X: https://x.com/latentspacepod

Full Video Episode

Timestamps

00:00:00 Introduction and the Fei-Fei Li & Justin Johnson Partnership00:02:00 From ImageNet to World Models: The Evolution of Computer Vision00:12:42 Dense Captioning and Early Vision-Language Work00:19:57 Spatial Intelligence: Beyond Language Models00:28:46 Introducing Marble: World Labs' First Spatial Intelligence Model00:33:21 Gaussian Splats and the Technical Architecture of Marble00:22:10 Physics, Dynamics, and the Future of World Models00:41:09 Multimodality and the Interplay of Language and Space00:37:37 Use Cases: From Creative Industries to Robotics and Embodied AI00:56:58 Hiring, Research Directions, and the Future of World Labs

Alex Lieberman and Arman Hezarkani, co-founders of Tenex, reveal how they?re revolutionizing software consulting by compensating AI engineers for output rather than hours?enabling some engineers to earn over $1 million annually while delivering 10x productivity gains. Their company represents a fundamental rethinking of knowledge work compensation in the age of AI agents, where traditional hourly billing models perversely incentivize slower work even as AI tools enable unprecedented speed.

The Genesis: From 90% Downsizing to 10x Output The story behind 10X begins with Arman?s previous company, Parthian, where he was forced to downsize his engineering team by 90%. Rather than collapse, Arman re-architected the entire product and engineering process to be AI-first?and discovered that production-ready software output increased 10x despite the massive headcount reduction. This counterintuitive result exposed a fundamental misalignment: engineers compensated by the hour are disincentivized from leveraging AI to work faster, even when the technology enables dramatic productivity gains. Alex, who had invested in Parthian, initially didn?t believe the numbers until Arman walked him through why LLMs have made such a profound impact specifically on engineering as knowledge work.

The Economic Model: Story Points Over Hours 10X?s core innovation is compensating engineers based on story points?units of completed, quality output?rather than hours worked. This creates direct economic incentives for engineers to adopt every new AI tool, optimize their workflows, and maximize throughput. The company expects multiple engineers to earn over $1 million in cash compensation next year purely from story point earnings. To prevent gaming the system, they hire for two profiles: engineers who are ?long-term selfish? (understanding that inflating story points will destroy client relationships) and those who genuinely love writing code and working with smart people. They also employ technical strategists incentivized on client retention (NRR) who serve as the final quality gate before any engineering plan reaches a client.

Impressive Builds: From Retail AI to App Store Hits The results speak for themselves. In one project, 10X built a computer vision system for retail cameras that provides heat maps, queue detection, shelf stocking analysis, and theft detection?creating early prototypes in just two weeks for work that previously took quarters. They built Snapback Sports? mobile trivia app in one month, which hit 20th globally on the App Store. In a sales context, an engineer spent four hours building a working prototype of a fitness influencer?s AI health coach app after the prospect initially said no?immediately moving 10X to the top of their vendor list. These examples demonstrate how AI-enabled speed fundamentally changes sales motions and product development timelines.

The Interview Process: Unreasonably Difficult Take-Homes Despite concerns that AI would make take-home assessments obsolete, 10X still uses them?but makes them ?unreasonably difficult.? About 50% of candidates don?t even respond, but those who complete the challenge demonstrate the caliber needed. The interview process is remarkably short: two calls before the take-home, review, then one or two final meetings?completable in as little as a week. A signature question: ?If you had infinite resources to build an AI that could replace either of us on this call, what would be the first major bottleneck?? The sophisticated answer isn?t just ?model intelligence? or ?context length??it?s controlling entropy, the accumulating error rate that derails autonomous agents over time.

The Limiting Factor: Human Capital, Not Technology Despite being an AI-first company, 10X?s primary constraint is human capital?finding and hiring enough exceptional engineers fast enough, then matching them with the right processes to maintain delivery quality as they scale. The company has ambitions beyond consulting to build their own technology, but for the foreseeable future, recruiting remains the bottleneck. This reveals an important insight about the AI era: even as technology enables unprecedented leverage, the constraint shifts to finding people who can harness that leverage effectively.

Full Video Episode

Timestamps

00:00:00 Introduction and Meeting the 10X Co-founders00:01:29 The 10X Moment: From Hourly Billing to Output-Based Compensation00:04:44 The Economic Model Behind 10X00:05:42 Story Points and Measuring Engineering Output00:08:41 Impressive Client Projects and Rapid Prototyping00:12:22 The 10X Tech Stack: TypeScript and High Structure00:13:21 AI Coding Tools: The Daily Evolution00:15:05 Human Capital as the Limiting Factor00:16:02 The Unreasonably Difficult Interview Process00:17:14 Entropy and Context Engineering: The Future of AI Agents00:23:28 The MCP Debate and AI Industry Sociology00:26:01 Consulting, Digital Transformation, and Conference Insights

Deedy Das, Partner at Menlo Ventures, returns to Latent Space to discuss his journey from Glean to venture capital, the explosive rise of Anthropic, and how AI is reshaping enterprise software and coding. From investing in Anthropic early on when they had no revenue to managing the $100M Ontology Fund, Das shares insider perspectives on the fastest-growing software company in history and what?s next for AI infrastructure, research investing, and the future of engineering.

We cover Glean?s rise from ?boring? enterprise search to a $7B AI-native company, Anthropic?s meteoric rise, the strategic decisions behind products like Claude Code, and why market share in enterprise AI is shifting dramatically. Das explains his investment thesis on research companies like Goodfire, Prime Intellect, and OpenRouter and how the Anthology Fund is quietly seeding the next wave of AI infra, research, and devtools.

Full Video Episode

Timestamps

* 00:00:00 Introduction and Deedy?s Return to Latent Space

* 00:01:20 Glean?s Journey: From Boring Enterprise Search to Valuation

* 00:15:37 Anthropic?s Meteoric Rise and Market Share Dynamics

* 00:17:50 Claude Artifacts and Product Innovation

* 00:41:20 The Anthology Fund: Investing in the Anthropic Ecosystem

* 00:48:01 Goodfire and Mechanistic Interpretability

* 00:51:25 Prime Intellect and Distributed AI Training

* 00:53:40 OpenRouter: Building the AI Model Gateway

* 01:13:36 The Stargate Project and Infrastructure Arms Race

* 01:18:14 The Future of Software Engineering and AI Coding

Jared Palmer, SVP at GitHub and VP of CoreAI at Microsoft, joins Latent Space for an in-depth look at the evolution of coding agents and modern developer tools. Recently joining after leading AI initiatives at Vercel, Palmer shares firsthand insights from behind the scenes at GitHub Universe, including the launch of Agent HQ which is a new collaboration hub for coding agents and developers.

This episode traces Palmer?s journey from building Copilot inspired tools to pioneering the focused Next.js coding agent, v0, and explores how platform constraints fostered rapid experimentation and a breakout success in AI-powered frontend development. Palmer explains the unique advantages of GitHub?s massive developer network, the challenges of scaling agent-based workflows, and why integrating seamless AI into developer experiences is now a top priority for both Microsoft and GitHub.

Full Video Episode

Timestamps

00:00:00 Introduction and Jared's New Role at GitHub00:01:00 From V0 to Agent HQ: The Evolution of Coding Agents00:02:51 The V0 Origin Story: From ChatGPT to AI Playground00:05:40 Building the AI SDK and ShadCN Collaboration00:07:08 The Birth of V0: Prompt to UI Revolution00:09:18 V0's Growth Journey and Model Evolution00:11:05 Model Strategy: Composite Models vs User Choice00:13:16 GitHub's Agent HQ and Model Marketplace00:15:51 The Future of Agent Abstraction and Standards00:16:33 Microsoft Core AI Integration and Workflow Vision00:18:37 Dev Containers and Repo Setup Challenges00:24:10 Agent Quality and Infrastructure Reliability00:27:05 Using Coding Agents for Non-Coding Tasks00:29:11 GitHub Homepage Redesign and Community Feedback00:30:27 Stacked Diffs: GitHub's Most Requested Feature

Jed Borovik, Product Lead at Google Labs, joins Latent Space to unpack how Google is building the future of AI-powered software development with Jules. From his journey discovering GenAI through Stable Diffusion to leading one of the most ambitious coding agent projects in tech, Borovik shares behind-the-scenes insights into how Google Labs operates at the intersection of DeepMind?s model development and product innovation.

We explore Jules? approach to autonomous coding agents and why they run on their own infrastructure, how Google simplified their agent scaffolding as models improved, and why embeddings-based RAG is giving way to attention-based search. Borovik reveals how developers are using Jules for hours or even days at a time, the challenges of managing context windows that push 2 million tokens, and why coding agents represent both the most important AI application and the clearest path to AGI.

This conversation reveals Google?s positioning in the coding agent race, the evolution from internal tools to public products, and what founders, developers, and AI engineers should understand about building for a future where AI becomes the new brush for software engineering.

Full Video Episode

Timestamps

00:00:00 Introduction and GitHub Universe Recap00:00:57 New York Tech Scene and East Coast Hackathons00:02:19 From Google Search to AI Coding: Jed's Journey00:04:19 Google Labs Mission and DeepMind Collaboration00:06:41 Jules: Autonomous Coding Agents Explained00:09:39 The Evolution of Agent Scaffolding and Model Quality00:11:30 RAG vs Attention: The Shift in Code Understanding00:13:49 Jules' Journey from Preview to Production00:15:05 AI Engineer Summit: Community Building and Networking00:25:06 Context Management in Long-Running Agents00:29:02 The Future of Software Engineering with AI00:36:26 Beyond Vibe Coding: Spec Development and Verification00:40:20 Multimodal Input and Computer Use for Coding Agents

In this conversation with Malte Ubl, CTO of Vercel (http://x.com/cramforce), we explore how the company is pioneering the infrastructure for AI-powered development through their comprehensive suite of tools including workflows, AI SDK, and the newly announced agent ecosystem. Malte shares insights into Vercel?s philosophy of ?dogfooding? - never shipping abstractions they haven?t battle-tested themselves - which led to extracting their AI SDK from v0 and building production agents that handle everything from anomaly detection to lead qualification.

The discussion dives deep into Vercel?s new Workflow Development Kit, which brings durable execution patterns to serverless functions, allowing developers to write code that can pause, resume, and wait indefinitely without cost. Malte explains how this enables complex agent orchestration with human-in-the-loop approvals through simple webhook patterns, making it dramatically easier to build reliable AI applications.

We explore Vercel?s strategic approach to AI agents, including their DevOps agent that automatically investigates production anomalies by querying observability data and analyzing logs - solving the recall-precision problem that plagues traditional alerting systems. Malte candidly discusses where agents excel today (meeting notes, UI changes, lead qualification) versus where they fall short, emphasizing the importance of finding the ?sweet spot? by asking employees what they hate most about their jobs.

The conversation also covers Vercel?s significant investment in Python support, bringing zero-config deployment to Flask and FastAPI applications, and their vision for security in an AI-coded world where developers ?cannot be trusted.? Malte shares his perspective on how CTOs must transform their companies for the AI era while staying true to their core competencies, and why maintaining strong IC (individual contributor) career paths is crucial as AI changes the nature of software development.

What was launched at Ship AI 2025:

AI SDK 6.0 & Agent Architecture

* Agent Abstraction Philosophy: AI SDK 6 introduces an agent abstraction where you can ?define once, deploy everywhere?. How does this differ from existing agent frameworks like LangChain or AutoGPT? What specific pain points did you observe in production that led to this design?

* Human-in-the-Loop at Scale: The tool approval system with needsApproval: true gates actions until human confirmation. How do you envision this working at scale for companies with thousands of agent executions? What?s the queue management and escalation strategy?

* Type Safety Across Models: AI SDK 6 promises ?end-to-end type safety across models and UI?. Given that different LLMs have varying capabilities and output formats, how do you maintain type guarantees when swapping between providers like OpenAI, Anthropic, or Mistral?

Workflow Development Kit (WDK)

* Durability as Code: The use workflow primitive makes any TypeScript function durable with automatic retries, progress persistence, and observability. What?s happening under the hood? Are you using event sourcing, checkpoint/restart, or a different pattern?

* Infrastructure Provisioning: Vercel automatically detects when a function is durable and dynamically provisions infrastructure in real-time. What signals are you detecting in the code, and how do you determine the optimal infrastructure configuration (queue sizes, retry policies, timeout values)?

Vercel Agent (beta)

* Code Review Validation: The Agent reviews code and proposes ?validated patches?. What does ?validated? mean in this context? Are you running automated tests, static analysis, or something more sophisticated?

* AI Investigations: Vercel Agent automatically opens AI investigations when it detects performance or error spikes using real production data. What data sources does it have access to? How does it distinguish between normal variance and actual anomalies?

Python Support (For the first time, Vercel now supports Python backends natively.)

Marketplace & Agent Ecosystem

* Agent Network Effects: The Marketplace now offers agents like CodeRabbit, Corridor, Sourcery, and integrations with Autonoma, Braintrust, Browser Use. How do you ensure these third-party agents can?t access sensitive customer data? What?s the security model?

?An Agent on Every Desk? Program

* Vercel launched a new program to help companies identify high-value use cases and build their first production AI agents. It provides consultations, reference templates, and hands-on support to go from idea to deployed agent

Full Video Episode

Timestamps

00:00 Introduction and Malte?s Background at Google

01:16 Vercel?s AI Engineering Philosophy and Ship AI Recap

03:19 Deep Dive: Workflows vs Agents Architecture

09:33 AI SDK Success Story: Staying Low-Level and Humble

16:35 Framework Design Principles and Open Source Strategy

19:20 Vercel Agent: AI-Powered DevOps and Anomaly Detection

27:06 Internal Agent Use Cases: Lead Qualification and Abuse Analysis

29:49 Agent on Every Desk Program and Enterprise Adoption

32:13 Python Support and Multi-Language Infrastructure

39:42 The Future of AI-Native Security and Development

In this deep dive with Kyle Corbitt, co-founder and CEO of OpenPipe (recently acquired by CoreWeave), we explore the evolution of fine-tuning in the age of AI agents and the critical shift from supervised fine-tuning to reinforcement learning. Kyle shares his journey from leading YC?s Startup School to building OpenPipe, initially focused on distilling expensive GPT-4 workflows into smaller, cheaper models before pivoting to RL-based agent training as frontier model prices plummeted. The conversation reveals why 90% of AI projects remain stuck in proof-of-concept purgatory - not due to capability limitations, but reliability issues that Kyle believes can be solved through continuous learning from real-world experience. He discusses the breakthrough of RULER (Relative Universal Reinforcement Learning Elicited Rewards), which uses LLMs as judges to rank agent behaviors relatively rather than absolutely, making RL training accessible without complex reward engineering. Kyle candidly assesses the challenges of building realistic training environments for agents, explaining why GRPO (despite its advantages) may be a dead end due to its requirement for perfectly reproducible parallel rollouts. He shares insights on why LoRAs remain underrated for production deployments, why GEPA and prompt optimization haven?t lived up to the hype in his testing, and why the hardest part of deploying agents isn?t the AI - it?s sandboxing real-world systems with all their bugs and edge cases intact. The discussion also covers OpenPipe?s acquisition by CoreWeave, the launch of their serverless reinforcement learning platform, and Kyle?s vision for a future where every deployed agent continuously learns from production experience. He predicts that solving the reliability problem through continuous RL could unlock 10x more AI inference demand from projects currently stuck in development, fundamentally changing how we think about agent deployment and maintenance.

Key Topics:

* The rise and fall of fine-tuning as a business model

* Why 90% of AI projects never reach production

* RULER: Making RL accessible through relative ranking

* The environment problem: Why sandboxing is harder than training

* GRPO vs PPO and the future of RL algorithms

* LoRAs: The underrated deployment optimization

* Why GEPA and prompt optimization disappointed in practice

* Building world models as synthetic training environments

* The $500B Stargate bet and OpenAI?s potential crypto play

* Continuous learning as the path to reliable agents

References

https://www.linkedin.com/in/kcorbitt/

* Aug 2023 https://openpipe.ai/blog/from-prompts-to-models

* DEC 2023 https://openpipe.ai/blog/mistral-7b-fine-tune-optimized

* JAN 2024 https://openpipe.ai/blog/s-lora

* MAY 2024 https://openpipe.ai/blog/the-ten-commandments-of-fine-tuning-in-prod

* Oct 2024 https://openpipe.ai/blog/announcing-dpo-support

* AIE NYC 2025 Finetuning 500m agents

* AIEWF 2025 How to train your agent (ART-E)

* SEPT 2025 ACQUISTION https://openpipe.ai/blog/openpipe-coreweave

* W&B Serverless RL https://openpipe.ai/blog/serverless-rl?refresh=1760042248153

Full Video Episode

Timestamps

00:00 Introductions

03:15 The Evolution of OpenPipe: From SFT to RL

07:49 The Mistral Era and LoRA Adapters

11:40 When You Actually Need Fine-Tuning

14:43 The Pivot to Reinforcement Learning

21:29 GRPO vs PPO: The Technical Trade-offs

24:02 The Environment Problem in RL

35:52 JAPA and Automated Prompt Optimization

44:35 Open vs Closed Models: The Token Economics

50:38 Ruler: Self-Supervised RL Rewards

57:09 World Models as Environment Solutions

1:00:15 CoreWeave Acquisition and Future Vision

At OpenAI DevDay, we sit down with Sherwin Wu and Christina Huang from the OpenAI Platform Team to discuss the launch of AgentKit - a comprehensive suite of tools for building, deploying, and optimizing AI agents. Christina walks us through the live demo she performed on stage, building a customer support agent in just 8 minutes using the visual Agent Builder, while Sherwin shares insights on how OpenAI is inverting the traditional website-chatbot paradigm by embedding apps directly within ChatGPT through the new Apps SDK.

The conversation explores how OpenAI is tackling the challenges developers face when taking agents to production - from writing and optimizing prompts to building evaluation pipelines. They discuss the decision to adopt Anthropic?s MCP protocol for tool connectivity, the importance of visual workflows for complex agent systems, and how features like human-in-the-loop approvals and automated prompt optimization are making agent development more accessible to a broader range of developers.

Sherwin and Christina also reveal how OpenAI is dogfooding these tools internally, with their own customer support at openai.com already powered by AgentKit, and share candid insights about the evolution from plugins to GPTs to this new agent platform. They discuss the surprising persistence of prompting as a critical skill (contrary to predictions from two years ago), the challenges of serving custom fine-tuned models at scale, and why they believe visual agent builders are essential as workflows grow to span dozens of nodes.

Guests:

* Sherwin Wu: Head of Engineering, OpenAI Platform https://www.linkedin.com/in/sherwinwu1/ https://x.com/sherwinwu?lang=en

* Christina Huang: Platform Experience, OpenAI https://x.com/christinaahuang https://www.linkedin.com/in/christinaahuang/

Thanks very much to Lindsay and Shaokyi for helping us set up this great deepdive into the new DevDay launches!

Key Topics:? AgentKit launch: Agent SDK, Builder, Evals, and deployment tools? Apps SDK and the inversion of the app-chatbot paradigm? Adopting MCP protocol for universal tool connectivity? Visual agent building vs code-first approaches? Human-in-the-loop workflows and approval systems? Automated prompt optimization and ?zero-gradient fine-tuning?? Service Health Dashboard and achieving five nines reliability? ChatKit as an embeddable, evergreen chat interface? The evolution from plugins to GPTs to agent platforms? Internal dogfooding with Codex and agent-powered support

Full Video Episode

Timestamps

00:00 Welcome to the OpenAI Dev Day Studio

01:11 Dev Day Evolution and Community Growth

03:08 Apps SDK and ChatGPT Distribution Strategy

05:27 MCP Protocol Integration Decision

09:26 Agent Kit Launch and Platform Vision

11:33 Agent Builder Canvas and Visual Workflows

17:22 Evaluations and Agent Testing Evolution

19:20 Automated Prompt Optimization and Research

26:35 Connector Registry and MCP Servers

34:10 Chat Kit as Consumer-Grade Infrastructure

39:13 Codex Power User Tips and AI-Native Development

42:27 Service Health Dashboard and Reliability Journey

Dylan Field (CEO Figma) on how they are letting designers build with Figma Make, how Figma can be the context repository for aesthetic in the age of vibe coding, and why design is your only differentiator now.

Full show notes: https://www.latent.space/p/figma

Quinn Slack (CEO) and Thorsten Ball (Amp Dictator) from SourceGraph join the show to talk about Amp Code, how they ship 15x/day with no code reviews, and why subagents and prompt optimizers aren?t a promising direction for coding agents.

Amp Code: https://ampcode.com/

Latent Space: https://latent.space/

Full Video Episode

Timestamps

00:00 Introduction00:41 Transition from Cody to Amp03:18 The Importance of Building the Best Coding Agent06:43 Adapting to a Rapidly Evolving AI Tooling Landscape09:36 Dogfooding at Sourcegraph12:35 CLI vs. VS Code Extension21:08 Positioning Amp in Coding Agent Market24:10 The Diminishing Importance of Model Selectors32:39 Tooling vs. Harness37:19 Common Failure Modes of Coding Agents47:33 Agent-Friendly Logging and Tooling52:31 Are Subagents Real?56:52 New Frameworks and Agent-Integrated Developer Tools1:00:25 How Agents Are Encouraging Codebase and Workflow Changes1:03:13 Evolving Outer Loop Tasks1:07:09 Version Control and Merge Conflicts in an AI-First World1:10:36 Rise of User-Generated Enterprise Software1:14:39 Empowering Technical Leaders with AI1:17:11 Evaluating Product Without Traditional Evals1:20:58 Hiring

Lance: https://www.linkedin.com/in/lance-martin-64a33b5/

How Context Fails: https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.htmlHow New Buzzwords Get Created: https://www.dbreunig.com/2025/07/24/why-the-term-context-engineering-matters.htmlContent Engineering:

https://rlancemartin.github.io/2025/06/23/context_engineering/ https://docs.google.com/presentation/d/16aaXLu40GugY-kOpqDU4e-S0hD1FmHcNyF0rRRnb1OU/edit?usp=sharingManus Post: https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-ManusCognition Post: https://cognition.ai/blog/dont-build-multi-agentsMulti-Agent Researcher: https://www.anthropic.com/engineering/multi-agent-research-systemHuman-in-the-loop + Memory: https://github.com/langchain-ai/agents-from-scratch- Bitter Lesson in AI Engineering -Hyung Won Chung on the Bitter Lesson in AI Research:

Bitter Lesson w/ Claude Code:

Learning the Bitter Lesson in AI Engineering: https://rlancemartin.github.io/2025/07/30/bitter_lesson/Open Deep Research: https://github.com/langchain-ai/open_deep_research https://academy.langchain.com/courses/deep-research-with-langgraphScaling and building things that ?don?t yet work?:

- Frameworks -Roast framework at Shopify / standardization of orchestration tools:

MCP adoption within Anthropic / standardization of protocols:

How to think about frameworks: https://blog.langchain.com/how-to-think-about-agent-frameworks/RAG benchmarking: https://rlancemartin.github.io/2025/04/03/vibe-code/Simon?s talk with memory-gone-wrong: https://simonwillison.net/2025/Jun/6/six-months-in-llms/

Full Video Episode

Timestamps

00:00 Introduction and Background

00:53 The Rise of Context Engineering

01:57 Context Engineering vs Prompt Engineering

05:56 The Five Categories of Context Engineering

10:02 Multi-Agent Systems and Context Isolation

14:48 Classical Retrieval vs Agentic Search

17:12 LLMs.txt and MCP Servers

24:51 Context Pruning and Memory Management

37:25 Memory Systems and Human-in-the-Loop

42:55 The Bitter Lesson Applied to AI Engineering

51:21 Frameworks, Abstractions, and Building for the Future

Our chat with Ari shows that data curation is the most impactful and underinvested area in AI. He argues that the prevailing focus on model architecture and compute scaling overlooks the ?bitter lesson? that ?models are what they eat.? Effective data curation?a sophisticated process involving filtering, rebalancing, sequencing (curriculum), and synthetic data generation?allows for training models that are simultaneously faster, better, and smaller. Morcos recounts his personal journey from focusing on model-centric inductive biases to realizing that data quality is the primary lever for breaking the diminishing returns of naive scaling laws. Datology?s mission is to automate this complex curation process, making state-of-the-art data accessible to any organization and enabling a new paradigm of AI development where data efficiency, not just raw scale, drives progress.

Full Video Episode

Timestamps

00:00 Introduction

00:46 What is Datology? The mission to train models faster, better, and smaller through data curation.

01:59 Ari?s background: From neuroscience to realizing the ?Bitter Lesson? of AI.

05:30 Key Insight: Inductive biases from architecture become less important and even harmful as data scale increases.

08:08 Thesis: Data is the most underinvested area of AI research relative to its impact.

10:15 Why data work is culturally undervalued in research and industry.

12:19 How self-supervised learning changed everything, moving from a data-scarce to a data-abundant regime.

17:05 Why automated curation is superior to human-in-the-loop, citing the DCLM study.

19:22 The ?Elephants vs. Dogs? analogy for managing data redundancy and complexity.

22:46 A brief history and commentary on key datasets (Common Crawl, GitHub, Books3).

26:24 Breaking naive scaling laws by improving data quality to maintain high marginal information gain.

29:07 Datology?s demonstrated impact: Achieving baseline performance 12x faster.

34:19 The business of data: Datology?s moat and its relationship with open-source datasets.

39:12 Synthetic Data Explain

ed: The difference between risky ?net-new? creation and powerful ?rephrasing.?

49:02 The Resurgence of Curriculum Learning: Why ordering data matters in the underfitting regime.

52:55 The Future of Training: Optimizing pre-training data to make post-training more effective.

54:49 Who is training their own models and why (Sovereign AI, large enterprises).

57:24 ?Train Smaller?: Why inference cost makes smaller, specialized models the ultimate goal for enterprises.

01:00:19 The problem with model pruning and why data-side solutions are complementary.

01:03:03 On finding the smallest possible model for a given capability.

01:06:49 Key learnings from the RC foundation model collaboration, proving that data curation ?stacks.?

01:09:46 Lightning Round: What data everyone wants & who should work at Datology.

01:14:24 Commentary on Meta?s superintelligence efforts and Yann LeCun?s role.

We first had Nathan on to give us his RLHF deep dive when he was joining AI2, and now he?s back to help us catch up on the evolution to RLVR (Reinforcement Learning with Verifiable Rewards), first proposed in his Tulu 3 paper. While RLHF remains foundational, RLVR has emerged as a powerful approach for training models on tasks with clear success criteria and using verifiable, objective functions as reward signals?particularly useful in domains like math, code correctness, and instruction-following. Instead of relying solely on subjective human feedback, RLVR leverages deterministic signals to guide optimization, making it more scalable and potentially more reliable across many domains. However, he notes that RLVR is still rapidly evolving, especially regarding how it handles tool use and multi-step reasoning.

We also discussed the Tulu model series, a family of instruction-tuned open models developed at AI2. Tulu is designed to be a reproducible, state-of-the-art post-training recipe for the open community. Unlike frontier labs like OpenAI or Anthropic, which rely on vast and often proprietary datasets, Tulu aims to distill and democratize best practices for instruction and preference tuning. We are impressed with how small eval suites, careful task selection, and transparent methodology can rival even the best proprietary models on specific benchmarks.

One of the most fascinating threads is the challenge of incorporating tool use into RL frameworks. Lambert highlights that while you can prompt a model to use tools like search or code execution, getting the model to reliably learn when and how to use them through RL is much harder. This is compounded by the difficulty of designing reward functions that avoid overoptimization?where models learn to ?game? the reward signal rather than solve the underlying task. This is particularly problematic in code generation, where models might reward hack unit tests by inserting pass statements instead of correct logic. As models become more agentic and are expected to plan, retrieve, and act across multiple tools, reward design becomes a critical bottleneck.

Other topics covered:

- The evolution from RLHF (Reinforcement Learning from Human Feedback) to RLVR (Reinforcement Learning from Verifiable Rewards)- The goals and technical architecture of the Tulu models, including the motivation to open-source post-training recipes- Challenges of tool use in RL: verifiability, reward design, and scaling across domains- Evaluation frameworks and the role of platforms like Chatbot Arena and emerging ?arena?-style benchmarks- The strategic tension between hybrid reasoning models and unified reasoning models at the frontier- Planning, abstraction, and calibration in reasoning agents and why these concepts matter- The future of open-source AI models, including DeepSeek, OLMo, and the potential for an ?American DeepSeek?- The importance of model personality, character tuning, and the model spec paradigm- Overoptimization in RL settings and how it manifests in different domains (control tasks, code, math)- Industry trends in inference-time scaling and model parallelism

Finally, the episode closes with a vision for the future of open-source AI. Nathan has now written up his ambition to build an ?American DeepSeek??a fully open, end-to-end reasoning-capable model with transparent training data, tools, and infrastructure. He emphasizes that open-source AI is not just about weights; it?s about releasing recipes, evaluations, and methods that lower the barrier for everyone to build and understand cutting-edge systems.

Full Video Episode

Timestamps

00:00 Welcome and Guest Introduction

01:18 Tulu, OVR, and the RLVR Journey

03:40 Industry Approaches to Post-Training and Preference Data

06:08 Understanding RLVR and Its Impact

06:18 Agents, Tool Use, and Training Environments

10:34 Open Data, Human Feedback, and Benchmarking

12:44 Chatbot Arena, Sycophancy, and Evaluation Platforms

15:42 RLHF vs RLVR: Books, Algorithms, and Future Directions

17:54 Frontier Models: Reasoning, Hybrid Models, and Data

22:11 Search, Retrieval, and Emerging Model Capabilities

29:23 Tool Use, Curriculum, and Model Training Challenges

38:06 Skills, Planning, and Abstraction in Agent Models

46:50 Parallelism, Verifiers, and Scaling Approaches

54:33 Overoptimization and Reward Design in RL

1:02:27 Open Models, Personalization, and the Model Spec

1:06:50 Open Model Ecosystem and Infrastructure

1:13:05 Meta, Hardware, and the Future of AI Competition

1:15:42 Building an Open DeepSeek and Closing Thoughts

ChatGPT handles 2.5B prompts/day and is on track to match Google?s daily searches by end of 2026. AI agents don?t browse like us?they crave queryable, chunkable data for tools like ChatGPT & Perplexity. A new industry is being born, some are calling it AI SEO, others GEO, but what is clear is that it drives amazing results. Businesses are seeing 2-4x higher conversion from visitors coming from AI compared to traditional search. Robert McCloy is the co-founder of Scrunch AI (https://scrunchai.com/), a fast growing company that helps brands and businesses re-write their content on the fly based on what agents are looking for.

Full Video Episode

Timestamps

00:00 Intro & Guest Introduction

01:30 The Genesis of Scrunch AI & AI Search Impact

06:02 AI Search Engines vs. Traditional SEO

06:28 Monitoring Prompts & The AI Search Stack

08:26 AI Training Data, Crawlers, and Content Strategy

12:33 AI Browsers and the Future of Web Consumption

16:06 Technical Mechanisms of AI Search & SEO Relevance

28:44 Personalization, Agent Experience, and Customer Journeys

30:44 Prompt Clusters, User Intent, and B2B Buying Patterns

36:06 Optimization Tactics: Prompt Injection, Content, and Pitfalls

40:37 Technical Content Delivery: JavaScript, Programmatic SEO, and LMS.txt

47:31 Case Studies & Conversion Optimization

51:36 Market Share & Platform Trends in AI Search

55:10 Wrap-Up & Future of AI-Driven Web

Saoud Rizwan and Pash from Cline joined us to talk about why fast apply models got bitter lesson?d, how they pioneered the plan + act paradigm for coding, and why non-technical people use IDEs to do marketing and generate slides.

Full writeup: https://www.latent.space/p/cline

X: https://x.com/latentspacepod

Full Video Episode

Timestamps

00:00 - Introductions 01:35 - Plan and Act Paradigm 05:37 - Model Evaluation and Early Development of Cline 08:14 - Use Cases of Cline Beyond Coding 09:09 - Why Cline is a VS Code Extension and Not a Fork 12:07 - Economic Value of Programming Agents 16:07 - Early Adoption for MCPs 19:35 - Local vs Remote MCP Servers 22:10 - Anthropic?s Role in MCP Registry 22:49 - Most Popular MCPs and Their Use Cases 25:26 - Challenges and Future of MCP Monetization 27:32 - Security and Trust Issues with MCPs 28:56 - Alternative History Without MCP 29:43 - Market Positioning of Coding Agents and IDE Integration Matrix 32:57 - Visibility and Autonomy in Coding Agents 35:21 - Evolving Definition of Complexity in Programming Tasks 38:16 - Forks of Cline and Open Source Regrets 40:07 - Simplicity vs Complexity in Agent Design 46:33 - How Fast Apply Got Bitter Lesson?d 49:12 - Cline?s Business Model and Bring-Your-Own-API-Key Approach 54:18 - Integration with OpenRouter and Enterprise Infrastructure 55:32 - Impact of Declining Model Costs 57:48 - Background Agents and Multi-Agent Systems 1:00:42 - Vision and Multi-Modalities 1:01:07 - State of Context Engineering 1:07:37 - Memory Systems in Coding Agents 1:10:14 - Standardizing Rules Files Across Agent Tools 1:11:16 - Cline?s Personality and Anthropomorphization 1:12:55 - Hiring at Cline and Team Culture

Speak (https://speak.com) may not be very well known to native English speakers, but they have come from a slow start in 2016 to emerge as one of the favorite partners of OpenAI, with their Startup Fund leading and joining their Series B and C as one of the new AI-native unicorns, noting that ?Speak has the potential to revolutionize not just language learning, but education broadly?.

Today we speak with Speak?s CTO, Andrew Hsu, on the journey of building the ?3rd generation? of language learning software (with Rosetta Stone being Gen 1, and Duolingo being Gen 2). Speak?s premise is that speech and language models can now do what was previously only possible with human tutors?provide fluent, responsive, and adaptive instruction?and this belief has shaped its product and company strategy since its early days.

https://www.linkedin.com/in/adhsu/

https://speak.com

One of the most interesting strategic decisions discussed in the episode is Speak?s early focus on South Korea. While counterintuitive for a San Francisco-based startup, the decision was influenced by a combination of market opportunity and founder proximity via a Korean first employee. South Korea?s intense demand for English fluency and a highly competitive education market made it a proving ground for a deeply AI-native product. By succeeding in a market saturated with human-based education solutions, Speak validated its model and built strong product-market fit before expanding to other Asian markets and eventually, globally.

The arrival of Whisper and GPT-based LLMs in 2022 marked a turning point for Speak. Suddenly, capabilities that were once theoretical?real-time feedback, semantic understanding, conversational memory?became technically feasible. Speak didn?t pivot, but rather evolved into its second phase: from a supplemental practice tool to a full-featured language tutor. This transition required significant engineering work, including building custom ASR models, managing latency, and integrating real-time APIs for interactive lessons. It also unlocked the possibility of developing voice-first, immersive roleplay experiences and a roadmap to real-time conversational fluency.

To scale globally and support many languages, Speak is investing heavily in AI-generated curriculum and content. Instead of manually scripting all lessons, they are building agents and pipelines that can scaffold curriculum, generate lesson content, and adapt pedagogically to the learner. This ties into one of Speak?s most ambitious goals: creating a knowledge graph that captures what a learner knows and can do in a target language, and then adapting the course path accordingly. This level-adjusting tutor model aims to personalize learning at scale and could eventually be applied beyond language learning to any educational domain.

Finally, the conversation touches on the broader implications of AI-powered education and the slow real-world adoption of transformative AI technologies. Despite the capabilities of GPT-4 and others, most people?s daily lives haven?t changed dramatically. Speak sees itself as part of the generation of startups that will translate AI?s raw power into tangible consumer value. The company is also a testament to long-term conviction?founded in 2016, it weathered years of slow growth before AI caught up to its vision. Now, with over $50M ARR, a growing B2B arm, and plans to expand across languages and learning domains, Speak represents what AI-native education could look like in the next decade.

Full Video Episode

Timestamps

00:00 Introductions & Thiel Fellowship Origins

02:13 Genesis of Speak: Early Vision & Market Focus

03:44 Building the Product: Iterations and Lessons Learned

10:59 AI?s Role in Language Learning

13:49 Scaling Globally & B2B Expansion

16:30 Why Korea? Localizing for Success

19:08 Content Creation, The Speak Method, and Engineering Culture

23:31 The Impact of Whisper and LLM Advances

29:08 AI-Generated Content & Measuring Fluency

35:30 Personalization, Dialects, and Pronunciation

39:38 Immersive Learning, Multimodality, and Real-Time Voice

50:02 Engineering Challenges & Company Culture

53:20 Beyond Languages: B2B, Knowledge Graphs, and Broader Learning

57:32 Fun Stories, Lessons, and Reflections

1:02:03 Final Thoughts: The Future of AI Learning & Slow Takeoff

When the first video diffusion models started emerging, they were little more than just ?moving pictures? - still frames extended a few seconds in either direction in time. There was a ton of excitement about OpenAI?s Sora on release through 2024, but so far only Sora-lite has been widely released. Meanwhile, other good videogen models like Genmo Mochi, Pika, MiniMax T2V, Tencent Hunyuan Video, and Kuaishou?s Kling have emerged, but the reigning king this year seems to be Google?s Veo 3, which for the first time has added native audio generation into their model capabilities, eliminating the need for a whole class of lipsynching tooling and SFX editing.

The rise of Veo 3 unlocks a whole new category of AI Video creators that many of our audience may not have been exposed to, but is undeniably effective and important particularly in the ?kids? and ?brainrot? segments of the global consumer internet platforms like Tiktok, YouTube and Instagram.

By far the best documentarians of these trends for laypeople are Olivia and Justine Moore, both partners at a16z, who not only collate the best examples from all over the web, but dabble in video creation themselves to put theory into practice. We?ve been thinking of dabbling in AI brainrot on a secondary channel for Latent Space, so we wanted to get the braindump from the Moore twins on how to make a Latent Space Brainrot channel. Jump on in!

Full Video Episode

Timestamps

00:00 Introductions & Guest Welcome

00:49 The Rise of Generative Media

02:24 AI Video Trends: Italian Brain Rot & Viral Characters

05:00 Following Trends & Creating AI Content

07:17 Hands-On with AI Video Creation

18:36 Monetization & Business of AI Content

23:34 Platforms, Models, and the Creator Stack

37:22 Native Content vs. Clipping & Going Viral

41:52 Prompt Theory & Meta-Trends in AI Creativity

47:42 Professional, Commercial, and Platform-Specific AI Video

48:57 Wrap-Up & Final Thoughts

Our last AI PhD grad student feature was Shunyu Yao, who happened to focus on Language Agents for his thesis and immediately went to work on them for OpenAI. Our pick this year is Jack Morris, who bucks the ?hot? trends by -not- working on agents, benchmarks, or VS Code forks, but is rather known for his work on the information theoretic understanding of LLMs, starting from embedding models and latent space representations (always close to our heart).

Jack is an unusual combination of doing underrated research but somehow still being to explain them well to a mass audience, so we felt this was a good opportunity to do a different kind of episode going through the greatest hits of a high profile AI PhD, and relate them to questions from AI Engineering.

Papers and References made

* AI grad school:

* A new type of information theory:

* Embeddings

* Text Embeddings Reveal (Almost) As Much As Text: https://arxiv.org/abs/2310.06816

* Contextual document embeddings https://arxiv.org/abs/2410.02525

Harnessing the Universal Geometry of Embeddings: https://arxiv.org/abs/2505.12540

* Language models

* GPT-style language models memorize 3.6 bits per param:

* Approximating Language Model Training Data from Weights: https://arxiv.org/abs/2506.15553

* LLM Inversion

* ?There Are No New Ideas In AI.... Only New Datasets?

* misc reference: https://junyanz.github.io/CycleGAN/

?

for others hiring AI PhDs, Jack also wanted to shout out his coauthor

Zach Nussbaum, his coauthor on Nomic Embed: Training a Reproducible Long Context Text Embedder.

Full Video Episode

Timestamps

00:00 Introduction to Jack Morris01:18 Career in AI03:29 The Shift to AI Companies03:57 The Impact of ChatGPT04:26 The Role of Academia in AI05:49 The Emergence of Reasoning Models07:07 Challenges in Academia: GPUs and HPC Training11:04 The Value of GPU Knowledge14:24 Introduction to Jack's Research15:28 Information Theory17:10 Understanding Deep Learning Systems19:00 The "Bit" in Deep Learning20:25 Wikipedia and Information Storage23:50 Text Embeddings and Information Compression27:08 The Research Journey of Embedding Inversion31:22 Harnessing the Universal Geometry of Embeddings34:54 Implications of Embedding Inversion36:02 Limitations of Embedding Inversion38:08 The Capacity of Language Models40:23 The Cognitive Core and Model Efficiency50:40 The Future of AI and Model Scaling52:47 Approximating Language Model Training Data from Weights01:06:50 The "No New Ideas, Only New Datasets" Thesis

Solving Poker and Diplomacy, Debating RL+Reasoning with Ilya, what?s *wrong* with the System 1/2 analogy, and where Test-Time Compute hits a wall

Full Video Episode

Timestamps

00:00 Intro ? Diplomacy, Cicero & World Championship 02:00 Reverse Centaur: How AI Improved Noam?s Human Play 05:00 Turing Test Failures in Chat: Hallucinations & Steerability 07:30 Reasoning Models & Fast vs. Slow Thinking Paradigm 11:00 System 1 vs. System 2 in Visual Tasks (GeoGuessr, Tic-Tac-Toe) 14:00 The Deep Research Existence Proof for Unverifiable Domains 17:30 Harnesses, Tool Use, and Fragility in AI Agents 21:00 The Case Against Over-Reliance on Scaffolds and Routers 24:00 Reinforcement Fine-Tuning and Long-Term Model Adaptability 28:00 Ilya?s Bet on Reasoning and the O-Series Breakthrough 34:00 Noam?s Dev Stack: Codex, Windsurf & AGI Moments 38:00 Building Better AI Developers: Memory, Reuse, and PR Reviews 41:00 Multi-Agent Intelligence and the ?AI Civilization? Hypothesis 44:30 Implicit World Models and Theory of Mind Through Scaling 48:00 Why Self-Play Breaks Down Beyond Go and Chess 54:00 Designing Better Benchmarks for Fuzzy Tasks 57:30 The Real Limits of Test-Time Compute: Cost vs. Time 1:00:30 Data Efficiency Gaps Between Humans and LLMs 1:03:00 Training Pipeline: Pretraining, Midtraining, Posttraining 1:05:00 Games as Research Proving Grounds: Poker, MTG, Stratego 1:10:00 Closing Thoughts ? Five-Year View and Open Research Directions

Emmanuel Amiesen is lead author of ?Circuit Tracing: Revealing Computational Graphs in Language Models? (https://transformer-circuits.pub/2025/attribution-graphs/methods.html ), which is part of a duo of MechInterp papers that Anthropic published in March (alongside https://transformer-circuits.pub/2025/attribution-graphs/biology.html ).

We recorded the initial conversation a month ago, but then held off publishing until the open source tooling for the graph generation discussed in this work was released last week: https://www.anthropic.com/research/open-source-circuit-tracing

This is a 2 part episode - an intro covering the open source release, then a deeper dive into the paper ? with guest host Vibhu Sapra (https://x.com/vibhuuuus ) and Mochi the MechInterp Pomsky (https://x.com/mochipomsky ). Thanks to Vibhu for making this episode happen!

While the original blogpost contained some fantastic guided visualizations (which we discuss at the end of this pod!), with the notebook and Neuronpedia visualization (https://www.neuronpedia.org/gemma-2-2b/graph ) released this week, you can now explore on your own with Neuronpedia, as we show you in the video version of this pod.

Full Video Episode

Timestamps

00:00 Intro & Guest Introductions01:00 Anthropic's Circuit Tracing Release06:11 Exploring Circuit Tracing Tools & Demos13:01 Model Behaviors and User Experiments17:02 Behind the Research: Team and Community24:19 Main Episode Start: Mech Interp Backgrounds25:56 Getting Into Mech Interp Research31:52 History and Foundations of Mech Interp37:05 Core Concepts: Superposition & Features39:54 Applications & Interventions in Models45:59 Challenges & Open Questions in Interpretability57:15 Understanding Model Mechanisms: Circuits & Reasoning01:04:24 Model Planning, Reasoning, and Attribution Graphs01:30:52 Faithfulness, Deception, and Parallel Circuits01:40:16 Publishing Risks, Open Research, and Visualization01:49:33 Barriers, Vision, and Call to Action

Solomon most famously created Docker and now runs Dagger? which has something special to share with you on Thursday.

Catch Dagger at:

- Tuesday: Dagger?s workshop https://www.ai.engineer/schedule#ship-agents-that-ship-a-hands-on-workshop-for-swe-agent-builders

- Wednesday: Dagger?s talk: https://www.ai.engineer/schedule#how-to-trust-an-agent-with-software-delivery

- Thursday: Solomon?s Keynote https://www.ai.engineer/schedule#containing-agent-chaos

Full Video Episode

Timestamps

00:00 Introduction & Guest Background00:29 What is Dagger? Post-Development Automation01:08 Dagger?s Community & Platform Engineers02:32 AI Agents and Developer Workflows03:40 Environment Isolation & The Power of Containers06:28 The Need for Standards in Agent Environments07:25 Design Constraints & Challenges for Dev Environments11:26 Limitations of Current Tools & Agent-Native UX14:11 Modularity, Customization, and the Lego Analogy16:24 Convergence of CICD and Agentic Systems17:41 Ephemeral Apps, Resource Constraints, and Local Execution21:01 Adoption, Ecosystem, and the Role of Open Source23:30 Dagger?s Modular Approach & Integration Philosophy25:38 Looking Ahead: Workshops, Keynotes, and the Future of Agentic Infrastructure

As part of our AI Engineer World?s Fair preview, we?re releasing a special cross podcast recorded with Sam Charrington of TWiML AI at last week?s Google I/O!

TUESDAY: Shrestha and Kwindla?s workshop: https://www.ai.engineer/schedule#milliseconds-to-magic-real-time-workflows-using-the-gemini-live-api-and-pipecat

TUESDAY: Kwindla?s workshop: https://www.ai.engineer/schedule#building-voice-agents-with-gemini-and-pipecat

WEDNESDAY: Shrestha and Kwindla?s talk: https://www.ai.engineer/schedule#milliseconds-to-magic-real-time-workflows-using-the-gemini-live-api-and-pipecat

WEDNESDAY: Kwindla?s keynote: https://www.ai.engineer/schedule#-voice-keynote-your-realtime-ai-is-ngmi

THURSDAY: Logan?s keynote: https://www.ai.engineer/schedule#a-year-of-gemini-progress-what-comes-next

Catch all the speakers at AIE (both workshops and talks):

Logan Kilpatrick: https://www.latent.space/p/chatgpt-gpt4-hype-and-building-llm

Shrestha Basu Mallick: https://www.linkedin.com/in/shresthabm/

Kwindla Hultman Kramer: https://www.linkedin.com/in/kwkramer

Full Video Episode

One of the new tracks at next week?s AI Engineer conference in SF is a new focus on LLMs + Robotics, ft. household names like Waymo and Physical Intelligence. However there are many other companies applying LLMs and VLMs in the real world!

CloudChef, the first industrial-scale kitchen robotics company with one-shot demonstration learning and an incredibly simple business model, will be serving tasty treats all day with Zippy (https://www.cloudchef.co/zippy ) their AI Chef platform.

This is a lightning pod with CEO Nikhil Abraham to preview what Zippy is capable of!

https://www.cloudchef.co/platform

See a real chef comparison:

See it in the AI Engineer Expo at SF next week: https://ai.engineer

Full Video Episode

Timestamps

00:00 Welcome and Introductions00:58 What is Cloud Chef?01:36 How the Robots Work: Culinary Intelligence05:57 Commercial Applications and Early Success07:02 The Software-First Approach10:09 Business Model and Pricing13:10 Demonstration Learning: Training the Robots16:03 Call to Action and Engineering Opportunities18:45 Final Thoughts and Technical Details

We are joined by Eno Reyes and Matan Grinberg, the co-founders of Factory.ai. They are building droids for autonomous software engineering, handling everything from code generation to incident response for production outages. After raising a $15M Series A from Sequoia, they just released their product in GA!

https://factory.ai/

https://x.com/latentspacepod

Full Video Episode

Timestamps

00:00 Introductions 00:35 Meeting at Langchain Hackathon 04:02 Building Factory despite early model limitations 06:56 What is Factory AI? 08:55 Delegation vs Collaboration in AI Development Tools 10:06 Naming Origins of 'Factory' and 'Droids' 12:17 Defining Droids: Agent vs Workflow 14:34 Live Demo17:37 Enterprise Context and Tool Integration in Droids 20:26 Prompting, Clarification, and Agent Communication 22:28 Project Understanding and Proactive Context Gathering 24:10 Why SWE-Bench Is Dead 28:47 Model Fine-tuning and Generalization Challenges 31:07 Why Factory is Browser-Based, Not IDE-Based 33:51 Test-Driven Development and Agent Verification 36:17 Retrieval vs Large Context Windows for Cost Efficiency 38:02 Enterprise Metrics: Code Churn and ROI 40:48 Executing Large Refactors and Migrations with Droids 45:25 Model Speed, Parallelism, and Delegation Bottlenecks 50:11 Observability Challenges and Semantic Telemetry 53:44 Hiring55:19 Factory's design and branding approach 58:34 Closing Thoughts and Future of AI-Native Development

In an otherwise heavy week packed with Microsoft Build, Google I/O, and OpenAI io, the worst kept secret in biglab land was the launch of Claude 4, particularly the triumphant return of Opus, which many had been clamoring for. We will leave the specific Claude 4 recap to AINews, however we think that both Gemini?s progress on Deep Think this week and Claude 4 represent the next frontier of progress on inference time compute/reasoning (at last until GPT5 ships this summer).

Will Brown?s talk at AIE NYC and open source work on verifiers have made him one of the most prominent voices able to publicly discuss (aka without the vaguepoasting LoRA they put on you when you join a biglab) the current state of the art in reasoning models and where current SOTA research directions lead. We discussed his latest paper on Reinforcing Multi-Turn Reasoning in LLM Agents via Turn-Level Credit Assignment and he has previewed his AIEWF talk on Agentic RL for those with the temerity to power thru bad meetup audio.

Full Video Episode

Timestamps

00:00 Introduction to the Podcast and Guests01:00 Discussion on Claude 4 and AI Models03:07 Extended Thinking and Tool Use in AI06:47 Technical Highlights and Model Trustworthiness10:31 Thinking Budgets and Their Implications13:38 Controversy Surrounding Opus and AI Ethics18:49 Reflections on AI Tools and Their Limitations21:58 The Chaos of Predictive Systems22:56 Marketing and Safety in AI Models24:30 Evaluating AI Companies and Their Strategies25:53 The Role of Academia in AI Evaluations27:43 Teaching Taste in Research28:41 Making Educated Bets in AI Research30:12 Recent Developments in Multi-Turn Tool Use32:50 Incentivizing Tool Use in AI Models34:45 The Future of Reward Models in AI39:10 Exploring Flexible Reward Systems

Note from your hosts: we were off this week for ICLR and RSA! This week we?re bringing you one of the top episodes from our lightning podcast series, the shorter format, Youtube-only side podcast we do for breaking news and faster turnaround. Please support our work on YouTube! https://www.youtube.com/playlist?list=PLWEAb1SXhjlc5qgVK4NgehdCzMYCwZtiB

The explosion of embedding-based applications created a new challenge: efficiently storing, indexing, and searching these high-dimensional vectors at scale. This gap gave rise to the vector database category, with companies like Pinecone leading the charge in 2022-2023 by defining specialized infrastructure for vector operations.

The category saw explosive growth following ChatGPT?s launch in late 2022, as developers rushed to build AI applications using Retrieval-Augmented Generation (RAG). This surge was partly driven by a widespread misconception that embedding-based similarity search was the only viable method for retrieving context for LLMs!!!

The resulting ?vector database gold rush? saw massive investment and attention directed toward vector search infrastructure, even though traditional information retrieval techniques remained equally valuable for many RAG applications.

Full Video Episode

Timestamps

00:00 Introduction to Trondheim and Background03:03 The Rise and Fall of Vector Databases06:08 Convergence of Search Technologies09:04 Embeddings and Their Importance12:03 Building Effective Search Systems15:00 RAG Applications and Recommendations17:55 The Role of Knowledge Graphs20:49 Future of Embedding Models and Innovations

We?ll keep this brief because we?re on a tight turnaround: GPT 4.1, previously known as the Quasar and Optimus models, is now live as the natural update for 4o/4o-mini (and the research preview of GPT 4.5). Though it is a general purpose model family, the headline features are:

Coding abilities (o1-level SWEBench and SWELancer, but ok Aider)

Instruction Following (with a very notable prompting guide)

Long Context up to 1m tokens (with new MRCR and Graphwalk benchmarks)

Vision (simply o1 level)

Cheaper Pricing (cheaper than 4o, greatly improved prompt caching savings)

We caught up with returning guest Michelle Pokrass and Josh McGrath to get more detail on each!

Full Video Episode

Timestamps

Part 100:00:00 Introduction and Guest Welcome00:00:57 GPT 4.1 Launch Overview00:01:54 Developer Feedback and Model Names00:02:53 Model Naming and Starry Themes00:03:49 Confusion Over GPT 4.1 vs 4.500:04:47 Distillation and Model Improvements00:05:45 Omnimodel Architecture and Future Plans00:06:43 Core Capabilities of GPT 4.100:07:40 Training Techniques and Long Context00:08:37 Challenges in Long Context Reasoning00:09:34 Context Utilization in ModelsPart 200:10:31 Graph Walks and Model Evaluation00:11:31 Real Life Applications of Graph Tasks00:12:30 Multi-Hop Reasoning Benchmarks00:13:30 Agentic Workflows and Backtracking00:14:28 Graph Traversals for Agent Planning00:15:24 Context Usage in API and Memory Systems00:16:21 Model Performance in Long Context Tasks00:17:17 Instruction Following and Real World Data00:18:12 Challenges in Grading Instructions00:19:09 Instruction Following Techniques00:20:09 Prompting Techniques and Model Responses00:21:05 Agentic Workflows and Model PersistencePart 300:22:01 Balancing Persistence and User Control00:22:56 Evaluations on Model Edits and Persistence00:23:55 XML vs JSON in Prompting00:24:50 Instruction Placement in Context00:25:49 Optimizing for Prompt Caching00:26:49 Chain of Thought and Reasoning Models00:27:46 Choosing the Right Model for Your Task00:28:46 Coding Capabilities of GPT 4.100:29:41 Model Performance in Coding Tasks00:30:39 Understanding Coding Model Differences00:31:36 Using Smaller Models for Coding00:32:33 Future of Coding in OpenAIPart 400:33:28 Internal Use and Success Stories00:34:26 Vision and Multi-Modal Capabilities00:35:25 Screen vs Embodied Vision00:36:22 Vision Benchmarks and Model Improvements00:37:19 Model Deprecation and GPU Usage00:38:13 Fine-Tuning and Preference Steering00:39:12 Upcoming Reasoning Models00:40:10 Creative Writing and Model Humor00:41:07 Feedback and Developer Community00:42:03 Pricing and Blended Model Costs00:44:02 Conclusion and Wrap-Up

We are calling for the world?s best AI Engineer talks for AI Architects, /r/localLlama, Model Context Protocol (MCP), GraphRAG, AI in Action, Evals, Agent Reliability, Reasoning and RL, Retrieval/Search/RecSys , Security, Infrastructure, Generative Media, AI Design & Novel AI UX, AI Product Management, Autonomy, Robotics, and Embodied Agents, Computer-Using Agents (CUA), SWE Agents, Vibe Coding, Voice, Sales/Support Agents at AIEWF 2025! Fill out the 2025 State of AI Eng survey for $250 in Amazon cards and see you from Jun 3-5 in SF!

Coreweave?s now-successful IPO has led to a lot of questions about the GPU Neocloud market, which Dylan Patel has written extensively about on SemiAnalysis. Understanding markets requires an interesting mix of technical and financial expertise, so this will be a different kind of episode than our usual LS domain.

When we first published $2 H100s: How the GPU Rental Bubble Burst, we got 2 kinds of reactions on Hacker News:

* ?Ah, now the AI bubble is imploding!?

* ?Duh, this is how it works in every GPU cycle, are you new here??

We don?t think either reaction is quite right. Specifically, it is not normal for the prices of one of the world?s most important resources right now to swing from $1 to $8 per hour based on drastically inelastic demand AND supply curves - from 3 year lock-in contracts to stupendously competitive over-ordering dynamics for NVIDIA allocations ? especially with increasing baseline compute needed for even the simplest academic ML research and for new AI startups getting off the ground.

We?re fortunate today to have Evan Conrad, CEO of SFCompute, one of the most exciting GPU marketplace startups, talk us through his theory of the economics of GPU markets, and why he thinks CoreWeave and Modal are well positioned, but Digital Ocean and Together are not.

However, more broadly, the entire point of SFC is creating liquidity between GPU owners and consumers and making it broadly tradable, even programmable:

As we explore, these are the primitives that you can then use to create your own, high quality, custom GPU availability for your time and money budget, similar to how Amazon Spot Instances automated the selective buying of unused compute.

The ultimate end state of where all this is going is GPU that trade like other perishable, staple commodities of the world - oil, soybeans, milk. Because the contracts and markets are so well established, the price swings also are not nearly as drastic, and people can also start hedging and managing the risk of one of the biggest costs of their business, just like we have risk-managed commodities risks of all other sorts for centuries. As a former derivatives trader, you can bet that swyx doubleclicked on that?

Show Notes

* SF Compute

* Evan Conrad

* Ethan Anderson

* John Phamous

* The Curve talk

* CoreWeave

* Andromeda Cluster

Full Video Pod

Like and subscribe!

Timestamps

* [00:00:05] Introductions

* [00:00:12] Introduction of guest Evan Conrad from SF Compute

* [00:00:12] CoreWeave Business Model Discussion

* [00:05:37] CoreWeave as a Real Estate Business

* [00:08:59] Interest Rate Risk and GPU Market Strategy Framework

* [00:16:33] Why Together and DigitalOcean will lose money on their clusters

* [00:20:37] SF Compute's AI Lab Origins

* [00:25:49] Utilization Rates and Benefits of SF Compute Market Model

* [00:30:00] H100 GPU Glut, Supply Chain Issues, and Future Demand Forecast

* [00:34:00] P2P GPU networks

* [00:36:50] Customer stories

* [00:38:23] VC-Provided GPU Clusters and Credit Risk Arbitrage

* [00:41:58] Market Pricing Dynamics and Preemptible GPU Pricing Model

* [00:48:00] Future Plans for Financialization?

* [00:52:59] Cluster auditing and quality control

* [00:58:00] Futures Contracts for GPUs

* [01:01:20] Branding and Aesthetic Choices Behind SF Compute

* [01:06:30] Lessons from Previous Startups

* [01:09:07] Hiring at SF Compute

Transcript

Alessio [00:00:05]: Hey everyone, welcome to the Latent Space podcast. This is Alessio, partner and CTO at Decibel, and I'm joined by my co-host Swyx, founder of Smol AI.

Swyx [00:00:12]: Hey, and today we're so excited to be finally in the studio with Evan Conrad from SF Compute. Welcome. I've been fortunate enough to be your friend before you were famous, and also we've hung out at various social things. So it's really cool to see that SF Compute is coming into its own thing, and it's a significant presence, at least in the San Francisco community, which of course, it's in the name, so you couldn't help but be.

Evan: Indeed, indeed. I think we have a long way to go, but yeah, thanks.

Swyx: Of course, yeah. One way I was thinking about kicking on this conversation is we will likely release this right after CoreWeave IPO. And I was watching, I was looking, doing some research on you. You did a talk at The Curve. I think I may have been viewer number 70. It was a great talk. More people should go see it, Evan Conrad at The Curve. But we have like three orders of magnitude more people. And I just wanted to, to highlight, like, what is your analysis of what CoreWeave did that went so right for them?

Evan: Sell locked-in long-term contracts and don't really do much short-term at all. I think like a lot of people had this assumption that GPUs would work a lot like CPUs and the like standard business model of any sort of CPU cloud is you buy commodity hardware, then you lay on services that are mostly software, and that gives you high margins and pretty much all your value comes from those services. Not really the underlying. Compute in any capacity and because it's commodity hardware and it's not actually that expensive, most of that can be sort of on-demand compute. And while you do want locked-in contracts for folks, it's mostly just a sort of de-risk situation. It helps you plan revenue because you don't know if people are going to scale up or down. But fundamentally, people are like buying hourly and that's how your business is structured and you make 50 percent margins or higher. This like doesn't really work in GPUs. And the reason why it doesn't work is because you end up with like super price sensitive customers. And that isn't because necessarily it's just way more expensive, though that's totally the case. So in a CPU cloud, you might have like, you know, let's say if you had a million dollars of hardware in GPUs, you have a billion dollars of hardware. And so your customers are buying at much higher volumes than you otherwise expect. And it's also smaller customers who are buying at higher amounts of volume. So relative to what they're spending in general. But in GPUs in particular, your customer cares about the scaling law. So if you take like Gusto, for example, or Rippling or an HR service like this, when they're buying from an AWS or a GCP, they're buying CPUs and they're running web servers, those web servers, they kind of buy up to the capacity that they need, they buy enough, like CPUs, and then they don't buy any more, like, they don't buy any more at all. Yeah, you have a chart that goes like this and then flat. Correct. And it's like a complete flat. It's not even like an incremental tiny amount. It's not like you could just like turn on some more nodes. Yeah. And then suddenly, you know, they would make an incremental amount of money more, like Gusto isn't going to make like, you know, 5% more money, they're gonna make zero, like literally zero money from every incremental GPU or CPU after a certain point. This is not the case for anyone who is training models. And it's not the case for anyone who's doing test time inference or like inference that has scales at test time. Because like you, your scaling laws mean that you may have some diminishing returns, but there's always returns. Adding GPUs always means your model does actually get. And that actually does translate into revenue for you. And then for test time inference, you actually can just like run the inference longer and get a better performance. Or maybe you can run more customers faster and then charge for that. It actually does translate into revenue. Every incremental GPU translates to revenue. And what that means from the customer's perspective is you've got like a flat budget and you're trying to max the amount of GPUs you have for that budget. And it's very distinctly different than like where Augusto or Rippling might think, where they think, oh, we need this amount of CPUs. How do we, you know, reduce that? How do we reduce our amount of money that we're spending on this to get the same amount of CPUs? What that translates to is customers who are spending in really high volume, but also customers who are super price sensitive, who don't give a s**t. Can I swear on this? Can I swear? Yeah. Who don't give a s**t at all about your software. Because a 10% difference in a billion dollars of hardware is like $100 million of value for you. So if you have a 10% margin increase because you have great software, on your billion, the customers are that price sensitive. They will immediately switch off if they can. Because why wouldn't you? You would just take that $100 million. You'd spend $50 million on hiring a software engineering team to replicate anything that you possibly did. So that means that the best way to make money in GPUs was to do basically exactly what CoreWeave did, which is go out and sign only long-term contracts, pretty much ignore the bottom end of the market completely, and then maximize your long-term contracts. With customers who don't have credit risk, who won't sue you, or are unlikely to sue you for frivolous reasons. And then because they don't have credit risk and they won't sue you for frivolous reasons, you can go back to your lender and you can say, look, this is a really low risk situation for us to do. You should give me prime, prime interest rate. You should give me the lowest cost of capital you possibly can. And when you do that, you just make tons of money. The problem that I think lots of people are going to talk about with CoreWeave is it doesn't really look like a cloud platform. It doesn't really look like a cloud provider financially. It also doesn't really look like a software company financially.

Swyx [00:05:37]: It's a bank.

Evan [00:05:38]: It's a bank. It's a real estate company. And it's very hard to not be that. The problem of that that people have tricked themselves into is thinking that CoreWeave is a bad business. I don't think CoreWeave is explicitly a bad business. There's a bunch of people, there's kind of like two versions of the CoreWeave take at the moment. There's, oh my God, CoreWeave, amazing. CoreWeave is this great new cloud provider competitive with the hyperscalers. And to some extent, this is true from a structural perspective. Like, they are indeed a real sort of thing against the cloud providers in this particular category. And the other take is, oh my gosh, CoreWeave is this horrible business and so on and blah, blah, blah. And I think it's just like a set of perception or perspective. If you think CoreWeave's business is supposed to look like the traditional cloud providers, you're going to be really upset to learn that GPUs don't look like that at all. And in fact, for the hyperscalers, it doesn't look like this either. My intuition is that the hyperscalers are probably going to lose a lot of money, and they know they're going to lose a lot of money on reselling NVIDIA GPUs, at least. Hyperscalers, but I want to, Microsoft, AWS, Google. Correct, yeah. The Microsoft, AWS, and Google. Does Google resell? I mean, Google has TPUs. Google has TPUs, but I think you can also get H100s and so on. But there are like two ways they can make money. One is by selling to small customers who aren't actually buying in any serious volume. They're testing around, they're playing around. And if they get big, they're immediately going to do one of two things. They're going to ask you for a discount. Because they're not going to pay your crazy sort of margin that you have locked into your business. Because for CPUs, you need that. They're going to pay your massive per hour price. And so they want you to sign a long-term contract. And so that's your other way that you can make money, is you can basically do exactly what CoreWeave does, which is have them pay as much as possible upfront and lock in the contract for a long time. Or you can have small customers. But the problem is that for a hyperscaler, the GPUs to... To sell on the low margins relative to what your other business, your CPUs are, is a worse business than what you are currently doing. Because you could have spent the same money on those GPUs. And you could have trained model and you could have made a model on top of it and then turn that into a product and had high margins from your product. Or you could have taken that same money and you could have competed with NVIDIA. And you could have cut into their margin instead. But just simply reselling NVIDIA GPUs doesn't work like your CPU business. Where you're able to capture high margins from big customers and so on. And then they never leave you because your customers aren't actually price sensitive. And so they won't switch off if your prices are a little higher. You actually had a really nice chart, again, on that talk of this two by two. Sure. Of like where you want to be. And you also had some hot takes on who's making money and who isn't.

Swyx: So CoreUv locked up long-term contracts. Get that. Yes. Maybe share your mental framework. Just verbally describe it because we're trying to help the audio listeners as well. Sure. People can look up the chart if they want to.

Evan: Sure. Okay. So this is a graph of interest rates. And on the y-axis, it's a probability you're able to sell your GPUs from zero to one. And on the x-axis, it's how much they'll depreciate in cost from zero to one. And then you had ISO cost curves or ISO interest rate curves. Yeah. So they kind of shape in a sort of concave fashion. Yeah. The lowest interest rates enable the most aggressive. form of this cost curve. And the higher interest rates go, the more you have to push out to the top right. Yeah. And then you had some analysis of where every player sits in this, including CoreUv, but also Together and Modal and all these other guys. I thought that was super insightful. So I just wanted to elaborate. Basically, it's like a graph of risk and the genres of places where you can be and what the risk is associated with that. The optimal thing for you to do, if you can, is to lock in long-term contracts that are paid all up front or in with a situation in which you trust the other party to pay you over time. So if you're, you know, selling to Microsoft or something or OpenAI. Which are together 77% of the revenue of CoreUv. Yeah. So if you're doing that, that's a great business to be in because your interest rate that you can pitch for is really low because no one thinks Microsoft is going to default. And like maybe OpenAI will default, but the backing by Microsoft kind of doesn't. And I think there's enough, like, generally, it looks like OpenAI is winning that you can make it's just a much better case than if you're selling to the pre-seed startup that just raised $30 million or something pre-revenue. It's like way easier to make the case that the OpenAI is not going to default than the pre-seed startup. And so the optimal place to be is selling to the maximally low risk customer for as long as possible. And then you never have to worry about depreciation and you make lots of money. The less. Good. Good place to be is you could sell long-term contracts to people who might default on you. And then if you're not bringing it to the present, so you're not like saying, hey, you have to pay us all up front, then you're in this like more risky territory. So is it top left of the chart? If I have the chart right, maybe. Large contracts paid over time. Yeah. Large contracts paid over time is like top left. So it's more risky, but you could still probably get away with it. And then the other opportunity is that you could sell short-term contracts for really high prices. And so lots of people tried that too, because this is actually closer to the original business model that people thought would work in cloud providers for CPUs. It works for CPUs, but it doesn't really work for GPUs. And I don't think people were trying this because they were thinking about the risk associated with it. I think a lot of people are just come from a software background, have not really thought about like cogs or margins or inventory risk or things that you have to worry about in the physical world. And I think they were just like copy pasting the same business model onto CPUs. And also, I remember fundraising like a few years ago. And I know based on. Like what we knew other people were saying who were in a very similar business to us versus what we were saying. And we know that our pitch was way worse at the time, because in the beginning of SF Compute, we looked very similar to pretty much every other GPU cloud, not on purpose, but sort of accidentally. And I know that the correct pitch to give to an investor was we will look like a traditional CPU cloud with high margins and we'll sell to everyone. And that is a bad business model because your customers are price sensitive. And so what happens is if you. Sell at high prices, which is the price that you would need to sell it in order to de-risk your loss on the depreciation curve, and specifically what I mean by that is like, let's say you're selling it like $5 an hour and you're paying $1.50 an hour for the GPU under the hood. It's a little bit different than that, but you know, nice numbers, $5 an hour, $1.50 an hour. Great. Excellent. Well, you're charging a really high price per GPU hour because over time the price will go down and you'll get competed out. And what you need is to make sure that you never go under, or if you do go under your underlying cost. You've made so much money in the first part of it that the later end of it, like doesn't matter because from the whole structure of the deal, you've made money. The problem is that just, you think that you're going to be able to retain your customers with software. And actually what happens is your customers are super price sensitive and push you down and push you down and push you down and push you down, um, that they don't care about your software at all. And then the other problem that you have is you have, um, really big players like the hyperscalers who are looking to win the market and they have way more money than you, and they can push down on margin. Much better than you can. And so if they have to, and they don't, they don't necessarily all the time, um, I think they actually keep pride of higher margin, but if they needed to, they could totally just like wreck your margin at any point, um, and push you down, which meant that that quadrant over there where you're charging a high price, um, and just to make up for the risk completely got destroyed, like did not work at all for many places because of the price sensitivity, because people could just shove you down instead that pushed everybody up to the top right-hand corner of that, which is selling short-term. Contracts for low prices paid over time, which is the worst place to be in, um, the worst financial place to be in because it has the highest interest rate, um, which means that your, um, your costs go up at the same time, your, uh, your incoming cash goes down and squeezes your margins and squeezes your margins. The nice thing for like a core weave is that most of their business is over on the, on the other sides of those quadrants that the ones that survive. The only remaining question I have with core weave, and I promise I get to ask if I can compute, and I promise this is relevant to SOF Compute in general, because the framework is important, right? Sure. To understand the company. So why didn't NVIDIA or Microsoft, both of which have more money than core weave, do core weave, right? Why didn't they do core weave? Why have this middleman when either NVIDIA or Microsoft have more money than God, and they could have done an internal core weave, which is effectively like a self-funding vehicle, like a financial instrument. Why does there have to be a third party? Your question is like... Why didn't Microsoft, or why didn't NVIDIA just do core weave? Why didn't they just set up their own cloud provider? I think, and I don't know, and so correct me if I'm wrong, and lots of people will have different opinions here, or I mean, not opinions, they'll have actual facts that differ from my facts. Those aren't opinions. Those are actually indeed differences of reality, is that NVIDIA doesn't want to compete with their customers. They make a large amount of money by selling to existing clouds. If they launched their own core weave, then it would be a lot more money. It'd make it much harder for them to sell to the hyperscalers, and so they have a complex relationship with there. So not great for them. Second is that, at least for a while, I think they were dealing with antitrust concerns or fears that if they're going through, if they own too much layers of the stack, I could imagine that could be a problem for them. I don't know if that's actually true, but that's where my mind would go, I guess. Mostly, I think it's the first one. It's that they would be competing directly with their primary customers. Then Microsoft could have done it, right? That's the other question. Yeah, so Microsoft didn't do it. And my guess is that... NVIDIA doesn't want Microsoft to do it, and so they would limit the capacity because from NVIDIA's perspective, both they don't want to necessarily launch their own cloud provider because it's competing with their customers, but also they don't want only one customer or only a few customers. It's really bad for NVIDIA if you have customer concentration, and Microsoft and Google and Amazon, like Oracle, to buy up your entire supply, and then you have four or five customers or so who pretty much get to set prices. Monopsony. Yeah, monopsony. And so the optimal thing for you is a diverse set of customers who all are willing to pay at whatever price, because if you don't, somebody else will. And so it's really optimal for NVIDIA to have lots of other customers who are all competing against each other. Great. Just wanted to establish that. It's unintuitive for people who have never thought about it, and you think about it all day long. Yeah.

Swyx: The last thing I'll call out from the talk, which is kind of cool, and then I promise we'll get to SF Compute, is why will DigitalOcean and Together lose money on their clusters? Why will DigitalOcean and Together lose money on their clusters?

Evan [00:16:33]: I'm going to start by clarifying that all of these businesses are excellent and fantastic. That Together and DigitalOcean and Lambda, I think, are wonderful businesses who build excellent products. But my general intuition is that if you try to couple the software and the hardware together, you're going to lose money. That if you go out and you buy a long-term contract from someone and then you layer on services, or you buy the hardware yourself and you spin it up and you get a bunch of debt, you're going to run into the same problem that everybody else did, the same problem we did, same problem the hyperscalers did. And that's exactly what the hyperscalers are doing, which is you cannot add software and make high margins like a cloud provider can. You can pitch that into investors and it will totally make sense, and it's like the correct play in CPUs, but there isn't software you could make to make this occur. If you're spending a billion dollars on hardware, you need to make a billion dollars of software. There isn't a billion dollars of software that you can realistically make, and if you do, you're going to look like SAP. And that's not a knock on SAP. SAP makes a f**k ton of money, right? Right. Right. Right. Right. There aren't that many pieces of software that you could make, that you can realistically sell, like a billion dollars of software, and you're probably not going to do it to price-sensitive customers who are spending their entire budget already on compute. They don't have any more money to give you. It's a very hard proposition to do. And so many parties have been trying to do this, like, buy their own compute, because that's what a traditional cloud does. It doesn't really work for them. You know that meme where there's, like, the Grim Reaper? And he's, like, knocking on the door, and then he keeps knocking on the next door? We have just seen door after door after door of the Grim Reeker comes by, and the economic realities of the compute market come knocking. And so the thing we encourage folks to do is if you are thinking about buying a big GPU cluster and you are going to layer on software on top, don't. There are so many dead bodies in the wake there. We would recommend not doing that. And we, as SF Compute, our entire business is structured to help you not do that. It's helped disintegrate these. The GPU clouds are fantastic real estate businesses. If you treat them like real estate businesses, you will make a lot of money. The cloud services you can make on that, all the software you want to make on that, you can do that fantastically. If you don't own the underlying hardware, if you mix these businesses together, you get shot in the head. But if you combine, if you split them, and that's what the market does, it helps you split them, it allows you to buy, like, layer on services, but just buy from the market, you can make lots of money. So companies like Modal, who don't own the underlying compute, like they don't own it, lots of money, fantastic product. And then companies like Corbeave, who are functionally like really, really good real estate businesses, lots of money, fantastic product. But if you combine them, you die. That's the economic reality of compute. I think it also splits into trading versus inference, which are different kinds of workloads. Yeah. And then, yeah, one comment about the price sensitivity thing before we leave this. This topic, I want to credit Martin Casado for coining or naming this thing, which is like, you know, you said, you said this thing about like, you don't have room for a 10% margin on GPUs for software. Yep. And Martin actually played it out further. It's his first one I ever saw doing this at large enough runs. So let's say GPT-4 and O1 both had a total trading cost of like a $500 billion is the rough estimate. When you get the $5 billion runs, when you get the $50 billion runs, it is actually makes sense to build your own. You're going to have to get into chips, like for OpenEI to get into chip design, which is so funny. I would make an ASIC for this run. Yeah, maybe. I think a caveat of that that is not super well thought about is that only works if you're really confident. It only works if you really know which chip you're going to do. If you don't, then it's a little harder. So it makes in my head, it makes more sense for inference where you've already established it. But for training there's so much like experimentation. Any generality, yeah. Yeah. The generality is much more useful. Yeah. In some sense, you know, Google's like six generations into the CPUs. Yeah. Yeah. Okay, cool. Maybe we should go into SF Compute now. Sure. Yeah.

Alessio [00:20:37]: Yeah. So you kind of talked about the different providers. Why did you decide to go with this approach and maybe talk a bit about how the market dynamics have evolved since you started a company?

Evan [00:20:47]: So originally we were not doing this at all. We were definitely like forced into this to some extent. And SF Compute started because we wanted to go train models for music and audio in general. We were going to do a sort of generic audio model at some points, and then we were going to do a music model at some points. It was an early company. We didn't really spec down on a particular thing. But yeah, we were going to do a music model and audio model. First thing that you do when you start any AI lab is you go out and you buy a big cluster. The thing we had seen everybody else do was they went out and they raised a really big round and then they would get stuck. Because if you raise the amount of money that you need to train a model initially, like, you know, the $50 million pre-seed, pre-revenue, your valuation is so high or you get diluted so much that you can't raise the next round. And that's a very big ask to make. And also, I don't know, I felt like we just felt like we couldn't do it. We probably could have in retrospect, but I think one, we didn't really feel like we could do it. Two, it felt like if we did, we would have been stuck later on. We didn't want to raise the big round. And so instead, we thought, surely by now, we would be able to just go out. To any provider and buy like a traditional CPU cloud would sell offer you and just buy like on demand or buy like a month or so on. And this worked for like small incremental things. And I think this is where we were basing it off. We just like assumed we could go to like Lambda or something and like buy thousands of at the time A100s. And this just like was not at all the case. So we started doing all the sales calls with people and we said, OK, well, can we just get like month to month? Can we get like one month of compute or so on? Everyone told us at the time, no. You need to have a year long contract or longer or you're out of luck. Sorry. And at the time, we were just like pissed off. Like, why won't nobody sell us a month at a time? Nowadays, we totally understand why, because it's the same economic reason. Because if you if they had sold us the month to month or so on and we canceled or so on, they would have massive risk on that. And so the optimal thing to do was to only to just completely abandon the section of the market. We didn't like that. So our plan was we were going to buy a year long contract anyway. We would use a month. And then we would. At least the other 11 months. And we were locked in for a year, but we only had to pay on every individual month. And so we did this. But then immediately we said, oh, s**t, now we have a cloud provider, not a like training models company, not an AI lab, because every 30 days we owed about five hundred thousand dollars or so and we had about five hundred thousand dollars in the bank. So that meant that every single month, if we did not sell out our cluster, we would just go bankrupt. So that's what we did for the first year of the company. And when you're in that position. You try to think how in the world you get out of that position, what that transition to is, OK, well, we tend to be pretty good at like selling this cluster every month because we haven't died yet. And so what we should do is we should go basically be like this broker for other people and we will be more like a GPU real estate or like a GPU realtor. And so we started doing that for a while where we would go to other people who had who was trying to sell like a year long contract with somebody and we'd go to another person who like maybe this person wanted six months and somebody else on six months or something and we'd like combine all these people. Together to make the deal happen and we'd organize these like one off bespoke deals that looked like basically it ended up with us taking a bunch of customers, us signing with a vendor, taking some cut and then us operating the cluster for people typically with bare metal. And so we were doing this, but this was definitely like a oh, s**t, oh, s**t, oh, s**t. How do we get out of our current situation and less of a like a strategic plan of any sort? But while we were doing this, since like the beginning of the company, we had been thinking about how to buy GPU clusters, how to sell them effectively, because we'd seen every part of it. And what we ended up with was like a book of everybody who's trying to buy and everyone is trying to sell because we were these like GPU brokers. And so that turned into what is today SF Compute, which is a compute market, which we think we are the functionally the most liquid GPU market of any capacity. Honestly, I think we're the only thing that actually is like a real market that there's like bids and asks and there's like a like a trading engine that combines everything. And so. I think we're the only place where you can do things that a market should be able to do. Like you can go on SF Compute today and you get thousands of H100s for an hour if you want. And that's because there is a price for thousands of GPUs for an hour. That is like not a thing you can reasonably do on kind of any other cloud provider because nobody should realistically sell you thousands of GPUs for an hour. They should sell it to you for a year or so on. But one of the nice things about a market is that you can buy the year on SF Compute. But then if you need to sell. Back, you can sell back as well. And that opens up all these little pockets of liquidity where somebody who's just trying to buy for a little bit of time, some burst capacity. So people don't normally buy for an hour. That's not like actually a realistic thing, but it's like the range somebody who wants, who is like us, who needed to buy for a month can actually buy for a month. They can like place the order and there is actually a price for that. And it typically comes from somebody else who's selling back. Somebody who bought a longer term contract and is like they bought for some period of time, their code doesn't work, and now they need to like sell off a little bit.

Alessio [00:25:49]: What are the utilization rates at which a market? What are the utilization rates at which a market? Like this works, what do you see the usual GPU utilization rate and like at what point does the market get saturated?

Evan [00:26:00]: Assuming there are not like hardware problems or software problems, the utilization rate is like near 100 percent because the price dips until the utilization is 100 percent. So the price actually has to dip quite a lot in order for the utilization not to be. That's not always the case because you just have logistical problems like you get a cluster and parts of the InfiniBand fabric are broken. And there's like some issue with some switch somewhere and so you have to take some portion of the cluster offline or, you know, stuff like this, like there's just underlying physical realities of the clusters, but nominally we have better utilization than basically anybody because, but that's on utilization of the cluster, like that doesn't necessarily translate into, I mean, I actually do think we have much better overall money made for our underlying vendors than kind of anybody else. We work with the other GPU clouds and the basic pitch to the other GPU clouds is one. So we can sell your broker so we can we can find you the long term contracts that are at the prices that you want, but meanwhile, your cluster is idle and for that we can increase your utilization and get you more money because we can sell that idle cluster for you and then the moment we find the longer, the bigger customer and they come on, you can kick off those people and then go to the other ones. You get kind of the mix of like sell your cluster at whatever price you can get on the market and then sell your cluster at the big price that you want to do for long term contract, which is your ideal business model. And then the benefit of the whole thing being on the market. Is you can pitch your customer that they can cancel their long term contract, which is not a thing that you can reasonably do if you are just the GPU cloud, if you're just the GPU cloud, you can never cancel your contract, because that introduces so much risk that you would otherwise, like not get your cheap cost of capital or whatever. But if you're selling it through the market, or you're selling it with us, then you can say, hey, look, you can cancel for a fee. And that fee is the difference between the price of the market and then the price that they paid at, which means that they canceled and you have the ability to offer that flexibility. But you don't. You don't have to take the risk of it. The money's already there and like you got paid, but it's just being sold to somebody else. One of our top pieces from last year was talking about the H100 glut from all the long term contracts that were not being fully utilized and being put under the market. You have on here dollar a dollar per hour contracts as well as it goes up to two. Actually, I think you were involved. You were obliquely quoted in that article. I think you remember. I remember because this was hidden. Well, we hid your name, but then you were like, yeah, it's us. Yeah. Could you talk about the supply and demand of H100s? Was that just a normal cycle? Was that like a super cycle because of all the VC funding that went in in 2003? What was that like? GPU prices have come down. Yeah, GPU prices have come down. And there's some part that has normal depreciation cycle. Some part of that is just there were a lot of startups that bought GPUs and never used them. And now they're lending it out and therefore you exist. There's a lot of like various theories as to why. This happened. I dislike all of them because they're all kind of like they're often said with really high confidence. And I think just the market's much more complicated than that. Of course. And so everything I'm going to say is like very hedged. But there was a series of like places where a bunch of the orders were placed and people were pitching to their customers and their investors and just the broader market that they would arrive on time. And that is not how the world works. And because there was such a really quick build out of things, you would end up with bottlenecks in the supply chain somewhere that has nothing to do with necessarily the chip. It's like the InfiniBand cables or the NICs or like whatever. Or you need a bunch of like generators or you don't have data center space or like there's always some bottleneck somewhere else. And so a lot of the clusters didn't come online within the period of time. But then all the bottlenecks got sorted out and then they all came online all at the same time. So I think you saw a short. There was a shortage because supply chain hard. And then you saw a increase or like a glut because supply chain eventually figure itself out. And specifically people overordered in order to get the allocation that they wanted. Then they got the allocations and then they went under. Yeah, whatever. Right. There was just a lot of shenanigans. A caveat of this is every time you see somebody like overordered, there is this assumption that the problem was like the demand went down. I don't think that's the case at all. And so I want to clarify that. It definitely seems like a shortage. Like there's more demand for GPUs than there ever was. It's just that there was also more supply. So at the moment, I think there is still functionally a glut. But the difference that I think is happening is mostly the test time inference stuff that you just need way more chips for that than you did before. And so whenever you make a statement about the current market, people sort of take your words and then they assume that you're making a statement about the future market. And so if you say there's a glut now, people will continue to think there's a glut. But I think what is happening at the moment. My general prediction is that like by the winter, we will be back towards shortage. But then also, this very much depends on the rollout of future chips. And that comes with its own. I think I'm trying to give you like a good here's Evan's forecast. Okay. But I don't know if my forecast is right. You don't have to. Nobody is going to hold you to it. But like I think people want to know what's true and what's not. And there's a lot of vague speculations from people who are not that close to the market actually. And you are. I think I'm a closer. Close to the market, but also a vague speculator. Like I think there are a lot of really highly confident speculators and I am indeed a vague speculator. I think I have more information than a lot of other people. And this makes me more vague of a spectator because I feel less certain or less confident than I think a lot of other people do. The thing I do feel reasonably confident about saying is that the test time inference is probably going to quite significantly expand the amount of compute that was used for inference. So a caveat. This is like pretty much all the inference demand is in a few companies. A good example is like lots of bio and pharma was using H100s training sort of the bio models of sorts. And they would come along and they would buy, you know, thousands of H100s for training and then just like not a lot of stuff for inference. Not in any, not relative to like an opening iron anthropic or something because they like don't have a consumer product. Their inference event, if they can do it right. There's really like only one inference event that matters. And obviously I think they're going to run into it. And Batch and they're not going to literally just run one inference event. But like the one that produces the drug is the important one. Right. And I'm dumb and I don't know anything about biology, so I could be completely wrong here. But my understanding is that's kind of the gist. I can check that for you. You can check that for me. Check that for me. But my understanding is like the one that produces the sequence that is the drug that, you know, cures cancer or whatever. That's the important deal. But like a lot of models look like this where they're sort of more enterprising use cases or they're so prior to something that looks like test time inference. You got lots and lots of demand for training and then pretty much entirely fell off for inference. And I think like we looked at like Open Router, for example, the entirety of Open Router that was not anthropic or like Gemini or OpenAI or something. It was like 10 H100 nodes or something like that. It's just like not that much. It's like not that many GPUs actually to service that entire demand. But that's like a really sizable portion of the sort of open source market. But the actual amount of compute needed for it was not that much. But if you imagine like what an OpenAI needs for like GPT-4, it's like tremendously big. But that's because it's a consumer product that has almost all the inference demand. Yeah, that's a message we've had. Roughly open source AI compared to closed AI is like 5%. Yeah, it's like super small. Super small. It's super small. Super small. But test time inference changes that quite significantly. So I will... I will expect that to increase our overall demand. But my question on whether or not that actually affects your compute price is entirely based on how quickly do we roll out the next chips. The way that you burst is different for test time.

Alessio [00:34:01]: Any thoughts on the third part of the market, which is the more peer-to-peer distributed, some are like crypto-enabled, like Hyperbolic, Prime Intellect, and all of that. Where do those fit? Like, do you see a lot of people will want to participate in a peer-to-peer market? Or just because of the capital requirements at the end of the day, it doesn't really matter?

Evan [00:34:20]: I'm like wildly skeptical of these, to be frankly. The dream is like steady at home, right? I got this $15.90. Nobody has $15.90. $14.90 sitting at home. I can rent it out. Yeah. Like, I just don't really think this is going to ever be more efficient than a fully interconnected cluster with InfiniBand or, you know, whatever the sort of next spec might be. Like, I could be completely wrong. But speaking of... I mean, like, SpeedoLite is really hard to beat. And regardless of whatever you're using, you just like can't get around that physical limitation. And so you could like imagine a decentralized market that still has a lot of places where there's like co-location. But then you would get something that looks like SF Compute. And so that's what we do. That's why we take our general take is like on SF Compute, you're not buying from like random people. You're buying from the other GPU clouds, functionally. You're buying from data centers that are the same genre of people that you would work with already. And you can specify, oh, I want all these nodes to be co-located. And I don't think you're really going to get around that. And I think I buy crypto for the purposes of like transferring money. Like the financial system is like quite painful and so on. I can understand the uses of it to sort of incentivize an initial market or try to get around the cold start problem. We've been able to get around the cold start problem just fine. So it didn't actually need that at all. What I do think is totally possible is you could launch a token and then you could like subsidize the crypto. You could compute prices for a bit, but like maybe that will help you. I think that's what Nuus is doing. Yeah, I think there's lots of people who are trying to do things like this, but at some point that runs out. So I would, I think generally agree. I think the only thread in that model is very fine grained mixture of experts that can be like algorithms can shift to adapt to hardware realities. And the hardware reality is like, okay, it's annoying to do large co-located clusters. Then we'll just redesign attention or whatever in our architecture to distribute it more. There was a little bit buzz of block attention last year that Strong Compute made a big push on. But I think like, you know, in a world where we have 200 experts in MOE model, it starts to be a little bit better. Like, I don't disagree with this. I can imagine the world in which you have like, in which you've redesigned it to be more parallelizable, like across space.

Evan [00:36:43]: But assuming without that, your hardware limitation is your speed of light limitation. And that's a very hard one to get around.

Alessio [00:36:50]: Any customers or like stories that you want to shout out of like maybe things that wouldn't have been economically viable like others? I know there's some sensitivity on that.

Evan [00:37:00]: My favorites are grad students, are folks who are trying to do things that would normally otherwise require the scale of a big lab. And the grad students are like the worst pilots. They're like the worst possible customer for the traditional GPU clouds because they will immediately turn if you sell them a thing because they're going to graduate and they're not going to go anywhere. They're not going to like, that project isn't continuing to spend lots of money. Like sometimes it does, but not if you're like working with the university or you're working with the lab of some sort. But a lot of times it's just like the ability for us to offer like big burst capacity, I think is lovely and wonderful. And it's like one of my favorite things to do because all those folks look like we did. And I have a special place in my heart for that. I have a special place in my heart for young hackers and young grad students and researchers who are trying to do the same genre of thing that we are doing. For the same reason, I have a special place in my heart for like the startups, the people who are just actively trying to compete on the same scale, but can't afford it time-wise, but can afford it spike-wise. Yeah, I liked your example of like, I have a grant of 100K and it's expiring. I got to spend it on that. That's really beautiful. Yeah. Interesting. Has there been interesting work coming out of that? Anything you want to mention? Yeah. So from like a startup perspective, like Standard Intelligence and Find, P-H-I-N-D. We've had them on the pod.

Swyx [00:38:23]: Yeah. Yeah.

Evan [00:38:23]: That was great. And then from grad students' perspective, we worked a lot with like the Schmidt Futures grantees of various sorts. My fear is if I talk about their research, I will be completely wrong to a sort of almost insulting degree because I am very dumb. But yeah. I think one thing that's maybe also relevant startups and GPUs-wise. Yeah. Is there was a brief moment where it kind of made sense that VCs provided GPU clusters. And obviously you worked at AI Grants, which set up Andromeda, which is supposedly a $100 million cluster. Yeah. I can explain why that's the case or why anybody would think that would be smart. Because I remember before any of that happened, we were asking for it to happen. Yeah. And the general reason is credit risk. Again, it's a bank. Yeah. I have lower risk than you due to credit transformation. I take your risk onto my balance sheet. Correct. Exactly. If you wanted to go for a while, if you wanted to go set up a GPU cluster, you had to be the one that actually bought the hardware and racked it and stacked it, like co-located it somewhere with someone. Functionally, it was like on your balance sheet, which means you had to get a loan. And you cannot get a loan for like $50 million as a startup. Like not really. You can get like venture debt and stuff, but like it's like very, very difficult to get a loan of any serious price for that. But it's like not that difficult to get a loan for $50 million. If you already have a fund or you already have like a million dollars under your assets somewhere or like you personally can like do a personal guarantee for it or something like this. If you have a lot of money, it is way easier for you to get a loan than if you don't have a lot of money. And so the hack of a VC or some capital partner offering equity for compute is always some arbitrage on the credit risk. That's amazing. Yeah. That's a hack. You should do that. I don't think people should do it right now. I think the market has like, I think it made sense at the time and it was helpful and useful for the people who did it at the time. But I think it was a one-time arbitrage because now there are lots of other sources that can do it. And also I think like it made sense when no one else was doing it and you were the only person who was doing it. But now it's like it's an arbitrage that gets competed down. Sure. So it's like super effective. I wouldn't totally recommend it. Like it's great that Andromeda did it. But the marginal increase of somebody else doing it is like not super helpful. I don't think that many people have followed in their footsteps. I think maybe Andreessen did it. Yeah. That's it. I think just because pretty much all the value like flows through Andromeda. What? That cannot be true. How many companies are in the air, Grant? Like 50? My understanding of Andromeda is it works with all the NFTG companies or like several of the NFTG companies. But I might be wrong about that. Again, you know, something something. Nat, don't kill me. I could be completely wrong. But the but you know, I think Andromeda was like an excellent idea to do at the right time in which it occurred. Perfect. His timing is impeccable. Timing. Yeah. Nat and Daniel are like, I mean, there's lots of people who are like... Sears? Yeah. Sears. Like S-E-E-R. Oh, Sears. Like Sears of the Valley. Yeah. They for years and years before any of the like ChatGPT moment or anything, they had fully understood what was going to happen. Like way, way before. Like. AI Grant is like, like five years old, six years old or something like that. Seven years old. When I, when it like first launched or something. Depends where you start. The nonprofit version. Yeah. The nonprofit version was like, like happening for a while, I think. It's going on for quite a bit of time. And then like Nat and Daniel are like the early investors in a lot of the sort of early AI labs of various sorts. They've been doing this for a bit.

Alessio [00:41:58]: I was looking at your pricing yesterday. We're kind of talking about it before. And there's this weird thing where one week is more expensive of both one day and one month. Yeah. What are like some of the market pricing dynamics? What are things that like this to somebody that is not in the business? This looks really weird. But I'm curious, like if you have an explanation for it, if that looks normal to you. Yeah.

Evan [00:42:18]: So the simple answer is preemptible pricing is cheaper than non-preemptible pricing. And the same economic principle is the reason why that's the case right now. That's not entirely true on SF Compute. SF Compute doesn't really have the concept of preemptible. Instead, what it has is very short reservations. So, you know, you go to a traditional cloud provider and you can say, hey, I want to reserve contract for a year. We will let you do a reserve contract for one hour, which is the part of SFC. But what you can do is you can just buy every single hour continuously. And you're reserving just for that hour. And then the next hour you reserve just for that next hour. And this is obviously like a built in. This is like an automation that you can do. But what you're seeing when you see the cheap price is you're seeing somebody who's buying the next hour, but maybe not necessarily buying an hour after that. So if the price goes up. Up too much. They might not get that next hour. And the underlying part of this of where that's coming from the market is you can imagine like day old milk or like milk that's about to be old. It might drop its price until it's expired because nobody wants to buy the milk that's in the past. Or maybe you can't legally sell it. Compute is the same way. No, you can't sell a block of compute that is not that is in the past. And so what you should do in the market and what people do do is they take. They take a block. A block of compute. And then they drop it and drop it and drop it and drop into a floor price right before it's about to expire. And they keep dropping it until it clears. And so anything that is idle drops until some point. So if you go and use on the website and you set that that chart to like a week from now, what you'll see is much more normal looking sort of curves. But if you say, oh, I want to start right now, that immediate instant, here's the compute that I want right now is the is functionally the preemptible price. It's where most people are getting the best compute or like the best compute prices from. The caveat of that is you can do really fun stuff on SFC if you want. So because it's not actually preemptible, it's it's reserved, but only reserved for an hour, which means that the optimal way to use as of compute is to just buy on the market price, but set a limit price that is much higher. So you can set a limit price for like four dollars and say, oh, if the market ever happens to spike up to four dollars, then don't buy. I don't want to buy that at that price for that price. I don't want to buy that at that price for that price for an hour. But otherwise, just buy at the cheapest price. And if you're comfortable with that of the volatility of it, you're actually going to get like really good prices, like close to a dollar an hour or so on, sometimes down to like 80 cents or whatever. You said four, though. Yeah. So that's the thing. You want to lower the limit. So four is your max price. Four is like where you basically want to like pull the plug and say don't do it because the actual average price is not or like the, you know, the preemptible price doesn't actually look like that. So what you're doing when you're saying four is always, always, always give me this compute. Like continue to buy every hour. Don't preempt me. Don't kick me off. And I want this compute and just buy at the preemptible price, but never kick me off. The only times in which you get kicked off is if there is a big price spike. And, you know, let's say one day out of the year, there's like a four dollar an hour price because of some weird fluke or something. If there are other periods of time, you're actually getting a much lower price than you. It makes sense. Your your average cost that you're actually paying is way better. And your trade off here is you don't literally know what price you're going to get. So it's volatile. But your actual average historically has been like everyone who's done this has gotten wildly better prices. And this is like one of the clever things you can do with the market. If you're willing to make those trade offs, you can get a lot of really good prices. You can also do other things like you can only buy at night, for example. So the price goes down at night. And so you can say, oh, I want to only buy, you know, if the price is lower than 90 cents. And so if you have some long running job, you can make it only run on 90 cents and then you recover back and so on. Yeah. So what you can kind of create as like a spot inst is what other the CPU world has. Yes. But you've created a system where you can kind of manufacture the exact profile that you want. Exactly. That is not just whatever the hyperscalers offer you, which is usually just one thing. Correct. SF Compute is like the power tool. The underlying primitives of like hourly compute is there. Correct. Yeah, it's pretty interesting. I've often asked OpenAI. So like, you know, all these guys. Cloud as well. They do batch APIs. So it's half off of whatever your thing is. Yeah. And the only contract is we'll return in 24 hours. Sure. Right. And I was like, 24 hours is good. But sometimes I want one hour. I want four hours. I want something. And so based off of SF Compute's system, you can actually kind of create that kind of guarantee. Totally. That would be like, you know, not 24, but within eight hours, within four hours, like the work half of a workday. Yes. I can return your results to you. And then I can return it to you. And if your latency requirements are like that low, actually it's fine. Yes. Correct. Yeah. You can carve out that. You can financially engineer that on SFC. Yeah. Yeah. I mean, I think to me that unlocks a lot of agent use cases that I want, which is like, yeah, I worked in a background, but I don't want you to take a day. Yeah. Correct. Take a couple hours or something. Yeah. This touches a lot of my like background because I used to be a derivatives trader. Yeah. And this is a forward market. Yeah. A futures forward market, whatever you call it. Not a future. Very explicitly not a future. Not yet a futures. Yes. But I don't know if you have any other points to talk about. So you recognize that you are a, you know, a marketplace and you've hired, I met Alex Epstein at your launch event and you're like, you're, you're building out the financialization of GPUs. Yeah. So part of that's legal. Mm-hmm. Totally. Part of that is like listing on an exchange. Yep. Maybe you're the exchange. I don't know how that works, but just like, talk to me about that. Like from the legal, the standardization, the like, where is this all headed? You know, is this like a full listed on the Chicago Mercantile Exchange or whatever? What we're trying to do is create an underlying spot market that gives you an index price that you can use. And then with that index price, you can create a cash settled future. And with a cash settled future, you can go back to the data centers and you can say, lock in your price now and de-risk your entire position, which lets you get cheaper cost of capital and so on. And that we think will improve the entire industry because the marginal cost of compute is the risk. It's risk as shown by that graph and basically every part of this conversation. It's risk that causes the price to be all sorts of funky. And we think a future is the correct solution to this. So that's the eventual goal. Right now you have to make the underlying spot market in order to make this occur. And then to make the spot market work, you actually have to solve a lot of technology problems. You really cannot make a spot market work if you don't run the clusters, if you don't have control over them, if you don't know how to audit them, because these are super computers, not soybeans. They have to work. In a way that like, it's just a lot simpler to deliver a soybean than it is to deliver it. I don't know. Talk to the soybean guys. Sure. You know? Yeah. But you have to have a delivery mechanism. Your delivery mechanism, like somebody somewhere has to actually get the compute at some point and it actually has to work. And it is really complicated. And so that is the other part of our business that we go and we build a bare metal infrastructure stack that goes. And then also we do auditing of all the clusters. You sort of de-risk the technical perspective and that allows you to eventually de-risk the financial perspective. And that is kind of the pitch of SF Compute. Yeah. I'll double click on the auditing on the clusters. This is something I've had conversations with Vitae on. He started Rika and I think he had a blog post which kind of shone the light a little bit on how unreliable some clusters are versus others. Correct. Yeah. And sometimes you kind of have to season them and age them a little bit to find the bad cards. You have to burn them in. Yeah. So what do you do to audit them? There's like a burn-in process, a suite of tests, and then active checking and passive checking. Burn-in process is where you typically run LINPACK. LINPACK is this thing that like a bunch of linear algebra equations that you're stress testing the GPUs. This is a proprietary thing that you wrote? No, no, no. LINPACK is like the most common form of burn-in. If you just type in burn-in, typically when people say burn-in, they literally just mean LINPACK. It's like an NVIDIA reference version of this. Again, NVIDIA could run this before they ship, but now the customers have to do it. It's annoying. You're not just checking for the GPU itself. You're checking like the whole component, all the hardware. And it's a lot of work. It's an integration test. It's an integration test. Yeah. So what you're doing when you're running LINPACK or burn-in in general is you're stress testing the GPUs for some period of time, 48 hours, for example, maybe seven days or so on. And you're just trying to kill all the dead GPUs or any components in the system that are broken. And we've had experiences where we ran LINPACK on a cluster and it rounds out, sort of comes offline when you run LINPACK. This is a pretty good sign that maybe there is a problem with this cluster. Yeah. So LINPACK is like the most common sort of standard test. But then beyond that, what you do is we have like a series of performance tests that replicate a much more realistic environment as well that we run just assuming if LINPACK works at all, then you run the next set of tests. And then while the GPUs are in operation, you're also going through and you're doing active tests and passive tests. Passive tests are things that are running in the background while somebody else is running, while like some other workload is running. And active tests are during like idle periods. You're running some sort of check that would otherwise sort of interrupt something. And then the active tests will take something offline, basically. Or a passive check might mark it to get taken offline later and so on. And then the thing that we are working on that we have working partially but not entirely is automated refunds, which is basically like, is the case that the hardware breaks so much. And there's only so much that we can do and it is the effect of pretty much the entire industry. So a pretty common thing that I think happens to kind of everybody in the space is a customer comes online, they experience your cluster, and your cluster has the same problem that like any cluster has, or it's I mean, a different problem every time, but they experience one of the problems of HPC. And then their experience is bad. And you have to like negotiate a refund or some other thing like this. It's always case by case. And like, yeah, a lot of people just eat the cost. Correct. So one of the nice things about a market that we can do as we get bigger and have been doing as we can bigger is we can immediately give you something else. And then also we can automatically refund you. And you're still gonna experience it like the hardware problems aren't going away until the underlying vendors fix things. But honestly, I don't think that's likely because you're always pushing the limits of HPC. This is the case of trying to build a supercomputer. that's one of the nice things that we can do is we can switch you out for somebody else somewhere, and then automatically refund you or prorate or whatever the correct move is. One of the things that you say in this conversation with me was like, you know, you know, a provider is good when they guarantee automatic refunds. Which doesn't happen. But yeah, that's, that's in our contact with all the underlying cloud providers. You built it in already. Yeah. So we have a quite strict SLA that we pass on to you. The reason why I'm like, hedging on this is because we have some amount of active checks, we have some amount of passive checks. There are always new genres of b******t, and the new genres of b******t might cause a customer to have bad experience. And the active or passive checks didn't catch it. And so then it's a manual process after that. Then we have like a literal thing in our website that you can just say, Hey, some hardware problem, please tell us. And then we will go and resolve it for you. How, I mean, cards don't change generation to generation. What is a new genre of b******t? If every component piece in the cluster has maybe like a one in a hundred chance of failing, or maybe a one in a thousand chance of failing, or maybe one in 10,000 chance of failing, You discover them. You discover them. So there's ones that like maybe nobody saw, maybe you didn't see, or maybe only matters for this one cluster with this motherboard in this particular data center or something. There's new interactions that otherwise don't happen. Most problems are really common and you can adapt to them. Like, like a GPU falls off a bus is like one of the most common things that can happen. So it's not SF Compute's job to go fix those things. No, it totally is to some extent. Totally is to some extent. So we, we operate the cluster. So unlike a reseller, which is what we were doing before. Yeah. In almost all cases, we have BMC access. So if on your laptop, there's like the button in the top right hand corner that you can hold down to like re-image the machine, there's a similar thing in like server X that you is like this other box that kind of plugs in and it basically lets you reset the machine from outside. And it's like remote, it's a remote hand sort of thing. So we ask for this and we get this from a lot of our vendors, which means we have quite a lot of ability to solve problems for customers in a way that you might not actually get from a reseller. Oftentimes we are the person who's debugging your cluster. For most customers that we work with, we have Slack channel. Our entire engineering team gets put in the Slack channel. If there was a problem at 2am, we are the ones who are debugging your problem at 2am. Not always the case because we don't physically run the hardware cluster or like the data center itself, but most problems are solvable through this. So that's the auditing side. The other side is I think of a standardization or whatever you call it. Beyond auditing. The other part of the work is kind of standardizing the commodity contracts. Yeah. So there's two ways that we do that. One is that you set like a this or better list. So you set like a spec list and you say, oh, you're going to get like a common variability is the amount of storage on the cluster. And so you'll say like, oh, you're going to get X or better. And there's some guarantee minimum and sometimes you might get more. And then we're working on a persistent storage layer that might sort of abstract a lot of this way, but mostly it's that. And then there's like a white list of motherboards and various things. Genres of things. But the other part is we run the clusters from bare metal up. And so we make a thing that's this like it's a UEFI shim. And if you're not familiar with what UEFI is, a UEFI is like the sort of firmware modern version of BIOS. Modern meaning it's been around for like forever. But you know, BIOS is like really old. It's like this whole IBM thing. And you can write code that exists at the UEFI layer. And again, when you hear UEFI, you should think BIOS. And it does the same sort of thing. It does the same thing as a Pixie boot, but in environments in which Pixie boot doesn't necessarily always work for us. So it basically sits at your BIOS, downloads an image, boots into an image that's like custom for the user. And then on top of that image, we can throw Kubernetes on it. We can throw VMs on it or whatever you want. And at some point, we'll probably like do more stuff with that. But that's functionally what we can do. The nice thing, though, is that because you control from that layer, you can easily image an entire cluster. You make it all the same. You can run your performance tests all automated. So much nicer. Right. Than what we used to do. Yeah. I mean, that is a very important work. I think like for me, as a trader, I need standard contracts. And so there basically needs to be the safe of a GPU. Yes. What we functionally do is we have a market under the hood that is focused on the buyer and the seller, and it's optimized for them. And then beyond that, for a trader, you can standardize around a certain segment of it. And you can trade on that contract. That's the goal that we're trying to get to. But you start by making something that works really well for buyers and really well for sellers. For those who are not familiar with derivatives markets, I can go ahead and say this because the point of being cash settled, which is something that you mentioned, which I think people might miss, is that you don't have to take physical delivery of the GPUs. Right. And so it's a pure financial instrument, which actually does mean that almost for certain, there will be more volume on SFC's marketplace than actually change hands in GPU terms. To be super clear. We are not a derivatives market. This doesn't happen yet. Yeah. We are not a derivatives market. We may in the future work to create a cash settled future. We are not currently a derivatives market. We are an online spot market. Yeah. I just think like people, normies get really upset when they're like, then they learn things like, oh, like derivatives on mortgages are like 12 times larger than the mortgages themselves. Yes. Yeah. No, I, um, a common thing that people have talked to us about, or like a fear or concern, I think people have is like, oh, you're financializing. Compute. And this will like cause various problems of sorts. Subprime crisis. Yeah. Um, and I think, so first I think part of this is just because crypto caused a lot of people to think about finance in the like very de-gen way for the right word. Um, and then before that, um, the sort of 2008, 2009 crisis, um, caused people to think about it also in sort of like a de-genny way. And this is very much not our mindset. The reason to create a derivative at all, or the reason to create a future at all is a risk reduction thing. Um, that's what futures do. The reason why a farmer wants a future is because they have no idea what the weather is going to do. And they don't want to be on the hook, um, for like they have small margins and if things go wrong, they really, really want to have a locked in price. Um, so that way they can like continue to exist for the next year. Data centers are the same way. The way that they solve it today is you go out and you sign long-term contracts with your customers. What that does for you is it means your business is de-risked. Um, you don't have to worry about the revenue for the next year. But that means that the customer now has to worry about what they're going to do with all this compute. And if they don't optimally use it and so on and so on, and that just pushes everything onto the startups who then in turn, push it on to VCs. And so what the VCs are forced to do in order to invest in AI is they have to go and write big, giant valuations, like pre-revenue at ridiculous multiples. So what you've done by not having a future is you've inflated the venture capital market, and that is a bubble. That's totally going to pop. At some point, like a lot of the companies are not going to work and the valuations are not going to work. And what's going to happen is a lot of these funds aren't going to return back to their LPs. And that affects the broader market. The way that you solve that, the way that you add security to the entire economic system in this chain is you add a future. That's how we did it in lots of other markets. It doesn't have to be this like, oh my gosh, we're going to like speculate on GB prices and like whatever. No. The whole point of SF Compute is to reduce the risk. Reduce the technical risk. Reduce the financial risk. Let's just chill out a little bit. There's so much other random s**t. It's supercomputers. There's AGI, whatever. No. Let's just like chill the f**k out. I mean, also like Dan is going, raising like at a $30 billion valuation for Ilya, you know, like. Yeah. If everybody else in all of AI is like pushing the hype and the extreme, everything we've been trying to do is go the other way. Like whole website is just like a f*****g single page. Um, like the entire brand is just like, what if we were? We're like calm in nature. And then everything that we do as the product is just calm. What if we, what if we were the opposite force of the big hypey extreme thing? What if we just like chilled things out? And part of that was because we, in the beginning were at the whim of the hypey nature. Like our entire origin is every 30 days and we don't sell out, we're going to go crazy and just completely bankrupt the company. And so everybody in the company is just like, what if we just chilled out? What if, what if we stopped? Yeah. This is the first time I've ever heard derivatives are the way to chill out. Yes. No. Futures are the way to chill out. Futures are the way to chill out the entire industry. And um, we wouldn't be doing this if it wasn't that case. I like that.

Alessio [01:01:20]: You have a very nice brand with a, you know, clear sky. We have to ask about the website. Yeah. What was the inspiration behind it? Why did you not go the black neon, more cool thing and go the more nature?

Evan [01:01:33]: I don't think I really am a black neon sort of person. I say. I'm wearing black pants and I thought I was wearing a black shirt, but apparently I'm not. So, um, the actual, the actual thing was a lot of companies do this thing where they, their website, you go to there and it's like a magical experience and like everything is extreme and amazing and credible and then you go to the product and it's like some SaaS app or something. Um, and it's like not actually that exciting. And that expectation of being like really, really good. And then the fall off the drop of not being really, really good. Yeah. It's something that from a product perspective, I never want it to happen, especially because in the beginning, like our product was really bad. And so I don't want to set the expectation that it's going to be like an amazing experience. I want to set the expectation that it's going to be like a good price for short term bursts. And so what we did instead is we set the thing to be really low. You set your expectations really low and then you get a supercomputer for like millions of dollars cheaper than you would have otherwise gotten your supercomputer. And so you have the opposite expectation. You have like really low expectations that are like mild or met higher. Yeah. And I think that's like the correct way to do things. But also I think we were just like so sick of hype and excitement and, um, I just like really want to like not do that. It's weird. Like by, by being anti-hype, you have created hype. Like I would say like the, the, the, the, the vibes are immaculate, you know, like you just, you go to like at the, the bay, the Cal trade, you just put up like a banner. This just, just says SF compute. True. That banner was created about five minutes before we had to actually put something up like before the deadline was there. Yeah. So it opens up Microsoft word and you did some serif. What is the font? Exactly. I don't know. Yeah. That was, um, indeed. Um, the, yeah, I think every time we tried to do the, the only caveat to this, the only caveat that we ever violate this rule with, uh, is when we're pitching San Francisco, I think San Francisco is amazing. So sometimes you will see these like advertisements from the city. Yeah. The city. Um, so if there's a part of San Francisco computes brand, which are these beautiful like images of SF. Yeah. And I am the complete opposite about this. I am such a San Francisco promoter that any time we talk about the city, I want to show the city from the like eyes that we have, which is mostly just gorgeous, beautiful area with nature. Like a lot of people think about San Francisco and they think about like tech industry or they think, yeah, or the tenderloin or something like grind culture or something. And no, like I think about like the fog, um, and just like the gorgeous view over the bridge and just the fact that there is this like massive amount of optimism in the city. And it's the backdrop of that optimism is the most beautiful countryside in all of the world. And so anytime we talk about SF, you will see like, or like we have a billboard somewhere that's just like local friendly supercomputer or whatever. And then the backdrop is like beautiful and amazing. And that's because to some extent we're pitching the city and the people here. And I think that people in the city here are actually really amazing. And so you get to earn the brand. Um, cause the expectations are met. Whereas I think on our own product, I'm typically want it to be better. And so I set the brand a lot lower. Um, and then the expectations are higher. Um, and you still meet the expectations, but you, you set them a little lower. I know. Are you the designer? I know you have an artistic side. Um, so, uh, I was in the beginning, so, uh, I'm like a figurative artist, so I draw people. Um, but we've worked with a design firm. Airfoil was really excellent with us. And then, um, nowadays though, John Pham, um, had a design from Vercel. Yeah. John is unbelievably amazing. Yeah. Um, I think the amount of care and craft and attention to detail that he puts into just everything is so cool. Yeah. Um, like if you go on our buy page right now, you go to sfcompute.com slash buy. There is an Easter egg there that will, you should find. I almost don't want to spoil it, but you should go find that Easter egg. If you just like hover the mouse around the thing in the top right hand corner, um, you will, you'll find it. Yeah, tweet at Evan if you find it. And then the, um, other person is, um, Ethan Anderson, our COO, who, um, has this really, really cool design. He has a RISD design background. And so, uh, his, like, uh, he used to be sort of industrial designery. I'm probably going to say that wrong. He's probably not an actual industrial designer, but design background, same. So I think between me and John and, uh, Ethan, um, I think we. The source of the vibes. The source of the vibes. I had to ask. Yeah. Okay. So we're going to zoom out a little bit. One of the last things I wanted to ask you was actually like, I remember, I think the first time that you was in like kind of cello and you were working on your email. Oh yeah. Yeah. Yeah. And I have a favorite pet topic of mine. We were here with Dharmesh yesterday talking about someone, build an agent that reads my emails. Yeah. And you did. And I think I actually paid for the first one. You were, you were so excited in the early GPT three days. I was like, you were like, uh, I'm building the most expensive startup ever. Yeah. It's so expensive. Anyway. So the point being what I'm trying to get to is you are a very smart guy. You built email. You, you didn't like it. You pivoted away. I've seen other, like every year there's someone who is like, I will crack email. Yeah. And I'll, and then, and then they give up. Yeah. What is so hard about email? I didn't pivot away because the product or the idea was bad. I pivoted away because I was super burnt out. I did a startup for like four years. And the first thing didn't work out. Is this room service? Yeah, this is room service. So my startup before this originally started as Quirk, which was like a mental health app, but then Quirk had the same problems that basically every mental health app has, which is like your retention goes to zero if you work at in any capacity. And so switched and then said, okay, well I will do something that's closer to my actual background was like a distributed systems company called Room Service. Room Service went for about nine months and then sort of had the same problem that I think every other competitor Room Service has, which is mostly people building a house. And so then I went back to our investors at the time, which was Nat and Daniel and specifically Daniel told me that I should go stare at the ocean. And you know, I will find something else to do and just throw s**t at the wall. And then I think, I think it was Gustav at YC. Maybe it was probably actually Dalton Caldwell. Dalton Caldwell, like just said, don't die. Like you can just keep doing things and don't die. And so I think I just got it in my head that you should just like keep trying things and not die. And I really, really, really did not want to die and didn't really know what to do. And so I just threw out like 40 products with the assumption that if you just keep trying things, you won't die. This is actually not the most ideal thing to do. You actually should totally just pick a thing and go with it. But my brain wasn't set on like, oh, I should do this particular thing. It was set on not die. And so I just kept going for a very long time for like four years. And by the end of it, I think I was just super burnt out. And I was going to do the email thing with one co-founder and then they quit. And then I was going to do an email thing with another co-founder. And then they fell in love and decided to go get married and you know all that. Okay. So it wasn't that email is intractable. I'm just trying to figure out like, look, is there something bad? Like, is this a graveyard of ideas, right? Everyone wants to do email and then nobody does because something. And I think it's just hard to make an email client. I think it's hard to make an email client. That is, it's a competitive space in which there are lots of things. I do think that the better version of that is something that looks closer to what Intercom is doing. And Intercom obviously existed beforehand. So you can think about like any product. Like, should you be doing it or should somebody else in the industry who already has the existing customer set do it? And I think Intercom has pretty much very successfully done like they already had the position to do it. Like, what do you actually need the AI to write your emails for? Like, most people don't need this. But what who does need this is like support use cases is pretty much there. And the people who are best able to execute on this is totally Intercom. So like props to Owen. I think that was like completely the correct move. Yeah. Closing thoughts. Call to action.

Alessio [01:09:07]: Yes. Oh, yeah, we are.

Evan [01:09:09]: We are hiring for two roles as of this recording. I don't know. Maybe this will change and we'll be hiring for different roles. So go to the website or whatever. But the first role is for traditional systems engineering. This is like low level systems or low level Linux systems. Yeah. So I'll rest most all of our code bases and rest. But we're not necessarily just looking for like rest engineers. We're specifically looking for like Linux people sort of pitches. You get to work on supercomputers. You get to work on one of the few places in supercomputers that I think has a pretty good business model and is like a like a working thing. And people generally seem to think that our vibe as of compute is very nice. The we have just an unbelievable. Excellent team. I think nowadays our CTO is Eric Park. He's the co-founder of Voltage Park, which is one of the other GPU clouds. And he is quite possibly the sweetest man I've ever met. He is extremely chill and also just extremely earnest and kind. And the rest of the team kind of feels that energy very strongly. And then the other role that we're hiring for is financial systems engineering, which I really should learn what it's not systems engineering, but we should really find a better name for this role. It's basically a fintech engineer. That it's we have the same problems as traditional fintech does. And that's like we have a ledger. We have recording requirements and all that stuff. This role is responsible for the not lose all the money. Cool. Like, we've got a whole bunch of money flowing through us. There is a bunch of stuff that you need to do in order to not lose all that money. And then the actual outcome of that work, besides not just losing all the money, which is very important, is that you end up with better prices for the vendors and better prices for the buyers. And this means that your grad student who is an engineer. Who is making the cancer cure or whatever and needs to be able to buy like 100K of compute to like scale up really big actually can do so. And that's I think the like this is part of the reason to work at SFC is that you're the things you do actually matter in a way that doesn't necessarily always at all the companies functionally. We run supercomputers like not soybeans or I don't know. It's a very cool place to work because your outcomes of what you do have real deal impact in a way that you don't always get when you're doing SaaS. Excellent pitch. I bet you've done that a lot, but it's nice to hear for the first time. I was going to say, like, you know, have you looked into Tiger Beetle, the dual entry accounting database? We have. That seems to be the thing if you want to make systems that don't lose money. Yes. Systems that don't lose money. There are lots of other things you have to do. Like you have to make things in a format that your accountants can read and then get audited and so on. It's not purely just the yeah, it's not purely just the tech. Cool. Awesome. Thank you so much. Of course.

We are happy to announce that there will be a dedicated MCP track at the 2025 AI Engineer World's Fair, taking place Jun 3rd to 5th in San Francisco, where the MCP core team and major contributors and builders will be meeting. Join us and apply to speak or sponsor!

When we first wrote Why MCP Won, we had no idea how quickly it was about to win.

In the past 4 weeks, OpenAI and now Google have now announced the MCP support, effectively confirming our prediction that MCP was the presumptive winner of the agent standard wars. MCP has now overtaken OpenAPI, the incumbent option and most direct alternative, in GitHub stars (3 months ahead of conservative trendline):

We have explored the state of MCP at AIE (now the first ever >100k views workshop):

And since then, we?ve added a 7th reason why MCP won - this team acts very quickly on feedback, with the 2025-03-26 spec update adding support for stateless/resumable/streamable HTTP transports, and comprehensive authz capabilities based on OAuth 2.1.

This bodes very well for the future of the community and project.

For protocol and history nerds, we also asked David and Justin to tell the origin story of MCP, which we leave to the reader to enjoy (you can also skim the transcripts, or, the changelogs of a certain favored IDE). It?s incredible the impact that individual engineers solving their own problems can have on an entire industry.

Full video episode

Like and subscribe on YouTube!

Show Links

* David

* Justin

* MCP

* Why MCP Won

Timestamps

* 00:00 Introduction and Guest Welcome

* 00:37 What is MCP?

* 02:00 The Origin Story of MCP

* 05:18 Development Challenges and Solutions

* 08:06 Technical Details and Inspirations

* 29:45 MCP vs Open API

* 32:48 Building MCP Servers

* 40:39 Exploring Model Independence in LLMs

* 41:36 Building Richer Systems with MCP

* 43:13 Understanding Agents in MCP

* 45:45 Nesting and Tool Confusion in MCP

* 49:11 Client Control and Tool Invocation

* 52:08 Authorization and Trust in MCP Servers

* 01:01:34 Future Roadmap and Stateless Servers

* 01:10:07 Open Source Governance and Community Involvement

* 01:18:12 Wishlist and Closing Remarks

Transcript

Alessio [00:00:02]: Hey, everyone. Welcome back to Latent Space. This is Alessio, partner and CTO at Decibel, and I'm joined by my co-host Swyx, founder of Small AI.

swyx [00:00:10]: Hey, morning. And today we have a remote recording, I guess, with David and Justin from Anthropic over in London. Welcome. Hey, good You guys have created a storm of hype because of MCP, and I'm really glad to have you on. Thanks for making the time. What is MCP? Let's start with a crisp what definition from the horse's mouth, and then we'll go into the origin story. But let's start off right off the bat. What is MCP?

Justin/David [00:00:43]: Yeah, sure. So Model Context Protocol, or MCP for short, is basically something we've designed to help AI applications extend themselves or integrate with an ecosystem of plugins, basically. The terminology is a bit different. We use this client-server terminology, and we can talk about why that is and where that came from. But at the end of the day, it really is that. It's like extending and enhancing the functionality of AI application.

swyx [00:01:05]: David, would you add anything?

Justin/David [00:01:07]: Yeah, I think that's actually a good description. I think there's like a lot of different ways for how people are trying to explain it. But at the core, I think what Justin said is like extending AI applications is really what this is about. And I think the interesting bit here that I want to highlight, it's AI applications and not models themselves that this is focused on. That's a common misconception that we can talk about a bit later. But yeah. Another version that we've used and gotten to like is like MCP is kind of like the USB-C port of AI applications and that it's meant to be this universal connector to a whole ecosystem of things.

swyx [00:01:44]: Yeah. Specifically, an interesting feature is, like you said, the client and server. And it's a sort of two-way, right? Like in the same way that said a USB-C is two-way, which could be super interesting. Yeah, let's go into a little bit of the origin story. There's many people who've tried to make statistics. There's many people who've tried to build open source. I think there's an overall, also, my sense is that Anthropic is going hard after developers in the way that other labs are not. And so I'm also curious if there was any external influence or was it just you two guys just in a room somewhere riffing?

Justin/David [00:02:18]: It is actually mostly like us two guys in a room riffing. So this is not part of a big strategy. You know, if you roll back time a little bit and go into like July 2024. I was like, started. I started at Anthropic like three months earlier or two months earlier. And I was mostly working on internal developer tooling, which is what I've been doing for like years and years before. And as part of that, I think there was an effort of like, how do I empower more like employees at Anthropic to use, you know, to integrate really deeply with the models we have? Because we've seen these, like, how good it is, how amazing it will become even in the future. And of course, you know, just dogfoot your own model as much as you can. And as part of that. From my development tooling background, I quickly got frustrated by the idea that, you know, on one hand side, I have Cloud Desktop, which is this amazing tool with artifacts, which I really enjoyed. But it was very limited to exactly that feature set. And it was there was no way to extend it. And on the other hand side, I like work in IDEs, which could greatly like act on like the file system and a bunch of other things. But then they don't have artifacts or something like that. And so what I constantly did was just copy. Things back and forth on between Cloud Desktop and the IDE, and that quickly got me, honestly, just very frustrated. And part of that frustration wasn't like, how do I go and fix this? What, what do we need? And back to like this development developer, like focus that I have, I really thought about like, well, I know how to build all these integrations, but what do I need to do to let these applications let me do this? And so it's very quickly that you see that this is clearly like an M times N problem. Like you have multiple like applications. And multiple integrations you want to build and like, what that is better there to fix this than using a protocol. And at the same time, I was actually working on an LSP related thing internally that didn't go anywhere. But you put these things together in someone's brain and let them wait for like a few weeks. And out of that comes like the idea of like, let's build some, some protocol. And so back to like this little room, like it was literally just me going to a room with Justin and go like, I think we should build something like this. Uh, this is a good idea. And Justin. Lucky for me, just really took an interest in the idea, um, and, and took it from there to like, to, to build something, together with me, that's really the inception story is like, it's us to, from then on, just going and building it over, over the course of like, like a month and a half of like building the protocol, building the first integration, like Justin did a lot of the, like the heavy lifting of the first integrations in cloud desktop. I did a lot of the first, um, proof of concept of how this can look like in an IDE. And if you, we could talk about like some of. All the tidbits you can find way before the inception of like before the official release, if you were looking at the right repositories at the right time, but there you go. That's like some of the, the rough story.

Alessio [00:05:12]: Uh, what was the timeline when, I know November 25th was like the official announcement date. When did you guys start working on it?

Justin/David [00:05:19]: Justin, when did we start working on that? I think it, I think it was around July. I think, yeah, I, as soon as David pitched this initial idea, I got excited pretty quickly and we started working on it, I think. I think almost immediately after that conversation and then, I don't know, it was a couple, maybe a few months of, uh, building the really unrewarding bits, if we're being honest, because for, for establishing something that's like this communication protocol has clients and servers and like SDKs everywhere, there's just like a lot of like laying the groundwork that you have to do. So it was a pretty, uh, that was a pretty slow couple of months. But then afterward, once you get some things talking over that wire, it really starts to get exciting and you can start building. All sorts of crazy things. And I think this really came to a head. And I don't remember exactly when it was, maybe like approximately a month before release, there was an internal hackathon where some folks really got excited about MCP and started building all sorts of crazy applications. I think the coolest one of which was like an MCP server that can control a 3d printer or something. And so like, suddenly people are feeling this power of like cloud connecting to the outside world in a really tangible way. And that, that really added some, uh, some juice to us and to the release.

Alessio [00:06:32]: Yeah. And we'll go into the technical details, but I just want to wrap up here. You mentioned you could have seen some things coming if you were looking in the right places. We always want to know what are the places to get alpha, how, how, how to find MCP early.

Justin/David [00:06:44]: I'm a big Zed user. I liked the Zed editor. The first MCP implementation on an IDE was in Zed. It was written by me and it was there like a month and a half before the official release. Just because we needed to do it in the open because it's an open source project. Um, and so it was, it was not, it was named slightly differently because we. We were not set on the name yet, but it was there.

swyx [00:07:05]: I'm happy to go a little bit. Anthropic also had some preview of a model with Zed, right? Some kind of fast editing, uh, model. Um, uh, I, I'm con I confess, you know, I'm a cursor windsurf user. Haven't tried Zed. Uh, what's, what's your, you know, unrelated or, you know, unsolicited two second pitch for, for Zed. That's a good question.

Justin/David [00:07:28]: I, it really depends what you value in editors. For me. I, I wouldn't even say I like, I love Zed more than others. I like them all like complimentary in, in a way or another, like I do use windsurf. I do use Zed. Um, but I think my, my main pitch for Zed is low latency, super smooth experience editor with a decent enough AI integration.

swyx [00:07:51]: I mean, and maybe, you know, I think that's, that's all it is for a lot of people. Uh, I think a lot of people obviously very tied to the VS code paradigm and the extensions that come along with it. Okay. So I wanted to go back a little bit. You know, on, on, on some of the things that you mentioned, Justin, uh, which was building MCP on paper, you know, obviously we only see the end result. It just seems inspired by LSP. And I, I think both of you have acknowledged that. So how much is there to build? And when you say build, is it a lot of code or a lot of design? Cause I felt like it's a lot of design, right? Like you're picking JSON RPC, like how much did you base off of LSP and, and, you know, what, what, what was the sort of hard, hard parts?

Justin/David [00:08:29]: Yeah, absolutely. I mean, uh, we, we definitely did take heavy inspiration from LSP. David had much more prior experience with it than I did working on developer tools. So, you know, I've mostly worked on products or, or sort of infrastructural things. LSP was new to me. But as a, as a, like, or from design principles, it really makes a ton of sense because it does solve this M times N problem that David referred to where, you know, in the world before LSP, you had all these different IDEs and editors, and then all these different languages that each wants to support or that their users want them to support. And then everyone's just building like one. And so, like, you use Vim and you might have really great support for, like, honestly, I don't know, C or something, and then, like, you switch over to JetBrains and you have the Java support, but then, like, you don't get to use the great JetBrains Java support in Vim and you don't get to use the great C support in JetBrains or something like that. So LSP largely, I think, solved this problem by creating this common language that they could all speak and that, you know, you can have some people focus on really robust language server implementations, and then the IDE developers can really focus on that side. And they both benefit. So that was, like, our key takeaway for MCP is, like, that same principle and that same problem in the space of AI applications and extensions to AI applications. But in terms of, like, concrete particulars, I mean, we did take JSON RPC and we took this idea of bidirectionality, but I think we quickly took it down a different route after that. I guess there is one other principle from LSP that we try to stick to today, which is, like, this focus on how features manifest. More than. The semantics of things, if that makes sense. David refers to it as being presentation focused, where, like, basically thinking and, like, offering different primitives, not because necessarily the semantics of them are very different, but because you want them to show up in the application differently. Like, that was a key sort of insight about how LSP was developed. And that's also something we try to apply to MCP. But like I said, then from there, like, yeah, we spent a lot of time, really a lot of time, and we could go into this more separately, like, thinking about each of the primitives that we want to offer in MCP. And why they should be different, like, why we want to have all these different concepts. That was a significant amount of work. That was the design work, as you allude to. But then also already out of the gate, we had three different languages that we wanted to at least support to some degree. That was TypeScript, Python, and then for the Z integration, it was Rust. So there was some SDK building work in those languages, a mixture of clients and servers to build out to try to create this, like, internal ecosystem that we could start playing with. And then, yeah, I guess just trying to make everything, like, robust over, like, I don't know, this whole, like, concept that we have for local MCP, where you, like, launch subprocesses and stuff and making that robust took some time as well. Yeah, maybe adding to that, I think the LSP inference goes even a little bit further. Like, we did take actually quite a look at criticisms on LSP, like, things that LSP didn't do right and things that people felt they would love to have different and really took that to heart to, like, see, you know, what are some of the things. that we wish, you know, we should do better. We took a, you know, like, a lengthy, like, look at, like, their very unique approach to JSON RPC, I may say, and then we decided that this is not what we do. And so there's, like, these differences, but it's clearly very, very inspired. Because I think when you're trying to build and focus, if you're trying to build something like MCP, you kind of want to pick the areas you want to innovate in, but you kind of want to be boring about the other parts in pattern matching LSP. So the problem allows you to be boring in a lot of the core pieces that you want to be boring in. Like, the choice of JSON RPC is very non-controversial to us because it's just, like, it doesn't matter at all, like, what the action, like, bites on the bar that you're speaking. It makes no difference to us. The innovation is on the primitives you choose and these type of things. And so there's way more focus on that that we wanted to do. So having some prior art is good there, basically.

swyx [00:12:26]: It does. I wanted to double click. I mean, there's so many things you can go into. Obviously, I am passionate about protocol design. I wanted to show you guys this. I mean, I think you guys know, but, you know, you already referred to the M times N problem. And I can just share my screen here about anyone working in developer tools has faced this exact issue where you see the God box, basically. Like, the fundamental problem and solution of all infrastructure engineering is you have things going to N things, and then you put the God box and they'll all be better, right? So here is one problem for Uber. One problem for... GraphQL, one problem for Temporal, where I used to work at, and this is from React. And I was just kind of curious, like, you know, did you solve N times N problems at Facebook? Like, it sounds like, David, you did that for a living, right? Like, this is just N times N for a living.

Justin/David [00:13:16]: David Pérez- Yeah, yeah. To some degree, for sure. I did. God, what a good example of this, but like, I did a bunch of this kind of work on like source control systems and these type of things. And so there were a bunch of these type of problems. And so you just shove them into something that everyone can read from and everyone can write to, and you build your God box somewhere, and it works. But yeah, it's just in developer tooling, you're absolutely right. In developer tooling, this is everywhere, right?

swyx [00:13:47]: And that, you know, it shows up everywhere. And what was interesting is I think everyone who makes the God box then has the same set of problems, which is also you now have like composability off and remotes versus local. So, you know, there's this very common set of problems. So I kind of want to take a meta lesson on how to do the God box, but, you know, we can talk about the sort of development stuff later. I wanted to double click on, again, the presentation that Justin mentioned of like how features manifest and how you said some things are the same, but you just want to reify some concepts so they show up differently. And I had that sense, you know, when I was looking at the MCP docs, I'm like, why do these two things need to be the difference in other? I think a lot of people treat tool calling as the solution to everything, right? And sometimes you can actually sort of view kinds of different kinds of tool calls as different things. And sometimes they're resources. Sometimes they're actually taking actions. Sometimes they're something else that I don't really know yet. But I just want to see, like, what are some things that you sort of mentally group as adjacent concepts and why were they important to you to emphasize?

Justin/David [00:14:58]: Yeah, I can chat about this a bit. I think fundamentally we every sort of primitive that we thought through, we thought from the perspective of the application developer first, like if I'm building an application, whether it is an IDE or, you know, call a desktop or some agent interface or whatever the case may be, what are the different things that I would want to receive from like an integration? And I think once you take that lens, it becomes quite clear that that tool calling is necessary, but very insufficient. Like there are many other things you would want to do besides just get tools. And plug them into the model and you want to have some way of differentiating what those different things are. So the kind of core primitives that we started MCP with, we've since added a couple more, but the core ones are really tools, which we've already talked about. It's like adding, adding tools directly to the model or function calling is sometimes called resources, which is basically like bits of data or context that you might want to add to the context. So excuse me, to the, to the model context. And this, this is the first primitive where it's like, we, we. Decided this could be like application controlled, like maybe you want a model to automatically search through and, and find relevant resources and bring them into context. But maybe you also want that to be an explicit UI affordance in the application where the user can like, you know, pick through a dropdown or like a paperclip menu or whatever, and find specific things and tag them in. And then that becomes part of like their message to the LLM. Like those are both use cases for resources. And then the third one is prompts. Which are deliberately meant to be like user initiated or. Like. User substituted. Text or messages. So like the analogy here would be like, if you're an editor, like a slash command or something like that, or like an at, you know, auto completion type thing where it's like, I have this kind of macro effectively that I want to drop in and use. And we have sort of expressed opinions through MCP about the different ways that these things could manifest, but ultimately it is for application developers to decide, okay, you, you get these different concepts expressed differently. Um, and it's very useful as an application developer because you can decide. The appropriate experience for each, and actually this can be a point of differentiation to, like, we were also thinking, you know, from the application developer perspective, they, you know, application developers don't want to be commoditized. They don't want the application to end up the same as every other AI application. So like, what are the unique things that they could do to like create the best user experience even while connecting up to this big open ecosystem of integration? I, yeah. And I think to add to that, the, I think there are two, two aspects to that, that I want to. I want to mention the first one is that interestingly enough, like while nowadays tool calling is obviously like probably like 95% plus of the integrations, and I wish there would be, you know, more clients doing tool resources, doing prompts. The, the very first implementation in that is actually a prompt implementation. It doesn't deal with tools. And, and it, we found this actually quite useful because what it allows you to do is, for example, build an MCP server that takes like a backtrack. So it's, it's not necessarily like a tool that literally just like rawizes from Sentry or any other like online platform that, that tracks your, your crashes. And just lets you pull this into the context window beforehand. And so it's quite nice that way that it's like a user driven interaction that you does the user decide when to pull this in and don't have to wait for the model to do it. And so it's a great way to craft the prompt in a way. And I think similarly, you know, I wish, you know, more MCP servers today would bring prompts as examples of, like how to even use the tools. Yeah. at the same time. The resources bits are quite interesting as well. And I wish we would see more usage there because it's very easy to envision, but yet nobody has really implemented it. A system where like an MCP server exposes, you know, a set of documents that you have, your database, whatever you might want to as a set of resources. And then like a client application would build a full rack index around this, right? This is definitely an application use case we had in mind as to why these are exposed in such a way that they're not model driven, because you might want to have way more resource content than is, you know, realistically usable in a context window. And so I think, you know, I wish applications and I hope applications will do this in the next few months, use these primitives, you know, way better, because I think there's way more rich experiences to be created that way. Yeah, completely agree with that. And I would also add that I would go into it if I haven't.

Alessio [00:19:30]: I think that's a great point. And everybody just, you know, has a hammer and wants to do tool calling on everything. I think a lot of people do tool calling to do a database query. They don't use resources for it. What are like the, I guess, maybe like pros and cons or like when people should use a tool versus a resource, especially when it comes to like things that do have an API interface, like for a database, you can do a tool that does a SQL query versus when should you do that or a resource instead with the data? Yeah.

Justin/David [00:20:00]: The way we separate these is like tools are always meant to be initiated by the model. It's sort of like at the model's discretion that it will like find the right tool and apply it. So if that's the interaction you want as a server developer, where it's like, okay, this, you know, suddenly I've given the LLM the ability to run a SQL queries, for example, that makes sense as a tool. But resources are more flexible, basically. And I think, to be completely honest, the story here is practically a bit complicated today. Because many clients don't support resources yet. But like, I think in an ideal world where all these concepts are fully realized, and there's like full ecosystem support, you would do resources for things like the schemas of your database tables and stuff like that, as a way to like either allow the user to say like, okay, now, you know, cloud, I want to talk to you about this database table. Here it is. Let's have this conversation. Or maybe the particular AI application that you're using, like, you know, could be something agentic, like cloud code. is able to just like agentically look up resources and find the right schema of the database table you're talking about, like both those interactions are possible. But I think like, anytime you have this sort of like, you want to list a bunch of entities, and then read any of them, that makes sense to model as resources. Resources are also, they're uniquely identified by a URI, always. And so you can also think of them as like, you know, sort of general purpose transformers, even like, if you want to support an interaction where a user just like drops a URI in, and then you like automatically figure out how to interpret that, you could use MCP servers to do that interpretation. One of the interesting side notes here, back to the Z example of resources, is that has like a prompt library that you can do, that people can interact with. And we just exposed a set of default prompts that we want everyone to have as part of that prompt library. Yeah, resources for a while so that like, you boot up Zed and Zed will just populate the prompt library from an MCP server, which was quite a cool interaction. And that was, again, a very specific, like, both sides needed to agree upon the URI format and the underlying data format. And but that was a nice and kind of like neat little application of resources. There's also going back to that perspective of like, as an application developer, what are the things that I would want? Yeah. We also applied this thinking to like, you know, like, we can do this, we can do this, we can do this, we can do this. Like what existing features of applications could conceivably be kind of like factored out into MCP servers if you were to take that approach today. And so like basically any IDE where you have like an attachment menu that I think naturally models as resources. It's just, you know, those implementations already existed.

swyx [00:22:49]: Yeah, I think the immediate like, you know, when you introduced it for cloud desktop and I saw the at sign there, I was like, oh, yeah, that's what Cursor has. But this is for everyone else. And, you know, I think like that that is a really good design target because it's something that already exists and people can map on pretty neatly. I was actually featuring this chart from Mahesh's workshop that presumably you guys agreed on. I think this is so useful that it should be on the front page of the docs. Like probably should be. I think that's a good suggestion.

Justin/David [00:23:19]: Do you want to do you want to do a PR for this? I love it.

swyx [00:23:21]: Yeah, do a PR. I've done a PR for just Mahesh's workshop in general, just because I'm like, you know. I know.

SPEAKER_03 [00:23:28]: I approve. Yeah.

swyx [00:23:30]: Thank you. Yeah. I mean, like, but, you know, I think for me as a developer relations person, I always insist on having a map for people. Here are all the main things you have to understand. We'll spend the next two hours going through this. So some one image that kind of covers all this, I think is pretty helpful. And I like your emphasis on prompts. I would say that it's interesting that like I think, you know, in the earliest early days of like chat GPT and cloud, people. Often came up with, oh, you can't really follow my screen, can you? In the early days of chat of, of chat, GPT and all that, like a lot, a lot of people started like, you know, GitHub for prompts, like we'll do prop manager libraries and, and like those never really took off. And I think something like this is helpful and important. I would say like, I've also seen prompt file from human loop, I think, as, as other ways to standardize how people share prompts. But yeah, I agree that like, there should be. There should be more innovation here. And I think probably people want some dynamicism, which I think you, you afford, you allow for. And I like that you have multi-step that this was, this is the main thing that got me like, like these guys really get it. You know, I think you, you maybe have a published some research that says like, actually sometimes to get, to get the model working the right way, you have to do multi-step prompting or jailbreaking to, to, to behave the way that you want. And so I think prompts are not just single conversations. They're sometimes chains of conversations. Yeah.

Alessio [00:25:05]: Another question that I had when I was looking at some server implementations, the server builders kind of decide what data gets eventually returned, especially for tool calls. For example, the Google maps one, right? If you just look through it, they decide what, you know, attributes kind of get returned and the user can not override that if there's a missing one. That has always been my gripe with like SDKs in general, when people build like API wrapper SDKs. And then they miss one parameter that maybe it's new and then I can not use it. How do you guys think about that? And like, yeah, how much should the user be able to intervene in that versus just letting the server designer do all the work?

Justin/David [00:25:41]: I think we probably bear responsibility for the Google maps one, because I think that's one of the reference servers we've released. I mean, in general, for things like for tool results in particular, we've actually made the deliberate decision, at least thus far, for tool results to be not like sort of structured JSON data, not matching a schema, really, but as like a text or images or basically like messages that you would pass into the LLM directly. And so I guess the correlation that is, you really should just return a whole jumble of data and trust the LLM to like sort through it and see. I mean, I think we've clearly done a lot of work. But I think we really need to be able to shift and like, you know, extract the information it cares about, because that's what that's exactly what they excel at. And we really try to think about like, yeah, how to, you know, use LLMs to their full potential and not maybe over specify and then end up with something that doesn't scale as LLMs themselves get better and better. So really, yeah, I suppose what should be happening in this example server, which again, will request welcome. It would be great. It's like if all these result types were literally just passed through from the API that it's calling, and then the API would be able to pass through automatically.

Alessio [00:26:50]: Thank you for joining us.

Alessio [00:27:19]: It's a hard to sign decisions on where to draw the line.

Justin/David [00:27:22]: I'll maybe throw AI under the bus a little bit here and just say that Claude wrote a lot of these example servers. No surprise at all. But I do think, sorry, I do think there's an interesting point in this that I do think people at the moment still to mostly still just apply their normal software engineering API approaches to this. And I think we're still need a little bit more relearning of how to build something for LLMs and trust them, particularly, you know, as they are getting significantly better year to year. Right. And I think, you know, two years ago, maybe that approach would have been very valid. But nowadays, just like just throw data at that thing that is really good at dealing with data is a good approach to this problem. And I think it's just like unlearning like 20, 30, 40 years of software engineering practices that go a little bit into this to some degree. If I could add to that real quickly, just one framing as well for MCP is thinking in terms of like how crazily fast AI is advancing. I mean, it's exciting. It's also scary. Like thinking, us thinking that like the biggest bottleneck to, you know, the next wave of capabilities for models might actually be their ability to like interact with the outside world to like, you know, read data from outside data sources or like take stateful actions. Working at Anthropic, we absolutely care about doing that. Safely and with the right control and alignment measures in place and everything. But also as AI gets better, people will want that. That'll be key to like becoming productive with AI is like being able to connect them up to all those things. So MCP is also sort of like a bet on the future and where this is all going and how important that will be.

Alessio [00:29:05]: Yeah. Yeah, I would say any API attribute that says formatted underscore should kind of be gone and we should just get the raw data from all of them. Because why, you know, why are you formatting? For me, the, the model is definitely smart enough to format an address. So I think that should go to the end user.

swyx [00:29:23]: Yeah. I have, I think Alessio is about to move on to like server implementation. I wanted to, I think we were talking, we're still talking about sort of MCP design and goals and intentions. And we've, I think we've indirectly identified like some problems that MCP is really trying to address. But I wanted to give you the spot to directly take on MCP versus open API, because I think obviously there's a, this is a top question. I wanted to sort of recap everything we just talked about and give people a nice little segment that, that people can say, say, like, this is a definitive answer on MCP versus open API.

Justin/David [00:29:56]: Yeah, I think fundamentally, I mean, open API specifications are a very great tool. And like I've used them a lot in developing APIs and consumers of APIs. I think fundamentally, or we think that they're just like too granular for what you want to do with LLMs. Like they don't express higher level AI specific concepts like this whole mental model. Yeah. But we've talked about with the primitives of MCP and thinking from the perspective of the application developer, like you don't get any of that when you encode this information into an open API specification. So we believe that models will benefit more from like the purpose built or purpose design tools, resources, prompts, and the other primitives than just kind of like, here's our REST API, go wild. I do think there, there's another aspect. I think that I'm not an open API expert, so I might, everything might not be perfectly accurate. But I do think that we're... Like there's been, and we can talk about this a bit more later. There's a deliberate design decision to make the protocol somewhat stateful because we do really believe that AI applications and AI like interactions will become inherently more stateful and that we're the current state of like, like need for statelessness is more a temporary point in time that will, you know, to some degree that will always exist. But I think like more statefulness will become increasingly more popular, particularly when you think about additional modalities that go beyond just pure text-based, you know, interactions with models, like it might be like video, audio, whatever other modalities exist and out there already. And so I do think that like having something a bit more stateful is just inherently useful in this interaction pattern. I do think they're actually more complimentary open API and MCP than if people wanted to make it out. Like people look. For these, like, you know, A versus B and like, you know, have, have all the, all the developers of these things go in a room and fist fight it out. But that's rarely what's going on. I think it's actually, they're very complimentary and they have their little space where they're very, very strong. And I think, you know, just use the best tool for the job. And if you want to have a rich interaction between an AI application, it's probably like, it's probably MCP. That's the right choice. And if, if you want to have like an API spec somewhere that is very easy and like a model can read. And to interpret, and that's what, what worked for you, then open API is the way to go. One more thing to add here is that we've already seen people, I mean, this happened very early. People in the community built like bridges between the two as well. So like, if what you have is an open API specification and no one's, you know, building a custom MCP server for it, there are already like translators that will take that and re-expose it as MCP. And you could do the other direction too. Awesome.

Alessio [00:32:43]: Yeah. I think there's the other side of MCPs that people don't talk as much. Okay. I think there's the other side of MCPs that people don't talk as much about because it doesn't go viral, which is building the servers. So I think everybody does the tweets about like connect the cloud desktop to XMCP. It's amazing. How would you guys suggest people start with building servers? I think the spec is like, so there's so many things you can do that. It's almost like, how do you draw the line between being very descriptive as a server developer versus like going back to our discussion before, like just take the data and then let them auto manipulate it later. Do you have any suggestions for people?

Justin/David [00:33:16]: I. I think there, I have a few suggestions. I think that one of the best things I think about MCP and something that we got right very early is that it's just very, very easy to build like something very simple that might not be amazing, but it's pretty, it's good enough because models are very good and get this going within like half an hour, you know? And so I think that the best part is just like pick the language of, you know, of your choice that you love the most, pick the SDK for it, if there's an SDK for it, and then just go build a tool of the thing that matters to you personally. And that you want to use. You want to see the model like interact with, build the server, throw the tool in, don't even worry too much about the description just yet, like do a bit of like, write your little description as you think about it and just give it to the model and just throw it to standard IO protocol transport wise into like an application that you like and see it do things. And I think that's part of the magic that, or like, you know, empowerment and magic for developers to get so quickly to something that the model does. Or something that you care about. That I think really gets you going and gets you into this flow of like, okay, I see this thing can do cool things. Now I go and, and can expand on this and now I can go and like really think about like, which are the different tools I want, which are the different raw resources and prompts I want. Okay. Now that I have that. Okay. Now do I, what do my evals look like for how I want this to go? How do I optimize my prompts for the evals using like tools like that? This is infinite depth so that you can do. But. Okay. Just start. As simple as possible and just go build a server in like half an hour in the language of your choice and how the model interacts with the things that matter to you. And I think that's where the fun is at. And I think people, I think a lot of what MCP makes great is it just adds a lot of fun to the development piece to just go and have models do things quickly. I also, I'm quite partial, again, to using AI to help me do the coding. Like, I think even during the initial development process, we realized it was quite easy to basically just take all the SDK code. Again, you know, what David suggested, like, you know, pick the language you care about, and then pick the SDK. And once you have that, you can literally just drop the whole SDK code into an LLM's context window and say, okay, now that you know MCP, build me a server that does that. This, this, this. And like, the results, I think, are astounding. Like, I mean, it might not be perfect around every single corner or whatever. And you can refine it over time. But like, it's a great way to kind of like one shot something that basically does what you want, and then you can iterate from there. And like David said, there has been a big emphasis from the beginning on like making servers as easy and simple to build as possible, which certainly helps with LLMs doing it too. We often find that like, getting started is like, you know, 100, 200 lines of code in the last couple of years. It's really quite easy. Yeah. And if you don't have an SDK, again, give the like, give the subset of the spec that you care about to the model, and like another SDK and just have it build you an SDK. And it usually works for like, that subset. Building a full SDK is a different story. But like, to get a model to tool call in Haskell or whatever, like language you like, it's probably pretty straightforward.

swyx [00:36:32]: Yeah. Sorry.

Alessio [00:36:34]: No, I was gonna say, I co-hosted a hackathon at the AGI house. I'm a personal agent, and one of the personal agents somebody built was like an MCP server builder agent, where they will basically put the URL of the API spec, and it will build an MCP server for them. Do you see that today as kind of like, yeah, most servers are just kind of like a layer on top of an existing API without too much opinion? And how, yeah, do you think that's kind of like how it's going to be going forward? Just like AI generated, exposed to API that already exists? Or are we going to see kind of like net new MCP experiences that you... You couldn't do before?

Justin/David [00:37:10]: I think, go for it. I think both, like, I, I think there, there will always be value in like, oh, I have, you know, I have my data over here, and I want to use some connector to bring it into my application over here. That use case will certainly remain. I think, you know, this, this kind of goes back to like, I think a lot of things today are maybe defaulting to tool use when some of the other primitives would be maybe more appropriate over time. And so it could still be that connector. It could still just be that sort of adapter layer, but could like actually adapt it onto different primitives, which is one, one way to add more value. But then I also think there's plenty of opportunity for use cases, which like do, you know, or for MCP servers that kind of do interesting things in and out themselves and aren't just adapters. Some of the earliest examples of this were like, you know, the memory MCP server, which gives the LLM the ability to remember things across conversations or like someone who's a close coworker built the... I shouldn't have said that, not a close coworker. Someone. Yeah. Built the sequential thinking MCP server, which gives a model the ability to like really think step-by-step and get better at its reasoning capabilities. This is something where it's like, it really isn't integrating with anything external. It's just providing this sort of like way of thinking for a model.

Justin/David [00:38:27]: I guess either way though, I think AI authorship of the servers is totally possible. Like I've had a lot of success in prompting, just being like, Hey, I want to build an MCP server that like does this thing. And even if this thing is not. Adapting some other API, but it's doing something completely original. It's usually able to figure that out too. Yeah. I do. I do think that the, to add to that, I do think that a good part of, of what MCP servers will be, will be these like just API wrapper to some degree. Um, and that's good to be valid because that works and it gets you very, very far. But I think we're just very early, like in, in exploring what you can do. Um, and I think as client support for like certain primitives get better, like we can talk about sampling. I'm playing with my favorite topic and greatest frustration at the same time. Um, I think you can just see it very easily see like way, way, way richer experiences and we have, we have built them internally for as prototyping aspects. And I think you see some of that in the community already, but there's just, you know, things like, Hey, summarize my, you know, my, my, my, my favorite subreddits for the morning MCP server that nobody has built yet, but it's very easy to envision. And the protocol can totally do this. And these are like slightly richer experiences. And I think as people like go away from like the, oh, I just want to like, I'm just in this new world where I can hook up the things that matter to me, to the LLM, to like actually want a real workflow, a real, like, like more richer experience that I, I really want exposed to the model. I think then you will see these things pop up, but again, that's a, there's a little bit of a chicken and egg problem at the moment with like what a client supported versus, you know, what servers like authors want to do. Yeah.

Alessio [00:40:10]: That, that, that was. That's kind of my next question on composability. Like how, how do you guys see that? Do you have plans for that? What's kind of like the import of MCPs, so to speak, into another MCP? Like if I want to build like the subreddit one, there's probably going to be like the Reddit API, uh, MCP, and then the summarization MCP. And then how do I, how do I do a super MCP?

Justin/David [00:40:33]: Yeah. So, so this is an interesting topic and I think there, um, so there, there are two aspects to it. I think that the one aspect is like, how can I build something? I think agentically that you requires an LLM call and like a one form of fashion, like for summarization or so, but I'm staying model independent and for that, that's where like part of this by directionality comes in, in this more rich experience where we do have this facility for servers to ask the client again, who owns the LLM interaction, right? Like we talk about cursor, who like runs the, the, the loop with the LLM for you there that for the server author to ask the client for a completion. Um, and basically have it like summarize something for the server and return it back. And so now what model summarizes this depends on which one you have selected in cursor and not depends on what the author brings. The author doesn't bring an SDK. It doesn't have, you had an API key. It's completely model independent, how you can build this. There's just one aspect to that. The second aspect to building richer, richer systems with MCP is that you can easily envision an MCP server that serves something to like something like cursor or win server. For a cloud desktop, but at the same time, also is an MCP client at the same time and itself can use MCP servers to create a rich experience. And now you have a recursive property, which we actually quite carefully in the design principles, try to retain. You, you know, you see it all over the place and authorization and other aspects, um, to the spec that we retain this like recursive pattern. And now you can think about like, okay, I have, I have this little bundle of applications, both a server and a client. And I can add. Add these in chains and build basically graphs like, uh, DAGs out of MCP servers, um, uh, that can just richly interact with each other. A agentic MCP server can also use the whole ecosystem of MCP servers available to themselves. And I think that's a really cool environment, cool thing you can do. And people have experimented with this. And I think you see hopefully more of this, particularly when you think about like auto-selecting, auto-installing, there's a bunch of these things you can do that make, uh, make a really fun experience. I, I think practically there are some niceties we still need to add to the SDKs to make this really simple and like easy to execute on like this kind of recursive MCP server that is also a client or like kind of multiplexing together the behaviors of multiple MCP servers into one host, as we call it. These are things we definitely want to add. We haven't been able to yet, but like, uh, I think that would go some way to showcasing these things that we know are already possible, but not necessarily taken up that much yet. Okay.

swyx [00:43:08]: This is, uh, very exciting. And very, I'm sure, I'm sure a lot of people get very, very, uh, a lot of ideas and inspiration from this. Is an MCP server that is also a client, is that an agent?

Justin/David [00:43:19]: What's an agent? There's a lot of definitions of agents.

swyx [00:43:22]: Because like you're, in some ways you're, you're requesting something and it's going off and doing stuff that you don't necessarily know. There's like a layer of abstraction between you and the ultimate raw source of the data. You could dispute that. Yeah. I just, I don't know if you have a hot take on agents.

Justin/David [00:43:35]: I do think, I do think that you can build an agent that way. For me, I think you need to define the difference between. An MCP server plus client that is just a proxy versus an agent. I think there's a difference. And I think that difference might be in, um, you know, for example, using a sample loop to create a more richer experience to, uh, to, to have a model call tools while like inside that MCP server through these clients. I think then you have a, an actual like agent. Yeah. I do think it's very simple to build agents that way. Yeah. I think there are maybe a few paths here. Like it definitely feels like there's some relationship. Between MCP and agents. One possible version is like, maybe MCP is a great way to represent agents. Maybe there are some like, you know, features or specific things that are missing that would make the ergonomics of it better. And we should make that part of MCP. That's one possibility. Another is like, maybe MCP makes sense as kind of like a foundational communication layer for agents to like compose with other agents or something like that. Or there could be other possibilities entirely. Maybe MCP should specialize and narrowly focus on kind of the AI application side. And not as much on the agent side. I think it's a very live question and I think there are sort of trade-offs in every direction going back to the analogy of the God box. I think one thing that we have to be very careful about in designing a protocol and kind of curating or shepherding an ecosystem is like trying to do too much. I think it's, it's a very big, yeah, you know, you don't want a protocol that tries to do absolutely everything under the sun because then it'll be bad at everything too. And so I think the key question, which is still unresolved is like, to what degree are agents. Really? Really naturally fitting in to this existing model and paradigm or to what degree is it basically just like orthogonal? It should be something.

swyx [00:45:17]: I think once you enable two way and once you enable client server to be the same and delegation of work to another MCP server, it's definitely more agentic than not. But I appreciate that you keep in mind simplicity and not trying to solve every problem under the sun. Cool. I'm happy to move on there. I mean, I'm going to double click on a couple of things that I marked out because they coincide with things that we wanted to ask you. Anyway, so the first one is, it's just a simple, how many MCP things can one implementation support, you know, so this is the, the, the sort of wide versus deep question. And, and this, this is direct relevance to the nesting of MCPs that we just talked about in April, 2024, when, when Claude was launching one of its first contexts, the first million token context example, they said you can support 250 tools. And in a lot of cases, you can't do that. You know, so to me, that's wide in, in the sense that you, you don't have tools that call tools. You just have the model and a flat hierarchy of tools, but then obviously you have tool confusion. It's going to happen when the tools are adjacent, you call the wrong tool. You're going to get the bad results, right? Do you have a recommendation of like a maximum number of MCP servers that are enabled at any given time?

Justin/David [00:46:32]: I think be honest, like, I think there's not one answer to this because to some extent, it depends on the model that you're using. To some extent, it depends on like how well the tools are named and described for the model and stuff like that to avoid confusion. I mean, I think that the dream is certainly like you just furnish all this information to the LLM and it can make sense of everything. This, this kind of goes back to like the, the future we envision with MCP is like all this information is just brought to the model and it decides what to do with it. But today the reality or the practicalities might mean that like, yeah, maybe you, maybe in your client application, like the AI application, you do some fill in the blanks. Maybe you do some filtering over the tool set or like maybe you, you run like a faster, smaller LLM to like filter to what's most relevant and then only pass those tools to the bigger model. Or you could use an MCP server, which is a proxy to other MCP servers and does some filtering at that level or something like that. I think hundreds, as you referenced, is still a fairly safe bet, at least for Claude. I can't speak to the other models, but yeah, I don't know. I think over time we should just expect this to get better. So we're wary of like constraining anything and preventing that. Sort of long. Yeah, and obviously it highly, it highly depends on the overlap of the description, right? Like if you, if you have like very separate servers that do very separate things and the tools have very clear unique names, very clear, well-written descriptions, you know, your mileage might be more higher than if you have a GitLab and a GitHub server at the same time in your context. And, and then the overlap is quite significant because they look very similar to the model and confusion becomes easier. There's different considerations too. Depending on the AI application, if you're, if you're trying to build something very agentic, maybe you are trying to minimize the amount of times you need to go back to the user with a question or, you know, minimize the amount of like configurability in your interface or something. But if you're building other applications, you're building an IDE or you're building a chat application or whatever, like, I think it's totally reasonable to have affordances that allow the user to say like, at this moment, I want this feature set or at this different moment, I want this different feature set or something like that. And maybe not treat it as like always on. The full list always on all the time. Yeah.

swyx [00:48:42]: That's where I think the concepts of resources and tools get to blend a little bit, right? Because now you're saying you want some degree of user control, right? Or application control. And other times you want the model to control it, right? So now we're choosing just subsets of tools. I don't know.

Justin/David [00:49:00]: Yeah, I think it's a fair point or a fair concern. I guess the way I think about this is still like at the end of the day, and this is a core MCP design principle is like, ultimately, the concept of a tool is not a tool. It's a client application, and by extension, the user. Ultimately, they should be in full control of absolutely everything that's happening via MCP. When we say that tools are model controlled, what we really mean is like, tools should only be invoked by the model. Like there really shouldn't be an application interaction or a user interaction where it's like, okay, as a user, I now want you to use this tool. I mean, occasionally you might do that for prompting reasons, but like, I think that shouldn't be like a UI affordance. But I think the client application or the user deciding to like filter out the user, it's not a tool. I think the client application or the user deciding to like filter out things that MCP servers are offering, totally reasonable, or even like transform them. Like you could imagine a client application that takes tool descriptions from an MCP server and like enriches them, makes them better. We really want the client applications to have full control in the MCP paradigm. That in addition, though, like I think there, one thing that's very, very early in my thinking is there might be a addition to the protocol where you want to give the server author the ability to like logically group certain primitives together, potentially. Yeah. To inform that, because they might know some of these logical groupings better, and that could like encompasses prompts, resources, and tools at the same time. I mean, personally, we can have a design discussion on there. I mean, personally, my take would be that those should be separate MCP servers, and then the user should be able to compose them together. But we can figure it out.

Alessio [00:50:31]: Is there going to be like a MCP standard library, so to speak, of like, hey, these are like the canonical servers, do not build this. We're just going to take care of those. And those can be maybe the building blocks that people can compose. Or do you expect people to just rebuild their own MCP servers for like a lot of things?

Justin/David [00:50:49]: I think we will not be prescriptive in that sense. I think there will be inherently, you know, there's a lot of power. Well, let me rephrase it. Like, I have a long history in open source, and I feel the bizarre approach to this problem is somewhat useful, right? And I think so that the best and most interesting option wins. And I don't think we want to be very prescriptive. I will definitely foresee, and this already exists, that there will be like 25 GitHub servers and like 25, you know, Postgres servers and whatnot. And that's all cool. And that's good. And I think they all add in their own way. But effectively, eventually, over months or years, the ecosystem will converge to like a set of very widely used ones who basically, I don't know if you call it winning, but like that will be the most used ones. And I think that's completely fine. Because being prescriptive about this, I don't think it's any useful, any use. I do think, of course, that there will be like MCP servers, and you see them already that are driven by companies for their products. And, you know, they will inherently be probably the canonical implementation. Like if you want to work with Cloudflow workers and use an MCP server for that, you'll probably want to use the one developed by Cloudflare. Yeah. I think there's maybe a related thing here, too, just about like one big thing worth thinking about. We don't have any like solutions completely ready to go. It's this question of like trust or like, you know, vetting is maybe a better word. Like, how do you determine which MCP servers are like the kind of good and safe ones to use? Regardless of if there are any implementations of GitHub MCP servers, that could be totally fine. But you want to make sure that you're not using ones that are really like sus, right? And so trying to think about like how to kind of endow reputation or like, you know, if hypothetically. Anthropic is like, we've vetted this. It meets our criteria for secure coding or something. How can that be reflected in kind of this open model where everyone in the ecosystem can benefit? Don't really know the answer yet, but that's very much top of mind.

Alessio [00:52:49]: But I think that's like a great design choice of MCPs, which is like language agnostic. Like already, and there's not, to my knowledge, an Anthropic official Ruby SDK, nor an OpenAI SDK. And Alex Roudal does a great job building those. But now with MCPs is like. You don't actually have to translate an SDK to all these languages. You just do one, one interface and kind of bless that interface as, as Anthropic. So yeah, that was, that was nice.

swyx [00:53:18]: I have a quick answer to this thing. So like, obviously there's like five or six different registries already popped up. You guys announced your official registry that's gone away. And a registry is very tempting to offer download counts, likes, reviews, and some kind of trust thing. I think it's kind of brittle. Like no matter what kind of social proof or other thing you can, you can offer, the next update can compromise a trusted package. And actually that's the one that does the most damage, right? So abusing the trust system is like setting up a trust system creates the damage from the trust system. And so I actually want to encourage people to try out MCP Inspector because all you got to do is actually just look at the traffic. And like, I think that's, that goes for a lot of security issues.

Justin/David [00:54:03]: Yeah, absolutely. Cool. And then I think like that's very classic, just supply chain problem that like all registries effectively have. And the, you know, there are different approaches to this problem. Like you can take the Apple approach and like vet things and like have like an army of, of both automated system and review teams to do this. And then you effectively build an app store, right? That's, that's one approach to this type of problem. It kind of works in, you know, in a very set, certain set of ways. But I don't think it works in an open source kind of ecosystem for which you always have a registry kind of approach, like similar to MPM and packages and PiPi.

swyx [00:54:36]: And they all have inherently these, like these, these supply chain attack problems, right? Yeah, yeah, totally. Quick time check. I think we're going to go for another like 20, 25 minutes. Is that okay for you guys? Okay, awesome. Cool. I wanted to double click, take the time. So I'm going to sort of, we previewed a little bit on like the future coming stuff. So I want to leave the future coming stuff to the end, like registry, the, the, the stateless servers and remote servers, all the other stuff. But I wanted to double click a little bit. A little bit more on the launch, the core servers that are part of the official repo. And some of them are special ones, like the, like the ones we already talked about. So let me just pull them up already. So for example, you mentioned memory, you mentioned sequential thinking. And I think I really, really encourage people should look at these, what I call special servers. Like they're, they're not normal servers in the, in the sense that they, they wrap some API and it's just easier to interact with those than to work at the APIs. And so I'll, I'll highlight the, the memory one first, just because like, I think there are, there are a few memory startups, but actually you don't need them if you just use this one. It's also like 200 lines of code. It's super simple. And, and obviously then if you need to scale it up, you should probably do some, some more battle tested thing. But if you're interested, if you're just introducing memory, I think this is a really good implementation. I don't know if there's like special stories that you want to highlight with, with some of these.

Justin/David [00:56:00]: I think, no, I don't, I don't think there's special stories. I think a lot of these, not all of them, but a lot of them originated from that hackathon that I mentioned before, where folks got excited about the idea of MCP. People internally inside Anthropik who wanted to have memory or like wanted to play around with the idea could quickly now prototype something using MCP in a way that wasn't possible before. Someone who's not like, you know, you don't have to become the, the end to end expert. You don't have access. You don't have to have access to this. Like, you know. You don't have to have this private, you know, proprietary code base. You can just now extend cloud with this memory capability. So that's how a lot of these came about. And then also just thinking about like, you know, what is the breadth of functionality that we want to demonstrate at launch?

swyx [00:56:47]: Totally. And I think that is partially why it made your launch successful because you launch with a sufficiently spanning set of here's examples and then people just copy paste and expand from there. I would also highlight the file system MCP server only because it has edit file. And basically, I think people were very excited when we had Eric who built your sort of sweet bench projects on the podcast as well. And people were very interested in this sort of like file editing tool that is basically open source via this project. And I think a lot of there's some libraries out there. There's some other implementations that like, you know, this is core IP for them. And now it's just you guys just put it out there. It's just really cool.

Justin/David [00:57:32]: Yeah. I really, I mean, honestly, the file system server is one of my favorites because I think it really speaks to like a limitation that I was feeling. You know, I was like hacking on a game as a side project and really wanted to connect it to like cloud and artifacts like David talked about before. Just giving cloud or like suddenly being able to give cloud the ability to like actually interact with my local machine was huge. I really love that sort of capability. Yeah. I mean, this is the classic example of like this server directly comes out of the frustration that both created MCP and that server. There was a very clear direct path of like, here's the frustration we're currently having to MCP plus the server that we both felt and Justin in particular. So that regard is close to our heart as like as a spiritual inception point of the protocol itself.

swyx [00:58:28]: Absolutely. Okay. And then I think the last thing I'll highlight is sequential thinking, which you already talked about. This gives like branching, which is kind of interesting. It gives a sort of, you know, I need more space to write, which is kind of super interesting. And I think one thing I also wanted to clarify was Anthropic this week, well, this past week, put out a new engineering blog with a think tool. And there's a bit of community confusion how sequential thinking overlaps with the think tool. I just think that it's just different teams doing similar things in different ways. And I think there's a lot of different parts of the world. But I just wanted to let you guys clarify.

SPEAKER_03 [00:59:03]: I think, mean, there's definitely like, sorry, let me start over.

Justin/David [00:59:11]: As far as I know, there is no common lineage between these two things. But I think it just speaks to a larger thing that like there are many different strategies to get an LLM to be more thoughtful or hallucinate less or whatever it might be. To kind of like express these different dimensions more fully or more reliably. And I don't know. I think this is like the power of MCP that like you could build different servers that do these different things or have like, you know, different products or different tools within the same server that do these different things. And like ask the LLM to apply a particular like mental model or thinking pattern or whatever for different results. So I don't know. I think I guess don't know that there will be like one ideal prescribed method like LLM. How you should think all the time.

SPEAKER_03 [01:00:05]: I think there will be different applications for different purposes. And MCP allows you to do that, right?

Justin/David [01:00:11]: Yeah, I think in addition, there's also like the way that the approach to this that some of the MCP servers, they're filling a gap that existed at the at a point in time that the models later catch up to by themselves. Because, you know, they have this training time and preparation research that goes into making models.

Justin/David [01:00:36]: And you can get a lot of mileage of something as simple as a sequential thinking tool like server. It's not simple, but it's like it's doable within a few days, which is definitely not the time frame you look at adding thinking to a model natively. I guess to come up with an example on the fly, like I could imagine building, you know, if I'm working with a model that is not particularly reliable or, you know, maybe someone considers the generation today overall not particularly reliable. Like I could imagine building an MCP server that gives me like best of three, you know, tries like three times to answer a query with the model and then picks the best one or something like that. Like you could get this kind of like recursive and composable LLM interactions with MCP.

swyx [01:01:18]: Awesome. Okay, cool. I think so, you know, we are sorry. Thanks for indulging on like some of the servers. We just wanted to double click on these. I think we have time for just like future roadmap things. People were most excited about this recent update. Moving from state to state. Stateful to stateless servers. You guys picked SSE as your sort of launch protocol and transport. And obviously transport is pluggable. The behind the scenes of that, like was it Jared Palmer's tweet that caused it or were you already working on it?

Justin/David [01:01:49]: No, we have GitHub discussions going back, like, you know, in public going back months, really talking about this, this dilemma and the trade-offs involved. You know, we do believe that like. The future of AI applications and ecosystem and agents, all of these things I think will be stateful or will be more in the direction of statefulness. So we had a lot of. I think honestly, this is one of the most contentious topics we've discussed as like the core MCP team and like gone through multiple iterations on and back and forth. But ultimately just came back to this conclusion that like if the future looks more stateful, we don't want to move away from that paradigm. Completely. Now we have to balance that against it's it's been operationally complex or like it's hard to deploy an MCP server if it requires this like long lived persistent connection. This this is the original like SSE transport design is basically you deploy an MCP server and then a client can come in and connect. And then basically you should remain connected indefinitely, which is that's like a tall order for anyone operating at scale. It's just like not a deployment or operational model. You really want to support it. So we were trying to think, like, how can we balance the belief that statefulness is important with sort of simpler operation and maintenance and stuff like that? And the news sort of we're calling it the streamable HTTP transport that we came up with still has SSE in there. But it has a more like a gradual approach where like a server could be just plain HTTP, like, you know, have one endpoint that you send HTTP posts to and then, you know, get a result back. But do you think that's it? Yeah. And then you can like gradually enhance it with like, OK, now I want the results to be streaming or like now I want the server to be able to issue its own requests. And as long as the server and client both support the ability to like resume sessions, like, you know, to disconnect and come back later and pick up where you left off, then you get kind of the best of both worlds where it could still be this stateful interaction and stateful server, but allows you to like horizontally scale more easily or like deal with spotty network connections or whatever the case may be.

Alessio [01:04:00]: Yeah. Yeah. And you had, as you mentioned, session ID. How do you think about auth going forward? For some MCPs, I just need to like paste my API key in the command. Is there kind of like a, yeah, what do you see as the future of that? Is there going to be like the dot M equivalent of like for MCPs or? Yeah.

Justin/David [01:04:18]: We do have authorization as a specification in the current draft of the next revision of the protocol. It's mostly at the moment focused on user to server authorization. Using like OAuth 2.1 or like, you know, a subset of, of modern OAuth basically. And I think that has, that has seems to be working well for people and people building on top of that. And that will solve a lot of these issues because you don't really want to have people bring API keys, particularly when you have like, when you think about a world, which, which I truly believe will happen where the majority of servers will be remote servers. So you need some sort of authorization with that server. Now for the local case, because the authorization is defined on, on the transport layer. And so requires framing, which means like headers effectively. This does not work in standard IO, but in standard IO you run locally and you can do whatever you want anyway. And you might just pop open a browser and deal with it that way. And then there's also like some thinking that is somewhat, somewhat not fully decided on about, you know, even using. Yeah. HTTP locally, which would solve that problem. And Justin is laughing because he's very much in favor of this where I'm very much not in favor of this.

Justin/David [01:05:38]: So there's some debate going on there, but like authorization, I think, you know, we have something, I think it's like, it's as everything in the protocol is like fairly minimal, like trying to solve a very practical problem. It tries to be very minimal in what it, what it does. And then we go from there and add based on practical pain points people have. On top of the protocol and don't try to over design it from the beginning. So we'll just see how far our current aspect gets us basically. Yeah. I want to build on that a bit because I think that last point is really important. And like, you know, when, when you're designing a protocol, you have to be extremely conservative because if you make a mistake, you basically can't undo that mistake or you break backwards compatibility. So it's far easier to like only accept things or like only add things that you're extremely certain about and let people kind of do ad hoc things. And then you can't do ad hoc extensions until maybe there's more like consensus that something is worth adding to the core thing and like supporting indefinitely going forward. And with auth in particular, and this example of API keys, I think this is really illustrative because we did a lot of this sort of like brainstorming, like, okay, if I have this use case, could I accomplish that with this version of auth? And I think the answer is yes for like the API key example. Like you can have an MCP server, which is an OAuth authorization server. And add a lot of that stuff. But if you look at the like slash authorize webpage, it just has like a text box for you to put in an API key. Like that would be a totally valid OAuth flow for the MCP server. Maybe not the most ergonomic or not what people would ideally like, but because it does fit into the existing paradigm and is possible today, we're worried about like adding too much other, too many other options that both then clients and servers need to think about.

Alessio [01:07:19]: Yeah. Have you guys gave scopes any thought? If it's like we had an episode with Dharmesh Shah yesterday from AJ. And he was giving the example of like email. Like he has all of his emails and, you know, he would like to have more granular scope for, hey, you can only access these types of emails or like emails to this person. Today, most scopes are like REST driven, basically. It's like what endpoints can you access? Do you see a future in which the model kind of access like the scope layer, so to speak, and kind of dynamically limits the data that passes through?

Justin/David [01:07:54]: I think the. I think there is a potential need for scopes. That goes back to like we have discussions around this, but what we're currently trying to do is just like routing them in very specific example and like have a good set of like these are actual problems that you cannot currently solve with the current implementations. And that's like the bar we set to add to the protocol. And I think that and then, you know, based on that prototype using that extensibility that we have at the moment where every structure that's returned is extensible. And then build on top of that. And prove that you that this will have a good user experience. And then we put it at the protocol. That's usually been for the most part the case. It's actually not quite the case for authorization in general. That's been a bit more top down. But I can totally see why people want it. It's just a matter of like showcasing the specific examples and like what the what the potential solutions would be so that we don't accidentally run into this like, yeah, the stuff that does this approach where like it sounds roughly right. And we put it in and it was actually not really right. And now you're back to this like adding is easy. Removing is hard in protocol design. And so we're just a little bit. We're just a little bit, you know, careful around this, so to speak. That being said, you know, every time I hear it like in the rough description, it makes sense. I would love to have a very practical end-to-end user example of this and where it falls apart the current implementation. Then we can have a discussion. There's a little bit of wariness from my perspective, too. Maybe not with Gov specifically. I think those could make a lot of sense as long as we have the use cases in mind. But I do think. You know, thinking about composability and logical groupings of things, I think it does often make sense for MCP servers to be quite small things. And if you want lots of collections of functionality for those to be discrete servers that you kind of combine together as a user or in the application layer. And so some of the pushback about auth has been like, well, if I need to authorize with like 20 different things on the other side, how can I do that? It's like, well, maybe maybe that's not what the server should be doing. And maybe it shouldn't be connecting to 20 different things. Maybe those should be separate servers that combine up somehow. Awesome.

swyx [01:10:00]: Lots of discussion there. Where should people go if they want to get involved in these debates? Is it just the specification repo discussion page? That's a good start.

Justin/David [01:10:09]: I want to caveat it slightly that on the Internet, it's very easy to be part of a discussion and having an opinion without then actually doing the work. And so I think there. We were. Both Jansen and I are very old school. Open source people that like it's it's marriage driven in the sense that if you have done work and if you if you showcase this with like practical examples and work in SDKs towards the ex extensions you want to make, you have a good chance that it gets in. If you're just there to have an opinion, you're very likely just being ignored, to be frank, because there's a limit to how much discussion points we can read. Of course, we value the discussion. And we want to have the discussion. But we also need to manage our time and our engagement. And we obviously select for the people who are doing the most work. We're trying to figure out, you know, honestly, like, I think. Even compared to open source work I've done in the past, just the sheer volume of conversation and notifications are an MCP stuff is extraordinary, which is great on one hand. But I think we do need to figure out more scalable structures. And I think that's a good start. Just to both engage with the community, but also keep conversations high signal and like effective. And I guess there's something else to be aware of related to David's point is like, I do believe that a big part of running a successful open source project is sometimes making hard decisions that people will be unhappy about. And you kind of just have to like, you know, learn to like, figure out like, what are the things? What is like the actual vision for the project? Where do we as the kind of like maintainers or like shepherds or whatever believes that it's going? And just commit to that and like understand that some people won't agree with that vision. And that's totally fine. But then maybe there will be other projects that are more in line with what they're hoping for or something like that. I think that's a very interesting and quite good point. It's like they're like a like a product like MCP is an entry into like into a solution space of the problems in that in the general like space. Yeah. I mean, it's it is one of many entries in a way. And and if you do not like the direction, you know, that we and like people that are very close, you know, in the development of the protocol choose then and then we cannot then then there's always place for more. Right. That's the beauty of open source. Right. The good old, you know, fork it approach. We do always want to hear the feedback and we need to make it scalable, I think. But also just the recognition that like sometimes we will be going with our intuition about what is the right choice. There might be a lot of like flame in the open source discussions about it. But that's just the nature of projects like this sometimes.

swyx [01:13:04]: Yeah. Fortunately, neither of you are new to that. I would also say there's a lot of history to be drawn from Facebook open source. Right. And both of you, if you weren't directly involved, you know, everyone who was directly involved, I would say reacts. We eventually started because I was obviously deeply part of the React ecosystem. We eventually started working groups where it was it was open. It was conducted on in discussions. And each member of the working group had a voice that represented a significant part of the community, but also showed that they did the work. They had a significance. They weren't sort of drive by people with no skin in the game. And I think that was helpful for a while. I'm not sure it's like an actively managed thing because of React's own issues with the multi-company situation that they're in. The other thing that actually is to me is more interesting is GraphQL. Because MCP currently has the hype that GraphQL had. And I lived through that one. And eventually, you know. Facebook donated GraphQL to an open source foundation. And I think that there's a question of like, do we want to do that? There's trade-offs, right? It's not a clear yes or no. Because I think GraphQL. Okay. So first of all, I would say that obviously I'm happy. Oh, sorry. Am I? Did I disconnect? Okay. I had a little.

Justin/David [01:14:16]: Okay. I had the same warning.

swyx [01:14:19]: Yeah, I had the same warning. Okay. I would say that most people are happy with Anthropic. And you guys, obviously, because you created it. You guys being the stewards. But at some point, at some scale, you're going to hit some ceiling there where you're like, okay, like, you know, this is owned by one company. And, you know, eventually people want to like, you know, the truly open standard is a nonprofit. There's multiple stakeholders. There's a good governance process. All of which is governed by like Linux Foundation, Apache, whatever. So I want to ask, like, any thoughts there? I personally would say it's too early. You know, like, what are your thoughts?

Justin/David [01:14:51]: Yeah. I think governance in general is a super interesting problem in the open source space. I think there are two things. On one side, we really, really, really want to make this and have this be an open standard and open protocol and open project with, you know, participation from everyone who wants to partake. And I think that actually is working quite well so far. If you look at the pull request, if you look, for example, a lot of the inputs on the streamable HTTP thing came from companies. Like, you know, Shopify and others that had discussed and worked on this and brought proposals to the table. And I think that works really well. The thing that we are a bit wary about is any type of official standardization, particularly going through an actual standardization body or any type of, like, foundational work that starts having processes as part of this to stay somewhat fair to everyone. That can add processes that in a fast moving field, like AI, can be detrimental to the project. And that's what we worry about. We worry about processes that are slowing us down. And so we're trying to find this nice middle ground of, like, how can we have participation that we luckily do have from everyone, work towards everyone's, you know, everyone's, like, problems that they have potentially with the governance model and figure the right path forward out without, you know, having to go back and forth.

Justin/David [01:16:23]: I think that's what we're trying to do. But yeah, we genuinely, we are very genuine in our desire to have this be an open project. And like, yes, it was initiated by Anthropic and David and I work at Anthropic. But like, we don't want it to be seen as like, this is Anthropic's protocol. I think it's very important for the whole ecosystem that this is something that, like, any AI lab could have a stake in or contribute to or make use of. But yeah, it's just, it's boundless. And we're balancing that against avoiding death by committee, basically. And so, like, I think there are a lot of models for doing this successfully in open source. I think most of the delicacies are really around, like, you know, sort of corporate sponsorship and corporate say. And we'll kind of navigate that as it comes up. But we absolutely want this to be like a community project. That being said, I want to highlight this, that at the moment, as we speak, there's plenty of people that are not Anthropic employees who have commit access and admin access, who's the repositories right there. You know, some of the people from Pydentic have commit access to the Python SDK because they did a lot of really good work there. And we had a lot of contributions from Block and others to the specifications. SDKs like the Java SDK and the C-Sharp SDKs, they're completely done by different companies. Like the C-Sharp one is done by Microsoft. It's a very recent addition last week. And they do everything there. They have full admin rights over that. The same goes with JetBranch doing the Kotlin one and Spring AI doing. The Java one. So it is actually, if you really look at it, it's already like a multi-company big project with everyone. It was a lot of people beyond just us two having commit access to and rights to the project as is. Yeah.

Alessio [01:18:06]: Awesome, guys. This was great. Just to wrap up, do you have any MCP server wish list? What do you want people to build you that is not there yet? Or client.

Justin/David [01:18:15]: Yeah. Client or server. I want more sampling clients. That's all I want. I want cool. I want someone to build a client that is sampling and someone else that builds me a server that does summarize my Reddit threads or summarize. Like I'm an old EVE Online player. Summarize what happened in EVE Online in the last week for me. I wish that someone would do that. But for that, I want a sampling client. I want this model independent. Not because I wanted to use any other model than Cloud because Cloud is by far the best. But I just want to have a sampling client for the sake of having a sampling client. Just a little bit of you. Yeah. Well, I'll echo that and just even broadly say, like, I think just more clients that support the full breadth of the spec would be amazing. I mean, we kind of designed things so that things can be adopted incrementally anyway. But, like, still, it would be great if, you know, all these primitives that we put this thought into do get manifested somehow. That would be amazing. But going back to, you know, some of my initial motivation for working on MCP and, like, excitement about the file system server. You know, like, I like hacking on a game as a side project. So I would really love to have an MCP client and or MCP server with, like, the Godot engine, which I was using to build the game. And just, like, have really easy, like, AI integration with that or, like, have, you know, Cloud run and playtest my game or something. Like, Cloud plays Pokemon. Who knows? Hey, at least you have them already built. Have Cloud already built your 3D model from now on with Blender, right? Yeah.

swyx [01:19:41]: I mean, honestly, even, like, shader code and stuff already. I was just like, this is not my wheelhouse. It's amazing what you can do when you enable builders. Yeah. We're actually working on a Cloud plays Pokemon hackathon with David Hershey. So to bring MCP into that, I had no plans.

Alessio [01:19:57]: But if he wants to, he can. Awesome, guys. Well, thank you for the time. Yeah. Keep up the good work.

Justin/David [01:20:03]: Thank you both. This was fun. Yeah. Thank you. Really appreciate it. Cheers.