Summary

GPT-4.1 is a three-model developer lineup—GPT-4.1, GPT-4.1 Mini, and the lower-latency, cheaper GPT-4.1 Nano—built around coding, instruction following, and a 1-million-token context window. It is smaller and cheaper than GPT-4.5, so it does not beat 4.5 on every intelligence eval, but Michelle Pokrass expects developers to replace much of their 4.5 usage with it. “The Mini is strictly better than GPT-4o Mini.”
The training story is moving beyond brute-force pre-training scale toward extracting more capability after training. Josh McGrath said the old narrative focused on ever-larger pre-trained models, while the team is now finding that “a significant amount of the gains actually come from new post-training techniques.” Nano has a new pre-training run, Mini another new pre-training run, and the larger model a new mid-training run.
One million tokens matter less as storage than as a test of dense, ordered, multihop reasoning. Basic needle-in-a-haystack retrieval saturated easily; the hard problem was traversing shuffled relationships across context, captured through graph-walk evals and the analogy of loading an entire tax code to determine one box on a return. This could reduce dependence on retrieval infrastructure for smaller workloads or allow RAG systems to insert far more chunks.
Better agent behavior came from measuring real developer failures, not merely teaching models to obey synthetic constraints. Open-source evals often ask for exactly four words or three paragraphs because those are easy to grade; opted-in API data exposed richer negative and ordered instructions. On an extraneous-edits eval, GPT-4o changed unrelated code 9% of the time versus 2% for GPT-4.1—material progress against agents that “go off and do a little too much.”
GPT-4.1’s coding edge is strongest when the job requires exploring and modifying a repository, while reasoning models retain an advantage on longer-horizon plans. The cited SWE-bench result was 55 for GPT-4.1 versus 41 for o1, but the team resisted treating that as universal coding superiority: a reasoning model may do better when handed one file and asked to reason through a change. The operating rule is “the fastest model that accomplishes your task.”
The model family creates a clearer latency-cost ladder without eliminating product gaps. Mini can serve autocomplete or instant text-to-SQL, while Nano targets very low-latency applications; GPT-4.1 handles harder execution, and a reasoning model can be added for planning. GPT-4.1 is API-focused, with no current plans for a Realtime API version or image-generation endpoint, while ChatGPT’s enhanced memory remains separate.
Economics improve through caching and customization more than through a blanket price cut. The prompt-caching discount rises from 50% to 75%. The launch discussion covered day-one fine-tuning for GPT-4.1 and GPT-4.1 Mini and raised Nano as a future possibility. Michelle argues that developers have “slept on the preference fine-tuning offering,” which steers style; reinforcement fine-tuning is only for reasoning models, while preference fine-tuning offers pairs.

Deep dive

1. GPT-4.1 is a developer reset, not a higher rung than GPT-4.5

Michelle framed the release around three deliberately practical capabilities: stronger instruction following, better coding, and OpenAI’s first 1-million-token-context models. Nano joins the full and Mini versions for applications where latency and price dominate; testing through OpenRouter provided useful real-world developer feedback.
The host’s naming pushback—why move backward from GPT-4.5 to GPT-4.1?—produced an important qualification. GPT-4.1 is a large improvement over the GPT-4o line, but it is much smaller and cheaper than GPT-4.5 and does not surpass it on every intelligence benchmark, including AIME and other evaluations. Incrementing beyond 4.5 would therefore have implied the wrong hierarchy.
Under the hood, Nano is a new pre-training run, Mini has another new pre-training run, and the full GPT-4.1 is a new mid-training run. Yet the team stressed that much of the improvement came afterward: the team pulled instruction-following strengths associated with GPT-4.5 into GPT-4.1 and found it could “squeeze a lot more out of post-training.”
The family is not a full omni-model replacement. There are no current plans for GPT-4.1 in the Realtime API, no GPT-4.1 image-generation endpoint, and ChatGPT’s enhanced memory is separate from the API model. Michelle’s narrower formulation was that the focus for GPT-4.1 was its three core developer capabilities.

2. Long context becomes difficult when every token participates

Josh McGrath said ordinary needle-in-a-haystack retrieval was surprisingly easy: most models performed well “right out of the box,” and the team saturated single-needle tests quickly. The harder work began when answers required reasoning across many context elements rather than locating one sparse fact.
His more useful mental model has two axes: density and orderedness. Summarization may require the entirety of a context, while retrieval touches only a sparse subset; some inferences proceed front to back, while others require the model to move repeatedly through the context as it samples an answer.
The team’s graph-walk eval encodes edge lists and asks the model to perform operations such as breadth-first or depth-first traversal. Early models sometimes looped—“Oh no, I can’t find this edge that I think needs to be there”—on work an undergraduate might script in minutes. That synthetic test is intentionally a “lower bound” for natural multihop reasoning.
Michelle connected the abstraction to hundreds of documents whose relationships are implicit, or an uploaded tax code where completing one box requires following references across many others. For smaller workloads, she said developers may not need the whole vector store and could insert more chunks directly into context; enhanced memory remains a separate ChatGPT feature.

3. Real prompts expose failures that tidy public evals miss

Michelle’s critique of public instruction-following tests was methodological: constraints such as “exactly four words” or “three paragraphs” are common because code can verify them, not because they represent the hardest developer needs. Opted-in API data supplies more diverse examples—especially negative and ordered instructions—after identifying information is scrubbed and models categorize the anonymized prompts.
On prompting folklore, her “truth is always messy” answer preserved both sides. GPT-4.1 usually follows instructions “stated once and clearly,” so all caps, promised tips, or bribes are unnecessary; they also should not hurt, and developers running production workloads may discover task-specific techniques the model team has missed.
XML was recommended for structuring model inputs, not as a universal replacement for JSON. JSON can remain preferable when an output must plug directly into an application. Likewise, headings such as “response rules” or “instructions” were examples rather than magic tokens.
Tests found that repeating the user query or instructions at both the beginning and end of a long context outperformed placing them only at either end. The host objected that duplication can conflict with prompt-caching design; Michelle replied that putting instructions at the beginning can still preserve caching, depending on which large data blocks vary by user. “When we figure it out, we will do that,” she conceded.

4. Useful coding agents need persistence without collateral edits

The recommended persistence prompt tells GPT-4.1 to continue until the task is complete instead of repeatedly asking whether it should proceed. Michelle corrected the host’s interpretation: that sentence alone did not create a roughly 20% SWE-bench gain; it was the best-performing harness combined with the model’s post-training improvements.
Persistence creates its own failure mode when an agent rewrites files outside the request. OpenAI therefore built an extraneous-edits eval: GPT-4o made unrelated changes 9% of the time, versus 2% for GPT-4.1. The improvement followed the team’s recurring loop—hear a concrete complaint, build an eval, then track it through training.
Coding performance was decomposed into better diffs, correct repository exploration, compiling code, and test creation. GPT-4.1 scored about 55 on SWE-bench against o1’s 41, but the team resisted flattening all coding into one leaderboard: GPT-4.1 was particularly trained to navigate repos, while a reasoning model may outperform it on a self-contained file edit. As an internal anecdote, a researcher reported that GPT-4.1 completed 49 of 50 commits in a massive pull request.
Michelle’s deployment ladder starts with GPT-4.1, drops to Mini or Nano if they preserve quality with lower latency, and moves upward to a reasoning model when longer-horizon coherence is missing. Planning with a reasoning model and execution with a targeted model is promising, though “we’re all kind of figuring out the best way to use these models together.”

5. Vision gains reveal the value—and hazards—of new pre-training

Michelle highlighted GPT-4.1 Mini’s multimodal improvement and its different pre-training base. Unlike the coding, context, and instruction-following gains attributed heavily to post-training, she said that essentially all of the observed multimodal gains came from pre-training. She also said GPT-4.1 improved both screen-oriented and embodied-image tasks, while deferring to the pre-training team on how developers should choose between them.
Better perception even invalidated some internal evaluations: Mini and Nano could read signs in image backgrounds that prior models missed, altering the expected answers. The episode’s useful warning was that stronger models can create “different eval problems” by exploiting information the benchmark designer assumed was inaccessible.
The hosts described day-one fine-tuning for GPT-4.1 and Mini and asked whether Nano would follow. Michelle distinguished familiar supervised fine-tuning from preference fine-tuning, which she called underused for steering style; reinforcement fine-tuning is only for reasoning models, while preference fine-tuning offers pairs. The host said he thought reinforcement fine-tuning was still in alpha, and Michelle said the exchange cleared up confusion. Creative-writing improvements are being folded into future general models rather than released separately.

6. Caching, deprecation, and shared evals define the economic flywheel

Pricing is not a uniform reduction across the lineup: Michelle corrected the hosts that GPT-4.1 Mini is not cheaper than GPT-4o, although it is cheaper than full GPT-4.1. The larger lever is prompt caching, whose discount increased from 50% to 75% for these models.
“Blended pricing” is intended to make comparisons easier—for example, expressing GPT-4.1 as roughly 25% cheaper than GPT-4—not to prescribe a universal cached-to-uncached ratio. The team had no median cache rate available, leaving developers to model the mix for their own workloads.
Deprecating GPT-4.5 can eventually reclaim compute, but OpenAI will run models concurrently during the transition because API removals require “sufficient notice.” Michelle’s requested feedback loop is concrete: opt into API data sharing, or upload an eval whose inference OpenAI will fund if it can reuse it. The hosts said the data-sharing offer ran through April 30, while the eval program had no announced end date.

Snap-on: Tools of the Trades - [Business Breakdowns, EP.213]Random Ramblings April 2025