A Performance Win With No Benchmark In It

Here's the deal: the Codex update OpenAI just previewed contains no eval scores. It contains these numbers instead. Opening a 741-turn conversation weighing 231MB dropped from 27.6 seconds to 1.7 seconds — a 94% cut. Under the same conditions, renderer memory growth fell roughly 88%, and round-trips between client and server fell roughly 98%.

The figures surfaced on August 14 through an internal Slack screenshot posted by Andrew Ambrosino, who leads Codex. This wasn't a formal release announcement; it was an internal performance report that made it outside. The update itself was described as shipping that same week.

What's interesting is what got fixed. GPT didn't get smarter. The client that manages your conversation history got less stupid. And in the current state of the coding-agent race, that turns out to be a competitive axis in its own right.

Where Codex Sits Right Now

Codex is OpenAI's coding agent, launched in 2025. It started as an async cloud task runner and has since grown a CLI, IDE extensions and desktop apps. The main mode today is terminal-driven: it reads your repo, edits files, runs tests, iterates. In effect OpenAI took the working pattern Claude Code established and rebuilt it on its own models, then kept extending the surface area.

Ambrosino runs that organization. In a recent interview he argued that implementation has become cheap and taste is the scarce resource — a framing that connects directly to this work. If writing code is table stakes now, what's left to compete on is how smoothly a person can actually operate inside the tool for hours.

The market itself looks nothing like it did a year ago. In 2025 autocomplete was the product. In 2026 the baseline is an agent that plans, edits across many files, and verifies its own work. OpenAI, Anthropic, Google, Cursor and a pile of open-source tools are all fighting for the same seat, and as model quality converges, the deciding factors slide down toward integration quality and operational reliability.

It's also not an accident that these numbers arrived as an internal screenshot rather than a changelog entry. Leaking a performance win into developer circles ahead of the formal release is its own kind of launch.

What 741 Turns Actually Describes

Get a feel for the scenario first. 741 turns means a human and an agent exchanged messages 741 times in a single session — reading files, running tests, seeing failures, patching, re-running, all day. A 231MB transcript means file contents, terminal output and tool-call results piled up inside it.

A year ago this was a pathological edge case. Coding assistants were used at the "write me this function" scale, and if a thread got long you just started a new one. Then agents started planning their own work and editing across a codebase, and sessions began lasting hours or days.

The problem is that client software wasn't designed for that. Hold the whole transcript in memory, recompute everything on each render, ask the server whenever state changes — none of that hurts at twenty turns. At seven hundred, it collapses.

27.6 seconds is what that collapse feels like. If reopening a session costs you half a minute, the quality of the model behind it stops mattering.

And latency like that doesn't just annoy people; it reshapes how they work. Slow reopen means you keep sessions short. Short sessions mean you don't hand the agent big jobs. Eventually a folk rule forms — "don't give the agent anything large" — and that rule is a product of client performance, not model capability. Publishing these numbers is, in part, an attempt to break that habit.

What Got Fixed

Metric Before After Change
741-turn conversation load 27.6s 1.7s ~94%
Renderer memory growth baseline — ~88% lower
Client↔server requests baseline — ~98% fewer
Test transcript size 231MB 231MB unchanged

The three metrics moving together tells you the shape of the fix. A 98% drop in requests means the old client was firing hundreds of granular calls just to paint a screen. An 88% drop in memory growth means it stopped holding the entire history resident and started holding only what it needs. The 94% load-time win falls out of those two.

The public changelog shows this work has been landing for weeks. CLI 0.147.0, shipped August 7, added the ability to "organize conversations into persistent, manually ordered sections and browse long transcripts incrementally," plus paginated transcript history — fetch what you need, not everything. The numbers Ambrosino posted read as the results report for that effort under realistic load.

None of the individual techniques are novel: lazy loading, virtualized rendering, request batching, caching what hasn't changed. This isn't new computer science. It's an agent client finally paying down the engineering basics it skipped while growing quickly.

One misreading is easy to fall into. Faster loading does not mean the model now remembers all 741 turns. The context window is unchanged, and only a slice of that transcript ever reaches the model. What improved is storage and display, not the model's field of view. Conflating the two produces the wrong expectation — that context will stop getting dropped.

The same weeks brought other Codex changes: a Linux desktop preview on August 11, along with the ability to import settings and recent work from Claude Code and Cursor. That second one is unambiguous about intent — reduce the friction of switching in.

What Each Side Gets

OpenAI gets session time. The battleground in coding agents is shifting from model quality to session persistence. The longer a developer stays inside one tool, the thicker the context it accumulates and the higher the cost of leaving. Turning 27 seconds into 1.7 is about not breaking that stay.

OpenAI also gets cost. Cutting client-server requests by 98% cuts infrastructure load by roughly the same factor. With Codex usage in the millions, that lands directly on cost of goods. User experience and unit economics improving from the same change is a rarer alignment than it sounds.

Developers get to stop throwing sessions away. Until now the standard practice was to abandon a thread once it got slow and re-explain the context in a fresh one. At 1.7 seconds there's no reason to. Multi-day refactors and long debugging campaigns can live in one session.

Enterprise teams get predictability. "It falls over past a certain size" is a serious objection during procurement. Being able to answer "does it survive our monorepo?" with a number changes that conversation.

Competitors get a benchmark. Now that a specific condition — 741 turns, 231MB — is public, other agents will face pressure to publish comparable figures. A client-performance benchmark now sits next to the model benchmark.

When Tooling Lost on Weight

Developer tools have been decided by performance before.

Eclipse versus IntelliJ is the canonical case. Feature parity was close; responsiveness on large projects was not. As the perception spread that Eclipse bogged down on big codebases, Java developers migrated. Daily latency beat the feature matrix.

Atom versus VS Code repeated it. Both were Electron apps, but large-file handling differed sharply. Atom was eventually discontinued and VS Code took the market.

The counterexample matters too: Sublime Text was faster than anything else at the time and still lost to VS Code on extensions and price. Speed is necessary, not sufficient.

Git is worth one more mention. Linus Torvalds's top requirement was speed — branch switching and commits had to be instant on something the size of the Linux kernel — and that constraint drove the design that displaced its competitors. Past a certain scale of subject matter, performance overwhelms features. Coding agents are entering that zone now.

Expect the same shape here. Model quality gets matched within months. Client performance and integration depth are accumulated engineering, and they take longer to copy.

How Competitors Respond

Anthropic's Claude Code is terminal-native and light by construction. It has handled long-session context through compaction — summarize when the window fills and continue — which has always drawn complaints about losing detail in the summary. Codex's approach changes storage and retrieval rather than summarizing, so they're different fixes. They're also not mutually exclusive, and convergence toward both seems likely.

Cursor wins on IDE integration, which also means inheriting the IDE's performance ceiling. SpaceX's acquisition gave it more resources; where those go is still unclear.

Google competes with Gemini CLI and its adjacent tooling. Long context has been a Gemini strength for a while, so client performance is the piece that has to catch up.

Open source is a live variable. The Codex CLI is on GitHub, so this optimization is inspectable at the code level, and good ideas move between agent tools quickly — one ships a plan mode and something similar appears elsewhere within weeks.

That client performance is now a competitive axis is itself a maturity signal. Early on the question was "does it work." Then "how smart is it." Now it's "does it hold up if I leave it running all day." That's the question you ask about a work environment, not a utility. Editors went through the exact same progression.

So What Actually Changes

For developers, your working habits are worth revisiting. If you've been avoiding long sessions, that reflex may be obsolete. But again — faster loading is not a bigger context window. Don't confuse the two.

For team leads, add a line to your evaluation. Comparing coding agents on model benchmarks alone misses the failure mode teams actually hit. Run a session for several days on your largest repo and measure load time and memory. Put a 300-turn run on your biggest monorepo in the comparison table.

For people building tools, the direction is clear. The bottleneck in agent UIs is usually state management and rendering, not model calls. That there was 98% of request volume to remove suggests most agent clients have similar slack in them.

For everyone else, little direct impact — but the trend toward coding agents running continuously is worth watching. When the speed of making software changes, the software you end up using changes too.

For companies marketing AI tools, the framing shifted. Announcements have always starred the model: eval scores, context length, price per token. The numbers that got attention here were 27.6 and 1.7 seconds. Speaking in units users actually feel landed harder. Expect more of it.

🥄 Three Things You're Probably Wondering

— Is this an official OpenAI announcement? Not a formal one. The figures come from an internal Slack screenshot shared by Codex lead Andrew Ambrosino. That said, the public changelog from early August already contains work in the same direction — persistent sections and paginated history — so the context checks out.

— Is 741 turns a realistic condition? It's on the extreme end, which is the point of a stress test. But multi-hundred-turn sessions aren't rare under current agent usage, and 231MB is a very believable transcript size for one.

— Does this make Codex better than Claude Code? Too early to read it that way. These are improvements against Codex's own previous version, not a cross-tool comparison, and the two are structured differently enough that a like-for-like measurement is hard. Measure on your own repo. Tool choice still hinges more on model quality, integration breadth, and fit with how your team works.

References

Numbers and criteria are as of announcement and may change.