GPT-4.1: Building a Developer Workhorse

Why move from GPT-4.5 to GPT-4.1?

A developer using GPT-4.5 faced an unusual upgrade question: why switch to a model with a lower version number? In Latent Space’s April 2025 conversation with Michelle Pokrass and Josh McGrath, Michelle positioned GPT-4.1 as a substantial improvement over GPT-4o that was much smaller and cheaper than GPT-4.5. It did not beat GPT-4.5 on every intelligence evaluation, but she expected developers could replace much of their GPT-4.5 usage with it.

The family comprised GPT-4.1, GPT-4.1 Mini, and GPT-4.1 Nano, with improvements focused on instruction following, coding, and OpenAI’s first one-million-token context windows. Josh emphasized Nano’s speed for low-latency applications. Testing through OpenRouter had helped the team gather feedback on real developer workloads.

Josh explained that version numbers reflected the capability improvement users experienced, rather than model size or a training recipe. Nano and Mini had new pretraining runs; the larger GPT-4.1 had new mid-training. Michelle credited a substantial share of the gains to post-training, which extracted more capability after the earlier training stages. The team also incorporated some of GPT-4.5’s instruction-following strengths, without specifying whether GPT-4.5 directly taught GPT-4.1 through distillation.

The release had a defined product scope. The Realtime and Responses APIs already used somewhat different model checkpoints, and there were no plans at the time to bring GPT-4.1 to the Realtime API.

A million tokens must support more than retrieval

A large context window lets a model receive more information, but finding one fact among distractors is only one way to use it. Josh said single-needle retrieval tests were relatively easy to saturate. The harder work was reasoning across the input, which motivated two newly open-sourced evaluations: one for ordering and another for traversing graphs.

Two dimensions help distinguish long-context tasks: - Context density: Summarization uses much of the input; finding a hidden fact uses only a small fraction. - Order of access: Some tasks follow the input from beginning to end; others require jumping between distant pieces of information. Window size alone does not describe either demand.

GraphWalks tests the second dimension by placing a graph in the prompt as edge lists—lists of connections between nodes—and asking the model to perform a graph operation. The evaluator executes that operation to obtain the reference answer. Although the task is straightforward to implement in a short Python script, early model versions reportedly looped when they could not find an edge they expected to exist.

The underlying capability is multi-hop reasoning: following several connected pieces of evidence to answer a question. Among hundreds of documents, an answer might require visiting ten. Ordinary documents leave those connections implicit; GraphWalks supplies them explicitly to isolate whether the model can follow them. Preparing a tax return illustrates the practical demand: determining one box’s contents may require consulting several other boxes and the tax code. GraphWalks behavior reportedly carried over somewhat to internal evaluations using natural data, though no quantitative correlation was given.

Some GraphWalks examples have empty answers, a consequence of random graph sampling that also makes fabricated answers visible. The ordering evaluation adds a different challenge: more needles require more reasoning about their positions in context. Occasional cases where smaller models matched or beat larger ones were tentatively attributed to chance.

Long context changes retrieval choices

For smaller tasks, the larger window could let developers supply the complete input directly, potentially eliminating a separate retrieval store. It could also complement retrieval-augmented generation, where retrieved passages are placed in the model’s input, by accommodating more passages. The choice depends on whether the application benefits from supplying everything or selecting relevant material first.

Context capacity remained separate from product memory. At the time, GPT-4.1 served the API, while enhanced memory was a ChatGPT-only feature. Some memories were placed in context, but a larger window did not itself give API users ChatGPT’s memory system.

Evaluate the instructions developers actually give

Instruction-following evaluations face a selection problem: easy-to-grade requirements can crowd out useful ones. Code can readily check for exactly four words or three paragraphs. More consequential real-world instructions are often harder to judge. Diverse developer data helped the team identify recurring patterns, including instructions about what to avoid, and then design evaluations around them.

The described workflow anonymized prompts and removed identifying information before models categorized them. Feedback about a weakness—such as following ordered instructions—could then trigger a search for relevant examples without manually reading every prompt. A separate recommendation was to limit collaboration between evaluation authors and model developers, preserving objectivity and reducing incentives to game tests.

For prompting, the starting point was a clear instruction stated once. Models had improved at following that, while the benefits of all caps, bribes, or tips remained unsettled. Headings such as response rules and instructions were examples of prompt organization, not special keywords that needed to be copied verbatim.

Persistence needs a boundary

A persistence instruction addresses a familiar coding-agent failure: repeatedly asking whether to continue instead of completing the task. But it did not, by itself, explain the reported improvement on the coding benchmark SWE-bench. The response credited an effective agent harness—the setup used to run the model—combined with post-training improvements.

Persistence also needs scope control. One participant cited complaints about Claude Sonnet rewriting many files when only a small change was requested. OpenAI’s extraneous-edits evaluation checked whether every change related to the requested edit. The reported rate fell from 9% for GPT-4o to 2% for GPT-4.1, with dataset size and further test conditions unspecified. Developer complaints had become a measurable training target: finish the task while keeping edits relevant.

Prompt structure meets prompt caching

The recommendation for XML inputs concerned organizing prompt material. JSON outputs remained useful for responses consumed directly by an application. Those formats served different sides of the interface.

Placement mattered too. The team tested instructions and the user query at the beginning, at the end, and at both ends of the context. Repeating them at both ends worked best in those evaluations, although no workload or numerical improvement was specified. The explanation offered for early instructions was that the model could take them into account while processing subsequent material.

That creates a trade-off with prompt caching, which reuses unchanged prompt material across requests. Moving a changing query toward the beginning can reduce reuse. Stable instructions at the beginning can still receive cache hits, depending on where changing data appears. End-only instructions were not presented as an equally effective solution, so developers needed to weigh the tested placement preference against their application’s caching behavior.

Choose for the task, then for speed

GPT-4.1 was described as better than earlier non-reasoning models at planning and working through steps when prompted. Reasoning models retained an advantage in forming coherent plans over longer horizons. The selection rule was practical: use the fastest model that successfully completes the task.

The suggested procedure was: 1. Start with GPT-4.1 on the actual task. 2. If it handles the task easily, try Mini or Nano to reduce latency. 3. If it struggles with sustained reasoning, try a reasoning model. Another option was to use a reasoning model to plan and a more targeted model to execute. That architecture was endorsed as useful, while the best ways to combine models remained an open engineering question.

Coding training addressed several capabilities together: producing better diffs, exploring repositories, generating code that compiles, and writing tests. Different workloads could still produce different rankings. A questioner noted that GPT-4.1 led o1 on SWE-bench but trailed it on Aider; benchmark variants and harness conditions were not specified in that comparison.

A useful distinction was repository exploration versus editing supplied code. GPT-4.1 had been trained specifically to navigate repositories. A reasoning model might do better when it could consider an entire supplied file before making a change. Smaller models suited latency-sensitive features such as editor autocomplete or an immediately populated text-to-SQL draft. Mini was described as substantially better than GPT-4o Mini and approaching the older GPT-4o, a qualitative assessment without workload-specific measurements.

Coding also mattered internally: better models helped OpenAI develop its own products faster. An anecdote described GPT-4.1 helping a researcher with a large pull request, but no aggregate measure of internally generated code was given.

Better vision can expose a broken evaluation

Vision gains had a different origin. Mini’s new pretraining base was credited with improved vision results, and multimodal gains were attributed almost entirely to pretraining. That contrasted with the substantial post-training contribution to coding, instruction following, and long context. GPT-4.1 reportedly improved on both screen imagery, such as screenshots and charts, and real-world imagery; training mixed both without a disclosed balance.

Screen-based tasks attracted more evaluation attention partly because they were easier to grade. But better perception could undermine an existing test: Mini and Nano learned to read signs in image backgrounds, affecting the validity of some internal results. The models’ improvement exposed weaknesses in the evaluation itself.

These gains concerned interpreting images. At the time of the conversation, there were no plans to add image generation to GPT-4.1.

Migration, fine-tuning, and developer feedback

Deprecating a model releases compute gradually as developers migrate away. Advance notice for API removals delays those savings, but preserves time for developers to move their applications. That migration window was a deliberate operational trade-off.

Fine-tuning was ready at launch. The question identified GPT-4.1 and Mini as supported, with Nano to follow; the response confirmed day-one readiness. Preference fine-tuning, using paired examples to steer output style, received the strongest recommendation as an underused option distinct from the original supervised fine-tuning offering. Reinforcement fine-tuning was restricted to reasoning models and was tentatively identified as the offering still in alpha.

GPT-4.1 was positioned as a standalone developer offering, with reasoning models as another tool; OpenAI’s models did not necessarily build on one another. Creative-writing improvements were being incorporated more broadly, informed by appreciation for GPT-4.5’s humor, greentext, and nuance.

The closing request to developers was concrete: send feedback and share evaluations. The evals product let developers upload a test and opt into sharing it with OpenAI in exchange for covered inference costs. Those tests would help assess whether later models improved on developers’ needs. At the time, no end date had been announced for that offer. A separate API data-sharing offer ran at least through April 30; an extension was suggested but not confirmed.

A blended price still needs a workload

The final question returned to cost. The reported prompt-caching discount increased from 50% to 75% for the discussed GPT-4.1 models. Cache reuse therefore mattered alongside model choice and the balance between input and generated output.

Blended pricing combines those cost components into one comparison. GPT-4.1 being 25% cheaper than GPT-4o was offered as an example, but its input/output mix and caching assumptions were unspecified. No median cache-hit rate or general rule was supplied. The application-level questions remained: how much does it read, how much does it write, and how much input is cached? Those quantities determine whether a headline saving describes the workload being built.