How OpenAI Builds for 800 Million Weekly Users: Model Specialization and Fine-Tuning

We want ChatGPT as a first-party app. First-party app is a really great way to get 800 million wows or whatever now. Tenth of the globe, right? Yeah, yeah, 10% of the globe uses it. Every week, every week. Yeah, even within OpenAI, the thinking was that there would be like one model that rules them all. It's like definitely completely changed. It's like coming increasingly clear that there will be room for a bunch of specialized models. There will likely be a proliferation of other types of models. Companies just have giant treasure troves of data that they are sitting on. The big unlock that has happened recently is with the reinforcement fine-tuning. With that setup, we're now letting you actually run a URL, which allows you to leverage your data way more. OpenAI sells weapons to its own enemies. Every day, thousands of startups build on OpenAI's API, many trying to compete directly with ChaiGPT. It's the ultimate platform paradox. Enable your competitors or lose the ecosystem. Sherman Wu runs this high-wire act. He leads engineering for OpenAI's developer platform, the API that powers half of Silicon Valley's AI ambitions. Before OpenAI, he spent six years at Opendoor teaching machines to price houses where a single wrong prediction could cost millions. Today, Sherwin sits down with A16Z general partner Martin Casado to explore something nobody expected. That the models themselves are becoming anti-disintermediation technology. You can't abstract them away. And every attempt to hide them behind software fails because users already know and care which model they're using. It's changing everything about how platforms work. Sherwin and Martin talk about why OpenAI abandoned the dream of one model to rule them all, how they price access to intelligence, and why deterministic workflows might matter more than pure AI agents. So maybe we can start from present day and go backwards. So I currently lead the engineering team for OpenAI's developer platform. So the biggest product in there, of course, is the API. Is there more for the developer platform than the API? It's kind of assumed that it's synonymous. Well, so I also think about other things that we put into our platform side. So technically our government work is also like offering and deploying this into different areas. Yeah, like I've talked about. Oh, like so you have like a local deployment. Yeah, yeah. So we actually do have a local deployment at Los Alamos National Labs. It's super cool. I went to visit it. It's very different than what I'm used to. But yeah, in a classified supercomputer with our model running there. So there's that, but like mostly at the API. Did you go to Los Alamos? We did. Yeah, I did go to Los Alamos. It was great. They showed us around. They showed us some of the historic sites. I used to work at Livermore, man. So I've got like an answer. Oh, yeah, yeah, yeah. My first time out of college. Right, right, right. Maybe you sell to them next. Yeah, well, we hope to. Yeah, so I work on the developer platform. I've been working on it for around three years now. So I joined in 2022. I was basically hired to work on the API product, which at the time was the only product that OpenAI had. and I've basically just worked on it the entire time. I've always been super interested in the developer side and kind of like the startup story of this technology and so it's been really, really cool to kind of see this evolve. And so that's my time in OpenAI. Before OpenAI, I was at OpenDoor for around six years. I was working on the pricing side. My general background before... Something is such a dissident. Pricing at OpenDoor to like running API. It's such a different... It's been fascinating actually for me to see the differences between the companies. They're run so differently. They both have opened in the name so there's some overlap, but that's pretty much it. But yeah, I was there for around six years working on the pricing team. So our team basically would run the ML models. This is actually pricing the assets on Opendoor. Yeah, yeah. The inventory. Exactly. So yeah, Opendoor would buy and sell homes and their main product was buying homes directly from people selling them with all cash offers. And so my team was responsible for how much we would pay for them. And so it was a really fun ML challenge. It had a huge operational element to it as well because not everything was automated, obviously. But it was a really fascinating technical challenge. Is there any sense of that on the API side? GPU capacity buying or is it just totally unrelated? On the API side, there is a small bit of how we price the models, but I don't think we do anything as sophisticated as Open Door. Open Door is just such a hard problem. It's such an expensive asset. The holding costs are very expensive. You're holding onto it for months at a time. There's a variability in the holding time. And that's a long tail of potential things that could go wrong. Long tail, yes. And try to think about it from a portfolio perspective. And if one of them, you're holding onto it for two years, it blows everything like it was negative. So it's a very, very different. Six years? Different challenge, yeah. Yeah, six years there. Wow. Lots of up and downs, saw a lot of the booms, saw a lot of the struggles. And then we IPO'd for a lot. But yeah, just in general, it was a very great experience. I think for me, it was also just had such a very like business operations and like a very like by the book type of culture, whereas OpenAI is like very different. What's so interesting, I was just thinking about it now, it's like even for a company like that, like you don't think about it as a tech company, but if there is a deep technology problem actually is the pricing, right? It's actually an ML problem. Yeah, that's what attracted me to the company. It's not like the website, it's not the platform, it's not the API, it's literally that. Yep, yep, yep. And that's what attracted me to it. I think that's what was interesting. It's also a way lower margin business than OpenAI, because you're making a tiny spread on these homes. They would talk about basis points, like eating bits for breakfast and all that stuff. Anyways, I was at Opendoor for around six years, and then before that was my first job out of college, which was at Quora, Adam D'Anse for the time. No kidding. Yeah, so I was working on the newsfeed, So worked on use feed ranking for a bit, worked on the product side. That was actually my first exposure to like actual ML and industry and learned a lot from the engineers at core. We basically hired a lot of the early feed engineers from Facebook. Was Charlie still there when you were there? Charlie was not there when I was there. Okay, so you looked right after you left. Yeah, yeah, yeah. That was a really legendary team. It's still known to be kind of this super iconic founding team. Yeah, yeah. The early founding team was really solid. I still think that even while I was there, I still like am amazed at the quality of the talent that we had. Phenomenal. I think there's like when the company was like 50 to 100 people. but yeah, like a bunch of the perplexity team was there. Dennis was on the feed team with me, Johnny Ho, Jerry Ma. Yeah, that's right. And then Alexander, the scale, now MSL, was there between high school and college. It was an incredible team. I think I kind of took it for granted when I was there. I was a good group. How did you get to Quora? What did you study in undergrad? Yeah, so before that, I was at MIT for undergrad. I studied computer science, did like one of those like computer science and the master's degree, kind of like crammed it in. I ended up at Quora because I got in what we call an externship there. So at MIT, you actually get January off. So there's like the fall semester and then January's off. And then you have the spring semester. And so it's called independent activities period. So some people just like take classes. Some people just do nothing. But some people will do like month-long internships and some crazy companies will offer a month-long internship to a college student. And it really is just kind of like a way to get people. Did you come out here from Boston? Yeah, it was crazy. So you had to apply. I remember, yeah, this is I think 2013, January or something. You had to apply. And I remember the core internship was the one that just paid the most. They paid, I think it was like $8,000, $9,000. And I was like, wow, that's like all for a month. And you're just kind of ramping up like half the time. I can eat for a year. Yeah, yeah. As a college student, it was like great. And yeah, they would kind of like fly you out here. So I did the interviews and then luckily got an offer. And so, yeah, I came out for a January. That was right when they moved into their new Mountain View office. And I basically, yeah, honestly just ramped up for like two weeks and then have two weeks of good productivity working on the feed team. So that was like user-facing? Yeah. User-facing product work, yeah. Yeah, I distinctly remember my externship project for those two weeks was just to like add a couple features to our feature store. And that would make its way into the model. I remember my mentor there is Tudor, who's now running, I think it's called Harmonic Labs. Yeah, yeah, yeah. Crazy team, crazy team. That's just unbelievable. I mean, by the way, I think it's one of the untold stories of Silicon Valley is like how good that original team ended at Quora is. I mean, a lot of them are still there and still good, but the diaspora from Quora is everywhere. Yeah, yeah. That's actually how I ended up at OpenAI to kind of fast forwarding from there because OpenAI kind of kept a quiet profile-ish. I'd always kind of kept house on them because a bunch of the core people I knew kind of like ended up there. It's kind of like checking in on it and they were like, yeah, something crazy is happening here. You should definitely check it out. So yeah, I definitely owe a lot to Quora. But yeah, part of the reason why I went there versus other options as a new grad was the team was just so incredible and I just felt like I could learn a ton from them. I didn't think about everything afterwards. I was just like, man, if I could just absorb some knowledge from this group of people, it'd be great. Awesome. Yeah. So one place I wanted to start is something that I find very unique about OpenAI. is it's both a pretty horizontal company, like it's got an API. Like I would say, we've got this massive portfolio of companies, right? And I would say a good fraction of them use the API. And then it's also a vertical company in that you've got full-on apps, right? Like everybody uses ChatGPT, for example. And so you're responsible for the API and kind of the dev tool side. So maybe just to begin with, is there an internal tension between the two? Like, is that a discussion? like the API may, whatever, it may help a competitor to like the vertical version or is it not, things are just growing so fast, it's not an issue. I'd just love to, how you think about that. By the way, it's very unusual for companies to have both of that. These two things this early, it's very unusual. Yeah, yeah, I completely agree. I think there is some amount of tension. I think one thing that really helps here is Sam and Greg, just from a founder perspective, have since day one just been very principled in the way in which we approach this. They've always have kind of told us we want ChatGPT as a first-party app. We also want the API. And the nice thing is I think they're able to do this because at the end of the day, it kind of comes back to the mission of OpenAI, which is to create AGI and then to distribute the benefits as broadly as possible. And so if you interpret this, you want it in as many surfaces as you want. And the first-party app is a really great way to get, you know, it's like 800 million wows or whatever now. 800 million wows? Yeah, yeah. It's pretty, it's actually mind-boggling to think about. I don't think, many people listening to this don't understand how big that is. Yeah, it's crazy. That's got to be actually historic for the time it's taken to get to 800 million. It's historic. It's also just the amount of time and how much we've got to scale up. A tenth of the globe, right? Yeah, 10% of the globe uses it weekly. Every week, every week. And it's growing, and it's growing. So at some point, it'll go even higher than that. So yeah, obviously the reach there is unmatched. But then also just being able to have a platform where we can reach even more than just that. One thing we talk about internally sometimes is, what does our end user reach from the API? Like it's actually really, really, it's really bright. It might even, it's hard because ChatGPT is growing so quickly, but like at some points it was definitely larger than ChatGPT. And the fact that we're able to get Tappan in all of this and get the reach that we want, I think is really good. But yeah, I mean, there's definitely some tension sometimes. I think it's come up in a couple of places. I think one of them is on the product side. So as you mentioned, sometimes there are competitors kind of like building on our platform who might not be happy if ChatGPT launches something that competes with them. That's the tale of the old is the cloud or operating systems or whatever. So like that's, you know, I think it's more like does chat to be T worry about the competitor, you know, type thing. Like, you know, you enabling a competitor. Yeah, yeah. So I mean, the interesting thing is like, I would say not particularly, mostly just because we've been growing so quickly. It's like, you know, it's like such a, you know, force right now. Yeah, yeah. Growth solves so many different things. And like, and the other way we think about it It's like everyone's kind of building around AGI, building towards AGI. Of course, there's going to be some overlap here. So yeah, I mean, but I would say like, at least in my position, I feel more of this tension from the customer, like the API customers themselves, right? It's like, oh my gosh, you know, you're like, are you going to build this thing that I'm working on? Yeah, that story is as old as the computer system. There's never not been a computer platform that didn't have that problem. So, okay, so I kind of go back and forth on this one. I want to try one out on you, which is the problem historically with, you know, offering a core services and APIs, you can get disintermediated, right? And so I can build on top of it, but then, you know, the user doesn't know, like, whatever, I build on top of the cloud, but I disintermediate from the cloud and then I can switch to another cloud or whatever. And it occurs to me that that's kind of hard to do with these models because the models are so hard to abstract away. Like, they're just unruly, right? If you try to, like, have traditional software drive them, They just don't kind of manage very well. So part of me thinks that it's almost like this like anti-disintermediation technology that you kind of have to expose it to the user directly. Does that make sense? And so I'm wondering if like, so even if I think ChatGPT is really just trying to expose them all to the user, the API is kind of just trying to expose the model to the user. So I think there's almost this argument that's like, if the real value is in the models, it doesn't really matter how you get it to them because it's going to be very tough for someone who's going to abstract it away. in the classic sense of computer science of like they don't know that they're using the model. Like you always know you're using GPT-5. Yeah, and the interesting thing is I think like the entire industry kind of has slowly changed their mind around this too. I think like in the beginning we kind of thought like, oh, these are all going to be interchangeable. It's just like software. Yeah, yeah, exactly. So these are the things that you can just swap out. Yeah. But I think we're learning this on the product side with like, you know, the GPT-5 launch and like 4.0 and like how so many people like 0.3 and 4.0 and all of that. I felt that when it changed. I'm like, you're not as nice to me. like I like the validation. Yeah, it's actually fun because I really loved GPT-5's personality, but I think it's like the way I used, you know, chat GPT was very utilitarian. Oh, I see. It's like, you know, mostly for work, it's like information. Yeah I definitely come around just you know but like I actually felt a dissonance when it changed It like it like there this emotional thing that goes on but it almost like it an anti mediation technology You kind of have to show this to the user Yeah, and then you see a lot of more successful products like Cursor do this directly, especially the coding products where users want more control. We've even seen some more general consumer products do this. And so it's definitely been true on the consumer side. The interesting thing is I think it's also been true on the API side. And that's also something that I think... No, exactly. That's exactly what I'm saying. The argument could be that I could use the API to disintermediate you, but you don't see that happening because it's so hard to put a layer of software between a model and a person. You almost have to expose the model. Yes, yes. And I think, if anything, I think the models are almost diverging in terms of what they're good at and their specific use case. And I think there's going to be more and more of this. But yeah, basically, it's been surprisingly hard for, or the retention of people building on our API is surprisingly high, especially when people thought you could just kind of swap things around. You might have even tools that help you swap things around. But yeah, the stickiness of the model itself has been surprising. And do you think that is because of a relationship between the user and the model? Or do you think it's more of a technical thing, which is like, my evals work for like OpenAI and, you know, and like the correctness maintains. Yeah, yeah. I think it's both. So I think there's definitely an end user piece here, which is what we've heard from some of our customers. Like they just get familiar with the model itself. But I also think there's a technical piece, which is like the, also as a developer, especially with startups, You're like really going deep with these models and like really like iterating on it, trying to get it really good within your particular harness. You're iterating on your harness itself. You're giving it different tools here and there. And so you really do end up like building a product around the model. And so there is a technical piece where, you know, as you kind of keep building with a particular product like GPT-5, you're actually like building more around it so that your product works uniquely well with that model. so I use I use Cursor and just for like a lot of stuff like writing blogs and like you know we're investors and I use it for sometimes for coding and it's remarkable how many models I use in Cursor so like literally my go-to model is GPT-5 I love GPT-5 I think it's a phenomenal like you know and then like I use like max mode with GPT-5 for planning and then but you know like I mean I like the tab complete model that's in Cursor and like you know the new model they just dropped is for like some basic you know some stuff Yeah, the Composer one. Yeah, the Composer one's good. Yeah. And so, like, you know... And I think that, like, kind of reflects this, too, because it's, like, it's a particular model for each particular use case. Yeah, yeah, yeah. Like, I've talked to a bunch of people who've used the new Composer model, and it's just really good for, like, fast, like, first pass. Exactly, that's right. Like, keep you in flow kind of thing, and then you kind of, like, bubble out to another model if you want, like, you know, deeper thinking. I mean, I literally sit down. I literally sit down and ask GPT-5 to help me plan something out, and it's really good at that. And then, you know, like when I'm coding and I'm doing like the quick chat thing, then I'll use Composer. And if there's like whatever, there's like some crazy bug or something like that. So, you know, do you remember like in the early days of all of this where like there's going to be one model? And I mean like even like investors, like we will never invest in a model company because like there will only be one model and it's going to be AGI. But like the reality, it feels like there's this massive proliferation of models. Like you said before, they're doing many things. And so maybe two questions, maybe too blunt or too crass. but the first one is what does that mean for AGI? And the second one is what does that mean for OpenAI? Like does that mean that like you end up with a model portfolio? Do you select a subset? Do you think this all gets superseded by some god model in the future? Like how does that play out? Because it's against what most people thought. Most people thought this is all going towards one large model that does everything. Yeah, I think the crazy thing about all this is just like how everyone's thinking has just changed over time. Totally. Like I distinctly remember this like, and the crazy thing is not that long ago. It's just like two or three years ago. I remember, like, even within OpenAI, the thinking was that there would be, like, one model that rules them all. And it's like, why would you, I mean, like, this kind of goes to the fine-tuning API product. It's like, why would you even have a fine-tuning product? Why would you even want to, like, iterate on it? There's going to be this one model that just subsumes everything. And that was also kind of the, that is also, like, the most simplistic, like, view of what the AGI will look like. And, yeah, it's, like, definitely completely changed since then. I think one, and, but then the other thing to keep in mind is, like, it might continue to change, like, even from where we are today. But it's becoming increasingly clear, I think, that there will be room for a bunch of specialized models. There will likely be a proliferation of other types of models. I mean, you see us do this with the Codex model itself. We have GPT-4.1 and 4.0 and 5 and all of this. And so I definitely think there's room for all this. I don't think that's bad for what it's worth. If anything, I think as we've tried to move towards HCI, things have just been very unexpected. and I think the market just evolved and the product portfolio evolves because of that. So I don't think it's a bad thing at all. What I do think it means... You could easily argue it's very good for OpenAI and very good for the model companies to not have win-or-take-all consolidated dynamics, right? I mean, you just have a healthier ecosystem, a lot more solutions you can provide a lot. Yeah, and as the ecosystem grows, it generally is helpful. This is one thing we actually think about a lot too is as the general AI ecosystem grows, OpenAI just stands to benefit a lot from this and this is also why we've, like some of our products, we've even started opening up to other models, right? Like our E-Tiles product now allows you to bring in other models. It's all this. We think it's like any rising tide generally helps us here. But yeah, I think as we move into a world where there'll be a bunch more models, this is why we've kind of invested in our model customization product with the fine tuning API, with the reinforcement fine tuning, opening that up as well. It's also part of why we open sourced GPT-OSS as well because we want to be able to facilitate. I want to talk about that in just a bit because the open source is actually very interesting. I mean, actually, I thought the open source model was great, but clearly it's something that a company has to be careful with. But before that, I want to talk a little bit about the fine-tuning API. So I've noticed that you are moving towards kind of more sophisticated use of things like fine-tuning, which in a way you could read that as a bit of a capitulation that like, you know, there is product-specific data and there's product-specific use cases that a general model won't do, to your point, right? So like as opposed to proliferation of model, you do that. It seems like a lot of that data is actually very, very valuable, right? And so, you know, to what extent is there like interest in almost a tit-for-tat where you can like expose, you know, the ability to get product data into fine-tuning and then you also benefit from that data because the vendors provide it to you versus like this is 100%, you know, like they keep their own data and there's kind of no interest in that. Because it feels to me like the next level of scaling, this is kind of where we're at. And so I'm just kind of curious how. Yeah, so I mean, maybe even like taking a step back, the main reason why we even invested in a fine-tuning API in the very beginning is one, there's been huge demand from people to be able to customize the models a bit more. It kind of goes into like prompt engineering and also like I think the industry has changed their mind on that as well, like it's evolved. But the second thing is exactly what you said, which is the companies just have giant treasure troves of data that they are sitting on that they would like to utilize in some fashion in this AI wave. And you can, you know, the simple things to put it in like, you know, some like vector, like do rag with it or something. But there's also, you know, if they have a more technical team, they do want to see how they can use it to customize the models. And so that is actually the main reason why we've invested in this. The interesting thing was way back, kind of back in like 22, 23, our fine-tuning offering was, I'd say like too limited so that it was very difficult for people to tap into and use this data. So it was just like an SIF, like a supervised fine-tuning PI. And like, we're like, oh, you can kind of use it, but in practice, it really is only useful for like, it's honestly just like instruction following plus plus. You like kind of change the tone. You're just really like instructing it. But I think the big unlock that has happened recently with the reinforcement fine-tuning model because with that setup, we're now letting you actually run RL, which is more finicky and it's harder and you need to invest more in it. But it allows you to leverage your data way more. By the way, this is just a naive question for me, which is, it feels, from just my understanding from my own portfolio, it feels like there's two modalities of use. One of them is I've got a treasure trove of data that I've had for a long time and I create my model on that treasure trove of data and all that happens offline and then I deploy that. There's another one which is like I actually have the product being used in real time. I've got a bunch of users. And like I can actually get much closer to the user. I can kind of A-B test and decide which data. And like it's kind of more of a near real time thing. Is this focus on like more product stuff or more? So the dream with the fine tuning API was that we should be able to handle both, right? It's like we actually had this dream and we have this whole like Laura set up with the fine tuning inference where we should just be able to scale to like millions and millions of these fine-tuned models, which is usually what would happen if you have like this online learning thing. Yeah, exactly. In practice, it's mostly been the format. In practice, it's mostly been like the offline data that they've like already created or they are creating with experts or something and like using their product that they're able to use here. But the main thing I was trying to say around the reinforcement fine-tuning APIs, it kind of changes the paradigm away from just like small incremental, like tone improvements, which is what SFT did, to actually improving the model to potentially SOTA level on a particular use case that you know about. Like that's where people have really started using the reinforcement fine-tuning API and that's why it's gotten more uptake because if the discussion is less like, hey, I can make this model, you know, not like speak in a certain way better, it's less compelling. But if it's like, hey, for like, you know, medical insurance coding or for like coding planning, agentic planning or something, you can create the world's best model using your data set with RFT. then it becomes a lot more And will you ever like or maybe do you will you ever like find ways to get access to that data? Like Yeah so Listen if I had the data and I wanted cheap GPUs I'd trade you for it I don't know Yeah I mean we've talked about this and we've actually been piloting some pricing here too where it's like because this data is like really helpful and it's kind of hard to get and if you actually build with the reinforcement fine tuning API you can actually get discounted inference and potentially free training too if you're willing to share the data It's always kind of, you know, it's up to the customer there. But if they do, it is helpful for us, and there will be benefits for the customer as well. That's awesome. Okay, you said that views on prompt engineering have changed. Yeah. Actually, I wasn't aware of that. All the other things I wasn't aware of, that's when I wasn't. Yeah, I mean, I think the prevailing view, this is back in 2022. I remember I was talking to so many people, and they're basically, I mean, this is similar to, like, the single model AGI view as well, which is, like, prompt engineering is just not going to be a thing, and you're just not going to have to think about what you're putting in the context window in the future. Like the model would just be good enough and it'll just like know, it'll know what you need to do. Yeah, that's definitely not a thing. Yeah, but like, I don't know, maybe people forget it, but like that was like a very common belief because like the scaling laws or whatever, something with the scaling laws and like you'll just mind meld with the model and like you just like, like prompting and like instruction following will be so good that you won't really need to do it. And if anything, like, yeah, it's like clearly been wrong. And, but it is interesting because I think it's a slightly different world that we're in now where the models have gotten really, really good at instruction following relative to the GB3.5 or something. But I think the name of the game now is less on prompt engineering as we had thought about it two years ago. It's more of like the context engineering side where it's like, what are the tools you give it? What is the data that it pulls in? When does it pull in the right data? Well, this is very interesting. I mean, to reduce it to an almost absurdly simplistic level, the weird thing about RAG, for example, the classic use of RAG, is you're using cosine similarity to choose something that you're going to feed into a super intelligence. So, like, you know, you're like, I'm going to randomly grab this thing based on, like, fucking embedding space. It doesn't really, you know, and then, you know, when you want the super intelligence to decide the thing to do, and so it's like pushing intelligence in that retrieval clearly is something that makes a lot of sense. It's almost like pushing the intelligence out in a way. Exactly. And to be fair, I think, like, RAG was kind of introduced when the models were like, it was like pre-reasoning models. so it was like you only had kind of like one shot to like do this and it wasn't that smart. But now that we do have the reasoning models, now that we have, I mean, if you, like one of my favorite models is actually 03 because it was like one of the most diligent models. I use 03. It would just like do all these tool calls and it's like really the intelligence itself trying to like do the, you know, tool calls or reg or anything like that or write the code to execute. And so the paradigm has shifted there, but yeah, because of that, I think like context engineering, prompt engineering, what you put, what you give the model is like extra important. Okay, so you have the API, which is horizontal, you've got ChatGPT and other products, which are vertical. We haven't even talked about pixels. This is all just language. Are agents a new modality? Is that something else? Like, you know, like codex or... What do you mean by modality? Like I mean they feel both vertical and horizontal to me in a way Like to me ChatGPT is a product right It like it a product and like my mom uses it right And an API is a dev thing You know you kind of give it to a developer and, like, a CLI is kind of somewhere in between to me. It's like, is it a product? Is it, like, it is horizontal? Like, you know, how is it handled internally? Is it a totally separate team that does agents? Or? No, so it's, yeah, it's interesting because, like, I think the way that I, the way that you frame it just now, it almost seemed like agents was like this singular concept that might have its own particular routine. Maybe a better question is, what is an agent to you? Yeah, yeah, yeah. Even getting a language is important for this conversation. I actually don't even know if it would be helpful for me to share, but my general take on agents is it's an AI that will take actions on your behalf that can work over long time horizons. And I think that's the pretty general. But if you think about it that way, maybe this is what you mean by modality, but it is just a way of using AI. And I guess it could be viewed as a modality, but we don't view it as a separate thing, separate from AI and traffic. Let me just try and give you a sense of where this question is coming from. I know how to build a product, and we know how to go to market for products. We know how to do... We know the implications of turning them into platforms. It's just we've been doing this for a very long time. We know how to do the same thing for APIs. We know how to do billing. you know like the tension of like people build on top of it and all of that stuff and like what I've been trying to and this is just maybe a personal inquiry it's just not clear for me for an agent if you if it sits in one of those two camps is it more like the product camp is it more like the or because it's kind of both like I could like literally give you code and yeah yeah and like as a user and then you just talk to it or I could like build in a way kind of embed it in like my app. But then that means something to you as far as how do you price it and what does it mean for ecosystem? For example, would you be fine if I started a company and just built it around Codex? Is that a thing? Starting a company and building it around Codex? I actually think that would be great. We released the Codex SDK and we want people to be able to build it and hack on it. Actually, I think this might be what you're getting at, which is kind of a unique thing about OpenAI and kind of reflects on how it's run, which is at the end, like, at the end of the day, OpenAI is like an AGI company. It's like an intelligence company. And so agents are just like one way in which this intelligence kind of be manifested. And so the way that I'd say we actually think about internally is all of our different product lines, Sora, Codex, API, ChatGPT, are just different interfaces and different ways of deploying this. So there's no like single teams like this is, you know, like thinking about agents. I would say the way that it manifests itself more is like each product area thinks about like what is, you know, this intelligence is actually turning into a form where it can actually, agentic behavior is more possible. What would that look like in a first-party product like ChatGPT? What would that look like? This is actually why Codex ended up becoming its own products. What would it look like in a coding-style product? We explored it and ChatGPT kind of worked there, but actually the CLI interface actually makes a lot more sense. That's another interface to deploy it. And then if you look about the API itself, it's like this is another interface to deploy it. You're thinking about it in a slightly different way because it's a developer-first mindset. We're helping other people build it. the pricing is slightly different. But it's all these like different manifestations of this core like intelligence that is the agent behavior. It is so remarkable how much of this entire economy is basically just token laundering. In a sense, it's literally like anything I can do to get like English in or like a natural language in and then like, you know, the intelligence out. And I mean, it's because things are so resistant to layering. It's so hard to layer a language out. Like, you know, I could even do it pretty easily with like codex. I could just like use it, you know, as a component of a program and just, you know, basically launder intelligence. I mean, of course, you know, I'd be charged to do that. So I actually, my view of this and having seen now so many kind of launches of different products, I've seen agent launches and the definition that you have, I've definitely seen APIs and I've seen products on these, it's like, they're actually quite different than like what we're used to. Like the cogs is different, the defensibility is different, So we're kind of rewriting it. And so it's kind of like, you know, you came from a kind of pricing background. I mean, you were working on a model for pricing. Now you have the API. So I just love your thoughts on like, I mean, how have you evolved your thinking and how do you price these, you know, access to intelligence where, you know, you don't know how many people are going to use it. It's almost certainly usage-based billing, not something else. Like, can you talk just a bit about like philosophy around pricing on these things? Is it different for product versus API? Yeah, I think the honest route there is it's evolved over time as well. And I actually think the simplest, the reason why we've done usage-based pricing on the API, honestly, is because it's closest to how it's actually being used. And so that's kind of how we started. I actually think usage-based pricing on the API has surprisingly held strong. And I actually think this might be something that we'll keep doing for quite a long time, mostly because... The cogs are so high. I don't know how you don't do usage-based. I just don't know how that and then there's also the strategy of how we price it and internally one thing we do is we always make sure that we actually price our usage based pricing from a cost plus perspective we're actually just trying to make sure that we're being responsible from a margin perspective by the way this is a huge shift in the industry in general just because I remember the shift from on-prem to recurring that was a big big deal that created Zora, it created a whole company it was like a whole book saw it You know, like, a bunch of consultants on how you do this. It changed, like, you know, and, like, I think the shift to usage is as big or bigger. And it's also even a really hard technical problem. Yeah. I see. Like, I can't even imagine 800 million wow. Like, how do you build? Yeah. Well, 800 million wow is a little easier because it's not usage-based pricing. It's subscription. So it's, like, that was, like, way easier. But, I mean, there's still, like, a lot of users on the API that we need to, like, you know, manage all the billing side. There's some, like, overages or stuff you've got to deal with on that? What do you mean by overages? I don't know. I guess I don't know. Most people have quotas, and then we'll kind of, like, there are, like, max quotas that we don't let people go over. But, like, in practice, these quotas are, like, pretty massive. And that would literally be, like, one of the most complex systems somebody's ever built if you would do usage-based at, like, that scale. I mean, these are very, very, very, and, like, you have to be correct. Like, these are very hard systems to scale. Yep, yep, yep, yep, yeah. I mean, we have a whole team thinking about this now internally. Yeah, I mean, usage-free pricing is also interesting. So we acquired this company called Roxette a while ago. A founder, his name is Venkot. He's been here for org now. Yeah, Venkot's awesome. Venkot's incredible. He's one of the best. Venkot, if you're listening, we're huge fans. I'm a huge fan. He's going to love this. Yeah, he's great, man. He's a legend. Anyways, I was talking to him about pricing as well. And his take is that pricing is kind of like a one-way ratchet. And basically, once you get a taste of usage-based pricing, you're never going to go back to the per seat. 100%. the like per deployment type pricing. And I think that's definitely true. And I think it's just because it's getting, it gets closer and closer to like your true utility. You're getting all this thing. The main pain point is like, you have to maintain all this infra. Yeah, to like get it to work well. But if you do have it, he thinks it's like a one-way ratchet where like there's just like no going back. And then, and I think the hot new thing now is like, oh, with AI, you can now kind of measure like outcomes. And so that's like another, you know, like step forward. And if that works, like maybe it's a one-way ratchet. So we thought about that. It's like, you know, is there some type of like outcome-based pricing? This is more on the first party side. on an API is kind of hard to measure that. Yeah, that's very hard. I mean, that's hard because you end up having to price and value non-computer science infrastructure, right? Like, you're literally going into verticalization now. Like, you're like, I mean, listen, if it's like porting a code base, maybe you'd have some expertise. But if it's like, whatever, like increasing crop yields. Like, at some level, you need to, like... But there could be a world where, like, the AI is like, I don't know if I can, like, actually, you know, make judgments of these and do it in an accurate enough way where you can tie it to billing. I think this is a problem with AI conversations because at any point in time, you're like, but it could get good at life. It's not a problem anymore. Yeah, yeah, at some point it'll be solved. It's so much like the prompt engineering and the single AGI, I think, from before. Yeah, it's like when you reach that level of, when you push it that far, everything's kind of solved. On outcome-based pricing, it sounds very appealing. Like if it can work, it can work. But one thing that we've started realizing is it actually ends up correlating quite a bit with usage-based pricing, especially with test time compute. Like, if the thing is just, like, thinking quite a bit, like, actually, you know, if you charge just by usage-based and not outcome-based, you're, like, basically approximating outcome-based at this point. If the thing is, like, thinking for, like, so long, it's, like, highly correlated with what it's doing. It's just adding more value. Yeah, yeah, exactly, exactly. And so, like, maybe at the end of the day, like, usage-based pricing is all you need, and it's, like, we're just going to, like, you know, live in this world forever. But, yeah, I don't know. It's constantly evolving. I think our thinking has evolved here as well. I personally am keeping track of if the outcome-based pricing setups can actually work here, but at least on the API side, I think it's such a usage-based setup, we have to get infrastructure around this, and so I think we'll probably stay with that for a while. So how do you think about open source? I think you're the only big lab that's releasing open source. No, Google has some of theirs. Okay. Yeah, mostly smaller models on their side. Yeah, that's right. So how do you think about open source vis-a-vis competition, cannibalization? What's the strategic goal? What's the complexity? Yeah, yeah. So I personally love open source. I think it's great that there's a... All of us grew up with it, right? Yeah, all of us grew up with it. The internet wouldn't exist without it. So much of the world is built in half of it. Cloud wouldn't exist without it. Nothing would exist without it, except for maybe Windows. And so it was interesting because I felt like over the last years, before we launched the open source model. I know Sam feels this way as well. It's like there's this weird mindset where because OpenAI hadn't launched anything, it just seemed like it was super anti, like OpenAI was super anti-open source. But I'd actually been having conversations with Sam ever since I joined about open sourcing a model. We were just trying to think about how can we sequence it? What compute is always a hard thing. It's like, do we have the compute to train this thing? So we've always wanted to do this. I'm really glad that we were able to finally do it. I think it was, was it earlier this year? I lost sense of time. AI time is so great. Yeah, I was like, was it last year? No, it was this year. Yeah, when GPOSS came out. And so I was just really glad that we did that. The way that I generally think about it is, one, I think as a, this is also particularly true for OpenAI, because as you said, we are a vertical and a horizontal company. It's like, we want to continue investing in the ecosystem. And just from a brand perspective, I think it's good. But then also, I think from OpenAI's perspective, if the AI ecosystem grows more and more, it's like a rising tide. It's all really helpful for us. And if we can launch an open source model and it helps unlock a whole bunch of other use cases in the other industries, I think that's actually not good for us. Also, what people don't talk about a lot is how well these open source AI business models actually work. Because the cannibalization risk is actually very low. and like you don't really enable competitors a lot because I mean when we say open source you really mean open weights right it's not like they can recreate it and like if I can distill your API as well as I can distill like you giving me the weights in some way so like it doesn't really change that dynamic a lot but like yeah I mean to be clear like we have not seen cannibalization at all yeah of course not it seems like a very different set of use cases the customers tend to be like slightly different the use cases are very different and by the way it turns out inference is super hard to actually have scalable, fast, performant. That's a hard, hard problem. Yeah, so I'd say the way that I personally think about open source in relation to the API business in particular is, well, one, it hasn't shown cannibalization risk, so I'm not particularly worried about that. But also, especially for all these major labs, there are usually two or three models where that is where you're making all of your impact, all of your revenue. And those are the ones where we're throwing a bunch of resources into improving the model, and these tend to be the larger ones that are extremely hard to inference. we have a really cracked inference team at OpenAI and my sense is even if we just literally open sourced GPT-5 or something it would be really hard to inference it at the level that we are able to get it to do there's also by the way feedback loop between the inference team and the training team so we can kind of optimize all of that is it possible to verticalize models for products? you might train models specifically for products? yeah I mean to actually I think we've kind of done this with GPT-5 codecs, right? Or do you mean like even more verticalization? I mean, like deep, deep, deep verticalization where like, you know, like the released model wouldn't, you know, it's like actually part of a product. I think we're like basically starting to move in that direction. I think there's a question of how deeply you verticalize it I think most of what we done is mostly at like the post like the tool use level Like Codex is particularly good at using the sorry GBD5 Codex is particularly good at using the Codex harness But there's like even deeper verticalization you can do. Yeah, so I mean, yeah. And that one I think is more of an open question. Yeah, so like a lot of my, I mean, a lot of my mental model of this comes from the pixel space, which is like, you, you know, you can Laura a bunch of image models, right? And you can do a bunch of stuff to make it better and more suitable for some products, for example. But, like, these open source models are really, really good. And, like, you would believe that you could, like, verticalize a model for, like, editing or cut and paste or this or that. You know, like, that's actually part of this. But you actually don't see that happen. Yeah. It's almost always like you're just kind of exposing, like, a model, not something, like, specific to a product. Yeah, I think there's a distinction to be made between the image model space and the text model space. Yeah, probably. Also because the image models tend to be way smaller and you can iterate on it a lot faster. That's why you get that crazy cool proliferation of the image model side. Whereas, I don't know, for the text models, there's always going to be this really big, fat free training step that you have to invest in here. And then even the post-training side is like, it's not the easiest thing. Just from a compute perspective, obviously it's much smaller, but like it's still pretty heavy to do like a full mid-train or like a post-training run. And so I actually think like that's one of the bigger bottlenecks because I think you are right that like on the image side, yeah, you can like fine-tune an image diffusion model to be like extremely good at like editing faces. Yeah, like something very specific. And then you build a product around that. Yeah, yeah, yeah. And it's like, yeah, you can just kind of put all these resources into and iterate on that one specific model whereas it's a much heavier motion on the tech side. I got to say, it is a bit of an anti-pattern to do both languages like language-based models and diffusion-like pixel models in the same company. Like, most that have tried, like, it sounded very clunky to do it. But, I mean, you and Google are the two kind of counter examples for this. And so, like, is it possible to even, like, converge the infrastructures on these things? Like, I mean, is it totally different orgs? Is it shared infrastructure? Like, how do you operationalize? Yeah. I think you're totally right, it's an anti-pattern. It's pretty tough to pull off. I think, honestly, like, props to Mark on our research team for, like, you know, structuring things in a way we're able to do it. From my perspective, I think the biggest thing is I think our, like, image, like our, I think, called, like, the world simulation team, like the team that built Sora and all that under Aditya, is just extremely solid. Like, they are, it's, like, the highest concentration of, like, talent that I've seen in a while. But is it the same, like, is it the same, is it, like, are they, like, totally separate infrastructure? Do they use the same infrastructure? Yeah, yeah, yeah. So it's actually like pretty separate. And I think that's part of the reason why we're able to kind of do this. Well, one is like the team needs to be extremely strong, which they are. And then two is they're run very separately. They're kind of like thinking about their own particular roadmap. They think about productization very separately as well, right? Which is how like the Sora app kind of came out of that as well. And then, yeah, even like the inference stacks are kind of like different. They own a lot more around their inference stack and they optimize their reference stack pretty separately. And so I think that contributes to helping us run things in parallel, but it's pretty hard to pull off for sure. Maybe you can educate this on me. So I think about APIs as mostly text-based for OpenAI. Do you guys do actual pixel-based stuff? Yeah, yeah, we do. We have a bunch. So Dolly, Dolly 2 is in the API. Of course, yeah. The OG model. Dolly 2 is in the API. That was like the first real text image model, right? Yeah, yeah, yeah, yeah. That was actually the model that got me to go to OpenAI. No kidding. Because it was the summer when I was thinking about something new. It's when Dolly 2 came out. And it just completely blew my mind. Wow. And I distinctly remember I was asking it to do the simplest thing, like draw a picture of a duck or something. And it was the simplest thing now. And it generated a picture of a white duck. And so that was actually the thing that kind of got me to OpenAI in the first place. But yeah, we have a bunch in our API. The image gen model as well as in our API. and then Sora 2 is in our API. We launched it at DevDay. It's actually been a huge hit. I've been very, very surprised. Need more GPUs for that. But the amount of use cases. And then from your standpoint, like you can converge that, like the API infrastructure probably like that. Yeah, so there's, yeah, I'd say on the API side, a lot of the infrastructure is shared for those, but once you reach the inference level, they're separate, right? Because you got to inference them differently. Yeah, yeah, yeah. And it is that team that has just like been really laser focused on making that side particularly efficient and, yeah, and work well separate from the text models. But yeah, we have image gen, we have video gen, and we'll continue adding more to the API there. So it feels like we've been evolving our thinking as an industry on a bunch of stuff, right? Like one of them for sure is like the models like we've talked about. The other one is like context engineering. It seems to me that like actually how you build agents and expose them has evolved too. So maybe you can talk a bit about that. Yeah, yeah, I think. So at Dev Day this year when we launched our agent builder, I got a bunch of questions around this because the agent builder is like, yeah, it's like the bunch of different nodes and it's like the deterministic thing. And I was like, oh, is this really like the future of agents? And we obviously put a lot of thought into this when we were thinking about building that product. But the way I think about it is- Do you think they came from a point of being constrained? By the way, they're like, oh, this is too constraining. Yeah, I think people are like, it's too constraining. It's not like AGI forward. You know, like at the end of the day, at the end of the day, the AGI will do everything. And so like, why not? Why have nodes in this like node builder thing? Just tell it what to do. Yeah, and so I think there's like two things at play here. One of them is like there is a like practicality component. And then the other thing is I think there are actually like different types of work that exist out there that could be automated into agents. And so on the practicality side is, yeah, like the models today just like maybe in some future world, instruction following would be so good that you just like ask it to do this four-step process. And it like always does the four-step process exactly. We're still not there yet. And in the meantime, you know, this entire industry being born and a lot of, you know, people still want to use these models. What can you build for them? So there's a practicality component of it. When did you launch that? Dev Day. So it feels like forever ago. Earlier this month, October 6th or something. Yeah, so less than a month ago. It's been crazy seeing the reception to it, by the way. I think the video where Christina and my team demos Agent Builder is one of the most viewed videos on our YouTube channel now. I will say just anecdotally from kind of my perspective, people love it. But I also saw the dissonance too. Like I saw when it came out, people were like, wait, what is this? Yeah, exactly. Is this no code, low code? Yeah, exactly. It's another low code thing. And now people love it. Yeah, yeah. Yeah, so there's a practicality piece. There's another piece, which is like when we were talking to our customers, we've realized that there's like, because at the end of the day, a lot of this, the agent work is just trying to automate work and like what people do in their day-to-day jobs. I realized there's like actually like two different types of work. There's the work that we think about, which is like maybe what like software engineers do where it's like it's very undirected. There's like a high level goal and then you have like, you know, you have your cursor and you're just like writing code and you're kind of like exploring things and going towards an objective. That's like, I don't know, more like knowledge-based work, like data analysis, maybe like that, like codings kind of like this. But then there's another type of work which is actually what we realize is like maybe even more prevalent in industry than software. We're just not aware of it, which is work tends to be very procedural, very like SOP oriented. Customer support is a good example of this. Customer support, there's a very clear policy that these agents and people have to follow. And it is actually not great for them to deviate from this and try something else. It's like the team really, the people running these teams just really want these SOPs to be followed. And this pattern actually generalizes a ton of different work. A standard operating procedure. Yeah, sorry. So it's just like the way in which you need to operate the support team. But this extends to marketing, this extends to sales, extends to like a bunch, way more than it has any right to. And what we realize is like there's a huge need on that side to have determinism here, of which an agent builder with nodes that kind of like helps enforce this thing ends up being very, very helpful. But I think a lot of us, especially in Silicon Valley, don't really appreciate that there's like a ton of work that actually falls into this camp. I got to say like there's a pattern that's similar to this. I'm wondering if you've seen it that I've seen where some regulated industries actually can't let any generated content go to a user. Yeah. Right. And so what they do, I think it's so interesting. They'll either pass in a conversation tree, and you can choose something from here. Yeah, so there's some human element to it. So as part of the prompt, they're like, here are the viable things you can say, choose which one to say. So the language reasoning has happened by the model, but nothing generated comes out. Interesting, interesting. Does that make sense? Yeah, yeah, yeah, yeah. And then another one I've seen is actual pseudocops. I'll pass in a Python function. And then it'll ask a human to use a pseudocode to write actual code that makes it in? It actually has a response catalog as part of it, and it has, like, the logic to apply. And then... Interesting. And so, like, the model takes the language in from the human user. And then, well, like, you know, the logic of how to respond is, like, in Python code, because it just turns out that, like, there's been a lot of code written for these types of things, and then it actually includes the responses that you would send out. Does that make sense? Actually, a lot of NPCs are done this way, like actually video game NPCs. Yeah. So because the way that I think about it is like, you know. So that way with the NPCs, the actual code being generated by the model is not what ends up making it to the end user. The code is not being generated by the model. It's the prompt has the code. So let's say that I have an NPC and I want the NPC, like let's say you're the gamer. And so you're coming in and you're talking to my NPC, but my NPC has some logic that it needs to do. Like if you say a certain thing, I'll give you a key. Maybe a little barter. like describing the game logic in English just doesn't work actually if you try and do it and then like actually scripting the output doesn't work either if you needed to use it in a game context like you would have to know like give like a specific direction or a specific this or that so how do you make these things behave in a more constrained way people pass in functions like they'll actually describe the logic in Python so like my prompt will be like you're an NPC in a video game the user just asked you a question here's the logic you should go through. If the user says this, then do this. It's like a pseudocode. Like if the user has this, you know, in the belt, do this, like whatever, whatever, whatever. And then here are the set of valid responses. And so you're almost constraining. I see, I see, I see. And then when it actually does do a response, you can validate that it's one of those responses. I see, I see. It's like highly structured. Yeah, yeah, okay. So the MPC still only exists in that, like the space that it can act in is still only within the space of the program that you get. Yeah, well, the logic is in there. So it can have a normal conversation, but like in as much as you're trying to guide the logic for like game design or game logic. I see. So you see this with NPCs but you also see this with regulated industries where like I literally can't have it like. Yeah, I was going to say what you described kind of sounds like, you know, giving the SOPs to like your set of human operators to like have to stick to it, please. Yeah, you must say these three things and here's like the discussion. And like you cannot give a refund if it's like less than this amount. Yeah, yeah, yeah. Very interesting, yeah. I mean, yeah. I don't want to equate them to NPCs but like this is similar to similar. I'm just saying it's actually like if you want to really guarantee what happens, there's like a set of techniques that you do. And like there's some situations where you want to constrain what they do. It could be from a regulatory standpoint. It could be because you want it to run for a long time. And it also could because I actually have game logic. And my game logic is a traditional program. Like I have like a monetary system. I have an item system. I have a battle system. Like you can't describe that in English. Like you have to kind of give it to them so it can behave within that. Yes, and that is exactly the problem I think we're trying to solve here. right so it's like if you do not give it any of this like it can just kind of go off and do whatever and yeah there are like regulatory concerns around this and that is the exact use case that I think we're trying to target with Asian Builder that's awesome well listen we're running out of time and there's a million more things I want to ask you but listen I really appreciate your time to come in it was a great kind of survey and like what's going on and particularly like teasing apart horizontal versus vertical in this page which I really want to do so thank you so much yeah thank you thanks for listening to this episode of the A16Z podcast. If you liked this episode, be sure to like, comment, subscribe, leave us a rating or review and share it with your friends and family. For more episodes, go to YouTube, Apple Podcasts and Spotify. Follow us on X at A16Z and subscribe to our sub stack at a16z.substack.com. Thanks again for listening and I'll see you in the next episode. As a reminder, the content here is for informational purposes only. Should not be taken as legal, business, tax or investment advice or be used to evaluate any investment or security and is not directed at any investors or potential investors in any A16Z fund. Please note that A16Z and its affiliates may also maintain investments in the companies discussed in this podcast. For more details, including a link to our investments, please see a16z.com forward slash disclosures.