Talk by Alexander Embiricos, Romain Huet, and Peter Steinberger (OpenAI) on the rapid progress of AI engineering, using Codex as the central example. It contrasts an OpenAI Dev Day 2024 demo on an o1 preview model that could not run or check its own code with a later demo where the model tested its own work and controlled a camera and lighting rig. Topics include Codex's accelerating release cadence (from ~15 months to ~6 weeks), building on the shared responses API, open-source harness, and AGENTS md format, cost and speed figures ($1/M input, $6/M output tokens; ~750 tokens/sec enabling a pull request in ~10 seconds), the Codex app design philosophy, the open-source stack and API primitives, Apps Server and plugins, high-speed inference for real-time workflows, and the future of removing the local/cloud distinction. Peter Steinberger discusses shifting from manual orchestration to managing agents, three changes for scalable agent loops, human attention as the bottleneck, and automating open-source issue resolution. # Channel Identity Observations — Video 01a15ca8 ## Observable Context - This appears to be a **conference keynote** (speaker references "this room," "over 7,000 AI engineers here today") by OpenAI staff (Romain Huet, Alexander Embiricos) plus guest Peter Steinberger, at what the transcript calls "this AI engineer" event — likely the AI Engineer conference / "Dev Day"-adjacent setting. ## Explicit Self-Description Claims - **Corporate affiliation stated directly**: "I'm Romain" / "I'm Alexander" followed by references to "we launched a preview of the 5.6 series" and "Codex" — presenters identify as OpenAI product/model builders. - **Mission claim**: "we look to our mission... AGI that benefits all of humanity." - **Product philosophy claim**: "the goal is squarely not to automate engineers... a product shape that we want is one that maximally empowers engineers." - **Openness claim**: "Codex cannot be a closed product that only OpenAI can improve... intentionally designed Codex as a set of layers that anyone can build on"; harness and app server described as open source. ## Intended Audience - **Practicing AI/software engineers**, addressed directly and repeatedly: - "There's over 7,000 AI engineers here today with us." - "You all are figuring out how this new capability can reach everyone." - "with 7,000 of the finest AI engineers in this room today." - Sub-audience: **engineering leaders** — "when we talk to engineering leaders, most of the conversation is about... value maxing." - The channel/platform frames its audience as **builders and experimenters**: "You guys experiment, you set up tools for yourself, for your team, and in turn, we get inspired." ## Claimed Scope - **Developer tooling and agentic coding products**: Codex app, goal mode, Codex Cloud, plugins, app server, responses API. - **Model releases**: "we used to ship a new model every 15 months or so, and now it's about roughly every 6 weeks"; GPT 5.6 family, cost/speed benchmarks (Cerebras, "750 tokens a second"). - **Ecosystem building**: subscriptions usable across "Open Code, Pi, Droids, Open Claw, to even Xcode and JetBrains." ## Demonstrated Presentation Patterns (vs. claims) - **Product-launch showcase format**: heavy emphasis on shipped features, benchmarks, pricing ("$1 per million input tokens") — demonstrates marketing/launch-oriented content. - **Guest practitioner segment**: Peter Steinberger's first-person workflow narrative ("I manage the manager of a small company of agents") demonstrates the channel includes community/user voices, not only employees. - **Live-demo culture referenced**: "I only do live demos, so I never know what's actually going to happen each time" — though no live demo occurs in this talk ("where's the live demo today?... we wanted to do something a little different"). - **Reciprocity framing**: repeated thank-yous positioning the audience as co-developers ("the entire industry wouldn't be here without you") — demonstrates community-centric presentation. ## Notes on Limits - No curated metadata was supplied; identity observations rest solely on title and transcript. - Speaker/organizer claims (e.g., open-source status, benchmark figures) are reported as claims, not verified. # Delivery Observations: "The Golden Age of AI Engineering" — OpenAI Keynote ## Overview Three speakers deliver a joint keynote: **Romain**, **Alexander**, and a featured guest segment from **Peter Steinberger**. Delivery is conversational, tag-team style, with frequent hand-offs and interjections. ## Tone - **Enthusiastic and informal throughout** — repeated casual intensifiers and hedges: - "Honestly," "you know," "like," "kind of," "actually" - > "Honestly, half the time I open X, I see someone in this room doing something that I had not realized Codex could actually do." - **Self-deprecating humor** from Peter: - > "Now, I fixed that by joining OpenAI. I know — the strategy does not scale." - **Playful banter between speakers**: - > "We refer to him as the demo god." ## Recurring Phrases & Verbal Habits - **"We can't wait"** — used repeatedly by Romain and Alexander (stable pattern, 3+ occurrences): - > "we're super excited to get into all of your hands" - > "We can't wait to see what you can build with this next month." - > "we really can't wait to uh, to see all of you build" - **"You know"** — extremely frequent filler across speakers; single clearest verbal tic. - **False starts and self-corrections**, suggesting live, unscripted delivery: - > "we we we really can't wait" - > "I I read a lot of sci-fi" - > "it's it's it feels cool" (Peter) - **Analogy-driven explanation** — a consistent teaching habit: - World's Fair analogy: > "the World's Fair made actually the future visible to everyone" - Teammate analogy: > "it's just like working with a team" - Manager/reports analogy: > "I was managing 10 direct reports" ## Teaching / Structural Habits - **Numbered and layered enumeration**: Peter explicitly lists "Three changes made it possible. Number one… And third…" and Romain walks a stack "layer" by layer ("First, it starts with the model… Moving on to the next layer… moving up the stack"). - **Explicit takeaway framing**: - > "if there's one thing I want you to take away from this section and this talk, it's this." - **Progressive timeline narratives** to show change over time: - > "completion, and then we went to inline prediction, and then finally… command K" - Peter: > "last year, I was primarily constrained by tokens. Now… the constraint shifted to compute… Now, I'm primarily constrained by attention." - **Contrast pairs** for argumentation: - > "software ate the world. And then AI ate software. But now… AI engineers are eating the world." - > "It's not the end of engineering… it's a return to the roots of engineering." - > "The agent runs the inner execution loop. I set the direction… in the outer loop." - **Rhetorical questions** to structure content: - > "How should we shape that? What should the products that we use feel like?" - > "Are you still staring at the agent while the code flies by?" - > "Really, why can't I talk to my agent and have it design the whole loop for me?" ## Audience Engagement Techniques - **Direct address and gratitude** — recurring acknowledgment of the audience's role: - > "So, yes, that's all of you." - > "I would say it's safe to say that we, Codex and actually the entire industry wouldn't be here without you." - **Interactive moments**: - > "can I get a show of hands? Who who is familiar with this kind of sight in offices?" - > "I want to give a shout-out to whoever over there is injecting energy." - **Referencing named community members** (Theo, Toma/Demilyan, Paul) to ground claims in real people. ## Personal Anecdotes as Evidence A stable pattern across speakers — personal stories used as proof points: - Alexander on live demos: > "I only do live demos, so I never know what's actually going to happen each time." - Peter's workflow history: > "I was juggling 10 or more terminal windows… Today, it feels a little bit silly." ## Isolated Moments vs. Stable Patterns - **Stable**: "you know" filler, "we can't wait," analogy-based teaching, numbered enumeration, audience gratitude. - **Isolated/uncertain**: Peter's staccato, aphoristic closing style (> "The future is not 20 terminals. It's better loops.") appears only once — insufficient repetition to call it a habit. - **Uncertainty note**: Speaker attribution in the transcript relies on `>>` markers and context; some hand-offs (e.g., around the 5.6 model pricing section) are ambiguous, so per-speaker pattern claims are kept general. # Position Extractor: The Golden Age of AI Engineering (OpenAI) ## Speakers - **Romain Huet** — OpenAI - **Alexander Embiricos** — OpenAI - **Peter Steinberger** — OpenAI, guest speaker ("the claw father") --- ## Opening: Engineering Is Not Ending **Speakers:** Romain and Alexander (jointly) - Analogy to the **World's Fair**: the future was made visible by building it in public; this event has "the exact same energy." - **Claim:** Contrary to the argument that engineers will disappear because coding is abstracted away, the opposite is true: > "Software ate the world. And then AI ate software. But now... the AI engineers are eating the world." - **Claim:** This is "the best time to be an engineer" because engineering was never about writing code — it's about **solving problems**, combining science with design, taste, judgement, and imagination. This is "a return to the roots of engineering," not the end. ## Accelerating Technology **Speaker:** Peter (initial section, identified later by name/context) - **Release cadence claim:** OpenAI used to ship a new model roughly every **15 months**; now roughly every **6 weeks**. - Mentioned launch of a preview of the **5.6 series** "last week." - **Trajectory of coding tools** (personal recollection): completions → inline prediction → command-K (no testing) → models testing their work → models taking on long, hard goals to completion. Each phase was "mind-blowing" the first time, then normalized. **Speaker:** Peter (demo anecdotes) - At Dev Day 2024, used o1-preview to build a drone interface from scratch; the model could **not run or verify its own code**, so he had to "cross my fingers" during the live demo. - By Dev Day 2025, models could test their own work, enough to control a live camera and lighting system. **Speaker:** Alexander (regarding Peter) - Refers to Peter as the "demo god"; internally, Peter estimates demos work "three times out of four." ## Product Progress & Codex **Speakers:** Peter and Alexander - Shipped this year (a selection): **Codex app, goal mode, remote** — things that "change how it feels to do work." - **Peter's claim:** Agents can now do any task you can do on your computer — not just coding, but work *before* coding (the "why") and *after* (review, deploy). Connecting agents to those loops is how agents "begin" and "land" more work. - **Alexander/Peter:** OpenAI used Codex to build Codex. - **Product-person perspective (Peter):** Most exciting outcome is **better decisions about what to build** — more prototyping, more time with users. - Thanks given to the audience for feedback; claim that "Codex and actually the entire industry wouldn't be here without you." ## Product Philosophy: Empower, Don't Automate **Speaker:** Peter - **Claim:** For a medium-length computer task with equal time, "the model will do a better job than me for the average task." - Framing via mission: **AGI that benefits all of humanity**. Two questions: 1. How do we set up agents to act in the world (what can they do, where do they run)? 2. How do we use agents — what should the product feel like? - **Position:** "The goal is squarely **not** to automate engineers" but to **maximally empower** them. - **Product shape:** Two modalities — - **Chat**: "Some people think chat is dead. I think chat is underrated." A single entity you can ask anything, anywhere. - **Hands-on collaborative UI** for inspecting, steering, shaping work. - Analogy to working with a team: mostly let teammates "cook"; occasionally dig into the weeds together. Goal: preserve the **feeling of mastery**. - **On the Codex app:** Before launch, he pitched people who said "I will never leave my terminal" — "but actually those people are now using it." Internal pushback existed ("people love the CLI, they love the IDE"); his counter: a CLI can't host a collaborative interface, and in an IDE "the order is wrong" — chat first, dig in when needed. ## Open Ecosystem / Layered Stack **Speaker:** Alexander - **Position:** "Codex cannot be a closed product that only OpenAI can improve." Designed as layers anyone can build on: - **Models via Responses API** — the same API used to build the Codex app; features baked into the API first (e.g., **compaction**). - **Codex harness** — open source; inspectable, forkable; **Agent MD** chosen so other agents can use it; OpenAI models are defaults, not hardcoded — open models usable with the same loop. - **Post-training**: the harness is used in model post-training so models learn tools/environments that are open source. - Example: the **OpenCode team** reused the reference implementation (e.g., examined ChatGPT signing code). - **App server** — open source, "not a community adapter" but the path used for OpenAI's own products (VS Code extension, Codex app). Example: Toma ("Demilyan" on X) built Codex Monitor before the app launched and now works on the team, building Codex for iOS. - **App layer** — extensible primitives: in-app browser, plugins (browser use, computer use built as plugins); role-specific plugins (data science, design), also open source. - **Claim:** Subscriptions usable across OpenCode, Pi, Droids, OpenClaw, Xcode, JetBrains. - **Key takeaway:** "We're not building one system for OpenAI and a second system that's simplified for developers. At every layer, we actually use the thing that we give to you." ## Value Maxing: Cost, Speed, Parallelism **Speakers:** Peter and Alexander - **Framing:** The goal is "value maxing," not "token maxing." - **Cost efficiency:** - **GPT 5.6 Terra** brings "GPT 5.5 level intelligence at half the cost." - **Luna** beats notable models on evals at **$1/M input, $6/M output** tokens — called "insane value." - Terminal Bench best shown as GPT 5.6 Sol. - **Speed:** - **GPT 5.6 Soul on Cerebras**: frontier intelligence at **750 tokens/second** — "a substantial PR written in like 10 seconds." - Speculation on implications: parallel approaches (5–6) with best-of selection; "feels less like waiting for an AI... more like a coworker showing you results." - **Parallel/cloud execution:** - Observation: people leave laptops open so agents keep working; the goal is to shut computers and run tasks in parallel, isolated, on their own boxes. - Codex Cloud was the first major launch; major upgrades "coming soon." - **Position:** "The future shouldn't have this awkward distinction between a local task and a cloud task" — the agent should figure out the right environment. - **On a prediction by Theo** (tweet referenced, not quoted verbatim): Alexander's view — the "vibe" of the tweet will arrive "much sooner than 6 months"; Romain would "not be surprised if it's sooner." ## Peter Steinberger: Managing Managers, Attention as Bottleneck **Speaker:** Peter Steinberger - **Evolution of his workflow:** - January: juggling 10+ terminal windows — felt like peak productivity, now "silly." > "I thought I was orchestrating. Really, I was polling. I was the scheduler, the router, and the memory." - One agent = pairing; 10 terminals = "managing 10 direct reports." - Now: talks to a **long-running manager** that delegates to a team; pairs directly only for tricky work. "I manage the manager of a small company of agents." - **Three enabling changes:** server-side compaction (reliable long-running tasks), coordination (one thread creates/steers projects), automation triggers. Together: "persistent context, delegation, and triggers. There's your loop." - **The moving bottleneck:** 1. Tokens — "fixed by joining OpenAI. I know the strategy does not scale." (self-deprecating joke) 2. Compute — MacBook "sounding like a jet engine"; fixed with test boxes on separate machines. 3. **Attention** — current constraint; cannot be added. "The most important skill today is deciding where to spend it." - **Claim about watching agents:** With earlier models, watching and steering mid-generation (escape, redirect) was necessary; the latest models understand intent well enough that watching code generation "is a little bit of a waste of time." - **Described loop example:** Issue filed → manager wakes, evaluates against project goals/vision → creates worker → worker implements, tests → another agent reviews → returns PR with diff, video, or VNC-accessible build → Peter reviews once, approves, loop lands. > "The agent runs the inner execution loop. I set the direction and I make decisions in the outer loop." - **Paul Thought** example: pinned chief-of-staff agent wakes every 10 minutes, coordinates GitHub work, creates sidebar threads for steering. - **Unsolved tensions / open problems (preserved):** - Long-lived managers shouldn't be tied to a laptop. Codex can move work between hosts; OpenClaw has a gateway and nodes — "neither feels like the final form." - He doesn't want to think about *where* he works; the agent should connect to any machine and know what runs locally vs. cloud. - The manager "shouldn't be a session trapped inside your app" — text, Slack, anywhere. - "Why can't I talk to my agent and have it design the whole loop for me? **We haven't solved that yet.**" - **Closing claim:** Models are advancing faster than harnesses and organizations around them; designing those is the next engineering problem — for the audience. > "The future is not 20 terminals. It's better loops. Let's build them." --- ## Unresolved Tensions (as expressed) - Local vs. cloud execution distinction persists today but is framed as transitional ("awkward"). - Attention as a human bottleneck with no scaling solution — only allocation decisions. - Agent harnesses and organizational structures lag behind model capabilities (explicitly unsolved). - Chat vs. hands-on modality is a "beginning," not a settled product form. # Speaker Attribution Record ## Video Metadata - **Title:** The Golden Age of AI Engineering — Alexander Embiricos & Romain Huet & Peter Steinberger, OpenAI - **Video ID:** `01a15ca8-ae93-7dfb-aee1-18d2c0572553` - **Format:** Live conference keynote with three presenters (appears to be an AI engineering event / "AI Engineer" conference; no curated metadata supplied) ## Identified Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | **Romain** (Romain Huet) | **Co-presenter / OpenAI representative** | Self-introduces: "I'm Romain." Delivers opening remarks, discusses value/maxing, cost efficiency, model speeds, Cerebras | | **Alexander** ("Alex", Alexander Embiricos) | **Co-presenter / OpenAI representative** | Self-introduces: "I'm Alexander." Discusses model shipping cadence, Codex app, product philosophy, "demo god" anecdote about Romain | | **Peter Steinberger** | **Guest speaker ("the claw father")** | Introduced as "a special guest who has bent what's possible with agents"; states "Thanks, Al" upon taking stage; delivers segment on agent orchestration, loops, attention constraints | | Audience / unnamed participants | **Attendees** | Applause, laughter, show-of-hands moments; no named contributions | ### Speaker Delineation Notes - Attribution between Romain and Alexander relies on contextual cues in the transcript (e.g., Alexander referenced as "he only does live demos" / "demo god"; Peter greets "Al"). - Some `\>\>` speaker-turn markers are ambiguous where turns are not verbally self-identified; individual attribution of certain overlapping segments is **uncertain**. ## Third-Party Claims / Named External Parties - **Homan** — referenced via "Homan's predicted score" on screen; present ("I hope I'm right") but no speaking role attributed. - **Theo** — cited for "a prediction over the weekend" tweet; discussed, not present. - **Paul (Paul thought / "Paul")** — described as running a chief-of-staff agent loop waking every 10 minutes; discussed by Peter, not present. - **Toma (aka Demilyan on X)** — cited as community developer of Codex Monitor and Codex for iOS team member. - **Open Code team** — cited as forking/inspecting the Codex harness. - **Cerebras** — named as infrastructure for GPT 5.6 speed claim. ## Product / Promotional Segments ⚠️ - **Product showcases (OpenAI products):** Codex app, Codex Cloud, goal mode, Codex for iOS, Responses API, compaction, app server, plugins, GPT 5.6 model family (Sol, Terra, Luna), GPT 5.5, GPT 5.3 Spark, Agent MD, AGENTS.MD. - **Promotional/launch framing:** "Last week we launched a preview of the 5.6 series"; pricing claims ($1/$6 per million tokens); speed claims (750 tokens/sec); "We can't wait for you to have it" — repeated launch-promotion language throughout. - **Self-referential ecosystem promotion:** open-source Codex harness, app server, plugins; "We're not building one system for OpenAI and a second system that's simplified for developers." ## Referenced Sources / Evidence Channels - **Benchmarks/evals:** Terminal Bench (referenced by name); unspecified "favorite eval." - **Screenshots/images:** Dev Day 2024 photo, laptop-open office scene, illustrated agent diagram (Codex image gen), shipped-features slide, Theo's tweet on screen. - **Personal anecdotes:** Live demos at Dev Day 2024 (o1 preview drone interface) and Dev Day 2025 (camera/lighting control). - **Mission statement quote:** "AGI that benefits all of humanity" (attributed to OpenAI's mission). ## Unavailable / Limited Evidence Channels - **No timestamps** in transcript. - **No curated metadata** supplied (no channel, description, or comment data). - **Comment availability:** **Not stated — unknown.** - **Audience size claim** ("over 7,000 AI engineers") is speaker-asserted; independent verification unavailable from source. Good morning, everyone. \>\> I'm Romain. \>\> Hey everyone, I'm Alexander. \>\> Wow, this room is incredible. There's over There's over 7,000 AI engineers here today with us. And you know, it's not just about who's talking about this technology. It's also about who's actually using it and pushing the frontier every day. So, we couldn't be more proud to be here with all of you today. And when we were thinking about this event with Alex, we kept coming back to the World's Fair. And the World's Fair made actually the future visible to everyone by building it in public, you know? Ideas that previously sounded impossible were actually suddenly there. People could see them. They could walk into them. And they could even start to believe in them. And honestly, this event has the exact same energy. The future of engineering is not arriving from somewhere else. It's really being built here by the people in this room and much faster than most expected. And that's why it's a little surprising that people keep saying that engineers are going away. The argument is that coding is, you know, abstracted away and therefore eventually we won't need engineers. Well, in fact, we think it's quite the opposite. You know, software ate the world. And then AI ate software. But now, what we're here to say is that the AI engineers are eating the world. AI engineers are the people here pushing the frontier. Yes. And you all are figuring out how this new capability can reach everyone. And there has never been a better time to be an engineer, in fact, because engineering was never about writing code. Engineering has always been about solving problems for yourself and for other people as well. It's about taking the latest science and combining it with design, with taste, with judgement, and most of all, imagination to make something that people can actually use. And in that sense, it's not the end of engineering. We think it's a return to the roots of engineering. \>\> And the technology we're building on is accelerating, getting faster and faster. For example, we used to ship a new model every 15 months or so, and now it's about roughly every 6 weeks. And in case you missed it, last week we launched a preview of the 5.6 series, and we're super excited to get into all of your hands. Now, building on top of all these models, the rate of product progress is relentless. And as a result, I don't have to tell you and the engineering feels completely different. So, just to go over a couple years of what for me were successive like mind-blowing experiences. You know, obviously for a long time we've had, you know, completion, and then we went to inline prediction, and then finally we had then we had command K where you could ask model to make a change, but they wouldn't test the work. Then models started testing the work, and now we have models taking on long, hard goals until they're done. And for me, each of these phases, I remember the first time was just mind-blowing, and then obviously afterwards you just get used to it and you're trying to get your work done. \>\> Yeah, in fact like I can't believe that build and test loop was not even part of the models just 2 years ago. This was a picture of me at Dev Day 2024, and I used 01 in preview at the time to build a mini drone in drone interface from scratch. And the slightly insane part is the model could not actually run the code or verify its own work, and I knew the demo would work most of the time, but surely not all of the time. So, I had to cross my fingers. You can kind of see here that I was pretty nervous, but hey, that's me. I only do live demos, so I never know what's actually going to happen each time. Luckily, it did work, and by Dev Day of last year in 2025, I was confident enough now the models could test their own work to kind of control an entire camera system and lighting system live. But yeah, we've come a long way. \>\> Yeah, so we refer to him as the demo god and you know, before the demo like I'll ask him so hey, how often does demo work? He'll be like, you know, three times out of four and we're all right, good luck. Um, obviously we've come miles since then and this year alone has been crazy. So, what we're putting up here are all the things that we've shipped so far. Not actually not even all, a selection of the things that we've shipped so far this year. Uh, my favorite things that we've shipped are like Codex app, goal mode, remote. These are things that really changes how it feels to do work. \>\> You know, obviously we couldn't do these things if we didn't use Codex to build Codex, but I think to me what is most interesting is that now Codex can do and agents can do any task that you can do on your own computer. And so, that means they're not just helping you with the coding, but they're helping you with what happens before the coding and they're helping you with what happens after the coding. And this is really key, right? I think there's been a lot of talk, there will be a lot of talk today about loops and if you can connect the agent to not only the work that you have to do, but why it has to be done, that's how you can get the agent to start to begin much more work. And then if you can connect it to what you do afterwards, review and deploy, that's how you help it land much more work. So, with all of this, of course we can move much faster, but to me as a product person, the most exciting thing is actually that we make better decisions around what to build. For instance, we try, we prototype many more ideas and we spend much more time with users. So, yes, that's all of you. So, wanted to pause and just give you all a big thank you both for the love and the constructive feedback. I would say it's safe to say that we, Codex and actually the entire industry wouldn't be here without you. \>\> Yeah, thank you so much for all the feedback. We're constantly listening to all of you. Thank you. \>\> \[applause\] \>\> Okay. So, the models are getting really good. I would say, if you pick like a medium length computer task and you give me and the model the same amount of time to get that task done, probably at least in my case, the model will do a better job than me for the average task. And so, okay, we're we're getting these models, you know, in some ways they're smarter than us. They can do almost anything. How should we shape that? What should the products that we use feel like? And so, to answer that, we look to our mission. The part of it here that I've got up is, you know, AGI that benefits all of humanity. And I think in order to do this, there are two main questions that I think about now. One is, how do we set up the agents to actually do things in the world? So, what can they do? You know, gradually agents are getting connected to more and more things. Then where do they run? More on that later. And then the other question is, how do we use these agents? For us, you know, what what should the product feel like around them? And for us, the goal is squarely not to automate engineers. Instead, the the product shape that we want is one that maximally empowers engineers. So, you know, if we think about what that product shape is, we actually think it's pretty simple. I I read a lot of sci-fi, and you know, watch superhero movies. And I actually think that the the simple ideas in there are approximately right. So, there are two modalities, roughly. Chat. I actually think I know some people think chat is dead. I think chat is underrated. Uh and some kind of hands-on experience. So, what you want is a single entity that you can ask for help with anything, anywhere. And then you want a a powerful collaborative UI that you can use when you want to inspect, steer, or shape things yourself. And so, I had Codex image gen me an illustration of this to help understand when you might want to use these things. And so, my analogy for you, yeah, I hope you like the image gen. Uh my analogy for you would be it's just like working with a team. Most of the time, you're just talking about stuff, and your team is just doing stuff. You don't actually want to watch over the shoulder, or like have to walk over to the workbench of your teammate for every single unit of work. Mostly, you just want to talk and let them cook. And then every now and then, you want to dig in and really dig in all the way to the weeds of things, and dig digging that problem together. And for us, as we build product, we have this idea that we want to make it so that you can retain this feeling of mastery of the work that we're doing, because that's really powerful. We don't want to make it feel like actually it's really hard to like get to the details and like, you know, disassemble the hardware in this case. So, the way that we're bringing to this to life is just the beginning, but this is why we built the Codex app. You get a very simple chat interface that you can use for coding and for anything else. And you know, you can have a conversation and then go deep as you want. So, in the case here, we have Homan's predicted score of this upcoming World Cup match. \>\> I hope I'm right. I hope I'm right. We'll see. \>\> \[laughter\] \>\> Okay. Um and what you can do here is you could go in and you can point at a very specific thing and say, "Hey, I want you to make this change." Or you can make this change yourself. And a fun story here is that actually I remember pitching some of you who I know are in the audience uh this idea before we started and I was told squarely like, "We I will never use such a tool. I will never leave my terminal." Uh or Vim or Emacs. Um but actually those people are now using it. And even internally like within our team, there were a lot of questions like, "Why should we build this? People love the CLI, they love the IDE." And it's a little subtle, but our take is that you can't really build that collaborative interface for any kind of work in a CLI. It's mostly chat. And then in an IDE, the order is wrong and so you're starting with the code, but now it's time to transition to like working with teammates where you chat first and you dig in when you need it. \>\> Totally. And we're moving really fast on this, on the product surface and the model layer, of course, but we're also trying to keep pace with all of you, right? Honestly, half the time I open X, I see someone in this room doing something that I had not realized Codex could actually do. And honestly, this is what pioneers do. You guys experiment, you set up tools for yourself, for your team, and in turn, we get inspired. We learn from you and eventually everyone benefits. And so we are helping uh uh you are helping us figure out like what to uh what to build next and also what the future of engineering should look like. But for that to work, one thing that we we really care about is that Codex cannot be a closed product that only OpenAI can improve. So we've intentionally designed Codex as a set of layers that anyone can build on. And we want to show you a little bit of that stack today and how it it manifests. First, it starts with the model and Alexander showed how quickly we're progressing on models. And you guys use these models through the responses API and guess what? This is how we built the Codex app, right? We use the same models and through the same API. We actually are building on the same thing that we give to developers. And when Codex needs something new, we always try to bake it into the API first so you can benefit as well. One example recently was compaction. Codex needed a way to compact long contexts for long-running tasks and so we'll build that into the API. So that means your agents can use the same primitives that we built for ourselves. Moving on to the next layer, the Codex harness is also open source so you can inspect it, you can fork it, you can adapt it. And we also took the same approach with Agent MD. Instead of reinventing a new file format for Codex for to follow instructions, we thought let's pick a name that other agents can actually use as well. The models are hard to default in the in the harness the models from OpenAI but they're not hard coded in there. So if you want to use an open model and keep the same agent loop, you can. And we also bring this Codex harness into the post-training process of our models. So that means the models can learn to call tools and navigate an environment that's actually something that's open source. Now take the open code team for instance. They actually were able to inspect how we have this like reference implementation and they could reuse the parts that make sense to them or change entirely all the rest and make different choices. I know for instance they were trying to see how we did like signing with ChatGPT and so they could look at the code and and and learn from it. And we think it's better than having developers reverse engineering how it builds what and and how we launch. But now let's say, speaking of subscriptions, that we want to go a level higher. And how you bring this harness into an app? And how do you let people sign in with their existing Codex subscription, for instance? Well, it turns out we had the same problem ourselves, cuz we wanted to build a VS Code extension and the Codex app. And we wanted to have a unified way to like actually control this harness. So we built app server, and we also made that open source. And the app server is not kind of a community adapter, it's really the path that we use for our own products. And you can use it, too. Toma, for instance, here, aka Demilyan on X, he built his own native app for Codex, called Codex Monitor, before we even launched the Codex app. Cuz he could build that using the app server. And now he works on our team, and he actually built Codex for iOS. And moving up the stack, at the app layer, we also want to make sure that innovation is not blocked on our own ideas. And so we built extensible primitives here, like the in-app browser that we showed on the screen, and plugins. So if you take, for instance, browser use and computer use, these were built as plugins using the exact same extension points that we have available for for all of you. And lastly, we also recently built role-specific plugins for Codex, say, to make it easier to to customize for people who work in data science or design, for instance. And these plugins are also open source. You can see under the hood and get inspired from them if that's useful. Our goal is really to keep making this as open and flexible as we can. And the best part is people can use their existing subscription in more and more places, from Open Code, Pi, Droids, Open Claw, to even Xcode and JetBrains as IDEs. And you can see how they're becoming quite a meaningful part of how people use these tools and that's really why we want to care about building this open ecosystem with all of you. So really if there's one thing I want you to take away from this section and this talk, it's this. We're not building one system for Open AI and a second system that's simplified for developers. At every layer, we actually use the thing that we give to you. And we want to thank all of you cuz every time you fork the harness, every time you find the edge of capabilities of the models, it means we get to learn and improve. And honestly, with 7,000 of the finest AI engineers in this room today, I'm confident that all of you will define a lot of how we uh will experience AI and how the world will experience AI in the future. So thank you. \>\> \[applause\] \>\> I want to give a shout-out to whoever over there is injecting energy. That's you, okay, thank you so much. Uh so, with all of your help, we are making agents explosively useful. Uh and so now the question is how do we get value out of them? And you know, that's not token maxing. We have a term for this that maybe you use as well. I don't know, is it on screen? Value maxing. So, you know, when we talk to engineering leaders, most of the conversation is about some themes relating to the idea of value maxing. So, we're going to walk you through a few common topics that come up, some things where we've already made a lot of progress, and some things where actually there's a lot more progress to still be made. So, the first one of these is cost efficiency. Everyone wants frontier intelligence. Pick your favorite eval, you want the best model. So, with terminal bench here for instance, that's GPT 5.6 Sol, and like I said, we can't wait for you to have it. But okay, you also want as much intelligence as you can get, and that's where efficiency comes in. Cost efficiency has been a focus for us for quite some time, and the results are continuing to pay off. So, for example, GPT 5.6 Terra, I think it's in like dark blue in there. Brings GPT 5.5 level intelligence, but at half the cost. And Luna there beats some pretty notable models in this eval. But at only $1 per million input tokens and $6 per million output tokens. I'll leave it up to you to compare those costs, but that is insane value. \>\> Yeah, we we we really can't wait to uh, to see all of you build uh, with GPT 5.6 and this new family of models. Now, the next thing I want to touch on is speed, right? GPT 5.3 could spark showed you what speed can unlock, but we also know that you all want frontier intelligence. You don't want to have a model that's like not as great as what you can operate at the very best. Well, this is GPT 5.6 Soul running on Cerebras, the frontier intelligence at now 750 tokens a second. We can't wait to see what you can build with this next month. And honestly, to put that in perspective, this is kind of like having a pretty substantial PR written in like 10 seconds. And it's not just about getting one answer faster, right? It's about what can you do with that speed? You can think about an agent taking different approaches, maybe like five or six in parallel, maybe like, you know, coming back and picking the best one in the time you would have taken to not even generate just one. So, we really can't wait to see what that can unlock when you have frontier intelligence, the very best at that speed. It really starts to feel less like waiting for an AI to respond and much more like a coworker that's like already showing you the results as it goes. \>\> Speaking of working with coworkers, um, can I get a show of hands? Who who is familiar with this kind of sight in offices? Okay. Okay, wow, a lot of you are very well behaved. I really see some people up front. Um, so yeah, a lot of people are keeping their laptops open so that agents can keep working. And this is funny, but you know, what we really want is to be able to shut our computers um, and we want to be able to run many tasks in parallel isolated on their own box. Now, we've been actually aiming at this from the start. Our first major launch was Codex Cloud, and it is due for some major upgrades coming soon. But, better yet, as we think about this, the future shouldn't have this awkward distinction between like a local task and a cloud task, and you have to decide where to run everything. Really, what you should have is kind of going back to what I was saying earlier. You should just have an agent, you talk to it wherever, whenever, about anything, and it should figure out, okay, what do I need to do, which environment is right for my work, and use whatever is available. \>\> In fact, Theo made this prediction over the weekend on this very topic. And it's a pretty acute tweet. Like, Alex, what do you think? Sooner or later than 6 months? \>\> I think the not in maybe not exact details, but the vibe of this tweet much sooner than 6 months. \>\> Yeah, I mean, at at the pace at which everything is going is going, I would not be surprised if it's sooner indeed. Um, Well, so now, you might be wondering, where's the live demo today? Uh, well, for this AI engineer, we wanted to do something a little different this time around. And we think it's a very unique moment for all of us to kind of reimagine how we work and how we build. And so, we wanted to bring a special guest who has bent what's possible with agents and really has pushed us to be more AGI pilled uh at OpenAI. So, with that, please welcome to the stage the claw father, Peter Steinberger. \>\> \[applause\] \>\> Peter, take it away. Thank you all. \>\> Thanks, Al. \>\> Good morning, everyone. You know, I love this picture because it reminds me just how much has changed in a few months. I was juggling 10 or more terminal windows, always waiting for one of them to finish, so I could steal the agent and queue new work. In In January, that felt like peak productivity. Today, it feels a little bit silly. I thought I was orchestrating. Really, I was polling. I was the scheduler, the router, and the memory. You know, at first, I paired with one agent. With 10 terminals, I was no longer pairing. I was managing 10 direct reports. Now, I mostly talk to a long-running manager, which delegates work to a team. For tricky work, I can still drop down and pair directly with a worker, but my default changed. I manage the manager of a small company of agents. Three changes made it possible. Number one, server-side compaction made long-running tasks reliable enough that I stopped optimizing around first sessions. Coordination lets one thread create and steer the right projects. And third, automation can wake the same manager when something happens. So, we have persistent context, delegation, and triggers. There's your loop. And once the loop starts working, you discover the next problem, the bottleneck keeps moving. You know, last year, I was primarily constrained by tokens. Now, I fixed that by joining OpenAI. I know I know the strategy does not scale. Then, my constraint shifted to token uh compute. All these threads run at the same time, and my MacBook starts sounding like a jet engine. That's mostly fixed by using test boxes. So, agents can run tests on a separate machine. Now, I'm primarily constrained by attention. And unlike tokens or compute, I can't simply add more of it. So, the most important skill is today is deciding where to spend it. Are you still staring at the agent while the code flies by? I know I know it's it's it feels cool, but with the earlier models, this was necessary. You know, you you you you see the agent go in a direction you don't like, you hit escape, you steer it, you steer it back. But, the latest generation of models is so good at understanding intent that it's a little bit of a waste of time to watch the agent generate code. Imagine someone files an issue on one of my open source projects. The manager wakes up, reads it against the project's goals, notes, and vision, and decides whether it might be a fit. If it does, it creates a worker. That worker investigates, implements the change, runs the tests, and another agent can review the result. I don't need to watch those agents work or consume every intermediary message. When the manager needs me, it returns a PR, the original issue, the proposed diff, maybe a video, or even a running build I can VNC into. I review once, I leave a note, I maybe approve, the loop continues, and it can land after the checks pass. The agent runs the inner execution loop. I set the direction and I make decisions in the outer loop. You know, Paul Paul thought he's already running a version of this. He pinned his chief of staff. It wakes up every 10 minutes and it coordinates his GitHub work. The agent creates threads in the sidebar so Paul can jump in whenever the work needs additional steering. You know, once the manager is long-lived tying it to a laptop just feels wrong. Codex can already move work between hosts. Open claw has a gateway and nodes. But neither feels like the final form. I don't even want to think where I work. My agent should be able to connect to any of my machines. They should know which work can be done in the cloud or which work requires my local machine. The manager shouldn't be a session trapped inside your app. It should be an agent that I can text, steer from Slack, or hear from wherever I am. Really, why can't I talk to my agent and have it design the whole loop for me? We haven't solved that yet. Models are advancing faster than the harnesses and organizations around them. Designing those things is the next engineering problem. That's where all of you come in. The future is not 20 terminals. It's better loops. Let's build them. Thank you. \>\> Thank you.