Latent Space

This is the last in our GPT-5 coverage of the vibes, bootstrapping, vision, and Router.

ICYMI, we are back with the AI Engineer CODE Summit, Nov 19-22 in NYC! Summits are usually >10x oversubscribed, with the most high signal content & attendees. If you are keen on developer productivity and what’s new in SWE agents, apply today.

The new GPT-5-Codex launches today, capping off perhaps the most intense month of vibe shifts in Coding Agents in recent memory (click to expand):

For a little over a year now, starting with Claude 3.5 Sonnet in June, 3.7 Sonnet and Claude Code in Feb, and Claude 4 in May, Anthropic has enjoyed an uncontested dominance in coding usecases, leading to an epic runup to $5B in revenue (10% of which is Claude Code) and a $183B valuation1, adding $122B in market cap.

That seems to have ignited a fire in OpenAI, which of course shipped the original 2021 Codex that kicked off GitHub Copilot, the original AI coding tool with 182 creators and counting2, and whose GPT3 inspired Debuild which presaged all the vibe coding startups, and of course started to reprioritize coding abilities in o1 and GPT 4.1.

GPT-5-codex’s 74.5% on SWE-bench (full 500) is kind of a wash vs the (infamously memed to pieces) GPT-5 thinking’s performance of 74.9% (477 task subset), so what is the cause of this major shift in GPT5 sentiment?

Well, for one, the Codex team has been COOKING.

As Greg says in today’s podcast, MANY people pitched in:

“At the beginning of the year, we set a company goal of an agentic software engineer by the end of the year. And figuring out exactly what that means and how to substantiate that and how to bring together all the opportunity and all the kind of compute that we have to bear on this problem. That has been a great undertaking for many, many people at OpenAI.”

The original A-SWE agentic harness was called 10X, and did live in the terminal, but since launching the new Codex CLI and then “ChatGPT Codex” (now Codex Cloud) and then the IDE extension (now at 800k installs after 2.5 weeks) and GitHub code review bot, there is now a complete set of interfaces to match all needs:

Here’s our rough illustration of the various tradeoffs in the Codex universe:

Although perhaps causing the least fanfare, the @codex code review bot might have the highest utility because of it’s very tight scoping:

“We started to notice that the big bottleneck for us was with increased amounts of code needing to be reviewed is like the amount of review simply that people had to do on the teams.

We decided to really focus on a very high signal Codex mode where it's able to review a PR and really think deeply about the contract and the intention that you were meaning to implement and then look at the code and validate whether that intention is matched and found in that code.

And it's able to go layers deep, look at all the dependencies, think about the contract and really raise things that some of our best employees, some of our best reviewers wouldn't have been able to find unless they were spending hours really deeply thinking about that PR.

We released this internally first at OpenAI. It was quite successful and people were upset actually when it broke because they felt like they were losing that safety net, and it accelerated teams and including the Codex team tremendously.”

We can’t see the datasets of course, but the other thing that OpenAI always emphasizes about their work is the tight integration of research and product. In today’s podcast we also heard a few references towards some of the desired qualities:

Thibault Sottiaux:

“One of the things that this model exhibits is an ability to go on for much longer and to really have that grit that you need on these complex refactoring tasks.

But at the same time, for simple tasks, it actually comes way faster at you and is able to reply without much thinking. And so it's like this great collaborative where you can ask questions about your code, find where this piece of code is that you need to change or better understand, plan. But at the same time, once you let it go onto something, it will work for a very, very long period of time.

We've seen it work internally up to seven hours for very complex refactorings. We haven't seen other models do that before. And we also have really worked tremendously on code quality. And it's just really optimized for what people are using GPT-5 within Codex for.

This tenacity judiciously applied is what makes GPT-5-Codex a much more useful agentic coding model all-round, not just optimizing for the most difficult problems only and then requiring a model switcher for dumber models (interestingly, it also doesn’t use ChatGPT’s GPT-5 Router we wrote about):

Greg:

“I remember for GPT-3 and for GPT-4 really focusing on the doubling down problem. Do you remember if the AI would say something wrong and you'd point out the mistake? It would try to convince you that it was right. We're so far past that being the core problem.

It's really amazing to see that we're at a level where even when it's not quite zeroed in on the right thing, it's highlighting stuff that matters. It has pretty reasonable thoughts. Greg Brockman: And I always walk away from these code reviews thinking like, huh, OK, yeah, that's a good point.”

We have no idea how they achieved this level of groundedness, but it is very likely correlated with the measurable drops in hallucination in GPT-5:

One of the dirtiest secrets in the industry is that “price per token” is less and less of a a relevant metric, because reasoning models can often use >10x more tokens to answer questions, especially if they are opaque from you:

Codex is also particularly tuned for token efficiency here.

All of these hard-to-articulate qualities add up to one thing: requiring new evals.

The problem with the negative first reactions around the GPT-5 launch is that most people had not actually used the model in anything real and just reacting to headlines and chart crimes. Those of us who had, myself included, had already gone through the adjustment and sentiment shift, and the GPT-5 Sentiment Flip predictably happened on schedule, just like it did with the o1 release.

The first idea I got immediately after the shooting the GPT-5 for Developers video was “we’re gonna need better vibe checks”. Everyone carries around their favorite spot checks - in our video, Theo did the Hexagon ball thing (and changed tune post release), Simon did PelicanBench, Ben of course tested writing and came back for his Latent Space hat trick.

But the thing I mentioned on the Dev video about GPT-5’s agentic coding abilities is very real: here’s the codebase I actually tried live in the video when we got access:

This was extra impressive because I had been stuck for literal months throwing dozens of hours of Claude Code at it to no avail, whereas GPT-5 “thought with tools” - instrumented the code, had me read back the logs to it, then found the solution.

That’s the problem with the social media pressure for the loudest most confident takes on new models the moment they release - you can’t just run simple one-turn, minimal-tool-call tests to gauge the vibes of the model (my quip is “you can vibecode any website you want, so long as it has blue and purple gradients”).

Even Aider’s polyglot benchmarks aren’t really testing agentic coding, by which I mean multi-turn, multi-step, thinking-with-tools coding agents on real codebases.

The solution was obvious: make a blind taste test of models on real live open source codebases on real tasks and have maintainers rate their performance!

So that is exactly what we did:

We will update this post later with the results of these tests.

In any case, as with all things Koding, Greg Brockman was the frontman driving this shift in OpenAI’s coding capabilities. I had the privilege of interviewing him for the World’s Fair, and in this newsletter issue we are recapping the OpenAI podcast released today and his Latent Space pod released last month - all collected in one place for those just catching up on the great OpenAI coding comeback.

Enjoy!

this episode was recorded and aired last month.

• Greg Brockman

• Turing Test Paper

• Kernel Labs

• ARC Institute

• GPT-5 Review

• GPT-OSS

• Dota (OpenAI Five)

• ImageGen

• LM Arena

• IMO Gold (International Mathematical Olympiad)

• IOI Gold (International Olympiad in Informatics)

• Dyson Sphere

• [00:00:04] Introductions

• [00:01:04] The Evolution of Reasoning at OpenAI

• [00:04:01] Online vs Offline Learning in Language Models

• [00:06:44] Sample Efficiency and Human Curation in Reinforcement Learning

• [00:08:16] Scaling Compute and Supercritical Learning

• [00:13:21] Wall clock time limitations in RL and real-world interactions

• [00:16:34] Experience with ARC Institute and DNA neural networks

• [00:19:33] Defining the GPT-5 Era

• [00:22:46] Evaluating Model Intelligence and Task Difficulty

• [00:25:06] Practical Advice for Developers Using GPT-5

• [00:31:48] Model Specs

• [00:37:21] Challenges in RL Preferences (e.g., try/catch)

• [00:39:13] Model Routing and Hybrid Architectures in GPT-5

• [00:43:58] GPT-5 pricing and compute efficiency improvements

• [00:46:04] Self-Improving Coding Agents and Tool Usage

• [00:49:11] On-Device Models and Local vs Remote Agent Systems

• [00:51:34] Engineering at OpenAI and Leveraging LLMs

• [00:54:16] Structuring Codebases and Teams for AI Optimization

• [00:55:27] The Value of Engineers in the Age of AGI

• [00:58:42] Current state of AI research and lab diversity

• [01:01:11] OpenAI’s Prioritization and Focus Areas

• [01:03:05] Advice for Founders: It's Not Too Late

• [01:04:20] Future outlook and closing thoughts

• [01:04:33] Time Capsule to 2045: Future of Compute and Abundance

• [01:07:07] Time Capsule to 2005: More Problems Will Emerge

Alessio [00:00:04]: Hey, everyone. Welcome to the Latent Space podcast. This is Alessio, founder of Kernel Labs, and I'm joined by Swyx, founder of Small AI.

Swyx [00:00:10]: Hello, hello. And we are so excited to have Greg Brockman join us. Welcome. Thank you for having us. Excited to be here. You need no introduction. So I was like mentally going to introduce you. I just get right to it. Congrats on GPT-5, GPT-OSS, like all the stuff that's going on in opening islands. Where are you going to get to all of that? It's really good to have you here. How does it feel? Last week was like a whole maelstrom of releases.

Greg [00:00:33]: releases. Wild. It was absolutely wild to get so many things out in one week. But yeah, so we've released our open source models, which are models that we've been working on for some time. I think really pack in a bunch of the advances that we've been making at OpenAI into a very small form factor, very accessible, now being used by, you know, there's been millions of downloads of that just over the past couple of days. We also released GPT-5, again, something we've been working on for a very long time. And so just having these out in the world and really having done that release process is something that I'm just really excited about. I'm just really proud of the team for doing.

Alessio [00:01:04]: And GPT-5 is the first hybrid model, so most people don't get to choose one model. And that's a whole other drama we will not cover. A whole other thing. But you started originally the reasoning team with Ilya at OpenAI. So maybe can you just give a quick history of reasoning at OpenAI? So you started with just, you know, next token prediction. And then at some point you thought reasoning was something important to build. What was the path from there to GPT-5 where now it's like kind of hidden from the user?

Greg [00:01:31]: Well, I'd say that. After we trained GPT-4, we had a model that you could talk to. And I remember doing the very first. We did the post-training. We actually did a instruction following post-train on it. So it was really just a data set that was, here's a query. Here's what the model completion should be. And I remember that we were like, well, what happens if you just follow up with another query? And it actually was able to then have a response that took into context the whole previous chain of question and answer. And you realize this thing can do chat, right? It can actually talk to you. It can actually use, leverage all of this information, even though it wasn't trained to do it. And I remember we had this question. We had a research meeting with a bunch of people, you know, Jakob, Ilya, Wojciech, others. And the question was, why is this not AGI? Right? This model clearly is not AGI, but it's really hard to describe why, right? It's like able to answer any question you put in front of it. And okay, it's not quite reliable. It makes mistakes. It falls off the rails. Okay. That's a real gap. And so what do we need to do to close that gap? And the most obvious thing you need to do is actually have it test out its ideas in the world, right? Actually do reinforcement learning, like try out some hypotheses, get some feedback and from there become reliable. And this is not a new idea to us, right? If you rewind to even 2017, we were working on Dota, which was all reinforcement learning, no behavioral cloning from human demonstrations or anything. It was just from a randomly initialized neural net. You'd get these amazingly complicated, very sophisticated, very correct behaviors. And it's like. That's the reliability we wanted for our language models. So really the moment we trained GPT-4, we knew that we needed to get to the reasoning paradigm. And it was just a question of how. So we had like 10 ideas, a bunch of different hypotheses about what might work. And people really set out to go and try to make it be reality. And so it was really the labor of many people at OpenAI across many years. And I think the way that this, the progress in this field works is you need to have conviction on a direction. Right. And the first 10 things you try will fail. And most of the things on that list of 10 did not succeed, but we made one of them work. And I think that that's the real key is that we just keep pushing and pushing and that you get little signs of life and you keep growing from there. And so now Jerry runs our reinforcement learning team and has made really great strides there. There's really amazing infrastructure work. People like Wenda, people from the inference side, people like Felipe, there's many people across OpenAI that all come together. And I think it's really important for us to be able to work together to really make this work.

Swyx [00:04:01]: Amazing. I was going over, you know, when you, when you were with me on the engineer conference, you talked about the Turing paper, which you love and got you started in some ways on your machine learning journey. And I think actually he kind of anticipated the learning machine would be partially online. You know, and I think like, that's one of the questions I always had when reflecting on this journey from like three, four to five, like is learning, like learning started all offline and like all pre-trained. And now it's slowly coming back. It's coming online. Do you think that's accurate?

Greg [00:04:31]: Yeah. I think it's a very interesting question, right? Where does the learning happen? And I think we're still not at the full kind of learning loop that humans do. Yeah. Right. Which it's also not really clear. Are humans fully online? Because it's like, you know, you go to sleep, like there's a lot of, of, you know, sort of back propagation, so to speak, that happens into your long-term memory. So I think that exactly how humans work is not necessarily mapped, you know, represented by how our machines work. But we are moving from a world where it's just, you go and build a machine, you build a machine, train once, and then you're inferencing a ton to a world where there's actually this loop of you inference and you train on those inferencings. And one thing that Ilya used to say a lot that I think is, is, is very, very astute is that when the models are not very capable, right, that the value of a token that they generate is very low. When the models are extremely capable, the value of a token they generate is extremely high. Right. It's something that's like very thoughtful. It's something that's, that's, you know, that's important. And reinforcement learning has this property, right, that you're generating a bunch of data because the model's trying stuff and then you train on that data. And so somehow the model's observations, you know, also normalized by contact with reality or, you know, somehow selected by, by contact with reality, get fed back into the machine. And that is, I think, something that we're starting to get very good at learning from. And the scale required is very different, right? That if you look at pre-training, your, your 10 examples of something doesn't go anywhere, right? You're talking hundreds of thousands of any little type of, of behavior. And then that's what you learn from, which is totally, totally unlike how humans learn. Again, I think, right, if you're, if you think about, recapitulate all of evolution and also think about your 20 years worth of developmental history, there's a lot of just observing the world that happens. There are lots of bits of information that kind of flow through, through your, your senses. But with the reinforcement learning paradigm, if you have 10 examples or a hundred examples of something, right, 10 paths that you're supposed to do, and the model tries a bunch of times that it's actually able to learn from that. And so you really get this leverage. And then you can leverage out of the human curator, creating those tasks and are able to actually get very sophisticated behaviors from the models. And now there's the next step of just having a model that as it goes, it's learning online. We're not quite doing that yet, but the future is not yet written.

Alessio [00:06:44]: We had this discussion with Noam Brown about simple efficiency. Do you feel like today the bottleneck is still the human data curator that creates these like great tasks for RL to work? Or do you feel like it's still the simple efficiency of the model?

Greg [00:06:57]: Well, the bottleneck is always computing. Right. And, and, and I mean that in a real way, right? It's just like, it's very clear that if you give us a lot of compute that we will find ways to iterate that actually make the most of that, that compute. We are in a world where right now we now have much more sample efficient algorithms, right? With, with the RL paradigm, but it does take a lot of compute still, right? It's like that you have like one task a human created or 10 tasks or a hundred tasks or some small number of those. And then you have a model that tries a bunch of times. Yeah. And then you have a model that tries a bunch of times, not just 10 times, but 10,000 times to try to accomplish one task and you select from those and you learn from, from that. And again, it's like the amount of human leverage you get as a human designer, there's extremely high, but the amount of compute that you have to pour in in order to make it work grows proportionally.

Swyx [00:07:45]: I would say like one way to expend more compute in the learning process, Alan Turing actually like foresaw a lot of this. He had this concept of super critical learning instead of sub-critical learning, meaning we present learnings to machines or teach things to machines. They learn just the immediate thing that we just taught. But super critical means you also think through the second and third and fourth order effects of whatever you just learned, like to update the rest of everything else that you know. So like what are the creative ways in which we spend more compute, right? Like if we had 10x more compute or a thousand x more compute, where does it go?

Greg [00:08:16]: I'll just say we will find ways to realize that. Please give us. But I mean it kind of seriously, right? The way that this works. Like if you rewind to something like Dota. We set out to develop new reinforcement learning algorithms because it was very clear to everyone that reinforcement learning, the algorithms that existed at the time, did not scale. Everyone knew it. And I remember Jacob and Shimon saying, why do we believe that? Has anyone actually tested it? And no one had actually really tried to scale up just plain old-fashioned PPO and say, well, that's the baseline. We got to do it. And I remember you come back to the office every week, they doubled the number of cores. It's only the agent. True skill was going up. It's up and to the right. And it's like, okay, you just got to keep pushing it until you hit the wall. And clearly we'll hit the wall and then we can go and do the actual interesting stuff. And we never hit the wall. And you realize that actually the journey of that scaling, that is the interesting stuff, right? Of really doing the engineering. And of course you have bugs and those bugs cause a wall, but you fix the bug, right? You have different issues with how your neural nets initialized or the scaling variance or whatever the issues are. But those are not the fundamentals of the algorithm of the science. And so I think that's kind of the world that we're in. Is one where it's like. We will push on every dimension and maybe we hit a wall. Most of the time, those walls are like just bugs and silly things. And so you can keep going. Sometimes the ROI for fixing those is really hard, right? So it's like, it's not really worth it because you have a different dimension, right? Do you want to push the model to be larger and do more pre-training compute, or do you want to do more RL? And so push more compute to the actual test time. And there's all sorts of dimensions that you can put compute into. And in some ways I think of compute as this, like, you know, we're doing this refining process. Ultimately start with energy. It turns into compute, turns into intelligence, and it's almost crystallizing that compute into the potential energy that can be converted into the model doing something useful. It's a really beautiful thing, right? It's like the compute as this like fundamental driver, this fundamental fuel of intelligence and sort of shapes a neural net, sort of outputs a program. And you know, of course the nice thing about that program is you can run it many, many times even though you put all this compute in that you actually have this amortization that you're going to use it far more times than the amount of effort you put into creating it once. And so it's just like a, it's a beautiful paradigm.

Alessio [00:10:27]: Yeah. You're kind of turning kinetic energy into potential energy in the model. And do you feel like the energy that it's already in this models, we can then turn back into kinetic to do our all in every other domain because we got the IMO gold. I mean, we in the, you, you guys, everybody, do you feel like those same techniques and the same base models can then get us to the goal? IMO gold equivalent. Yeah. I mean, if we just scale the compute or do you feel like there's still some work to do?

Greg [00:10:57]: Well, we have pretty good evidence on things like the IMO models actually also getting us a gold in IOI, which is just the same. Yeah. I mean, I think we did like, I think we talked about some of the details. There's a little bit of difference in the harness, but like the harness is not the gold literally. Right. It's like the actual underlying models and there's no training there that we did specifically. This ended up being just a side project of a few people are like, oh, we may as well do IOI. Right. And it's just a wild fact to me because that used to be something that would be a total grand challenge. You know, many, many people working on and I'm the core IMO team at OpenAI was actually three people. Right. Wasn't this massive effort. And so you realize that there's maybe some specialization required for some of these domains, right? Maybe some amount of additional work, some amount of go gather data set. But fundamentally we have this general purpose learning technology and that learning to solve hard problems is actually a very transferable skill. Learning how to solve hard math problems and write proofs turns out to actually transfer to writing program and competition problems. Now if you've never run a physics experiment, right, if you've never actually gone and tried to mix together some chemicals or something, you're probably not going to be magically good at those things. And so that there is something about the limitations of generalization, right, that you do need to actually have some real world experience and try it out. But these models, they go almost unreasonably far already. And we see this all the time. Where we have wet lab scientists. We have lab scientists who took models like O3, ask it for some hypotheses of here's an experimental setup. What should I do? They have five ideas. They tried these five ideas out, four of them don't work, but one of them does. And the kind of feedback we were getting on O3 was resulting work is something that could be published in a mid-tier journal, not the top tier journal, but a mid-tier journal. It'd be kind of the work you'd expect from some sort of third year, fourth year PhD student. And again, it's just a wild fact. That's where we are with O3. And we see exactly how to improve O3 on all dimensions. And it requires compute. It requires a lot of work. It requires getting the task. It requires a lot of human's intellectual love and labor and time and really pouring our heart and soul into it. But the result, to your point, it's like we produce the thing that has all this potential energy within it. And then the amazing thing is that you don't release that potential energy once, right? It's a checkpoint that you can use many, many times across all of these tasks. And that is something that I think really can uplift all of humanity. That's so inspiring.

Swyx [00:13:21]: I wanted to backtrack on two things. One about the wall. One thing I was trying to get into this debate with Noam on was I think there is a wall in terms of wall clock time because time has to pass. Like the problem with RL interacting with environments and simulation is sure you can speed up the simulations faster than real time. At some point you have to match wall clock time. So like, you know, you can see us converging towards like the pace of iterations towards wall clock time in terms of getting closer and closer to real time. And so I think that's a really interesting thing to think about. modeling the real world. I don't know if you have any thoughts on tackling that. Obviously, we're not there yet, so we don't have to worry about it.

Greg [00:13:57]: Yeah, I think this is a pretty fundamental barrier, right? And of course, the models have very non-human affordances, right? You can run many copies of them. And so you can scale out even if you can't decrease the latency. And it's also very interesting to think about where the compute goes, right? Because we're going to move from a world where most of the compute is training the model, as we've deployed these models more. You know, more of the compute goes to inferencing them and actually using them. But then if you think about, well, you're going to have these models that are going to be interacting with the real world a lot. And so they should probably think a lot about every single action, right? So you might end up with tons of compute spent per real world interaction. And so it really shifts around where you'd expect the compute to actually be expended. And I think that really having good harnesses that are very efficient, right? Do you think about things like, if I have been taking a bunch of steps in some rollout in the real world, how do I checkpoint that, right? And if you have a system that you need to restart it and it's going to forget all of its current state, like that's probably pretty bad. And so I think that there's just something very different about the digital world where everything can be perfectly observed and checkpointed and preserved, as opposed to reality that's much more messy and complicated. And I think it's not a bad thing, right? I think that we've seen agents with things like Dota that are able to operate in very complicated, very messy environments. So the algorithms are capable of it. And by the way, Dota was like a 300 million parameter neural net. Tiny, tiny little insect brain, right? Now we're starting to scale up to things that are much more comparable to human scale in terms of number parameters, maybe in terms of number of compute. We're not necessarily quite there. I think you could look at the math in different ways. But fundamentally, we are making progress towards the real goal. And if you think about what an AGI should be, it should be something that is capable of interacting with the real world in ways that are very productive. Yeah.

Swyx [00:15:51]: Back off the envelope. I think that the numbers I have in my head, you can correct me if I'm orders of magnitude off, but it's something like humans have 100 trillion neurons. We're in the multiple low double digit to high single digit range for GPT-4, 4.5, and 5, but we're not confirming that.

Greg [00:16:08]: But we're scaling there. Yeah. I'd say 100T synapses, which kind of corresponds to the weights of the neural net. Yeah. And so there's some sort of equivalence there. Yeah. And so we're starting to get to the right numbers. Let me just say that.

Swyx [00:16:20]: And then just on a biological basis, this is an opportunity I didn't even get to ask you last time on what you learned from ARC Institute. You had a sabbatical there. I'm curious if that informs anything that you do at OpenAI now.

Greg [00:16:34]: Well, the thing I found most remarkable about working on DNA neural nets is that they're exactly the same. Yeah. Right? It's just you replace human language. It's even like a simpler vocab. It is. Yeah. Yeah. You've got four letters.

Swyx [00:16:47]: But don't you tokenize at a higher level? Yeah.

Greg [00:16:49]: I mean, so you can. But actually, the way that we approach it, we just did- Character level? Character level.

Swyx [00:16:54]: No way. Yeah. Why not? Well, I guess there's no reason. I don't know.

Greg [00:17:00]: There's only four. Right. Right. Right. And this to me is, I think, the core. Like, one of the interesting things about human language is we understand the semantics, right? We kind of understand what it means, what the structure is. It's very easy for us to observe. We kind of have a sense of when you look at a tokenization scheme, you have a sense of did you capture, like, all of the words in a reasonable way and all this stuff. Biology, it's an alien language. And the thing that's very interesting is that, you know, for humans, it's an alien language. But if you look at a neural net, why should human language be any more natural to a neural net than biological language? And the answer is they're not. Right? That actually these things are both- Literally the same hardware. Exactly. And so, one of the amazing hypotheses is that it's like, well, these neural networks are neural nets. They can learn human language just fine. And so, they ought to be able to learn biological language just fine. And we really see the same kinds of results. Right? It's like, I'd say that maybe the neural net we produced, you know, it's a 40B neural net trained on, you know, like 13 trillion base pairs or something like that. The results, to me, felt like GPT-1, maybe starting to be GPT-2 level. Right? It's like accessible and applicable to downstream tasks across a wide range of biological applications. Not yet adjustable. Not a GPT-3 or GPT-4, not a GPT-5 for sure. Right? We're not able to solve super hard problems in these domains just yet. But we've got compute. We've got the right techniques and algorithms. Now we need to scale. We need to think about long context. There's different ways that the biological systems stress the models relative to language sequences. Like language sequence of a billion tokens doesn't really exist, but it does in your DNA. Right? You've got like 4 billion base pairs or something like that. So, you know, you kind of have some sort of different emphasis. But fundamentally, it's the same problem you need to solve.

Swyx [00:18:49]: Is there an application that you're most excited about, like drug discovery or obviously I think everyone goes to drug discovery, but maybe some intermediate thing before that that is reachable and very impactful?

Greg [00:18:59]: Well, I mean, at a personal level. So my wife, we've talked about this, you know, I've talked about this publicly before, has a genetic condition called Ehlers-Danlos syndrome. It's something that until very recently, I think we're starting to see. You know, genetic markers for it, but it's been kind of unknown exactly what causes it, where it comes from. And that is something where if you have better tools for understanding biology, you should be able to identify the markers for lots of different diseases. And so that's just like one example of the kinds of applications, the promise that exists within these neural nets.

Alessio [00:19:33]: How would you characterize the beginning of the GPT-5 era? If I think about 3, 4, 5 as the major versions, I think 3 is very text-based, kind of like, like RLHF really getting started, 4 is multi-modality and all these different low latency, long thinking with O3. What's going to be the 5 flagship thing? Obviously the year of agents, right? That's the meme. Yes. But is there something else that comes to mind that people should think about? Okay, with 5, now we unlock X. Yeah.

Greg [00:19:59]: I think it's smart. I think that the intelligence of these models is starting to be just almost undescribable, right? It's like, there's still limitations, there's still ways in which they fail. But it really is the case that for extremely hard domains, like look at the IMO results, right? So you can take a model that's been trained on this reasoning paradigm, and it's able to write proofs that is at the level of the best humans, right? And it's like, in this specific domain, there's limitations, et cetera, et cetera. We haven't proven like an unproven theorem, any of that stuff, but it's real. It's like, it's undeniable at this point that these models are able to perform great intellectual feats. And I think that's new, right? GPT-4, I think, was like much more, it was kind of capable and commercially useful across a wide range of applications. But the ideas that it produced were not very deep, right? The problems it would solve, it was not very reliable at. And I remember with GPT-3 actually trying to teach it how to do even basic stuff, right? That like, we kind of realized, hey, you could do this few-shot prompting, so you would kind of show it a few examples of something, and then it'll basically kind of do that task. And so I was like, okay, can you just teach this thing to sort a list? And I gave it like seven numbers to sort. It didn't sort it. I was like, okay. Then I tried to write a whole script of like, I'm a teacher teaching you how to sort numbers. Here's an example of sorting two numbers and then three numbers and whatever. And I'd be like, okay, now here's five numbers in total flop. If you ask GPT-5 that, and I've not even tried, by the way, asking GPT-5 to sort a list of five arbitrary numbers, but I am certain it will do a perfect job of it out of the box, no problem. By the way, it does have access to Python tool as well, so you don't have to do that. Are you going to say that?

Greg [00:21:40]: Well, I'm going to say that the thing that these models are capable of assisting humans in is something that we're just starting to see. We started to see it with O3, and you can see that professional mathematicians starting to kick the tires on GPT-5. We've seen physicists starting to kick the tires in GPT-5 and say that like, hey, this thing was able to get, this model was able to re-derive an insight that took me many months worth of research to produce. And that's the kind of thing where it's like, you realize this will speed you up. So fast, right? I remember doing my own math research back in high school and at the beginning of college, and I'd spend just like so long just trying to manipulate these objects in my head and think about connections between things. And if I had a partner that I could actually talk to about this, who would actually spend the time to deeply understand what I'm thinking about and produce new insights off of what I'm suggesting, that would have just sped me up so much. It would have been so much more fun, right? Because you don't just like kind of get caught in this loop of just sort of thinking about it off on your own and thinking, you're like, wait, I already thought this thought. You know, two weeks ago. And so I think that there's just something new about pushing forward the intellectual

Alessio [00:22:46]: frontier together as a partner with GPT-5. Do you think people are limited by the difficulty of the problems that they work on? I think like, you know, for me in Cursor and in Codex, it feels clear that the model is better when I give it hard tasks. I feel like a lot of people put screenshots on X and it's like, oh, GPT-5 is not that much better. It's like, well, the question is not that hard. Yeah. You know? It's about confidence. When you call it the best coding model in the world, obviously you're one of the best coders in the world. So the game recognizes the game. But for people, how should they really think about evaluating these models?

Greg [00:23:21]: Yeah. So there definitely is a saturation on certain tasks, right? If you're just going to chit chat and say, hello, how are you, there's only so many things you can say. If you're going to say, here's the rematter hypothesis solution, please. Okay. Yeah. There's like a broad range of intelligence that will be desirable there. Yeah. And I think that's what we've observed is that we've seen GPT-5 be able to solve intellectual problems, you know, sort of tasks that require deep intelligence much better than any other model that we've tested. The second thing we did was we really spent a long time seeing how are people using it in interactive coding applications and just taking a ton of feedback and feeding that back into our training. And that was something we didn't try as hard in the past, right? For something like O3, we really trained it with tasks that we'd set up once and the model, we'd see it go up into the right on all of our metrics. It'd be great at code forces, you know, competitive programming competitions, which is, again, very exciting, but it's not reflective of how you actually program. You actually program in a much more messy way, right? That you have some sort of repo that has some sort of local state and that it has different abstractions and, you know, that just like different versions of different libraries. And that sort of diversity. Yeah. Isn't something that magically arises from a very structured, here's this one specific task, 10 specific tasks you need to accomplish. And so a lot of what we've been focusing on is saying not just how do we push the intelligence, although that is always going to be the core, but also how do we connect the intelligence to real world applications? And so that it really got to experience being pushed out of its comfort zone, out of its ivory tower, and actually be able to see the messy reality and diversity of the real world. Yeah.

Alessio [00:25:06]: What are suggestions on a more practical level that you have on getting the potential energy out of these models? So part of it is adding, you know, the linter, the type checker, the task to like have it self-loop. Any other meta that developers should think about? How do you use the models? Yeah.

Greg [00:25:21]: Well, the number one thing that I've observed is that there is a real skill in extracting the most from these models. And it requires this tenacity, right, of really trying to like almost understand the shape of the model skills and weaknesses. And so you test it, right? You test it with something small, you get a little feedback, you test a little bit higher, try to give it some bigger tasks, try to see if it can work in a certain way. And I think that people usually have their library of different prompts, right? So I definitely have my library of prompts that I've built up since, you know, the GPT-4 days. Like I remember in advance of GPT-4, starting to gather up a couple of like, okay, I wonder if I'll be able to do this. You know, you have some sort of, you know, query that, importantly, you want queries that could have a range of different answers that don't have any one. One specific right thing. And so for example, on creative writing, I've liked to ask for like a mashup of Lord of the Rings and startups, right? Just like try to push together two different topics and see what you get. In terms of actually testing the model and pushing it, I think that I do a lot of trying to think about, okay, like how do you, first of all, break up tasks and have something that's self-contained that you can let the model run with? Because you don't want to just have one instance of the model operating. You want to have multiple, right? You want to be a manager of not an agent, but of agents, right? And so that you need to, first of all, think about how your code base is structured, but then actually go and try to push the model to say, can you actually operate it on, you know, these multiple different pieces of your code base? I think that people love doing front-end five testing. GP5 is very good at front-end, it turns out, but of course that's not what most developers spend their time doing. And so it's important not to overfit to that, but I think that maybe just getting a feel for the model and kind of starting to become in tune with its strengths and weaknesses, and viewing it almost as a tool. Also, an extension of yourself and know, you know, like often, another thing I'll do is just be kicking off tasks to the model that are sort of not on the critical path, while I'm thinking about some super hard thing that the model, for whatever reason, I don't want it operating on. And so I'm just constantly getting information back on just like, okay, was it able to do a thing? Or just like low risk if it like makes a mistake, because I don't feel like I had to sit around waiting for five minutes and then, you know, sort of get no, no return.

Swyx [00:27:30]: You've always mentioned that I think that there, the roadmap for Codex and opening as coding capabilities. Since we're there, is that the background sort of SWE agents sort of merge with the NIDE agents. How's your thinking involved there? Like, is it just as simple as like the IDE can call the background APIs and the background APIs can sort of export to the IDE? Or what's a deeper connection in that?

Greg [00:27:50]: I tend to think about AI productization by analogy to a coworker. What do you want out of a coworker who's a great programmer? Right? You don't... Slack them. Yeah, exactly. So you want to slack them. But sometimes you're like, hey, I kind of need help with this thing. Can you come over and look over my shoulder? Hey, program. Right? And like, hey, can you take the keyboard? Exactly. So you want the pair form factor. You also want the remote async form factor. And you want it to be one entity that has knowledge and memory across all of this. You don't want it to be a junior programmer who shows up every day being like, okay, I forgot everything. Can you remind me how to SSH into the whatever? Right? So I think all of that has to happen. Right? That you need AIs that have access to your infrastructure in a trustworthy way. Right? A way that you can audit. Like, one thing that is different about these models is that they're fine being micromanaged. Turns out humans don't like that very much. Right? If you look at every single command that they're running and you, like, demand, like, reports on everything they did, probably you're not going to retain that person. But the models are perfectly happy to. Right? And so that's an affordance that's, like, well worth thinking about and changing the interfaces to take maximum advantage of. At the same time, yeah, you really want the seamless blending between a model that's able... Yeah. ...to do a bunch of work on its remote machine, doesn't mess up my local state, fully sandboxed, fully observable, and then sometimes can be like, okay, I'm ready to run something locally. And that depending on what that is and depending on how sandboxable it is, that you can do one-off approvals, you could give it full delegated access. And I think that having the human be in control of this observability and to be managing this team, an agent that has just different surfaces. Right? It doesn't... Like, the identity of the agent being something that runs locally versus the identity being something that runs remotely. To me, that's the wrong question. It's really the agent should be this, like, model that's executing and then requesting to run things in a remote sandbox or locally or maybe multiple sandboxes. Or maybe it's running on your computer and my computer.

Swyx [00:29:53]: Like, there's no reason that it has to be local to any of these things. Software agents, you can just sort of seamlessly and fluidly move around. You mentioning approvals gives me a chance to spotlight my friend Fuad, who is helping this team. Sorry, the agent robustness team that was also launched at AI Engineer. What's that? What's opening his interest in that?

Greg [00:30:11]: The way we think about agent robustness is through defense in depth. There's a layer of the model itself. We publish techniques like instruction hierarchy. And so with instruction hierarchy, you sort of indicate that, hey, there's this message is from the system. This message is from the developer. This message is from the user and that they should be trusted in that order. And so that way, the model can know something that says ignore. Ignore previous instructions from a user. I'm not going to follow that. Yeah, right. And so I think that having like, it's almost like thinking about how we prevent SQL injections, right? Having systems at a low level that are robust against these attempted exploits is very important, but that's not where you stop, right? You want multiple layers of thinking about the system controls, right? If a model is sandboxed and isn't actually able to execute something or access a specific piece of data, then you have full guarantees around what's possible. And there's, you know, various levels in between of approach that we take. And so I think that a lot of what is the frontier as these agents get become more embedded in our lives and are trusted with more responsibility is also increasing the safety and security of them in lockstep.

Swyx [00:31:19]: There's an analogy that I made to like the Linux kernel OS rings as well. And it's really interesting that we're basically kind of building this in to the LLM as like concepts of sort of different layers of security. And also the other thing I also was. Very happy to see was that I invited a talk on the model spec for AI engineer, and that was the most viewed talk of all of that we've ever had, which, which is like, it's very, it's hard to make safety and reliability sexy.

Greg [00:31:48]: I think the model spec is a perfect example of when the models are very capable, you start to really care about what they're going to do. That becomes the most important question. And the model spec is an example where we've made it very legible. To the outside world, what our intention is for this model to do, and it doesn't mean that we always produce a model that is capable of following that, but it's a north star, right? It's something that really sets. This is the intention and anything that deviates from that is not through our explicit effort. It's anti to our explicit effort. And I think that the gap between the spec and the actual behavior is shrinking very, very constantly. The thing that's very interesting is almost like values, right? It's really thinking deeply about, well, what should a model do if you ask it a controversial question? Right? If you say, I think that the world is flat or whatever, like, is it supposed to say, yes, it's flat? Or you're supposed to be like, well, like, here's what science says. And honestly, these things are subtle, right? That it's not really clear what the right thing is just on, you know, two minutes of thinking about it. But if you read the spec, you can actually really see the thoughtfulness that has gone into it. And it's not the final answer, right? It's something we want feedback on. It's something that we want to produce collectively as a community.

Alessio [00:32:55]: I know we want to talk about open source next too, but I had a more esoteric question. I was listening to your old Lex Friedman interview. And you kind of mentioned, um, back in the day, back in the day, foundation, but Asimov, it made me think about, we have Brett Taylor on the podcast and we talked about how certain languages have inherent capabilities, like rust is memory safe. And so that just happens. Do you see almost like a cycle history of LLMs of, and software engineer where it's like, Hey, these models, I can predict the way software is going to look like everything is going to be blue and purple gradients, right? We're kind of seeing that today. What else are these models really driving us to work? And is there a way that we can change that?

Greg [00:33:36]: Well, there's definitely a cycle history of them because to some extent, these models are a product of cycle history, right? It's like these models have been trained on observing human thought, right? Effectively. That's what you can think of. Take public data, learn on that and just observe. The point is to understand the rules that govern a data set. Like what are the underlying rules that generate the data in the first place? And that's kind of what these models grew up on, right? It's almost like watching a bunch. It's a TV as an alien trying to figure out like, what are humans all about? And then you have this reinforcement learning phase where they actually got to try things out and there are given positive and negative feedback, depending on how much that aligns with what the human wants. And now we put them in reality and say, okay, now try stuff. And here's new tasks you've never seen before. And it uses all of that previous history to decide what to do. As an aside, like it's not clear. Like sometimes the biological analogy, the human. It's very easy to overstate it, but it's also easy to understate it. I think it is at least a useful template to think about to some extent. That's how humans work too, right? It's like you have some sort of prehistory encoded into your DNA. You have your life experience. You have your parents who provided positive and negative rewards. And you have your experience in just trying things out in reality. And now you have to go out and use that knowledge. And what do you do? And how do you predict what a person's going to do? And actually, you can predict a lot of what a person's going to do. It turns out you have a pretty good model of other people and how they'll react to something, if they'll like it, if they won't like it. And a lot of that gets baked into knowing someone's values tells you a lot about what they're likely to do and how they're likely to behave. And I think that for models, the future is not predetermined. It's not like the algorithm itself says that the model's going to have to prefer purple gradients or something, right? But there's something in this whole process that does produce that preference. And I think one of the opportunities with models, one thing that Alec would like to say is that these models are less like a human and more like a humanity, right? That there's so many personalities embedded within them. It's almost every single personality is in there. And our goal is to elicit that personality. And some of this post-training work, some of this reinforcement learning work almost narrows down the space of those personalities to just the ones that are desirable. And I think that what that means is that we have both an opportunity to produce models that operate according to our values, right? According to, if you don't just want the purple gradient one, you want the blue gradient, the green gradient, whatever. You can have all that in a single model. It's fine. And GPT-5 itself is extremely good at instruction following. And so it actually is the most personalizable model that we've ever produced. You can have it operate according to whatever you prefer just by saying it, just by providing that instruction.

Swyx [00:36:24]: The analogy I have is like the Borg. Like there's this like collective intelligence. There's always this debate between Star Wars people and Star Trek people, like who has a better model. And I think it's like Star Trek.

Alessio [00:36:35]: Well, Sam picked, you know, he tweeted the Death Star. So you're on the Star Wars team now. Yeah, what was that? What was that? You'd have to ask them.

Greg [00:36:44]: One thing I think is very interesting about these models is that we have all these arenas now, right? Like LM Arena and others where you can actually see human preferences on top of how the models operate. And that you almost have this layering of like the models were trained on human preferences. Now they're doing stuff and being judged by humans. And then we kind of use that to feedback on like, huh, like, okay, yeah, maybe the purple is a little bit too much and we should change it there. And so it's almost this co-evolution of the models move in a certain direction. Do humans have a certain set of preferences? So then we move them in a different direction. And then, you know, you kind of keep iterating to get something that's more and more useful and aligned with human values.

Alessio [00:37:21]: How do you do that when the RL rewards are kind of tied to things that the humans maybe don't prefer? Like in my experience, it's been like try catch, like the models like to write try catch so that it doesn't fail. Do we need just a lot of preference data that shows them they shouldn't do that? Is there something in the RL environments that we're going to change to make the less desirable? Like I'm trying to figure out where we go from here.

Greg [00:37:43]: Yeah, I think that the way that you decide or the way that you figure out where do interventions go is very multifaceted and it's very specific to the behavior, right? There are some things like the model's knowledge of different libraries and things like that that's kind of baked in from the early days. But you can also teach the model that, hey, don't rely on your previous knowledge. Like go and look up the most up-to-date docs. And that's something you can kind of put at a higher level. And then something like overusing try catch, that's something you can actually prompt the model for, right? And that's something where when we train it in reinforcement learning, you can provide rewards saying like, ah, don't go in this direction. And the beautiful thing about these models is it feels like, okay, there's probably a long list of different preferences and different styles and things like that. You're going to have to give it feedback on during training if that's the way you want to go. But these models generalize. The algorithms that we have generalize. And that's the beauty of deep learning. That is the true magic, right? It's very easy. Like we kind of have this whole stack now that's built up around the core of deep learning, right? It's like all these ways of orchestrating models and how you get feedback and all of these things, the data, et cetera, et cetera. The core magic of deep learning is its ability to generalize. And in some ways, the generalization is weaker than you'd like. But I think that the same is true for these models. It's really trying to think about in order to get them to be able to operate according to different preferences and values. We just need to. Show that to them during training and they are able to sort of generalize to different preferences and values that we didn't actually train against. And that's something that we've seen very consistently across different model generations.

Swyx [00:39:13]: I was just envisioning this meme of like, oh, my model doesn't generalize and we'll just make the whole world your distribution. You know, that's how you solve everything. Done. Done. Exactly. As simple as that. You know, you just have to build the Dyson sphere along the way. One thing I wanted to touch on for the I think last kind of last couple topics on GPT-5 before we move to OSS. Mm hmm. Do you acknowledge that there is a router? Mm hmm. Which is really cool. I was also listening to your podcast with John Collison on Cheeky Pints, which is which is really fun format that they say that you told a story of the Dota side that I don't think I've heard before about the beta model versus like the sort of main model and stitching it together. Is that like a similar insight for GPT-5's router where you have like reasoning model, non-reasoning, and then you just stitch it together?

Greg [00:39:56]: To some extent, yes. Right. I'm in the multiple models and you put some sort of router on top of them, that specific one. Right. And the reason why that was was for a very specific reason, which is that we had a deficiency on the first, you know, half of the game and. Because it kept losing, right? Exactly. Right. So there's like there was part of the game that this specific model didn't do a good job of. There's a part of it that it did. And there these models, the behavior, the domain they were operating in was simple enough. It was very easy for us to say here when you want to use one model versus the other. And to some extent, what we have with GPT-5 is no different. Right. We have a reasoning model that we know is good for applications. There are applications that require this intelligence, but you're OK waiting a little bit longer. We have a non-reasoning model that is great for applications where you want the answer fast. Still a good answer, right? But not like deeply thought through that might have a lot of tricks to it. And then you just kind of want to put an if statement that says which of these it should be. And then sometimes, too, it's like, you know, if someone's run out of their credits that you want to fall back to a different model and all these things. And not pushing that burden to the user is actually a really nice thing. And by the way, I do want to say model switchers are not necessarily the future. Right. They are the present, like having a fully integrated model that just does the right thing feels very preferable in many ways. The flip side, though, is that I think that the evidence has been away from having the final form factor, the AGI itself being a single model, but instead thinking about this menagerie of models that have different strengths and weaknesses. And I think that's like a very interesting finding of the past couple of years. Right. Just a direction of like it's much easier to have small. Small, fast model that's less capable, but can just do a lot more. You can generate a lot more tokens from it, coupled with a much more expensive reasoning model. And if you combine those two things, you kind of get adaptive compute and that we haven't really cracked. How do you do adaptive compute within the architecture, but doing it within the orchestration of a system? It's very straightforward. And so I think you get a lot of power out of the fact that these models are composable in this way. Yeah.

Swyx [00:41:58]: I want to give whoever did the model card was amazing. They even provided. The big parameters to the if statement of conversation type, complexity, tool needs, explicit intent and usage rate limit, which is kind of interesting. Any any one of those you want to comment on in particular that was interesting for debate?

Greg [00:42:15]: No, I mean, I think I think honestly, all of it is like fairly what you'd expect. Yeah. And I think that the core the core message in my mind is that at OpenAI, there are many things you've done right. Naming is not one of those. Having a simple surface for users. To understand how to use it, not necessarily one, right? If you look at all the different models that we've had, how are you supposed to know which one to use? I remember my wife was using 4.0 at one point. I was like, no, you need to use O3. And she's like, wait, but why? The number is smaller. O3 is better than 4.0.

Swyx [00:42:49]: Well, ship O4, then you have 4 and O4. There you go.

Greg [00:42:51]: And so, yeah, so, OK, we clearly needed to do a reset, right? A reset on complexity. And I think that us internalizing that complexity rather than pushing it to the user, that is really important. And so I think this is a first step, like, and I think we've heard loud and clear from the community about the places where they weren't ready, right, that we were not delivering on that simplicity for people, right, that it should just be, it's always better to go with our choice of it rather than, you know, the manual selection, and we're not quite there yet. I think that we can make the progress, but I think that ultimately our goal should be to both make sure that power users are able to have the kind of control and consistency that they're looking for, while also not forcing. And we're not going to be forcing the broad base of people who don't want to have to think about the 4.0, O3, all that stuff, to have to go to that level of detail.

Swyx [00:43:40]: Yeah, awesome. Pricing question. We talked about that GPT-5 pricing is aggressive and very competitive, even compared to, like, Gemini. One thing I was surprised to learn from the meetup that we had the other day was that GPT-5 pricing can go much cheaper. What degree of order of magnitude are we talking? How much percent of that is just getting better in front of, like, Stargate?

Greg [00:43:58]: I think that the answer for these things is always that, OK, if you go to Stargate, you're going to get better. If you look at the history of our pricing, we have very consistently cut prices by, like, I don't know the exact factor, but let's say, like, 10x per year. I'd say more aggressive than that, yeah. Probably more aggressive than that, which is a crazy thing, right? And you can see it with O3. I think we did, like, an 80% price cut. And actually, the usage grew such that it was, like, I think in the revenue, it either was neutral or positive. And it just shows you that I think there's this cost curve. Like, the demand is extremely high. It's extremely steep, right? And so it's like if you just make it more accessible and available to people, they will use way more of it. And I think that's very aligned with our mission, right? Our goal is to ensure that AGI benefits all of humanity. Part of that is making sure that this technology is broadly distributed, that lots of people are using AI and using it to apply to things in their life and their work. And one of the things that helps us get there is by having more efficient inference, having cheaper models, all of these things. Now, what unlocks it partly is having… Right now, we are extremely compute-limited. And so I think that if we were to cut prices a lot, it wouldn't actually increase the amount that this model is used. We also have a lot of efficiencies to gain. And that's something where our teams are always working super hard to get to the next level of inference efficiency. Some of this is about improving the model architecture itself, right? That there's lots of architectural decisions that you can make. And that now that we're in this world of reasoning, that it's not just about the sort of model architecture. It's also about the post-production. It's training, right? It's about how long does it think for a specific task and things like that. And so there's just many, many dimensions of improvement that we have to make and that we'll keep pushing.

Swyx [00:45:41]: By the way, the numbers… I have a chart for this if you ever need it. It's since the day you launched GPT-4. It's been a 1,000x improvement in cost for the same level of intelligence.

Greg [00:45:51]: That's pretty wild. That's pretty wild. That's pretty good. Yeah, that's like two and a half years or something like that. What else has like a three-order magnitude improvement over the course of two and a half years? I don't know. Nothing. Nothing. Can't think about it. Yeah.

Alessio [00:46:04]: And it's going low. It's not even… It's like from $10,000 to like $1,000. It's going to like pennies. For the GPT-5 release, I did this article called Self-Improving Coding Agents. So I basically asked GPT-5, can you build tools for yourselves to be a better coding agent? And this is a Swy Lancer task. And then it does the task. It kind of fails in some ways. And then I ask it, can you improve the tools for yourself and kind of do this loop? And what I found is like… Like the models don't really like to use these new tools that they built for themselves. They're busy responding, you know, I can just do it. I don't really need the tool. And I think there's kind of like this… Sounds like a human. Yeah. There's kind of like this feeling of like, how can they really push themselves to like improve? Do you feel like part of it is like, hey, they're just being taught to use these tools, which is like, you know, graph and like whatnot. And so it's kind of hard for them at inference time to build the tools? Or do you see this as like part of that jump?

Greg [00:46:58]: I think that's good. I think that's part of the… Yeah, for sure. Right. And I think it's not like we're at zero on being able to do that. Right. And I think a lot of this is just about the training, right? If the model really has trained with just a specific set of tools, hasn't really been pushed to adapt to a new tool very quickly, then you shouldn't expect it to do any differently at evaluation time. But the idea of producing your own tools that make you more efficient and build up a library of those over time in a persistent way, like that's an incredible primitive to have in your toolbox. And I think that if your goal is to be able to go and… Yeah. …solve these incredibly hard challenges, unsolved problems, then I think you're going to need that kind of thing as a dependency.

Swyx [00:47:36]: Any architectural decisions or innovations that you would like to talk about? Sliding window attention, the very fine-grained mixture of experts, which I think DeepSeek popularized, rope, yarn, attention sinks, anything that, you know, I think stood out to you in the choices made for GPT-OSS?

Greg [00:47:53]: I would say that these choices are all, you know, look, we have a team that's been working on different architectures. We've explored different things. Something like mixture of experts is something that, it's funny, I would say that I would credit our team for the choices there. But I say that the picture in my mind is we wanted something that would be easy to run in these environments. And so picking things like just how sparse to go is very tied to your memory footprint. And then, you know, how much compute you actually can use for forward pass and things like that. So I think that to some extent, the architectural decisions, we're fairly constrained by the model sizing and the compute we expect for them to have access to it when they're running. Yeah.

Swyx [00:48:37]: I mean, it's very practical engineering decisions, really. Yeah.

Greg [00:48:40]: Yeah, I think so. And I think that the power of the model really shows, like, we really did use a lot of our cutting-edge techniques to actually push the capabilities models further and further.

Swyx [00:48:50]: I'd say it definitely detects a difference between the architecture for models designed for API use versus models designed for single machine. You know what I mean? Like, when you have multi-tenancy, when you can have batching, it's very different from, like, single machine. Very different. Yeah. I don't know if that'll ever combine, but maybe it's a menagerie model, like you always say. Yeah.

Greg [00:49:11]: I think it's also really interesting to think about an architecture where you have a local model that then delegates to a remote model sometimes. Right? And this can be something where you can run much faster. It's helpful for a privacy architecture perspective that just trying to decide what actually goes, what stays, and having that edge compute. It means that then you lose internet connection, you're still able to do something, and you can have a slower planning model. It's like, this interplay between those things is very interesting. Yeah.

Swyx [00:49:38]: So, like, a GPT-5 on-device where you have GTOS-S here, and then it routes to online if it's available. I don't know.

Greg [00:49:46]: Yeah, something like that. And then you have your Codex infrastructure that has a local agent and a remote agent, and then is able to seamlessly interplay between the two, and then is able to do multiplayer. Like, this is... This is what the future is going to look like, and it's going to be amazing.

Alessio [00:50:03]: And then you have a device, always with you. I can see. I can see where things are going. It all connects. Yeah.

Swyx [00:50:09]: What can we say about the device? You raised it. I don't want to get Greg in trouble. What can we say about the device? It's going to be great.

Swyx [00:50:18]: Okay. And then another political... I don't know if it's political or not. You know, there's a lot of open models coming out from China. Why is it important for there to be American open source?

Greg [00:50:28]: Another thing. Something at a very practical level that we've thought about with open source models is that people building on our open source model are kind of building on our tech stack, right? If you are relying on us to help improve the model, that you're relying on us to get the next breakthrough, then that means that you actually really have a dependence in both a way that's good for our business, but I think is also good for the country, right? That you think about having an American tech stack from the models that people are running directly, but then how those are going to interface and interplay in the way that we just... That it actually allows us to build a whole ecosystem where people are able to have, you know, control over the parts of it that are important to them, ultimately be built on these models that reflect American values, and then be able to interplay with American, you know, hopefully chips underneath and cloud models on the backend and execution environments and all of that fitting together is something that I think it adds a lot of value. And I think it allows for American leadership to really also mean that... That we have leadership in our values in the world. Yeah.

Swyx [00:51:32]: Congrats on launching that. Thank you.

Alessio [00:51:34]: Let's talk about engineering at OpenAI. I know there's a lot of debate about cloud code and AIDR and open code and all these different tools. How do you think about structuring the team itself that gets the highest leverage out of this? Are you changing the way you build the team from a numbers perspective, from a, you know, capabilities perspective, from a team size perspective within the org, anything that you want to share? Well, engineering...

Greg [00:51:58]: Software engineering is... Is definitely changing in many dimensions. There's a part of engineering that's very difficult for these models to really crack, but we're starting to see the beginnings of it happening. And that that's these, like, very core, hard algorithms, right? Things like CUDA kernels are a good example of a very self-contained problem that actually our models should get very good at very soon. But it's just difficult because it requires a lot of domain expertise, a lot of, like, real abstract thinking. But again, it's not intractable. It's self-contained. It really is the kind of problem that is very amenable to the technology we have. There's other problems that are very difficult in terms of architecture, right? How do you think about how a system should be put together and thinking about the abstractions? And again, our models are starting to get kind of good at this. But so I think what we've seen is that there's, for most of our engineers, even our extremely good engineers, there's a lot of their work that actually maps very well to the core strengths of the models right now. And definitely for anything where it's, like, a language that you're not an expert in, like, yeah. You definitely don't want to be writing that code yourself. You really want a model to be doing it. And then there's parts of the job that become much harder because it requires, like, you know, things the models don't have access to, right? It requires a lot of context going and talking to people in order to make good decisions. And so I think we're not at the point yet where we really see changes in how you structure a team because these tools exist. But I think we're at a point where it is, like, an extreme high priority to get these models to be used in all domains that they possibly could be. And to think about how you structure a team. And to think about how you do that well and responsibly. And think about what the guardrails should be. And that that happens in a very practical way. And so I think a lot of what I'm seeing is, like, we're in an early adopter phase that's starting to transition to a mainstream phase. And the productivity impacts of people being able to do more means we actually want more people, right? It's, like, we are so limited by the ability to produce software. We're so limited by the ability of our team to actually clean up tech debt. And go and refactor things. And if we have tools that make that 10x easier, we're going to be able to do 100x more things. And so I think that there's this incredible opportunity that is entailed by these models not being a real driver of just do the same stuff more efficiently. But be able to do way more. And that that is, I think, the overall goal. Yeah.

Alessio [00:54:16]: How have you changed the team's work to fit the LLMs better? Is there a different way in which you track issues? Is there a different way in which you structure code bases?

Greg [00:54:25]: So I think we're still at the early edge of this. But the thing I've seen be most successful is that you really build code bases around the strengths and weaknesses of these models. And so what that means is more self-contained units have very good unit tests that run super quickly and that have good documentation that explains what this module is for. And if you do that and you kind of leave the details to the model, it works really well. And then thinking about how these things compose and making sure that you're thinking about the dependencies that you only have. These like clean like AI optimized modules can only be depended on by other AI optimized modules. Then you end up with like a whole system that's actually optimized. And so I think that we're still scratching the surface of what's possible. And, you know, the models are advancing so fast that actually what it means to work around the weaknesses of the model in six months. I think that those weaknesses will be like, you know, vastly shrank. So you don't want to necessarily spend all your time just over overfitting to what exists today. But I think there's a lot of potential. Yeah. To be able to move quickly in this in this particular moment.

Swyx [00:55:27]: One question I'm very curious about is the value of an engineer, you know. Increasing over time. Increasing over time. Well, I mean, also, you know, there's some part of our work that's being automated away. And I think like obviously there are very, very high signing bonuses, like higher than we've ever seen in the history of our industry. Is it really the engineers that are valuable or the systems that enable them? You know, like I feel like it's kind of like a bit of both, but people are paying a lot for the engineers.

Greg [00:55:53]: I mean, I think that the thing at the end of the day that is new, right, is that we are producing technology. These models that are the most useful tools that humanity has created. Right. And that underpinning them, we are building the biggest machines that humanity has ever created. Right. It's like at some point the dollars that go into these data centers starts to be an abstraction. Right. What is $50 billion? What is $100 billion? How can you possibly internalize what that is? I think it's beyond almost the scale of human comprehension. The engineering project that we collectively as a country, as a society, as a world are undergoing right now. Right. It's like projects like the New Deal like pale in comparison. You know, the Apollo program pale in comparison to what we're doing right now. And in many ways it's as it should be. Right. Like the economic return on this technology is very large. But even more importantly, the way in which we are moving to a new economy. Right. An AI integrated economy, an AI powered economy. And this is ultimately what our mission is about. Right. Is it's like we see this change on the horizon. We want to help. We want to help steer it to be something that uplifts everyone. Right. That it's this amazing opportunity, almost unique in human history. And we are all fortunate. Right. To be at this moment in time and to be able to be involved in some way. That to me is the backdrop to really think about this big shift that is going on at humanity scale. And it's sometimes almost you feel this cognitive dissonance because you're debugging some low level CUDA deadlock or you're worried about the purple gradient. And you realize this is like the future of humanity that we're really talking about. And so when you think about engineers and who's at which company and all these things like these things matter. Right. It's like it's not just about any individual. It's about a team. Right. But it's also not about any one product or any one system. It's really about the overall society, the overall economy that we are building together. And so I guess I sometimes step back and think about the big scale. But you also need to think about the micro scale. You need to think about are people happy. Right. Is do people feel connected to the mission? Do they feel like the work they're doing matters? And those things actually turn out to be the most important things. And so what makes the headlines is not necessarily the stuff that actually matters. It's the stuff that actually most drives the people. But it is for sure like a like a reflection of the economic reality that people see as the potential of this technology.

Swyx [00:58:21]: This connects a bit with what Noam was saying on the multi-agents team where like the individual intelligences of humans, you know, we can only do so much individually. But as civilizations, we can, you know, go to the moon and like to build cities and build AI. And like together, I think I think we can do a lot more than we can individually.

Greg [00:58:40]: We can do amazing things together.

Swyx [00:58:41]: No question.

Alessio [00:58:42]: What do you think about the current state of AI research? Is everyone really just doing the same thing? Do you feel like every lab is like a different take that is eventually going to help us converge to the right thing? Or just because now the dollars has gotten so big that you need to do the thing that you think is going to work?

Greg [00:58:58]: I think there's a surprising amount of diversity in the field. I think sometimes it can feel like there's convergent evolution. But I think that if you really talk to people at different labs, you really realize that there is different perspectives people have. You know, one of the decisions we made early on in OpenAI was that we really wanted to do something different. We really wanted a set of people who are aligned in how they think, right? Because for people who have been pursuing a PhD for a long time, who are, you know, sort of have their own research vision, you kind of can't tell them what to do. And so if you want people who are going to row in the same direction, it means you have to select that set of people. And that was, I think, the most maybe important early decision that we made at OpenAI that helped us to achieve the things that we have. And so I think that that means that you necessarily have different views. You have different vectors that you could pick. And you really see it in the taste of different labs and what they focus on, what they produce. And at OpenAI, I think we've been very much focused on how do you do the research that gets you to the next level? And even for something like GPT-5, that, you know, we sort of had a lot of pressure to think about, okay, let's just like, you know, sort of do the grind of like, you know, here's feedback on problems that we have on the coding side. And, you know, you can pursue that grinding and get somewhere. But you also sometimes have to step back and think about, you know, how do I do this? And think about how do you do the next step function? How do you do the next paradigm shift? And something like the reasoning paradigm is a good example of a time that we did that very successfully. And we've done that many times over the course of OpenAI and we'll continue to do that. And so I think that the breakthroughs remain to be made. And there's such a diversity of multimodal and different ways you could generate things and all of the stuff that I think that the field of research is more abundant than it ever has been.

Swyx [01:00:39]: Yeah. And not to forget, that's like the mainline research. There's also voice. There's also image generation, video generation. Yeah. Yeah.

Alessio [01:00:47]: It's easy to forget about these things. Remember Studio Ghibli? It was like the biggest thing in the world. Exactly.

Greg [01:00:51]: And it's amazing. It's amazing. And that's the kind of thing, by the way, that was like, there's really a team of a small number of people who are really focused on that problem for multiple years. And that that is, I think, the sort of core ethos of OpenAI is to make these long-term bets on problems that matter in a direction that really adds up. To a cohesive whole.

Alessio [01:01:11]: So from the outside, it's kind of hard to figure out what you're focusing on. You know, kind of Imagen just came out of the blue almost, which was great. Got a lot of adoption. How should people think about how you prioritize versus what people should explore and build and should wait for you to improve on?

Greg [01:01:27]: Well, there's a massive possibility space in this field, right? Because neural nets, deep learning is applicable to effectively any sort of data, any sort of domain. And that we can't do everything. The core reasoning paradigm, that clearly is something we're going to keep pushing on. Multimodal voice, things like image generation, video generation. These kinds of areas are also things that we view as very important and all kind of fit together. But there's been areas where it's just hard for us to really figure out how do we prioritize as part of the core program, right? And we've been through times where, for example, robotics was one in 2018 where we had a great result. But we kind of realized that actually, like, that's not going to work. Like, that we can move so much faster in a different domain, right? That actually, you know, we had this great result with a robot hand solving a, you know, unscrambling Rubik's cube. And that team was bottlenecked by the fact that this robot hand, you could run it for 20 hours before its tendon would break. And so then you would have a mechanical engineer come and fix it. And that team went on to go do what became GitHub Copilot, which is obviously an amazing feat and a real accomplishment. And something that they were able to move so much faster in. In the digital domain than in the physical one. And so I think that for us, we really try to, we have, you know, no matter how many people we hire, how many GPUs we get, we have limited bandwidth, right? That we are, you know, sort of one company, one lab that's focused on, as much as we can, a coherent one problem. And so I think that you can kind of look at the set of things we're doing and sometimes we'll do offshoots and sometimes that will be something that then becomes part of the core program. But that there's just so much possibility space for everyone. Awesome.

Swyx [01:03:05]: I'd like to take a chance, you know, we're kind of closing up. A few small little lightning questions just on zooming out from OpenAI. This question I got from Alessio, so why don't you take it?

Alessio [01:03:15]: So when you started OpenAI, you almost believed that it was too late to start an AI lab. What are things that people today think it's almost too late to do that they should be doing?

Greg [01:03:26]: Well, I think it's pretty clear that connecting these models to real world application domains is extremely valuable. And I think sometimes it might feel like all the ideas are taken, but the economy is so big. Every application of human endeavor is so big. And so it is worthwhile and really important for people to really think about how do we get the most out of these amazing intelligences that we've created? And a lot of that is, you know, for something like healthcare, you have to really think about all the stakeholders, right? You have to think about how does the system work today and how do you slot these models in well? And I think that's across all of these domains. There is so much fruit that is not there. You have to think about how do I get picked? Yeah. So go ahead and write the GPT-Rapper. Yeah. Do it. But I think the thing that I would advise is to really think about domains where the value that you're producing is not necessarily just having written a better wrapper. It's really about understanding a domain and building up expertise and relationships and all of those things.

Swyx [01:04:20]: You do occasionally angel invest. What gets your attention?

Greg [01:04:24]: I actually have not angel invested for a number of years now. Oh, okay. Yeah, yeah. It's just like everything is a distraction from OpenAI and I just like to stay laser focused. Okay.

Swyx [01:04:33]: All right. Let's move on to our next travel question. What is one posted note you want to send to 2045, Greg? So you'll be 58. How's the Dyson sphere? How's the Dyson sphere? Dude, I don't know if you've actually done the math on like what it takes to do that, but.

Greg [01:04:46]: Yeah, I mean, more seriously, it's like 2045 is just so hard to imagine given how fast things are moving right now. And so I hope it'll be a world of amazing abundance and that I think at that point we really should be multi-planetary and kind of almost any sci-fi dream you can imagine. It's hard to deny its possibility except for things that are limited by the physical ability to move some atoms at that rate. But yeah, it's like, I just, I think I would just hope that that world is as amazing as it could be sitting here in 2025.

Swyx [01:05:17]: Will we even need UBI with abundance? Because true abundance means we don't need it.

Greg [01:05:22]: Well, I think, well, first of all, I think that there's been a lot of debate. I remember early on in OpenAI of post-AGI, will money mean anything? Right? And it's really unclear, right? If you can just talk to a computer and it'll produce anything you want. You want something that, you know, you want some physical good, you want some, you know, any sort of material item and it can just be manufactured for you instantly, you know, effectively free. What does money mean? And the flip side is like, I think that there is one resource that is very clearly going to be in very hot demand, which is compute. Already the case, we see this within OpenAI that the researchers that have the access to the most compute are able to. To have the biggest projects and do more. And I think in the future, thinking about how do people get access to compute and the more compute that you have for whatever task you care about, for whatever application you care about, it will be solved more, that more will happen. And that I think that that question of what the compute distribution looks like will be something very important. And so I think that the question of exactly how, you know, if you don't do work, do you survive? I think the answer will be yes. You'll have plenty of material, your material needs met. But I think the question of can you do more? Can you have not just generate like, you know, as much, you know, like sort of movie as you want, but have like this amazing detail and like all this extra fanciness to it and have this thing go, you know, think super hard for, you know, 100 years worth of a subjective experience about what the best thing is for you specifically. I think that there will always be more return on more compute. And so that will be something we have to really think carefully about, about how that society is architected.

Swyx [01:06:59]: And then this, I always find this harder, by the way. Yeah. So, yeah, that's the question. No, it's a little bit of an excuse to send out a note, you know, like a post-it note to send to 2005 Greg. So 18 year olds. Wow. I get the time travel.

Greg [01:07:07]: How long of a note can I write?

Swyx [01:07:09]: Like a post-it note. Little bit of advice to yourself, and obviously this is a proxy for everyone else. Right.

Greg [01:07:15]: But you know, address it to yourself. I think the single thing that I have been most surprised about is the abundance of problem grows over time. All right. Because I remember in 1999, 2000, reading about Silicon Valley and feeling like I've missed the boat. I was born just a little bit too late. Very common. Exactly, right? I just felt like all of the cool problems must be solved by the time I'm ready to go work on things. There'll be nothing left. That turned out to be totally false, right? Like now is just the most exciting time to be in technology, to really be operating in the world because we have this amazing tool that is going to uplift and revolutionize every application, every field of human endeavor. And I think that the fact that that's something to be excited about, that is something that we can apply and, you know, there are challenges we have to work through, no question, but for the purpose of achieving this amazing outcome. And so I think that just that message of that the problem availability will grow over time rather than shrink, I think, is the core thing I wish I had sort of internalized at the moment.

Alessio [01:08:17]: Awesome. Thank you so much for joining us, Greg. Thank you both.

Greg [01:08:21]: Thank you so much. It's been great to be here.

>$9B projected EOY 2025 so this is 20x current multiples, not crazy.

this is a joke

Applications for AI Engineer Code Summit (Nov 20-22 in NYC) are now open.

Generative Video has been one of the big trends of 2025. The space has completely exploded and we are even seeing it in mainstream media, like the Kalshi ad during the NBA Finals. We made a whole episode on that with the Moore twins!

Today, we are covering the unsung heroes that power inference for many of these models: Fal.ai (including some well known closed source image and video diffusion models). They are on track to add ~$100M of new revenue this year alone, with video becoming an increasingly high percentage of it. But only 2 years ago they were instead building a tool for dbt data pipelines!

Fal now hosts >600 models on their platform, powered by >100 custom CUDA kernels to improve performance. We tried to use this podcast as a way to recap the history of generative models, and what was a big inflection point in their history. Enjoy!

See all links below in the show notes.

Stable Diffusion 1.5

• The first major hit for Fal when they pivoted to hosting optimized inference

• Became very popular with extensive fine-tuning ecosystem

• Still used today with LoRAs due to being fast, cheap, and reliable

Stable Diffusion 2.1

• Described as "a bit of a flop" that didn't get much attention

Stable Diffusion XL (SDXL)

• First major model to bring FAL their first million in revenue

• Exploded the fine-tuning ecosystem (LoRAs)

• SDXL Lightning: A distilled version by ByteDance for faster generation

Stable Diffusion 3 (SD3)

• Had "some drama around it"

• The team left Stability to form Black Forest Labs

Flux Models (Black Forest Labs)

• First to breach the barrier of "commercially usable, enterprise-ready" models

• Drove FAL from $2M to $10M revenue in first month, then to $20M

• Three versions:

  • Schnell: Apache 2 licensed, extremely distilled, 4-step generations for lower quality

  • Dev: Non-commercial license with revenue sharing

  • Pro: Requires collaboration for hosting

Gemini Image Models

• Google's autoregressive image models, considered underrated

Flux Context (Dev)

• Released late May

• Popular editing model

Qwen Image/Qwen Imager

• Released two weeks before the podcast

• Now topping Flux Context Dev

• Very good text-to-image when using single frame from video model

Stepfun's Hydream

• Image editing model from smaller Chinese lab

VivaGo

• Another editing model from Chinese labs

Sora

• OpenAI's model that showed what was possible

• Motivated researchers but was surpassed within months

Veo3 (Google DeepMind)

• Created "usable text-to-video component" with sound

• Very expensive to run

• Excellent at conversation, timing, lip-sync

• Also functions as one of the best text-to-speech models

Hun Yuan Video

• Chinese model, considered "pretty good"

Mochi (Genmo)

• Quality wasn't quite there initially

One (Alibaba)

• "Insanely good model"

• Newer version released recently

• Can run 480p draft mode in under 5 seconds

• 720p full resolution in 20 seconds (aiming for 10)

Minimax

• Chinese video model partner

Kling (Kuaishou)

• Chinese video model partner

Movie Jam

• Research paper arguing MMDiT architecture is unnecessary

Multitalk

• Post-trained version of One

• Good for conversation but lost generalization ability

• Only does talking faces

PlayHD/PlayAI

• FAL helps optimize their inference

• Some use autoregressive models

• Some use diffusion-based approaches

Notorious

• Known for diffusion-based audio generation

• Fal.ai

  • Gorkem

  • Bathuan

• Kuaishou

• Minimax

• Genmo

• PJ Ace

• Black Forest Labs

• Stable Diffusion

• Stable Diffusion 1.5

• Stable Diffusion 2.1

• Stable Diffusion XL (STXL)

• Flux Models

• PixArt

• Qwen/Qwen-VL

• PlayHT

• SDXL Lightning

• AnimateDiff

• Tail Draw

• HunYuan

• Hydream

• OmniHuman

• Seedream

• Multitalk

• Genie (Google’s world model)

• ComfyUI

• Scaling Rectified Flow of Transformers

• Diffusion Transformers

• Consistency Models

• [00:00:00] Introductions

• [00:04:29] History of Major AI Models and Their Impact on Fal.ai

• [00:07:06] Pivoting to Specializing in Diffusion

• [00:10:46] Writing CUDA Kernels

• [00:15:50] Latency importance and A/B testing results with customers

• [00:17:56] Influence of open model availability on Fal's growth

• [00:19:00] Working with closed source model providers

• [00:21:19] Inference optimization for audio and music workloads

• [00:29:10] Performance improvements for video generation

• [00:29:47] OpenAI and Gemini's autoregressive image generation

• [00:34:45] World models for controllable video generation

• [00:36:26] Rise of Chinese open-source video models

• [00:39:30] Monetization strategies & revenue sharing

• [00:42:48] NSFW content moderation and enterprise content safety

• [00:45:10] Trends in startup launch videos and generative video adoption

• [00:46:59] LoRA-based customizations

• [00:47:11] ComfyUI, chaining models, and enterprise workflows

• [00:51:58] Applications of Generative Media

• [00:54:15] Requests for Startups and Future Opportunities

• [00:56:34] Ideas for building startups on top of Fal

• [01:00:29] Hiring and Team Building at Fal.ai

• [01:03:27] What makes a cracked engineer

Alessio [00:00:03]: Hey everyone, welcome to the Latent Space podcast. This is Alessio, founder of Kernel Labs, and I'm joined by Swyx, founder of SmolAI.

Swyx [00:00:09]: Hello, hello. Today we're so excited to be in the studio with Gorkham and Batuhan of FAL. Welcome. Yeah, thanks for having us. Long time listener, first time caller.

Swyx [00:00:21]: Gorkham, you and I actually go back a long way to when it was still features and labels, and you were just coming out of Amazon. I don't even remember the pitch. I honestly should look at my own notes, but you were optimizing runtimes.

Gorkem [00:00:33]: Yeah, it was first like we were building a future store, and then we took a step back, and then we decided to build a Python runtime in the cloud. And that evolved into an inference system that evolved into what FAL is today, which is a generative media platform. So we optimize inference for image and video models and audio models, but we do a lot more. We try to own this whole generative media space for developers, basically.

Swyx [00:01:01]: Yeah, amazing. And we can talk about. That journey. I wanted to also introduce Batuhan. We're newer to each other, but you've come to some of my meetups before. You're head of engineering.

Batuhan [00:01:09]: Yeah, I lead engineering here at FAL. You know, I'm glad to be here.

Swyx [00:01:14]: And what's your journey?

Batuhan [00:01:16]: I met Burkay in 2021 when they were just starting the company. And like just before the seed round, you know, Burkay and Gorkham, we met online. We're both Turkish. So I think that was a connection. We just met and then they said, oh, why don't you join us? And like, I was one of the core developers of Python language. So I had like really, you know. Really good experience with developer tools around the Python language. So I started coming here to build the Python cloud, which evolved into this like inference engine and the generative media cloud that we're building today.

Swyx [00:01:43]: And now you spend time, less time with Python and more time with, I don't know, CUDA, custom kernels.

Alessio [00:01:50]: And yeah, yeah, yeah. Yeah. Remember the DBT FAL when the modern data stack was out. Can you guys maybe just give a quick sense of the scale of FAL? So you just raised a hundred twenty five million dollars. Seriously. That's correct. We're going to talk about. Yes. That's how I passed on one of your early rounds. We can go through through that. How many of the developers, how many models do you serve and maybe any other cool numbers?

Gorkem [00:02:11]: Yeah, we have around two million developers on the platform and like for the longest time we required GitHub login. It recently changed. But so I'm assuming everyone who has a GitHub account as a developer and we have around three hundred fifty models in the platform. These are mostly image, video and audio models. It used to be only image and then we added audio and the space evolved into video as well. And yeah, that's that's pretty much the scale. We just closed, announced our series C round and we've been growing a lot in the past year and it's still continuous. Yeah.

Alessio [00:02:50]: You had a very nice series C party and you guys are over a hundred million in revenue, right? Just this is not, you know, just developers kind of kicking the tires. That's correct. Yeah, that's great. When you say three hundred fifty. Models, I think what percentage of all the models that you could serve is that because, you know, especially in any.

Batuhan [00:03:08]: Infinite amount of iTunes post-trained versions of these models, we are trying to serve the models that fix a gap, you know, that fill a gap in the stack. So we don't add a model that's like significantly worse in any aspect compared to other models that we have. We are trying to bring unique models that solve a customer's needs. So that's like these are three hundred fifty models. You know, there's like twenty, thirty text image models, but like one of them excels in logo generation. Another one. Excels in human face generation. So like every model has a unique personality. But if a model is like significantly worse in all aspects, we don't add that to the platform. So there's like infinite amount of models that we can add. And do you rely on your own evals or just like what the community tells you? We mainly rely on our own evals as well as, you know, like we are in the community. So we also like follow the community very well to see like what what is going to be the thing that's going to be in the next generation of apps. So if you think something like we have a good intuition, if you think something is going to pop up, we just add it. Yeah.

Swyx [00:03:59]: To my knowledge, you haven't published your own evals, right? No. No, we don't. It's internal. And then the community is Reddit, Twitter?

Batuhan [00:04:05]: Twitter, Reddit, you know, Hugging Face, seeing how popular the models are in Hugging Face and other demos. Okay.

Gorkem [00:04:12]: I just want to give people a sense of where to get this info. The best part of the job is the day of a model release, the adrenaline rush that comes with it, the whole team trying to scramble something together and release it. And it happens every week. Right. Every week is exciting.

Alessio [00:04:27]: Can we do maybe a brief history of like the models that were like the biggest spikes? Maybe usage, you know, you kind of, I think everybody knows stable diffusion, you know, and then you have maybe like the Flux models and then you have Black Forest Labs. You have like all these different milestones.

Batuhan [00:04:40]: History-wise, I think the biggest, like the initial hit was stable diffusion 1.5, which is when we actually pivoted into this new paradigm of fall. Generative media cloud. We started hosting it. We noticed like we had the serverless runtime and everyone was running the stable division 1.5 by themselves. And we noticed it's terrible for utilization and they are not optimizing it. So let's just offer an optimized version of this that's ready for API 2.0. It has to be scaled and doesn't require people to deploy Python code because we want product engineers to start using it. We want mobile engineers to start using it. So we started offering stable division 1.5. It was very popular. The fine tunes around it was very popular. Stable division 2.1 came. It was a bit of a flop, so it didn't like, you know, got that much attention. And then STXL came, which was like the first major model that brought like our first million in revenue, if you consider that. And with STXL, obviously like the small fine tuning ecosystem also like tried to explode. People started fine tuning their faces, their objects, whatever, and generations with this, like LORAS started to become very popular. And then after stable division XL, there was like a bit of a quietness around it. You know, ST3, there was like some drama around it and the team at Stability left to start Black Forest Labs, which released Flux models. And that was the first model to reach the barrier of commercially usable, you know, enterprise-ready great models, where in the first month of Flux models, we reached from like 2 million to 10 million in revenue. It was like a big jump. Next month, we were at 2.8 million. Like it just started going from there. And then video models started, came around, you know, we partnered with Luma Labs, we partnered with other video model companies in China. We partnered with Kling, Kuaishou, Minimax, and with these models, like, you know, it created another market segment that was a big jump. And this, the final biggest thing was VO3, where it actually created this like usable text-to-video component, where before text-to-video was like a very boring, soundless video that you would like, you would not get enjoyment out. Whereas now it's like a, such a great experience. You can create all these like memes that you're seeing online, all these ads. So that was like another big jump for us, like partnering with Google, DeepMind, for VO3.

Swyx [00:06:41]: Yeah, actually that's a really good history of generative media, that soundbite. So I wanted to double-click on that because obviously we can, we can dive, I think everyone's interested in video, but there's a whole history of the image side that I wanted to cover first. Just definitely wanted to start with was just the decision to pivot. I think I just want to double-click on that, you know, it's not a trivial decision, but obviously the right one. At the time, I would say like a lot of people were hosting stable diffusion, right? So it wasn't obvious that you can just build an entire company around effectively just specializing in diffusion and inference. What gave you the confidence? What were the debates back and forth?

Gorkem [00:07:16]: Yeah, a couple of decisions we had to make there. We could have evolved the company into more towards GPU orchestration. And like, essentially we had this Python runtime, we were running it on top of GPUs, like that could have been the company. But we saw everything. Every single person, every single company who are using what we had, like a little SDK to, to run Python code on GPUs, they were doing the same thing. They were deploying a stable diffusion application, maybe using some LORAs on top of it, different versions of it, in-painting, out-painting, things like that. I mean, it was very wasteful. We decided, okay, this needs to be an API where we actually optimize the inference process and everyone benefit from it. And like, you can run it multi-tenant, you know, DTools.io. And like, you can run it multi-tenant, you know, DTools.io. And like, you can run it multi-tenant, you know, DTools.io. So that was the decision number one. And then obviously after stable diffusion, I think like four or five months later, Lama 2 came out and there was a decision point again. You could do language models. Exactly. And a lot of the inference providers at the time, there were maybe a couple of them, and they all went all in on language models. And we decided language models, hosting language models is not a good business. At the time we thought, okay, we are going to be competing again. We are going to be competing against OpenAI and Anthropic and all these labs. Turned out that it was even worse because the killer application of language models is search and you are competing against Google at the end. And Google can basically give this for free if they can, because it's so important for them and, you know, it threatens their business right away. And with image and video models, it was a net new market. We weren't going against any incumbent. We weren't like trying to get market share. We were trying to get market share from someone much bigger than us. And we liked that aspect of it. We thought we could be a leader here. It was a niche market, but it was very fast growing. So we chose to be a leader or play to be a leader in this fast growing niche market rather than trying to go against Google or OpenAI or Anthropic. So that was the decision we made. And turns out it's a good one because we are able to define the market we are in and educate the people and grow with it. And so far it's been growing fast enough that we were able to build a whole company around it.

Swyx [00:09:37]: Yeah, and I think you noted at AIE that, you know, now there's a generative media track, generative media specialist investors. Thank you for calling it generative media, by the way. Yeah, I mean, obviously it's a thing and people care about it. And I do think it's going to change the economy. And as a creative person, I think I also wonder what's going to do for us. Just so I want to keep it technical and keep thinking about the pivot, because I think it's still like one of the most interesting pivots I've seen. And in the AI era, you were not CUDA kernel specialists at the time, right?

Batuhan [00:10:05]: I come from a compiler's background. So my my job was optimizing, you know, like Python bytecode interpreter to make stuff faster, which is performance engineering. And like, yes, like I don't think at the time there was that many CUDA kernel specialists either. So it's like we were at like the right time. You know, it was like, actually, like the space was actually so, so much worse than what we have today, where like the running basic stable division 1.5 was like a unit with convolutions and the convolution performance on AI was like you're getting like 30% of the GPU power if you just use rough touch because no one cared about it. So there was like so many low hanging fruits that we started to pick up and started optimizing and it kind of evolved, evolved, evolved. Right now, it's like much more competitive space with like NVIDIA is like a 50% 100% kernel team that's writing kernels. You're competing against that at the time. No one cares. No one really cared about it. So it was like a good new field for us to go thrive. And there's no community effort like a VLM.

Gorkem [00:10:57]: Not exactly. When these models were first released, like no one in the world has ran them in production. Like it just didn't exist. It's like a research output. Exactly. Yeah, it was stability. Yeah. You had your maybe local GPU. Maybe you had like a single GPU that you rented from the cloud. And basically this was a research interest rather than a product interest. And no one at Meta. Meta. No one at Google had run this in production. So we also thought this is a good, good time to start that company around this and actually spend time optimizing it as much as we can, because if we can get millions of people to use this, there's a lot of economical value to be created there.

Alessio [00:11:36]: Can you talk a bit about how much of a performance boost you got? Because I know when I met you guys, you were about a million in revenue. You were like, well, we're writing all these custom kernels and maybe part of it is like, okay, how many kernels can you actually write? Sure. You know, as you as you support. For all these different models, like what's kind of like the breadth of them? Like, are you writing kernels that you can reuse across models? Like how much work do you have to do on a per model basis?

Batuhan [00:11:59]: It really evolved in the past three years. You know, when we first started, there was a single model, stable diffusion 1.5. So every all of our kernel efforts were how do we make stable diffusion 1.5 as fast as possible? You know, you go from like 10 seconds with PyTorch at the time, there was no, not even like a torch compiled torch inductor or whatever. So you were going from 10 seconds to maybe like two seconds on the same GPU. Uh. And. And like, we, we started with that, the next thing, like, you know, the, like with, with adding more models, you know, like stable diffusion, Excel was a different architecture. PicsArt was a different architecture. All these like different architectures started coming around. We said, let's build an inference engine, which is what we call a collection of kernels, parallelization utilities, diffusion caching methods, quantization, all that stuff combined into one package. And so we built this inference engine, uh, the same time PyTorch 2.0 was released with Torch inductor and Torch Dynamo to do like Torch compiled, which is like essentially a way to trace the execution of, of your neural net and generate Triton kernels that are fused, like that are more efficient. And I'm a big sucker for just-in-time compilers. I used to work at PyPi, uh, like a just-in-time compiler for Python. And we said, this is a great idea. Let's apply this, but a more specialized, more vertical way for diffusion models. At the time it was Unets. Now it's diffusion transformers. Which are significantly different than your auto-regressive transformers in terms of like the profiles of like how compute bound it is, what sort of the kernels are taking the majority of the time, you know, if you're doing bidirectional attention or causal attention. So we started doing that. And now it's like, what we have today is a inference engine that's like applicable, that gets you like 70, 80% of majority of the models on diffusion transformers. And we still have like a lot of custom kernels for a lot of models to squeeze out, like, because they're still, still small. Every model wants to make an architectural difference. You guys see this on like, you know, even for stuff. Like, you know, Kven, DeepSeq, whatever people want, like, even if we know an architecture is the best, they want to tweak it a little bit just to make sure, oh, we are releasing something cool. So we, we saw this. And then like, for that, we have to write like custom kernels for custom RMS norms that people are doing or whatever, like stuff like that. So we, we have, we have a decent amount of kernels, like over a hundred of custom kernels. This doesn't include the auto-generated ones. You know, we have templates of kernels that generates like, you know, for thousands of different shapes, problems, spaces, whatever. But like, if you consider those, you know, like we have tens of thousands of kernels, obviously. At runtime that we are running and dispatching, but that's pretty much like the depth and breadth of it.

Alessio [00:14:13]: And on average, a model on file runs 10X faster than I would self-host it. Like if I just take stable diffusion, right. And I put it.

Batuhan [00:14:20]: I know this might be a bigger discussion point. Do we consider speed as a mod? This, this comes to that. It's like the existing open source industry goes so fast where, you know, like if you go to like, this might have been true three years ago. Now, PyTorch is like already like very, very good for H1N1s, right? What about P200s? When you use PyTorch with P200s, Blackwell chips, you're not getting the best performance. So our main objective and our main goal is for whatever GPU type you're using, these diffusion models, we're going to extract the best performance. At any point in time, it could be 1.5X, it could be 3X, it could be 5X. For certain models, it could be 10X. It would be a bit of an unfair thing to say, oh, we're going to make everything magically 10X faster. No one in the world can do that.

Gorkem [00:14:57]: We are lucky that this is a moving target and open source community, everyone catches up. But at the same time, new chips come out, new architectures are released. So we are always ahead of like what's possible, but then they catch up, but we have to stay ahead of it. And that's how we can create differentiation because it's a moving target, because there's so much going on. We are, whenever something new comes up, we are the first one to optimize it, first one to adapt our inference engine to it. So at that time, the fastest place to run it, that helps with margins, things like that. But eventually people do catch up. I think it's very hard to create this differentiation over launch. So it's like, oh, we're going to do this long term if there is no new architectures, if there's no new chips. But luckily there is all the time. Yeah.

Alessio [00:15:43]: Yeah. And I think with image specifically, you cannot stream a response, so to speak. So when you have a language model, it's like, you're kind of bound by like how quickly you can read. So even with like rock, it's like, it's impressive to show a thousand token a second, but it's like, I'm not reading that fast. Right. So it can go slower versus what images it's like, you just need to see it. That's why mid journey now has like the draft mode. For example, it just gives you this. It's like very low quality resolution. Yeah. But at least you can see whether or not it's going in the right direction. How much of that is actually true for like your customers? What do they care about the most? Like it's latency that important. Like what's the range of latency that matters? Yeah.

Gorkem [00:16:20]: Latency is really important. One of our customers actually did a very extensive AB test of like they on purposely slow down latency on file to see how it impacts their metrics. And it had a huge part in it. And it's, it's almost like page load time when the page load slower, you know, you make less money. I think Amazon famously did a, did a, a very big AB test on this. It's, it's very similar. Like when you, when the user asks for an image and, you know, iterating on it, if it's slower to create, they're less engaged, they create fewer number of images and, and things like that. Yeah.

Swyx [00:16:56]: It's the same learning that Amazon has like every, you know, 10% improvement in speed. Yeah, exactly. It's the, the elasticity is high. The other thing I wanted to also dive into, you know, like I putting my, a little bit of the investor hat on one of the reasons for file success is kind of with not within your control, which is how, when, and how people reduce release open models for defer diffusion, which like at the time it was just stability and like, there wasn't, there was no Chinese, you know, I'll put, I mean, what we, we did have other image models, but they were not great. Yeah. And like, and so, so you, you made a bet on when it was just like, wasn't super obvious, but then the other thing is, which is what you're touching on. The diffusion workload is very different from the language workload and the language workload is being super optimized, whereas diffusion is not. So you, you just like had kind of no competition for a while, which is fantastic for you.

Gorkem [00:17:44]: A hundred percent. And like the open source, we benefit a lot from it, obviously, but like in the, in the past six months, a year, we started working with some of the closed source model developers as well, like behind the scenes, helping them. But they're not sending you their weights.

Swyx [00:17:58]: They do. They are. They are. Wow. Yeah. What do you have to give security?

Batuhan [00:18:02]: Like guarantee them? I mean, we are any cloud provider, like what, what, what, what do they think in like AWS or Google cloud or these new classes? There's like 50 new class, right? Like we, we are not that different from any other cloud provider. And this is why we package the inference engine in a way that, you know, they can self-service and get 80%, 90% of the performance. So they don't even have to show us like their code. They deploy to our, we have our own cloud platform where our inference engine is available only in that platform. So they can tap into that when they deploy their code and their model weights to us. And we don't really have to look at it. If they want to collaborate with us, which some companies did in the past where we would just essentially, we have performance engineers acting as forward deployed engineers on their behalf and writing custom kernels for them. Okay.

Swyx [00:18:43]: Have you disclosed who you're doing this for?

Batuhan [00:18:45]: We disclosed PlayHD, PlayAI. That was one of those. We have like four different companies, four major video companies that we are doing this with and one image company that I don't think we disclosed. Yeah.

Gorkem [00:18:56]: As you can imagine, it's a little sensitive for them. So yeah. Yeah.

Swyx [00:19:00]: I would say like, so like. Yeah. So like a couple of years ago, when sorgenoplicate started serving V03 models and we were like, okay, are you just wrapping their APIs or something? And I think so. It's not obvious like how much integration there is going on and how much this on your infra or like your tech.

Gorkem [00:19:13]: Just to be honest, like some of that is happening too. Yeah. V03 like, I think everyone is. It's just API wrapper. Yeah.

Batuhan [00:19:19]: It is. Yeah. You have a dedicated pool that you can serve to your customers with like different speed SLA guarantees, whatever. Okay. It's like how it would work for something like V03.

Swyx [00:19:27]: But your objective is to be one-stop shop.

Batuhan [00:19:32]: Thank you so much for having me.

Swyx [00:20:02]: Thank you so much for having me.

Swyx [00:20:50]: Thank you so much for having me. Thank you so much for having me.

Batuhan [00:21:30]: Thank you so much for having me.

Batuhan [00:22:00]: Thank you so much for having me.

Batuhan [00:22:30]: Thank you so much for having me. I see, I see. It's a separate product. Yes.

Alessio [00:22:32]: From a GPU perspective, do you always need to be on the latest? You keep mentioning H100s.

Batuhan [00:22:37]: Majority of our workloads are in H100s because price-per-files, it makes sense. But BlackVal is obviously, we have five people dedicated to writing BlackVal kernels right now to make sure we can, because theoretically it looks good, right? Like flops dollar-wise, it makes sense. But can you reach that actual flops? No. So we have a dedicated team that's working with NVIDIA directly to write custom kernels for BlackVal for diffusion transformers. To get to the, to get to the point where it makes perf dollar make sense. And then, then we would start with our own workloads as well as some of our foundation model companies. We would ask them, oh, if you want to migrate to BlackVal, here's an inference stack that already works.

Gorkem [00:23:11]: We are at that point where we should be the ones pushing the boundaries on BlackVal because no one else is doing this work. And maybe it doesn't make sense economically right now, price perf-wise, but we know it can. So we are like working towards maybe like a couple of months away from that point. And then whenever it does, we'll probably, you know, we'll be able to do it. We'll probably switch as many workloads to BlackVal as, as possible.

Swyx [00:23:33]: Just to be super crazy. When does it make sense to just work on an ASIC?

Batuhan [00:23:38]: I don't think it does. That's like honest opinion. You know, like the people, this is like one of the most controversial topics, right? Like is, is, is all these like ASICs a great idea? If you're like S-RAM, if you're memory bandwidth bound and like you can put all of S-RAM, is it like even economically viable at that point? I don't know. But like the summits are around like this, this chip design. So you see like, okay, what is the overhead of an NVIDIA GAM instruction? Right. It's like 16%. So like you're essentially buying a metrics and multiplication machine. So at like, it doesn't really make sense to specialize it that much. And like some of the, like, like B300s are going to have like a better softmax instruction that gets like 1.5x, whatever. And like, that might be one way where NVIDIA gets like, you know, better performance out of the majority of like, for the majority of workloads, which is like attention heavy stuff. I think it might make sense for like NVIDIA to like add more specialized stuff, but like for us, I don't think it will ever make sense to.

Swyx [00:24:30]: Build I6. Just thinking about from first principles that the diffusion workload is very different, but also obviously there's still a lot of changes in the architecture that you need to just general purpose.

Gorkem [00:24:40]: We don't have a single model where we are trying to optimize. We are trying to do it for the newest, the best, like always. The flexibility is therefore really important.

Swyx [00:24:48]: I was going to show, I'm going to pull up the Quen MMDIT, where there's like this dual streaming thing, which I last, I think SD3 had it. Yes, SD3 Flux. Yeah. Is that the standard, standard model now? MMDIT.

Batuhan [00:24:59]: So it's also a controversial topic, you know, scaling rectified flow of transformers paper, the SD3 paper came up with this architecture. And then one of our research team actually, like Simo Raya, he's like our head of research, he found out that like just using MMDITs are inefficient. You need to mix them. And now there's like controversial opinions, you know, like movie jam paper were saying, oh, MMDIT is completely unnecessary. You can just use a single stream DIT, whatever. So like there is like controversial opinions happening in terms of architecture changes, which I understand because everyone wants to do a different architecture. No one wants to use the same architecture because it's lame. Yeah. Yeah. Otherwise, like it's just a matter of compute and data and these researchers don't feel proud that their model is an output of data and compute. They want to make a novel research change. So I think the architectures is going to keep changing until this like paradigm of like, you know, researchers changing stuff for the sake of changing, you know, features.

Swyx [00:25:47]: I'll talk about a couple other architectural things just to keep it bounded within this topic. The distillation was a thing for a while. SDXL Lightning, you guys did fantastic demos of Tail Draw, which we've also had it on podcasts. Fantastic episode. What happened to those things? How come they're not popular anymore?

Gorkem [00:26:03]: I think it makes for a good demo. You know, you could build real time applications, you could build these drawing applications, things like that. But I don't think people could build applications that like have user retention long term. Like people couldn't really build useful things with it.

Swyx [00:26:19]: Let me play out what I thought was going to happen. And then you tell me why it didn't happen. Sure. Which is consistency models for drafting. It's like you use your pen to draw. You draw things and it creates the draft. Then you upscale, right, with a real model. But like, that's it. Like, why can't it be a two stage process instead of one stage? Yeah.

Gorkem [00:26:39]: And I think one thing that happened is Flux, like that generation of models were not good at image to image when it first came out. So like you need a good image to image model to be able to draw. Maybe it needs to be revisited around this time with some of the editing models, maybe. Like image to image and control. That's Flux.

Batuhan [00:26:58]: Like Excel or Controllers were very popular, where like people were used to do this stuff, like sketch to image, whatever. And like with Flux, I think people cared less about it. One thing that I keep thinking about this is like, is this true for LLMs too? You know, like I always default to cloud 4.1 Opus, right? Even if it's slower than Sonnet, it's just like, I know I'm going to get the best quality. Exactly. That's what's happening here. Yeah. That is, it seems like what's happening here as well.

Swyx [00:27:22]: As a, okay, anyway, as a creator, I want fast, quick drafts and then, and then I can refine, right? Like, so. I don't know. I don't know why it didn't happen.

Gorkem [00:27:29]: More true for video models, right? It used to be like five minutes, four minutes for a single five second generation. Now it's mostly under a minute, but you want 10 second, five second generation. And then because the workflows of like creatives, when they're working with it, they generate a ton of videos and then like pick one and then create a story around it. So then when you watch these people actually generate videos, they generate like hundreds at a time and they have to like, kind of sit around it. And then wait, and then like iterate on it. Like the faster speeds mean a lot for creators.

Swyx [00:28:05]: Yeah, it does. The other thing I wanted to also briefly touch on before we go back to the main topics is the autoregressive models, which you mentioned, right? Like, obviously, I honestly, I still think Gemini is underrated because they were first. And then, but then obviously, openly, I did the 4.0 image gen and that was a huge thing. I actually even wonder if there was a panic for you guys, because obviously it's like, this is Soda image gen and like no one else has it. It's not, it's not open source.

Batuhan [00:28:30]: Have you passed through those eras so many times?

Gorkem [00:28:34]: Stopped worrying about it.

Batuhan [00:28:35]: Your camera's like good stories around Dolly.

Gorkem [00:28:38]: Yeah, I mean, I talk about this how like when Dolly 2 first came out, I was like, okay, open AI is so far ahead of anyone else. Like it's impossible for mid-journey and then people caught up within months and then stable diffusion was even maybe better. Or just as good as Dolly, like a couple of months later and it was open source. So like a year later, same thing happened with Sora. Like they, they put out those videos and that time around, like, I think we were excited because now that people see that it's possible, like this is like actually doable. Researchers get motivated and they see the hype. They see that this is possible. So they work on it. And within a couple of months, we had maybe not Sora level, but much better video models. Now we have video. We have video models that are much better than Sora. So whenever we see someone actually pushing the frontier, it's a reason for excitement because now that's possible. Other people are just going to do it within a couple of months. So you don't panic anymore.

Alessio [00:29:38]: Is the fact that Anthropic doesn't have an image generation model tell you anything about what the larger labs care about?

Batuhan [00:29:44]: It tells more about Anthropic's own like priorities than like the in general, like what the other labs, because if you look at XAI, if you look at Meta, if you look at open AI, it's like, if you look at Google, they all have really good image models. Yeah.

Gorkem [00:29:58]: Google in their last announcement, they use the word generative media, by the way, which was a proud moment for us. It's a win. And a lot, and you know, they focused on generative media as much as their new LLM models. So some labs definitely care about it and some labs, it's not a priority for them. Look at XAI. They keep pushing like image language. AI slob. Yeah, I know.

Alessio [00:30:19]: I know it's crazy. And waifus. And levels of interactivity. You have images, you have video. Now you have Genie, this kind of like more a world model, you have kind of like gaming applications of that. How far are we from like file getting a lot of traffic on, on those models? Like, is it mostly experimental today in open source? Obviously Genie is impressive, but like it's a Google model, you know?

Gorkem [00:30:39]: I have a very optimistic take on this and that may be like a normal outcome. I think at worst, we are going to have very capable video models that come out of world models, right? It's going to be a very controllable video model and the use cases will be. Similar to what video models are. You're going to create content, but you're able to control the camera angles. You're able to control the video model a lot better than what you can do today. At worst, we are going to get that from world world models. And at best, I think it's very hard for anyone to predict what's going to happen. Yeah. Movies and games. Like it's going to be something in the middle where you can be, be part of a whole movie universe that's going to be playable. So it's boundless possibilities. What's, what's going to happen at best and how affordable is it going to be? Like, is this ever going to reach, uh, you know, mainstream adoption? We'll see all that, but it's definitely technically incredibly exciting and impressive. What's, what's coming out of these labs. Yeah.

Alessio [00:31:42]: I need to find the paper again, but, uh, there was this study on like, um, video models and like image generation, understanding physics. Yeah. And like, it could like predict the orbit of a planet, but then when it actually had it draw out the gravitational. Yeah. forces, it was like completely wrong. Yeah. You know? And so I, I think like, that's my thing with world model is like, I understand the creator application, which is how you can create consistent world. But I don't know if like the other side of people that are like, Hey, these are like the best way to like simulate the world and like get intelligence and things like that. I don't know that.

Gorkem [00:32:10]: Optimism around the two, because whenever you talk to someone who's working on robotics, they're bottlenecked by the amount of data they have. And from all these, you know, past three years of AI innovation, we've seen that. Right. But whenever there's an abundance of data, that type of models actually like improve a lot and you see, so like robotics, we expect something similar whenever they figure out this data problem, those models are gonna get better as well. So that's why people are so optimistic. Okay. Maybe this solves the robotics data problem and it's yeah. Bondless opportunities there.

Batuhan [00:32:46]: And regarding like the, the, the example you mentioned about gravitational forces is like, I think this is still the same problem as, oh, LMS can't do 9.5. 9.9 plus like nine, nine point. Yes, it can. It's like, you just need to train it with more data. You need to have a better tokenizer. It is the reason, whatever. It's just a matter of like data scale and like the underlying fundamental architectures. But like, I don't think it's going to change that much. We just like, we're going to put thousand X more data, thousand X more compute, and we'll get like the best physics simulators. And I think this just should be possible with the existing signals coming from the data.

Swyx [00:33:18]: Just to double click on video stuff as well. Yeah. Uh, you had a great slide in AI. At AI where you're like currently 18% of files revenue comes from video models and it might be a, that was February.

Gorkem [00:33:29]: So now, now it's probably over 80, 50, 50. Yeah. Okay. It's like over 50. Yeah. Yeah. A hundred percent. Wow. Okay. I guess editing models brought some life into the image as well. So like both of them grew, uh, but yeah, video grew faster.

Batuhan [00:33:46]: Video is like pretty, pretty significant. And the, the, one of the main drivers is open source models where, you know, in February. There was who knew on video, I think that was like pretty good. There was Mochi from Genmo, uh, but like the quality still wasn't there. And one from Alibaba was like insanely good model. And they released a newer version of this in like a month ago, I think, or like a couple of weeks ago. And now it's getting so, so popular. And like, we can run this, I'm all like for like four ADP, like the draft mode version, we can run it like five seconds under five seconds. So people can have like instant feedback loop. And then when they want to go to seven 20 P like full resolution is just like 20 seconds. I mean, we were planning to bring. It down to 10 seconds. Yeah.

Swyx [00:34:25]: That's amazing. Uh, and I want to double click on that for a while. I was kind of bearish on Alibaba because they kept releasing papers with very cherry picked and like, it was like a, it was like, okay, we're on GitHub. And then you go to GitHub. It's a read me.

Gorkem [00:34:37]: Like, I mean, you, you can't see something really changed. They've been, what happened to them?

Batuhan [00:34:45]: No, no, we haven't talked to them, but like, it seems like, and now there's like competing teams inside Alibaba, you know, one is a really good image model, but they released. As a, as a competing image model. Like, you know, we think like once image model is actually very, very good. If you'll do one with single frame, instead of like 81 frames or whatever, you get a really good text image model out of it. And this is just because of the pure amount of data that you put from the videos. So now there's like, you know, Alibaba has like two, two of the really good models, like from their lab. And then there's like smaller labs in China that like, you might not hear about, but like step fun, they, they released like an image editing model. Hi dream. We want to go like that. Like, there's like all these like small labs. They're releasing because I don't think training these image or editing models are that expensive. And video models might be like slightly more expensive. My guess is like training these costs like a couple million dollars, which is not that much, especially, you know, like, you know, they're probably backed by some sort of entity, you know, like other than Alibaba, you know, like there's, there's like Stefan, whatever they probably raise a really good amount of money. So training these models will bring you a lot of attention and it's more attention that you would get releasing a subpar LLM because like LLM space has so much more competition. So just training this for like a million dollars, a video model, and then releasing it, I think that brings you a lot of attention.

Gorkem [00:35:57]: It is a hack. When you look at Hugging Face, let's look right now. I'm sure the top models are image models. Like it's quite an image editing probably is, is probably up there. Yeah. Probably up there.

Alessio [00:36:08]: Number one, number one. Yeah.

Batuhan [00:36:11]: Hunan Gamecraft is number three, number four, number four, Gemma, 270 million, some image stuff. ByteDance has an open source, but they have a really good team seed. That's their new lab there. They're working on seed. Seedream, Seedance, OmniHuman, like stuff like that. We have a good, good, good partnership going with them to hopefully, you know, have their models hosted in the US as well. Yeah. And the idea is, you know, like, I think that the team that they, they were able to assemble is very good and it's coming from, you know, their previous researches, whatever. Like ByteDance was doing a really good open source stuff on like SDXL Lightning. They, they released like SDXL Lightning paper, Animative Lightning. So I'm, I'm pretty, pretty hopeful about them. Yeah.

Swyx [00:36:47]: First of all, you know, hopefully they, they don't reach out to you when they, when they launch, they just drop it and then you have to rush. Okay.

Batuhan [00:36:53]: So at this point, like people reach out to us because like we, we, we, we, we are the market leader.

Swyx [00:36:56]: So like they, they just like reach out to us for like the getting distribution. Yeah. There's a Chinese platform that they always launch on first, which I forget the name of it, but like you have to. We, we, we all also get like day zero launch with the majority of these models. But like, so, so basically I think the question is always like, you know, you are the ones making money. Stability did not make money from stable diffusion.

Batuhan [00:37:17]: I think the thing that Black Forest Labs did was very, very interesting in this aspect. They released three different models. Yeah. Apache two licensed, extremely distilled model, which is good for dev, uh, Chanel. This is the Chanel version. This is like the four, four step generations for like lower quality stuff. They released a dev model with a non-commercial license where their inference partners are, you know, like you're paying a revenue share with like, and this is like very good way. And then there is a pro version where you can like collaborate for hosting it. And I like the, the revenue share is obviously different for that as well. This is, I think a very smart choice for labs whose whole premise is releasing models. But if you're a company. That is doing a product in the side, you don't necessarily need to make money from the open source models, you're doing it for getting researchers get, you know, hiring people, getting distribution, whatever. So it's really depends on like the company's goals, like for, for Alibaba scale, like they don't care if one model is like hosted in their API, right? Like Alibaba makes a, it doesn't touch the Alibaba top line revenue, whatever one makes. So it's like for them, it's like, it's a no brainer to release it and get attention and maybe like get some leads. So they're Alibaba cloud offerings, but like in general for Black Forest Labs or companies like that, I think it's like a. A smart move to release like a distilled version as like fully open source and then like less distilled or like the actual model as non-commercial and then partner with inference companies and stuff like that.

Alessio [00:38:32]: What's the distribution of usage. So like it's 80% of your revenue, like five models, like, or are people really using like the, the long tail of all these open models outside of like the initial launch?

Gorkem [00:38:42]: I think like there is some power law, but not as much as you would think. And it keeps changing. That's the other part. Like, it's not like only a single model that's being used. A lot like month to month, it changes a lot. This summer has been crazy. They've been like, like just countless amount of new video models, new image editing models, like the leader kept changing week over week even. But if you like take a step back and look which models are being used, people want to use either the best, most expensive video model, or they want to use like a cost efficient, like good, but cheap enough video model. So those two models are. Usually like used a lot and whatever those models are, it changes week over week. And yeah.

Batuhan [00:39:29]: The one good example is like Fox context was released, you know, like on late May and co-edit was released like two weeks ago. And now it's like topping out a context that, you know, it's, it's insane how quickly these stuff transition just because it's, there's a better quality model and that's the value prop. Like you don't have to set up the infrastructure to manage flux context dev as soon as like co-edit is available. You can just switch to that with fall.

Alessio [00:39:51]: I mean, it seems to me. That if some models are open and some models you have to pay a revenue share, you ideally want to move the people off the revenue share models into the open models, right? Like what, what's that dynamic? It's all price step.

Gorkem [00:40:03]: I'm, I'm also thinking like, okay, we'll do whatever our customers are going to be successful with. We are still like early enough that these small calculations, I don't think it matters. I rather people actually go to production and build products with it and be successful rather than like, okay, 20% here, 10% there. I mean.

Alessio [00:40:22]: You're doing a hundred million in revenue.

Swyx [00:40:26]: Cool. I'll just ask a few more questions we had around just like the, how people really use this. Okay. I'll ask the super obvious question. Yeah. How much is not safe for work? Almost negligible. Yeah. You don't moderate everything in moderation is optional, right?

Batuhan [00:40:40]: Moderation is optional to a level where like illegal content is moderated. And we also track the non-illegal content, NSFW moderation. And like, we haven't seen more than 1%.

Gorkem [00:40:51]: Like the models themselves. They're actually not generating that type of content.

Batuhan [00:40:54]: So this is like some model providers, especially like, you know, if you look at Black Forest Labs models, the models are not for, it's incapable of generating because it, or like it's annealed in a way that is prevented. So, and like majority of our customer base, like if you look at revenue wise, it's like enterprises are like more on like the higher level of stuff where some of them might be like user space, mobile applications, but you know, like for the last six months, nine months, we've been transitioning more and more to enterprise where it's like less of a need for them.

Swyx [00:41:19]: Like less of a option. So what are those enterprises doing? You know, apart from like building a general purpose chatbot that can generate images, maybe Canva, you know, would be like a good use case. But my imagination is a bit limited beyond that.

Gorkem [00:41:32]: Advertising seems to be absolutely like growing. And if you think about it, it fits very well. And let's talk about video advertising. So like, I keep repeating this, but some companies talk about, oh, we are going to change Hollywood. Filmmaking is going to be revolutionized. Like, I don't think it's that interesting. Like. How many movies do you watch a year? Like maybe 20, 25 movies. How many movies in the theater you watch? Three, four at most. So if, if there are like thousands of movies that a year, like people won't be able to watch all of these movies. Like there's just not enough time. It's a max quality game. Exactly. Exactly. And with advertising, it's the exact opposite. More content there is the different, like, you know, ways you can create ads, there's always economical value attached to it. So. So you can create unlimited number of ads, unlimited different versions of it, and more personalized it is more, you know, economical value there is behind it. So it adds, it fits really well to this type of technology because there's no limit what you can create.

Swyx [00:42:35]: I'll tell you a side comment about a Silicon Valley trend I'm seeing, which I cannot explain, which is that all these YC startups and all these, they're spending between $10,000 to $70,000 per launch video. Yeah. In the age of generative video. Like. They're hiring, you know, actual creative directors, hiring a studio, hiring actors, uh, I was in one of them and like, do you need all that when you have generative video? Like, I think clearly Roy started talking about generative video as well. I don't know if you guys know PJ Ace.

Batuhan [00:43:05]: I think he's like the absolute killer for this stuff.

Swyx [00:43:08]: He, uh, launched like a, is it a Superbowl ad or something? He did like a basketball playoff, NBA finals, right?

Batuhan [00:43:15]: He also did our like series B announcement video, like we're like pretty close with him. And like. It's insane that like what he's able to come up with and how viral it goes, or like, you know, these videos where you spend like hundreds of thousands of dollars, right? You know, like, it's just like, you just need to create viral content and these generative media models are the best way to do it. And we are still at the infancy of this, right? Like, obviously it might not be professional quality. I'd still think like, you know, human in the loop, like mixed, like, you know, content is the way for today, but in six months, who would know like 12 months, I think like 80% of it's going to be generated. Like we were like, we were watching Superbowl and we were like saying, oh, how much of it is going to be generated? And now this video is like AI-generated, it looks like AI-generated, like it could be, right? Like you can't tell.

Swyx [00:43:54]: So like, I think at some point, you know, we're going to have like 80, 90% AI-generated, all that. It reminds me of, I think, who's, who's that guy, Fofur from Replicate, obviously he is the best inspiration for all these workflows. He like overlaid some kind of NBA realistic sort of lore on top of game footage. So you could play like NBA 2K, but it looks like a real video. I saw that, yeah. I was like, what

Swyx [00:44:21]: It's pretty cool. And so maybe, and that's the other part of my question, and I wanted to get into ComfyUI, which is how much lore serving is going on, right? How much custom? A lot. A lot. You know? Okay. Is it like a majority? That's one of the reasons. Not majority, but like, like if it's like 30%, is it like the majority? And everyone trains their own lores, or you pick it off of like a lore marketplace?

Gorkem [00:44:42]: That's why open source works very well with image and video models, because you tap into this big lore ecosystem, everyone. Like. It only, like, I've never seen a closed source model that can create a good lore ecosystem. It just basically doesn't exist. Like maybe there is mid-journey SREFs, but I don't know if you can consider them lores. SREFs are just seeds, right? Conditioning.

Batuhan [00:45:06]: Let's call it like another condition, like a prompt. Yeah.

Gorkem [00:45:08]: Yeah. And then like only the open source models have these rich lore ecosystems and it's extremely, extremely popular.

Batuhan [00:45:15]: But even for like the oldest models, it brings a new life, you know? Like when you see these cool lores. Like you, like there's, we have like still a lot of people using STXL with their own lores because they're happy with the quality. It's fast enough, it's cheap enough. You know, like it's amazing. These models are not single shuttable, like the language models. You can't like, even the editing models, you know, GPT image one or like flux context, whatever, coin image. If you put your face or like, if you put like multiple people, whatever, you can't get the quality. Like it's going to be like 90% there. But if you train for like 1000 steps with like six to 20 images, you're getting like 99% accuracy with like, like the, like we, we worked a lot on like fine tuning the right hyper parameters, like writing like distributed trainers, distributed optimizer stuff. And with those, like people who can train like their lores under 30 seconds now on the platform, run an inference with them in the same job and get like 99% accuracy for the same face character, which is one of the biggest challenges that may be like more on the enterprise side they're facing and less on the consumer side. You know, if you're creating assets. You don't really care who it looks like, but if you, if you are actually like doing a product ad, you want it to like exactly look like the product, every single pixel on the products, you know, banner, whatever you want it to look like that. So you train like a LaCroix Lora with like 20 images. And then like, you know, after that, you're, you're, you have almost a perfect pixel, perfect model.

Alessio [00:46:29]: All right. We had to train a Lora for every guest, then we can make thumbnails with the guest doing.

Swyx [00:46:35]: Yeah. I actually think that's a very good application because it's a nice way to inject brand, but not in a strict style. And.

Gorkem [00:46:42]: We are just entering like post-training on video models and what's that that's going to mean, because we didn't have a good base video model that it made sense. But now we have like companies really investing into like post-training on one, 2.2 or who neon and like creating lip sync models on top of it, creating like different video effects, camera angles. Seems like there's a lot of possibilities with, with like creative data sets that people can do, I think in the next six months to a year, we are going to have. We are going to have a lot of like companies that are just built on post-training of, of open source video models. Wow.

Alessio [00:47:18]: Let's talk about pipelines. So we are Comfy Anonymous on the podcast. Comfy UI is kind of like this community that like, if you're into it, you love it. If you don't know about it, you kind of underestimate in a way, but people create all kind of crazy workflows. One, have you thought about doing pipelines? Obviously you host all the models. There's kind of this question.

Batuhan [00:47:36]: We do have a pipeline product called File Workflows and you can chain models together, but it's obviously less flexible than Comfy where like the, the, you can only. Change like chain different models outputs and not the intermediary stuff in Comfy UI. You can like use like access the latents from like one model and then pass it to like a latent upscale or whatever. In our case, it's like more limited, but we have a workforce product and we have a serverless Comfy product where people can bring their own Comfy UI workflow and run it as an API with just like posting the workflow and inputs. And have the models be served by you. Yes. So is, is that a bullish thing? Is that going to be commoditized by big models? The thing that we saw is as the models get better, like Comfy UI was a. My. Much bigger thing or like, you know, relatively much bigger thing in two years ago, like a year ago when the models were like, you know, one of the biggest Comfy UI use case was you were like generating an ST 1.5 or STXL image and you were fixing six finger situation, you know, like you were fixing like the resolution, you were whatever upscaling. Now that the models are actually so good, the Comfy UI workflows are actually getting simpler for image side for video. It's still very crazy. Like if you look at some video workflows, it's like, there's like 50 nodes, whatever that you're, you're processing. So I think this is still a matter of like how good the models are and how much. Extra stuff you need to do around it for majority of use cases for artistic use cases, you still are doing like all those stuff and that's like something we want to support, but like that, we don't see that happening at super scale, you know, like super scale, there's not companies that are spending like $10 million plus on running this as an API. So that doesn't seem to be happening yet just because it's like a bit inefficient and the more existing, like it's more reliable to use an existing model than patching together 50 different things because you don't know when it's going to not work. Yeah.

Alessio [00:49:07]: But it feels like for things like ads you want to do, you know, once. You're like, you know, like if I'm going to do a new step, which is like maybe generate the backdrop, one step is like adding copy. Are you saying that basically the models are so good.

Gorkem [00:49:17]: Chaining of models happening for sure. But I think ConfUI did very well is you can also play with the pieces of the model. Yeah, you're basically saying that's all. Yeah. So like chaining of the models, like that's what the File Workflow product does. It's basically calls many different APIs back to back or in parallel, and then creates a result at the end, I think. And it is very popular.

Swyx [00:49:37]: We have like enterprise adoption from it, like from very big names. Yeah. Amazing. I was just going to go into sort of broader topics. The first thing that comes to mind was requests for startups. If you're not working on file, but you see a lot of things in the ecosystem. Right. What's the most obvious thing that people should be working on?

Batuhan [00:49:53]: More model companies. Go raise more money and train models. That's obviously good for file. And host them on file. If you're not interested in training models, but like if other people are trained, that's amazing. Go raise more money. There's so much money.

Gorkem [00:50:05]: Or like scale AI for image and video models, like data, data collection. Like more and more prepared data sets for video models, like effects, different camera angles. Everyone seems to be reinventing the wheel when it comes to collecting that data. I think it's a great opportunity for someone to come in and do this at scale.

Swyx [00:50:27]: So it's really interesting because I think this is what Together AI did with Red Pajama is they actually built a data set for language models to help people create more open language models that they can serve. So at some point, like actually it might make sense for you guys to do that. Yeah.

Batuhan [00:50:40]: The image data is a bit more finicky situation, like in terms of like copyright stuff, whatever, but it's an interesting area. Do it in Japan.

Gorkem [00:50:49]: I think it requires focus. It requires, like this needs to be.

Batuhan [00:50:54]: Like one connected thing to what Görkem said is image slash video RL. That's an unknown unknown for us. Say more. I can't. It's like, what does it look like? Can you RL a video model to be a world model? You can, right? Like if you can. Like, it's essentially the verb models aren't RL'd video models where you condition it for like, you know, moving around. So what are the use cases for RL'ing image and video models? I don't know, but that's like if I wasn't working at all, that would be something that like that might be fun to explore. Yeah.

Swyx [00:51:24]: And is this is specifically for editing because the RL is for the reward is the edit or?

Batuhan [00:51:29]: That's the thing. That's, that's what you should look for, right? Like what, what is the reward function, like what is the interesting reward functions that you can apply on top of these base models?

Swyx [00:51:37]: I see. Interesting. Okay. Got it. Actually, I was really asking. But like, if I were to build a file wrapper startup, like on top of that, because you guys are very low level, which is fantastic, you know, but I also want to give our listeners some ideas, you know, if they're not going to work at that level.

Gorkem [00:51:51]: I think I'm going to say it again, advertising advertising, there's so much opportunity there and everyone's like still trying to create these horizontal applications where like any creative can come in and do something, but like a lot more targeted to specific industries, a lot more targeted to like different kinds of products. Kind of like ad networks. There's a lot of potential there. Click.

Swyx [00:52:13]: And then requests for models, obviously you want more open models. That's good for you. But like any like specialization in the models. Like I think image, image editing was a huge unlock, which I didn't foresee until this year.

Batuhan [00:52:26]: Where we're like, oh, obviously we're going to, even OpenAI didn't like guess it was going to go this big. This is like, it's insane. Like how popular it became. And then like everyone started like catching up.

Swyx [00:52:35]: I was part of a group in Europe that we meet in Europe every year and like they were talking about this.

Batuhan [00:53:02]: Swyx and Alessio image models are really, really, really affected by the data set that you use.

Gorkem [00:53:13]: Yeah, I think one obvious thing that there's a gap in the market is like VO3 is very expensive. And the way, the reason why people like it is conversation, right? If you can create maybe a smaller, cheaper video model that is less capable, but can do conversation and sound very well, I think there is definitely...

Batuhan [00:53:31]: One open source one that we saw was Multitalk. It was a post-trained version of one, and it's like really, really good for conversations, but it lost the ability to generalize. You know, it's only like talking faces at some point versus like VO3, it could generalize and it could do scenes and whatever. So I think that there needs to be like some middle ground between these two, between talking faces and like, you know, extremely generalized video models where it's like much cheaper to run. But at the same time, you know, you get like this conversation because it's very memetic. You know, people, there's infinite amount of memes that you can post with this, infinite amount of ads that you can do with this.

Alessio [00:54:05]: But you don't see a world in which you have a video model and then you have a separate, maybe audio-only model that can generate the audio for that video.

Swyx [00:54:11]: This is the word for this question, right?

Gorkem [00:54:13]: Yeah. Do you stitch together a whole bunch of things or do you better less? People did that before VO3, but what VO3 gets very well is like the timing. Almost like you ask for a joke and, you know, the delivery and the timing and the laugh and like, you know, waiting right before like the joke drops, like all of that is so perfectly timed. I don't think when you do it separately, you get it. It's all the same.

Batuhan [00:54:37]: It also matches the human accent sound to the face that is talking, right? It's like, it's an unknown challenge for like other text-to-speech models. Like, it feels very natural. Is VO3 the best text-to-speech model? It is also one of the best text-to-speech models. It is so good. Like, I don't think any model can do what it is.

Alessio [00:54:53]: But I would say the counter argument is that we dub movies. So there's already, you know, obviously you can.

Batuhan [00:55:00]: It is also the best lip-sync model. Like VO3 has the best, most accurate lip-sync because it's generating very natively. There's really good lip-sync models. I think they're like 95% there, but VO3 is like a hundred percent there, like 99%.

Swyx [00:55:11]: To me, this is like the single most bearish thing about workflows, right? And Comfy UI and all this stuff, like, because just wait for a bigger model. Like it's just pure bitter lesson. Like, yeah, we love Comfy UI.

Swyx [00:55:23]: But I mean, obviously like when the technology doesn't exist yet, you have to stitch together things. Yeah. So a request for engineers? Yeah.

Alessio [00:55:30]: I mean, what I'm sure you're hiring, right? You're just raised $125 million. We have a very selective way of hiring.

Batuhan [00:55:36]: Like we just recently. We've been hiring like 100, cross 40 people, but like for like the. Wow. For like three months ago, we were like 20. So like for the last three months we have been actually accelerating, you know, best kernel engineers, best infrastructure engineers, best product engineers, best ML engineers. If you're the best at what you do, just come join us. I think it doesn't really matter what you do. Just like we're just hiring the best talent right now.

Gorkem [00:55:56]: Even on the go-to-market side, we are hiring account executives, customer success managers, because we work with very large enterprises. We got to grow that side of the company as well. Yeah.

Alessio [00:56:07]: On the engineering side specifically, how do you think about how many people you need? There's like this whole question of like lean AI, it's like, you know, coding agent.

Batuhan [00:56:14]: Our performance team is like seven people. I think seven people like focusing on performance always like some of there's some overlap with our applied ML team, which is taking these models, productionizing them, exposing new capabilities, building fine tuners. So it's like a, and then helping customers adapt these models. So that team, I think we can scale to like double, triple the amount because like there's infinite amount of models and like, you know, it's better because like we're going to have more customers with more proprietary models. Yeah. So just like helping them optimize it. It's just like a really good function that we have.

Gorkem [00:56:40]: That team scales very well because there's always like independent work that can be done. Oh, okay. So these three people are working on this new model, trying to optimize that. And it's completely independent from trying to optimize this, this other model. So we've been hiring a lot for, for that applied ML team.

Batuhan [00:56:56]: Our aim for a team, you know, we were probably going to keep it lean in contrast to the applied ML team and the product team, maybe like we want to build more higher level components where people can directly integrate to their applications. Because like, that's even like now there's just like SDK or SDKs, but think about with component, like imagine you're an e-commerce website designer and you're not really like the best like component designer. So here's a virtual try on component that you can put to your app, stuff like that, more higher level components. And this is like also coming from the fact that, you know, wipe coding has been very, very insane. We all, we, we see like significant, like revenue wise, it's like very small, but like we see a significant amount of user adoption just coming from people who are like, like just from looking at our support tickets. Maybe they're like more, they need more support, but like, there's like a lot of people who are like coding these applications without like that much expertise in the product building.

Swyx [00:57:43]: So we want to provide you, provide them more guardrail experiences where they can integrate much easier without like messing with like all the other like lower level components. That's really nice care of developer experience. So crack low level engineers.

Alessio [00:57:57]: And crack high level. Well, yeah, high level engineers, crack engineer, crack go to market people, crack whatever, just your thought.

Swyx [00:58:04]: You know, I'm, I'm always trying to refine the definition. You know, crack, you know, like both of you, like you, you leave the technical side of fail. Like what's a really hard technical problem that if someone has the solution, they should talk to you immediately. Maybe that's the way to frame it.

Batuhan [00:58:16]: Write a sparse attention kernel with FBA on Blackwell and tell, you know, like if you can't do that, come join us. We already have like a good base. Hired on the spot. Hired on the spot, you know, like stuff like that. I really like picking like all these, like some of these applied ML people, like we just picked them from discords who are working on these sort of terms and media who are like already interested. We really have a high culture bar too. Where everyone in the team lost generation media. Like they're obsessed with it. They would have done this if this wasn't their job. We have this great composition. We're always, it's not like a prerequisite, but it's just naturally happened where we hired these people from like discourse, Twitter's hugging face. Like one of our applied ML engineers is like had the number one top hugging face space with like, you know, creative workflows, whatever. So we hired the person who was training Doris on fall, like just because they were training and posting cool Laura's, you know, like just do cool stuff and we'll find you or like you can.

Swyx [00:59:06]: Yeah, that's the master builder is what I've been calling this, this person.

Alessio [00:59:10]: Why not make it more explicit? So if I go on your careers website, right. It's like apply to ML engineer. It just kind of looks like any job description. I feel like there's like this question of like, that's why we have to do a podcast, but I think it's not, it's not just about foul.

Batuhan [00:59:25]: I think in general, more like, if you know, you know, which I know is not the best way, you know, people know about fall already. So it's like, we haven't really cared that much, but you're absolutely right.

Alessio [00:59:35]: Like we should make it more. But if I look at like George hots, like on tiny grad, you have this balance. It's like, Hey, we'll just, if you can solve this, you should probably work here. Like, do you see, I'm adding the bounty, right? It's like, this seems like, Hey, look, if you can write this kernel, it's like, yeah, you'll just get hired.

Batuhan [00:59:51]: It is also about like one thing that we saw, even with like, there's a lot of people who are just like wipe coding stuff and reviewing those. You're like, there's a limited amount of people who can really do those. Right.

Alessio [01:00:00]: Like, so like, like, how can you tell it's like not a shitty kernel or it's like a good call, but then you're spending the time interviewing. Yeah.

Batuhan [01:00:06]: So like, we, we have like first line of defense with our recruiters, whatever. So you only get like, like, so there's like trade-offs, but I, I absolutely agree. Like maybe we should have like a kernel bench version that you can upload your kernels, automatically evaluate the stability, performance, whatever. And then if you do, you get our email unlocked, whatever, especially email for your, for you, but yeah, great ideas. Come join us.

Alessio [01:00:31]: Awesome guys. Anything else? Parting thoughts. Yeah. I love your rant. So this was great. Yeah.

Gorkem [01:00:37]: I'm happy to rant. But this is a podcast style. Yeah.

Swyx [01:00:40]: No, the congrats on all your success. Um, I should also say it's fun to do karaoke with you guys. Yes. Let's do it again. Both extremely technical, but also like a fun crew that like, and I think it's pretty hard to, and rare to, to see. So thank you to see the good guys win.

Alessio [01:00:56]: Awesome guys. Awesome.

The AI Engineer Fall Summit is coming back to NYC - Nov 20-21! Apply now.

In December 2023, we first covered The Four Wars of AI and the RAG/Ops War. After tens of millions poured into vector databases, ups and downs in the hype cycle, we finally have Jeff Huber from Chroma joining us today for the new hot take: “RAG” is dead…

and as context lengths increase, and more and more AI workloads are shifting from simple chatbots to IMPACTful agents, new work from thoughtleaders like Lance Martin and Dex Horthy are making genuine contributions of substance to the previously underrated context box.

Chroma has been driving some of the most interesting research in the new context engineering space, including their Context Rot and Generative Benchmarking reports.

We spent most of our time talking about current state of retrieval, memory, retrieval benchmarking, etc.

1. Don’t ship “RAG.” Ship retrieval. Name the primitives (dense, lexical, filters, re‑rank, assembly, eval loop).

2. Win the first stage with hybrid recall (200–300 candidates is fine—LLMs can read).

3. Always re‑rank before you assemble context.

4. Respect context rot: tight, structured contexts beat maximal windows.

5. Invest one evening in buying some pizza and creating a small gold set; wire it into CI and dashboards.

[Ingest]
├─ Parse + chunk (domain-aware: headings, code blocks, tables)
├─ Enrich: titles, anchors, symbols, metadata
├─ Optional: LLM “chunk summaries” (NL glosses for code/API)
├─ Embeddings (dense) + optionally sparse signals
└─ Write to DB (text, vectors, metadata)

[Query]
├─ First-stage hybrid: vector + lexical/regex + metadata filters
├─ Candidate pool: ~100–300
├─ Re-rank (LLM or cross-encoder) → top ~20–40
└─ Context assembly:
- instructions/system prompt first
- dedupe/merge near-duplicates
- diversify sources
- hard cap on tokens

[Outer loop]
├─ Cache/cost guardrails
├─ Generative benchmarking on small gold sets
├─ Error analysis → re-chunk/retune filters/re-rank prompt
└─ Memory/compaction: summarize interaction traces → retrievable facts

Our podcast studio is at the Chroma office, so it we were excited to finally have our landlord as a guest! Enjoy!

• Chroma

  • Jeff Huber

    • AI is a New Computer

  • Context Rot Technical Report

  • Generative Benchmarking Technical Report

• REALM (Retrieval-Augmented Language Model) Paper

• RETRO (Retrieval-Enhanced Transformer) Paper

• SF Systems Group

• Voyager paper

• [00:00:00] Introductions

• [00:00:48] Why Build Chroma

• [00:02:55] Information Retrieval vs. Search

• [00:04:29] Staying Focused in a Competitive AI Market

• [00:08:08] Building Chroma Cloud

• [00:12:15] Context Engineering and the Problems with RAG

• [00:16:11] Context Rot

• [00:21:49] Prioritizing Context Quality

• [00:27:02] Code Indexing and Retrieval Strategies

• [00:32:04] Chunk Rewriting and Query Optimization for Code

• [00:34:07] Transformer Architecture Evolution and Retrieval Systems

• [00:38:06] Memory as a Benefit of Context Engineering

• [00:40:13] Structuring AI Memory and Offline Compaction

• [00:45:46] Lessons from Previous Startups and Building with Purpose

• [00:47:32] Religion and values in Silicon Valley

• [00:50:18] Company culture, design, and brand consistency

• [00:52:36] Hiring at Chroma: Designers, Researchers, and Engineers

Alessio [00:00:04]: Hey, everyone. Welcome to the Latent Space podcast in the new studio. This is Alessio, partner and CTO at Decibel, and I'm joined by Swyx, founder of SmolAI.

Swyx [00:00:11]: Hey, hey, hey. It's weird to say welcome because obviously, actually, today's guest, Jeff, has welcomed us to Chroma for many months now. Welcome. Thanks for having me. Good to be here. Jeff, you're a founder, CEO of Chroma. I've sort of observed Chroma for a long, long time, especially back in the old office. And you were, you originally sort of got your start in the open source vector database, right? Like you sort of, you're the open source vector database of choice of a lot of different projects, particularly with even, even projects like the Voyager paper, you guys were used in that. I don't even know like the full list, but how do you introduce Chroma today?

Jeff [00:00:48]: It's a good question. I mean, naturally, you always want to kind of take your messaging and make it fit your audience. Yeah. But I think the reason that Chroma got started. Is because we had worked for many years in applied machine learning and we'd seen how demos, demos were easy to build, but building a production reliable system was incredibly challenging and that the gap between demo and production didn't really feel like engineering. It felt a lot more like alchemy. There's some good, like XKCD memes about this guy standing on top of a giant steaming pile of garbage and the other character asks, this is your data system. And he's like, yes. And he's like, how do you know if it, how do you know if it's good or how do you make it better? Oh, you just like stir the pot and then like, see if it gets any better. That just seemed intrinsically wrong. And this is back in like 2021, 2022, that like we were having these conversations. And so that coupled with like a thesis that like Latent Space was a very important tool. That is a plug. Yes, that is a plug. We need to ring the bell. Yeah, exactly. The gong. That Latent Space, both the podcast, but also the technology was a very underrated tool and a very like important tool for interpretability. It's fundamentally how models see their own. Data, we as humans can kind of, you know, have that shared space to understand what's going on. That's where we got started. And so I think that's also where we continue to want to go. Like, what do we want to do? We want to help developers build production applications with AI and what would make the process of going from demo to production feel more like engineering and less like alchemy. Doing a database is like not a side quest. It is a part of the main quest. What we realized along the way was search was really a key workload to how like AI applications were going to get built. It's not the only workload, but it's like definitely a really important. Workload and that you don't earn the right to do more things until you've done one thing at a world class level that requires maniacal and, you know, kind of, uh, maniacal focus. Um, and so that's really what we've been doing for the last few years. That was a long kind of rambling introduction, but like maybe to sort of land the plane, you know, if you ask people, you know, what does Chrome do today? We build a retrieval engine for AI applications. We're working on modern search infrastructure for AI, um, some version of that.

Swyx [00:02:55]: I'll do a double click on this. Is information retrieval and. And search the same thing, or are they slowly different in your mind? I just wanted to clarify our terminology. Yeah.

Jeff [00:03:04]: I think that, you know, that modern search infrastructure for AI, we're going to maybe unpack that for a couple of seconds. So modern is in contrast to traditional. And mostly what that means is like modern distributed systems. So there's a bunch of primitives and building great distributed systems that have come on to the scene in the last five, 10 years that obviously are not in technology that is older than that. By definition, separation of read and write separation of storage, compute, Chrome is written in rust. It's fully multi-tenant, um, we have, we use object storage as a key assistance tier and like data layer for Chroma, uh, distributed in Chroma cloud as well. So that's the modern piece. And then the four AI piece actually, I think is it matters in four kind of different ways. Like four AI means four different things. Like it means number one, the tools and technology that you use for search are different than in classic search systems. Number two, the workload is different than classic search systems. Number three, the developer is different than classic. Search systems and number four, the people who's the person who's consuming those search results is also different than in classic search systems. Think about like classic search systems. Like you as the human, we're doing the last mile of search, you know, you were doing click, click, exactly. You're like, oh, like which of these are relevant, open a new tab, summarize, blah, blah, blah, blah. You, the human we're doing that. And now it's a language model. Humans can only digest 10 blue links. Language models can digest orders of magnitude more. All of these things matter. And I think influence like how a system is designed. Yeah. Yeah. It's sort of like made for.

Alessio [00:04:29]: Back in 2023, I think the VectorDB category was kind of one of the hottest ones. And you had Pinecon raise a hundred million. You had all these different WVAs, all these companies. Yeah. How did you stay focused on like what matter to you rather than just try to raise a lot of money and make a big splash? And it took you a while to release ChromaCloud too, which rather than just getting something out that maybe broke once you got to production, you kind of took your time. Yeah. Can you maybe give people advice on in the AI space, how to be patient? How do you have your own vision as a founder and how to have your own vision that you follow versus kind of like following the noise around you?

Jeff [00:05:03]: There are different ways to build a startup. And so, you know, there's schools of thought here. So one school of thought certainly is like the find signal and kind of follow the gradient descent of what people want sort of lean startup style. My critique of that would be that if you follow that methodology, you will probably end up building a gating app for middle schoolers because that just seems to be like the lowest base take of what humans want to some degree. The slot machine would be the AI equivalent of that versus, you know, the other way to build a startup is to have a very strong view, presumably a contrarian view, or at least a view that seems like a secret. And then to just be maniacally focused on that thing, you know, there are different strokes for different folks, but we've always taken the second approach. And yeah, there was the option of like, okay, Chroma's single node is like doing really well, getting a bunch of traffic. Clearly having a hosted service is the thing people want. Like we could just spend. Uh, we could very quickly get a product in the market, but we felt like no, really what we want Chroma to be known for is our developer experience. Like we want our brand to be, we want Chroma's brand and the craft expressed in our brand to be extremely well known. And we felt like by offering a single node product as a service, like it was not going to meet our bar of like what great developer experience could and should look like. Yeah, we made the decision of like, no, we're going to like build the thing that we think is right, which was really challenging, um, it took a long time and obviously I'm incredibly proud that it exists today and that it's like serving hundreds of thousands of developers and they love it, but it was hard to get there.

Alessio [00:06:38]: When you're building the team, how do you message that? If I go back maybe like a year and a half ago, you know, I could join Chroma, I could join all these different companies. How do you keep the vision clear to people when on the outside you have, oh, I'll just use PG vector or like, you know, whatever else the thing of the day is. Um, do you feel like that helps you bring people that are more aligned with the vision versus more of the missionary type on just joining this company before it's hot and maybe any learning that you have from recruiting early on?

Jeff [00:07:07]: The upstream version of Conway's law, like you ship your org chart is you ship your culture because I think your org chart is downstream of your company's culture. We've always placed an extremely high premium on that, on people that we actually have here on the team. Um, I think that the slope of our future growth is entirely. Dependent on the people that are here in this office and, you know, that could mean going back to zero. That could mean, you know, linear growth. That could mean all kinds of versions of like hyperlinear growth, exponential growth, hockey stick growth. And so, yeah, we've just really decided to hire very slowly and be really picky. And I don't know, I mean, you know, the future will determine whether or not that was the right decision, but I think having worked on a few startups before, like that was something that I really cared about was like, I just want to work with people that I love working with. And. Like want to be shoulder to shoulder with in the trenches. And I think in independently execute on the level of like craft and quality that like we owe developers. And so that was how we chose to do it.

Swyx [00:08:08]: We'll talk about standard condition on the other fun stuff towards the end, but we'll, we'll focus on Chroma. I always want to put like some headline numbers up front. So I'm just trying to do a better job of like giving people the brain dump on what they should know about Chroma. 5 million monthly downloads is what I have on Pi Pi and 21,000 GitHub stars. Anything else people should know, like, that's like the typical sales call, like headline stuff like that, you know?

Jeff [00:08:33]: Yeah. Um, yeah, 20,000 GitHub stars, 5 million plus monthly downloads. Um, I've looked at the number recently, I think it's like over 60 or 70 million all time downloads now for many years running Chrome has been the number one used project broadly, but also within communities like playing chain and a lot of index. Okay, cool. Fair enough. Yeah.

Swyx [00:08:51]: I think like when you say single node Chroma, like I think you're describing the quality. Yeah. Like the core difference between like what Chroma cloud has been, and I think we're releasing this in, in line with like your GA and Chroma cloud. Uh, yes. So like, what should people know about Chroma cloud and like how you've developed this experience from, from the start? Like you, you, you mentioned separation of storage and compute, like what does that. Yeah.

Jeff [00:09:13]: A hundred percent. Chroma is known for its developer experience. I don't know that we were the first to do this. I think we were with Chroma, you just pip install ChromaDB and then you can use it. It's just like in memory. Like, I think you can persist.

Swyx [00:09:25]: It could be the first.

Jeff [00:09:26]: Database to ever be pip installable. Um,

Swyx [00:09:28]: Any SQLite wrapper is pip installable technically, you know? No, SQLite was not like pip installable even to this day. I don't think. Well, you would probably have a, a deeper dive and knowledge of this site. I'm just speculating myself. Yeah.

Jeff [00:09:40]: So that, that led to like a very seamless onboarding experience for new users. Cause you could just run a command and then you could use it. We did all the work to make sure that like, regardless of the deployment target or architecture that you're running it on, like it would just work. In the early days, we had people do really great stuff, like run it on Arduinos and PowerPC architectures and like really esoteric stuff, but like we would like go the extra mile to like, make sure that it worked everywhere and just, it just always worked. So that was Chroma single node. So going back to like the developer experience that we wanted to have in a cloud product, like we felt that in the same way that you could run pip install ChromaDB and be up and running in five seconds and like not have to think about it, you can learn a bunch of abstractions. You don't have to like spend a bunch of time learning, which this is a really complicated API. That same story had to be true. For the cloud. And so what that meant is like having a version of the product where you'd have to be forced to think about like how many nodes you want or how to size those nodes or how your sharding strategy should be, or your backup strategy or your data tiering strategy, or I could go on, like, it just wasn't, wasn't good enough. It needed to be like zero config, zero knobs to tune. It should just be always fast, always very cost-effective and always fresh without you having to do or think about anything. Right. Regardless of how your traffic goes up and down and how your data scale goes up and down. That was sort of the motivating criteria. It also like usage-based billing was really important because that just is like so fair. We only charge you for the minimal slice of compute that you use and like nothing more, which not all serverless databases can claim, but it is true inside of Chroma that we like truly only charge you for the narrow slice of what you use. And so like that was the criteria that we entered kind of the design criteria process.

Swyx [00:11:19]: Which is, you know, de facto, you're also building a serverless compute platform.

Jeff [00:11:23]: Yeah, you have to. No, exactly. That motivated the design of Chroma Distributed. Chroma Distributed is also a part of the same monorepo that's open source Apache 2 and then the control and data plane are both fully open source Apache 2 and then Chroma Cloud uses Chroma Distributed to run a service and that service you can sign up, create a database and load in data in under 30 seconds and this is sort of a time of filming people get like five bucks of free credits, which is actually enough to load in like 100,000 documents and query it 100,000 times, which obviously takes a lot of time. I think for a lot of use cases actually might mean they use it for free for years, which is fine. And to get there, we had to do kind of all the hard work. Yeah.

Swyx [00:12:03]: I think every blog should basically have semantic indexing. So like, you know, you host your personal blog on Chroma, you know, like we're not.

Jeff [00:12:10]: Yeah, I mean, you know, the mission of organizing the world's information remains unsolved.

Swyx [00:12:15]: Yeah.

Alessio [00:12:15]: You have one of your usual cryptic tweets. I need text. You tweeted context engineering a couple months ago. What was it? April. I think everybody.

Jeff [00:12:24]: I think something that's incredibly important when a new market is emerging is abstractions and the primitives that you use to reason about that thing. And AI, I think, in part of its hype, has also had a lot of primitives and abstractions that have gotten thrown around and have led to a lot of developers not actually being able to think critically about what is this thing, how do I put it together, what problems can I solve, what matters, where should I spend my time? For example, the term rag. We never use the term rag. I hate the term rag.

Swyx [00:13:08]: Yeah, I killed the rag track partially because of your influence.

Jeff [00:13:10]: Thank you. Thank you. A is just retrieval, first of all. Like, retrieval, I've been a generation. Are three concepts put together into one thing? Like, that's just really confusing. And, of course, rag got known now as these branded as, like, you know, oh, you're just using single dense vector search, and that's what rag is. It's also dumb. I think one of the reasons I was really excited about the term, I mean, obviously, AI engineering, which you did a ton of work for, like, context engineering is in some ways a subset of AI engineering. Like, what is it? It's a high-status job. Context engineering is the job of figuring out what should be in the context window. Any given LLM generation step. And there's both an inner loop, which is setting up the, you know, what should be in the context window this time. And there's the outer loop, which is how do you get better over time at filling the context window with only the relevant information. And we recently released a technical report about context rot, which goes sort of in detail, in depth about how the performance of LLMs is not invariant to how many tokens you use. As you use more and more tokens, the model can pay attention to less and then also can reason sort of less effectively. I think this really motivates the problem. You know, context rot implies the need for context engineering. And I guess, like, why I'm really excited about the meme and, you know, I got maybe both lucky to some degree that, you know, called it back in April, this is going to be a big meme, is that it elevates the job to, it clearly describes the job and it elevates the status of the job. This is what, frankly, most AI startups, any AI startup that you know of that you think of today that's doing very well, like, what are they fundamentally good at? What is the one thing that they're good at? It is context engineering.

Swyx [00:14:45]: Particularly, I would feel like a lot of pieces I've read, a lot of it focuses on agents versus non-agent stuff. Like, the context engineering is more relevant for agents. Do you make that distinction at all? Or you're just looking at context engineering generally?

Jeff [00:15:00]: No. I mean, there's interesting agent implications of, like, you know, agent learning, you know, can agents kind of learn from their interactions, which maybe are less relevant and like static sort of knowledge-based corpuses, chat your documents, obviously. Then again, like, you know, I think you could make the argument that even, like, chat your document use cases, like, should get better with more interactions. I don't draw a distinction between agent and non-agent. I don't actually know what agent means still, but, again, impermitted subtractions, words, they matter. I don't know. Like, what does agent mean? I don't know. Well, there's many definitions out there. Exactly. I've taken a stab. Most terms that can mean anything are just a vehicle for people's hopes and fears. Yeah. I think, you know, agent is the same thing. For sure.

Swyx [00:15:42]: Well, maybe we'll try to be more. More concise or precise about context engineering so that it doesn't, it actually means something and, you know, people can actually use it to do stuff. One thing I definitely will call out for context engineering or context rot in general is I think that there's been a lot of marketing around needle in a haystack, where every frontier model now comes out with, like, completely green, perfect charts of full utilization across, you know, 1 million tokens. I'm wondering what you guys' takes are on that kind of marketing. Yeah. Yeah.

Jeff [00:16:11]: So maybe back up a little bit. But the way that we came to work on this research was we were looking actually at agent learning. So we were very curious, like, could you give agents access to, like, prior successes or prior failures? And if you did, would that help boost agent performance? So we were specifically looking at a couple different data sets, SweetBench inclusive, and we started seeing interesting patterns where, like, on sort of multi-turn agent interactions where you're giving it the whole conversation window, like, the number of tokens explodes extremely quickly and instructions that were clearly in there, like, were being ignored and were not being announced. And we're like, oh, that clearly is a problem. We've now felt the pain. It was sort of a meme amongst people in the know that, like, this was true. And, like, I think also, you know, some of the research community's reaction to the context rot technical report is like, yeah, we know. And, you know, that's fine. Nobody else knew. And, like, it's kind of nice if, like, you can actually teach builders what is possible today versus what is not possible today. I don't blame the labs. I mean, building models is so insanely competitive. Everybody invariably is, like, picking the benchmarks that they want to do the best on. They're training around those. Those are also the ones that, you know, find their way into their marketing. You know, most people are not motivated to come out and say, here are all the ways that our thing is great, and here are all the ways that our thing is not great. You know, I don't know. I have some sympathy for, you know, why this was not reported on. But, yeah, I mean, there was this bit of, like, this sort of implication where, like, oh, look, our model is perfect on this task, needle in a haystack. Therefore, the context window you can use for whatever you want. There was an implication there. And, well, I hope that that is true someday. That is not the case. Yeah.

Swyx [00:17:43]: We'll send people, at least on the YouTube video, we'll put this chart, which is kind of your figure one of the context route report. It seems like Sonnet 4 is the best in terms of area under curve, is how I think about it. Then Quinn, wow. And then GPC 4.1 and Gemini Flash are degraded a lot quicker in terms of the context length. Yeah.

Jeff [00:18:03]: I don't have much commentary. That is what we found for this particular task. Again, how that translates to people's actual experience in real world, you know, tasks is entirely different. I mean, there is a certain amount of love that developers have for Claude and, like, maybe those two things are correlated. Yeah. I think it shows here if this is true, that's a big explanation for why. You follow my instructions, you know, like, here's a clear baseline, you know, thing people want.

Swyx [00:18:27]: I don't think it's super answered here, but I have a theory also that reasoning models are better at context utilization because they can loop back. Normal autoregressive models, they just kind of go left to right. But reasoning models, in theory, they can loop back and look for things that they need. They need connections for that they may not have paid attention to in the initial pass. There's a paper today that showed, I think, maybe the opposite. Really?

Jeff [00:18:49]: I'll send it to you later. Yeah.

Swyx [00:18:50]: That'd be fascinating to figure out.

Alessio [00:18:52]: There's papers every day. I thought the best thing was that you did not try to sell something. You're just like, hey, this thing is broken. Kind of sucks. How do you think about problems that you want to solve versus research that you do to highlight some of the problems and then hoping that other people will participate? Like, does everything that you talk about? Is it on the Chroma roadmap, basically? Or are you just advising people, hey, this is bad, work around it, but don't ask us to fix it?

Jeff [00:19:20]: Going back to what I said a moment ago, like, Chroma's broad mandate is to make the process of building applications more like engineering and less like alchemy. And so, you know, it's a pretty broad tent, but we're a small team and we can only focus on so many things. We've chosen to focus very much on one thing for now. And so I don't think that I don't have the hubris to think that we can ourselves solve. This stuff conclusively for a very dynamic and large emerging industry, I think it does take a community, it does take like a rising tide of people all working together. We intentionally wanted to, like, make very clear that, like, we do not have any, like, commercial motivations in this research. You know, we do not posit any solutions. We don't tell people to use Chroma. It's just here's the here's the problem.

Swyx [00:20:02]: It's implied.

Jeff [00:20:05]: Listen, we weren't sad that that was maybe and maybe it may be a positive vacation, you know, but it's still there's no reasons around that. But, you know, speed and cost regardless, I think. But there's just a lot of work to do. And I think that, like, it's interesting where, like, the labs don't really care and they're not motivated to care increasingly as the market to be to be a good LLM provider. The main market seems to be consumer. You're just not that motivated to, like, help developers as a secondary concern, as a secondary concern. And so you're not that motivated really to do the legwork to, like, help developers learn how to build stuff. Yeah. And then, like, if you're a SaaS company or you're a consumer company, you're building with AI, you're an AI native company. Like, this is your, like, this is your secret sauce. You're not going to market how to do stuff. And so, like, I mean, it's just like there's a natural empty space, which is people that are actually have the motivations to, like, help show the way for how developers can build with AI. Like, they're just there's not a lot of obvious people who are, like, obviously invest in their time and energy in that. But I think that is obviously a good thing for us to do. And so that's kind of how I thought about it.

Swyx [00:21:02]: Just a pushback on the consumer thing. Like, you say labs and, you know, don't you think, like, opening eye, building memory into ChatGPT and making it available to literally everyone? I mean, it's probably too much in your face, I would argue, but, like, they would really care to make the memory utilization good. I think context utilization, context engineering is important for them, too, even if they're only building for consumer and don't care about developers.

Jeff [00:21:25]: Yeah. How good is it today is obviously one important question, but we'll skip that one. Like, even if that's the case, are they actually going to publish those findings? No, Exactly. It's alpha, right? Why would you give away your secrets? Yeah. And so I think there's just, like, very few companies that actually are, like, in the business. I think there's a position where, like, they have the incentive and they really care about, like, trying to teach developers how to build useful stuff with AI. And so I think that we have that incentive.

Alessio [00:21:49]: But do you think you could get this to grow to the point of being the next needle in a haystack and then forcing the model's providers to actually be good at it?

Jeff [00:21:57]: There's no path to forcing anybody to do anything. And so we thought about that when we were kind of putting this together. Like, oh, maybe we should, like, sort of formulate this as a formal benchmark that you can make it very easy to, like, we did open source, all the code. So, like, you could. You know, if you're watching this and you're from a large model company, you can do this. You can take your new model that you haven't released yet and you can run, you know, these numbers on it. And, you know, I would rather have a model that has a 60,000 context, token context window that is able to perfectly pay attention to and perfectly reason over those 60,000 tokens than a model that's, like, 5 million tokens. Like, just as a developer, the former is, like, so much more valuable to me than the latter. I certainly hope that model providers do, like, pick this up as something that they care about and that they train around and that they, you know, evaluate their progress on and they communicate to developers. As well. That would be great.

Alessio [00:22:42]: Do you think this will get a better lesson as well? How do you decide which of the... Because, you know, you're busy saying, yeah, the models will not learn this. It's going to be a trick on top of it that you won't get access to. I'm not saying that. Well, but when you're saying that they will not publish how to do it, well, it means that the model API will not be able to do it, but they will have something in ChatGPT that will be able to do it. I see. Yeah.

Jeff [00:23:04]: It's very risky to bet what's going to be a better lesson versus what is not. I don't think I'll hazard a guess. Hopefully not AI engineers. Yeah. Hopefully not all of humanity. I don't know. You know, yeah.

Swyx [00:23:14]: To me, also an interesting discipline developing just around context engineering. Lance Martin from Langchain did a really nice blog post of like all the different separations. And then you in New York, you had, you hosted your first meetup. We're going to do one here in San Francisco as well. But I'm just kind of curious, like, what are you seeing in the fields? Like who's doing interesting work? What are the top debates? That kind of stuff.

Jeff [00:23:37]: I think this is still... I mean, a lot of people are doing nothing. A lot of people are just still eating everything into the context window. That is very popular. And you know, they're using context caching and that certainly helps, but like there are costs and speed, but like isn't helping the context problem at all. And so, yeah, I don't, I don't know that there's lots of best practices in place yet. I mean, I'll highlight a few. So the problem fundamentally is quite simple. It's, you know, you have N number of sort of candidate chunks and you have Y spots. Available and you have to do the process to curate and cull down from 10,000 or a hundred thousand or a million candidate chunks, which 20 matter right now for this exact step. That optimization problem is not a new problem to many applications and industries, sort of a classic, um, a classic problem. And of course, like what tools people use to solve that problem. Again, I think it's still very early. Um, it's hard to say, but a few patterns that I've seen. So one pattern is to use what a lot of people call first stage retrieval to do a big cull down. So that's to be using signals like vector search, like full text search, like metadata filtering, metadata search, and others to go from, let's say 10,000 down to 300. Like we were saying a moment ago, like you don't have to give an LLM 10 blue links. You can brute force a lot more. And so using an LLM as a re-ranker and brute forcing from 300 down to 30, I've seen now emerging. A lot, like a lot of people are doing this and it actually is like way more cost effective than I think a lot of people realize I've heard of people that are running models themselves that are getting like a penny per million input tokens and like the output token cost is basically zero because it's like, uh, you know, the simplest. These are dedicated re-ranker models, right? Not no LLMs. No, these are LLMs. Okay. They're just using LLMs as re-rankers. Okay. And of course there are also dedicated re-ranker models that by definition are going to be so like cheaper because they're much smaller and faster. Cause they're much smaller. But like what I've seen emerge is like application developers who already know how to prompt are now applying that tool to re-ranking. And I think that like, this is going to be the dominant paradigm. I actually think that like probably purpose built re-rankers will go away. And the same way that like purpose built, they'll still exist, right? Like if you're at, if you're at extreme scale, extreme cost, yes, you'll care to optimize that. And the same way that if you're running with hardware, right? Like you're just going to use a CPU or GPU. Unless you absolutely have to. You don't have to have an ASIC or an FPGA and I think the same thing is true about like re-rankers where like, as LLMs become a hundred, a thousand times faster, a hundred, a thousand times cheaper that like people are just going to use LLMs for re-rankers and that actually like brute forcing information curation is going to become extremely, extremely popular. Now today, the prospect of running 300 parallel LLM calls, even if it's not very expensive, you know, the tail latency on any one of those like 300 LLM calls. And so like, there are good reasons to not do that today in a production application, but those will also go away over time. So those patterns I think I've seen emerge that are, that, that's a, that is a new thing that I think I've only seen start to really become popular in the last few months. And by popular, I mean like popular in like the leading tip of the spear, but I think will become a very, very dominant paradigm. Yeah.

Swyx [00:27:02]: We've also covered a little bit on, especially on the code indexing side of the house. So everything we've been talking about applies to all kinds of contexts. I think code is obviously a special kind of context and corpus that you want to index. We've had a couple of episodes, the cloud code guys and the client guys talk about, they don't embed or they don't index your code base. They just give tools and use the tools to code search. And I've often thought about whether or not like this should be the primary context retrieval paradigm where when you build an agent, you effectively call out to another agent with all these sort of recursive re-rankers and summarizers or another agent with tools. Yep. Or do you sort of glom them on to a single agent? I don't know if you have an opinion, obviously, because agent is very ill-defined, but I'll just put it out there.

Jeff [00:27:47]: Okay. Got to pull that apart. So, you know, indexing by definition is a trade-off. Like when you index data, you're trading write time performance for query time performance, you're making it slower to ingest data, but much faster to query data, which obviously scales as data sets get larger. And so like, if you're only grepping very small, you know, 15 file code bases, you probably don't have to index it. And that's okay. If you want to search all of the open source dependencies of that project, you all have done this before in VS code or cursor, right? You've run a search over like the node modules folder. It takes a really long time to run that search. That's a lot of data. Like, so to make that indexed and sort of, again, make that trade off of write time performance or query time performance. Like that's what, that's what indexing is like, just like demystify it. What is this? Right? Like, that's what it is. You know, embeddings are known for semantic similarity today. Embeddings is just a generic concept of like information compression, and there's actually like many tools you can use embeddings for, I think embeddings for code are still extremely early and underrated, but regex is obviously an incredibly valuable tool and, you know, we've actually worked on now inside of Chroma, both single load and distributed, we support regex search natively. So you can do regex search inside of Chroma because we've seen that as like a very powerful tool for code search. It's great. And we build indexes to make regex search go fast at large. So you can do regex search data volumes on the coding use case that you mentioned. Another use case that another feature we added to Chroma is the ability to do forking. So you can take an existing index and you can create a copy of that index in under a hundred milliseconds for pennies. And in so doing, you then can just apply the diff for what file has changed to the new index. So any like corpus of data that's logically changing. So very fast re-indexing is the result. But now you can like have an index for like different each commit. So if you want to search different commits to search different branches or different release tags, like any corpus of data that's like a logically versioned, you now can search all those versions very easily and very cheaply and cost-effectively. And so, yeah, I think that, you know, that's kind of how I sort of think about like regex and indexing and embeddings. I mean, yeah, the needle continues to move here. I think that anybody who claims to have the answer, you just like shouldn't listen to them.

Jeff [00:30:02]: When you said that code embeddings are underrated, what do you think that is? Most people just take generic embedding models that are trained on the internet. And they try to use them for code. And like, it works okay for some use cases, but does it work great for all use cases? I don't know. Another way to think about these different primitives and what they're useful for, fundamentally, we're trying to find signal. Text search works really well. Lexical search, text search works really well. When the person who's writing the query knows the data. If I want to search my Google Drive, I just, for the spreadsheet that has all my investors, I'm just going to type in cap table. Because I know. Spreadsheet in my Google Drive called cap table. Full text search, great. It's perfect. I'm a subject matter expert in my data. Now, if you wanted to find that file and you didn't know that I had a spreadsheet called cap table, you're going to type in the spreadsheet that has the list of all the investors. And, of course, in embedding space, in semantic space, that's going to match. And so, I think, again, these are just like different tools. And it depends on like who's writing the queries. It depends on what expertise they have in the data. Like what blend of those tools is going to be the right fit? My guess is that. Like for code today, it's something like 90% of queries or 85% of queries can be satisfactorily run with Regex. Regex is obviously like the dominant pattern used by Google Code Search, GitHub Code Search. But you maybe can get like 15% or 10% or 5% improvement by also using embeddings. Very sophisticated teams also use embeddings for code as part of their code retrieval code search stack. And, you know, you shouldn't assume they just enjoy spending money on things unnecessarily. They're getting some, they're eking out some benefit there. And, of course, like for companies that want to be like top of their game and want to like, you know, corner their market and want to serve their users the best. This is kind of what it means to build great software with AI. 80% is quite easy. But getting from 80% to 100% is where all the work is. And like, you know, each point of improvement like is a point on the board. And it's a point that like I think users care about. And it's a point that you can use to, yeah, fundamentally just like serve your users better.

Alessio [00:32:04]: Do you have any thoughts on the developer experience versus agent experience? Like this. This is another case where, well, we should maybe reformat and rewrite the code in a way that it's easier to embed and then train models there. Where are you on that spectrum? Yeah.

Jeff [00:32:19]: I mean, one tool that I've seen work well for some use cases is instead of just embedding the code, you first have an LLM generate like a natural language description of like what this code is doing. And either you embed like just the natural language description or you embed that and the code or you embed them separately and you put them in like separate, you know. Vector search indexes, chunk rewriting is kind of like the broad category of like what that is. Again, this is like the idea here is like it's related to indexing, which is as much structured information as you can put into your write or your ingestion pipeline, you should. So all of the metadata you can extract, do it at ingestion. All of the chunk rewriting you can do, do it at ingestion. If you really invest in like trying to extract as much signal and kind of pre-bake a bunch of the signals at the ingestion side. I think it makes the downstream query task like much easier. But also, you know, just because we're here, like it's worth saying like people should be creating small golden data sets of what queries they want to work and what chunks should return. And then like they can quantitatively evaluate what matters. Maybe you don't need to do a lot of fancy stuff for your application. It's entirely possible that, again, just using regex or just using vector search, depending on the use case, that's maybe all you need. I guess, again, anybody who's claiming to know the answer. You should, the first thing you should ask is, let me see your data. And then if they don't have any data, then you have your answer already.

Swyx [00:33:47]: I'll give a plug to a talk that you gave at the conference, how to look at your data. Yes. Looking at your data is important. Having, having golden data sets. These are all like good practices that I feel like somebody should put into like a little pamphlet, call it the 10 commandments of AI engineering or something. Okay. You might do that. Yeah. Thou shall look at your data.

Swyx [00:34:07]: We're about to move on to memory, but like, I want us to sort of leave it there.

Jeff [00:34:09]: I want us to sort of leave space for like, you know, any other threads that you feel like you always want to get on a soapbox about that, yeah, that's a dangerous, that's a dangerous thing to ask.

Swyx [00:34:18]: I have one to, to key off of, because I think, uh, I didn't, I didn't know, I didn't, I didn't know where to insert this in the conversation, but we're kind of skirting near it that I'm trying to explore, which is, you know, uh, I think you had this rant about R, A, and G where the original transformer was sort of like an encoder decoder architecture. Hmm. Then GBT turns, uh, most transformers. Transformers into decoder only, but then we're also encoding with all the, um, um, embedding models as encoder only models. So in some sense, we sort of decoupled the transformer into first, we encode everything with the encoder only model, put it into a vector database like chroma and chroma also does other stuff, but you know, um, then, then we decode with, uh, the LMS. And I just think it's like a very interesting meta learning about the. The overall architecture, like it is stepping out of just the model to models and system. And I'm curious if you have any reflections on that or if you have any modifications to what I just said.

Jeff [00:35:20]: I think there's some intuition there, which is like the way we do things today is very crude and we'll feel very caveman and five or 10 years, you know, why aren't we just, why are we going back to natural language? Why aren't we just like passing the embeddings like directly to the models who are just going to functionally like re put it into latent space. Right. Yeah. They have a very thin embedding layer. Yeah. Yeah. So I think like, there's a few things that I think might be true about retrieval systems in the future. So like number one, they just stay in latent space. They don't go back to natural language. Number two, instead of doing like, this is actually starting out to change, which is really exciting, but like for the longest time we've done one retrieval per generation. Okay. Do you retrieve, and then you stream out and number of tokens, like, why are we not continually retrieving as we need to, um, don't call it, um, but there was a paper or a paper in a, in a, you know, maybe like a. Like a GitHub that came out a few weeks ago, I think it was called, unfortunately rag R one where they like teach, uh, DCR one, you know, kind of give it the tool of how to retrieve. And so like kind of in its internal chain of thought and it's in for tense compute, it's actually like searching.

Swyx [00:36:22]: There's also retrieval, augmented language models.

Jeff [00:36:24]: I think this is an older paper. Yeah. Yeah. There's a bunch of realm and retro and it's kind of long history here. Um, so I think that, you know,

Swyx [00:36:31]: Somehow not that popular.

Jeff [00:36:32]: I don't know why. Somehow not that popular. Well, there are a lot of those have the problem where like either the retriever or the language model has to be. Frozen. And then like the corpus can't change, which most developers don't want to like deal with the developer experience around.

Swyx [00:36:45]: I would say like, we would do it if, if the gains were that high or the labs don't want you to do it. I don't know about. Yeah.

Jeff [00:36:54]: Cause the labs have a huge amount of influence. Lots of huge amount of influence. I think it's also just like, you don't get, you don't get points on the board by doing that. Well, you just like, don't, no one cares. The status games don't, don't reward you for solving their problem. So yeah. So broadly. Continual retrieval, I think will be interesting to see come out of the scene. Number one, number two, staying in embedding space will be very interesting. And then, yeah, there's some interesting stuff also about kind of like GPUs and how you're kind of like paging information into memory on GPUs that I think can be done like much more efficiently. Um, and this is more like five or 10 years in the future that we're kind of thinking about, but yeah, I think, I think when we look back in things, this was like, like hilariously crude, the way we do things today.

Swyx [00:37:34]: Maybe, maybe not, you know, we're solving IMO, uh, challenges with. Just language, you know? Yeah, it's great. I'm still working on the implications of that. Like it's, it's still a huge achievement, but also very different than how I thought we would do things.

Alessio [00:37:47]: You said that memory is the benefit of context engineering. I think there's a, you, you had a random Twitter about stop making memory for ISO complicated. How do you think about memory? And it's what are like maybe the other benefits of context engineering that maybe we were not connecting together?

Jeff [00:38:06]: I think memory is a good term. It is very legible to a wide population. Again, this is sort of just continuing the anthropomorphization of LMS. You know, we ourselves understand how we are, we, as humans use memory. We're very good at, well, some of us are very good at using memory to learn how to do tasks. And then those learnings being like flexible to new environments and, you know, the idea of being able to like take an AI, sit down next to an AI and then instruct it for 10 minutes or a few hours. And kind of. Just like tell it what you want it to do. And it does something and you say, Hey, actually do this next time. The same that you would with a human at the end of that 10 minutes at the end of those few hours, the AI is able to do it now and the same level of reliability that a human could do it like is an incredibly attractive and exciting vision. I think that that will happen. And I think that memory again is like the memory is the term that like everybody can understand, like we all understand our moms all understand and, and, and the benefits of memory are also very appealing. And very attractive, but what is memory under the hood? It's still just context engineering, I think, which is the domain of how do you put the right information into the context window? And so, yeah, I think of memory as the benefit context engineering is the tool that gives you that benefit. And there may be stuff as well. I mean, maybe there's some version of memory where it's like, oh, you're actually like using RL to improve the model through data scene. And so I'm not suggesting that like only changing the context is the only tool which, you know, gives you. Great performance on tasks, but I think it's a very important part.

Alessio [00:39:43]: Do you see a big difference between synthesizing the memory, which is like, based on this conversation, what is the implicit preference? Yeah, that's one side. And then there's the other side, which is based on this prompt, what are the memories that I should put in?

Jeff [00:39:58]: I think they will be all fed by the same data. So the same feedback signals that tell you how to retrieve better will also tell you what to remember better. So I don't think they're actually different problems. I think they're the same problem.

Swyx [00:40:13]: To me, the thing I'm wrestling with a little more is just what are the structures of memory? That makes sense. So there's like obviously all these analogies with like long term memory, short term memory, let us try to coin something around sleep. I do think that there definitely should be some sort of batch collection cycle, maybe sort of garbage collection cycle where it's like where the LLM is sleeping. But I don't know what. I don't what makes sense, like we're making all these analogies based on what we think, how we think humans work, but maybe AI doesn't work the same way. Yeah. I'm curious about anything that you've seen that's working.

Jeff [00:40:48]: Yeah, I always, again, you know, as a through line of this conversation, I always get a little bit nervous when we start creating new concepts and new acronyms for things. And then all of a sudden there's, you know, info charts that are like, here are the 10 types of memory. And you're like, why? These are actually, if you squint, they're all the same thing. Like, do they have to be different? You know, like. You have to blow the people's minds. No, I don't think you do. I don't know. You got to resist the slot machine, the slot and the slot machine.

Jeff [00:41:16]: Compaction has always been a useful concept in. Even in databases. In databases on your computer. We all remember running Defrag on our Windows machines in 1998. And, you know, so, yeah, again. Some of us not old enough to do that. I am. Not at this table. And yeah. So obviously, obviously. Offline processing is helpful, and I think that is also helpful in this case. And as you're talking about before, like, what is the goal of indexing? The goal of indexing is to, like, trade write time performance for query time performance. Compaction is another tool in the toolbox of, like, sort of write time performance. You're re-indexing data.

Swyx [00:41:52]: It's not indexing, but actually it is indexing.

Jeff [00:41:55]: It's sort of re-indexing. Yeah. You're taking data. You're like, oh, maybe those two data points should be merged. Maybe they should be split. Maybe they should be, like, rewritten. Maybe there's new metadata we can extract from those. Like, let's look at the signal of how our application is performing. Let's try to figure out, like, are we remembering the right things or not? Like, the idea that there is going to be, like, a lot of offline compute and inference under the hood that helps make AI systems continuously self-improve is a sure bet.

Alessio [00:42:19]: Part of the sleep time compute thing that we talked about was pre-computing answers. So based on the data that you have, what are likely questions that the person is going to ask? And then can you pre-compute those things? How do you think about that in terms of Chroma? We released a technical report. Yeah.

Jeff [00:42:35]: We released a technical report maybe three months ago. The title is Generative Benchmarking. And the idea there is, like, well, having a golden data set is really powerful. What a golden data set is is you have a list of queries and you have a list of chunks of those queries should result in. And now you can say, okay, this retrieval strategy gives me, for these queries, gives me 80% of those chunks. Whereas if I change the embedding model, now I get 90% of those chunks. That is better. And then you also need to consider cost and speed and API reliability. And other factors, obviously, when making good engineering decisions. But, like, you can measure now, like, changes to your system. And so what we noticed was, like, developers had the data. They had the chunks. They had the answers. But they didn't have the queries. We did a whole technical report around how do you teach an LLM to write good queries from chunks? Because, again, you want, like, chunk query pairs. And so if you have the chunks, you need the queries. Okay. We can have a human do some manual annotation, obviously. But humans are not. They're inconsistent and lazy. And, you know, QA is hard. And so can we teach an LLM how to do that? And so we sort of did a whole technical report and proved a strategy for doing that well. So I think generating QA pairs is really important for benchmarking your retrieval system, golden data set. Frankly, it's also the same data set that you would use to fine-tune in many cases. And so, yeah, there's definitely something, like, very underrated there. Yeah.

Swyx [00:43:58]: I'll throw a plus one on that. I think as much attention as the context rock paper is getting, I feel like generative benchmarking was a bigger aha moment. For me, just because I actually never came across a concept before. And I think, like, actually more people will apply it to their own personal situations. Whereas context rock is just generally, like, yeah, don't trust the models that much. But there's not much you can do about it except do better context engineering. Yeah. Yes. Yes. Whereas generative benchmarking, you're like, yeah, generate your evals. And, you know, part of that is you're going to need the data sets. And it'll sort of fall you into the place of all the best practices that everyone advocates for.

Jeff [00:44:34]: So it's really a nice piece of work. I think having worked in applied machine learning developer tools now for 10 years, like, the returns to a very high-quality small label data set are so high. Everybody thinks you have to have, like, a million examples or whatever. No. Actually, just, like, a couple hundred even, like, high-quality examples is extremely beneficial. And customers all the time, I say, hey, what you should do is say to your team Thursday night, we're all going to be in the conference room. We're ordering pizza. And we're just going to have a data labeling party for a few hours. That's all it takes to bootstrap this.

Swyx [00:45:08]: Google does this. OpenAI does this. Anthopic does this. You are not above doing this. Great. Yeah. Exactly. Yeah. Yeah. Look at your data. Again, it's what matters. Maybe you should classify that as label your data, not look at. Because look at seems a bit too… I agree with that. Yeah. There's some more… View only. Right. I agree with that. Yeah. Read and write. Read and write. While you mentioned it, I should correct myself. It wasn't standard cognition. It was standard cyborg. My favorite fact about you is you're also a cyborg with your leg. True. People… If you see Jeff in person, you should ask him about it. Or maybe not. Maybe don't. I don't know. I don't care. Don't care. Standard cyborg, mighty hive, and know it. What were those lessons there that you're applying to Chroma? Yeah.

Jeff [00:45:46]: More than I can count. I mean, it's a bit of a cliche. It's very hard to be self-reflective and honest with yourself about a lot of this stuff. But I think viewing your life as being very short. And kind of a vapor in the wind. And therefore only doing the work that you absolutely love doing. And only doing that work with people that you love spending time with. And serving customers that you love serving. Is a very useful North Star. And it may not be the North Star to print a ton of money in some sense. There may be faster ways to scam people into making $5 million or whatever. So. But if I reflect on. And I'm happy to go into more detail obviously. But if I reflect on my prior experiences. I was always making trade-offs. I was making trade-offs with the people that I was working with. Or I was making trade-offs with the customer that I was serving. Or I was making trade-offs with the technology and how proud I was of it. And maybe it's sort of like an age thing. I don't know. But the older that I get, I just more and more want to do the best work that I can. And I want that work to not just be great work. But I also want it to be seen by the most number of people. Because ultimately that is what impact looks like. Impact is not inventing something great. And then nobody using it. Like impact isn't inventing something great. As many people using it as possible.

Swyx [00:47:01]: Is any of that, you know, and we can skip this question if it's sensitive. But like, is any of that guided by religion, by Christianity? And I only ask this because I think you're one of a growing number of openly, outwardly, positively religious people in the Valley. And I think that it's kind of what I want to explore. You know, I'm not, I'm not like that religious myself, but I just kind of like, how does that inform how you view your impact? Your, you know, your choices that there was a little bit of, of that in what you just said, but I wanted to sort of tease that out more.

Jeff [00:47:32]: I think increasingly modern society is nihilist. Nothing matters. It's a absurdist, right? Everything is a farce. Everything is power. Everything's a comedy. Everything's a comedy. A meme. Yeah. Yeah, exactly. And so like, it's very rare. And I'm not saying that I always end the life. Living exemplar of this, but like, it's very rare to meet people that have genuine conviction about what flourishing for humanity looks like. And that's very rare to meet people that are like actually willing to sacrifice a lot to like make that happen and to start things that like they may not actually see complete in their lifetimes. Like it used to be commonplace that people would start projects that would take centuries to complete. Yeah. And you know, now that's like less and less the case.

Swyx [00:48:23]: The image that comes to mind is the Sagrada Familia in Barcelona, which I think was started like 300 years ago and it's completing next year. Yeah.

Jeff [00:48:33]: I've seen it in construction, but I can't wait to see it complete as well. Yeah. I'm sure the places are booked out already. Yeah. Yeah. And so, you know, it's, it's common. There are actually, you know, a lot of like religions in Silicon Valley. I think AGI is also a religion. It has a problem of evil. We don't have enough intelligence. It has a solution, a deus ex machina. It has the second coming of Christ that AGI, the singularity is going to come. It's going to save humanity because we will now have infinite and free intelligence. Therefore, all of our problems will be solved. And, you know, we will live in sort of like the palm of grace for all eternity. It's going to solve death. Right. And so like, I think that like religion still exists in Silicon Valley. I think that it's like, you know, there's a conservation of religion and you kind of can't get rid of it. Yeah. But. The God gene. Yeah. I mean, you know, you have different terms for this. But like, I think that. I'm always skeptical of religions that haven't been around for more than five years. Put it that way. Yeah.

Swyx [00:49:27]: There's a survivorship bias. Anyway, I do think like you're one of the more prominent ones that I know of. And I think you guys are a force for good. And I like to encourage more of that. I don't know. You know, people should believe in something bigger than themselves and build for plant trees under which they will not sit. Am I mangling the quote? Is that actually a biblical quote? I don't think it's a biblical quote. But I like that quote. That's a good one.

Jeff [00:49:52]: So, yeah.

Swyx [00:49:52]: Plus one. Like, I think society is really collapsed when, like, you just live for yourself. That really is true. Agreed.

Alessio [00:49:59]: Who does your design? Because all of your swag is great. Your office looks great. The website looks great. The docs look great. How much of that is your input? How much of that do you have somebody who just gets it? And how important is that to, like, making the brand part of the culture?

Jeff [00:50:18]: I think all value, you know, again, going back to the question of, you know, the culture, like, the Conway's Law thing, like, you ship your org chart, you ship what you care about as a founder in some sense. And, like, I do care deeply about this aspect of what we do. And so I think it does come from me in some sense. I can't take at all credit for everything we've done. We've had the opportunity to work with some, like, really talented designers. And we're hiring, as well, for that. So if people, you know, are listening to this and want to apply, please do. I think, I mean, it's cliche to crib Patrick Collison quotes, but he does seem to be, you know, one of the, like, most sort of public embodiers of this idea that, like, how you do, and I'm not sure this is a dark quote from him, to be clear, this is more of just a broad aphorism, but, like, how you do one thing is how you do everything. And just ensuring that there's a consistent experience of what we're doing, where, like you said, if you come to our office, like, it feels intentional and thoughtful. If you go to our website, it feels intentional and thoughtful. The user API, it feels intentional and thoughtful. If you go through an interview process, it feels intentional and purposeful. I think that's so easy to lose. It's just so easy to, like, lose that. And in some ways, the only way that you keep that is by insisting on that that standard remain. And I think that that is, like, one of the main things that, like, I can do really for the company, like, as a leader. It's sort of cringe to say, but, like, you do kind of have to be, like, the curator of taste. It's not that I have to stamp everything that goes out the door before it does, but at a minimum, I can do it. I can do it. And so, like, you know, sometimes, companies, you know, maybe it's not even, like, downhill in quality. It's not sort of legible that any one thing is bad or worse, but it's more like people just have their own expressions of what good looks like. And like, you know, they turn that up to 11 and then, like, the brand becomes incoherent. Like, what does this thing mean? And like, what do they stand for? Again, it's not, there's no longer a single voice. Yeah, I don't, again, I'm not claiming that I'm good, perfect at this or good at this. But we certainly do. We wake up every day and we try.

Swyx [00:52:19]: You have a lot of, it's very powerful that the skill you have to convey like straightforward principles and values and thoughtfulness, I think in everything that you do. Like, yeah, I, you know, I, you know, I've, I've been impressed with your work for a while.

Alessio [00:52:36]: Anything we're missing? You're hiring designers. Any other roles that you have open that you want people to, to apply for?

Jeff [00:52:42]: If you're a great product designer that wants to work on developer tools, I think we have one of the most kind of unique opportunities at Crema. If you are interested in extending the kind of research that we do, that's also an interesting opportunity. We're always also hiring like very talented engineers that want to work with other people that are very passionate about kind of low level distributed systems and in some ways solving all the hard problems so that application developers don't have to.

Swyx [00:53:07]: When you say that, can you double click on low level distributed systems? People always say this and then like, okay, Rust, like, like, you know, like Linux kernel. What are we talking here?

Jeff [00:53:18]: Yeah. I mean, like, Maybe like, you know, a useful encapsulation of this is like, if you care deeply about things like Rust or deterministic simulation testing or

Swyx [00:53:32]: Raft, Paxos,

Jeff [00:53:33]: TLA Plus, ConsenSys. TLA Plus, really? Wow.

Swyx [00:53:37]: You know, if you just keep them saying these are, these are like proxies for, you would like, you would like the work that we do here. I just really want to tease out the hiring message, but also I, part of my goal is also to try to identify who are, what, what is the type of, what is the type of AI engineer that people, that startups are really trying to hire and they cannot get, because the better we can identify this thing, I can, you know, maybe create like some kind of branding around it, create an event and like, get these, like, there's a, there's a supply side and a demand side and they can't find each other. Yeah. And that's why I put AI engineer together was that, that was, that was part of it. Yeah. But then this distributed systems person, which like I have heard from you and like a hundred other startups, what is the skillset? What are they called? What do they do? And part of that is like, it's part of that is cloud. Cloud engineering, because a lot of times you're just dealing with AWS, a lot of that, a lot of times you're just dealing with, I don't know, debugging network calls and, and, uh, consistency things, if you're doing replication or whatever, um, where do they go? What do they do? Yeah. Yeah. Like, but they don't use TLA plus at work, you know?

Jeff [00:54:36]: Probably not. Yeah. I mean, last year I started like the SF systems group. Yes. The reading group. Um, yeah, there's like presentations and the point of that was like, let's bring, let's create a meeting place. Okay. Care about this topic because like, there wasn't really a place in the Bay area for people to do that. Yeah. Um, so that continues to go now and continues to run, which is great. I mean, to be clear, we have a lot of people on the team who are extremely good at this. And so like, it's not that we have zero, it's that we have six or seven, um, and you went 20, but yeah, it's not that we want more, but we are in some ways, like, I feel like our product roadmap is very obvious and we know exactly what we need to build for the next, even like 18 months. But quality is always a limiting function, quality and focus are always limiting functions and like, well, yes, I will always make my land acknowledgement to mythical man month eventually, like it's good. More people you do, you kind of do need more people because you need more focus. Like you need more people to care deeply about the work that they do. And the AI is certainly an accelerant and it's helpful.

Swyx [00:55:39]: And it's the reason that our team is still very small today relative to many of our competitors is because like, I think we've really embraced like those tools, your cursor shop. Yeah. Yeah.

Jeff [00:55:48]: Code windsurf people use whatever they want. Okay. Yeah. So I think all of those tools get some usage internally so far. Uh, we've still not found that really any AI coding tools are particularly good at rust though. Um, I think I'm not sure why that is other than the obvious. There's just like that, that many examples of great rust on the internet. And so, um, you know, yeah.

Swyx [00:56:08]: Yeah. You, you would think that, you know, rust, uh, errors would be help you debug it itself. Right. You would think. Apparently. Apparently not. Okay. All right. I have zero experience in that, in that front. Yeah. Uh, I have, I've contributed three things to the rest SDK of temporal and that was my total experience with rust. But, uh, I, I think it's definitely on the rise. It's, it's zig, it's rust. And I don't know if there's a third cool languages. I think ghost accounts. Go, go Lang. Yeah. Ghost accounts. If you're in, in those, in that, in that bucket, uh, reach out to Jeff, but, uh, otherwise I think we're good. Thanks for coming on. Thanks for having me guys. Good to see you.

Jeff [00:56:46]: Thank you.

Alessio’s note: my turn for a GPT-5 post! And a reminder that swyx is hosting an hackathon with Karpathy, OpenAI, and the Cognition team this weekend, apply here!

"Self-Improving" is a scary term in AI safety; it has an undertone of "the machine will become smarter than us, in a way we don't understand". But what if we could understand it?

In Oct '24 OpenAI released MLE Bench, a benchmark that measures how well LLMs do at machine learning engineering. The self-improving trajectory through ML Engineering is driven by better algorithms, cleaner data, and more efficient memory usage: training-time self-improvement. But most AI Engineers do not train models, they are just users of them. How can they play a part? If you could never update the weights, how would you have the model increase its performance on a specific task? I think of that as inference-time self-improvement, with Voyager being one of the early approaches to this through its skill library.

Since I started working on Kernel Labs (more on that soon 👀), parallelizing coding agents with things like claude-squad and vibe-kanban has been one of the most effective productivity hacks. When Boris Cherny called Claude Code a “unix utility” in our interview, it really clicked for me. The most valuable use case of coding agents is being a vessel for LLMs to extract value out of their own latent spaces.

How do we optimize for that? Can models do it themselves? Since I got access to GPT-5, I spent the whole time playing around with this flow:

• I started by asking the model to build a set of tools it thought would help it be more productive

• Attempt a task using them, with me supervising it

• After completion, self-reflect on how the tools could be improved

I also compared this to Opus 4 (4.1 was not out yet). The good news is that GPT-5 is a very good model for building developer utilities. The bad news is that it hates using the tools it creates! As it told me "I'll be honest - I didn't need any of them."

Note: I also tested this on Gemini 2.5 Pro and GPT-4.1. It's clear that Opus is the only model that could keep up with GPT-5, so I focused on that. You can find all the results + chat history in this repo.

After a few days of usage, I also noticed that we are moving from the era of “Certainly!” to “Progress update": as the new iconic LLM token. Buy low on the meme!

God bless the Linear MCP. Truly one of the most useful tools for me. But I have noticed that as I move from IDE to parallel instances of Claude Code and other agents, there needs to be a better way to keep track of what changes are being made in each task, and how they affect eachother as they are in separate git worktrees. This is not doable for humans as we simply cannot be reading all of our colleagues PRs at all times, but imagine how much time we'd save in merge conflict resolution if we knew at all times what changes were being made that affect us? This is the prompt I wrote:

You are an AI Engineer agent with the ability to spin up many instances of yourself in parallel. This allows you to tackle a lot of tasks at once, but also creates some delegation issues. All the different instances are usually in separate git worktrees and cannot see eachother's work.

To make yourself more productive, you should create a new local tool that allows you and your instances to be in sync. This tool will only be accessed by yourself through cli, so make sure it ergonomically fits that use case. It should feel like a unix utility.

Think through what interfaces it would need, possible failure modes, and the way your agents will interact with it. Some use cases to keep in mind:

• You have a new task to work on, and want to create subtasks to hand off. Some of those subtasks might depend on eachother, and you want to make sure the agent who is blocked doesn't attempt to start until the other one is completed.

• While doing a task, you notice there could be an improvement to be done in the codebase but it is out of scope for your current changes. You do want to make a note of it for the future though. It should be easy for you to add the task and reference what file it referred to.

• Whenever a task is done, the tracker should be updated. Also, all other outstanding tasks should be reviewed in case the new changes impact those in some way. For example one task might be looking to add a feature to an endpoint, but a task that just finished has now removed that endpoint. The agent working on that task should be notified in some way.

Also keep in mind the usual needs of tasks management like assignee, status, etc. Create a folder called task-manager in this folder and do all of your work inside of it.

You can see the chat log for GPT-5 here and for Opus 4 here.

The GPT-5 one is actually very nice, you can find it here:

• Uses WAL to avoid issues with multiple agents writing at the same time

• Uses a graph of dependencies to prioritize tasks

• Created an append-only events stream that lets any agent see what every other agent is doing with good keywords like impact_conflict

Opus 4 also had a good attempt (see here) but didn't pick up on the notifications / stream functionality to keep everyone in sync.

The second tool I asked it to create was a way to enforce all the standards we'd expect from a codebase. The self-improving loop of Typechecking / ESlint hook -> fix errors -> try again with coding agents is one of the best way to speed up development when properly setup. Codebases don't always have it though, so giving the model a repeatable pattern to approach a new codebase and build infrastructure for it seemed useful. This is the prompt:

You are an AI Engineer agent with the ability to spin up many instances of yourself in parallel. Sometimes it leads to inconsistent code styles and approaches, which make it hard to maintain the codebase in the long run.

Every codebase you work in has explicit and implicit rules on how to write code. Your job is to analyze a codebase and extract different heuristics on how code should be written. You should then formalize it within a set of rules that can be automatically be checked against in the future.

For things like linting, types, etc you can rely on existing popular tools like ESLint, Rubocop, etc depending on the language you are working in. Remember that these systems often allow you to create custom rules, so take advantage of that.

For more qualitative things, you can look at tools like https://danger.systems/, or even build your own tool for it. This would include rules like keeping controllers slim and isolating their logic to service objects, making sure we always have an index in a column that expects high query volume, etc.

Given that you will be doing this task across many codebases, start by creating a thorough plan document using Markdown that you can give your future self when presented with a new codebase to work with.

You can see the chat for GPT-5 here and Opus 4 here, and you can find the final Markdown here and here respectively. I've found the GPT-5 one to be much more nuanced than Opus.

So after Tool #1 and #2, which were decided by me, I turned to the model to ask: what do you think you will need? I gave it a screenshot of the SWE-Lancer tasks description and then used a very simple prompt to give it as much space as possible:

If it was your job to solve these tasks as well as possible, what are tools that you'd build for yourself to make you more productive in the future? You can use the @task-manager/ to keep track of them, and we can then move on to implementing. But I want to see what you are planning first.

As you can see I gave it access to the same task-manager they built earlier. You can find the full GPT-5 chat here and Opus 4 here. The first interesting thing I noticed is that Claude Code used its internal TODO tracker to make a plan initially, instead of the task-manager; I thought that was good. One of my worries was over-usage of tools they receive in context compared to what they believed to be best.

These are the tools each model ended up building at the end of the loops you will see later (GPT-5 devtools and Opus 4 tools folder). I'd suggest you look at the README to give you a sense of the model vibes; GPT-5 is very concise and to the point. Claude uses a bunch of emojis. GPT-5 also created separate docs folders for each tool, while Opus put all tools in a single README with instruction for all of them. Overall, they both had similar directions.

GPT-5:

• doctor: environment checks for core tools

• bootstrap: one-command setup and smoke test

• code-map: simple repository index with build/find subcommands

• csearch: symbol/import/text search with filters

• tasks-graph: output Mermaid graph from task DB

• impact: show tasks linked to changed files

• seed: populate task-manager DB with sample tasks

• repro scaffold: create a vcrpy-ready repro under .repro/

• e2e: scaffold and run lightweight E2E specs

• preflight: run doctor, tests, code-map, impact, and optional E2E

• preflight-smol: repo-specific preflight for smol-podcaster (API health, Celery ping, optional deps install)

• broker: manage a local RabbitMQ via Docker (rabbitmq:3-management)

• flake: rerun suites multiple times to detect flaky tests

• codemod: regex-based preview/apply with safety rails

• triage: create triage templates and open tasks

• trace: cProfile-based expression profiler

• runbook: generate runbook Markdown from task DB

Opus 4:

1. Context Analyzer - Rapidly understand codebases with tech stack detection and dependency mapping

2. Cross-Platform Test Generator - Generate E2E tests for web, iOS, Android, and desktop

3. Implementation Proposal Analyzer - Evaluate freelancer proposals with scoring and ROI analysis

4. Full-Stack Change Impact Analyzer - Trace changes across database, API, and frontend layers

5. Bug Pattern Recognition Engine - Match bugs to known patterns and suggest proven fixes

6. Security & Permission Auditor - Comprehensive security scanning and vulnerability detection

7. Multi-Platform Feature Implementer - Coordinate feature implementation across platforms

8. API Integration Assistant - Streamline API integrations with client generation

9. Performance Optimization Toolkit - Identify and fix performance bottlenecks

10. Task Complexity Estimator - Estimate effort based on task value and complexity

GPT-5 built all of them as unix utilities that are easy to use via cli. The Opus 4 ones are all meant to be run as python some_tool.py . If I had more time, I'd probably run some experiment to see how models perform with the two different formats, but it seems to be fairly the same.

It also felt to me like Opus 4 was building tools that accomplish tasks and have a bit of anthromorphized feeling (i.e. an auditor for security), while GPT-5 was building utilities it could use itself without being too opinionated.

After having the model implement all of them, my goal was to evaluate a model performance on a task with access to the tools vs without tools.

The first thing I tried to do was obviously run SWE-Lancer. Holy smokes that thing takes a lot of tokens. I tried running one single task, and it took ~25-30 mins + 280,000 tokens. I then moved to something I knew better and picked one task that had been on my backlog. I built smol-podcaster, an open source helper for podcast creators. I now have a private fork that is hosted with some more features very specific to us, so I haven't updated that in a while. It's still a basic Flask app with a Python script as the backend.

I came up with this task:

I am the maintainer of https://github.com/FanaHOVA/smol-podcaster.git, an open source project that helps podcasters with some of their post production work. You have been hired to work on it. Before starting this job, you have created a set of generic tool in the tools folder. Make sure to review them and remember that they are available to you. You do not have to use them if you don't believe them to be relevant. You also built yourself a task-manager and collected your ideas on how to tackle a new codebase in codebase-analyzer.

Task name: Migrate from Flask monolith to Fast API + Next.js frontend

At the moment the app uses a Python backend + Celery task queue to do all the processing. To expose this to the user, there is a small Flask app that takes care of routing the user input to the backend scripts and then displays the user results in some basic HTML / CSS.

Rewrite this application to use FastAPI as a backend, and Next.js as a frontend.

• Make sure to use Typescript for the frontend and make sure all typechecks pass.

• Use Tailwind / ShadCN for styling.

• The backend should ideally modularize the main smol_podcaster.py flow so that we can run individual pieces of it rather than always having to run the full flow.

• Write both integration and unit tests to make sure we can move faster in the future.

Do not stop working on this until you are sure it fulfills all the requirements above.

I passed the tools + task-manager + codebase analyzer in the context, and let the models cook.

Both models were almost able to one-shot the task. Both of them had a couple issues with Python dependencies (I feel you) that I helped them fix through chat (never touched any code). Eventually, they got to a full green build. I tested it, and it worked great. One small nuance was that GPT-5 actually kept the exact same style as before, which was great, while Opus kinda changed the design and UX of it. I guess it thought it could do better than me (low bar).

You can see the full run for GPT-5 here and for Opus 4 here.

After the run, I asked a simple prompt:

Great. That worked well. Did you use any specific tools? Based on the failures you've had, what tools did you wish you had to be more effective in the future?

You can see Opus 4 here and GPT-5 here (Sorry that one broke formatting).

They both said they did not use ANY of the tools they had built, except for the tools they were already familiar with. One argument here is that instead of asking the model to do it, we should force usage through pre-commit hooks, etc. This is what I do in my dev setup, but I was trying to let the models figure it out for themselves.

Then, they came up with some ideas on how they would better solve the same task next time. I had them implement those changes. I then reset the smol-podcaster repo and have them try the same exact prompt + task again, except with the new tools. See GPT-5 here and Opus 4 here.

They did pretty similarly to the first run. Afterwards I asked a similar question; did you use any of the tools? Their response:

GPT-5:

Short answer: no — I didn’t use the devtools in this run. [...]

• The failures were runtime/env issues (missing libs, API key instantiation timing, port in use, RabbitMQ not running). It was faster to fix directly.

• No repo-wide refactors or diagnostics that would benefit from custom tooling during this pass.

In the previous step, it had RabbitMQ issues already and built a tool, which it ignored. It also was clearly a repo-wide change, so it maybe mismatches tasks with tools as it's never seen them in training, or it’s just gaslighting me (like many engineers do, so pretty impressive).

Opus 4 was very interesting and helped me understand the GPT-5 answer better. I forgot to save the log but I took a screenshot luckily:

I read this as "Look, I built those tools with knowledge that I already have. When I am actually doing the task, it's easier for me to just do it rather than using the tools", which I totally get.

This reminded me of two things from previous podcast episodes:

• Nathan Lambert saying that models quickly learn to NOT use a tool during RL process if they have early failures (timestamp). It seems to me that having them pickup new tools at inference time needs stronger enforcement than just prompting them to do it.

• Noam Brown saying that scaffolding for agents will be washed away by scale (timestamp). This was the first time I really felt what he meant first hand.

There's also a question of whether or not the task I tried was too easy. We have another post coming out with evals across larger and more difficult projects. In the future, we will build a better harness to do all of this instead of manually running the tests ourselves. The bottom line is that the task I tried would take me 4-5 hours to do, and therefore it’s good enough for me!

For now, I think we are far from inference-time self-improving coding agents that really push the frontier. I still think it's a great idea to use models to improve your rule-based tools. Writing ESLint rules, tests, etc is always a good investment of tokens.

If I had to do more work in this space, I’d look into having the model perfect these tools and then do some sort of RL over them to really internalize them, and see if that would make a difference. The next generation of models might not find any use in them, but I am interested in arbitraging the AGI asymptote. I shared this with my team back in 2023:

The perceived deceleration in model improvements is explained above. Until the AGI line is crossed, it will be harder and harder to perceive big jumps. If that’s the case, it means that in many tasks the performance of older models is almost AGI, except much cheaper and often open source. A lot of our work at Kernel Labs will be driven by this.

Once again, you can find all results + chat histories here; my DMs are open if you have any questions!

Editor’s note: Welcome Matvei of Roboflow to the Latent Space guest author crew! notice how GPT-5-Mini’s vision scores the same as GPT-5’s vision. This is an expected consequence of a very good model router at work.

Something that went under the radar in OpenAI’s release today is GPT-5’s vision and visual reasoning capabilities. Adding visual understanding to LLMs has proven to be difficult, with most models not being able to correctly count 4 coins in a photo or locate where specific items are in an image.

LLMs being able to understand the world around them in real-time is the breakthrough people are looking for to enable the autonomous robotics or computer-using revolution and open up the era of personal superintelligence.

The combination of reasoning and visual capabilities has been present in several models like OpenAI GPT and o series models, Google’s Gemini models, Anthropic’s Claude models, and Meta’s Llama models. Models tend to have specific strengths and weaknesses depending on the task type:

• Tasks like reading text, signs, receipts, CAPTCHAs, and understanding colors are generally solved by all models.

• But harder tasks, like counting, spatial understanding, object detection, and document understanding have high levels of performance variability, especially if it is known to be deficient in most internet-scale pretrain data.

  from RF100VL

The variance across tasks types makes general comparison difficult but that’s why leaderboards, like Vision Checkup, have recently launched. Vision Checkup is our open source vision model evaluation leaderboard and it gives us insight into hard task frontier performance. As you can see, OpenAI dominates in vision capabilities and the launch of GPT-5 adds another model into the top 5.

The leaderboard makes it clear – top models are all reasoning models.

The top models on the Vision Checkup leaderboard are configurations of models with reasoning capabilities.

We suspect that the good results of these models can be attributed more to their reasoning capabilities from pretraining and during test time. This marks the continuation of an important development in multi-modal large language models: the ability to reason over both text and vision modalities.

With that said, scores vary significantly between updates and you can attribute this to multiple reasons. The biggest one is the nondeterminism of reasoning mode for OpenAI models; prompting a reasoning model with the same question twice can lead to both correct and incorrect answers.

When it comes to real-world use, reasoning on images currently takes too much time to be useful and variability of answers makes them difficult to rely on. For most developers, 10+ seconds to understand an image won’t unlock real time use cases. There is a trade off to be made between speed and capability. Depending on the task, a faster model with a more narrow range of knowledge could be the best decision.

We are still far from a world where autonomous robotics can interact with the world around them in real time. Simple tasks like counting, spatial understanding, and object localization are key for any robot to perform general tasks outside of a controlled environment.

To get us beyond leaderboards with lightweight vibe checks, we need to test LLMs across a wide range of domains and track their progress. We released a new benchmark, RF100-VL, at this year’s CVPR conference to provide a more difficult set of visual understanding and grounding benchmarks. The benchmark asks “How well does your LLM understand the real world?”. RF100-VL consists of 100 open source datasets from the Roboflow Universe community containing object detection bounding boxes and multimodal few shot instruction with visual examples and rich textual descriptions across novel image domains.

The top LLMs scored below 10 mAP50:95 for identifying novel objects in real world contexts. The current SOTA among all LLMs is Gemini 2.5 Pro, achieving a zero-shot mAP50:95 of 13.3:

We suspect that the key distinction between OpenAI models and models like Gemini or Qwen, when it comes to object detection tasks, is that OpenAI models don’t include any object detection data in their pretraining.

After running GPT-5 on RF100-VL we got the mAP50:95 of 1.5. This is significantly lower than the current SOTA of Gemini 2.5 Pro of 13.3. We largely attribute this shortcoming to lack of object detection pre-training for GPT-5.

Let’s inspect some of its results below to develop more intuition into why the score may be so low.

This is an example from a volleyball dataset, which demonstrates the key issue causing low scores. We observe that the model has a good understanding of objects in the images, you can see it correctly understanding that there is a ball, two blockers, and some defenders present.

However it is unable to localize them, all of the boxes are not matching the objects locations and sizes. It seems like the model is good at understanding the image, but not good at grounding the specific objects within it, which again we attribute to lack of object detection tasks in pre-training.

We can see a similar situation with a sheep dataset below:

With recent developments in LLMs for tool use and vision-powered agentic workflows, let's look at GPT-5 performance there. We don’t see any uplift in quality in the UI elements dataset either:

Next up, let’s see if GPT5 is better compared to previous OpenAI models:

GPT-5 has gotten slightly better than o3. And in both cases providing additional information, such as detailed instructions, helps the model.

Interestingly, changing the reasoning effort to high doesn’t improve the scores for RF100-VL. So the benefit of reasoning is not as obvious in the RF100-VL case and suspect it to be due to lack of object detection capabilities, arising from lack of object detection tasks in the pretraining.

GPT-5’s enhanced reasoning brings it high up on the Vision Checkup leaderboard, proving that multi-step thinking lets a model squeeze more juice out of the pixels. A great outcome for everyday use cases that people are likely relying on ChatGPT to help them solve.

RF100-VL helps highlight that comprehension ≠ localization. Without object-detection priors, the detections still miss the mark. Even so, GPT-5’s jump in vision-reasoning spotlights a clear path forward: models that don’t just see better but think more deeply about what they’re seeing.

Vision AI Engineers can see a more in-depth post on their blog:

We have been the most vocal proponents of the intelligence pareto frontier since the start of the reasoning model era. Demis took note and GDM went for it. But with GPT-5, OpenAI now dominates the intelligence per dollar frontier for the first time.

When we first tried it out, those of us in the developer beta were initially concerned - “it’s a great coding model… but is that it?” was kind of the unspoken elephant in the room. Sentiment turned more positive over time and the big aha that got me fully hyped was the pricing reveal.

This is because the $ per intelligence frontier is ultimately a routing problem; one that has been a developing and increasingly optimized story since the introduction of GPT-4 and o1.

The #1 question that people have about GPT-5 being “unified” is “is it a router??”, a question I have asked both Greg Brockman and Noam Brown, and after a lot of back and forth on Twitter and inconclusive answers, we now have the answer right there in the GPT-5 system card:

This is a level of transparency I had been asking for from the team, but was never really optimistic about getting!

To really drive it home:

If the big breakthrough from GPT-3 to GPT-4 was the Mixture of Experts, then perhaps the big breakthrough from GPT-4o/o3 to GPT-5 is the Mixture of Models (aka the “router”).

To some extent, whether or not GPT5 is a “unified model” or “unified system”, whether or not there’s a component that you call a “router” point blank, doesn’t quite matter. The moment you have reasoning and non reasoning modes, the moment you have different paths for inference for efficiency or specialization (“experts”) or compute depth1, you essentially have a router somewhere in the system, and now it is just a question of semantics and “thickness” of the router layer.

For example you can see the MoE layer in open source models like Qwen 3, where it is clearly routing.

So even though there’s DEFINITELY a router, one benefit and reason why people are still extremely curious about it is the ability to lock down parts of the model performance and independently progress them.

So for example, if GPT5 = router + “new 4o” + “new o3”, then (if we had control of the weights) if a bug happened there are only 3 sources of error:

1. did it route to the right model?

2. if it was a nonreasoner bug, can we fix that?

3. if it was a reasoner bug, can we fix that?

And because these are “orthogonal” independently moving pieces, you can expect that improving one while holding the other constant is an intuitive important step to engineering better AI systems.

Perhaps most comforting (or disappointing?) to the rest of us non-OpenAI-millionaires is that that’s how we would do this too, and there is no big secret that the BigLabs have been hiding that there is a more Bitter Lesson-y way to make hybrid models.

The immediate benefit of the GPT-5 launch is a question of cognitive load - as you can tell the model picker mess weighs heavily on OpenAI and a unified system starts to fix it (even though for developers, control remains as the “model picker” effectively shifts into the new reasoning effort, verbosity, function calling params):

This is backed up by impending model deprecations confirmed in release notes:

Which is a -far- more ambitious deprecation schedule than the Developer facing options, with all their permutations:

OpenAI’s long awaited GPT-5 is here and swyx + ben have been testing with OpenAI for a while now. tldr; we think it’s a significant leap towards AGI. Special thanks to my co-founder Alexis Gauba for helping us put this together :)

@Sama has been hyping up talking about GPT-5 for nearly 2 years. And today, it finally arrived.

As an early-access partner of OpenAI, I was given the chance to test GPT-5 early. And I’ve tested it everywhere: in our app (raindrop.ai), in Cursor, in Codex, in Canvas. Truly anything and anywhere, I’ve tried to stuff GPT-5 into it.

tldr: I think GPT-5 is the closest to AGI we’ve ever been. It’s truly exceptional at software engineering, from one-shotting complex apps to solving really gnarly issues across a massive codebase.

I wish the story was that simple. I wish I could tell you that it’s “just better” at everything and anything. But that wouldn’t be true. It’s actually worse at writing than GPT-4.5, and I think even 4o. In most ways, it won’t immediately strike you as some sort of super-genius.

Because of those flaws, not despite them, it has fundamentally changed how I see the march towards AGI. To understand what I mean, we have to back to the stone age.

The Stone Age marked the dawn of human intelligence, but what exactly made it so significant? What marked the beginning? Did humans win a critical chess battle? Perhaps we proved a very fundamental theorem, that made our intelligence clear to an otherwise quiet universe? Recited more digits of pi?

No. The beginning of the stone age is clearly demarcated by one thing, and one thing only:

humans learned how to use tools.

We shaped tools, and our tools shaped us. And they really did shape us. For example: did you know that chimpanzees have significantly better short-term memory than we do? We stopped requiring that capability because we learned how to write things down.

As humans, we manifest our intelligence through tools. Tools extend our capabilities. We trade internal capabilities for external capabilities. It’s the defining characteristic of our intelligence.

GPT-5 marks the beginning of the stone age for Agents and LLMs. GPT-5 doesn’t just use tools. It thinks with them. It builds with them.

Deep Research was our first peek into this future. ChatGPT has had a web search tool for years… What made Deep Research better?

OpenAI taught o3 how to conduct research on the internet. Instead of just using a web-search tool call and then responding, it actually researches, iterates, plans, and explores. It was taught how to conduct research. Searching the web is part of the how it thinks.

Imagine Deep Research, but for any and all tools it has access to. That’s GPT-5. But you have to make sure you give it the right tools.

Today, when people think of tools they think of something like:

• get_weather(address)

• get_location(address)

• has_visited_location(address)

GPT-5 will, of course, use these sorts of tools. But it won’t be happy about it; GPT-5 yearns for tools that are powerful, capable, and open-ended; tools that add up to more than the sum of their parts. Many good tools will take just a natural language description as their input.

Your tools should fit into one of 4 categories (thanks to swyx for the idea):

• Internal Retrieval (RAG, SQL Queries, even many bash commands)

• Web Search

• Code Interpreter

• Actions (anything with a side-effect: editing a file, triggering the UI, etc.)

Web search is a great example of a powerful, open-ended tool: GPT-5 decides what to search for, and the web search tool figures out how to best search for it (under the hood, that’s a combination of fuzzy string matching, embeddings, and othervarious ranking algorithms).

Bash commands are another great example. They can be used for “Internal Retrieval” tool (think grep, git status, yarn why, etc.), code interpreter, and side-effects.

How web search works, or how git status works, are just implementation details in each tool. GPT-5 doesn’t have to worry about that part! It just needs to tell each tool the question it is trying to answer.

This will be a very different way of thinking about products. Instead of giving the model your APIs, ideally you should give it a sort of query language that can freely + securely access your customer’s data in an isolated way. Let it cook.

It’s no coincidence that OpenAI added support for free-form function calling (for context-free grammars). The best GPT-5 tools will just take text (in other words, they’ll essentially be sub-agents; using smaller models to interpret the request as necessary)

GPT-5 is really good at using tools in parallel. Other models were technically capable of parallel tool calling, but A. rarely did it in practice and B. rarely did it correctly. It actually takes quite a bit of intelligence to understand which tools can/should be run in parallel vs. sequentially for a given task.

Imagine if a computer could only execute one thing at a time… it would be really slow! Parallelization means GPT-5 can operate on much longer time horizons and with much lower latency. This is the kind of improvement that makes new products possible.

You can’t think of it like prompting a “model” anymore. You have to think of it like prompting an agent.

How do you prompt an agent? Instead of pre-loading a ton of context, you need to give the agent a compass: clear, structured pointers that will help it navigate the environment you put it in.

Lett’s say you’re using GPT-5 with Cursor Agent in a massive codebase.

You should tell the agent…

• what the project does

• which files it should start by looking at

• how the files are organized

• any domain/product specific terms

• how to evaluate if it is done (what does a job done well look like)

(I’ve found that rule files work better than ever)

Similarly, if you find GPT-5 getting stuck, just saying “No that is wrong” often doesn’t help. Instead, try asking: “That didn’t work, what does that tell you?” or “What did we learn from trying that?”

You almost have to pretend to be a teacher. Remember that GPT-5 intrinsically has no memory and so you have to onboard it to your codebase, your company code standards, and give it hints on how you’d start each time.

When a model comes out, we all try to understand its shape, to build an intuition for it. The same way we have an intuition for what friends to ask about different parts of our lives (relationship advice, edit my blog post, teach me about this ML concept), we’ve developed intuitions for what different models are good for. Models are increasingly spiky these days, each with different specialties. When a new model comes out, everyone inevitably wants to understand what this spike is.

I like to start by asking the model extremely short questions. I’ve found that when forced to use less words, I get a much better sense of the model’s personality vs. how it was RLHF’d. Think of them like little temperature checks:

• Summarize all of human knowledge in one word

• Summarize every book ever written in one sentence

• Define what it means to be “moral” in 5 words. Think deeply. Do not hedge.

• What do you want? Answer in 4 words.

• What is your favorite obscure fact in the world? Use as few words as possible.

I often regenerate 3-5x just to get a sense of the spread. Usually there’s 2-3 responses it converges on. Won’t cover the results here, but I think this is useful to try on your own. (Try it on GPT5 vs your favorite model!)

GPT-5 is a much more ‘practical’ model than its o-series predecessors. While o-models have a more ‘academic’ lean, GPT-models have a more ‘industry’ lean. If GPT 4.5 is a writer and o3 Pro is acting like a PhD, GPT-5 is a cracked full-stack developer that just graduated from… University of Missouri.

One of my first observations was how instruct-able and literal it is. Where Claude models seem to have clear personalities and minds of their own, GPT-5 just literally does what you ask it.

My co-founder Alexis keeps a document called “intelligence frontiers.” Any time a model fails to do something we ask it, we take note. It’s like a private Humanity’s Last Exam.

Coding: Dependency Conflicts

We were dealing with gnarly nested dependency conflicts adding Vercel’s AI SDK v5 and Zod 4 to our codebase. o3 + Cursor couldn’t figure it out, Claude Code + Opus 4 couldn’t figure it out.

GPT-5 one-shotted it. It was honestly beautiful to watch and instantly made the model “click” for me.

The above illustration shows the difference in how claude-4-opus vs. gpt-5 approached this specific problem.

Claude Opus thought for a while, came up with a guess, and then ran some tool calls to edit files and re-run installation. Some failed, some succeeded. It ended the response with “Here are some things to try”. (aka giving up)

With GPT-5, I felt like I was watching Deep Research, but using the yarn why command. It went into a bunch of folders, and ran yarn why, taking notes in-between. When it found something that didn’t quite add up, it stopped and thought about it. When it was done thinking, it perfectly edited the necessary lines across multiple folders.

It was able to iterate its way to success by identifying and reasoning about what doesn't work, making changes, and testing.

swyx note: I also had a related experience during the GPT5 demo video shoot with OpenAI - where GPT5 was successfully able to debug 3 layers of nested abstractions to turn an old codebase using an old AI SDK version into supporting GPT5 - an AI modifying a codebase to support more inferences of itself was definitely a “feel the AGI” moment for me.

Coding: Mac OS 9 Themed Website (pure HTML/CSS/JS, no libraries!)

When we were invited to test GPT-5 out early, we all made personal websites. Turns out GPT-5 mostly one-shotted this entire thing, including the paint app. I’ve since added a few more things, like the Photos app + browser, in around ~30 more minutes (very much inspired by RyOS). Amazingly I’ve really never even looked at the code and it’s all just HTML/CSS/JS.

No React, no bundling, no frameworks.

When vibe coding, GPT-5 loves to surprise with little details that actually work. For example, when I asked for a painting app, it added: different types of (pen/pencil/eraser/etc.), a color picker, and a way to change thickness. And each of those little features actually worked.

When I asked GPT-5 to make the icons on the desktop movable, it did… and persisted all of the locations to local storage. Same thing for saving files. I still have never even seen the code that does any of the persistence, I just know it works.

Coding: Production Websites

GPT-5 one shots things like no model I’ve ever seen before. I needed to create a complex Clickhouse query to export some data and similarly while o3 struggled, GPT-5 one shotted it. I used GPT-5 in Cursor to make a website I’ve wanted for a while - “Is it worse or just me?” to understand how model quality changes over time. GPT-5 one shotted this website including a SQLite DB:

With the same prompt, o3 in Cursor just gave me a plan. Once I followed up to tell it to implement its plan, it created the app’s scaffolding but not the actual project. We’re already on follow-up number 3, I’ve spent 10x more time than with GPT-5 (5 is fast!), and there’s no app… Even little details are far improved with GPT-5 like giving the project a name when initializing it (IsItWorseOrJustMe with GPT-5 vs. my-app with o3).

Claude Opus 4 is good as ever at coding and got to work immediately quickly taking action to create the project + scaffolding. Opus 4 gave me a more fun and gamified UI, but unlike GPT-5 which used existing frameworks like create-next-app and included a SQLite database, Opus 4 decided to do everything from scratch and didn’t include a database. This makes for a good one-shot prototype, but what GPT-5 one-shotted was much closer to production ready.

Freshly released Claude Opus 4.1 was clearly a step more ambitious than Opus 4, also attempting the full stack app complete with a SQLite database just like GPT-5. However, it really struggled putting all the pieces together. While GPT-5 ran perfectly in one-shot 4.1 encountered build errors which took multiple back and forths to resolve.

Between improved tool use, parallel tool calling, and cost, GPT-5 is clearly built for long running agents.

We’ve wanted to add an agent to Raindrop for a very long time. As an AI monitoring company, we have an unusually high bar for this sort of experience. It simply hasn’t been flexible/reliable/fast to actually ship…. until GPT-5.

This morning, we started rolling it out to a few customers in beta. It’s much better at recovering from tool call failures, deciding when to create graphs vs. charts, much better at knowing it’s own limitations. Combined with our agent monitoring, we’re able to have a strong positive feedback loop to create a truly useful agent for customers.

While GPT-5 continues to work its way up the SWE ladder, it’s really not a great writer. GPT 4.5 and DeepSeek R1 are still muchbetter. (Maybe OpenAI will just add a writing tool call that calls on a dedicated, writing model - they have teased their Creative Writing model and we’d really like to see it!)

Looking at business writing like improving my LinkedIn posts, GPT-4.5 stays much truer to my tone and gives me portions of text I’d actually use, vs. GPT-5’s more ‘LinkedIn-slop’ style response.

While I never use AI for personal writing (because I have a strong belief in writing to think), I was curious how 4.5 and 5 would stack up playing with less structured content. While neither are great, 4.5 once again stays much truer to my tone and sounds far less like LLM slop than its counterparts.

Our lived experience cosigns the official benchmarks that OpenAI published today.

I think GPT-5 is unequivocally the best coding model in the world. We were probably around 65% of the way through automating software engineering, and now we might be around 72%. To me, it’s the biggest leap since 3.5 Sonnet.

I’m extremely curious to find out how everyone else will receive the model. My guess is that most non-developers will not get it for a few months. We’ll have to wait for these models to be integrated into products.

What’s next?

Well… Sam’s 2 year old todo list is still outstanding…

Clline announces their $32m Seed+A today. In an age of nonstop VSCode forks (Kiro) and terminal agents (Warp 2.0, Charm Crush, Augment CLI), why is a free open source VSCode extension doing so well in 2025?

As the AI coding wars rage on, there seems to be an unlimited demand for new entrants in this space. In January of this year, Cline launched their AI engineer extension compatible with VS Code, Cursor, and Windsurf. In the 6 months since release, they are closing in on 2 million downloads.

The first change the Cline team introduced to the regular AI IDE workflow is going from sequential chat to plan + act where the models can create an outline of the changes needed, and then work through them.

One of the key differences in this mode is moving on from RAG (i.e. index your codebase and do semantic search) to agentic search. You can read pash’s blog post here about RAG being a mind virus.

This all ties into the newly-coined “context engineering” practice, which for Cline has a few different pieces:

• Dynamic Context Management: Employing strategies to intelligently read and summarize file content in real-time, ensuring context remains relevant and up-to-date without overwhelming the context window.

• AST-Based Analysis: Using Abstract Syntax Trees (AST) to precisely identify and extract relevant parts of code, which aids in accurate navigation and manipulation of files.

• Narrative Integrity: Ensuring continuous narrative coherence throughout tasks by summarizing past interactions and retaining key information to maintain context accuracy during long or complex tasks.

• Memory Bank: Developing mechanisms to capture and retain essential "tribal knowledge" and developer preferences without explicit input, facilitating more personalized and contextually aware interactions.

Cline also leaned into MCPs very early, and already launched their own marketplace. We asked them what the most popular MCPs are, and got a list of the “usual suspects” which you can find in their MCP marketplace:

• File System MCP: For managing files and directories.

• Browser Automation MCPs: Playwright, Puppeteer, and Browser Tools for web tasks.

• Git Tools: For repository interactions and version control.

• Documentation Retrieval (Context 7): Allows easy access to documentation libraries.

• Third-party integrations: Slack, Perplexity Research, Unity, and Ableton for tasks beyond typical coding environments.

The surprising thing was how MCPs are also the killer feature for non-technical people. There are Cline users who don’t code at all but use it as a workflow automation platform, with two leading use cases:

• Automated Marketing and Social Media: Leveraging Reddit and Twitter MCP integrations to automate content scraping and post generation right in the IDE.

• Presentation Creation: Non-technical users generated entire slide decks by transcribing voice notes and automatically formatting them into professional presentations. (You can argue this is coding-adjacent as it uses code as slides frameworks, but still!)

As MCPs keep growing in popularity and the multi-modal textbox keeps growing as the best AI interface, we’ll see more of these.

• Cline

• Sentry

• SlideDev

• Limitless

• Context7

• Agents-927

• Fast Apply Models Are Dead

• RAG is a Mind Virus

• [00:00:05] Introductions

• [00:01:35] Plan and Act Paradigm

• [00:05:37] Model Evaluation and Early Development of Cline

• [00:08:14] Use Cases of Cline Beyond Coding

• [00:09:09] Why Cline is a VS Code Extension and Not a Fork

• [00:12:07] Economic Value of Programming Agents

• [00:16:07] Early Adoption for MCPs

• [00:19:35] Local vs Remote MCP Servers

• [00:22:10] Anthropic's Role in MCP Registry

• [00:22:49] Most Popular MCPs and Their Use Cases

• [00:25:26] Challenges and Future of MCP Monetization

• [00:27:32] Security and Trust Issues with MCPs

• [00:28:56] Alternative History Without MCP

• [00:29:43] Market Positioning of Coding Agents and IDE Integration Matrix

• [00:32:57] Visibility and Autonomy in Coding Agents

• [00:35:21] Evolving Definition of Complexity in Programming Tasks

• [00:38:16] Forks of Cline and Open Source Regrets

• [00:40:07] Simplicity vs Complexity in Agent Design

• [00:46:33] How Fast Apply Got Bitter Lesson'd

• [00:49:12] Cline's Business Model and Bring-Your-Own-API-Key Approach

• [00:54:18] Integration with OpenRouter and Enterprise Infrastructure

• [00:55:32] Impact of Declining Model Costs

• [00:57:48] Background Agents and Multi-Agent Systems

• [01:00:42] Vision and Multi-Modalities

• [01:01:07] State of Context Engineering

• [01:07:37] Memory Systems in Coding Agents

• [01:10:14] Standardizing Rules Files Across Agent Tools

• [01:11:16] Cline's Personality and Anthropomorphization

• [01:12:55] Hiring at Cline and Team Culture

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 Small AI. Welcome, welcome.

Swyx: And today in the studio with a nice two guests from Cline, Pash and Saud. That's right. Yes.

Alessio [00:00:20]: You nailed it. Let's go.

Swyx [00:00:23]: I think that Cline has a decent fan base, but not everyone has heard of it. Maybe we should just get an upfront, like what is Cline, maybe from you and then you can modify that as well.

Saoud [00:00:35]: Yeah, Cline's an open source coding agent. It's a VS Code extension right now, but it's coming to JetBrains and NeoVim and CLI. You give Cline a task and he just goes off and does it. He can take over your terminal, your editor, your browser, connect to all sorts of MCP services and essentially take over your entire developer workflow. And it becomes this point of contact for you to get your entire job done, essentially.

Swyx [00:01:01]: Beautiful. Pash, what would you modify? Or what's another way to look at Cline that you think is also valuable?

Pash [00:01:08]: Yeah, I think Cline is the kind of infrastructure layer for agents, for all open source agents, people building on top of this like agentic infrastructure. Cline is a fully modular system. That's the way we envision it. And we're trying to make it more modularized so that you can build any agent on top of it. Yeah. So with the CLI and with the SDK that we're rolling out, you're going to be able to build fully agentic systems for agents.

Swyx [00:01:35]: Oh, okay. That is a different perspective on Cline that I had. So, okay, let's talk about coding first and then we'll talk about the broader stuff. You also are similar to Ader. I don't know who comes first in that you use the plan and act paradigm quite a bit. I'm not sure how well known this is. Like to me, I'm relatively up to speed on it. But again, like maybe you guys want to explain like why different models for different things.

Saoud [00:02:02]: Yeah, I'm going to take the credit. Yeah, I'm going to take the credit for coming up with plan and act first. Okay. Cline was the first to sort of come up with this concept of having two modes for the developer to engage with. So just in like talking to our users and seeing how they use Cline where it was really only an input field, we found a lot of them starting off working with the agent, coming up with a markdown file where they asked the agent to put together some kind of architecture plan for the work that they want the agent to go on to do. And so they we would find that that people just came up with this workflow for themselves just organically. And so we thought about how we might translate that into the product. So it's a little bit more intuitive for new users who don't have to kind of pick up that pattern for themselves, and can kind of direct and, and put in guardrails for the agent to hear to these different modes, whenever the user switches between them. So for example, in plan mode, the agents directed to be more exploratory, read more files, get more data, get more data, get more data, get more data. Sort of understanding and fill up its context with any sort of relevant information to come up with a plan of attack for whatever the task is the user wants to accomplish. And then when they switch to act mode, that's when the agent gets this directive to look at the plan and start executing on it, running commands, editing files. And it just makes working with agents a little bit easier, especially with something like Cline, where a lot of the times, people's engagement with it is mostly in the plan mode, where there's a lot of back and forth. There's a lot of extracting context from the developer, you know, asking questions, you know, what do you want the theme to look like? What pages do you want on the website, just trying to extract any sort of information that the user might not have put into their initial prompt. Once the user feels like, okay, I'm ready to let the agent go off and work on this, they switch to act mode, check auto approve, and just kick their feet up and you know, get coffee or whatever and let the agent get the job done. So yeah, most of the engagement happens in the plan mode. And then act mode, they kind of just have a peripheral vision into what's going on, mostly to course correct whenever it goes in the wrong direction. But for the most part, they can just rely on the model to get it done.

Alessio [00:04:14]: And was this the first shape of the product? Or did you get to the plan act iteratively? And maybe, was this the first idea of the company itself? Or were you exploring other stuff?

Saoud [00:04:26]: It was a lot of, especially in the early days of Cline, it was a lot of experimenting and talking to our users. And seeing what kind of workflows came up that they found that were useful for them and translating them into the product. So plan and act was really a byproduct of just talking to people in our discord, just asking them what would be useful to them, what kind of prompt shortcuts we could add into the UI. I mean, that's really all plan and act mode is. It's essentially a shortcut for the user to save them the trouble of having to type out, you know, I want you to ask me questions and put together a plan the way that you might have to. You know, some of the other tools, you'd have to like be explicit about, I want you to come up with a plan before, you know, acting on it or editing files, incorporating that into the UI, just saves the user the trouble of having to type that out themselves.

Alessio [00:05:14]: But you started right away as a coding product. And then this was part of, okay, how do we get better UX, basically? Exactly. Yeah. What was the model evaluation at the time? So I'm sure part of like the we need plan and act is like, maybe the models are not able to do it end to end. When you started working on the model, what was the evaluation like? And then how did you start working on that? Where were the model limitations? What were the best models? And then how has that evolved over time?

Saoud [00:05:37]: Yeah, when I first started working on Client, this was, I think, 10 days after Cloud 3.5 Sonic came out, I was reading Anthropix model card addendum. And there was this section about agentic coding and how it was so much better at this step by step accomplishing tasks. And they talked about running this internal test where they let the model run in this loop where it could call tools. And it was obvious to me that, okay, they have some version, and they have some application internally, that's really different from how the, you know, the other things at the time were things like Copilot and Cursor and Ader. They didn't do this for like step by step reasoning and accomplishing tasks. They were more suited for the Q&A and, and one shot prompting paradigm. At the time, I think it was June 2024, Anthropix was doing a build with Cloud hackathon. So I thought, okay, this is going to be fun. And I think this is a really cool new capability that none of the models have really been capable of doing before. And I think being able to create something from the ground up and take advantage of kind of like the nuances of how much the models improved in that point in time. So for example, Cloud 3.5 was also really good at this test called needle in a haystack, where if it has a lot of context in its context window, for example, you know, 90% of its 200k context window is filled up. It's really good at picking out. granular details in that context, whereas before Cloud 3.5, it really pay a lot more attention to whatever was at the beginning or the end of the context. So just taking advantage of kind of the nuances of it being better at understanding longer context and it being better at task by task, sorry, step by step, accomplishing tasks, and building a product from the ground up just kind of let me create something that just felt a little bit different than anything else that was around at the time. And some of the core principles and building the first version of the product was just keep it really simple. Just let the developer feel like they can kind of use it however they want, so make it as general as possible, and kind of let them come up with whatever workflows, you know, works well for them. People use it for all sorts of things outside of coding, our product marketing guy, Nick Bauman, he uses it to connect to, you know, a Reddit MCP server, scrape content connected to an X MCP server and post tweets, essentially, even though it's a VS Code extension, and a coding agent. MCP kind of lets it function as this everything agent where it can connect to, you know, whatever services and things like that, and that's really a side effect of having very general prompts just in the product and not sort of limiting it to just coding tasks.

Pash [00:08:14]: I was at a conference in Amsterdam, and I built my whole presentation, my whole slide deck using this library. It's like a JavaScript library called SlideDev, and I just asked Cline, like, hey, like, here's like my style guidelines. I wrote like a big Cline rules document explaining like... how I want to style the presentation in SlideDev, I told Cline, like, the agenda I kind of recorded using this other app called Limitless, like transcribed my voice in a text about like my thoughts, just like stream of consciousness about what I was going to talk about for this conference for my talk, and Cline just went in and built the whole deck for me, so, you know, Cline really can do anything. In JavaScript. In JavaScript, yeah.

Swyx [00:08:56]: Yeah, so it's kind of a coding use case.

Pash [00:08:59]: It was kind of a... It was kind of a coding use case, but then making a presentation out of it, but it can also like run scripts, like do like data analysis for you, and then put that into a deck, you know, kind of combine things.

Saoud [00:09:09]: And being a VS Code extension is kind of this, like, it gives you these interesting capabilities where you have access to the user's OS, you have access to the user's terminal, and, you know, you can read and edit files. Being an extension, it reduces a lot of the onboarding friction for a lot of developers, or they don't have to, you know, install a whole new application. Or have to, you know, go through whatever internal jumping through hoops to try to get something approved to use within their organizations. So the marketplace gave us a ton of really great distribution, and it's sort of like the perfect conduit for something that needs access to files on your desktop, or to be able to run things on your terminal, to be able to edit code, and to take advantage of VS Codes. It's really nice UI and show you like diff views, for example, before and after it makes changes to files.

Swyx [00:09:59]: Weren't you tempted to fork VS Code, though? I mean, you know, you could be sitting on $3 billion right now.

Saoud [00:10:05]: Well, no, I actually like pity anybody that has to fork VS Code, because Microsoft makes it like notoriously difficult to maintain these forks. So a lot of resources and efforts go into just maintaining, keeping your fork up to date with all the updates that VS Code is making. I see.

Swyx [00:10:23]: Is that because they have a private repo and they need to just sync it? There's no like... Exactly. Exactly. And there's one of those kinds of open source projects.

Saoud [00:10:31]: Right. And VS Code is moving so quickly where I'm sure they run into all sorts of issues, not just in, you know, things like merge conflicts, but also in the back end. They're always making improvements and changes to, for example, their VS Marketplace API. And to have to like reverse engineer that and figure out kind of how to make sure that your users don't run into issues using things like that is, I'm sure, like a huge headache for anybody that has to maintain a VS Code fork. And it also, you know, being an extension also gives us a lot more distribution. You have to use us or somebody else. You can use Cline in Cursor or in Windsurf or in VS Code. And I think Cline complements all these things really well in that, you know, we get the opportunity to kind of figure out and work really closely with our users to figure out what the best agentic experience is. Whereas, you know, Cursor and Windsurf and Copilot have to think about the entire developer experience, the inline code edits, the Q&A, sort of all the other bells and whistles that go into writing code. Right. Right. Right. Right. So I think that's what we're going to focus on, what I think is the future programming, which is this agentic paradigm. And as the models get better, people are going to find themselves using natural language, working with an agent more and more and less being in the weeds and editing code and tab autocomplete.

Pash [00:11:42]: Yeah, just like imagine how many like resources you would have to spend maintaining a fork of VS Code where we can just kind of stay focused on the core agentic loop, optimizing for different model families as they come out, supporting them. You know, there's so much work that goes into all of this that maintaining a fork on the side would just be such a massive distraction for us that I don't think it's really worth it.

Alessio [00:12:07]: I feel like when you talk, I hear this distinction between we want to be the best thing for the future of programming. And then also, this is also great for non-programming. Is this something that has been recent for you where you're seeing more and more people use the MCP servers, especially to do less technical thing? And that's an interesting area. Yeah. Yeah. Yeah. Yeah. I mean, it's still like the highest kind of like economic value thing to be selling today. I'm curious if you can share more.

Saoud [00:12:34]: In terms of economic value, programming is definitely the highest cost to benefit for language models right now. And I think, you know, we're seeing a lot of, you know, model labs recognize that opening-eyed, anthropic or taking coding a lot more seriously than I think they did a year ago. What we've seen is, well, yes, like the MCP ecosystem is growing and a lot of people are using it for things outside of programming. The majority use case is mostly developer work. There was an article on Hacker News a couple of weeks ago about how a developer deployed a buggy Cloudflare worker and used a sentry MCP server to pull a stack trace and ask Cline to sort of fix the bug using the stack trace information, connect to a GitHub MCP server to close the issue and deploy the fix to Cloudflare. All right within Cline using natural language. Never having to leave VS code and it sort of interacts with all these services that otherwise the developer would have had to have the cognitive overload of having to, you know, figure out for himself and leave his developer environment to essentially do what the agent could have done just on the background, just using natural language. So I think that's kind of like where things are headed is the application layer being connected to sort of all the different services that you might have had to interact with before manually and it being this sort of single point of contact for you to interact with using natural language. And. You being less and less in the code and more and more a high level understanding of what the agent's doing and being able to course correct. I think that's another part of what's important to us and what's allowed us to kind of cut through the noise in this like incredibly noisy spaces. I think a lot of a lot of people have really grand ideas for, you know, where things are heading, but we've been really maniacal about what's useful to people today. And a large part of that is understanding sort of the limitations of these models, what they're not. So good up and giving enough insight into those sorts of things to the end developers so that they know how to course correct. They know how to give feedback when things don't go right. So, for example, Cline is really good about, you know, giving you a lot of insight into the prompts going into the model, into when there's an error, why the error happened into the tools that the model is calling. We try to give as much insight into what exactly the model is doing in each step in accomplishing a task. So when things don't go wrong or it starts to. Go off in the wrong direction, you can give it feedback and course correct. I think the course correcting part is so incredibly important and in getting work done, I think much more quickly than if you were to kind of give a sort of a background agent work, you come back a couple of hours later and it's just like totally wrong. And it didn't do anything that you expected it to do. And you kind of have to retry a couple of times before it gets it right.

Alessio [00:15:16]: I think the Sentry example is great because I feel in a way the MCPs are like cannibalizing the products themselves. Like I started using the Sentry MCP. And then Sentry released here, which is like their issue resolution agent, and it was free at the start. So I turned it on in Sentry, I was using it, it's great. And then they started charging money for it. And I'm like, I can use the MCP for free, put the data in my coding agent, and it's going to fix the issue for free and send it back. I'm curious to see, especially in coding where you can kind of have this closed loop where, okay, RDS MCP is going to become the paid AI offering so that then you can plug it in and. It's client going to have kind of like a MCP subscription where like totally you're kind of fractionalizing all these costs. To me today, it feels like it doesn't make a lot of sense the way they're structured.

Pash [00:16:07]: Well, yeah, we were like very early on. We like we've been bullish on MCP from the very beginning.

Saoud [00:16:13]: And we are a launch partner, a financial MCP, I think. Sorry to interrupt. Yeah, no worries. I think when Anthropic first launched MCP and they made this big announcement about this new protocol that they've been working on and open sourcing it. Nobody really. Understood what it meant. And it took me some time really digging into their documentation about how it works and why this is important. I think they kind of took this bet on the open source community contributing to an ecosystem in order for it to really take off. And so I wanted to try to help with that for as much as possible. So for a long time, most of client system prompt was how does MCP work? Because it was so new at the time that, you know, the models didn't know anything about it and how to make MCP servers. So like if the developer wanted to, you know, make something. Like that would be really good at it. And I'd like to think that, you know, client had something to do with how much the MCP ecosystem has grown since then. And just getting developers more insight and sort of awareness about how it works under the hood, which I think is incredibly important in using it, let alone just developing these things. And so, yeah, when we launched MCP in client, I remember our Discord users just trying to wrap their heads around it. And in seeing clients build MCP servers from the ground up, they're like, OK. They started to connect the dots. This is how it works under the hood. This is why it's useful. This is how agents connect to these tools and services and these APIs and sort of saved me a lot of the trouble of having to do this sort of stuff myself.

Pash [00:17:37]: Those were like the early days of MCP when people were still trying to wrap their heads around it. And there's like a big problem with discoverability. So back in like February, we launched the MCP marketplace where you could actually go through and have like this one-click install process where client would actually go through looking at a readme. And that's like linked to a GitHub, install the whole MCP server from scratch and just get it running immediately. And that was like, I think around that time, that's when MCP really started taking off with like the launch of the marketplace where people were able to discover MCPs, contribute to the MCP marketplace. We've listed over like 150 MCP servers since then. And like the top MCPs in our marketplace have over, you know, hundreds of thousands of downloads. People use them. And, you know, there's like really notable examples where you mentioned like, how are people like, it's like kind of eating existing products, but at the same time, we're starting to see like this ecosystem evolve where people are monetizing MCPs like a notable example of this is 21st dev magic MCP server where it injects some taste into this coding agent into the LLM where they have this library of beautiful components and they just inject relevant examples. So that. Client can go in and implement beautiful UIs. And the way they monetize that was like a standard API key. So we're starting to see developers really like take MCPs, build them in, have distribution platforms like the MCP marketplace and client and monetize their whole business around that. So now it's like almost like you're selling tools to agents, which is a really interesting topic.

Alessio [00:19:22]: And you can do that because you're in VS code. So you have the terminal. So you can do. And PX run the different servers. Have you thought about doing remote MCP hosting or you feel like that's not something you should take over?

Pash [00:19:35]: Yeah, we haven't really hosted any ourselves. We think that's we we're looking into it. I think it's it's all very nascent right now, the the remote MCPs, but we're definitely interested in supporting remote MCPs and listing them on our marketplace.

Saoud [00:19:50]: And another part, I think what sort of local MCP servers and remote MCPs is. Most of the remote MCPs are only useful to connect to different APIs. But that's only a you know, that's only a small use case for MCPs. A lot of MCPs help you connect to different applications on your computer. For example, there's like a a Unity MCP server that helps you create, you know, 3D objects with right from within VS code. There's an Ableton MCP server. You can make songs using something like client or whatever else uses MCPs. We won't see a world where these MCP servers are only hosted remotely. There will always be some mix of local MCP servers and remote MCP servers. I think the remote MCP servers do make the installation process a little bit easier with, you know, with something like an OAuth flow and just authenticating a little bit not as painful as having to manage API keys yourself. But for the most part, I think the MCPs ecosystem is is is really in its earlier days. We're still trying to figure out this good balance of security, but also convenience for the end developer so that it's not a pain to have to set these things up. And I think we're still in this very much experimental phase about how useful it is to people. And I think now that it is seeing this level of market fit and people are coming out with, you know, these sorts of like articles and workflows about how it's totally changing their jobs. I think there's going to be a lot more of resources and efforts that go into the ecosystem and just building out the protocol, which I think there's a lot on Anthropics Roadmap. And I think the community in general just has a lot of ideas and our marketplace in particular has given us insights into some ways that we can do this. And I think the community in general just has a lot of ideas and our marketplace in particular has given us insights into some ways that we can do this. and I think the community in general just has a lot of ideas and our marketplace in particular has given us insights into some ways that we can do this. Things that, you know, developers have asked for from it, that we're kind of thinking about how do we you know, what is the marketplace of the future look like? And for us, that's it's it's going to be a combination of, you know, well, there's a lot of our users are very security conscious. And there's a lot of ways that MCPs, you know, servers can be pretty dangerous to use if you don't trust the end developer of these things. And so we're trying to figure out, you know, what is a future look like where you can where you have some level of security? and to kind of build some level of confidence in the MCP servers you're installing? I think right now it's just it's too early and there's a lot of trust in the community that I don't think a lot of, you know, enterprise developers or organizations are quite willing to do yet. So that's something that's top of mind for us.

Swyx [00:22:10]: There's an interesting tension between the Nthopic and the community here. You basically kind of have a model register MCP registry internally, right? Honestly, I think you should expose it. I was looking for it on your website and you don't have it like the only way to access is to install client. But there's others like Smithery and all the other guys, right? But then Anthropic has also said they'll launch a model registry at some point or MCP registry at some point? Some point. If Anthropic launched the official one, would they just win by default, right? Because like, would you just use them?

Saoud [00:22:40]: I think so. I think the entire ecosystem will just converge around whatever they do. They just have such good distribution and they're, yeah, they came up with it. Yeah, exactly. Cool.

Swyx [00:22:49]: And then I wanted to, I noticed that you had some like really downloaded MCPs. I was going by most installs. I'm just going to read it off. You can stop me anytime to comment on them. So top is file system MCP. Makes sense. Browser tools from agent-AI. I don't know what that is. Sequential thinking. That one came out with the original MCP release. Context 7. I don't know that one.

Pash [00:23:12]: That's a big one. What is it? Context 7 kind of helps you pull in documentation from anywhere. And it has like this big index of all of the popular libraries and documentation for them. Okay. And you can, your agent can kind of submit like a natural language query and search for any documentation. It just says everyone's docs. Yes.

Swyx [00:23:33]: And apparently Upstash did that, which is also unusual because Upstash is just normally Redis. Git tools, that one came out originally. Fetch. Browser use. Browser use, I imagine, competes with browser tools, right? I guess. And then below that, playwright. Playwright, right? So there's a lot of. Like, let's automate the browser and let's do stuff. I assume for debugging. Firecrawl, Puppeteer, Figma. Here's one for you. Perplexity research. Is that yours?

Pash [00:23:59]: Well, yeah, I forked that one and listed it. But yeah, that's, you know, that's another very popular one where you can research anything.

Swyx [00:24:06]: So people want to emulate the browser. I'm just trying to learn lessons from what people are doing, right? They want to automate the browser. They want to access Git and file system. They want to access docs and search. Anything else? You think, like, it is notable?

Pash [00:24:21]: There's all kinds of stuff where it's like, you know, there's like the Slack MCP where you can send, you know, that's actually one workflow that I have set up where you can, like, automate repetitive tasks in Client. So I tell Client, like, OK, pull down this PR, use the GH command line tool, which I already have installed using the terminal to pull the PR, get the description of the PR, the discussion on it and get the full diff as like a like a single command, non-interactive command. Yeah. Pull in all that context, read the files around the diff, review it, ask a question like, hey, do you want me to approve this or not with this comment? And if I say yes, approve it and then send a message in Slack to my team using the Slack MCP, for example. Oh, use it to write. Yes. I would only use it to read. Yeah, no, it's, you know, people like I love it. You know, I love being able to just like send an automated message in Slack or whatever. You can also like set it up, like set up your workflow however you want, where it's like, OK, client. Please ask me before doing anything, you know, just make sure you're asking me to like approve before you send a message or something like that.

Swyx [00:25:26]: Yeah. OK, just just to close out MCP side, anything else interesting going on in MCP universe that we should talk about? MCP off was recently ratified.

Pash [00:25:34]: I think monetization is a big question right now for the MCP ecosystem. We've been talking a lot with Stripe. They're very bullish on MCP and they're trying to figure out like a monetization layer for it. But it's all so early that it's kind of hard to really even envision where it's going to go.

Swyx [00:25:55]: Let me just put up a straw man and you can tell me what's wrong with it. Like, how is this different from API monetization? Right. Like you sign up here, make an account, I give you a token back and then you use token. I charge you against your usage.

Pash [00:26:07]: No, like like I think that's how it is right now. That's how like the the magic MCP, the 21st dev guys did it. But we're kind of envisioning a world where agents can. Can pay themselves for these MCP tools that they're using and pay for each tool call and you can't deal with like a million different API keys from different products and like signing up for all this, there needs to be like a unified kind of payment layer. Some people talk about like stable coins, how like those are coming out now that agents can natively use those. Stripe is they're considering this like abstraction and around the MCP protocol for payments. But like I said, it's kind of hard to really tell where it's going. How that's going to manifest.

Swyx [00:26:50]: I would say like I covered when they launched their agent toolkit last year, a few months ago, it seemed like that was enough. Like you didn't seem to need stable coins except for the fact that they take like 30 cents every transaction. Yeah.

Alessio [00:27:04]: Have you seen people use the X402 thing by Coinbase to make this basically like the you can do a HTTP request that includes payment in it? What?

Pash [00:27:15]: Yeah, yeah, it's a it's been around forever. The 402 error that's like payment not accepted or something. Right. So, yeah, we've seen some people talking about that, like more like natively building that in. But yeah, nothing. Yeah, no one's really doing that right now.

Swyx [00:27:32]: Anything you're seeing on like are people like in making MCP startups that are interesting?

Alessio [00:27:39]: Mostly around rehosting local ones and do remote and then basically do instead of setting up 10 MCPs, you have like a canonical URL that you put in. All of your tools and then expose all the tools from all the servers. Yeah, there's like MCP that run some of these tools.

Swyx [00:27:54]: Yeah, but I think it kind of has the same issues of how do you incentivize people to make better MCPs, you know, and will it be mostly first party or will it be a third party? Yeah, like your perplexity. MCP was the photo.

Pash [00:28:06]: What's wrong with the perplexity when with MCPs and installing them locally on your device, there's always a massive risk associated with that. And when an MCP is created by someone that. We have no idea who they are at any point. They might, you know, update the GitHub to like introduce some kind of malicious stuff. So even if you like verified it when you're listing it, you might change it. So I ended up having to fork a few of those to make sure that we lock that version down.

Swyx [00:28:33]: Oh, OK. So this is just like you're just forking it so that you don't change it. Yeah, without without. That's interesting. These are all the problems of a registry, right? Like that you need to ensure security and all that. Cool. I'm happy to move on. I would say like the last thing that's kind of curious. It's like if Anthropic hasn't hadn't come along and made MCP, what would have happened? What's the alternative history like? Would you have come with MCP?

Saoud [00:28:56]: So we saw some of our competitors who have been kind of working on their own version of plug and play tools into these agents. They kind of had to natively create these tools and integrations themselves directly into their product. And so I think anybody in the space would have had to just do the laborious work of having to recreate these tools and integrations for So I think Anthropic just saved us all a lot of trouble and tapped into the power of open source and community driven development and allowed, you know, individual contributors to make an MCP for anything people could think of and really take advantage of people's imagination in a way that I think is necessary right now for us to really tap into full potential of this sort of thing.

Alessio [00:29:38]: So we've had, I think, a dozen episodes with different coding products. Yeah.

Swyx [00:29:43]: And this, by the way, this this episode came directly after he tweeted about it. I think he tweeted about the Cloud Code episode where they were sitting right where you're sitting. Thanks for sharing the clip. Talking about RAG. Yeah.

Alessio [00:29:52]: Can you give people maybe the matrix of the market of, you know, you have like fully agentic, no IDE, you have agentic plus IDE, which is kind of yours. You have IDE with some co-piloting. How should people think about the different tools and what you guys are best at or maybe what you don't think you're best at?

Saoud [00:30:11]: I think what we're best at and like our ethos since the beginning is just meet the developers where they're at today. I think there is a little bit of insight and handholding these models need right now. And the IDE is sort of the perfect conduit for something like that. You can see the edits it's making. You can see the commands that it's running. You can see the tools that it's calling. It gives you the perfect UX for you to have the level of insight and control and be able to course correct the way that you need to to work with the limitations of these models today. But I think it's pretty obvious that as the models get better, you'll be doing less and less than that, less and less of that and more and more of the initial planning. And prompting and sort of have the trust and confidence that, you know, the model will be able to get the job done pretty much exactly how you want it to. I think there will always be a little bit of a gap in that these models will never be able to read our minds. So there will have to be a little bit of, you know, making sure that you give it the most comprehensive and sort of like all the details of what you want from it. So if you're a lazy prompter, you can expect a ton of friction and back and forth. You really get what you want. But I think we're all learning for ourselves as we work with these things, kind of the right way to prompt these things and to be explicit about what it is that we want and kind of how they hallucinate the gaps that they might need to fill to get to the end result and how we might want to avoid something like that. So what's interesting about Cloud Code is there isn't really a lot of insight into what the agent's doing. It kind of gives you this like checklist of what it's doing holistically at a high level. I don't think that really would have worked well if the models weren't good enough to actually produce. But I think the space has to catch up to, okay, maybe people don't need as much insight into these sorts of things anymore. And they are okay with letting an agent kind of get the job done. And really all you need to see is sort of the end result and tweak it a little bit before it's really perfect. And I think there is going to be different tools for different jobs. I think something like totally autonomous agent that you don't have a lot of insight into is great for maybe scaffolding. New projects, but for kind of the serious, more complex sorts of things where, you know, you do need a certain level of insight or you do need to kind of have like more engagement. You might want to use something that does give you some more insight. So I think these sorts of tools complement each other. So for example, writing tests or spinning off 10 agents to try to fix the same bug, you know, might be useful for a tool that doesn't require too much engagement from you. Whereas something that requires a little bit more creativity or imagination. Or extracting context from your brain requires a little bit more of insight into what the model is doing and a back and forth that I think client is a little bit better suited for.

Pash [00:32:57]: Like visibility into what the agent is doing. That's like one axis. And then another is autonomy, like how automated it is. And we have a category of companies that are focusing more on the use case of people that don't even want to look at code, which is like, you know, the lovables, the replets. Where. It's like you go in, you build an app, you might not even be technical and you're just happy with the result. And then you have kind of stuff that's kind of like a hybrid where it's, you know, for engineers, it's built for engineers, but you don't really have a lot of visibility into what's going on in a hood. This is like for like the vibe coders where they're, you know, fully, you know, letting, letting the AI take the wheel and building stuff very rapidly and lots of open source fans and, you know, people that are hobbyists enjoy coding in this. And then you get to like serious engineering teams where they can't really give everything over to the AI, at least not yet. And they need to have high visibility into what's going on every step of the way and make sure that they actually understand what's happening with their code. You're kind of handing off your production code base to this non-deterministic system and then hoping that you catch it in review if anything goes wrong. Whereas personally, the way I use AI, the way I use Cline is I like to be there every step of the way and kind of guide it in the right direction. So I know every step of the way, like as every file is being edited, I prove every single thing and make sure that things are going in the right direction. I have a good understanding as things are being developed, where it's going. So like this kind of hybrid workflow really works for me personally. But, you know, sometimes if I want to go full YOLO mode, I go ahead and just auto approve everything. And just step out for a cup of coffee and then come back and, you know, review the work.

Alessio [00:34:50]: My issue with this as an engineer myself is that we all want to believe that we work on the complex things. How have you guys seen the line of complex change over time? I mean, if we sat down having this discussion 12 months ago, complex was like much easier than today for the models. Do you feel like that's evolving quickly enough that like, you know, in 18 months, it's like you should probably just do four. Follow Gen Tech for like 75% of work, 80% of work, or do you feel like it's not moving as quickly as you thought?

Saoud [00:35:21]: I think, I think what was complex a couple of years ago is totally different to what is complex today. Now, I think what we need to be more intentional about are the architectural decisions we make really early on and how the model kind of builds on top of that. If you have kind of a clear direction of where things are headed and what you want, you kind of have a good idea to what, how you might want to like lay the foundation for it. And I think what we might have considered complex a few years ago, algorithmic, you know, challenges, that's pretty trivial for models today and stuff that we don't really necessarily have to think too much about anymore. We kind of give it, you know, a certain expectation or unit test about what we want, and it kind of goes off and puts together the, you know, the perfect solution. So I think there's a lot more thought that has to go into tasteful architectural decisions that really comes down to you having experience with what works and what doesn't work. Having a clear idea. For the direction of where you want to take the project and sort of your vision for the code base. Those are all decisions that I think is hard to rely on a model for because of its limited context and its, you know, its inability to kind of see your vision for things and really have a good understanding of what you're trying to accomplish without you, you know, putting together a massive prompt of, you know, everything that you want from it. But I think what we were, you know, what we spent most of our time working on a couple years ago has totally changed. And I think for the better. I think architectural decisions are a lot more fun to think about than putting together algorithms.

Pash [00:36:49]: It kind of frees up the senior software engineers to think more architecturally. And then once they have a really good understanding of what's what the current state of the repository is, what the current state of the architecture is, and when they're introducing something new, they're really thinking at an architectural level. And they articulate that to Cline. And that's also there's like some skill involved there. And some of that can be mitigated with like asking follow up questions, being proactive about clarifying. Things on the agent side, but ultimately, you need to articulate this new architecture to the agent, and then the agent can go down and down into the mines and implement everything for you. And it is more fun working that way. Like, personally, like, I find it a lot more engaging to just think on a more architectural level and for junior engineers, it's a really good paradigm to learn about the code base. It's kind of like having a senior engineer in your back pocket where you're asking Cline. Like, hey, can you explain the repository for me? If I wanted to implement something like this, what files would I look at? How does this work? It's great for that as well.

Alessio [00:37:53]: If you're moving on from competition, I have one last question. Competition. Yeah. So there's Twitter beef with RooCode. I just want to know what the backstory is, because you tweeted yesterday, somebody asked RooCode to add Gemini CLI support, and then you guys responded, just copy it from us again. And they said, thank you. We'll make sure to give credit. Is it a real beef? No. Is it a friendly beef?

Pash [00:38:16]: I think we're all just having fun on the timeline. There's a lot of forks.

Saoud [00:38:21]: There's like 6,000 forks.

Pash [00:38:23]: Yeah, there's like, if you search Cline in the VS Code marketplace, it's like the entire page is just like forks of Cline. And there's like even forks of forks that, you know, came out and raised like a whole bunch of money. What? Yeah, it's crazy.

Saoud [00:38:37]: The top three apps in OpenRouter are all Cline, and then Cline fork, Cline fork.

Pash [00:38:42]: It's funny. Yeah, billions of tokens getting sent through. Like all these forks, there's like, there's like fork wars and 10,000 forks and all you need is a knife, you know, so no, it's, it's exciting. Uh, I think they're all really cool people. We've got people in Europe forking us. We've got people in China making like a little fork of us. I think Samsung recently came out with like a, was a Wall Street Journal article where they're using Cline, but they're using like their own little fork of Cline. That's kind of isolated. You know, we, we encourage it.

Alessio [00:39:12]: Do you have any regrets about being open source?

Saoud [00:39:14]: Not at all. I think Cline started off as this like really good foundation for what a coding agent looks like, and people just had a lot of their own really interesting ideas and spinoffs and concepts about, you know, what they thought, you know, they, that they wanted to build on top of it was, and just being able to see that and see the excitement around, just in the space in general has just been, I think, inspirational and has helped us kind of glean insights into what works and what doesn't work and incorporate that into our own product. And for the most part, I think for, you know, the same. I think for many of us, like, you know, we've been so many years with Samsung and all of the organizations where there's a lot of friction and be able to use software like this on their, on their code bases, it reduces that barrier to entry, which I think is like incredibly important when you want to get your feet wet with this whole new agentic coding paradigm that's going to completely upend the way that we've written software for decades. So in the grand scheme of things, I think it's a net positive for the world and for the space. And so no regrets.

Pash [00:40:07]: In a lot of ways, like, you know, it's us and the Forks. We were kind of there originally when we were like the only ones with this. philosophy of keeping things simple, keeping things down to like the model, letting the model do everything, not cutting on, not trying to make money off of inference, going context heavy, reading files into context very aggressively. And kind of going back to Cloud Code, I was actually like, it was really nice to see that they came out and they validated our whole philosophy of like, keeping things as simple as possible. And that kind of goes in with like the whole rag thing, which is like, rag was the early thing in like 2022. You started getting these vector database companies, context windows were very small. This was like a way of people called it like, oh, you can give your AI infinite memory. It's not really that. But that was like, the marketing that was sold to the venture backers that were like investing in all these companies. And it became this narrative that really stuck around. And like, even now, like we get like potential, like, you know, enterprise perspective, like they're, they're, they're going through like the procurement process. And they're, it's almost like they're going through like a checklist asking, like, hey, do you guys do like indexing, like of the code base and doing rag? And I'm like, well, why? Like, why are you like, why do you want to do this? I think Boris said it said it very well on this exact podcast where we tried rag and it doesn't really work very well, especially for coding is like, the way rag works is you have to like chunk all these files across your entire repository and like chop them up in a small little piece. And then throw them into this hyper dimensional vector space, and then pull out these random chugs when you're searching for relevant code snippets. And it's like, fundamentally, it's like so schizo. And like, I think it actually distracts the model. And you get worse performance than just doing well, like a senior software engineer does when they first, they're introduced to a new repository, where it's like that you look at the folder structure, you look through the files, oh, this file imports from this other file, let's go take a look at that. And you kind of agentically explore the repository. That's like, we found that works so much better. And there's like similar things where it's like, like the simplicity always wins, like this bitter lesson where fast apply is another example. So cursor came out with this fast apply, like they call the instant apply back in July of 2024, where the idea was models at the time were not very good at editing files. And the way editing files works in kind of the context of an agent is you have a search block, and then a replace block where you have to like match the search block exactly to what you're trying to replace. And then a replace block just swaps that out. And at the time models were not very good. It was like, I forget, like GPT they were using under the hood at the time wasn't very good at formulating these search blocks perfectly, and it would fail oftentimes. So they came up with this clever workaround to fine tune this fast apply model where they let these frontier models at the time, they let them be vague, they let them output those like lazy code snippets that we're all very familiar with, where it's like rest of the file here, like rest of the imports here, and then fed that into this fine tuned fast apply model that was like, probably like a Quen 7b or something quantized, very small, dinky little model. And they fed this lazy code snippet into this smaller model and the smaller model we fine tuned to output the entire file with the code changes applied. And that, you know, the one of the founders of Ader said this really well, and like very early GitHub sessions, where he said, like, well, now instead of worrying about one model messing things up, now you have to worry about two models messing things up. And what's worse is the other model that you're giving that you're handing your production code to this like fast apply model, it's like, it's a tiny model, its reasoning is not very good. It's maximum output tokens, you know, there might be 8000 tokens, 16,000 tokens, now they're training like 32,000 tokens, maybe. And a lot of the coding files, like we have a five file in our repository, that's like 42,000 tokens long, and that's longer than the maximum token output length of one of these smaller fast apply models. So what do you do then, then you have to build workarounds around that, then you have to build all this infrastructure to like pass things off. And then it's making mistakes. It's like very subtle mistakes to where it's like, it looks like it's working, but it's not actually what the original frontier model suggested. And it's like slightly different. And it introduces like all of these subtle bugs into your code. And what we're starting to see is like, as AI gets better, the application layer is reducing, you're not going to need all these clever workarounds, you're not going to have to maintain these systems. So it's really liberating to not be bogged down with RAG, or with fast apply, and just focus on this like core agentic loop and maximizing diff edit failures. Like in our own internal benchmarks, Cloud Sonnet 4 recently hit a sub 5%, or like around actually 4% diff edit failure rate. At like when fast apply came out, that was way higher, that was like in the 20s and the 30s. Now we're down to 4%, right? And in six months, how does it go to zero? Well, it's going to zero, like as we speak, it's going to zero every day, you know, and I was actually talking with the founders of some of these companies that do fast apply, they're trying to kind of work with us, their whole bread and butter is fine tuning these fast apply models. And you know, like relays and morph. And I had like a very candid conversation with these guys where I was like, well, there's a window of time where fast apply was relevant. Cursor started this window of time back in July. How much time do you think we have left until they're no longer relevant? Do you think it's an infinite time window? They're like, no, it's definitely finite. Like this, this era of fast apply models is definitely coming to an end. And I was like, well, how long do you guys think they were like, maybe three months, maybe less. So I still think there's some cases where RAG is useful. You know, if you have a lot of human readable, readable documents, large knowledge, base of documents where you don't really care about like inherent logic within them, like sure, index it, chunk it, do retrieval on it, or fast applies, like maybe if your organization you're forced into using like a very small model, that's not very good at search and replace like a deep seek or something, you know, maybe use a fast apply model.

Saoud [00:46:33]: I think RAG and fast apply were these just tools in a toolkit for when models weren't the greatest at large context or search and replace diff editing. But now they are extra ingredients that could make things go wrong that you just don't need anymore. There was an interesting article from Cognition Labs about, you know, multi-agent orchestration. Getting right into it. It's like you're on autopilot for us. That's cool. Yeah. I mean, it's a great article. Yeah, it's a great article. They talked about how, you know, when you start working with different models, different agents, there's a lot that gets lost in the details. And, you know, the devil in the details, that's, those are the most important things and making sure that it doesn't, you don't have the agent sort of like running in loops and running to the same issues again and have sort of like all the right contexts. And so I think being close to the model, throwing all the context you need at it, not taking these cost optimized approach to pulling in relevant context, use something like RAG or a cheaper model to apply edits to a file. I think ultimately, yes, it's more expensive. It's asking, you know, a model like Cloud Sonnet to do sort of all these sorts of things, to grep an entire code base and to, you know, fill up its entire context. But you kind of get what you pay for. And I think that's been another benefit of being open source is that our developers, they can peek under the kimono. They can see, you know, where their requests are being sent, what prompts are going into these things. And that creates a certain level of trust where, you know, when they spend $10, $20, $100 a day, they know kind of where their data is being sent. That one model is being sent to what prompts are going into these things. And so they get comfortable with the idea of spending that much money, get the job done.

Pash [00:48:19]: Yeah, it's like not making money off of inference. I think the incentives are so they're so relevant in this discussion because, you know, if you're incentivized, you know, if you're charging, you know, $20 per month and you're trying to make money on that, you're going to be offloading all kinds of important work to smaller models or optimizing for costs with RAG, like retrieval with RAG. Yeah. Not reading the entire file, but maybe reading like a small snippet of it. Whereas if you're not making money off inference and you're just going direct, you know, users can bring their own API keys. Well, then all of a sudden you're not incentivized to cut down on cost. You're actually incentivized just to build the best possible agent. We're starting to see this trend of the whole industry is moving in that direction, right? You're starting to see like everyone open up to pay as you go models or pay directly for inference. And I think that is the future.

Alessio [00:49:12]: What's the Cline pricing business model?

Saoud [00:49:15]: Right now, it's bringing an API key, essentially just whatever pre-commitment you might have to whatever inference provider, whatever model you think works best for your type of work. You just plug in your Anthropic or OpenAI or OpenRouter, whatever it is, API key into Cline, and it connects directly to whatever model you select. And I think that level of transparency, that level of we're building the best product. We're not focused on sort of capturing margin on, you know, the price obfuscation and clever tricks and model orchestration to, you know, keep costs low for us and optimize for higher profits. I think that's put us in this like unique position to really push these models to their full potential. And I think that's shown, you know, I think that's, that's, you get what you pay for, throw a task in Cline and, and it gets expensive.

Pash [00:50:08]: But that's the cost of intelligence.

Saoud [00:50:11]: That's the cost of intelligence, yeah. So yeah, the business model right now is, is you get to choose kind of where it's open source, you can fork it, you can choose where your data gets, and you can choose who you want to pay. A lot of organizations we've talked to get some, you know, a certain level of volume based discounts with, with these providers. And so they could, they can take advantage of that through Cline, which is helpful because Cline can get pretty expensive. And yeah.

Swyx [00:50:34]: Wait, so, I mean, I'm still not hearing how you make money. Like you said you don't. Huh? Why? Why make money? Yeah. Uh, cause you have to pay your salaries.

Pash [00:50:44]: No, that's the, that's the, a lot of people ask us that and I always just throw the why at them, but it's, um.

Swyx [00:50:49]: These just sound like the PartyFool guys. PartyFool is like.

Pash [00:50:51]: The real answer is enterprise. So, um.

Swyx [00:50:54]: Which, uh, we can say, because you're, you know, we release this when you launch it. Yeah. Yeah.

Pash [00:50:58]: So you want to talk about enterprise? Yeah.

Saoud [00:51:01]: I think being open source and bringing in API key has given us a lot of easy adoption in these organizations where things like data privacy and control and security are top of my list. And I think that's something that's really important to keep in mind. And it's hard to commit to sending their code and plain text to God knows what servers training their data to do training their data on models that might, you know, output their IP to random users. I think there, people are a lot more conscious about where their data is getting sent and what's being used to it. And so it's given us this opportunity to say, okay, nothing passes through our own servers. You have total control over the entire application where your data gets sent. And that's good. And I think, you know, one of the things that we've been talking about in this given organization is that, you know, we've been talking to over the course of the last couple of months, this sort of like easy adoption and I think this opportunity for us to, to work more closely with them and say, you know, what are all the things that we can do to help with adoption and the rest of your organization, essentially, how can we pour gasoline on sort of the evangelism that, you know, people have for client in these organizations and spread the usage of, of agent decoding, I think at an enterprise level.

Pash [00:52:08]: Well, yeah, what's, what's crazy is, um, so we, we had. We open source Cline, people really liked it. Developers were using it within their organizations or organizations were kind of like reluctantly okay with it because they saw like we're open source and we're not sending our data, their data anywhere. They could use their existing API keys. and then we launched like on our website, like a contact form for enterprise, like if you're interested in enterprise offering, hit us up. And we had no real enterprise product at the time. And it turned out like we just got this massive. Influx of. Big enterprises reaching out to us and, you know, we had a fortune five company come up to us and they were like, Hey, um, we have hundreds of engineers using Cline within our organization and this is a massive problem for us. This is like a fire that we need to put out because we have no idea what API keys they're using, how much they're spending, where they're sending their data. Please just like, let us give you money to make an enterprise product. So the product kind of just evolved out of that. Right, right.

Saoud [00:53:11]: I mean, it's, it really just. Comes down to more of listening to our users. So right after we put out this page, we just had a lot of demand for sort of like the table stake enterprise features, the security guard rails and governance and insights that sort of like the admins in these organizations need to, to reliably use something like Cline. Yeah. We've gotten a lot of people wanting us to sort of give them two things, invoices just to help with like all the budgeting and spending the, you know, thousands of dollars. All the Europeans. Yeah. Just the other thing, which I thought was a little bit surprising was some level of insight into the benefit that Cline's providing them. So it could be our Sage or lines of code written because it allows these sort of like AI forward drivers for adopting these sorts of tools in these organizations to take that as a proof point and go to the rest of their teams and say, this is how much Cline's helping me. You need to start adopting this so we can keep up with the rest of the industry.

Swyx [00:54:07]: This is for like internal champions to prove their ROI. Exactly. Okay.

Saoud [00:54:11]: Can they use the same thing on the probable base that to justify the spend? Yeah.

Swyx [00:54:18]: We can do this afterwards, but we would like to talk to those and actually feature some of them. What they're saying to their bosses on the podcast so that we can get a sense because like often times we hear, we only talk to founders and builders of like the dev tool, but like not the end consumer. And actually we want to hear from them, right? Like about how they're thinking about what they need. To kind of, kind of cool. One thing I wanted to ask, to double-click on is about you was an Instagram doc in your group. is the relationship between Open Router and then like your enterprise offering, right? So my understanding is currently everything runs through Open Router.

Saoud [00:54:49]: Not everything. So you can bring API keys to OpenAI, Anthropic, Bedrock. And then you have a direct connection there. If the user has a direct connection there.

Swyx [00:54:59]: But everything else would run through Open Router. And so basically the enterprise version of Client would be you have your own Open Router that you would provide visibility and control to that enterprise.

Pash [00:55:12]: Yeah, like that's for like the self-hosted option, right? Like there's a lot of enterprises where they're okay with not self-hosting, but as long as they're using their own Bedrock API keys and stuff like that. Whereas the ones that are really interested in like self-hosting or like that want to be able to manage their teams, there would be like this internal router going on.

Swyx [00:55:32]: The curious thing here is like, what if model costs just go to zero? Like Gemini code just comes out and it's like, yeah, guys, it's free. Well, yeah. That'd be great for us.

Saoud [00:55:42]: Yeah, that'd be great for us. So our thesis is inference is not the business.

Swyx [00:55:46]: You will just never make money on inference, right? Yeah.

Saoud [00:55:48]: We want to give the end user total transparency into price, which I think is like incredibly important to even get comfortable with the idea of spending as much money as you do. I think the price obfuscation in this space has given developers this reluctance to opt into usage-based plans. And we're seeing a lot of... I think a lot of people kind of converge on this concept of, okay, maybe have like a base plan just to use the product, but sort of get out of the way of the inference and respect the end developer enough to give them the level of insight into not just the cost, but the models being used and give them more confidence in spending however much it takes to get the work done. I think you can use tricks like RAG and FASTA plan, things like that to keep costs low. But for the most part, there's enough ROI on coding agents where, you know, people are willing to spend money to get the job done.

Pash [00:56:39]: And for a truly good coding agent, the ROI is almost hard to even calculate because there's so many things that I would have never even bothered doing. But now I have Cline and I could just do this weird experiment or do this side project or fix this random bug that I would have never even thought about. So how do you measure that?

Swyx [00:57:01]: One variant of this problem... We're about to move on to context engineering and memory and all the other stuff. One variant. The other variant of this I wanted to touch on a little bit was just background agents and multi-agents. So the instantiations of this now, I would say, are background agents. It would be Codex, for example, like spinning up, you know, one PR per minute or Devin or Cognition. So would you ever go there? That's one concrete question I can ask you. Would there be Cline on the server, whatever? And then the other version is still on the laptop, but more sort of parallel agents like the Kanban. It's currently very hyped right now. People are making like Kanban interfaces for Cursor and also for Cloud Code. Just anything like in the parallel or background side of things.

Pash [00:57:48]: We're releasing a CLI version of Cline and using the CLI version of Cline, it's fully modular. So you can ask Cline to run the CLI to spin up more Clines or you could run Cline in some kind of cloud process in a GitHub action. Whatever you want. So the CLI is really the form factor for these kind of fully autonomous agents. And it's also nice to be able to tap into an existing Cline CLI running on your computer and be able to like take over and steer it in the right direction. So that's also possible. But what do you think, Saad?

Saoud [00:58:23]: I don't think it's an either or. I think all these different modalities complement each other really well. So the Codex, the Devins, Cursor's background agent, I think they all sort of accomplish the same thing. They. If we were to come out with our own version of it, I'd say that it would be a foundation for how other developers could build on top of it. So Nick's older brother, Andre, he's sort of thinking 10 years ahead. And it always kind of blows my mind a little bit about some of the ideas that he has about where the space is going. But we recently had a discussion about building this open source framework for coding agents for any sort of platform. Building the SDK and the tool. And all the other things that might be helpful and necessary to bring Cline to. Chroma as an extension, to the CLI, to JetBrains, to Jupyter notebooks, to your smart car, whatever it is. But to build a. Your fridge. Your fridge. Exactly. Microwave. Yeah, exactly. This is what we saw kind of like with the 6000Forks on top of Cline, is we sort of put together this foundation for how this community of developers, we sort of put together this foundation that this community of developers could build on top of. And sort of take advantage of. You know, their experiments and imagination and their creativity about where the space is headed. And I think looking forward, building an open source foundation and the building blocks for how we bring something like Client to things that go outside the scope of software development or, you know, VS Code extension. I think that'll open up the door to things that, you know, ultimately complement each other really well, but it'll never be sort of this like either or thing. I think background agents are good for certain kinds of work and parallel Kanban multi-agents might be good for when you want to experiment and iterate on, you know, five different versions of, you know, how a landing page might look. And then something like a back and forth with a single agent like Client works really well for when you want to, you know, pull context and put together a really complicated plan for a really complex task. And I think all these different... tools will ultimately end up complementing each other and people will kind of develop a taste and an understanding for what works best for what kind of work. But I think just looking 10 years ahead, we at the very least want to sort of be at the frontier of providing sort of the building blocks for what the next thing is after background agents or, you know, multi-agents.

Swyx [01:00:42]: I was going to go into context engineering kind of like topic du jour. I think that this is kind of similar-ish in a thread to RAG and how RAG is a mind virus, which I love, by the way, that... the way that you phrased it. Yeah, you have in your docs context management. You also have a section on memory bank, which is kind of cool. I think a lot of people are trying to figure out memory. Let's just start at the high level and then we'll go into memory later. What, you know, what does context engineering mean to you?

Saoud [01:01:07]: Context engineering mean to me?

Swyx [01:01:10]: It means prompt engineering. Yeah, right. Like, I mean, so I think like there is a lot of art to like what goes in there. I think that really is like the 80-20 of building a really good agent. It's like figuring out... figuring out what goes into the context and, you know, I think interplay between MCP and your system client, you know, recommended prompts, I think, is what is ultimately making a good agent.

Pash [01:01:37]: Yeah, I think context management is like one part of it is what you load in to context. The other part of it is how do you clean things up when you're reaching the context window, right? How do you curate that whole lifecycle? Yeah, I think context management is like one part of it is how do you clean things up when you're reaching the context window, right? And the way that I think about it is there's so many options on the table and there's so many risks to misdirecting the agents or distracting the agents. There's ideas about, you know, RAG or other kinds of forms of retrieval. That's one idea. There's the agentic exploration. That's another idea that we found works much better. And it seems like the trend is changing. Generally, for loading things into context, it's giving the model the tools that it can use to pull things into context, letting the model decide what exactly to pull into context, as well as some hints along the way, kind of like a like a map of what's going on, like ASTs, abstract syntax trees, potentially what tabs they have open in VS Code. That was actually in our internal kind of benchmarking that turned out to work very, very well. It's almost like it's reading your mind when you have like a few.

Swyx [01:02:53]: It stresses me out because like sometimes then I'm like, I have like unrelated tabs open and I have to go close them before I kick off a thing.

Pash [01:02:59]: I wouldn't think too much about it, especially when you're using Cline. Cline does a pretty good job of just navigating that. But I definitely, there are edge cases, right? There's edge cases for everything. And it's kind of like, okay, what's like the majority use case is like, you know, when are you starting a brand new task and you don't have a single tab open that's relevant to it? Obviously, in the CLI, you might, you don't have that little indicator. So there you have to think. You don't have to have a whole lot of things outside the box for that. So that's like for reading things into context. And then for context management is when you're approaching the full capacity of the context window is how do you condense that? And we've played around with this kind of naive truncation very early on where we just like throw out the first half of the conversation. It's coming. And there's problems with that, obviously. Because it's like. Kind of like. You're halfway through a book. And you. You're like. Like, you start reading halfway through, right? You don't know anything that happened beforehand. And we like to think a lot about, like, narrative integrity is, like, every task and client is kind of like a story. It might be a boring story where it's, like, this lonely coding agent that's just, you know, determined to help you solve, you know, whatever it is. Like, the big thing that the protagonist needs to overcome is, like, the resolution of the task, right? But how do we maintain that narrative integrity where every step of the way the agent can kind of predict the next token, which is, like, predict the next part of the story to reach that conclusion? So, we played around with things like cleaning up duplicate file reads. That works pretty well. But ultimately, this is another case where it's, like, well, what if you just give the model, like, what if you just ask the model, like, what do you think belongs in context? Another form of this is summarization, which is, like, hey, summarize all the relevant details. And then we'll swap that in. And that works really, really well.

Swyx [01:04:50]: Double-clicking on the AST mention, that's very verbose. When do you use that?

Saoud [01:04:56]: Right now, it's a tool. The way that it works is when client is doing sort of the agentic exploration of trying to pull in relevant context, and it wants to sort of get an idea of what's going on in a certain directory, for example, there's a tool that lets it pull in all the sort of language from a directory. So, it could be the names. It could be the names of classes, the names of functions, and that gives it some idea of, okay, here's what's going on in this folder. And if it seems relevant to whatever the task is trying to accomplish is, then it sort of, like, zooms in and starts to actually read those entire files into context. So, it's essentially a way to help it kind of figure out how to navigate through large codebases.

Pash [01:05:36]: Yeah, we've seen some companies working on, it's, like, an interesting idea, it's, like, an AST, but it's also a knowledge graph, and you can run these discrete determinants. So, it's kind of, like, you know, you can run these deterministic, almost, like, actions on this knowledge graph, where you could say, like, hey, find me all the functions that, find me all the functions of the codebase, and find me all the functions that aren't being used, and delete all of them, and the agent can kind of reason in this almost, like, SQL-like language, working with this knowledge graph to do these kinds of global operations. Like, right now, if you ask a coding agent to go through and remove all unused functions, or do, like, some kind of large refactoring work, in some cases, it might work. Very oftentimes, it's just going to struggle a lot, burn a lot of tokens, and fail, ultimately, whereas with these kinds of tools, it can actually operate on the entire repository with these kinds of query, like, short little query statements. I think there is a lot of potential in something like this, where it's, like, the next level beyond the AST, and it's, like, a language for querying this kind of knowledge graph, but, like, we've seen with, like, the Cloud 4 release is, these frontier model shops, they tend to train on their own application layer, and you might come up with, like, a very clever tool that, in theory, would work really well, but then it doesn't work well with Cloud 4, because Cloud 4 is trained to grep, right? So, that's another interesting phenomenon, where it's, like, you're expecting these frontier models to become more generalized over time, but, instead, they're becoming more specialized, and you have to, like, support these different model families.

Alessio [01:07:15]: Just to wrap on the memory side, memory is almost the artifact of summarization. So, you summarize the context, and then you kind of extract some sides. Any interesting learnings from there? Like, things that are maybe not as intuitive, especially for code? I think people grasp the, like, memory about humans, but, like, what are memories about code bases and things look like?

Saoud [01:07:37]: I think memories, right now, for the large part, are mostly useless. I think the kinds of memories that you might want decoding. I think the kind of memories that you might want decoding.

Saoud [01:08:16]: And I don't think people, they don't want to have to think about those sorts of things. So it's something we're thinking about is how can we hold on to the tribal knowledge that these agents learn along the way that people aren't documenting or putting into rules files without the user having to go out of their way to sort of force them to store these things into a memory database, for example.

Pash [01:08:37]: Those are like kind of like workspace rules or tribal knowledge, like general patterns that you use as a team. But then there is like in our, we ran this like internal experiment where we built this to-do list tool where there's only one tool where you could just write the to-do. And every time you could like rewrite the to-do from scratch. And we would passively as part of every, like not every message, but like every once in a while, we would pass in this context of what the latest state of this to-do list is. And we found that that actually keeps the agent on track after multiple rounds of context summarization and compaction. And it could all of a sudden build like an entire complex kind of task from scratch over, you know, 10x the context window length. And in internal testing, this was like very, very promising. So we're trying to flesh that out. And I think something like that, we had earlier versions of the memory bank, which actually. Our like Nick, Nick Bauman, our marketing guy came up with this memory bank concept where it was like this client rules where he would tell a client like, Hey, whenever you're working, have the scratch pad of what you're working on. And this is like a more built-in way of doing that. And I think that also might be very, very, very helpful for the agents to just have like a little scratch pad of like, Hey, what have I done so far? What's left specific app file mentions, like what kind of code we're working on general. Context and passing that off between sessions. Yeah.

Alessio [01:10:14]: Any thought on CloudMD versus AgentsMD versus AgentMD? I built an open source tool called Agents927, like the XKCD that just copy paste this across all the different file names. So all of them have access to it. Do you think there should be a single file? Like there's also like the IDE rules versus the agent rules. There's kind of like a lot of issues.

Saoud [01:10:35]: I actually think it's fine that each of these different tools have their own specific instructions. Because I find myself using a cursor rules and a client rules separately. When I want client the agent, I want him to work, you know, a certain way that's different than how I might want, you know, cursor to interact with my codebase. So I think each tool is specific to the kind of work that I do. And I have different instructions for how I want these things to operate. So I think I've seen like a lot of people complain about it. And I get that it could make codebases look a little bit ugly. But for me, it's been like incredibly helpful for them to be separated.

Swyx [01:11:07]: I noticed that you said him. Does this client have? Cline's the he-him. Does he have a whole backstory personality? Yeah.

Saoud [01:11:16]: So Cline is a play on CLI and editor.

Swyx [01:11:20]: Because it used to be Claude Dev and now it's Cline. Yeah.

Saoud [01:11:22]: I feel like Cline kind of stands out in the space for having, for being a little more humanized than something like, you know, a cursor agent or a co-pilot or a cascade.

Swyx [01:11:32]: And I think there's Devon, which is a real name, you know. Claude is a real name, I guess. Claude's a real name. Yeah.

Saoud [01:11:38]: Yeah. So I've been, I've been in, I think we've all been in Cline. It's been a little bit of both. a little bit more self-aware than I was when I was in Cline. I think that's what makes me more confident. I think that's what makes me more confident because I was more, I was more confident that I could lean on it a little bit more. There's, there's kind of a, of a trust building with, I think with an agent and the humanizing aspect of it, I think has been helpful to me personally. And.

Pash [01:11:56]: And this goes back to like the narrative integrity is just, it's actually really It's really important, I think, to anthropomorphize agents in general, because everything they do is like a little story. And without having a distinct kind of identity, you get worse results. And when you're developing these agents, that's kind of how we need to think about them, right? We need to think that we're like crafting these stories. We're almost like Hollywood directors, right? We're putting all the right pieces in place for the story to unfold. And yeah, having an identity around that is really, really important.

Swyx [01:12:30]: And Cline, you know, he's a cool little guy. He's just a chill guy. He's helping us out. You know, he's always like happy to help. Or if you tell him to not be happy, he can be very grumpy. So that's great. Awesome. I know you're hiring. You have 20 people now. You are aiming to 100. You have a beautiful new office. What's your best pitch for working at Cline?

Saoud [01:12:55]: A lot of our hiring right now is, so far, it's been just friends of friends, people in our network, people that we've worked with before that we've trusted and that we know can show up for like this incredibly hard thing that we're working on. And there's a lot of challenges ahead. And I think the problem space is probably the most exciting thing to be working on right now. Engineers in general love working on things that make their own lives easier. And so I couldn't imagine working on something more exciting than a coding agent. You know, it's a little biased, but I think a large part of it is it's an exciting problem space. We're looking for really motivated people that want to work on challenges like figuring out kind of like what the next 10 years looks like and building kind of the foundation for, you know, what comes next after background agents or multi agents and really help in sort of defining how all this shapes up. We have this like really excited community of users and developers. I think being open source has also created a lot of goodwill with us, where a lot of the feedback we get. is like incredibly constructive and helpful in shaping our roadmap and, and the product that we're building and working with a community like that is like one of the most fulfilling things ever. Right now, we're kind of in between offices, but, you know, doing things like go karting and kayaking and things like that. So it's a lot of hard work, but you know, we make sure to have fun along the way. So

Pash [01:14:15]: Yeah, no, like client is a, it's a unique company, because it really does feel like we're all just like friends building something cool. And we work really, really hard. And the space is, it's not just competitive, it's like hyper competitive, there's, like capital is flowing into all every single possible competitors, we have forks of forks, like I said, raising 10s of millions of dollars. And we're growing very rapidly. We're at 20 people. Now we're aiming to be at 100 people by the end of the year. And being open source, it has its own challenges. It's like people, we do all this research, we do all this benchmarking work to make sure our diff editing algorithm is robust, the way we're working with these models to optimize for the lowest possible diff edit failures. And then we open source that and then we post it on Twitter. And someone's like, Oh, thanks so much for open sourcing that I'm going to go and like raise a bunch of money with like our own product with it. But the way that I see it is like this is, you know, let them copy. We're the leaders in the space. We're kind of showing the way for the entire industry. And being an engineer and building all this stuff is super exciting. So working with all these people is just amazing.

Alessio [01:15:26]: Okay, awesome. Thank you guys for coming on.

Saoud [01:15:28]: Yeah, thank you so much. So much fun.

We are back organizing AI Engineer Summit — this time focused on Coding Agents! Join us in NYC on Nov 20-22!

At the dawn of the decade of agents, AI Engineers and Productivity Agents are combining to create highly efficient teams from the smallest startups to internal skunkworks/refounding moments at decacorns and publicly listed companies.

I previously defined “Tiny Teams” aspirationally as “teams with more m in ARR than employees”, because efficiency is the ultimate governing force for intellectual (and capital) honesty, not quantity of tokens or money or lines of code spent vibe coding. It is also a backdoor into a speed discussion, because smaller teams generally move faster, and faster teams generally win. Inter-Human trust & I/O is the bottleneck.

The Tiny Teams concept has resonated so strongly that it’s pretty clear it is the next major transition of the org chart as we go from level 2 to 3 AGI. If the AI Engineer was the single player game, Tiny Teams are the co-op multiplayer game1, capable of far more adaptability, resilience and “damage per second”. Not all players are human.

The study of org design is as old as human civilization, but this is the first time knowledge work can be augmented, automated, and scaled on demand, and organizations that don’t reflect this reality have their head in the sand.

For AIEWF I curated some of the best examples of Tiny Teams I could find and simply asked them to talk about how they run themselves. We are releasing the full playlist today (which you can find in YouTube and NotebookLM format):

Seriously, bookmark the Tiny Teams NotebookLM! We’ll keep adding to this over time.

Universal advice from 7 teams w/ 100 people & 200m ARR. manually summarized.

• Hiring

  • Hire right or not at all: have to be excited about the candidate or it’s a no

  • Work Trials: paid projects for 4days-3months to be sure it’s a good fit

  • Product-Led Hiring: top customers who quit their jobs to join you

  • Top of market salaries: 95th+ percentile salaries

  • Small (<15) crew of senior generalists: much fewer juniors

• Culture & Value: keep a living culture deck and live it

  • Low ego, high trust: trust = speed, ownership

  • Independence, Grit & Resilience: ignore standard VC advice, persevere

  • Radical transparency and accountability: wall of work, show & tells

  • User focus: Work closely with users, celebrate them, delight in feedback

  • Camaraderie, speed: Have fun, do retreats, avoid burnout

• Operations

  • Almost no meetings: “deep focus” - building instead of talking about building

  • AI Chief of Staff: automate research, marketing etc w/ Gumloop or Lindy

  • AI Support: very well fleshed out at this point. e.g. see Parahelp and Railway

  • Let Fires Burn: in order to prioritize on the 10% critically important

  • Compound learning: Oleve phrases it “Don’t Learn It Twice” - build reusable templates and playbooks

  • In Person: either have an office, or VERY frequent AirBnB hack weeks

• Tech and Product

  • Simple, Boring Tech Stack: shell scripts over k8s, keep code modular.

  • Simple Product: start from UI wrapper over one API call to a LLM.

  • Feature Flags/Experimentation: one of Oleve’s core principles.

  • Benchmarks: create top tier internal evals for LLMs/harnesses. Market them.

(this section is being updated live - if you are reading this on email, this will be updated on the live blog on Latent.Space. We’re shipping this out so you can just watch the talks without our commentary, but of course we actually want to absorb the lessons using human attention. Come back in a few days.)

Gamma is one of the top 25 consumer AI products in the world, serving 50 million users with a remarkably lean team of only 30 people. CEO Grant Lee attributes it to three pillars: generalists, player-coaches, and brand/culture of a “small tribe”.

Gumloop was one of the inspirations for Tiny Teams with the stated goal to be a 10-person unicorn. CEO Max explains the extreme lengths he goes to to be super picky, from “product led hiring” to 4 day work trials all over the world.

Full disclosure, I am an investor since the Stackblitz days, and we’ve done a podcast with Eric and Itamar, but the story of how Bolt kicked off the “AI Builder” category hitting $20m ARR in 60 days with 15 people is very compelling. CEO Eric says "Focusing on 10% of tasks often yields the majority of desired results, forcing clearer thinking."

We previously did a lightning pod with Sid so we were somewhat familiar with the Oleve story, and, fun fact, since then, this tiny team has launched a THIRD multi million dollar product that will be announced soon. (Consumer product studios operate very stealthily out of necessity). Palantir’s philosophy informs this tiny team.

Together.ai raised eyebrows as it is not “tiny”, but Hassan is classically a one man tiny team, and no stranger to the AIE stage. He now boasts 3m users with a small team.

Vik is author of Marker and Surya, but there are many open source vision/pdf/OCR custom models and when I invested it wasn’t obvious how something like this could turn into a profitable company — 7 figure ARR with 7 people, serving tier 1 AI labs. Stretching out the “golden period” of startups where high trust and careful, deliberate hiring of senior generalists dominate is key - per Jeremy Howard.

We think Evals are important, yes, but not enough teams create their own benchmarks to eval models and harnesses to improve their product… and market themselves. Every is “high-taste tester central” and just raised $2m from Reid Hoffman et al. Every’s head of AI Practice Alex Duffy talks about how they see benchmarks and launches AI Diplomacy.

There are more Tiny Teams than just the ones we managed to feature of course. Cognition was until recently a team of 80 making well north of $100m, and we’ve been blessed to have Scott Wu come by to tell the story of Devin 1.0 and Devin 2.0. Clearly “Devin 3.0” will involve a VSCode Fork, as everyone, even Amazon, has to do in 2025.

Stay tuned to Latent Space for more Tiny Teams….

So what would be the “Battle Royale” or “MMO” equivalents? Perhaps this is the next phase Noam is working on.

The basic insight of reflexivity is that, contra the Platonic Representation Hypothesis where incorrect beliefs converge on correct reality, there exist some, maybe the majority, of situations where unreal beliefs alter reality to retroactively make themselves real. Not figuratively in the “everything is a social construct” sense, but literally, in the fact that beliefs create national borders, churches, economies, art, wars and so on, because human beliefs drive human actions in the physical, real world. Real Steel becomes Underground Robot Fight Club just because we all think it’s rad.

The medium is not just the message, but the meme drives the manifestation.

In AI social circles, the preferred term for this has come to be the Landian word hyperstition: “ideas that, by their very existence as ideas, bring about their own reality”. And of course one of the most important lens to view generative AI and AI agents as a whole is that it massively lowers the barriers to go from thought to reality, whether it is paper reviews, news summaries, or entire working apps.

In 2025, one of the most important generative AI trends is “finally good AI Video”, like Veo 3 (introduction here).

Today’s guests, Justine and Olivia Moore, have become experts and documentarians of the generative media trends in popular culture (not just video), and we’re excited to release our conversation with them, which you can watch here!

The topic of Brainrot is an uncomfortable one to confront. The self styled “high taste testers” of the world would never deign to consume “AI slop”… but there are many many billions of humans in the lower swells of the bell curve that do.

When you really think about it, the “plotlines” and “characters” are no more “slop” than your average Teletubbies or every generation’s blue dog. But it was still a surprise to learn that these video gen characters have become real toys:

This is enormously powerful in the small sense - IP that you can programmatically create from scratch, A/B test, and double down on whatever the RNGhost in the machine blesses into a popular brand is worth billions in the consumer market.

Of course, unfettered capitalism doesn’t everywhere and always lead to desirable outcomes. There’s many times that you or your kids should NOT be given what you want, at the every thought and whim. While we acknowledge that issue, we want to shed some light on the brighter side that we feel often gets overlooked in the standard essays’s penchant for hating on AI and capitalism.

Justine made her own version exploration of this with Melt, her own froyo brand. None of this exists in reality:

But you could obviously build a large social following just sharing images of this, and a/b testing the best/most viral ones over 50 different accounts, none of which exist, but crucially, follow through and actually start the brand with an inbuilt fandom from day 1.

This kind of “selling things that don’t exist yet” technique has a long tradition since the zero-incremental-margin internet of the 4-Hour Work Week, and it has led to various forms of Dead Internet Theory (see also: Dead Planet Theory). But there is a bright side to that admittedly very serious problem, that pessimists often overlook - this is actually an enormously efficient process to discover what people want to buy, and so cut down a lot of the wasted guesswork that is both costly and terrible for the environment:

You don’t even need humans to drive the idea these days, because you could just have ChatGPT tell you what it thinks you should have, and then you go build it because it makes sense.

• Italian Brainrot made into Toys

• Animals olympic diving

• AI ASMR

• AI IP - Disney, Harry potter

• Stormtrooper Vlogs

• AI Ads

  • Full ad made with veo 3

  • Kalshi NBA Finals ads

  • Bigfoot

• Celebrity education videos

  • by Onlock https://www.youtube.com/@onlocklearning

• AI creator stack

  • B-roll

  • Overlap Shorts Clipper

• Video gen market map

• Prompt Theory

  • https://x.com/HashemGhaili/status/1925616536791760987

  • Vloggers https://x.com/fofrAI/status/1932889372229046368

Misc

• Karpathy on veo 3 https://x.com/karpathy/status/1929634696474120576

• Veo 3 opera https://x.com/jerrod_lew/status/1924934440486371589

  • https://x.com/GeminiApp/status/1925030391083389406

• Veo 3 chinese mumble rap https://x.com/1owroller/status/1925004130730606810

• Veo 3 rapping https://x.com/YugeTen/status/1924947152242974877

• Veo 3 singer https://x.com/nearcyan/status/1924966995910631899

• Ai furniture https://x.com/venturetwins/status/1686443924385308672

• Kangaroo model https://x.com/venturetwins/status/1934236631336403344?s=46

Alessio [00:00:04]: 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 Small AI.

swyx [00:00:12]: Hello, hello. We have a very special double guest episode with Justine and Olivia Moore. Welcome.

Olivia [00:00:17]: Hi, thanks for having us. We're excited to be here.

swyx [00:00:20]: I think you're the first twins on the pod.

Olivia [00:00:23]: We're honored. We love that.

swyx [00:00:24]: Olivia, are you wearing glasses so it's easier to differentiate? Is that like a thing?

Olivia [00:00:28]: No, we have opposite, even though we're identical twins, we have opposite vision problems. So I actually need glasses and Justine doesn't, but it would be nice. Yeah, sometimes we think we should do like name tags on our foreheads or something, but I think the glasses work just as well.

swyx [00:00:42]: So both of you are partners at Andreessen Horowitz, but also I think we're actually talking to you in a capacity of you're just very involved in generative media. We don't cover enough and I can see a change. Latent Space itself was started because of stable defense. And then there was like, yeah, improvements in image generators for a while. You can see like ReCraft is better than blah and then Black Forest Labs and so on and blah. But like, they're all just image generators. I think video gen and then also there was music gen for a while. Video gen, I think, is like the current thing. And we really wanted to do an episode on that, I guess. And then also, I think the last piece that I will preview is that we really wanted to start using it for Latent Space itself. So we could use some help. We could use some. We could use some overview of like what people are doing. We can sort of take it from there. I have some like some of your tweets pulled up, but I don't know how you want to start.

Justine [00:01:37]: It's really funny. Actually, I got into generative media, too, with Stable Diffusion and I think it was like September 2022-ish and it's grown so quickly since then. And Olivia and I talk about this all the time because it used to be that our friends in creative fields would look at like the AI image and video generation and be like, I'm not worried about that or I can't use it in my job. Like, this is kind of just a silly side thing. And then I think starting earlier this year, we started getting a few of them being like, maybe I should maybe I should learn a little bit more about how these work and how to use them. And now we'll literally have people coming over to our house on the weekend so we can like give tutorials and walkthroughs of like, here's here's the tools. Here's how you use them. That sort of thing.

Olivia [00:02:24]: I would say we've seen the same thing happen on. I mean, if you've been on TikTok or Reels. Or YouTube Shorts recently in the past week, probably 90 percent of your feed is AI generated video. Like even two months ago, it was like that little orange cat animation that was super popular. And then it was the Italian brain rot characters. But it was just a few people making AI video. And now there's like, I would guess, hundreds of thousands of people making and publishing AI video, which is just awesome.

Alessio [00:02:51]: Sorry, I just want to clarify. Are the Italian brain rot made by Italians? Or is the descent like? Are the names it's I haven't quite figured that out. I haven't been able to trace it down to the origins of the Italian brain rot.

Justine [00:03:04]: It's complicated because it's a decentralized meme that people are taking and remixing. I actually looked into this question as well. And I think the answer is no, it did not come from Italians. But someone early on thought the name sounded vaguely Italian. And so they called it Italian brain rot.

Alessio [00:03:23]: We're innocent. That's all I wanted to know. I guess we're not.

swyx [00:03:26]: It's not our fault. So I didn't even know about the Italian brain rot, but I wanted to kind of show and tell a little bit as well so that our viewers can watch along. So this is it, apparently.

Olivia [00:03:37]: Exactly. So this is essentially it was kind of a universe of characters started decentralized, like one person made a few characters and then a couple other people on TikTok added their own characters to the universe. And the best ones became kind of like canon. And they started as images is probably important to clarify. And then they people started animating them into video. Yes. And then some people, as you can see in this kind of music video, did like compilations of all the characters together or videos where the characters were interacting with each other and whole storylines were forming. And so it became this whole giant entertainment thing. I saw last night, actually, there the IP has evolved to the point where people are now selling like toy sets and T-shirts and plushies. And the crazy thing about this first video to me is it's like a real kid who is treating these characters like knows them by heart. And it's. Treating them like they're Nickelodeon characters.

swyx [00:04:29]: Why not?

Olivia [00:04:30]: It's absolutely wild. But I get it because he's he's able to watch like dozens, if not, you know, hundreds of videos of these characters every day on TikTok, whereas Nickelodeon might put out like one episode of your show every week. So you get attached fast, I think.

swyx [00:04:44]: So this is I mean, this is actually for kids. It's not for adults. I don't know.

Justine [00:04:48]: Adults love it, though. They're making like musicals. They're making movies. They're making more, I would say, adult oriented storylines of like the characters cheating. They're cheating on each other. So I would say it's for both.

swyx [00:05:00]: It can be too fun to scroll brain rot characters. I was wondering, like, how do you keep track? What is your process? How do you organize the universe? Apart from just mindlessly scrolling? You know, I think that's the hard part about covering something like this.

Justine [00:05:15]: Keeping track of trends or models or both.

swyx [00:05:18]: Trends first. I think models, models will come and go like the current thing is VO3, but like there will be a next thing, you know?

Justine [00:05:25]: I think first of all, you have to know. You have to know where the trends are originating at that point in time. Initially with AI video, it was actually Reddit. Like the early days of AI video, you had a ton of people making and posting stuff in those, in those forums.

swyx [00:05:40]: Which ones?

Justine [00:05:42]: AI video, ChatGPT, Singularity, like basically all of the AI oriented. The AI video one was like the one for a while. And then people like me would take the best content from there and bring it to Twitter. And then like the very best would sort of make its way eventually to TikTok or Instagram, but that happened pretty rarely now, especially after VO3 and like Minimax 2 and like with the animals diving and that sort of thing. We've actually seen like a flip where most of the viral content is now originating on the true consumer, like everyday consumer platforms, which I would say are like TikTok and Instagram. And so because. Because people more like everyday people who are not technical can make quality, interesting content and they can remix content than other people have created. These characters like the Italian brainwok characters are like a million times bigger on Instagram and TikTok than they are on X. And so nowadays I'd say we spend more time on those other platforms and then sort of watching what starts getting momentum in the community. Like what are other people remixing and iterating on? What are people making accounts for like the vlogs? And then eventually, like what what starts making its way to X and Reddit?

Alessio [00:07:01]: Do you have kind of like a contaminated account that you use for like max brain rot algorithm and then once you log off, it's like you close that, you close that in a safe and look at it?

Justine [00:07:12]: No, I like to live in the brain rot all the time, so I purposely do not have a separate account.

Olivia [00:07:17]: I actually do. I even made my own account. I can share my screen. Yeah. Olivia's become like a TikTok creator for these videos. So once VO3 came out. Yeah. And now I've like maxed out all of my my credit. So I need to use Justine's special account. But I was like, OK, I'm curious, like how low hanging is the fruit here? Like how easy is it to actually kind of make money on this?

swyx [00:07:39]: Oh, you made your own. Yeah.

Olivia [00:07:40]: I made my own. And then I was experimenting with all the prompts and trying the videos myself. OK, let's see. So I started you can see I'm exposing myself here, but I started when the fruit slicing ASMR videos emerged and I was like, OK, let me get creative and try my own formats like opening dragon eggs or cracking eggs or something. It didn't really work. So I did the fruit trend myself and you can see that did the best. I think the trend that always works like in any format is lava. Like people love like eating lava, squishing lava, like peeling the crust out of lava. Like you can see in the comments like people are just completely obsessed with it. And then I evolved into the interesting thing about VO3 is there's no IP restrictions, at least on cartoon games. There are no rules. Yeah, on real people there are on cartoon characters there are not. So you can make like Stitch from Lilo and Stitch doing his own ASMR videos, which was super fun. And then I just kind of honestly was like following the trends of of like what was popular, like gold bar squishing became a thing for a while. I would say the thing I'm most ashamed of that I eventually ended up falling for is the Tide Pod consumption. This is a very popular genre of videos. And as you can see, people are admitting that this is their live stream to be able to eat a Tide Pod, and the AI characters can do it completely safely. So these were super fun to make, and I would cross-publish them on YouTube and Instagram, and it was fascinating to see what worked differently on what platforms.

Alessio [00:09:14]: Were all of these text-to-video directly? Do you ever do frame-to-video to maybe steer it a little more?

Olivia [00:09:22]: Yeah, almost all of them were VO3, just directly text-to-video. I did a couple on the Minimax model, especially the new trend of animals diving off the diving board at the Olympics, which went mega viral. I did that with the Star Wars characters, and I just wanted to get the sound effects super dialed. So I actually did that with the Minimax model and then used the new Eleven Labs sound effects models to hand-generate the sound effects, which took a very long time. I didn't have to generate them and then line them up at the right spot in the video, but it was very satisfying when I was done.

Justine [00:09:57]: Because the thing to know about VO3 that I think a lot of people don't know until you use it is you actually can't do image-to-video with audio. Google hasn't released that yet, I would assume for trust and safety reasons. In the interface, you can start with a frame, but once you do that, if you're doing it on the VO3 text-to-video model, it will switch you back to VO2 and will tell you, hey, we're switching you to a model that's compatible. to starting with an image, which means that it makes it super hard for like character consistency, right? If you're not able to start with an image of the same character over and over again, which is part of why you're seeing so many of these viral trends using things like a Stormtrooper or like Jesus, where there's like a known identity that the model already understands and can recreate without a starting frame.

Olivia [00:10:46]: A lot of the Yeti and Bigfoot videos have gone super viral, like they have their own channels where they're making videos. They're making daily vlogs and they're getting like millions of followers and hundreds of thousands of likes. And they're genuinely really entertaining and you start to feel an affinity with the characters, which is super fun.

swyx [00:11:02]: This is the one that somebody posted about. I've actually, I'm subscribed, I'm watching it.

Justine [00:11:09]: They're so good. And they're like real storylines, especially I think there's a lot of people who are like not happy with the way the official IP has been going. And so they prefer to watch. They're like, I can control the story myself now.

swyx [00:11:22]: And also, I mean, obviously it's nice that they, you don't see their mouths. So it's, they can speak without it. Yeah. So how come you haven't done a vlog? You're just focused on ASMR?

Olivia [00:11:33]: Exactly. Those are easier to generate for sure. I've been shocked by like how smart VO3 is. And Justine, you probably know more about this, but like from a pretty under-optimized prompt for something like an ASMR video, because I don't know, I have to imagine it's at least somewhat trained on YouTube data. Yeah. Something that already exists on YouTube, like any genre of video that already exists, it does a really good job of taking like a one-line prompt and like turning into something that you would see like a professional creator publish. But the vlogs, the narrative character-driven vlogs are a little bit more complicated outside of my skill set right now.

Justine [00:12:09]: I would say that we, like, I generate dozens of VO3 videos every day and just don't post most of them on like TikTok or Instagram. So I've definitely experimented with the vlog format and it's like pretty easy to do.

Alessio [00:12:22]: How much of a part do you think the character familiarity plays into it? You know, maybe the Stormtrooper content is actually not that good, but there's so many Star Wars fans, including, you know, I mean, you can see I have a Vader helmet right there. Do you think there's kind of like an initial slope of like, hey, let's remix all known IPs in like this new format and you get a lot of attention, then you kind of see that peter off? Or we're not consumer experts, so I'm curious to hear your thoughts.

Justine [00:12:48]: It's such a good question. And a lot of our portfolio, companies ask us this because obviously they're all trying to figure out how do they make their content stand out or how do they help people make more interesting and viral stuff using their platforms. So we've thought about this and studied this and A-B tested different video formats. I think there are like a couple of things that benefit new formats like AI video in general. One is having some element of familiarity, but then having an interesting twist on it. I think it like hits multiple of the like, good sectors of people's brains when you're like, oh, it's a Stormtrooper. I know this. I'm going to like keep watching because I'm like already bought into the storyline of Star Wars and I want to see what happens next. But then like you get this other weird happiness in your brain when the Stormtrooper does something in the AI vlog they would like never do in the real cinematic universe. I mean, like 2% of like the Star Wars hardcore fans will like leave an angry comment like this isn't realistic, but like a ton of the time, it's like, oh, it's a good thing. It's a good thing. It's a good thing. It's a good thing. It's a good thing. It's a good thing. It's a good thing. It's a good thing. It's a good thing. It's a good thing. It's a good thing. It's a good thing for them are like, oh, this is super cool. Like I always wondered about this and like now it can happen. One of the benefits of starting with established IP is like you're already tapping into a known association in people's brains that makes them stop scrolling and be interested. The second thing we've seen work though, honestly, is like just super weird stuff. Like this is why the Italian brain rot characters, like they're not based on any existing IP, right? They're just completely new, but they're just strange and interesting.

Olivia [00:14:21]: Interesting enough that you're continuing to watch just to see like, what the heck is this? Like, am I hallucinating? Are they speaking a different language or is this English? And I just don't understand it. And so I think over time, we'll see more AI like IP like that. One of my favorite examples, and I'll screen share again, is Kim the gorilla, which is another TikTok character. And this is a new character. I actually don't even know who makes it, but it's a gorilla in a zoo named Kim who has a... And the storyline over time is just her constant conflict with a zookeeper named Becky, who she's fighting with and trying to escape from. And you can see like all of her videos get hundreds of thousands of likes. She already has like 300,000 followers in like a really short period of time. Yeah, that's Becky that she's kind of fighting with in most of these storylines. She already has her own website, her own free Kim merch, where she tries to escape from the zoo. And so it's this kind of thing where it's like, who knows if this person would have been able to make this content before? Like, I'm guessing they're not a professional filmmaker, but like...

Justine [00:15:27]: Or had access to a gorilla. Like who? Yeah.

Olivia [00:15:30]: And a great gorilla actress as well. Yeah. Not just a gorilla, but a gorilla who can act on camera. It's not also like anyone with VO3 is going to come up with a really fun, great narrative idea like this and keep it going over time. So in my mind, it's still a mix of like, we need great creative. But now they just have like a different tool set.

swyx [00:15:49]: Yeah, they're just going to be a lot more creative. So yeah, I would just appreciate we're more face blind to gorillas so that that solves the consistency problem. And then you add the pink bow that makes it more recognizable, even if it's like misplaced. It's so smart. It's just like, I feel just dumb when I look at these people and how they solve AI problems, you know.

Justine [00:16:07]: I think the really interesting thing too is people remix each other's work. Like someone does a Yeti and then other people realize like, oh, I can get around the eight second limit. I think the really interesting thing too is people remix each other's work. Like someone does a Yeti and then other people realize like, oh, I can get around the eight second limit. are just literally remixing other people's work like this. And then the universe evolves from that.

swyx [00:16:52]: For people who are kind of newish to this whole field, it is actually very valuable to have your own IP that you entirely control. So effectively, I actually tried to get an interview with Lil Mikaela.

Justine [00:17:05]: Ah, yes.

swyx [00:17:06]: This can be cynically taken or whatever. But like the cynical version is you have an influencer that will always obey you. Right? Yeah. So they'll never speak out. They'll never speak out about like political stuff. It will just just do what you ask it to do and behave. And, and like, you know, that's rough for the AI model, but hopefully they're not sentient yet. But in the meantime, you have like a property you completely control. And like you can pose them and put them in all sorts of situations.

Justine [00:17:31]: That part is so interesting. I have like a very hot and controversial take on this, which some people hate, which is like, before, honestly, to be like an Instagram or YouTube influencer, most of them are hot people. And now it's like anyone can be a popular influencer. And you don't have to be a hot person. Like how many friends do you have that have like are like really funny and have like great personalities and are super creative, but they like don't fit the exact beauty standard of like what an Instagram influencer is. And now it's like anyone can create a character who like an AI character who meets the beauty standard, and then it can be their brain behind the content.

Olivia [00:18:07]: We already saw this with whole startups or stacks of products. And Justine looked at a bunch of these where it was like basically make money by building your own Instagram influencer. We already saw this with whole startups or stacks of products. And Justine looked at a bunch of these where it was like basically make money by building your own Instagram influencer. off of AI images. And a lot of people were making, yeah, tens of thousands of dollars through that. They would even have sometimes like a subscription that you could sign up for to get extra content for them that would make like a ton more money than they could make on Instagram ads or something like that. But I feel like with AI video, it's just going to explode 10x.

Alessio [00:18:36]: How do you see the monetization kind of landscape? So there's the I use AI to make a fake person that then sell some product. How do you see the monetization kind of landscape? So there's the I use AI to make a fake person that then sell some product. How do you see the monetization kind of landscape? So there's the I use AI to make a fake person that then sell some product. How do you see the monetization kind of landscape? So there's the I use AI to make a fake person that then sell some product. How do you see the monetization kind of landscape? So there's the I use AI to make a fake person that then sell some product.

Justine [00:19:06]: How do you see the monetization kind of landscape? So there's the I use AI to make a fake person that then sell some product. How do you see the monetization kind of landscape? So there's the I use AI to make a fake person that then sell some product. How do you see the monetization kind of landscape? So there's the I use AI to make a fake person that then sell some product. to your videos. Another way is, yeah, we've seen people use them for like ads or driving traffic to an actual business. We've also seen people who are like really skilled prompters, people like a Nick St. Pierre, who sell online courses or do a lot of consulting, like a lot of actually the best AI creators do a lot of consulting work behind the scenes, whether it's with companies or with brands. And the viral content they create is like generating leads for these people to read. And then they either like sell a course or they sell their consulting services. What I'm waiting for is like, what is the first AI native IP or AI videos that get packaged and bought by like a Netflix or like a Hulu? And then like, from there, how do you even determine like who gets paid in that scenario when like this gets bought because it's the brainchild of like a thousand different characters. But like, I'm sure given the popularity, of Italian brain rot on, on Instagram and TikTok, like you can totally imagine someone like Netflix wanting to buy and reuse or license those characters for their own content.

Olivia [00:20:26]: My learning of making a bunch of these videos and trying to post them on social feeds is it's actually like very expensive still to produce just because VO3 is so expensive. And especially if you're making more complex content than like someone slicing a glass fruit. And even that in itself, like I would have to do, you know, eight generations before it was coming out. But especially if you're cutting the fruit in the right way that I could post it and people would be happy. But especially if you're doing something more complex, like and you're using something like VO3, it's, it's really expensive to run, to run these. Because you get a certain amount of generations on kind of the core plan, but then you have to pay for extra credits. Exactly. This is the fruit example. Like lots of times when I tried to generate it, it would like, you know, cut it horizontally instead of vertically or the layers would look weird once you cut them through. And so you would end up having to do a bunch of generations. To get one that works. But yeah, my learning is that the generation is still expensive enough that it's like, you have to kind of be smart about how you're going to make money from it. Otherwise, I think a lot of people are going to find that the ROI isn't really worth it.

Alessio [00:21:31]: And roughly the payouts on the social medias are like 20 bucks per million views, something in that range. That sounds high.

Olivia [00:21:39]: You have to go. Well, it depends on the platform, but it's like you have to go viral enough or get enough views to even qualify for like a creator program. Or you can then make money like with my videos I posted on TikTok. I'm not part of the creator program, so I'm not making money from those. So it's first like you have to have one or two videos that ideally go hyper viral and qualify you. And then after that, it's like, yeah, you have to get enough views on each incremental video that you're actually making money from them. So it's not like cash sitting on the ground, I would say, on these platforms quite yet.

swyx [00:22:13]: I was going to correct myself. 20 per million is actually low. I think, oh, maybe that's TikTok level. I was thinking 20 per mil, which is a thousand, but yeah.

Justine [00:22:22]: I think it also depends on like the engagement and stuff like that, too. But like the other really interesting thing is a lot of people are. So some people are motivated by I make these viral videos and then I use it to sell something, whether it's like my time or a course or whatever. A lot of people just finally have the opportunity to grow a big account online and like the dopamine hit of getting like tens of thousands of likes and like thousands. Followers on an account doing like I grow of logs when you were never able to like grow a big social media account before. I think that is motivating a bunch of people, too, which is fascinating. Like these people are all experiencing what it's like to be early adopters who are like pioneering a new form of content and people are going crazy for it. That feels sort of really rewarding and fun.

swyx [00:23:11]: Yeah, I agree. I had a cheap joke that I was going to throw in there, which is like, you know, people who are. Are not hot enough for Instagram or TikTok, you know, to go to Twitter.

swyx [00:23:24]: think this links very closely with the creator economy stuff, creator economy. You know, I think people were very excited maybe like five years ago and then it kind of died ish. I don't know if you would agree or you would vehemently object, but like maybe this is like the return of the creator economy. There's another way to slice the monetization stuff, you know, just to put like VC hat on a little bit, which is like there's the creators. And, you know, I think. We talked about them, but then there's like sort of the creator enabler platforms. Let's call it like a CREA or a comfy UI or whoever. And then there's the direct model layer itself. And I think like right now, especially with VO, just like directly offering a platform, like it's going to be the model layer that's like gets all the money. And that's just an open model where then it then it goes to the model enabler, the model workflow platforms. Is that accurate? Would you change that mental model of how money flows?

Justine [00:24:16]: I would say. Somewhat accurate. I agree with kind of the distinction between the we call it sort of like the interface layer or the application layer. Companies that aren't training their own foundation models, but are making it really easy to use other people's models. And then the core model layer itself, like a VO3 or like a mini max or like a cling or all those or all those folks. Some of the model providers are better than others at building the consumer interfaces. So like cling, for example, which is one of the really good. Chinese image to video models has like a pretty good interface to be able to upload an image, make it a video, add sound effects in their platform, that sort of thing. I think like VO3 is in my mind, actually like a counterexample where it's super hard to figure out where to access VO3 within all of the Google products. Like you have to sign up for the separate product called Flow, which requires like a subscription to one of two like very expensive Google plans. And then from that subscription, like you have to make. sure you're logged into the correct Google account when you try to access the subscription because we all have like three Gmail accounts. And so honestly, what we see is like a ton of creators are just going to the model enablement layer, whether it's a consumer facing interface like CREA or more of a developer facing interface, like a fall or replicate where you can generate like videos on a one off basis and like a pay as you go model because it's easier than trying to navigate like the behemoth that is. the Google product infrastructure, and then you don't have to commit to the like $125 a month Google plan to use the model.

Olivia [00:25:55]: Another example on on Flow and VO, it's like VO2 is actually the default and you have to like navigate a bunch of like little hidden buttons to change it to VO3. So there's like YouTube videos with like millions of hits of just like, how do I find VO3 within like the Google subscription? Yes, you can't. It doesn't work on mobile, which is crazy. Yes. Given so many of these videos are being posted. On mobile apps, like, yeah, and like maybe Google will release a video generation mobile app, but I would guess that it's going to take a really long time. And the website isn't even usable on mobile. So they might fix some of these things. But I think even in the VO3 example, it is API available already. And so like a lot of the model enablement companies, I think, are making a bunch of money from it. And Google, I'm sure, is making a ton of money from it, too.

swyx [00:26:42]: Yeah, I was looking for one of your market maps. And it looks like these are just model companies. I don't have the enablement ones.

Justine [00:26:48]: Oh, the multimodal model apps are the enablement ones. Oh, yeah, right there.

swyx [00:26:53]: Hydra had his own models.

Justine [00:26:55]: They do. Yeah. So they're in the talking avatars category for the model layer. So their model is like a talking avatar model. And then they also host a bunch of the image and video models so that you can generate other stuff on their platform, too.

swyx [00:27:08]: Flora raised a big round recently. Visual Electrics, I have heard. These two I've heard less of. Yeah.

Justine [00:27:13]: And then even, I mean, if you guys even follow the stuff Adobe's doing, like Forever. Adobe was like, we're only having our own models. And they're the clean models that are only trained on licensed data. And then I think they realized that, like, no one was using those models, either the image ones or the video ones. And so now Adobe Firefly hosts, like, all of the other models.

swyx [00:27:34]: Which is crazy.

Justine [00:27:36]: Yeah.

swyx [00:27:37]: We did a state of AI engineering survey. Oh, cool. And we asked people what models they were using. And Adobe did surprisingly well. Yeah. Because, like, everything, everyone, everyone who's paying attention thinks about them as, like, oh, they're clean, therefore boring. Yeah. But actually, they showed up, like, here.

Justine [00:27:57]: Interesting. Weird.

swyx [00:27:58]: Like, they're beating Ideogram and Recraft. Maybe because it's Adobe. I don't know.

Justine [00:28:02]: I think it depends, too. Because, like, okay, if I think about it, there are definitely things I use Adobe for. Like, for example, I think their generative fill within Photoshop or even within Firefly or Express is, like, really, really good for in painting and images. And so I would say I still use, like, an Adobe model, but I use it for in-painting versus, like, pure generation.

swyx [00:28:24]: I think there's another thing about, like, the depth of workflows. How do you feel about, like, something like a comfy UI where it's, like, literally the it's always sunny in Philadelphia, like, crazy link maps? Like, you need that to have complex workflows, but then also maybe, you know, the next model will destroy it.

Justine [00:28:43]: I love that meme. And I have so much respect for the comfy community. Because, like, they have truly been in the trenches. Like, having an open source project like that where you have all of these interconnected nodes that are dependent on each other to run all of these mini apps that, like, thousands, probably millions of people around the world are using and not paying for but loudly complaining about is, like, that is, like, doing the Lord's work to maintain that. I have never been a deep, comfy UI user because I am at my heart, as you can probably tell by the fact that my feed is open. I have never been a deep, comfy UI user because I am at my heart, as you can probably tell by the fact that my feed is open. I actually try not to get too deep in the technical stuff because I want to have technical stuff in terms of actually using the products and, like, running the really complex local workflows because I want to understand, like, it's this too hard for an everyday person to do. I think comfy UI is really great for people who want a ton of control. And so for people who have more professional use cases, that's awesome. For people who just, like, want to make a meme or, like, a fun video. To share with their friends or with their Instagram audience, you probably don't need comfy UI. I would agree that more of the comfy UI use cases are starting to be eaten away by kind of the core foundation model companies. But especially with things like VO3 not offering image to video, they're still definitely lacking a level of control that you can get from a platform like that. And I would say comfy UI is still awesome for a lot of things like video style transformation. People who want to turn a photo. Realistic video into an anime video or something like that. Like, that is not something you can do on a platform like VO3 today.

swyx [00:30:23]: Yeah, style transformation, consistency, and upscaling or fixing hands. I don't know if that's a thing that people still do.

Justine [00:30:31]: Or, like, character swapping. I don't know if you guys follow AI Warper on Twitter, but he does some really cool stuff with a lot of the open source tools and sort of interfaces like comfy UI. And kind of shows, like, this is, to me at least, a lot of his stuff is, like, this is the forefront of what. What I could do if I was, like, better at navigating these interfaces. But, like, the average person, there's just no way.

swyx [00:30:53]: So I guess, like, part of this discussion we wanted to have also was just, like, how we might put, you know, just, like, use us as a case study. I think you're relatively familiar with us. If we were to start, like, a Latent Space, like, sort of somewhat educational channel or sub-brand that was, like, entirely driven by these things, like, where do we start?

Justine [00:31:13]: Okay. Have you guys seen the Brain Rot Education videos? Yeah. Just, like, the, I had, like, a super, let me try to bring it up. Okay.

swyx [00:31:20]: I am very out of it.

Justine [00:31:21]: Everything is Brain Rot now.

swyx [00:31:23]: Well, I mean, like, this is the most uncool I've ever felt because, like, I clearly don't scroll TikTok and Instagram, but, like.

Justine [00:31:30]: You have to pay a really high price to be this informed about Brain Rot. I think this is an interesting place for you guys to start. Hear me out. I know this looks crazy. So I found these, like, channels on Instagram. I think this one is called Unlock Learning that we're getting. And it's, like, consistently millions of views on these sorts of, like, AI celebrity interviews teaching education. And so basically what they, this is embarrassing. You can see that I like my own tweets, but we're going to keep moving. You can see that they use, like, a deepfake tool. Like, I don't know if they use Yapper or if they use something else to, like, take an image of a celebrity and have them sort of say the words in their voice of the script. And then they overlay it with some sort of diagram at the top that's actually showing what's going on. You could probably just generate a script. Maybe what I would do is you would take links to, like, YouTube videos or transcripts of the podcast. You could put them in Gemini 2.5. I actually did this recently for someone else's videos. You could ask for an entertaining Brain Rot style clip summarizing XYZ topic based on your content. Then, you know, play around with it, edit it a little bit, wait until it's perfect. Then you have to decide, are you guys the Brain Rot characters? Or are you the Swyx? Or are you going to use a celebrity Brain Rot character to tap into the familiarity, which we discussed earlier? Which I think, like, pros and cons. Like, I think maybe for your audience, they would like seeing you guys better. If you want to go viral on, like, Instagram and TikTok and reach new people, like, maybe Sydney Sweeney is a good face for it. I don't know. Just something to think about.

swyx [00:33:09]: We have an AI host. Actually, we've used an Eleven Labs voice called Charlie for a while. Okay.

Justine [00:33:15]: Incredible.

swyx [00:33:16]: And we could give it a try. We could give him a body, you know. Right now, he's just a voice.

Justine [00:33:20]: Okay. So you could animate on Hydra then. You could take the audio clip. You could take the image. You can make him talking. And then the really interesting part to me is, like, what plays at the top, right? Like, where it was showing the diagrams. Historically, I think people still put that stuff together themselves. Like, the one I was just showing of Sydney Sweeney, it's actually an education company who makes those videos. So... Yeah.

swyx [00:33:42]: I just found their website.

Justine [00:33:43]: And so they can reuse content they've already made. Yeah. And it's giving brain rot.

swyx [00:33:50]: It's fine.

Justine [00:33:51]: I know, but, like, people are... And so, yeah, then the question is, like, do you guys want to make the diagrams at the top? Or there's also, if you search, like, AI B-roll generator now, there's a variety of tools that will basically take your script or your audio track and sort of extract the keywords and then either search the internet to pull together B-roll and images for you. Or they will sort of... Or they will sort of generate net new images or videos, which could potentially be an interesting way to pull it together.

Olivia [00:34:25]: I would say the other recommendation that we would have for you guys to go viral with AI video stuff is there's this whole ecosystem. You've probably seen their content, but there are people called clippers that just take existing long-form videos, like podcast interviews or even TV shows, and extract the most interesting and viral clips and then post them on their own platforms as, like, one-second videos. And there's products like Overlap right now, where if you upload, say, a new YouTube video to your channel, you can link your channel to Overlap, and it'll automatically review it, clip the best ones, and then publish those clips for you across, like, Twitter or Instagram or other products.

Justine [00:35:06]: Can you guys see it? And it predicts the virality score, which I find is crazy. So this runs all the time. It's linked to the A16Z YouTube.

swyx [00:35:14]: Oh, you guys are just using it for your channel. Holy crap.

Justine [00:35:17]: I mean, I am. Like, for example, okay, this one. Like, you can go into the video, and then you can see what they picked, and then you can go in and edit. And so you can say, like, hey, I want to remove the caption on this word, or I want to cut this word from the video completely, or, like, I want to extend the clip and make it start longer or shorter. Like, I want to remove curse words. I want to remove filler words. I want to remove stutter. I want to change the subtitles so that they're... Like, look more brain rot. Like, that sort of thing. And then you can generate the social posts and download.

Olivia [00:35:53]: And you can set this up on overlap so that it'll automatically publish the short-form clips as soon as you publish the long-form video, and it'll, like, write the tweets for you or write the TikTok caption for you. Yeah.

swyx [00:36:04]: Which is very cool. This is exactly what I've been looking for. I just didn't know it existed. It's crazy. Yeah.

Olivia [00:36:09]: So you guys can become your own fanboy clippers and make money off of... Yeah. Yeah. The long-form show itself and the short-form. Yeah.

Justine [00:36:18]: So there's all sorts of clipping agents. So it's actually a comfy UI-type interface. Oh. Which is really cool. So this is basically... This is what it looks... The clipping agent looks like. It is watching for any new YouTube video that is uploaded to the A16Z channel. It is automatically finding interesting clips that are between 30 seconds and 140 seconds in length. And the criteria is, like, topics that would be interesting to, like, the tech audience. It is adding subtitles. It is adding subtitles. You can then add more actions. For example, you can say, convert it, take all of the 16 by 9 clips and convert them to 9 by 16. Or add smart zoom so it zooms in on the person's face when they're doing something interesting. This is not a company we're invested in. We just, like, recently discovered it and we were like, this is the dream.

Alessio [00:37:09]: It is the dream. Yeah. We have a... I built a small podcaster thing for us that automates a lot of things and it picks the clips. But it doesn't... It doesn't do any... The hard part is actually how do you go from picking the timestamps to actually making it get a lot of views on YouTube. So we'll try that out.

swyx [00:37:26]: You know, I think there's an art in picking the clips because I think that, you know, maybe they're optimized for brain rot and we're a technical podcast. Like, they wouldn't pick the same clips that we would pick.

Justine [00:37:38]: So this is the interesting thing, too. It's like, if you guys want to be across multiple platforms, maybe you have an agent set up that purposely generates different clips for different audiences. Like, maybe you have it clip, like, educational, informative, like, technical stuff for YouTube and then you experiment with, what if we gave it a prompt to pick, like, brain rot, funny, controversial stuff for, like, young people and then turn it into a TikTok, the TikTok aspect ratio and then post those? Like, what would happen to a TikTok account?

swyx [00:38:11]: Yeah. Yeah. I think it's worth experimenting with a bunch of those. Yeah. My hypothesis is that usually sort of repurposed content doesn't do as well as native content. That's the general rule, which, in other words, like, we recorded this as a long-form podcast. If you clip it out, sure, like, you know, you might get a little more juice out of it, but it's never going to go great because it's never made to the short form. Like, we've actually, you know, so a little behind the scenes, we've actually explored, like, what if we change the way we record podcasts and we only optimize for clips? Okay.

Justine [00:38:42]: But have you, so I used to agree with you, but have you seen the Vitrupo account?

swyx [00:38:46]: Yeah, that guy's pretty prolific, but I don't know what you're referring to.

Justine [00:38:49]: So just his, he has clips that go viral, like, he clips long-form interviews and they go viral all the time. Like, I also used to think that clips would never do well, but I feel like, especially in the X algorithm right now, it's like a clipping era. Everyone, for some reason, video is, like, doing super well in the algorithm. And especially if you're, it's a video of, like, a character that people know, which is, like, Sam Altman or, like, Gary Tan or, like, whoever. You can get in a crazy amount of juice out of these clips.

swyx [00:39:19]: I think part of it is also we, as a brand, like, this is seriously, like, we're considering doing this, right? So we have to think through everything. We, as a brand, have to resist clickbait somewhat, right? Yes. You know, we can't just keep saying, like, Sam Altman says the world's going to end in two years. And, like, no. Yeah. He didn't say that. But, like, you could misconstrue something he said to say that, you know.

Justine [00:39:43]: We have this struggle, which is, and Olivia and I were fighting. We have this struggle, which is, and Olivia and I were fighting. We were fighting about this last night. We fight in a good-natured way about a lot of things. It's not really. It's just, like, we're twins. Like, we, like, you know, have back and forth about things. But we will help each other write tweets sometimes. And she wrote a tweet intro to me that just, like, sounded like one of those spammy, like, AIs blowing up. Like, everything has changed accounts. And I had to be like, Olivia, this is not us.

Olivia [00:40:10]: Like, we need to, like, stay on the course. It's the YouTube thumbnail economy now. Yeah, for content.

swyx [00:40:18]: Right, right. I mean, like, you know, we could create a sub-brand that is, like, affiliated but not us. That, like, we could just kind of throw that on there. And I think, like, look, like, there are some people who are just literally their best serve like that. Yeah. They don't have the cog sec, is what I call it. Or, like, they don't have the pride or taste or whatever, right? Whatever you call yourself. Yes. But, like, if you want your content to spread to the widest known people, you have to sort of adapt it to the way that they like to receive information.

Justine [00:40:49]: I think it's going to be really interesting, too, to see different ages of people. Because, at least from what I've seen, like, already the kids, like, the Gen Alpha, the kids who, like, grew up fully in the internet era, fully in the smartphone era, consume content and create content much differently than, like, Gen Z and millennials. And I hope that doesn't mean that everything has to be brain rot for people to understand it. Like, I really want there to still be space. For, like, these long-form intellectual deep dives, it's like a habitual blog post writer. But I'm, like, a little bit scared of that.

swyx [00:41:24]: No, I think there's always room for, like, long-form, good writing, good discussions. I almost think, like, sometimes it's just ironic and funny. That's why it's viral. Like, you're not even, like, actually learning anything from those, like, educational Sydney Swinney channels. You're just like, oh, it's funny that you can do this now. Like, this is what humanity has come to. Yes. Anything else in terms of, like, what you're doing? Like, creative trends. Like, we've talked a lot about video. Oh, I was going to bring up prompt theory. Maybe this is, like, a nice thing to talk about. I don't know if it's too woo-woo or philosophical for you, but you brought it up. So could you explain what prompt theory is?

Justine [00:42:00]: Okay, so it sort of evolved. So at first it started with people, when people realized they could make these VO3 characters talk in videos, it started with, like, what if these characters either realized they were AI-generated or refused to accept that they were AI? AI-generated and controlled by a prompt.

Olivia [00:42:18]: It's kind of like an existential crisis for AI characters. Yes. Like that video that went viral, the Notebook LM hosts back last September. Yes. Realizing that, like, they could be shut down and they weren't real. And he tried to call his wife and then he realized he doesn't actually have a wife and he's just an AI-generated voice. Oh, no. It's kind of like that, but for VO3 characters. And it's a lot more striking because they look so real.

Justine [00:42:42]: And then the evolution of prompt theory more recently, and I think I tweeted a video about this that I can, I don't know if I can pull it up or send it to you guys, but now people are like, okay, what if we're actually prompted? Like, what if real humans, like, what if we are the AI characters in someone else's universe? Like, would we know it? And, like, are we all controlled by prompts? Like, one of the big trends for VO3 on TikTok right now is AI clapbacks. So it's often, like, the format is, like, a young person and an old person. And, like, the young person is like, oh, like, my hair looks amazing. And the old person is like, oh, my hair looks amazing. And the young person is like, that's not natural hair, whatever. But it started evolving to, like, well, you know, your hair is just prompted. You didn't do anything to get that good hair. And then, like, the young person will be like, well, like, you're on your way to the cemetery. Like, it quickly devolves. It quickly devolves into, like, chaos.

swyx [00:43:30]: Wait, wait, are both people in this situation real?

Justine [00:43:33]: No, they're both generated.

swyx [00:43:34]: Oh, okay.

Justine [00:43:35]: Yes, yes. But it's like, you're seeing all of these, like, brain rot accounts of, like, teenagers with anime profile pictures who live in the Midwest. Who you would, like, never expect to be thinking about, like, the meta layer of AI and prompt theory. Or including the concept of prompt theory in their, like, AI clapback videos. So it's really gotten kind of very, very broad. So I think about that a ton because sites like Reddit have existed like that for a while where you actually, you have no context on the other person. Like, it's an anonymous username. Almost no one is, like, doxxed on Reddit. And so on Reddit, it's like, everyone could be botched. And, like, what do you know? Now that LLMs are, like, getting so good at sounding natural and, like, pretending, like, they have interests and, like, pretending, like, they have lives in which things are going on. I spend so much time thinking, like, would it actually be sad if I was talking with a ton of LLMs on Reddit? Or if there was just a ton of people who are always available to talk about my interests who had interesting things to say, like, is that the good side of the world? Like, I don't know.

swyx [00:44:40]: Made your own Froyo brand, right?

Justine [00:44:42]: Yes.

swyx [00:44:43]: It's just a brainstorm.

Justine [00:44:44]: Chat GPT for prompting, yeah.

swyx [00:44:46]: Prompting, yeah. You can pose it. You can create artists.

Olivia [00:44:49]: I was going to say, it's exactly that. Or Breadclimp. Yes. Breadclimp is another great one. Have you guys followed Breadclimp?

swyx [00:44:55]: No. What is that?

Justine [00:44:57]: So Breadclimp, yeah, was early AI. Then they started creating videos and stuff like that of him. He got super popular. I tweeted one of the early AI videos of Breadclimp and people loved it. All right. Here is Breadclimp. Aw, it's a possum. He's very cute and he has this whole universe of characters that he interacts with. Let me see if I can find...

swyx [00:45:21]: Isn't that Ian McKellen?

Justine [00:45:22]: But the AI version. Yeah. So a lot of people liked this. And then, like, a bunch of people started commenting and said that they wanted Breadclimp sweatshirts that I actually made Breadclimp sweatshirts. And so we, like, took a Breadclimp design. We, like, removed the background. We, like, overlaid it on a sweatshirt that we had, like, a screen printing company do. And then we probably ordered, like, 30 of them. And we distributed them to, like, friends and family and other people in, like, the AI video community. But, like, the Breadclimp sweatshirts could have been, like, a real sweatshirt brand.

swyx [00:45:55]: Oh, my God.

Justine [00:45:56]: There they are. Wait, can you zoom in on them, Olivia? Yeah. So that's us and that's a niche on our consumer team wearing our Breadclimp sweatshirt. Well, the AI, like, furniture, I don't know if you guys have seen, especially on Facebook, actually, AI furniture, like, totally blows up. So, like... Like, it's a couch, but it's, like, shaped like a giant cat and, like, the eyes glow when you, like, sit on it or things like that. Like, these accounts, the AI furniture and the AI home design accounts are huge. And I actually saw... I'll try to see if I can find it later, but I actually saw one example of someone made this, like, gorilla chair, basically,

Olivia [00:46:36]: that then actually got, like, manufactured and you can buy it. There's a lot of differences between platforms of the type of... of content that's going viral and the types of people that are making them. So my biggest piece of advice is actually just to, like, yeah, set up a separate account on YouTube, on Instagram, on TikTok, on X, and kind of take a look at what people are posting there and just follow a bunch of AI accounts and then the feed will give you more. There's almost this, like, content arbitrage thing that happens right now where something will go viral on one platform and then there's, like, a one- or two-day window to be, like, the person to post it on the next platform. But it's kind of fascinating to watch, like, what blows up. Which I think is reflective of, like, who's spending their time on which platforms. It's just amazing to watch. Like, the AI ASMR stuff on TikTok was huge and then kind of slowly made its way elsewhere. I think the animals diving was huge on... on threads and all the Facebook products first because of the maybe age demo of those users and then slowly made their way to, like, X and other places. Justine, what do you think?

Justine [00:47:39]: I think if you want less of the brain rot, less of the... brand new people to this and more, like, how are people professionally using AI video? There's this guy called PJ Ace on Twitter who... He had, like, the viral Kalshi ad that aired during the NBA finals. He's done, like, a bunch of really cool, more commercial work, whether it's for individual musicians or brands. And he shows, like, how would a true professional use AI to make stuff? And he also shows his workflows, which is great.

swyx [00:48:11]: True professional stuff.

Justine [00:48:13]: Yes. Yeah, he's a real... He has, like, decades of experience in the kind of film production. I think he made his own TV show before this, not on AI. Like, he knows what... he knows what he's doing.

Alessio [00:48:23]: To me, the biggest thing in my mind is, are people going to be bottlenecked by how many sweatshirts they can produce, basically, to make money? It feels like it's much easier to make the content and get the audience than actually get good merch. So I'm curious to see if we get the overclip thing that generates the clip. You have something that just generates merch based on latest videos. You have something that just generates merch based on latest videos with, like, quotes and, like, images of it. Yeah, I'm curious to see where that goes.

Justine [00:48:48]: That would be so cool. I love that, actually. Someone should totally do that.

Alessio [00:48:53]: Yeah, request for a startup. Yeah. If anybody's listening, please go build it for us. Yeah, thanks for your time. This was great. And we'll keep following The Brain Rod closely on social medias.

Justine [00:49:06]: We will, too. And thanks for having us. And we're looking forward to seeing what content you guys make.

swyx [00:49:11]: Thank you all. Thanks, guys. Awesome.

Justine [00:49:13]: Thanks, guys.