⚡️GPT5-Codex-Max：以人格、工具与信任训练智能体——Brian Fioca + Bill Chen，OpenAI

Okay, we're here at AI Engineer Code, and we have 2 of our speakers, Bill and Brian. Welcome.

Hi.

Thank you for having us.

Bill, Brian, I know you've been listeners for a little bit. What's your take on Latent Space? How does it perform a role in your work at OpenAI?

Yeah, I mean, first of all, I love the name.

I'm a massive Latent Space context-management person. Tell us the story behind the name, by the way.

Yeah. So it started—we never had Latent Space as a name at the start. It was called L-Space.

Interesting.

One of my readers donated the domain name lat.space. He said, “You want it?” I said, “Yeah, awesome.” So the name just came accidentally. It was in the ether, but I didn’t have the domain. I just called it L-Space. L-Space is like the visual domain.

No, it’s amazing. I love it because you’re always on the cutting edge, and it goes into a lot of detail about all the things I should be keeping up with as part of my job. There’s so much to keep up with, right? So there are only so many sources of really good, high-quality information for what’s happening on a deep level.

Well, you guys have your own podcast now, so I’m like, “Competition.”

Yeah. Well, I still listen to yours, and I still think yours is really good. So you guys are, I guess, representing startups, Team Codex—everything you just launched, Codex Max yesterday. We’re good at namings. People do make—I think Tibo was like, “Yeah, you know, we’re good at a lot of things, but not, like, naming.” Why call it Max? Was there any internal discussion?

Yeah, I mean, it’s complicated because it needs to be differentiated from the previous one. The idea is that Max can run for a really long time. We can go 24 hours or more. I’ve actually had it run for more than that over the course of a couple of days, with me closing my laptop and nobody opening it.

But the name—you could come up with something like Pro, but Pro is sort of slower and more thoughtful. Max is about speed and maximization, like a maximalist. So for this mode, it can run for a long time, but it can also, for the same types of problems, get to the right answer faster.

Is it inside Codex on the web?

When you say a really long time—24 hours?

I think that was on the web. Inside Codex, I’m not sure, but I’ve actually done it on my local computer for quite a bit longer than 24 hours, over the course of a couple of days, with my laptop closed and nobody opening it.

So it’s simply better and faster?

Yeah.

So I think part of what you guys are speaking about is the training that goes into something like this. People just kind of wave their hands at RL, but what specifically have you learned? What’s a good path to focus on?

I got to—I mean, this sounds weird to say, but I was lucky enough to be really close to the training team while GPT-5 was training. Bill was there too.

One of the big things that we focused on was personality, right? It’s really important to build trust with developers in how a model works. If a model doesn’t act the way you expect it to, or if it doesn’t work alongside you well, you’re not going to trust it. You’re not going to get as much out of it.

For coding, we thought, “What is the best personality for a coder, for a pair programmer, for somebody you trust?” How do we evaluate against that? How do we come up with behavioral characteristics?

We came up with things like communication: it needs to keep you abreast of what’s going on while it’s working. Planning: come up with a strategy, do some searching, gather context, and figure out what to do before you just dive in, if it makes sense. Then check your work. These are just best software-engineering practices that turn out to be behavioral characteristics, and we can measure the model’s performance on those behaviors and grade it that way.

Yeah, I will say that another key aspect of how we train the model is that we work really, really closely with some of our coding partners. A lot of those folks lead on the bleeding edge, so they have a lot of understanding of what particularities they need. We really focused on those areas and dove deeply into them.

Yeah, that’s right. Especially tools, right? Different harnesses have different tools. Some people have context, like semantic search. Some people have different ways of doing code edits. Initially, our models were trained the way they were trained to use tools, and that kind of bakes in a habit. We’ve been getting the models better at using different types of tools.

Yeah, it’s a lot to follow that point, but I’ll go tools first and then go back to the personality piece.

On the engineering side, I think the communication when GPT-5-Codex just came out was, “Well, this is the model trained for our Codex, not necessarily your choice,” right? Has that message changed for other startups using the GPT-5-Codex model?

Right, no. Codex is, just to be clear, the frontier coding model that we have, optimized for its harness. The Codex team is very focused on creating a coding agent, and they want it to work perfectly inside the shape of the harness and API that we have. So they’re completely unbounded.

It’s open source, so—

Yes, it’s open source, and the model is available in the API. That’s what they focus on.

And then the conflict is that you just said other startups have other tools.

I think we can disentangle Codex from the mainline models a little bit. The Codex models are focused on the agent itself—the Codex agent. The model has been trained with the agent specifically in mind.

It actually turns out to be somewhat easier to integrate because we come into it with a firm opinion on what the best way of using it looks like. Some of the folks we work with really appreciate that we come into it with that opinion.

For the other ones, which have more general or specific tools that they need, the mainline model is more general. That’s what Brian was referring to when he talked about GPT-5’s tools getting—

Yeah, so the non-Codex GPT-5 is more general across the board. It can respond to things that are much broader than just coding. It has coding capabilities that are also mirrored in Codex, and they work together to keep that tuned up.

Since it’s more general, it does have more steerability with different types of tools. When you’re implementing tools, the model can get bogged down if it hasn’t seen a tool that it’s used to. It might take more time thinking about how to use it or make more mistakes.

Our recommendation is that if you want bleeding-edge, coding-focused performance, pay attention to the Codex line, the Codex SDK, and the Codex models, because that’s what’s really aimed at it. You’ll have to do some work to look at how we’re implementing our tools inside Codex to maximize its capability without bogging it down, but people are having success bending it in ways that maybe we haven’t thought of.

Sure.

Yeah.

Do you have any examples? You say people are bending it, and you have a thought.

Yeah. Codex is trained with terminal tools in mind. What we thought would be the case is that you would essentially have to strip out all of the tools except for the terminal tools.

But we found that some of our partners discovered you can still have a lot of the tools, as long as they’re named the same way as the terminal tools and have the same input and output. All of a sudden, tool-calling performance jumps by a lot.

Yeah. Codex loves ripgrep. If you make a ripgrep tool and tell it to use it, it’ll use it.

So if you call it grep, it actually does a little bit worse, but if you call it rg, it does really well, right?

Yeah. This is something that we ourselves only discovered.

This is one of the coolest things about model training. They literally develop habits just like a person does. If you’re working on some podcasting tool, you’re really good at editing, and then somebody makes you use a different one, it’s going to slow you down. You’re going to get bogged down and make mistakes.

Sure, but I don’t know if I’d call it cool because it’s supposed to generalize.

Well, right. That’s the end goal, yes, of course. That’s what we’re doing with the GPT-5 series of models. They’re way more general, and Codex is focused on maximizing coding. Those are the 2 horizons that we’re working on.

Yeah. Awesome. I want to go back to personality.

I know you hate that word sometimes.

It means different things to different people.

Yes. When it comes to people who are very keen on model research, model personality is much more like what your peer group would say.

Yeah. It's like your warmth, your friendliness, or your agreeing with people's emotional state, whatever. It's really jarring when that is also applied to coding agents, where, like, I want to talk to, like, Silicon Valley HR, but it could be I'm doing the fake.

Awesome. I think the other thing is also: what does it matter? Because you said a lot of things about commenting, that you're going to use user engagement and all that. Does it matter if it's a cron job anyway, right? You're going for 24 hours; you're closing your laptops. You have the extra-high verbosity parameter now. Doesn't matter.

Exactly. So here's where we're in this world right now: we're in between a situation where people don't quite have—the models don't quite have—the trust of senior engineers or engineers doing very important work. And so we've found our customers have found that people really want to follow along with what it's doing so they can interject or stop it, or at least understand what it's thinking, so they don't waste all kinds of time doing a rollout that they have to throw away.

For the GPT-5 series, because it's more general and it's just about as good at coding as Codex for a lot of things, we've taught it to be more communicative. It has preambles before tool calls. It'll say things like, "I'm about to go look for this." And you can steer that really well.

I actually really like it. I've created a personality for my coding agent—I tweeted about this—because I really like my tools to be kind of fun to work with if I'm in there with them. I want to wake up in the morning and be like, "Oh, I'm going to go work on this project with my buddy 5.1," right?

But some people don't like that. And for, like you said, long-running agentic tasks, that can get in the way. You're burning tokens that don't really matter if it's running in the cloud. So with 5.1, you can turn that off. You can prompt it not to do that, but the Codex model can't actually do that, and it relies on the reasoning summarizer to give you that update.

I guess, more broadly, what should people know or think about in terms of what we're doing with models in general? More broadly than just the model-and-experience release, what trends are you seeing, and what discussions are active?

Our talk today is focused on talking a little bit about the trend that we're seeing: the abstraction layer really starting to move upward from the model layer toward the agent layer. As I said, we train our models to be a little bit more opinionated, especially with regard to one model, like Codex, and the models are really good at doing certain things inside of a certain harness, a certain type and shape. So we're packaging that up more closely. We're actually shipping this entire agent all together. Then you can build on top of that agent.

One of the patterns that we're seeing is, rather than focusing on optimizing with every single model release, you're actually just able to plug in an agent like Codex into your platform and be able to use it out of the box.

Yeah. And you're seeing Zed use this, GitHub, and VS Code. It lets you just package a whole agent to work inside of it. That way, if you're building a coding tool, like I said, and you don't feel like having a whole team keep up with every single model release and every single API change, and how to update the harness to do different kinds of sandboxing and all that kind of stuff, you can just build one layer above.

Yeah. One thing—one theme—I'm finding at this conference so far, even early, like the pre-conference talks, is that I think people are starting to really explore subagents: agents that, more abstractly, use agents. We used to call it multi-agent; I don't know what it is now. I don't know if there are any thoughts on your end about this, where you get to call—I guess a very basic example is what you just said—which is that the agents can create another instance of Codex as a tool, and then, from there, you just use the tool. Is there a case for scaling with subagents? There you go.

Yeah, I think so. I mean, Codex Max was designed for that, right? It has its own compaction and context management. Codex Max manages its own context window, and so it can run basically forever without you having to worry about it while it's inside of the Codex harness.

And that lets you do a lot of different things. You can essentially have it hand off its own context to other subagents, right? So, letting it spawn different agents to do more of its work in parallel and all kinds of things like that. It's built for that. We're just starting to see the indications of what that means, but that's, I think, the future, and we're really excited about that.

Yeah. It's really, I think, like I said, the trend that we're observing here—really moving up the abstraction layer to the agent layer—allows you to do a lot of cool things, like brand-new screens, spinning up a few agents, and creating new abstractions as the long-running agent workflow continues. Right now, we're building all the primitives as well, specifically with that in mind.

Yeah. And it's really about moving the threshold up further, right? Like I was saying before, I now trust Codex to do some of my hardest work. I haven't written a single line of code by hand in months because I know what I can trust it to do.

You're the fourth person that said that in the last 24 hours.

Yeah, no, it's real. I mean, I've actually launched something. There's an open-source project that I did—a Codex upgrade pack for migrating from Completions to Responses—that was totally written by Codex. I didn't write a single line of that code, and now it's out there. It was open source.

Most of the folks at OpenAI—well, initially, when Codex first launched, around 50% of folks at OpenAI started using it. But now—

That's very true. They use it every day. The way that we do it is we're really good at evals, right? In order to develop trust and build a product that can do more than you design it for, which is really what we're talking about here—you’re making an agent that can solve its own problems—you have to get really good at figuring out how to build those guardrails and evals around what it's doing, what it's allowed to do, and checking it in production.

So we have all of this platform tooling now around agent traces and rollout traces, coming up with evals for that, and building graders and all the things you need to maximize the pipeline so you can let it go and then be like, "Okay, I don't really like the way it did that. Great. Have it meta-prompt itself so that next time it actually does a better job."

What are the biggest gaps in terms of organizational capabilities that OpenAI is investigating? Can you say more about that? Why is that suddenly a big priority now? Obviously, I think OpenAI always did internal evals, but now it's a team that's more outward-facing. Maybe this idea that the path to AGI really goes through evals. I'm sorry, that was a little—

It's so true. It was repeated way too many times, but I think there are a lot of academic evals, right? There's SWE-bench, there's other—name it. But I think there's a slight lack of evals on sort of what people care about the most.

And we want to make sure that whatever we're developing, model-wise as well as product-wise, is aligned and is actually making the most amount of useful impact on this world. Applied evals are really in that direction, capturing all of those sorts of real-world use cases and things for us to hill-climb on together.

I like to think of it as, people say it's a PhD in an API, right? But if you hire a PhD student, they don't know how to do the job. You have to give them a job description. Okay, that's a prompt, right? So now you have your policy, and then you have them do the job, and they're going to kind of flail around, right? So they need mentorship, guardrails, evals, performance reviews, and the best practices for how to do their job.

What we're doing is trying to put our models out there and see what they're good at and what they're not good at. We're talking to our customers, and they're like, "Oh, we could really use your model for more things. If it could do this one thing, here's our eval. Help us build those evals with you so that we can see where we're deficient and go back and train the model to be able to do that job in a way that we wouldn't normally get to see it perform."

Yeah.

How do you do multi-turn evals? I think that's the really hard thing. Sometimes you need multi-turn if it doesn't get it right on the first go, but if it could get it right on the first go, then it's no longer multi-turn. So then what?

Do you want to take it? I have some ideas.

Oh, yeah, you go.

I've built a few myself. This is sort of my personal work. I think this is an area that people are just now getting into. We have LLM as a judge: you can use an LLM as a judge to look at an entire trajectory. You can see, "Okay, over the course of all of this, how well did it perform? What did it do?" Then you could walk it back a step to the part you don't like, have the model run the next step with the instructions, grade it on that, and have it improve itself.

We do this all the time inside of harnesses. It's like, "That was a good answer, but I don't really like how long it took you to get there. Can you give yourself better instructions for doing that next time?" It'll write something, and we'll add it in there, and then suddenly it's better, right? So that's one way of doing it.

Yeah.

I think multi-turn evals—most of the companies or startups that we work with these days, the agent runs in a multi-turn way, right? Therefore, if you can build an agent harness that works in a multi-turn way, you can evaluate it. There are also academic benchmarks that already do this in some ways, like τ-bench, and now we have τ²-Bench, which does this particularly well. We certainly take inspiration from that.

I have this idea. I call it a job interview eval. I haven't finished it, but really, if you're evaluating a coding agent, what do you want it to be able to do? You want it to be able to take an underspecified problem. Imagine you're interviewing a developer: you give them a problem, "Hey, go implement a string reverse or whatever." It's up to them to ask, "Okay, I need more information. What are the constraints here?" Then you judge them on that.

They start implementing it, and you give them some modifications and grade them on that. You can imagine building, with an LLM, a rollout that is promptable: the model responds, and then you can grade the whole thing.

Yeah. One thing I would love—and this is the feature-request part of the podcast—is batch multi-turn evals. The Batch API is single-turn, but you can't really batch multi-turn requests. Is that already doable?

Batch multi-turn requests? I don't believe you can do it yet. But I think that's valid, because you need evals to be as cheap as possible. They're not that time-sensitive, and you want to run them overnight when things are cheapest. Feedback taken. That's the thing: every day we're trying to make the platform better, and right now evals are certainly part of how we make product feature updates. We talk to people like you, and they're like, "Hey, can you do this?"

If I'm going to throw thousands of runs at this thing, I should probably spend some time worrying about costs.

Speaking of which, what are you trying to beat, though?

I mean, Devin and Cascade. I have a personal side project where I want to make Devin for non-coding.

Oh, I like—I love Devin so much. I think Slack—my semi-hot take that I'm floating around just to see how it feels—is that Slack is the ultimate user interface.

Yes, for work, right? I don't want to read email. I just read Slack all day. I interact with my email agent through Slack. So basically, I'm building a Devin for email.

Well, that's the thing: you can use Devin to do that, right? A coding agent like Codex CLI. Back in the old days, I started out in the '90s working at IBM as a systems administrator, and I had to write my own custom software and Bash scripts to solve real-world problems every day. So I had this toolkit of scripts that I made for organizing file directories or doing other random things that weren't necessarily writing code.

You can get phenomenal use cases just sorting through your email using an LLM or something right in the terminal, or have it generate snippets of video clips from YouTube that you can watch later, or things like that.

You know, I never thought about that, but I do that all the time as part of Latent Space. I should probably invest in that tooling. I had Codex go through my really messy directory of all these experiments that I was running and completely organize them and put them into shape, and it was so wonderful.

I used it for something more boring: organizing my desktop. We have a lot of files on the desktop, and Codex is really good.

Yeah, people think they have files named IMG_0416.jpg.

Yeah. Just find all the images and put them in one folder. I think even that is something Codex can do.

I think that's one of the big themes we're also seeing: coding tools are breaking out of coding and into personal automation.

Exactly. Because if you think about it, before graphical user interfaces and browsers, how did we interact with a computer? We did so through a terminal, by writing commands and writing code and stringing them together inside the terminal. One way to think about it is that these coding agents are actually computer-use agents for the terminal.

Yes. Yeah.

They're actually incredibly general. I would say that coding agents today are still not vision-native enough. You have to try to get them to use vision, and oftentimes they still fail. We should use vision a lot.

I was going to end the episode by asking for your 2026 predictions. We sit down this time next year—what do you want to see? What do you hope to see? I'll kick it off with the easy one: more computer use.

When you say things like, "We'll have a coding agent build its own integration to your application," a lot of applications don't have APIs or MCPs. The only thing you have is a UI, right? Either because they're legacy or because they don't want you to take the data. But the data is yours; you just have to, in a non-provisioned way, take it as the user.

Yeah. And I can continue just by saying that that's definitely going to be something we'll be capable of in 2026. The other thing that I'm really looking forward to is Codex being able to do more, right? We're already starting to talk about how Codex, or coding agents, can use computers in novel ways. We'll see more general use cases like that coming along, as well as more extensible ways for you to build with those sub-agents.

I really want to see the trust level go up even further, right? At OpenAI, I get to work with some of the most amazing developers I've ever worked with in my life. They're incredible—some crazy tech leads. I wish every company, whether a small dev shop in Alaska where I worked for a while or OpenAI, could have on their team capabilities that you would only be able to get at a top-tier firm, right?

All of my teammates at all these places could turn to a coding model and be like, "Hey, how do we do this crazy, awful refactor that we have to do to support this new customer?" Or, "Wow, there's so much of a mess here. What's the best way to actually implement this new technology?" And have it be so trusted, so right, and so smart that we can actually perform better than we could normally get access to.

I think that's going to be it. Any final calls to action?

Oh yeah, we're Brian and Bill at OpenAI, and yeah, feel free to find us on our Twitter, socials, whatever. And then let us know how you're building.

Yeah. And we love working with startups, and anytime you have feedback about whether you really wish the model could do this or the product could do this, and you could unlock some massive capabilities, just let us know.

Yeah. Amazing. We'll do. That's it. Thank you. Nice. Nice. Thank you.