Episode Description
Summary
This episode discusses the launch of OpenAI's GPT 4.1, 4.1 mini, and 4.1 nano models, focusing on their improvements in instruction following, coding, and long context capabilities up to 1 million tokens. Guests Michelle and Josh from OpenAI explain the models' positioning relative to previous versions like 4.0 and 4.5, new evaluation benchmarks like Graphwalks and MRCR, and the importance of post-training techniques. The conversation also covers prompting strategies, vision capabilities, fine-tuning options, and pricing structures.
Chapters
Topics
People
Key Concepts (23)
References (7)
Transcript (112 segments)
Hey, everyone. Welcome to the Lit in Space podcast. This is Alessio, partner and CTO at Dasibull, and I'm joined by my cohost, Zwix, founder of Small AI.
Hey. And today we have a returning guest as well as a new friend. Welcome, Michelle and Josh.
Hey there. Hi. Both of you work on the I I guess, Michelle, I I think you used to introduce you as manager on the API team.
You it seems like you've changed your your role since we last talked on the on the podcast. Yeah. Now I lead a team on the research side, specifically in post training.
Yeah. And, Josh, you are also on post training? Yep.
I'm a researcher on Michelle's team. Yeah. And I just found an interesting commonality you guys have.
continuing the tradition of extremely cracked engineers. Oh, yeah. We talked about that last time.
That's right.
Okay. So we're we're gathering to talk about g p c 4.1.
You launched it. I mean, we we we got a little preview, and it was a little bit rumored. Right?
It it was prereleased, I guess, with OpenRouter as Quasar Alpha, and then there was also an Optimus version. And, I think you got people are trying to figure out, like, why are we going back from 4.5 to 4.
1? Know, there's a whole bunch of other things. But, like, what are the headline facts, I guess, you guys want to emphasize about 4.
1?
Yeah. I'll just say we released three new models today, GPT 4.1, GPT 4.
1 mini, and GPT 4.1 nano. And the real focus on these were just making the models that were great for developers.
So we improved instruction following, coding, and shipped our first 1,000,000 context models. Josh, anything to add? I I don't know if there's anything else that people should really that are, like, sort of in the fine print.
No. I think the only thing that I would touch on maybe twice is that there's actually a a new model in the lineup, Nano, which is even faster for developers that are making, you know, low latency applications.
And cheaper. What's the any fun story behind the code names? Or, you know, I got the strawberry hat as another fun time in the lore of OpenAI.
Yeah. Yeah. We really wanted to get as much developer feedback as possible on this model to make sure it worked well in the real world.
And so we tested it kind of through OpenRouter, and it was super cool to see people latch on to the names and and get the theories going. But the feedback we got from there was super helpful.
Yeah. Yeah. So not even like the name.
It's more about just like the API shape. Once we saw, like, Chad Kampo, it was like very obviously OpenAI.
Yeah. It's a it's a good note.
Yeah. But, like, I mean, okay. Is is there, like, an emphasis on stars?
Like, what what inference were we supposed to draw from, you know, quote, unquote, supermassive black holes?
I don't think there's anything really to draw from there. I think it was just They're just cool. Just fun.
Just cool. Code names.
concept. The vibes are good. The vibes are good.
You know? Yeah. Yeah.
The other thing about the examples, we we're just mining for lore here. Right? The interesting animal comes up a few times on the livestream and on the blog post.
What's up to Tapirs? Who who likes Tapirs here? Yeah.
Our our team is just a super big fan of Tapirs.
So Okay. They just happen to work their way into a lot of our content.
Okay. Cool. Awesome.
Yeah. Go ahead. Yeah.
Go ahead. I I I think, like, the first thing that, yeah, we just wanna run through is, obviously, the 4.1 to 4.
5. I I think that's the first thing that everybody was maybe confused about. So and I know you're deprecating four point five.
Sounds like four point one is just like a kick ass model, and the four point five size, maybe it's not as good of a fit. That was just a research preview. So, yeah, I I don't know.
Whatever you wanna say to to address that, I think it's something we've seen come up also in the Discord.
Yeah. Totally. Okay.
Naming is really hard, and we've tried to make this as less confusing as we can. But, you know, nothing's perfect. Basically, the way we got here is that g p d 4.
1 is, like, a pretty big improvement over the four o line. We really wanted to signify that. However, it's a model that's like much smaller and cheaper than GPT 4.
5. And as a result, you know, doesn't achieve the same like AIMI or other intelligence evals. So it doesn't beat 4.
5 on all of the evals. And so we didn't think it made sense to increment beyond 4.5.
But we do think for most developers, they can kind of replace a lot of their 4.5 usage with 4.1.
And then the mini is strictly better than four o mini.
Yeah. Yeah.
With the with the nano. Like but like, we don't know if 4.1 is a distillation of 4.
5 or there's there's no relationship there. Like, what can we say about, like, the shared lineage?
Yeah. What I'll say there is we're always using various research techniques to improve our models. And distillation is something we talked about before.
It's it's really meaningful, especially for the small models. And we've kind of pulled out some of the things that made four point five really good. Like, it has a lot of the instruction following greatness and also rolled that into four point one.
Awesome. I think one of the because I I strongly remember on the four o launch that their communication was that we're kinda moving to a new model architecture that is omni model. Right?
That was what that's the o in four o. And then 4.1 is part of this subsequent trend of trying to merge everything, like the reasoning model, the omni model, everything.
And I think that there's there's this doubt about whether 4.1 I I think it's basically trying to be sold as a strict replacement for four o, But I don't know. Is it going to be fully omni model?
Is it is it, like, roughly the same architecture that we that we that we think four o has?
So we we already have different slugs on the real time API and, like Yeah. Responses API. So they're already, you know, somewhat different checkpoints.
I don't we don't have any current plans to release 4.1 in the real time API. But, you know, things things may change.
Yeah. And then there's ImageGen and all that. Right?
maybe about nothing announced. Not not right now. The focus for 4.
1 was kinda these three core capabilities for developers.
Yeah. We our our Discord actually also did a launch watch party for the recent 4.5 podcast that Sam Altman did, where I think for the first time, it was basically kinda confirmed that like some telling that people already knew like Andre Karpathy was already talking about this that 4.
5 was like 10 X the size of four and I think there's a question about like, do we do the linear linear interpolation of 4.1 is like, you know, zero point is, like, I don't know, two x size or something? Mhmm.
That's not really how we think about naming the models. There's a whole bunch of different parts that go into the the recipe. And so, you know, it doesn't really reflect on just the pretraining recipe or version numbering.
But I think the 4.1 is just because of the large jump that we have in, like, coding capabilities, long context, and so on. It's more so what it's like for the end user more so than anything about the training recipe.
We we can go a little under the hood on training, though. And we'll say that, you know, Nano is obviously a new pre train. We also have a new pre train for mini.
And then the larger version is a new mid train. But we find that actually a significant amount of the gains come from new post training techniques. And so I think in the past, the narrative is that you need to pre train these larger and larger models to get better performance, and we're finding that we're able to squeeze a lot more out of post training now.
Talking about how big a model is, the other side of it is the context window. You have a 1,000,000 context. I know that Sam at that day last year, he said that, yeah, 1,000,000 was, like, months away, so right on right on time.
Can you talk about, yeah, how hard that was to get to 1,000,000 and then maybe where the end game is in your mind? Is it 10,000,000, a 100,000,000, infinite? What what what really matters as you start to scale this?
Yeah. Josh worked a lot on long context, so he's the right person to ask. Definitely.
So I think the first thing that we that I thought was really interesting when we were going to long context is actually some of the evals that you see as, like, headlines on maybe other blogs where it's needle in a haystack. Actually, most of the models do really well right out of the box. But then we had to actually first get a lot of measurement on the longer context for long context reasonings.
You know, we actually just open sourced two new evaluations that are about using the context in a more complex way. So, you know, one of them, you have to reason a lot about ordering, and the other is actually walking through graphs. So there's a lot of reasoning that you have to do in those datasets, and that's where doing long context is actually much harder.
But single needle in a haystack, we were able to saturate pretty easily, and then the most of the work came at this these harder tasks.
Yeah. I was gonna say how no. Just how you think about length of context in terms of consuming documents versus, like, active kinda, like, thinking and planning.
I think there's obviously a whole part on the prompting side around building agentic workflows. Do you do you think that people maybe, like, still think too much of it about, yeah, needle in a haystack kinda document retrieval versus, like, traversing very long plans and kinda, like, iterations in context?
Yeah. I think the mental model that I have is maybe actually has some more variables in it. So there's sing there's the needle in a haystack where you have, like, some amount of distractors and some, you know, needles that you're trying to find.
And I think that it's more so about how dense of the context do you need to use. So, like, summarization, you're you're actually just using the entirety of the context, whereas, you know, needle in a haystack, it's very sparse. And then I also generally think about orderedness.
If you're going to make some sort of inference on this, do you are you just look looking, you know, sort of front to back, or do you need to move around in the context in order to generate a good answer while the model's sampling?
Yeah. Is that something that you worked on with Graphwalks?
synthetic and clean way to measure the model.
to sort of test the model's ability and train in the model's ability to reason throughout the context in a sort of shuffled way. Yeah. You know, actually, I have the ability I I like to give people a little bit of visual aid with with these things.
So I actually went into your Hugging Face release and got a example of the graph task. And so there's there's a few versions of this. Right?
There's, like, the BFS and DFS version. And, also, it's I I guess it's very character specific. So I don't know.
Maybe could you tell us, like like, you know, design choices around this? Like, what was surprisingly hard? You know, anything like that.
Yeah. So the idea here is you you take a graph and you encode it into the context by looking at the the edge list and just putting that into the context and then asking the model to do an operation. And then, you know, under the hood, we're actually just executing the real operation and using that to then evaluate the model's ability to work.
One of the things that I found surprising at first was the what the model would do when it wasn't sure how to use its context. You know, early versions of the model just sort of looping saying, like, oh, no. I can't find this edge that I think need should be there.
And, yeah, I think I was actually very surprised how all models seem to have more difficulty than I would have expected on a task that, you know, we would find very simple or, like, you know, maybe an an an undergrad could write a Python script to to run-in a couple of minutes.
Yeah. Right. Okay.
So, like, what is the per like, no. What what is the real life task that this is meant to model, I guess? You know, I I feel like the other one, MRCR Yeah.
Seems a little bit more intuitive where, you know, you have, like, four different stories and you pick out the second one, and that's a that's a real task that that people have. But people don't really traverse graphs. Like, this is a bit more theoretical, but, like, you know, is there was there any sort of correlation study done?
Yeah. This is actually meant to be sort of the idealized version of, like, a multi hop reasoning benchmark. So we have a lot of things where, you know, you're putting hundreds of documents into the context, and then you might ask a question that you actually have to traverse 10 documents for.
But there, the edges are they're implicit. Right? Like, there is some underlying graph that's connecting all of these documents that you need to traverse in order to answer the question, But they're actually much harder to traverse because the edge isn't actually given to you.
And so the question there was like, okay, if I actually just give you all of the IDs of these things that you need to traverse, can the model even do that? Where it's like a it's actually just a lower bound on how well the model can do. And I think it's a, that's actually somewhat well well reflected in some of the internal benchmarks we have that are using more natural data.
Yeah. You can imagine something like a tax return, right? Where you like upload the entire tax code, Like, to figure out what to put into this, you know, box, you'll need to reference all of these boxes.
And so this is, a similar level of multi hop reasoning. But, again, like Josh said, all of the references are implicit.
Yeah. I I think that some kind of backtracking, if it's needed, is also super interesting, especially for agent work. I for listeners who who've been listening to us for a while, we actually covered this paper in NeurIPS last year two years ago, CogEval, where they actually modeled graphs for graph traversals for agent planning.
And, it it reminds me closely of that. It's just that they never came up with this exact format that you have here, basically is the same thing. Yeah.
I also like that you included blank answers because sometimes people do hallucinate Our models do hallucinate answers, and you have a fair amount of blank ones.
Thanks for random sampling over graphs I did, I guess. Yeah.
Is this tied also to the file search API that you released recently? Like, how should people think about how everything kinda comes together in the API?
Yeah. I think oftentimes with retrieval, you, you know, might be using Rag to fill the context. And a lot of this is like to get around the limitation of a short context window.
So we do expect a lot of developers to start, you know, uploading their full context more directly to the model. So for smaller tasks, you maybe don't need the whole vector store. But we do anticipate this to play well with that paradigm as well.
Like, maybe you can just insert way more chunks into the context. So we we think it'll play nice.
Yeah. Any relationship to the memory upgrades in TragicPt that we recently got? Is long context just directly usable for memory, or should we just always have a separate memory system?
Yeah. It's a it's a good question. So right now, the Dreaming feature, we kind of have some of the these memories embedded in the context.
But, you know, they are they are separate features. So 4.1 is powering the API, whereas the enhanced memory is is ChatGPT only.
Yeah. Awesome. Yeah.
I think I think that's interesting. I guess the the one last thing I'll call out on long context, which is kind of an unintuitive or maybe there's an explanation, which was the, you had, you had two needle for MRCR, and then we had four and eight, and everything kind of just regresses to some kind of baseline of like, let's say 30% or 20% as that. But it's interesting to see where the smaller models sometimes match or outperform the larger models.
I was wondering if there's anything unusual there, or do you think it was, a bad roll of the dice?
I think it's probably just a a bad roll of the dice. I think I would probably look more so at the the larger panel once these things regress as you increase the number of needles because there's sort of more complex reasoning that has to do about the order of different things in its context.
Yeah. Awesome. Yeah.
Cool. Happy to happy to move on from there. Yeah.
We have a whole bunch of other evals that we can go over. So I had in my notes that we could talk over, you know, any anything that you that you want. There was also, like, Collie from Shen Yue with who is have have on a podcast for instruction following.
And I I I realized that, you know, he joined OpenAI, and I wonder if he had a role to play in that one.
No. We did not collab a ton on it. Honestly, I think it's best when email authors and model developers don't collab too much because you you want to keep things, you know, as objective as possible, not trying to game any emails.
Yeah. And and then there I I think there was also, like, for the first time, the announcement of the or shout out of the internal instruction following benchmark from API data. People have had the ability to opt in to share data for a while.
Actually, I I, like, published the I I posted a tweet out because I found it in the dashboard that you can just opt in and and, like, there's there's basically sixteen days left for this program where you can just get free inference. And, like so so I'm just kinda curious, like, what you found from that kind of IF eval that that might be different from the normal IF eval that people have. Yeah.
Totally.
you know, or or crafted in a way that are easy to craft. So for example, like, Graphwalks is is somewhat easy to craft. Like you can create this graph and verify it easily, but it is not exactly aligned with what the users are doing.
And this is true for some of the instruction following evals where you ask the model to output exactly four words or, you know, three paragraphs or stuff like that, things that you can verify easily in code. And these are useful instructions, but we find that many of the really interesting instructions are actually challenging to grade. And so the open source evals often don't have them.
And so getting this like real world diverse set of data actually helps us find like, what are the commonalities and what developers are doing? What is a really good example of, like, a negative instruction? And then we can go from there and figure out how to how to evaluate it.
Yeah. I I think that's that's also an interesting question of, like, what domains do people use you on? And I I wonder if, like, there's a way to tell you because sometimes it can be very confusing if I for ex especially because maybe I'm building an app and letting people use my key, but other people are building apps on top of me.
Yeah. Where you just have to parse through the prompts. Yeah.
It's true. Well, I will say we do use our own products internally where we can. And so you're we're not manually by hand reading every prompt.
After they're like anonymized, we scrub them of any identifying data, then we use our models to take passes to categorize them. And so if we get feedback that like we're not doing well on ordered instructions, then we can kinda do a pass over all of our data and find some good examples of those.
So there's the instruction following section in this great prompting g v t four one models. I think maybe we can go through some of these examples. The first one that caught my mind that it's not necessary to use all caps and other incentives like bribes or tips, but developers can experiment with this for extra emphasis.
So I I think the second part leaves me confused. Are you saying that people should still try and do this and sometimes the model responds positively to it? Do you feel like it's still just part of the lore?
I'm curious why I I would have loved for you to say either yes. It works or like, no, you should stop. It looks silly.
I guess the truth is somewhere in the middle. The truth is always messy.
just stated once and clearly. But we find, honestly, developers often become the best experts at prompting our models because, you know, you're building your livelihood on this thing and and get to know the details of it really intimately. So I will say stuff like that won't hurt the performance of the model.
We kinda always wanna leave it open to people to figure out what works best.
Yep. Yeah. And then you had to always start with our response rules or instructions section.
Are those keywords meant to be taken kinda like verbatim? Like, those are kinda like the tokens that work the best, or is it just like a an example?
Warm example.
Yeah. K. Cool.
Yeah. This is great. I feel like until today, did an episode with, like, the prompt report on, like, all these prompting techniques, but then it's also unclear for which model and which ones work best.
So it's super useful. And then you had a in the agentic workflows one, you have a persistence thing. It's like Yeah.
Please keep going. How much?
But 20 I I wouldn't it's not that this one prompt improves SWE bench 20%. It's that we found this is the most effective harness for our model. And combined with all the post training improvements, it results in the big improvement.
But, yeah, like, the model is trying a lot to be helpful. And often it wants to check back in with the user and be like, you know, should I keep doing this? Like, is am I on the right track?
And so a prompt like this makes sure it keeps going, doesn't bother you again, and just gets the task done.
Yep. Yeah. I think, like, there's this interesting trade off between persistence and yielding back to the user.
The more agentic a model wants to be, the the more persistent it should be, but then sometimes it just goes off the rails.
And I wonder how you solve this trade off because sometimes it just goes too far. There's been criticisms of Claude Sonnet trying to rewrite too many files at once when I just wanted to make one thing, for example. And that's a that's a form of bad persistence.
I I what are the axes here in which, like, you think about it? Yeah. I think one of the interesting thing that comes to mind here is that we had an extraneous edits eval, where you ask the model to make an edit and classify like, were all of its changes related to what it was asked to do?
Or did it go off and and do a little too much? And we found that from four point zero, which got 9%, which is pretty crazy. 9% of the time making an experience edit is a lot.
4.1 is at 2%. So it's a pretty big improvement.
So yeah, I'll just say like focusing on this, we've heard feedback about this. We made an eval, and we made sure to track it and improve it during training too.
Yeah. Yeah. I mean, everything comes out to eval as as as as no surprise to anybody.
That's true. There's another interesting eval that I think is causing some noise. For the first time, I think also that and you being the master of structured outputs should know that JSON is bad now, and we should all use XML?
I wouldn't say that. I don't know which eval you're talking about. But It's in the prompt guide, which maybe you guys didn't write.
So we're kinda springing this on you. Yeah. Noah and Julian on our team wrote the prompt guide and did a great job.
I do think XML is very helpful for structuring prompts, Whereas for parsing outputs, maybe the story is a bit different. Like, sometimes it's really useful to get outputs in JSON so you can plug them directly into your application. But I do think the models work particularly well with XML as inputs.
But, Chris, you need to add? No. No.
Cool. I I mean, I think people always just care a lot about cool tool calls and structured outputs as as you well know. And so any updates to instructions over there is good.
People also are interested in this concept of that apparently putting the instructions and user query at the top and the bottom, so duplicating it at the top and the bottom in the context, is much better that is better than putting it top only and much better than putting it bottom only. Again, this is from the prompt guide, so I don't know how aware you guys are on this.
Yeah. I think part of that was just, like, you know, empirical. We we tried all three for when we were evaluating the model, and having that redundancy is definitely the best.
But then using the those the instructions at the beginning, the model's going to be able to then take that into account as it does processing.
Yeah. I I think, like, a lot of people would see this as, like, running counter to prompt caching because, obviously, you want to put the things that change a lot at the bottom. Basically, is this fixable in post training?
Like, can we just tell models to take instructions or user queries only at the bottom because we want to optimize for prompt caching?
When we figure it out, we will do that.
Mean, it seems doable. It seems like a post training thing. I I don't know.
Maybe my mental model post training is wrong. So I think actually having things at the the beginning of the prompt, you would still get prompt caching there. If you're putting in, for example, like, a big needle on Haystack and you have the data changing each time, like, be it per user, there's still different ways that you can be putting the prompt at the beginning and getting a lot of the the cache hits.
It sort of just depends on your use case.
Yep. Awesome.
The the other thing I noticed, I know you made a note of this, Sean, too, is our own chain of thought and reasoning and how people should think about this model versus their reasoning model. Yeah. What's your yeah, should I just use 4.
1 and prompt it to do a channel thought? Should I use o one and make a plan and then use 4.1 to implement the plan?
How should people think about composability?
Yeah. It's a great question. We have found that 4.
1 is a lot better at doing planning and thinking through its steps in COT when prompted than our previous non reasoning models. But our reasoning models are designed to have kind of more coherent plans and be able to reason over longer horizons than these non reasoning models. And you can see that reflected in things like intelligence bench benchmarks.
So AIME, GPQA, stuff like that. You'll see the reasoning models do much better. So in general, I would say like the question you're really getting at is like, I'm a developer, which model should I be using?
And I think the answer is always going to be the fastest model that accomplishes your task. Right? So maybe you start prompting 4.
1 as a starting point. If it does your task super well, then maybe you could drop down to 4.1 minutei and save latency or even nano.
Whereas if 4.1 is struggling a bit little, maybe needs more coherent reasoning over longer time horizons, then maybe you upgrade to a reasoning model.
Is there a quick way to get through these heuristics? I know one thing that a lot of people do is, like, they use o one for, like, a plan, and then they put that plan in cursor and then have the plan apply to their code base. It sounds like there's maybe not a rule to when to do which.
It's just, like, task dependent.
Yeah. I would say we're all kind of figuring out the best way to use these models together. And so I do think reasoning models for planning and using kind of more targeted models to execute is definitely a good architecture.
Cool. If there's nothing else on on on that side, I'd love to go into the coding, which is something that we're emphasizing a lot. It's doing super well.
It's better than o one and Suitebench. Was that expected?
Not really.
Yeah. Like, what's the I mean, what's the story there? There's also Sweet Lancer, which is a newer one, which attaches a money value to things.
And, basically, what like, what should people understand is going on here? Like, is it a better coding based model or just a coding agent model? And I think there's also there's also a question about, like, you know, how important to coding is it if I'm not using a coding use case?
Yeah. So I'll start by saying we just set out to make model that was great at coding, both in your terminal or in your editor or wherever you wanna use it. And so we kind of broke that down into the problems that it encompasses.
So like developers want the model to produce better diffs, for example. Or they want the model to explore the code base correctly. Or they want to produce code that compiles or produce code that writes tests.
And so our approach was kind of teaching the model all of these various facets. There's kind of just a bunch of work streams that all coalesced around GBT 4.1.
Yeah. I think much improved post training all over to make for a better coding model.
Yeah. I I think there's, like, different kinds of coding. Right?
Like, it's it's interesting for me to observe that there for example so I'm just gonna pull it up on the chart here because I always like to show people visuals. You're 55 on sweep bench and o one gets, like, a 41. But then on oh, I I don't think I I don't think I have the others.
Like, but but Ader is it is less it is not at o one level. And so I I think I I think I struggle to get some kind of intuition of when like like, what are the different elements of coding? I guess there's, like, you know, single file edits where there's, a diff or a or a whole file, and then there is entire project edits.
Is that a reasonable split? Are there more to this?
Yeah. That's one way to think about it. Basically, where g p t 4.
1 can kinda explore and go through a repo. Yeah. It's been trained to do that particularly well.
Whereas, you know, to just get some code and produce a a change, a reasoning model might do better because it it can kind of reason over the entire file. And so that's one good way to think about it.
Yeah. Yeah. That's fair.
Any any understanding of, like, the smaller ones, the smaller models? Like, basically, for coding, I should only use 4.1 and forget the rest?
No. You you might, like, want to use the smaller models. Maybe if you have, like if you have an IDE where you need an autocomplete feature, for example.
Or if you want something super fast, if you're building like, I don't know, a text to SQL thing, you might want the first version to populate instantly. So you can see like 4.1 minutei is actually quite significantly better than four point minutei, and not that far away from the old four o.
So I I do think that model will find use case in in a bunch of these coding niches.
And I know you might not be able to talk about this, but the clip of the OpenAI CFO talking about the AgenTix Wii has been going viral, I think, today. It it seems like every lab is putting a lot of emphasis into coding. So, yeah, I'm just curious if there's anything you can share about how people should think about OpenAI in coding.
You know? Obviously, today, you don't have, you know, Clotus, ClotCode. You don't have any anything related to coding.
And I think the WinSarf partnership today, they they're giving four one for free 4.1 for free for a couple weeks. It's maybe, like, one of the first OpenAI endorsement, I guess, on the livestream.
But, yeah, just I know there might not be an answer that the PR team might approve, but Okay. I'm curious if you have any takes and thoughts. I think just stay tuned.
Yeah.
I think coding is an important use case for our users. And so that's why we focused it on it a lot for four point one. We also love to use our own products internally.
And so making four point one selfishly helps us move faster as a company. And so that's where the real focus has been for this model. Mhmm.
Do do you track what percentage of code is is written by four point one internally now? We do have some metrics like that. I don't have it off the top.
But I was actually just talking to one of the researchers on the team who worked on something over the weekend. And he said that this model GBT 4.1 was able to, like, get 4,950 of his commits on this massive PR done.
So we were pretty happy to hear that.
Excited to use it. Awesome. Yeah.
I think on the yeah. I I think coding is a super exciting use case, and I think, like, OpenAI has always been very developer first as you've been too, Michelle. So it's great to see the the convergence.
Yep. The other I think the last capability that I kinda vectored in on was vision or just multimodality in general. It is a lot better.
Basically, I I I I think, like, I I I really like these niche benchmarks like MathVista and ChartSyve. Yeah. Just any any any extra color on on, like, the vision side that you wanted to talk about, but you maybe you couldn't fit into the blog post.
Yeah. Yeah. Go ahead.
Oh, I was just I think one maybe small nugget there is actually I think the the 4.1 mini is really exciting on that front. As we were talking about, it's a different pre training base.
And I think that really shows up in some of the vision evals.
And yeah. We talked about, like, coding instruction following long context, a lot of gains coming from post training. But in particular, multimodal, like, basically, everything you're seeing, the gains are there for pre training.
So kudos to the pre training teams there. They've done incredible work on on perception and multimodal.
Yeah. Totally. So something that we've been exploring on the podcast for a while, and I'm curious if there's any takes on on on your side, is is there a strong split between, like, sort of what I call, like, screen vision versus embodied vision.
Right? Like, are you taking pictures of are you training on snapshots of a computer for computer use? Or, you you know, and anything with charts, anything on on a PDF is very similar to that, or pictures from the real world, which is more embodied, right, like where a robot might be able to use that.
People have argued back and forth. I'm curious where the the the movement is or the emphasis is.
I think one of the first off, I think that 4.1 is better at both of those things regardless of how it's actually trained. I think I would probably somewhat defer to the pretraining team when it comes to which one you should be using.
We're using, you know, a mixture of both, but we've improved our results across evals on both.
Awesome. Yep. Yeah.
That's something that I think people should they definitely do want to explore the more embodied stuff as well because the benchmarks tend to focus on the the screen vision stuff, you know, more more chat. It's always easy to get the eval that is easy to grade. Yeah.
Exactly. Those are the things that get looked at the most for sure. Yeah.
I think one of the things that was really funny with both of the 4.1 mini and nano is we had some strange internal eval results.
And it turns out that actually the these new vision capabilities, they were able to read, like, you know, signs in the background and stuff, which was actually changing, like, some of the validity of our results. And so we were, you know, just running into different Eval problems as you actually improve the models.
Is there a feature of a 4.1 image gen, or is that, like, a completely different part of this vision? Like, you know, in in some sense, vision is image to text, and the other the other way around is image gen.
Is it that simple, or is it something else? It is not. No plans right now to to get 4.
image gen. K. Well, you know, it's very, very popular.
We like the game too.
It's like melting your GPUs. I mean, talking about GPUs. Right?
Like, you know, part of this whole deprecation of 4.5 and and moving people to 4.1 is to get back your GPUs.
That's a that's a message that both Shiki and Kevin Weil have mentioned. But, like, you are running all these models concurrently for the next three months. Like, I don't know if you get back to GPUs or you think you just grow the usage even more.
Yeah. I I do think, you know, people get the message on deprecation and start moving over. And so what as developers use this model a little less, we can kinda reclaim that compute.
But you're right. It takes a while. And the trade off there is really our commitment to developers.
Like, we have something in the API, we won't take it away on without, you know, sufficient notice. Yeah. With some notice.
So that's the trade off that that is is right for us.
Okay. Awesome. Then a couple other smaller announcements.
Fine tuning available day one, which is, I think, new for OpenAI. Usually, you have to wait, like, a month or two for the fine tuning capability. For one 4.
1 only and and mini 4.1 and mini only and nano in future. Any specific callouts for for fine tuning?
I guess, like, this fine tuning is just general discipline that always applies, but any wins that you guys can talk about?
So first off, yeah, shout out to the fine tuning team. They've worked really hard to get this ready on day one. One thing I will say is that I think people have slept on the preference fine tuning offering or the I think that's what we call the product.
Yep. So SFT is people know it pretty well. It's the original fine tuning we had.
Whereas this preference fine tuning is super helpful for steering in a particular style. And so I I think not enough people are using that. Isn't that only for reasoning models, or is that for everything?
No. That's reinforcement fine tuning is only for reasoning models. Right.
Preference fine tuning is to offer the pairs. Yeah. Exactly.
Yeah. And I thought it was in alpha. This is why I haven't looked into it.
I thought Jean I think it's a RFT that's still in alpha. Okay.
Well, that's a lot of confusion that we that we just cleared up. Yeah. I think we're going to last time, you know, I'm doing my conference again in June, and I think we're gonna do a workshop on just general all the fine tuning options, and I think that will clear up a lot of things, which is good.
Okay. New models, I know that we can't talk a lot about a lot of them. Noam Brown from your reasoning team just said that there should be a follow-up on reasoning models soon.
What can we say about that? And sounds like he's not the right people to ask, but but stay tuned for Yeah. But, like, 4.
1 is a good basis for, like, whatever comes next. Right?
Yeah. Not all of our models kind of build on each other necessarily, but we think 4.1 is a great standalone offering for developers.
And we also think, you know, reasoning models are a good tool in the toolbox.
Yeah. Like, more just generally, like, I always want to explore the relationship between non reasoners and reasoners, and then also, like, how we merge them. Are we doing routing?
You know, anything anything of that sort. Obviously, you have a lot of secret sauce. Cool.
And then I think the other thing that a lot of people are demanding or asking about is the creative writing model. Will that ever see the light of day?
We're working on incorporating kind of those improvements into the models more generally. Not a separate release. People loved about 4.
5 is, like, the humor, the green text, the nuance. So we've heard that feedback. And I know, yeah, there's lots of folks working on that and trying to bring it into our next models.
Awesome. Alessio, anything else? No.
This was great. Any requests for the developer community? Things that you want them to try out that maybe people are not doing?
Things you want them to build for you using the new one the new APIs?
I feel like, first off, send us feedback. It was really useful to look at different partners and customers who are using our models and to get this, like, nice wrapped feedback from them. It allows us to iterate a lot faster.
And on that vein, you know, opt in to to data sharing. This just helps us make the model better for you. And one kind of slept on way to do this is the Evalues product.
So you can upload an eval and opt in such that we'll pay for the inference costs if we can also use the eval. And this is just another great way, like, we'll we'll use those evals to make sure our models are are getting better for people over time.
Yeah. I think the opt the evals is permanent. There's no end date announced.
But the opt in in the API is at least until April 30. I think a lot of people still don't know about it. We might wanna extend that so that people can Yeah.
Do more. Good flag. Yeah.
All all raised with the team. Yeah. Awesome.
And and I think the the the last question I had was on just on pricing. I think pricing, you know, it's basically just generally cheaper than four o, but, like, not a not a ton, but, like, cheaper. And then you're also introducing this concept of blended pricing for the first time that I've I've seen it, but maybe it's just been out there for a while because you have caching and all that.
Just generally, what is the cash to noncash ratio that we should be thinking about when thinking about workloads? Like, is there is there a general rule of thumb?
So one clarification, which is that GPT 4.1 Mini is not cheaper than GPT four o. So not it's not just like a blanket decrease in all the models.
But however, 4.1 minutei is cheaper than 4.1.
Also, not sure if this is widely reported, but we've increased our prompt caching discount from 50% to 75% on these models. Yeah. I saw that.
So that's a a big input, you know, into figuring out what kind of application you build. And then your question was on, like, what kind of Right. Pricing thing about?
Yeah. Blended pricing. Right?
and across providers because, like, I you know, it's like, some people are three to one in terms of context to output, and then some of part of that is cached. I I selfishly I I make a chart that just plots all the model labs versus all the prices that you you and I'm sure you guys have seen it. And I don't know what numbers to plug in there.
So what are people seeing in real life? What's the median, you know, caching rate?
I don't think we have that off the top. The the blended pricing is more to just make it easier to compare. Like, so you could say something like g p t 4.
1 is 25% cheaper than g p t four. Yeah. You want one number.
Yeah. Yeah. Yeah.
No.
Alright. Well, I'll have to figure it out. But thank you so much.
That was that was fantastic. Thanks for all the work. I think people are very excited to get to work testing this out, giving you feedback.
And I'm sure we'll be back again for the next one, probably the reasoner.
Nice. Thank you, guys. Thank you.
Shared via Hopper