By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.

GPT 4.1: The New OpenAI Workhorse

We’ll keep this brief because we’re on a tight turnaround: GPT 4.1, previously known as the Quasar and Optimus models, is now live as the natural update for 4o/4o-mini (and the research preview of GPT 4.5).

Alessio FanellihostswyxhostMichelle PokrassguestJosh McGrathguest

Apr 15, 202545mWatch on YouTube ↗

Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.

CHAPTERS

Jump to publisher timestamps

Chapter summaries

Meet the guests and why GPT‑4.1 is the focus
The hosts welcome Michelle Pokrass and Josh McGrath, who both work in post-training. They set the agenda for the episode: unpacking the GPT‑4.1 release and what matters most for developers.
- •Alessio Fanelli and swyx introduce the Latent Space Podcast and the guests
- •Michelle explains she now leads a research team focused on post-training
- •Josh shares he is a researcher on Michelle’s team
- •The conversation is framed around the GPT‑4.1 launch and developer-relevant takeaways
What shipped: GPT‑4.1, Mini, Nano—and the developer-oriented improvements
Michelle outlines the three-model lineup released: GPT‑4.1, GPT‑4.1 Mini, and GPT‑4.1 Nano. The focus is improving instruction following and coding, and introducing a one million context window aimed at developer workflows.
- •Three new models released: GPT‑4.1, GPT‑4.1 Mini, GPT‑4.1 Nano
- •The stated focus is “models that were great for developers”
- •Improvements highlighted: instruction following and coding
- •They shipped their first one million context models
- •Josh emphasizes Nano as a new option for low-latency apps
Codenames, themes, and tapirs: separating lore from signal
The hosts probe for meaning behind codenames and recurring motifs in examples. Michelle and Josh confirm the themes are mostly for fun, while feedback gathered during testing was the meaningful part.
- •Michelle says OpenRouter testing helped gather developer feedback
- •Josh says there’s no deeper meaning to the star/space-themed names
- •Michelle and Josh confirm codenames are just “fun”
- •Michelle explains the team is simply a big fan of tapirs, hence their appearance in content
Why “4.1” after “4.5”: naming, positioning, and deprecating 4.5
Alessio raises widespread confusion about the 4.1 vs 4.5 numbering and the 4.5 deprecation. Michelle explains 4.1 is a significant jump over the 4o line, but smaller/cheaper than 4.5 and not intended to surpass it on top intelligence evals.
- •Michelle says naming is hard and the team tried to reduce confusion
- •4.1 is positioned as a big improvement over the 4o line
- •Michelle says 4.1 is smaller and cheaper than 4.5 and won’t beat it on all evals
- •Michelle expects many developers can replace a lot of 4.5 usage with 4.1
- •Michelle confirms GPT‑4.1 Mini is strictly better than 4o‑mini
Lineage and training recipe: distillation, pre-train vs mid-train, and post-training gains
The hosts ask whether 4.1 is distilled from 4.5 and how much of the “recipe” matters. Michelle and Josh describe using distillation techniques (especially for small models) and stress that many improvements now come from post-training, not only scaling pre-training.
- •Michelle says distillation is meaningful, particularly for smaller models
- •Michelle says they pulled “instruction following greatness” and rolled it into 4.1
- •Josh says version numbering reflects user experience more than a single training factor
- •Michelle says Nano is a new pre-train; Mini also has a new pre-train; the larger version is a new mid-train
- •Michelle says significant gains are coming from new post-training techniques
Omnimodel and product surface: API slugs, real-time, and what 4.1 is (and isn’t) shipping on
The hosts compare GPT‑4.1 to the “omnimodel” framing associated with 4o and ask if 4.1 is a direct replacement across modalities. Michelle clarifies there are different API checkpoints/slugs, no current plan for 4.1 in the real-time API, and the release focus is the three core developer capabilities.
- •swyx asks whether 4.1 shares the same “omnimodel” architecture direction as 4o
- •Michelle notes different slugs across the real-time API and the responses API
- •Michelle says there are no current plans to release 4.1 in the real-time API
- •Michelle reiterates 4.1’s focus was instruction following, coding, and long context
- •They note image generation and other modalities are not part of the 4.1 focus right now
Reaching one million context: what was easy, what was hard, and how to measure it
Josh explains that simple long-context tests like single “needle in a haystack” are often easy for models. The harder part is evaluating and training long-context reasoning that requires complex context use, prompting OpenAI to create and open-source new evaluations focused on ordering and graph reasoning.
- •Alessio asks about the difficulty of achieving a one million context window and the end game
- •Josh says headline “needle in a haystack” is often saturated easily
- •Josh says long-context reasoning requires more complex context usage to measure and improve
- •Josh says they open sourced two evaluations: one about ordering and one about walking through graphs
- •Josh emphasizes the hardest work was improving performance on these more complex tasks
A mental model for context use: density, orderedness, and moving around the prompt
Josh proposes a richer framework for thinking about long context than “retrieval.” He distinguishes sparse vs dense context use (e.g., needle search vs summarization) and whether reasoning requires jumping around and using ordering information during generation.
- •Alessio asks how to think about long context beyond document retrieval
- •Josh frames context use by density (sparse needles vs using the entire context)
- •Josh highlights “orderedness” as a key variable for difficulty
- •Josh describes tasks where the model must move around in the context while sampling
- •Josh links this thinking to the motivation behind their graph-based measurements
Graph Walks eval deep dive: encoding graphs in text, failures, and what it represents
Josh explains how the Graph Walks task is constructed by embedding edge lists in the prompt and asking the model to perform graph operations, which can be checked by executing the operation. He describes surprising early failure modes, and why this synthetic setup is a lower bound for real multi-hop reasoning across many documents.
- •Josh explains graphs are encoded as edge lists in the prompt and evaluated against executed ground truth
- •Josh describes early model behavior when confused, including looping and complaining about missing edges
- •Josh says many models struggled more than expected on seemingly simple graph tasks
- •Josh says Graph Walks approximates an idealized multi-hop reasoning benchmark where edges are explicit
- •Michelle offers an analogy: referencing parts of a large tax code resembles implicit multi-hop dependencies
Long context in products: RAG, file search, and how memory relates (and doesn’t)
The discussion turns to how one million context changes developer architectures. Michelle suggests developers may upload more directly instead of relying solely on vector stores for smaller tasks, while also expecting it to work alongside retrieval; she also clarifies ChatGPT memory features are separate from the 4.1 API offering.
- •Alessio asks whether this relates to the file search API and how it all fits together
- •Michelle says long context can reduce the need for a vector store on smaller tasks
- •Michelle says it should also “play nice” with retrieval by allowing more chunks in context
- •swyx asks whether long context is directly usable for ChatGPT memory
- •Michelle says memory features are separate: 4.1 powers the API, enhanced memory is ChatGPT-only
Instruction-following in the real world: why API data matters and what’s hard to grade
Michelle contrasts easy-to-grade open evaluations with harder, more realistic instruction-following scenarios. She explains that opt-in API data (processed with anonymization and model-based categorization) helps identify common developer patterns and difficult instruction types, such as negative instructions.
- •Michelle says many open-sourced instruction-following evals skew toward easy-to-grade instructions
- •Michelle says interesting real-world instructions can be challenging to grade, so they’re underrepresented
- •Michelle says opt-in API data helps reveal what developers actually do and common failure cases
- •Michelle describes anonymization/scrubbing and then model-assisted categorization rather than manual reading
- •Michelle mentions using this pipeline to find examples (e.g., ordered instructions) when feedback indicates weaknesses
Prompting guidance for 4.1: emphasis tricks, agent persistence, and reducing extraneous edits
The hosts question parts of the prompting guide, including whether emphasis tactics matter and how to encourage persistence in agentic workflows. Michelle says the models now follow clear instructions better, the “keep going” style prompt is part of an effective harness, and they explicitly measured and improved over-editing behavior.
- •Alessio asks about all-caps/bribes/tips; Michelle says clear instructions usually suffice and such tactics shouldn’t hurt
- •Alessio asks about starting with a “response rules/instructions” section; Michelle says it’s an example, not magic keywords
- •Michelle says “keep going” prompts help avoid the model repeatedly checking back with the user
- •swyx raises the persistence vs user-control trade-off; Michelle cites an “extraneous edits” eval
- •Michelle reports extraneous edits improved from 4o to 4.1 based on their tracking and training focus
Structure and placement: XML vs JSON, duplicating instructions, and prompt caching trade-offs
They discuss structured prompting recommendations: XML can be useful for structuring inputs, while JSON may still be preferable for application-parsed outputs. Josh notes redundancy—placing instructions both at the beginning and end—performed best empirically, and they discuss how this can conflict with caching goals depending on the workload.
- •Michelle says XML can be helpful for structuring prompts, while JSON can be useful for outputs consumed by applications
- •Josh says tests showed duplicating instructions at the top and bottom worked best empirically
- •Josh says having instructions early helps the model account for them during processing
- •swyx asks whether post-training could optimize instruction placement for prompt caching; Michelle says they’ll do it when figured out
- •Josh explains caching benefits depend on how prompts are arranged and the specific use case
Choosing models: chain-of-thought prompting vs reasoning models, and how to compose them
Alessio asks when to use GPT‑4.1 versus dedicated reasoning models and how to combine them. Michelle says GPT‑4.1 plans better than prior non-reasoning models when prompted, but reasoning models sustain more coherent long-horizon reasoning; she frames selection as using the fastest model that reliably accomplishes the task.
- •Michelle says 4.1 is better at planning and chain-of-thought when prompted than earlier non-reasoning models
- •Michelle says reasoning models produce more coherent plans and longer-horizon reasoning, reflected in intelligence benchmarks
- •Michelle suggests a practical approach: start with the fastest model that works, then move down (Mini/Nano) or up (reasoning) as needed
- •Michelle says using reasoning models for planning and targeted models for execution can be a good architecture
- •They note developers are still learning best practices for composing models together
Why 4.1 is strong at coding: what they trained for, how it differs, and smaller-model niches
The hosts dig into why GPT‑4.1 performs well on coding benchmarks and how to interpret different coding tasks. Michelle describes breaking “coding” into facets like producing better diffs, exploring repos, producing compiling code, and writing tests; they also discuss when Mini or Nano might be preferable for speed-sensitive experiences.
- •swyx says 4.1 is better than o1 on SWE-bench and asks if that was expected; Michelle says it wasn’t
- •Michelle says they targeted multiple coding facets: diffs, repo exploration, compiling code, and writing tests
- •Michelle distinguishes repo exploration strengths (4.1) from cases where a reasoning model may reason over an entire file better
- •Michelle says Mini can fit fast workflows like autocomplete or instant first-pass outputs (e.g., text-to-SQL)
- •Michelle says 4.1 Mini is significantly better than 4o-mini and not far from the old 4o
Vision and multimodality: where gains came from, screen vs embodied, and what’s not included
They cover improvements in vision/multimodal capability, with emphasis that multimodal gains largely came from pre-training. Josh and Michelle discuss screen-based versus real-world (embodied) vision, note evaluation bias toward easy-to-grade benchmarks, and confirm there are no current plans for 4.1 image generation.
- •Josh says 4.1 Mini is exciting for vision and that its different pre-training base shows in vision evals
- •Michelle says multimodal gains are primarily from pre-training rather than post-training
- •swyx asks about screen vision vs embodied vision; Josh says performance improved across both and training includes a mixture
- •Michelle notes benchmarks skew toward what’s easier to grade
- •Michelle says there are no current plans for “4.1 image gen”
Deprecation, GPUs, fine-tuning day one, and what’s next (reasoning, creative writing, feedback, pricing)
The closing stretch touches on operational realities: why deprecations happen, how compute is reclaimed over time, and OpenAI’s commitment to notice periods. They highlight fine-tuning availability at launch (and preference fine-tuning as underused), tease future reasoning updates without details, discuss incorporating creative-writing improvements broadly, and end with requests for feedback, opt-in data/evals sharing, and a note on caching discounts and blended pricing comparisons.
- •Michelle says deprecation compute is reclaimed as developers migrate, balanced against providing sufficient notice
- •Michelle highlights preference fine-tuning as underused for steering style; RFT is discussed as separate and still in alpha
- •Michelle and Josh say they can’t share details on upcoming reasoning models, but encourage staying tuned
- •Michelle says creative-writing improvements people liked in 4.5 are being incorporated into models more generally
- •They ask developers to send feedback, opt in to data sharing, and share evals (with inference costs covered when opted in)
- •Michelle clarifies pricing isn’t a blanket decrease across all models, notes prompt caching discount increased from 50% to 75%, and says blended pricing aims to simplify comparisons

Publisher timestamps

Get more out of YouTube videos.

Read along on your phone, search it beside the video, or ask your favorite AI app what was said.