A conference talk titled Cooking with Codex, presented by Charlie Guo and Gabriel Chua of OpenAI, showing how OpenAI Codex is used for software development. Per the description, the presenters demonstrate building a macOS live translation app from a Slack conversation, turning repository history into a shareable site about the Agents SDK, generating a repository visualization, exporting dashboard data via computer use, and building a Google feedback form through the Chrome extension. They discuss browser control for local testing versus access to signed-in applications. Longer project examples include a live Q&A site, an internal form builder adapted from an existing repository, and a Python package with a Rust backend reconstructed from research papers. Topics covered include goals with verifiable completion criteria, subagents, visible threads, audits, progress dashboards, remote threads, hooks for deterministic checks, automations, and a custom interface called Retrodex that demonstrates App Server integration. The central question is how to turn a successful individual request into a repeatable process with useful checks and human input. These are the creator's described demonstrations; the record does not independently verify outcomes. # Channel Presentation Observations: Cooking with Codex ## Source Scope - **Video ID:** 01a15ca6-eb42-7907-99cc-6eecfc104ccf - **Title:** "Cooking with Codex — Charlie Guo & Gabriel Chua, OpenAI" - **Metadata:** None supplied beyond title and transcript. - **Format observed:** A live workshop recording with two presenters, both identified in the transcript as members of the OpenAI developer experience team. --- ## 1. Explicit Self-Description These are statements the presenters make about themselves or the session. They are self-description, not channel-level claims. - **Speaker identity:** Charlie introduces himself as "on the developer experience team at OpenAI." Gabriel says he is "also on the developer experience team, flying in from Singapore." - **Session framing:** Charlie calls it "the cooking with Codeex workshop." Gabriel says, "this is a cooking show." - **Audience framing:** Charlie addresses the room as "power users": > "I'm pretty sure this AI engineers welfare. We're in a room full of power users." - **Session purpose:** The presenters state they want to "help you cook really fast and cook something really cool." --- ## 2. Intended Audience The transcript shows a mixed audience but a clear orientation toward experienced builders. ### Primary audience (as addressed) - **Power users and developers** attending an AI engineering conference. Evidence: the "power users in the room" remark and the explicit reference to "AI engineers" conference context. - **Developers who build products** on top of Codex. Evidence: a section on embedding Codex via the app server "into your product or in your own internal platforms." ### Secondary audience (as addressed) - **Newcomers to Codex.** Evidence: > "if it's your first time sort of using codeex uh do check it out. Do give it a download." ### Audience-facing practices - Live audience participation: Charlie asks for German speakers ("I understand there's some German speakers in the room"). - A second-hour hackathon is announced, with presenters described as "sue chef to your main chef." - Swag and API/Codex credits are offered to attendees. --- ## 3. Claimed Scope The presenters describe the session as covering a broad range of Codex capabilities. The stated structure: - **What's new** (record and replay, thread handoff, mobile GA, device pairing) - **Six steps to cooking with Codex:** 1. Give Codex context 2. Build things 3. Take action (computer use) 4. Collaborate on long-running tasks 5. Work over time (automations) 6. Bring Codex everywhere (app server / embedding) - **Closing thoughts** and a planned hackathon. The presenters frame the session as "a whirlwind tour" and say a follow-up workshop will "go through the step by steps." --- ## 4. Demonstrated Presentation Patterns These are observable features of how the material is presented. They describe this video only. ### Live product demonstration - Most segments are **live demos** of Codex features, with the presenters narrating actions in real time. - Demos include building a real-time translator, generating a Sites page, a Codex remote session driven from a phone, a computer-use download task, and a Google Drive feedback form creation. ### Food and cooking metaphor - The entire presentation uses cooking vocabulary: "cooking show," "recipes," "ingredients," "sous chef," "fresh from the oven," "taste test." - Example quote: > "And these are the six steps to cooking with CEX." ### Conversational and informal delivery - Frequent asides and humor ("Yeah, cooking show is over. No, I'm kidding.") and self-deprecation ("I'm a data scientist by training. Not very... the best at like sort of working with like web RTC websockets."). ### Heavy use of the company's own product and ecosystem - Repeated references to OpenAI products and internal use: Codex app, ChatGPT mobile app, Sites, the Agents SDK, the OpenAI developers plugin, and the app server. - Statements about internal practice, such as: > "At OpenAI, we've been using sites extensively." ### Vendor-positioned claims - Several capability assertions are made by the presenters about their own product, for example: > "Codex really good at like complex refactors, longunning tasks." > "Reasoning models are really intelligent..." - Quoted third-party praise is included as supporting evidence: > "this individual from Japan said like in fact codeex has strong compaction." --- ## 5. Distinguishing Claims from Demonstrations | Type | Examples from the transcript | |---|---| | **Creator claim (about product)** | "90 plus% of the time it can figure out the right thing to do." | | **Creator claim (about product)** | "Codex is really good at like complex refactors." | | **Demonstrated on stage** | Live Mac OS translation app built and run during the session (with audio troubleshooting shown). | | **Demonstrated on stage** | Computer-use task downloading commit and PR data while the presenter's hands were off the keyboard. | | **Demonstrated on stage** | Remote session triggered from a mobile app and a Codex-generated site. | | **Stated but not shown** | The "Chronicle" memory feature for Pro subscribers is described; the presenter notes they are on a Business plan, so it was not demonstrated. | Note: The 90%+ success figure is a presenter's stated estimate, not a measured result shown in the material. --- ## 6. Self-Check Notes - All observations above cite transcript passages or describe them directly. - No private motives of the presenters were inferred. - No channel-wide conclusions are drawn. These observations apply only to this single workshop recording. - Organizational affiliation (OpenAI) is stated by the presenters and by the video title; it was not independently verified. # Delivery Observations: "Cooking with Codex" Workshop ## Scope and Source Limits - **Source:** Title and auto-style transcript only. No curated metadata was supplied, so delivery context is limited to what the transcript shows. - **Speakers:** Two presenters. Charlie and Gabriel (Gabe) introduce themselves by name, and later stage handoffs ("I'll let Charlie...") support attribution. Speaker turns are marked only by ">>" in places, so attribution for unmarked passages is inferred and may be imperfect. - **Transcript quality:** Some words are garbled ("Codeex," "codecs," "sub aents," "Codex max"), and bracketed numbers appear throughout. Their meaning is unclear, so this document does not cite them as timestamps. --- ## 1. Tone and Register ### 1.1 Conversational, informal, and playful Both speakers keep an informal register with humor and light self-deprecation, even when describing technical features. - Self-aware joke during a demo: > "Hey, can you just build this? Yeah, cooking show is over. No, I'm kidding." - Acknowledging demo risk: > "You know it's a real demo, live demo when you got to do it on stage. It's real." - Teasing about the format: > "It is a cooking show." ### 1.2 Enthusiastic superlatives, used frequently Positive intensifiers recur across the session, usually paired with "really" or "pretty." - "really really cool stuff" - "Some of it pretty pretty incredible." - "It's pretty nice." - "It's really useful." Observation: the enthusiasm is consistent across both speakers and across sections, but it is applied to features in general rather than tied to specific claims, so it carries limited evidential weight. ### 1.3 Candid admissions of uncertainty during demos Presenters openly flag inexperience or imperfect setup. > "I've never built a Mac OS app." > "I'm a data scientist by training. Not very not the best at like sort of working with like web RTC websockets." > "So this is like we don't know how this is going to taste." --- ## 2. Vocabulary and Recurring Phrases ### 2.1 Cooking and kitchen metaphor (highly recurrent) The entire session is framed as a cooking show. Terms repeat throughout: *ingredients*, *recipes*, *dish*, *chef*, *kitchen*, *taste test*, *fresh from the oven*, *cook*. > "So what's new? What's fresh from the oven?" > "It's a bit like having that uh you know sue chef like double check everything." > "...with the sort of ingredients we're going to share with you some of the recipes..." The metaphor is structural (the "six steps" are framed as a recipe), not just decorative. ### 2.2 "Magic" and "magical" (recurrent evaluative word) > "It's like pretty magical the first time you see it." > "it is insanely magical." > "it's still just so magical to watch those little cursors fly around." > "It can be a really magical experience..." Observation: this word is used to describe experiential reactions to demos and features, appearing at least four times across both speakers. ### 2.3 "For exposition purposes" (recurring framing device) Used to signal that a demo step is being done differently from how it would be in practice. > "Uh here I'm being particularly prosaic in the prompt for exposition purposes." > "for exposition purposes, what we're using here is the Chrome extension..." > "for exposition purposes here we are like prompting and like being more methodical but in reality you can just like let codeex work on it..." ### 2.4 "Bit like" analogies Analogies are used to make features concrete: > "it's a bit like a mag." > "I think that's a bit like that." > "Maybe you're building something... it's a bit like that software factory..." ### 2.5 "It's 2026" framing Used as a framing device for the pace of change: > "So, it's it's been 2026. This slide barely summarizes everything we've shipped..." > "So it's 2026. Um we're not going to go to the developer platform and click uh create API key..." ### 2.6 "Fingers crossed" (live-demo hedge) > "All right, fingers crossed. This is a live app." > "And fingers really fingers crossed." ### 2.7 Filler and discourse markers Common fillers and discourse markers appear throughout, including: - **Fillers:** "uh," "um," "like," "you know" - **Tag questions:** "right?" and "right," e.g., "We might be, you know, on the beach... but we still want to get work done." and "Gabe mentioned we might be out in the world, right?" - **Repetitive hedges:** "I think" appears very frequently, sometimes doubled, e.g., "I think I think I would add to that..." --- ## 3. Teaching and Presentation Habits ### 3.1 Explicit signposting and agendas Both speakers announce structure up front and reference it later. > "There's a quick agenda. We're going to talk about what's new and then the real pun intended meat of the session is the six ways to cook with codeex." > "So to recap, uh part one, right, we want to give codecs context." > "to summarize on the complex task, we had three different projects." ### 3.2 Numbered, sequential framing The content is organized into numbered steps, stated explicitly: > "these are the six steps to cooking with CEX. Number one you got to give Codex your context." Later sections explicitly reference "the first two steps," "the next four steps," and "the first one is computer use." ### 3.3 Recap-heavy structure Recaps appear at the end of nearly every major section, usually introduced with "So to recap" or "to summarize" and often delivered by the other presenter. This repeated recap pattern is one of the most consistent structural habits in the transcript. ### 3.4 Demo-first, narrate-as-you-go style Presenters narrate live actions in real time, often describing what is happening on screen while waiting: > "So let's see what Codex can do." > "So ah there it is. You see it again. My cursor is here and then you see the blue ones here." > "So let's go let's do German and let's just make sure the audio is working as well." ### 3.5 Explanation through contrast Concepts are often explained by contrasting two approaches: > "So one thing is that context is not just about best practices or external information." > "the Chrome extension... is the most useful for when you need to hand off um state or authorization to the agent." > "...computer use... really shines when you have applications that otherwise don't have a programmatic interface to them." ### 3.6 Hands-off handoffs between speakers The presenters pass the stage with consistent wording: > "So I'll let Charlie uh take the stage here." > "I'll let Charlie uh sort of summarize our first two dishes of the day." > "I'll let Charlie just really give a nice summary of what where the different flavors are." ### 3.7 Concrete, personal anecdote as an illustrative device Personal use cases anchor abstract features: - Weekend IKEA furniture manual as a visualization prompt. - Managing "Slack, Gmail, linear" for daily agendas. - Dictation as "a really underutilized feature because we speak so much faster than we can type, right?" --- ## 4. Communication Patterns ### 4.1 Explicit prompt-clarity messaging A recurring instructional point is that clear, direct instruction matters more than special phrasing: > "I think one misconception these days is like people always ask does prompt engineering matter? In so far as the instructions are clear, it still matters. Like I can't read your mind. Codex can't read your mind." > "So you just need to tell Codex very clearly what you want." ### 4.2 Verifiability emphasis Success criteria are repeatedly framed as needing to be verifiable: > "one of the biggest things that I tell people who are just trying it out for the first time is be really specific with the criteria that you're giving the model to to know when it's done." ### 4.3 Collaborative turn-taking and affirmation The two presenters build on each other's points with brief affirmations and additions: > "I think I think I would add to that..." > "Yeah, thanks Gabe." > "Got it. Cool." ### 4.4 Self-reflection on process Presenters describe their own workflow with first-person reflection: > "in giving the app context, a lot of times I will work through a difficult problem or a workflow that you know I'm not sure how I wasn't sure before how to tell Codeex how to do it." --- ## 5. Stable-Looking Patterns vs. Isolated Moments **Stable-looking patterns (repeated across multiple sections):** - Cooking and kitchen metaphors throughout. - "For exposition purposes" framing used at least three times. - Explicit signposting, numbered steps, and recaps. - Frequent "I think" hedging and "right?" tag questions. - The word "magical" used across several demos. - Explicit stage handoffs using the same wording. **Isolated moments (appear once or are context-specific):** - The pirate-reply custom instruction example. - The "monkey's paw" reference to goal behavior (transcribed as "monkeykey's paw"). - The "Oops." during a demo. - The "Mic test" and audio troubleshooting exchanges. - The data scientist disclosure. **Uncertainty:** With one transcript and no metadata, it is not possible to confirm whether these patterns are typical of either presenter beyond this session. The sample is a single live workshop, so patterns here describe this delivery only. # Observation Record: "Cooking with Codex" Workshop **Source:** Video `01a15ca6-eb42-7907-99cc-6eecfc104ccf` **Title:** Cooking with Codex — Charlie Guo & Gabriel Chua, OpenAI **Speaker attribution basis:** Transcript only. Speakers are identified by the introductions in the transcript ("my name is Charlie," "my name is Gabriel"). Where the transcript does not clearly indicate which speaker made a statement, this record says so. --- ## 1. Session Framing ### 1.1 Stated Purpose - **Charlie** (self-identified as on the developer experience team at OpenAI) and **Gabriel / "Gabe"** (self-identified as also on the developer experience team, speaking from Singapore) present a workshop on using Codex. - The stated agenda: review of what's new, "six ways to cook with Codex," closing thoughts, then a mini hackathon in the second hour. ### 1.2 Stated Framing Metaphor - The session uses a cooking metaphor throughout. The **six steps** are presented as "recipes" or "ingredients." - Quoted from the presenters: *"Anyone can cook but only the fearless can be great"* (attributed to the film *Ratatouille*). --- ## 2. What's New (as described by the presenters) - **Record and replay:** Described as building on computer-use technology. Lets users show Codex a sequence rather than describe it. - **Thread handoff:** Described as moving work between cloud, remote, and local. - **Mobile app:** Described as now generally available, with one-to-one device pairing. - **Plugins, computer use, multimodality, mobile, and app shots** are listed as shipped features. Charlie describes app shots as a "personal favorite." - Gabe states that "this slide barely summarizes everything we've shipped" and that the year is "50%" complete. --- ## 3. The Six Steps (Presenter Framework) | Step | Label (as stated) | Presenter | |---|---|---| | 1 | Give Codex your context | Gabe | | 2 | Build things | Gabe | | 3 | Computer use / take action | Charlie | | 4 | Collaborate on long-running tasks | Charlie | | 5 | Working over time (automations, hooks) | Gabe, Charlie | | 6 | Bring Codex everywhere (embedding, app server) | Charlie | > Gabe frames the sequence as: "Number one you got to give Codex your context... And that's already just a step two." --- ## 4. Step-by-Step Claims ### 4.1 Context (Step 1) — Gabe **Claims:** - Context exists in "documents, in your brain, in your conversations, in your email, in notion, linear, so forth." - **App shots** (a screenshot that embeds text) are presented as a way to pass conversational and visual context without retyping. Gabe describes his own use of Command-based capture as a convenient input method. - **Plugins** for external sources (Slack, Gmail, Linear, etc.) are presented as bringing context in. **Stated reasoning:** Context reduces the need to "repeat yourself." ### 4.2 Building (Step 2) — Gabe **Claims:** - Codex can build a real-time translator app as a live demo. Gabe states, "I've never built a Mac OS app, but with the plug-in, all the best practices are there." - Gabe presents a "what's new" site built from the Agents SDK repository, using the **Sites** feature (described as in preview for enterprise and business plans, launched in June). **Qualifications stated during the demo:** - Gabe described the translator build as an untested live demo: *"We don't know how this is going to taste."* - Charlie, during the live demo, noted the audio did not immediately work and asked for a mic test. The demo's live outcome is not verified in the transcript. ### 4.3 Remote Work — Charlie **Claims:** - **Codex remote** is available in the ChatGPT mobile app and lets a user issue commands to a laptop or remote server. - Charlie describes leaving the laptop open while Codex works: *"you can sort of free yourself from having to be at the computer all the time."* - Charlie states he has been doing this "lately," describing it as "100% a thing that I've been doing." - Charlie says the practice is "almost like a regular occurrence" for "everyone" — **this is a generalization from Charlie's own experience and should be read as his characterization.** ### 4.4 Plugins — Charlie and Gabe **Charlie's definition:** Plugins bundle **skills** (best practices, external prompts, team practices), **apps** (configuration and connectivity to external services), and **MCP servers** (tools). **Claims:** - The **built-for-Mac-OS plugin** provides skills on AppKit, Liquid Glass, and signing/inspecting applications. - The **OpenAI developers plugin** can directly create an API key for the user, which Charlie contrasts with manually going to the developer platform: *"pray that you actually saved it somewhere."* **Gabe's addition:** The Codex app can build plugins and skills. He describes a workflow of asking Codex to "make this a skill or even better make this a plugin" after solving a problem, so future work can skip re-deriving it. ### 4.5 Memory and Personalization — Gabe **Claims:** - **Memories** are off by default and can be enabled in settings under personalization. - **Chronicle** is described as a research preview for Pro subscribers, capturing on-screen context. Gabe notes Charlie's account is a Business plan, so Chronicle was not available to him. - **Custom instructions** via an `agents.md` file in the home directory apply to all conversations. Gabe's example: "always reply like a pirate." **Qualifications:** - Gabe says memory generation can be skipped for chats involving tools, "because sometimes the tools might return information that you might not want persisted over time." - Charlie says memories and Chronicle "will use up a little bit more of your token budget." - Charlie characterizes memory as making the app "feel like a true collaborator" and says it can be "a really magical experience." This is an expressed positive assessment, not a measured result. ### 4.6 Dictation and Input Habits — Charlie **Claims:** - Charlie describes dictation as "really underutilized" because "we speak so much faster than we can type." - He states that users no longer need every word correct: *"you can just give it reams and reams of your own rambling."* - Charlie claims that for app shots, "90 plus% of the time it can figure out the right thing to do." **This is an informal, unsourced estimate given in the talk.** ### 4.7 Sites and Artifacts — Gabe and Charlie **Claims:** - Sites create shareable artifacts. Charlie reports using Sites at OpenAI to summarize events and to support offsite planning, where a colleague created a site comparing locations and trade-offs. - Gabe demonstrates `/code review` against uncommitted changes, describing it as "a bit like having that sue chef like double check everything." - Gabe reports an SVG-based image output from a Codex-created example: *"It used SVG but not too bad. Not too bad."* --- ## 5. Computer Use (Step 3) ### 5.1 Flavors Distinguished — Charlie Charlie distinguishes three mechanisms: - **Computer use:** Controls the whole desktop. Charlie says it "shines when you have applications that otherwise don't have a programmatic interface." Mac OS cursor behavior: Charlie states it "doesn't steal your cursor," so the user can keep working. - **Chrome extension:** Uses the user's signed-in browser. Charlie says it is most useful "when you need to hand off state or authorization." He notes that Google can detect headless Chromium and loop on captcha-style prompts. The Chrome extension is described as a "sign-in browser." - **In-app browser:** Described as having deeper hooks into the browser engine than the Chrome extension. Charlie says it is best for building local web apps and deep interaction testing. **This mechanism was not demonstrated in the session**, as Charlie notes. ### 5.2 Demonstrations - Gabe asks Codex to download commit and pull request data from a dashboard. Gabe states: "It's a bit like a mag... pretty magical the first time you see it." The demo was not verified to complete within the transcript. - A feedback-form creation task via the Chrome extension was started and not completed on stage. --- ## 6. Long-Running Tasks (Step 4) — Charlie ### 6.1 Claims About Capability - Charlie states Codex is "really good at like complex refactors, long-running tasks." - Three examples are described: 1. A **green-field live Q&A site** (described as running about 15 hours at the time of recording, with admin, participant, and stage views, and moderation via the moderation API). 2. A **form builder** adapted from an open-source repo, running about 5 hours 57 seconds. 3. A **research-paper reimplementation** as a Python package with a Rust backend, running about 7 hours 1 minute 40 seconds. Charlie said he constrained it away from dynamic programming and toward heuristics. ### 6.2 Prompt Engineering — Charlie - **Claim:** Prompt engineering in the sense of "magic phrases" is no longer necessary. *"I don't think we're in that state anymore."* - **Qualification:** Clarity still matters. *"Codex can't read your mind."* Charlie says "the real thing is about context." - He notes the prompt for the Q&A site was written prosaically "for exposition purposes," and that it was produced by talking to Codex on the phone. ### 6.3 Goals — Charlie - A **goal** is described as a primitive that evaluates itself against user-given success criteria at each turn. - **Stated guidance:** Criteria should be "as verifiable as possible." - **Qualification:** Charlie says goals are "like a genie": "when it works well, it is insanely magical," but "sometimes I feel like I've entered into a monkey's paw type situation" where the model technically completes the task in an unexpected way. - Charlie mentions a goal that ran 40 hours to reimplement Doom in native Swift, attributed to "Tama." ### 6.4 Sub-Agents vs. Thread Handoff — Charlie - **Sub-agents:** Used "when the work primarily needs to be visible to the model." Charlie says sub-agents "keep the context separate." Customizable via a `sub-agents.toml` file, including model choice (lightweight vs. more thorough). - **Thread-to-thread handoff:** Used "when you still want to be in the loop." Charlie describes a "creative director" thread coordinating art, music, animation, and mechanics threads in a game project, with instructions in `agents.md` to get sign-off before a task is considered done. ### 6.5 Hooks — Charlie and Gabe - **Charlie:** Hooks in `config.toml` introduce "deterministic behavior at specific checkpoints." Use cases he names include logging, scanning inputs and outputs, checking for pasted API keys, approving tool calls against an allow-list, and custom validation at turn end. - **Gabe:** Demonstrates a hook that runs a Python script at the end of each turn to tidy the repo. He frames hooks as a guardrail that matters more as autonomy increases. ### 6.6 Communication Between Threads — Charlie - Side threads and the main thread can message each other. Charlie emphasizes that **side threads are ephemeral**: *"if there is any context that you want to keep long-term in your project, make sure you're communicating that back to the main thread because they will get stale after a while."* - Charlie describes a remote thread instructing a local thread to run Chrome QA, which then reports results back. - Slack plugin use: Charlie asks Codex to post summaries and blockers to Slack. He says he checked periodically over a weekend and used the session to unblock tasks. ### 6.7 Compaction — Gabe and Charlie - **Gabe's claim:** Codex natively trained on multiple context windows through **compaction**, introduced with GPT-5.1 Codex Max in November. - Gabe quotes external users stating that compaction "basically solve[d]" the issue and that Codex "only remembers the good stuff." **These are quotes from unnamed or partially identified users and are presented as user testimony, not verified claims.** --- ## 7. Automations and Working Over Time (Step 5) ### 7.1 Heartbeat Automations — Charlie - Heartbeat automations run within a thread on a timer until a condition is met. - Demonstration: provisioning a DigitalOcean droplet, with Codex checking readiness every five minutes. Charlie notes the result was shown as "an example that was already done," not live. ### 7.2 Thread-Spawning Automations — Charlie - Automations can spawn new threads, including worktree threads that address bug reports and open PRs. - Charlie's proposed Slack-based example: classify feedback into compliments, bugs, and feature requests; spawn worktree threads for fixes; request review from a named colleague (Dom). - Charlie describes this as building a "software factory" but does not claim it was completed. ### 7.3 Other Automation Ideas — Gabe and Charlie - **Gabe:** A weekly review automation that examines conversation threads to suggest skills to add or remove. A second automation could cross-validate drafted email replies against the sent replies, which Gabe calls "the ground truth." - **Charlie:** Uses an automation to monitor notifications and update Obsidian daily notes. He notes the Codex app's scheduled page supports threads for recurring recaps. ### 7.4 Cost Note - Charlie: memories and Chronicle "use up a little bit more of your token budget." Automations are not explicitly described as costly in the transcript. --- ## 8. Embedding Codex Anywhere (Step 6) — Charlie - **App server protocol:** Described as the core protocol underpinning the Codex app, CLI, and VS Code extension. - **Claim:** Developers can embed Codex in their product via the app server and let users use their ChatGPT subscription and token budget. Charlie states this "brings the ability for your users to... use their chat GBT subscription." - **Qualification:** Computer use and features requiring local machine access "are... not going to be there" in the app server. - Charlie demonstrates **Retroex**, a custom UI built on the app server during the previous night, which he says shares a session with the Codex app. - Open-source status: the Codex repo is open source; Charlie suggests asking Codex about the repo itself. --- ## 9. Closing Thoughts — Charlie Charlie frames a set of questions he repeatedly asks himself: - "Have I tried asking Codex to do it?" - Moving from single turns to **loops**. He notes "loop maxing" as a term in use. - What blocked Codex: missing context, missing permissions, or missing repeatable tools (skills or plugins). - Scaling from one agent to many, including implicit delegation and orchestration across threads. - **Removing humans from unnecessary steps.** Charlie gives the developers plugin as an example where API key retrieval no longer requires a human. He says "we do still want humans in the loop like where they need to be." - Building a "software factory" versus a single piece of software. --- ## 10. Logistics and Announcements — Gabe and Charlie - Gabe describes the second-day schedule: a keynote, a talk by Jason on daily use, a workshop on plugins and app shots, sessions on the harness, voice agents (Charlie), building on the Codex harness (Dom), and LLM inference in production. - Promotional offer (stated, not verified): **$100 USD in Codex credits and $100 USD in API credits**, with a QR code shown. - Swag (sweatshirts) mentioned for attendees who stay to the end of the build session. --- ## 11. Unresolved Tensions and Caveats | Topic | Tension or caveat stated in the transcript | |---|---| | Live demos | Multiple demos (translator, dashboard download, feedback form) were not confirmed to succeed on stage. | | Memory and Chronicle | Presenters acknowledge a token cost and a safety concern about tool-returned data persisting. | | Goals | Charlie describes unexpected literal compliance ("monkey's paw"). | | Sub-agents | Charlie's delegation boundary (visible to model vs. visible to user) is his own framing. | | Prompt engineering | Charlie says magic phrases are unnecessary, yet also says clarity still matters. | | Compaction | Supporting claims rely on quoted user testimony, not presenter measurement. | | Estimates | "90 plus%" for app shots and similar figures are informal presenter estimates. | | Speaker attribution | Some segments are transcribed without clear speaker markers; attributions above rely on context and self-identification. | --- ## 12. Self-Check - Every claim above is attributed to Charlie or Gabe, or marked as quoted third-party testimony. - Qualifications, disagreements, and unverified demonstrations are preserved. - No private motivations or beliefs are inferred beyond what was stated. - No external facts, timestamps, or sources were added beyond those in the transcript. Duration figures are as stated by the presenters. # Speaker Attribution and Provenance Record ## Video Identification - **Video ID:** 01a15ca6-eb42-7907-99cc-6eecfc104ccf - **Title:** Cooking with Codex — Charlie Guo & Gabriel Chua, OpenAI - **Format:** Live workshop transcript, with audience interaction and live demonstrations - **Curated metadata supplied:** Title only. No speaker bios, cited-source list, or comment-availability information was supplied. --- ## Speakers and Roles ### Primary Speakers - **Charlie** (self-identified as Charlie Guo in the title) - Self-described role: member of the developer experience team at OpenAI - Presents segments on remote sessions, plugins, goals, sub-agents, hooks, automations, and closing thoughts - **Gabriel "Gabe" Chua** (named in the title as Gabriel Chua) - Self-described role: member of the developer experience team at OpenAI, speaking from Singapore - Presents the opening agenda segments on context, building, sites, computer use, and the app server ### Additional Voices - **Unnamed audience members or demo participants** - Brief exchanges during the mic test and live translation demo ("Are you there?", "Are you dead?") - Speaker identity is not established in the transcript - **Unnamed workshop staff or volunteers** - Referenced as "OpenAI staff" present in the audience to answer questions; no speech attributed to them specifically > Speaker turn markers (">>") are present but do not consistently label which named speaker is talking at each boundary. Attribution between Charlie and Gabe for some turns is inferred from self-introduction order and topic handoffs stated in the transcript ("I'll let Charlie...", "I'll let Charlie summarize"). --- ## Named Third Parties Referenced These individuals are mentioned but do not speak in the transcript: - **Christine** — named as a participant in the brainstorming of the demo idea - **Dom** — referenced in demo tasks (review and approval of a PR) and in a comment about a possible record of building; a speculative line ("I think Dom might have") is noted but not confirmed - **Brent** — referenced as using Codex for video editing with Premiere - **Jason** — referenced as presenting a later talk and workshop on Codex usage - **Cory** — referenced as having created a site for offsite planning - **Tama** — referenced as having used a long-running goal to reimplement Doom in Swift - **Daniel** — referenced as having put Codex into 3D-printer devices - **A gentleman in Japan** — referenced as using Codex on mobile while traveling; and a quoted individual from Japan on compaction - **Gabriela** — used as a placeholder name for users in the live translation Slack feedback demo --- ## Promotional and Commercial Segments All of the following are flagged as promotional or product-promotional content: - **Product feature showcases:** Codex app, Codex remote on the ChatGPT mobile app, sites, plugins, computer use, Chrome extension, in-app browser, memories, Chronicle, custom instructions, hooks, automations, and the app server - **Third-party plugin promotion:** Digital Ocean plugin (described as "just released last week"), Convex, Vercel, Slack, Gmail, Outlook, Microsoft Teams, Linear, Notion - **Call to action for downloads and credits:** Urges download of the Codex app; announces 100 USD Codex credits and 100 USD API credits, with a QR code shown - **Swag offer:** Sweatshirts offered at the end of the session - **Event promotion:** Upcoming talks (keynote, Jason's session, Dom's sessions, voice agents session, LLM inference session), and references to the AI Engineer conference - **Pricing and plan references:** Business plan, Pro plan, and enterprise and business availability for sites --- ## Referenced Sources and Materials ### Named Products, Models, and Technologies - GPT Realtime Translate (named by Charlie as a latest model) - GPT 5.1 Codex Max (described as first trained natively on multiple context windows with compaction) - GPT 5.5 and "5.5.4 mini" (named in the Retroex demo) - OpenAI Agents SDK (open source) - OpenAI Python GitHub repository (used in the computer-use demo) - openai/codex repository (open source) - Ratatouille (film quoted in the opening) - IKEA instruction manual format (style requested for a visualization) ### Referenced Skills, Plugins, and Documents - "Define goal" skill from the OpenAI skills repository - Built Mac OS plugin (AppKit, liquid glass, signing guidance) - OpenAI developers plugin - Digital Ocean plugin - Convex plugin - Image gen skill - Obsidian vault (local notes used in a personal automation) - AGENTS.md file (custom instructions and agent guidance) ### Third-Party Claims Made by Speakers - A session with nearly 300 sub-agents (described as a tweet the speakers had seen; not verified in the transcript) - A Codex-built synth plugin for Ableton - A self-driving golf cart built with Codex - A goal that reportedly ran for 40 hours to reimplement Doom in native Swift (attributed to Tama) - Quoted user reactions about compaction ("did OpenAI basically solve compaction...", "codeex has strong compaction") - A claim that "90 plus%" of the time appshots work correctly (speaker's personal estimate) - A claim that Google detected a headless Chromium browser and sent an infinite capture loop (described as a general problem, not a specific case) > These are presented as speaker reports or anecdotes. None are supported by linked evidence in the transcript. ### Unverified Quantities - Run durations stated on screen or by speakers: 15 hours, 30 min, 55 sec; 5 hours 57 seconds; 7 hours 1 min 40 sec; a reference to a 12-hour run; and 4 minutes 2 seconds for a live app build - Token and credit figures: "100 USD" in Codex credits and "100 USD" in API credits --- ## Comment and Availability Information - **Comment availability:** Not supplied in the curated metadata. - **Audience interaction in the transcript:** Live audience exchanges occurred during the mic test and the German-language translation demo. The transcript does not record any written comment feed. - **Feedback channel referenced:** A Slack channel used for live feedback during the translation app demo, and a feedback form created for the workshop. Neither is included in the source material. --- ## Known Gaps and Limits - **No cited-source list** was supplied with the video. - **Speaker turn attribution** is incomplete; several `>>` turns cannot be tied to a named speaker from the transcript alone. - **Live demo outcomes** (translation app audio, Retroex output, sites output, form builder results) are described by speakers and cannot be independently confirmed from the transcript. - **Video or visual evidence** (slides, screen recordings, on-screen dashboards) is referenced but not included in the transcript; any claims that rely on visuals are recorded only as spoken descriptions. - **Transcript quality:** Some words and phrases appear to be auto-transcribed with errors (e.g., "Codeex," "codex max," "sub aents"). Terms are recorded here as the speakers used them, with standard spelling where the referent is clear. All right. \>\> Good morning, everybody. \>\> Uh, thanks for bearing with us. There was a long line outside, so we just wanted to make sure everybody could get in and get a seat. Um, thank you so much for being here. This is the cooking with Codeex workshop. We're so excited to have you. Uh, my name is Charlie. I'm on the developer experience team at OpenAI. \>\> And my name is Gabriel, also on the developer experience team, flying in from Singapore. Nice to be here. Uh so before we kind of dive into the nuts and bolts, you know, I wanted to do a quick review of what have folks been cooking with Codeex. \>\> It is a cooking show. \>\> Uh these you might have seen some of these tweets. Um but you know there's a real range of stuff that people have been making. Some of it pretty pretty incredible. Uh I think this one uh a session with nearly 300 sub aents. Has anybody beat that in a given session? No. I think I think Dom might have, but we'll see. Um Codeex working on a synth plugin uh for Ableton. Um really really cool stuff. I think on our team um we have a team member Brent who's doing at this point video editing with codeex driving premiere right which is not what you would normally expect to see from from a coding app. Uh playable you know games I think like gaming to me is is really a place where where the models and the app can shine. the ability to go and check your work um for the game as it's done or to hand off between different threads and you know manage audio versus art design versus game mechanics versus you know difficulty balancing. Um I think I think the different threads and sub aents are amazing here. And last but not least um you know building a self-driving golf cart with codeex uh which I think is just absolutely incredible. Um, it kind of makes me wish I was back at school so I could be hacking on uh stuff in my nights and weekends again. But where have people been cooking? I think that's pretty fun. So you we sort of see it everywhere. Everyone's codex mixing everywhere, anywhere, all the time. I mean, literally in between meetings, you've seen people like holding their laptops everywhere, keeping it open. It's become a meme at this point. Fortunately, we now have Codex on mobile. So, this uh gentleman in Japan was able to like bounce between ideas in bouncing between cities while on the bullet train or while walking a dog. And you don't just ha you don't necessarily have to use Codex on the Codex app or use it within like the chat GPD app. You can just put Codex anywhere with it being open source there being the app server which we'll talk about briefly at the end. You can put it here. So this Daniel for example put it into three e- in devices. So you really can codex max anywhere. So if it's your first time sort of using codeex uh do check it out. Do give it a download. What's really nice is that if you have existing configuration for other agents you can just bring it in and just get started really cook quick. And today we want to through the cooking show help you cook really fast and cook something really cool. So there's a quick agenda. We're going to talk about what's new and then the real pun intended meat of the session is the six ways to cook with codeex. Some closing thoughts and then the second hour of the session we'll have like a mini hackathon where we're going to have live cooking right in this room and we'll be like walking around helping to be your sue chef to your main chef. So what's new? What's fresh from the oven? A few a bunch of things I think fundamentally to just really help you give context to Codex really fast. There was record and replay. You spend time maybe describing, oh, you got to press that button, you got to press this button. Maybe just show codeexc by doing it. It builds on sort of our technology with computer use and so forth. Tread handoff really fun. You can sort of push things from the cloud to the remote to your local and vice versa. We'll demonstrate some of that. And the mobile app is now in generally available. So now there's like sort of onetoone device pairing, a much more secure way of working with codecs. So, it's it's been 2026. This slide barely summarizes everything we've shipped and we're only 50% literally 50% of the year. Some things have been really fun. The plugins, computer use, multimodality, being able to use Codex on the mobile, app shots, that's a personal favorite. These things really make Codex and the Codex app really fun to use. And we'll be talking about some of these. They are all sort of key ingredients. So, that's cooking a Codex. Uh we wanted to like start with this quote where it's from our favorite movie Ratatouille. Anyone can cook but only the fearless can be great. And today with the sort of ingredients we're going to share with you some of the recipes but with your ingenuity we think you're going to cook some really fun stuff. And these are the six steps to cooking with CEX. Number one you got to give Codex your context. There's a lot of context in like your documents, in your brain, in your conversations, in your email, in notion, linear, so forth. You got to give codeex that context. That's a really important ingredient. And then once you have it, you can literally just build things. And that's already just a step two. For the power users in the room, there's some interesting stuff where Codex can actually take action. You might notice right now like on I'm on Chrome and you just see this thing nice thing at the top saying Codex started debugging this browser. what's happening in background is actually codex is reading the slides as I'm speaking and then you can sort of collaborate with codex on longrunning tasks and you want to work over time where you want to put this make it repeatable sort of ensure consistency and really like build those loops and finally we want to bring codex everywhere if you want to embed it in your own product or in your own internal platforms that's also possible so let's just dive right in for the first two steps cooking a codeex where you give it your context and you can just build So, a few days ago, like on Friday, uh Charlie and Christine and myself, we were thinking, "Yikes, it's it's Friday. It's Friday night." We sent it at 4 4:44 p.m. We don't have a demo idea for this workshop. Uh we had any suggestions. Then Christine suggested, "Hey, let's build a real-time translator." Charlie uh suggested, "Hey, let's use GPT realtime translate. It's one of our latest models. It's really good." And then we can even have a plugin. I've never built a Mac OS app, but with the plug-in, all the best practices are there. So maybe you would like copy paste, you would like Google or search or what these things are. Then you go to codeex, but I'm going to do something fun. So I'm going to take my two thumbs over here, my my right thumb and my left thumb. I'm going to put it on the command key. I'm just going to press it. And bam, that's a app. All that context on Slack, all the conversation, that brainstorming is just right there. And let's just ask Codex. Hey, can you just build this? Yeah, cooking show is over. No, I'm kidding. And we're going to let Codex cook on that. And what happens with a appshot is that when you take a it's like a screenshot, but all the text is embedded as well. And it's very nice because that's where you have a lot of personal context, the conversations, there's brainstorming, you don't have to like repeat yourself. You just give codecs and you can like just figure it out. So, we're going to look let let that work on it for a bit and we're going to try something else as well. So, we have the agents SDK. It's open source. It's pretty nice. And uh you got like some things that have come up in the recent months. So, I was thinking, hey, maybe we could build like a website to sort of just briefly describe what's new and we're going to use this thing called sites. So, sites is something that we launched earlier in the month in June for in preview for enterprise and business plans. It lets you sort of create a simple site and it's really about just creating artifacts you can share. So here we sort I worked with Codex for a bit and let's just see what Codex cooked here. So we're going to open it up and it's all what's new with the agents SDK. You have the it's pretty nice. You have like six changes, sandbox agents, codex as a tool, tool search, realtimes agents. We'll be talking about that in a in the next few days as well. And then you can see like the code snippets are here. So yeah, it's pretty nice with sites. You can then create artifacts that you can share with your team. So that's another example of bringing context because you have a code base. It's a really large codebase. There's git commits, there's history to it. is a lot of things. That's that context and that's step one. You're just going to give it to Codex to build it and that's step two. You can just build things. So let's give in that last last example here. Maybe like now we're Charlie's out on the streets think uh taking a walk with his kids, his dog, and he's wondering, hey, maybe you wanted to build something. So I'll let Charlie uh take the stage here. Got it. Cool. Uh so what I want to show you is Codex remote. Gabe mentioned we might be out in the world, right? We might be, you know, on the beach. we might be um camping something but we still want to get work done. We still want to keep cooking. So Codex remote is a feature that's now available in chatbt a mobile app and allows us to connect to a you know laptop or remote server and issue commands that can be executed uh remotely. So in this case let's say we want to visualize something about this agents SDK right um for me personally you know last weekend I was building a bunch of IKEA furniture so that's kind of on the brain. Uh, why don't we try to visualize how this repo works in the style of an IKEA manual? Can you create a visualization of this repository in the style of an IKEA instruction manual? Uh, I want to understand how all of the primitives fit together. So, this is going to send for my phone. And here we go. So, you can use remote to keep working. Uh, you know, you leave your laptop on. Codex will keep the the laptop open while it's cooking in the background. Um, and it means that, you know, you can sort of free yourself from having to be at the computer all the time or having to walk around with your laptop open all the time, which is 100% a thing that I've been doing lately. \>\> It's almost like a regular occurrence. Every weekend, everyone's like leaving their laptop in the room at home and just like walking out touching grass, you know, still checking in. Hey Codex, is everything okay? Is there anything I can do to help unblock you? And in a sense, everyone's become a manager. So, let's see. Go back to the live translation. We'll see what's going on over here. All right, it's building. It's did some web search. It's finding out what's going on. So, I think we've sort of covered very briefly uh to another concept called plugins. So, just going to the slides. So, we go there. Here it is. Yeah. So plugins are a bundle that sort of bundle together skills which are best practices, external prompts, uh maybe practices that are custom to your team, apps which have the configuration and provide the connectivity to external services and MCP servers which provide the tools that are necessary and wow already sort of popped it up there. We'll just skip that in a bit. So that's plugins. And if you just take a look at some of the plugins we were using here. So if you just go over to the Codex app and you just scroll right up here, there's this button called plugins. And you'll see a bunch of plugins. So for example, what we were using was the built Mac OS plugin which has a bunch of best practices uh in terms of the skills for how to use AppKit, how to use liquid glass, how to sign and inspect the built application. And we were also actually using the OpenAI developers plugin. So it's 2026. Um we're not going to go to the developer platform and click uh create API key, save it somewhere, pray that you actually saved it somewhere. Now with Codex and the plugin, it can just directly create the API key for you as necessary and it really keeps things really smooth as you it doesn't really interrupt you in that flow. So those were the sort of two plugins we were using. But there are other plugins that may be relevant like say uh Gmail, Outlook, uh maybe use Microsoft Teams, use Slack and that provides all the relevant connectivity you need for your agent to work to bring context into the kitchen. \>\> I think I think I would add to that, you know, the Codex app um comes with the skills to build your own plugins. So in giving the app context, a lot of times I will work through a difficult problem or a workflow that you know I'm not sure how I wasn't sure before how to tell Codeex how to do it. And when I get to the end of that conversation, I will often say, "Hey, make this a skill or even better make this a plugin so that to next time I need to do this, you can just invoke the plugin and get the job done and we don't have to step through all of this work again." So this is what Codex built in say 4 minutes and 2 seconds. Let's see if it works. So it's a live translation. So let's let's maybe do like I I understand there's some German speakers in the room. So let's go let's do German and let's just make sure the audio is working as well. And let's see what Codex can do. So again, I've never used built a Mac OS app. I'm a data scientist by training. Not very not the best at like sort of working with like web RTC websockets. But with the Codex app and the plugins, I'm able to get that sort of best practices through the through that. So let's just do that. Make sure the input change to the phone, the output is here. And all right, fingers crossed. This is a live app. It's it's built. So this is like we don't know how this is going to taste. And fingers really fingers crossed. Oops. Hello there. Hello. Mic test. One, two, three. Okay, let's change the audio. You know it's a real demo, live demo when you got to do it on stage. It's real. \>\> Mic test. One, two, three. Are you there? \>\> Yeah. Thanks for the tip. Hello. Are you dead? Hello. \>\> So, right now I'm at the AI engineer conference conference \>\> and I'm like winging this live. I have really It's actually not the most set up. \>\> Yeah, cuz like actually right now the speakers my mic. How was that? \>\> All right. So, one thing is that context is not just about best practices or external information. There's a lot of context in our heads. Whenever you talk to Codex, there's a lot of a lot of things that Codex can learn about you. And that's where memory comes in. It's really useful. It's I think about it as bringing context over time. So it is off by default but if you go to Codex app you can turn it on and let's say like for example I use UV and then Codex would learn that over time. I prefer using UV for Python package management. But memories and context isn't just textural. It's also about what we're doing what's on screen and so forth. And we have a research preview called Chronicle for pro subscribers. Also worth checking out. And with that you could literally for example be on the GitLab GitHub looking at your pipeline it failed and you just ask Codex why is this failing and it sees ah you were looking at your GitLab your GitHub pipelines and then it'll sort of figure it out. So to sort of set that up it's quite straightforward you can just go to the Codex app you go into settings and then it's called personalization and you can enable it. So you can enable memories and also sort of given the um as a safety feature you can also sort of skip uh generating memories in chats that involve tools because sometimes the tools might return information that you might not want persisted over time. So that's also worth considering. Right now I'm using a business plan so that isn't chronicle but if you're on a pro plan you would see chronicle as option to enable here as well. And then there's this thing called custom instructions. So here you can sort of en it's like setting the agents.mmockdown in the home directory. It applies to all conversations. So for example, I said here always reply like a pirate. Then in the subsequent commentary, Codex would always reply like a pirate. A trivial example. So that's context. And to summarize, I'll let Charlie uh sort of summarize our first two dishes of the day. So to recap, uh part one, right, we want to give codecs context. Um you need to know which ingredients you're actually using for your recipe. Um that includes bringing in external content via plugins, right? Me personally, I am a pretty heavy user of Slack, Gmail, linear. Um and then it makes it really easy to just say like, hey, go look at my, you know, unread Slack messages for today and create a daily agenda for me to to think about when I get into work. Um, you want to be able to like keep the flow when you're adding your own individual context for the tasks that you're working on. Uh, I love dictation. I think just being able to, you know, as we've been demoing up here on stage, say, "Here's the context. Um, go do it." I think dictation to me is a really underutilized feature because we speak so much faster than we can type, right? And these days, you know, we're we're beyond the the era where you have to make sure every single word is correct when talking to a large language model. you can just give it reams and reams of your own rambling uh in transcription form and it'll generally figure out the right thing to do, right? And you're able to actually talk through the idea and and get to a better space by the time you send it to the model. Uh likewise, appshots I think are are incredible and also very heavily underused. Um the ability to just like from any app I think I I don't copy and paste, you know, anything from Slack anymore. I just appshot my my Slack window or I just appshot my browser and send it directly into codeex um and tell it go figure it out, right? And you know 90 plus% of the time it can figure out the right thing to do. Last but not least, we've got personalization. Um I think you know agents MD which hopefully folks know and love. Uh and then memories as well uh in the Codex app via Chronicle. Um, worth noting, I think memories, uh, and Chronicle will use up a little bit more of your token budget, but, uh, it can be a really magical experience to have the app just kind of understand what it should be doing based on conversations you've had it in the past. It really levels it up and makes it starts to feel like a true collaborator. Um, there's a ton more stuff, I think, both in like context and personalization in the Codex app. Strongly recommend you go check it out. Um, pets is like a universally beloved uh, personalization feature which we're not really going to showcase here today, but um, is would would yeah, definitely go make your pet. \>\> Cool. And once you have all the ingredients, it's you you're here to build and to really help you build and you want to distribute it. Sites is a great thing. At OpenAI, we've been using sites extensively. Uh I for example have been using sites to summarize like an event like an event after like like after an event like today's I would ask hey Codex can you summarize what happened today create a site then we can share it with the team the rest of the organization I create a site to sort of uh we we were planning offsite and then Cory Cory on the team created a site to help us plan choose different locations understand the trade-offs so you can create artifacts to help you make decisions specific for code you can even you can also it helps with code review so let's just give a quick example with a live translate what we had just built. You just do slashcode review and then you can review against uncommitted changes and then voila, you're firing off a code review task. It's a bit like having that uh you know sue chef like double check everything. You know, you've seen the movies right before the chef like sends out a dish, they always do a quick taste test. I think that's a bit like that. Image gen where you can create images. And let's see what the example Charlie kicked off created. Oh, okay. It used SVG but not too bad. Not too bad. So then what you could also do is use the image gen skill and ask codeex to sort of cook it. So we'll come back to that in a bit but let's try that. Let's use this and spreadsheets document and slides. We won't be talking much about it today but you can sort of build these artifacts as well. And in the subsequent talks in the rest of the days and the AI engineers uh Jason for example will be sharing more about how he's sort of building with codecs for sort of these uh deliverables. So those are the first two steps, context and building. But it doesn't just stop there. So if you're sort of new to Codex, it's your first time still using coding agents. I think that's really helpful. But I'm I'm pretty sure this AI engineers welfare. We're in a room full of power users. So for the next four steps, we hope we're going to share something that's practically useful for you. And the first one is computer use. So Codex can sort of take actions like as you see right now in the browser, Codex is debugging something. I won't tell you what's happening. I will we'll reveal the surprise at the end but sort of working in the background thinking about something. So let's give an example. So I I used to work in a large organization before open AAI and not everything had an API. You had a lot of enterprise software that had like they were legacy. There were different dashboards. You wanted to download data. So let's say for example we have this dashboard that somehow pulls data from the OpenAI Python GitHub repo. There's this nice date range picker. But imagine I had to get data for every month from the start of the year the year to today I'll press Monday to Sunday, Monday to Sunday, Monday to Sunday, Monday to Sunday. It's a lot of buttons you have to press. Then there are different data sets you could choose. So what if Codex could help me with that? And the answer is yes. So again, I'm going to take a shot my two thumbs and then just take it. Okay, let's just make sure we're in a new conversation. I'll just ask, \>\> hey, um, can you help me download the, uh, number of commits for the last seven days as a CSV and the number of pull requests, the pull request data as a JSON from the start of the month to today. Uh, yeah, use like computer use and go for it. So again, it's like two different dates. I'm asking it for the like Monday to Sunday or the last seven dates days but also from like the 1st of June to today which is the 29th of June and you would see okay Codex has correctly invoked the computer use skill and very soon it's going to like start looking at the application um you see here looked at application and very soon in the chain of thought summaries you would see more of it and very very soon again my hands are not on the keyboard and you can see this is my cursor I'm just going to like park it over here right next to enterprise is uh you would see another cursor pop up. \>\> There it goes. \>\> And yeah, there it is. It's moving. It's downloading it again. My hands are here. Charlie's hands are here. My phone is like unlock. It's locked. And Codex is downloading all this data by itself. It's a bit like a mag. It's like pretty magical the first time you see it. And that's we're going to let Codex work in the background. And that's the beauty of computer use of Codeex. You don't have to wrestle with the agent for control of your screen. You can let it work in the background. \>\> I I think it's also worth pointing out that on Mac OS, you know, it doesn't uh steal your cursor, right? Like Gabe still opening the app. He can still use a different tab. \>\> I can go scroll on Twitter and something. Yeah. \>\> Yeah. And so you can still drive your computer while things are just happening, you know, in the apps that Codex needs access to. \>\> So we're going to let that work. But sometimes not everything is like a native application. And there's some sometimes you're like maybe using Google Drive, you're creating a feedback form like for today's workshop, you know, I mean feedback forms are I personally find it very cumbersome to create a feedback form. you need to like uh create a question, you need to like fill in the different options and I always forget to mark it as mandatory even though I want it to be mandatory and it's you press so many buttons with creating these feedback forms. So I already have the questions drafted here and let's see if Codex can help me with that. So I just create a new thread. So again, appshot, it's quite addictive, I must say, the user interface. And we just say, hey, um, can you create these uh this feedback form for me using the questions in the Google docs? Um, remember to make mark each question as mandatory. And just to give codeex a bit of a I mean just to make things for exposition purposes, what we're using here is the Chrome extension, which is slightly similar to computer use. So that's this is computer use, but here it's directly controlling a specific application which is Chrome. So we're going to fire that off and we're going to see very soon another cursor come up. So I'm going to put this two side by side over here and you would see codeex thinking about the task. It realizes, hey, I have the question form questions already. Then it still needs to drive the live tab to actually create it. And again, like what we saw earlier, it's going to sort of start pressing buttons. So let's just wait for a bit to see the first button get pressed and then we'll swap back to the slides in a bit. So ah there it is. You see it again. My cursor is here and then you see the blue ones here. So you can continue to go do different tasks. Let's say like maybe I'm interested to learn something about the codeex repo. We were talking about memories. So I can just like ask hey um can I configure the model that's used for memories in codecs and what's the config uh term I need to change? So you see while you're continuing to do other tasks, codeex in the background is sort of doing the button pressing for you and we'll fire that off. So that's computer use and there are like different flavors of it like you know how maybe you know your favorite dishes come in different flavors and I'll let Charlie just really give a nice summary of what where the different flavors are. \>\> Yeah, at this point there's there's like mentioned a few different ways that Codex can start controlling the applications that you're using. Um, and it's kind of important to understand, you know, when you should reach for each one. The three that we currently have today are computer use, which you saw, uh, the Chrome extension, which you also saw, uh, and the inapp browser, which I think we did not demo. Um, the inapp browser, why don't I start there, is a feature where in the Codex app, you know, it has it the ability to open, uh, a browser tab on the side just like you would kind of a normal um, you know, desktop coding editor these days. Uh but in addition to just opening and rendering web pages, uh Codex has really deep hooks into that browser engine uh deeper than it has at the Chrome extension. Um and so as a result, uh I think the inapp browser is really great for when you're building local web applications and you want to do a lot of deep testing um on the interaction design on how it's rendering because Codex can see much further into the uh into the the layout at that point. But going back to the two that we talked about today, um we have computer use, right? Which is great for um I mean anything on your on your laptop or your computer. Um but it really shines when you have applications that otherwise don't have a programmatic interface to them, right? Um it's great if it's a web app and you can reverse engineer the API calls, but you know there's a lot of desktop software out there. There's a lot of legacy software out there which doesn't easily expose that kind of interface to an agent. And so if you just need C codeex to drive the app in the same way that you a human being would computer use is really incredible and kind of unlike anything else that that I've tried it it to this day it's still just so magical to watch those little cursors fly around. Um then there's the Chrome extension uh which is your sign-in browser and I think that is the most useful for when you need to hand off um state or authorization to the agent. So, I think we've all, you know, probably run into the issue where we want to build an agent to go and, you know, use the worldwide web the exact same way that we do, and the first thing that it immediately runs into is like, "Oops, I can't log into your Gmail account." Um, and worse than that, like Google has detected I'm on a headless Chromium, and it's just sending me this infinite capture loop, right? Uh, and so the Chrome extension allows codeex with your permission to go and read from certain websites as you uh and borrow your credentials so that you don't have to worry about the authentication step as you're building. Cool. Um, so that's Codex take action and then next we're going to move on to collaborating on complex tasks. \>\> So this one's a really fun one. So I think people have really talked about how Codex is really good at like complex refactors, longunning tasks, and in the sort of next 15 to 20 minutes, I want to share some tips on how you can sort of work best with codecs on these complex tasks. So, it's going to be a bit hard to like kick off a 20our longrunning task and we're all just going to sit here, enjoy lunch, dinner, and breakfast. So, I started off some tasks the night before, and they're like four different tasks, each covering a slightly different flavor. So, this one, it's still running for like 15 hours. It's running on my remote uh uh instance. \>\> You can see at the bottom here, I'm running a goal. It's been running for 15 hours, 30 minutes, and 55 seconds. So, I got to scroll, scroll, scroll, and here I am right at the top. So, it's a bit of like a green field project. I want to build a live Q&A site. Uh, it's going to be in a room for like 400 people. There's like a admin view. There's a participant view. There is a onstage view. And then like I describe, oh, maybe the admin can do like AI generated tags. There's a moderation features on the stage view. There's a 16x9 uh run every application through our moderation API. make the experience feel like something OpenAI would launch so on and so forth. Uh here I'm being particularly prosaic in the prompt for exposition purposes. You could just ramble to codeex as well and it'll get it'll get the job done. But here just like exposition purposes, I know people are excited to take photos. This is like an example of how you're being clear. I think one misconception these days is like people always ask does prompt engineering matter? In so far as the instructions are clear, it still matters. Like I can't read your mind. Codex can't read your mind. So you just need to tell Codex very clearly what you want. But it's prompt engineering where you see as oh I got to use this magic phrase. I don't think we're in that state anymore. Reasoning models are really intelligent and they sort of the real thing is about context. So actually goes back to our first step giving context clearly. So how I wrote this prompt was I was just talking to Codex. I was I was yapping it on yapping to it on the phone. I just hey Codex can like polish this prompt so I can show it on stage. So yeah it's building this thing and I'm using like a few different things like convex. There's a a plugin for convex that helps to do uh real-time interactions going to deploy in a cell and of course the open AAI uh plugin and all right the feedback form is done. So that very nicely came up and yeah that's one example so it's like a green field project but you know not everything is like you're going to start from scratch. So here's another example that ran for uh 5 hours and 57 seconds. So here's an open source repo for a form builder and I wondered, hey, could I like repurpose this and build it internally in sites? So maybe you don't want to buy SAS. It's a small team of like seven of you. You want to just have a internal form builder. You want to use the chat GPT authentication that comes with these sites to sort of ensure that only people within your team use it and then you got to let Codex sort of build it. And I I will show you an example what that looks like later. Then the last example of a long-running task that was running. This one ran for uh let's see I think 7 hours 1 minute and 40 seconds. So it's like some uh gradu uh research papers from my graduate school days. Uh it was like written in like Julia then I think like an R and I was like hey can I like write a Python package with a Russ backend and then I told Codex again I gave some constraints I don't want to use dynamic programming you got to use like some heruristics and then codex read the papers and did it. So those are the three longrunning tasks and I want to like give some examples and some of the best practices that come with it. So in one of these for example what I told Codex was this over here you can define a goal. So there is actually a skill in the openi skills repo called define goal and I told codex hey don't create one goal create a series of goals and put it in a goals.mmuckdown file. Again, it's just very arbitrary, but it's just a collection of files that you sort of see and you can can inspect it and then create a dashboard, progress dashboard.html, so you can go back to it and see what's going on. Because in this seven hours, you don't really know what's going on. You want to have some some way to like see what's happening. And rather than having this one thread do all the work, it's actually spawning new threads. So, if we go to the see, I've pinned the project, but if we go to the the thread, but if we go to the project, you'll see it's it's spun many other threads. So for example at different milestones it ran code review and then it also ran a goal audit. So it's seeing like hey are you on track there's this initial thing you talked about like goals mount down are you deviating from it? If it is then it will nudge back the main thread. Hey remember this or do we need to rethink the plan and so forth. So it ran at different times. That's why there's like different milestones M2 M3A and so forth. Uh there's another example here with like the live Q&A site. Uh this is still running. So this is running on a remote session. So it's like my gaps remote and I want to like do testing. So what I told Codex is that hey you can spawn a local thread on my machine and use the Chrome extension to then inspect it. So you would see for example this is a thread that came and you would see it says here send by codeex from another thread. So the remote thread can communicate with the local thread and says hey you got to do click ops you got to do browser you got to do QA testing. Then the local thread did all the QA testing and it send the results back to the remote thread. So that's another thing that's uh worth uh thinking about for these longunning tasks. And let's see what else we can call out here in the long running tasks. Ah communication. So one other way of thinking about this is that maybe you could just ask codeex to send you Slack messages. So here I have a few demos. So, I was building a live Q&A site and without having to set up additional infrastructure, you can just use the Slack plugin and just say, "Hey, um, reply to this thread and give me like a summary of what's done, what's not yet done, and are there any blockers?" Because sometimes there are blockers. Maybe there's like a authentication issue, there's an API key that you need to give to Codeex and so forth. So, I asked Codex to speak to me. And over the weekend, like on Sunday while I was out with my friends, I was just regularly checking, is there anything I can help unblock Codex for these different tasks? Um let's just give some screenshots of what that process looked like. So just take a look at it. So another nice feature with codeex is that while you have the main thread. So right here in you see in the screenshot on the right left is the main thread on the right you can start a site thread. So you literally see here and say let's focus on signing in with chat GPD first. I want to sleep soon. I assume you need me to do that because I know like okay I think Codex needs probably some help with that because I'm running a building a new instance on the app server a new user interface so it needs to get some credentials so it needs to know where my credentials are and it says okay actually the credentials are already here so okay update the main thread so you can use the site thread to update the main thread so let's do an example of that live as well so here this one is still running you could just do slash site and it creates a site thread and you can just ask codeex like what's going on. So maybe we just ask it takes a while this I think due to the network but let's say uh hey um what's going on can you list like uh what you've done so far maybe in the last hour what do you plan to do next is there anything I can do to unblock you and then from this when you get the agent tells what's going to do next you can also get a sense of like what maybe it's like on the wrong wrong track then you can sort of tell codex hey maybe you don't want to do that we should do this instead then the site thread can communicate with the main thread so that's a pretty nice uh feature \>\> it's worth noting with side threads. Those are ephemeral. So if there is any context that you want to keep longterm in your project, make sure you're communicating that back to the main thread because they will get stale after a while. \>\> Uh here's another example where what we were doing earlier was a site thread talking to the main thread. This example is where two different main threads are talking to each other. Specifically on the right uh the left side um we have uh codecs saying test spawning a local thread in the local form builder project. If it succeeds make that the default location for all local future local threats especially for Chrome or end to end testing. So again on the what's happening here is that it's running on the remote service but so it doesn't have access to my chrome chrome browser. Then it send a message to the local host and then it can then from there uh see uh chrome appears to be installed and then from there it can do the testing with chrome. So there you can get the remote session to work with the local session and this was the test that it did. So while it's working in the cloud locally on my laptop like me at 3:00 a.m. while sleeping Codex opened Chrome it went through the form building flow and it created a form end to end. Sub aents are also a particularly helpful thing in these longunning tasks because you want to make sure context is well separated. Uh agents sort of focus on different tasks and here's one nice example. So it was building a application and I just like took a peek at it and I just not necessarily best practice. I just sent it to the main thread saying not very good. Yeah. And then Codex said yeah agreed that's technically cleaner but it's still a bad chat interface. And you notice here what it did was that it messaged the sub agent. So the sub agent was already previously spawned but then the main agent messaged the sub aent and you would see this the message over here. So for example it says this. So it sent it and says update your verification task with this new user screenshot and directive. So there you have the sort of inter agent communication. Uh so this was that what it did thereafter. So it did its own tests because I sent a screenshot with the messages flushed to the bottom. I didn't want that. So then Codex did its own test and it says uh send retroex visible okay in one short sentence and it sent it. So CEX itself did its own QA testing to sort of verify my feedback. Um and this is an example for the live QA where the main thread was spawning different other site threads for example the audit of the goal the code review but also doing that communication back to Slack. So this thread over here where it says provide slack thread URL that's over here where I was providing all these updates. So a separate sort of session was managing that. We earlier talked about goal and here is a dashboard that the codex created for the goal. So you would see it has all these different milestones, what's been completed, what's active, what's yet to be started. And then the dashboard also gave me a sense of like what the different threads are doing like oh this thread is the main orchestrator. There's a communication thread. There's one thread doing like visual UX. There's one doing like the managing the app server protocol and so forth. And even like creates it into like more conceptual work streams like one workstream on off one workstream on testing one workstream on UI polish. But throughout the night sometimes codeex does get blocked. So then with the example of convex in versel, it said oh um I I marked it as blocked because the critical path it didn't have the authentication didn't have like the identity to access these external services but still I did everything I could up till that point. So it said it was blocked so it will come up in the UI and then I just selected it and I say add to site chat and it says can you please explain what's going on because I just woke up like I I didn't have context of what's going on but Codex is telling me he was blocked. So I'm trying to get Codex to to catch me up to speed. So here it's like saying explain step by step what I can do to unblock you here. So it gave me different options how I can give the code VLE details the convex details and then I sort of did it. So here it I sort of I selected it and say do that. So then the site thread told the main thread to sort of create the CLI login flow and I'll just click it over here and I'll be able to then authenticate and give vers uh codeex which again is running on a remote instance access and the right permissions to manage my versel project. Then in the case of convex there's a deployment key. So I was like hey I'm not going to paste that into the chat. So I asked Codex give me a secure way to do it. Then it gave me this like bash code that I could just paste it in and I could then set the key into the remote environment. So that was like a way where you could collaborate with Codex in a remote instance, do different testing, managing permissions and so forth. Um, so let's see what they actually built from this entire process. So let's look at a site builder site one. So this is it, the internal form builder. So to recap again, there's an existing repo where of a form builder, but I want to like customize it for like maybe my internal team. We're like maybe five of us. I don't want to spend money on SAS. So we can build our own form builder. So it creates a new draft. You could call it like AI engineers uh workshop. Hello. And then just say like yeah I should I should ask the Chrome extension to do this but you know for exposition purposes. Okay. And you can like preview the form and then you can sort of share it thereafter. You can like copy publish the link. Then there'll be a sharable link. You open the link and then someone else in your team can fill it in. And again because this is hosted on sites only people that have access to your chat GPT workspace can then access this form. So that's really nice. Yeah. Then you can see all the responses and so forth. So this was again what we did. So to summarize on the complex task, we had three different projects. One was a machine learning one where I wanted to reimplement a package with a Rust back end. one was to take a existing uh to build from scratch like a green field project a live Q&A site and the third was to take an existing open source project and customize it for my sort of needs and codex was able to sort of get it done in those cases. So underlying this are a few sort of uh concepts and primitives here. Let's go back to the slides. So the first thing is compaction. You saw how codex worked for seven hours. It worked for 5 hours. It worked for like right now I think the other one is like 12 hours. And many times it's compacting its context window. This is not a new technology. In November 19 when we released GPT 5.1 Codex Max, yes the name was GPT 5.1 Codex Max, we natively train the model on multiple uh context windows through a process called compaction. And that's what lets Codex be really good at it. Um some examples of what people have said about compaction to quote did open AI basically solve compaction I pretty much never had issue with 5.5 and codecs across ultra long threads spanning many compactions. Uh this individual from Japan said like in fact codeex has strong compaction. So even if you make a lot a lot in the same thread it's less likely to forget. And in that sense because it only remembers the good stuff. There's some token efficiency to that I suppose. And as always, people think it's pretty quoted. I'll let uh Charlie share a bit more about like specific uh primitives and concepts that enable this such as goal. \>\> Yeah, thanks Gabe. So, as you saw, we we have a goal that's already been running for 15 hours. And uh I think you know goal is is one of these primitives that um is incredibly powerful if you can use it in the right way. Uh, one of the biggest things that I tell people who are just trying it out for the first time is be really specific with the criteria that you're giving the model to to know when it's done. Um, and specifically, you want that criteria to be as verifiable as possible. Uh, sometimes I do feel a little bit like goal is is kind of like a genie in the sense that when it works well, it is insanely magical. uh and when it doesn't sometimes I feel like I've entered into a monkeykey's paw type situation where you know it has done the thing technically that I asked it to do but like very much not in the way that I was expecting. Um so it when you give it a task it'll run off it'll keep evaluating itself against the success criteria against the verifiable criteria that you've given it. Um and at each turn it'll check hey did this actually complete um and if not should I keep going right um there are quite a lot of use cases uh for very large projects in this way. Um, you know, Tama, as you can see, used a SLGO that was running for 40 hours, uh, that did a reimplementation of Doom in native Swift code. Um, if that's the type of thing that that you want to give a shot. Um, but also things like code migrations, large refactors, uh, retrying loops, uh, experiments, and, you know, like games or or full oneshotting apps with fairly detailed specs. Um, I think goal is is pretty incredible. Uh we've also got sub aents which we uh saw a little bit of a preview of here right sub aents in codeex um you know by default will get used out of the box. You can tell tell the model hey uh you know think about delegating to sub agents here um but you can also customize them. So if you want if you know you have a sub agent that should be your um you know code reviewer right you can have a specific prompt set of developer instructions here. Um, if you know you want that code reviewer to just be focused on um, like just be a lightweight model so that it runs quickly. Or if you want it to be a much more intelligent model so that it's very thorough, you can customize that in its own uh, sub aents.totml file. Um, and you can give these names. You can say, oh, go, you know, check with the code reviewer, go check with the docs researcher, um, in order to to implement, right? Sub aents uh, can work in tandem with uh, thread-to-thread handoff in codec. So, um, thread to thread is is quite new. I think we just released it in the last week. Yeah. Um and so uh that's just an even higher level of abstraction. Um and the way that I think about balancing them is, um when the the delegation of work needs to be visible to you, the user versus when it just needs to be visible to the model. So sub aents we started with because I think that is when the work, you know, primarily needs to be visible to the model. um if you want to delegate, you know, some uh like a subcontractor, you know, I don't really care what they're talking about. I just want to make sure that the work comes back good. Sub aents are a great fit and the model is great at figuring out when it should be um handing off into sub aents. Uh it also keeps the the context separate. I think unlike you know a lot of other tools that um we've we've brought to codeex to help keep context windows efficient. Um, sub agents are one where uh, you know, you're keeping the context separate and the mo the the models are communicating with each other. Thread to thread handoff is useful for when you still want to be in the loop and you still want to be able to like look at everything that's happening. Um, and perhaps even larger than that, you are mentally thinking about separating these two uh, these two threads, right? So, um, one example is over the weekend I was working on a game um, and I had a creative director thread, right? I could have used a sub agent and that would have worked fine, but I wanted to see all of the different things that were happening and I I didn't want it to just be delegated into the ether via sub agents. So, with the creative director thread, I opened up um different threads, one to work on the art direction, one to work on the music, one to polish the animations, one to figure out the game mechanics, and I was using those um and I told them in the agents MD file, when you're done, go and check with the creative director thread, which I'd given a bunch of extra context on, you know, the look and feel I wanted for the game. Go check with the creative director and get sign off before you consider this task done, right? Uh and they all did so. that, you know, it was actually really interesting to watch the threads just constantly sending messages to each other back and forth as they worked on the game. Uh, we didn't quite show it here, but we also have hooks in the Codex app. Um, if you want to set up your own hooks, you can do so in your config.toml file uh in your codeex home directory. Um, these are really great for when you want to start introducing uh deterministic behavior at specific checkpoints in your software development life cycle or in your just you know general uh development life cycle. So I think in these cases you might use hooks to do things like um you know send your conversation to a logging engine right um you might want to scan inputs or outputs. I think there's quite a lot of security use cases for hooks, right? Before Codeex takes a specific action, maybe you want to look at the prompts and figure out, hey, have we accidentally pasted an API key that's that's going to go somewhere um or before it takes an action to call a tool? Hey, is this tool, you know, on like not on our approved white list or something that we need to be extra sensitive about when calling the tool to evaluate if it's if it's safe to use. Um, and we can also do custom validation checks as well when the turn stops. these days, you know, you can tell the agency MD, hey, go and use the the llinter, right, before you consider the work done to check your work. Um, and it's really good about doing that, but if there are things that are a little bit more sophisticated or a little bit more complex that you want to do to validate the output, uh, you can use hooks to to take care of that as well. Um, you know, I find that when building more and more complex projects, some of the most important things are figuring out, like I've said, the verification criteria or the success criteria. You want to give the model as many boundaries as it can as you can and let it fill in the lines um in accordance with like the boundaries that you've given it. \>\> Cool. Um and that brings us to working over time. \>\> Thanks Charlie. So just to quickly share on hooks uh slipped to my mind as well. So we have the OpenAI agents SDK and there's actually a quick example of hooks right over there. So if you go to settings, all the hooks are sort of there. And you would see the hook for the agents SDK repo. And here it's sort of doing at the every end of its turn a Python script to just tidy the repo. So again, there like some of these housekeeping that maybe you want the language model to do. You can run it deterministically with a hook. And hooks become particularly useful with longunning tasks because there is that trade-off. You're giving the agent more autonomy. It's going to work off work longer and longer without your supervision or abstracted supervision. And to that to that end hooks become useful in getting the guardrail. So on working over time what we're trying to show here is that now we sort of collaborated codecs we have some of the power tool power user tools like computer use. How can we like sitch this all together and let you know codeex work on its own? I mean for exposition purpose here we are like prompting and like being more methodical but in reality you can just like let codeex work on it like with thread handoffs. In practice, I could have all my demos in one thread and just ask that thread to segregate to separate it and send it and delegate it to the various threads. So here's one quick example of a automation. So right now you notice like on my uh screen over here that these like blue orbs. So this is just showing that it's a remote host and maybe you want to create one. So we have a nice plugin here with the digital ocean plugin which we just uh released last week and then you saw do it. You can just try it in chat. I'm just going to like fire it off as well. And what it's going to do is going to like provision this infrastructure. It's going to take some time. And I'm not going to like stand here and look for for it to provision this infrastructure. Uh and Codex is not going to like just keep um like waiting. What it's going to do is create a heartbeat automation. So it's going to like monitor and so forth. So it says yes. And let's just show in the spirit of this being a cooking show an example that was already done. So here provision a digital ocean droplet. Okay. Yes. And then it created the automation here. I set a codeex heartbeat to resume this track in about 5 minutes. So it's going to keep tracking every 5 minutes. Is it ready? Is it ready? Is it ready? Is it ready? And once it's ready, it will take the next step. So in this case, it did it. So okay, the droplet's ready. And it even gave a nice link. So if you click this link, it's a deep link. It's a link like a deep link to the settings page within the Codex app which automatically sets up the SSH instance for you. So you just need to press it and then it'll preconfigure everything. It knows where it will create the SSH key for you if necessary and so forth. So that's nice and you can extend this to other parts of like say the software development life cycle. Uh maybe you're building something you need to deploy. You have a pipeline that triggers event based and it takes time. So you can get codeex to like run every 5 minutes, every 10 minutes check is it ready, is it ready, is it ready and maybe depending on the event then it sort of spawns different tasks and so forth. So that's a heartbeat automation. It runs within the thread. But we can also do automations that sort of spawn new threads. Uh so one example of this so right now I have actually the Slack channel. So see if it's up. So remember the Mac OS translation app. So in the last say 45 minutes we had a bunch of users all called Gabriela and they've been using it. They've been giving a lot of feedback on the translation app. for example, oh the screen feels focused. I can tell where to start, so it's positive. Is there a way to do a quick sound check before the audience sees caption? So, so there's a lot of feedback. People are giving feedback. And I want to like, you know, give this feedback the attention it deserves. So, I want to create an automation to do that. So, just make sure we are in I'm just going to close this since we don't need it already. Over here, we create a new thread. And then I'm just going to like do a appshot. Um, every half an hour, can you just like look at the comments and uh suggestions in this channel and reply to them? Uh, I think there'll be like a few categories. There's one category where it's like compliments. There's one category where it's a bug report. There's one category where it's a feature request. Uh, so forth. Let me just like fire that off. So, it's going to create an automation. And I I just sent it, but I realized, oh, wait. Um, if it's a feature request or a bug fix, I want to do something different. So, I'm going to like steer this. Oh. Um, if it's a uh bug fix or feature request, can you also then like spin a new thread in a work tree and actually address that and then open a PR and then like request Dom to review it and then so forth and ask Dom to like approve it within like 24 hours. If not, just keep reminding him. So yeah, it's it's it's a comical example, but here it's where I'm try I what I was first doing was steering. So I'm going to I don't have to wait for codeex to finish. I can sort of steer it midway. And what I'm trying to do is in addition to all this feedback and classifying it if it's a it's a bug report, if it's something that uh we can fix. Codex would then sort of spawn a thread. So we're putting all these primitives together, the automation, the plug-in which can can read slack. The fact that one codex thread can communicate with other codex threads and even create work tree threads and so forth. So imagine then you wake up and this is a bit like that software factory where all the PRs are ready then you can even add additional comp layers to it where it's all this review you build a test version you send it to someone they test it and then they give the thumbs up then it's good to go that feedback gets fed back to the PR then the PR reviewer sees all this holistically. So yeah, there's a lot of it you can chain together to build that automation. So then every half an hour it would do this and it will find DOM as well in the uh channel. So you we were talking earlier about how we've actually been running a automation in the background and let's find that. So let's see here it is. So earlier while everyone was coming into the room I was asking Codex can you run an automation every five minutes taking a screenshot of what's happening on screen the Google Chrome uh Google drive presentation we only have 16 minutes and I'm asking Codex to estimate to what extent are we going to overrun so right now it's at checkpoint 13 it's seeing if the demo is there it's flashing 12 uh 10 12 and so forth so Codex is doing its own assessment of like to what extent are we going to finish on time so it's a bit of a meta example of how you can use automations and chain together other tools like in this case the Chrome extension. \>\> It looks like it's telling us we might be a little bit behind the ball here. \>\> Yeah, it's it's a you know it is what it is. So automations have been really useful in my personal life to extent really like getting a lot of things done. Uh some automations that may be useful too. Uh one automation you can run maybe every Friday you ask Codex to look at all your conversation threads and see are there skills that you could improve? Are there like things you could add to the agents markdown? Or are there skills you could just remove? maybe skills that you haven't been using. A second automation or approach that may be useful. Maybe you're using automations to draft email replies. You can have one automation that drafts the email reply, but you can run a second automation that sort of cross validates against the eventual reply you sent because that is the ground truth. Then it updates like a markdown file with the best practices, tips and so forth. And in that regard, the email drafting automation can get better over time. So, um I'll let uh Charlie just recap what automations are and share a bit more about the app server as well. Our final step. Cool. Uh so I think yeah, automations uh there's two types two types of automations, right? Um I think the more powerful one these days tends to be the inapp or inthread heartbeat automations. And so those just live in a single thread. They run on a timer. Um they you know keep going over and over until they're they're done. Um, these I find like have just almost unlimited use cases. Uh, me person, Gabe shared some of his. I think me personally, um, I feel like I'm drowning in Slack and email and linear notifications every day. Uh, so I have an automation that just sort of, uh, goes through and checks the latest updates from, you know, all the sources that might need my attention. I have a local Obsidian uh, vault and so it's just constantly updating my daily notes. It's constantly updating my uh, notes on different work streams and it's keeping a lot of context there. And that way I can just pull from that later if I say, "Hey, you know, what's going on with the latest uh AI engineer world's fair talk?" Like, you know, how far are we on the demos, how far are we on the notes? And then I can just Codex can just quickly tell me, here's what's happened since the last time you checked in. Uh, but automations can also live in a new thread. If you set them up in the Codex app, uh, under scheduled, the scheduled page, um, you can have them spin out in their own thread as well. Um, and then that's useful if you just want to say, "Look, every week I want you to do a recap of what all of my direct reports have been doing, or I want you to look at all of the analytics from this uh system, and then we're just going to do a one-time look together, and then I'm going to archive the thread and not worry about it again." Uh, I think last but not least, we've got embedding codecs anywhere. Um, and so I think we're for this one, uh, I want to talk a little bit about the app server protocol, right? Which is, um, the core protocol that underpins the Codex app, the Codex CLI, uh, the Codex VS code extension. Um, the app server is basically, uh, what allows all of these services to talk with the main codeex harness, right? Um, and it's integrating all of the tool calls and the plugins and the context compaction that you know and love. Um we have you know built a lot of the components of the Codex ecosystem to be open source because uh we really want to encourage developers to build wherever you are and for whatever use case that that you have. And so to that extent um you know if you're not aware you can embed codecs into your product using app server. Uh I think this brings a lot of the uh power of codecs directly to you. Um, and it brings the ability for your users to uh use their chat GBT subscription and perhaps more importantly use their chat GBT token budget uh to power the products that you're building. Um, and like I said, it has all the same underlying features that we've been demoing. You know, compaction, steering, the ones that need to live on your computer like computer use are are, you know, not going to be there. But for everything that exists in the core, uh, you know, agent harness, we've got that in the app server. So as a quick demo of that, so there was a fourth longrunning task that I kicked off last night. It was actually to build my own user interface for codeex with the app server called Retroex. So it's been working for a while. I think there are different tasks I worked with it. And this is sort of the work in progress retroex. It's using the app server. Uh let's just okay zoom in then optimize it for the stage. But yeah, you can like choose the model 5.5.4 mini the reasoning effort. So I told like oh make it a bit funky when you change the reasoning effort. So at low there's like a small glitter at medium the color changes you think high and extra high it's like woo a bit more. So you could just like simply say like uh hello and let's see this is in retroex going to send hello and then allow access. It's going to run and it's going to reply back hello. And what's nice and to just prove that it's all running on the same app server is that if we go to the Codex app in the same project uh retroex you should see that over here let's see yeah it should we can change the threads I believe but yeah that's an example of how you can build it's it's a trivial example of building a funky user interface but let's say you want to build agents on the cloud you want to manage different agent providers uh you're considering in a large organization your different sort of providers you're using and you want to build a unified layer the app server is a useful way for you to integrate it into your own platforms and because it's open source if you go to you get clone openai/codex you can just ask codeex about codeex you could just say like uh hey can you tell me more about the codeex app server and then you can fire it off and you can start building your own applications or integrations from there immediately so that's the app server And we have a nice blog post talking about it and there have been more engineering blog posts about like our Windows sandbox first of its kind how we built the agent loop amazing stuff and it's a good reference point also like if you're AI engineer seeing the codeex repo it's a great source and we'll have uh further talks in the subsequent days about this. So I'll let Charlie share some closing thoughts after seeing this entire cooking show. Uh, thanks Gabe and thanks everybody again for being here. I think um hopefully you've learned a bit today about how you can use Codex to kind of level up your workflows. Some of the co closing thoughts that I want to end on here are, you know, questions that I repeatedly ask myself as I'm trying to get to the frontier of what Codex can do, right? Um they start pretty simple just by asking, have I tried asking Codex to do it? Right? Um I think like one of the things around the office that we say uh more frequently than ever now is have you asked Codex? Um, but I think as you evolve that workflow, right, you want to go from just asking in individual turns to building loops, right? We've all heard about loop maxing. That is the new thing. Um, and I think we want to think about how does that how does that work, right? Like what is it that the loop needs to be checking at each turn, right? Um, as you go down this path, there's going to be additional questions like, okay, you know, as it's progressing, how how like what blocked Codeex from actually getting to the answer, right? Um, was there context that it needed? Were there permissions that it needed? Are there ways to build that context into repeatable tools like skills or plugins that Codex can use the next time it runs into this problem? Um, how do I start scaling kind of from one agent to many? Right? Like as you think about the work, is there ways that you could be prompting Codex to implicitly delegate the structure of the things that you are building? Um, or to start orchestrating across multiple threads to have different Codex instances communicating with each other. And then ultimately uh you know if you take a step back and ask the question okay why does this process need a human at all right I think like as we've shown you know one thing that you might assume uh when building with codeex or when building with the open AI API is that a human needs to be involved to like go to the platform page and go get an API key and then paste it into the environment right I think like uh as we've shown with the developers plugin that is not the case anymore the plug-in itself can just go fetch the API key and set it up locally for you um and ultimately you know we do still want humans in the loop like where they need to be but uh for everything that's not that like how do we figure out how to take the human out of the process to unblock ourselves and how do we figure out how to build the machine that builds the machine right I think like it is one thing to sit with a coding agent and build a single piece of software is another thing to start zooming out and say actually I want to build a software factory right I want to build a system that um that then builds individual pieces of software on an assembly line as we Um, and so a lot of these things are kind of how I start to get from, um, just an individual ask to something significantly bigger. \>\> Cool. And I think with that, um, we are \>\> a recap of \>\> Yeah. Yeah. \>\> Good. So, um, thanks so much for joining us today on a 9:00 a.m. on a Monday. It's the I hope it's a great way to kick off your, uh, AI engineer welfare. And that's not it. So, tomorrow we have our opening keynote. It's going to be fun. Do check it out. We also have Jason on the developer experience team giving a talk about how he gets the most out of Codeex. It's a nice foil to today's presentation about how he's using on a day-to-day basis. And then he has a workshop after that where he goes through step by step like setting up the plugins, doing app shots and so forth. So today's session is more uh like a whirlwind tour. This workshop will go through the step by steps of how to get to set yourself up for success with codecs. We then have a session on uh from the harness about the harness and then sessions about voice agents. Charlie will be talking about that as well. Uh Dom will be doing a session on building on the Codex harness and then another session explaining behind the Codex harness. So the first one is you build on top of it. Then the second one is explain the harness. Then lastly a session about LLM inference in production and so how we sort of do that at OpenAI. So thank you for joining us and that's the end of the first segment of today's workshop where we sort of give that whirlwind tour of everything codex and hopefully you have something fun to cope with. So it's time to build and to help you with that for today's session. Uh first things first, if you've not downloaded downloaded the Codex app, do give it a download. And for credits, so we are giving 100 USD in Codex credits and 100 USD in API credits. So we'll leave leave this QR code up there's their phones up and take a photo. Yeah, I could like appshot this and say, "All right, send this via email to everyone who attended, but we don't have your emails." Yeah. \>\> Cool. And I would also mention uh please stick around uh to the end of the build session um if you can. We brought uh swag for everybody. So at the end of the 2our mark um on your way out you can pick up a sweatshirt I believe. \>\> We love to see what you're building as well. Yeah. \>\> Yeah. Well, we will be here. We will be here in the audience. We've got uh opening eye staff here as well um to help unblock you or to answer any questions about uh using codecs. \>\> Thank you.