gpt-5 vs gpt-5-codex

Gpt-5-codex takes very long as compared to gpt-5, I also saw this problem while using Codex CLI

GPT-5 Codex can simply take more steps for the same input, and usually, that’s exactly what happens.

Remember that each iteration or tool call reloads the entire previous context, not just the new result.
This is also a side effect of everything being funneled through the main context, with no helper agents handling reads or writes.

You might even have a piece of outdated code sitting in the context — and yet, with every tiny change, it’s still carried along in the context, inflating it further.

In the UI and logs, it only shows you the new tokens, not the full context.

Each read is added to the context, so when you read file 1 and then file 2, you’re actually processing three reads total:
first file 1, then file 1 + file 2 together — so three files in total, even though you only really read two.

This causes the growth to be quadratic, meaning the more iterations you have, the heavier the load becomes.

In reality, GPT-5 Codex was supposed to be more efficient.
But in practice, with a single request, it can drain the entire 5-hour limit if things go wrong.

That’s because the situation is misinterpreted by looking only at the new tokens, without taking into account the quadratic growth that happens behind the scenes.

So, with this kind of quadratic growth, if the model makes 5 function calls vs. 45, the GPU load difference will be extreme.

The attention mechanism scales quadratically, meaning that every new token doesn’t just add a small, linear cost —
it increases the total cost by the square of all tokens combined.

If anyone’s curious about the description, here it is.

Strategy Steps (context lengths) Total cost Overhead vs. one-shot 70k Multiplier vs. 70k one-shot
This is the attention computation cost for the same total number of tokens:

| Strategy | Steps (context lengths) | Total cost | Overhead vs. one-shot 70k | Multiplier vs. 70k one-shot |
|--------------|------------------------------|----------------|--------------------------------|---------------------------------|
| One-shot: add 50k at once | 70,000 | 4,900,000,000 | – | 1.00× |
| 5× in 10k increments | 30k, 40k, 50k, 60k, 70k | 13,500,000,000 | +8,600,000,000 | 2.7551× |
| 20× in 2.5k increments | 22.5k, 25k, …, 70k | 46,937,500,000 | +42,037,500,000 | 9.5791× |

Interpretation:

The “square at the bottom” (self-attention) and the “triangle at the top” (progressively reloading longer context) combine into a sum of squares.
Hence the explosion: 5 steps cost about 2.76× more than a one-shot, and 20 steps cost nearly 9.58× more.

!Image

That’s correct, right?

Design takeaway:
If you recompute the full context each time, you move from a pure quadratic cost to a sum of squares.

One-shot is always the most computationally efficient,

If you factor in the cost reduction for cache, the problem might drop by about 4×, but that’s still not much given the scale of this explosion.
The GPU still suffers, and the model itself is weaker.

So, introducing GPT-5 Codex doesn’t solve the problem — it actually makes it worse in this situation.
Just imagine the scale with several prompts, each running 50 iterations.

Stepping must be paired with iterative summarization or RAG
to stay in the linear regime — loading only snapshots, not the entire previous buffer every time.

GPT-5 Codex can simply take more steps for the same input, and usually, that’s exactly what happens. Remember that each iteration or tool call reloads the entire previous context, not just the new result. This is also a side effect of everything being funneled through the main context, with no helper agents handling reads or writes. You might even have a piece of outdated code sitting in the context — and yet, with every tiny change, it’s still carried along in the context, inflating it further. In the UI and logs, it only shows you the new tokens, not the full context. Each read is added to the context, so when you read file 1 and then file 2, you’re actually processing three reads total: first file 1, then file 1 + file 2 together — so three files in total, even though you only really read two. This causes the growth to be quadratic, meaning the more iterations you have, the heavier the load becomes. In reality, GPT-5 Codex was supposed to be more efficient. But in practice, with a single request, it can drain the entire 5-hour limit if things go wrong. That’s because the situation is misinterpreted by looking only at the new tokens, without taking into account the quadratic growth that happens behind the scenes. So, with this kind of quadratic growth, if the model makes 5 function calls vs. 45, the GPU load difference will be extreme. The attention mechanism scales quadratically, meaning that every new token doesn’t just add a small, linear cost — it increases the total cost by the square of all tokens combined. If anyone’s curious about the description, here it is. Strategy Steps (context lengths) Total cost Overhead vs. one-shot 70k Multiplier vs. 70k one-shot This is the attention computation cost for the same total number of tokens: Strategy Steps (context lengths) Total cost Overhead vs. one-shot 70k Multiplier vs. 70k one-shot One-shot: add 50k at once 70,000 4,900,000,000 – 1.00× 5× in 10k increments 30k, 40k, 50k, 60k, 70k 13,500,000,000 +8,600,000,000 2.7551× 20× in 2.5k increments 22.5k, 25k, …, 70k 46,937,500,000 +42,037,500,000 9.5791× > Interpretation: > The “square at the bottom” (self-attention) and the “triangle at the top” (progressively reloading longer context) combine into a sum of squares. > Hence the explosion: 5 steps cost about 2.76× more than a one-shot, and 20 steps cost nearly 9.58× more. !Image That’s correct, right? Design takeaway: If you recompute the full context each time, you move from a pure quadratic cost to a sum of squares. One-shot is always the most computationally efficient, If you factor in the cost reduction for cache, the problem might drop by about 4×, but that’s still not much given the scale of this explosion. The GPU still suffers, and the model itself is weaker. So, introducing GPT-5 Codex doesn’t solve the problem — it actually makes it worse in this situation. Just imagine the scale with several prompts, each running 50 iterations. Stepping must be paired with iterative summarization or RAG to stay in the linear regime — loading only snapshots, not the entire previous buffer every time.

This is all interesting, but what can we do as users?

@alexx-ftw

Take part in building open software and be aware of your impact.
Don’t give in to the narcissistic opinions of those who dismiss the work of developers and claim they are the ones driving AI just by pumping in cash and counting gigawatts.

That’s as illusory as thinking you can fly to the Moon by building a big enough steam engine.
A rocket engine uses energy wisely, and that’s why it’s more efficient. :)

When Craig Mundie (Senior VP at Microsoft) criticized Open Source for a lack of innovation and for destroying intellectual property, Torvalds replied:

I wonder if Mundie has ever heard of Isaac Newton. He is famous not only for laying the foundations of mechanics (and the beginnings of the theory of gravity, which most people remember, including the story about the apple), but also for saying:
“If I have seen further, it is only by standing on the shoulders of giants.”

"What I cannot create, I do not understand."

— Richard Feynman

And Greg Brockman, in an interview, claimed that right now software isn’t the problem — only computational power is. :)

It’s developers who create AI — and who use it the most.

Just to be clear, this is a slightly joking comment :)

Cheers! :)

@alexx-ftw Take part in building open software and be aware of your impact. Don’t give in to the narcissistic opinions of those who dismiss the work of developers and claim they are the ones driving AI just by pumping in cash and counting gigawatts. That’s as illusory as thinking you can fly to the Moon by building a big enough steam engine. A rocket engine uses energy wisely, and that’s why it’s more efficient. :) And Greg Brockman, in an interview, claimed that right now software isn’t the problem — only computational power is. :) It’s developers who create AI — and who use it the most. Cheers! :)

You might be using Gigawatts yourself with those replies HAHAHAH

The brain consumes just 20W — about the same as a night lamp — while surpassing the best computers in computational power.

The question is: how much are you using to answer this question? :)

Hahahaha!

Besides, we’re in the Codex issues section — this isn’t a gossip forum, but a place for developers who actually want to participate in the project’s growth.
So I don’t see what’s so strange about that.

If someone isn’t interested, why even come here?
They can always read a guide on how to write a prompt to get a nice little calculator, instead of taking part in discussions about real software development.

But I know it rubs some vibe coders the wrong way that there are people building the very software that lets them play at programming. :)

So, for the average vibe coder, just looking at the code might make it hard to believe that it was written by an ordinary human being. :)
It might even bruise their programming ego.

PS. Besides, as we can see from the current GPT-4o situation, doing something secretly is less welcome than doing it openly.
So why not just explain what the problem is?

GPT-5 Codex can simply take more steps for the same input, and usually, that’s exactly what happens. Remember that each iteration or tool call reloads the entire previous context, not just the new result. This is also a side effect of everything being funneled through the main context, with no helper agents handling reads or writes. You might even have a piece of outdated code sitting in the context — and yet, with every tiny change, it’s still carried along in the context, inflating it further. In the UI and logs, it only shows you the new tokens, not the full context. Each read is added to the context, so when you read file 1 and then file 2, you’re actually processing three reads total: first file 1, then file 1 + file 2 together — so three files in total, even though you only really read two. This causes the growth to be quadratic, meaning the more iterations you have, the heavier the load becomes. In reality, GPT-5 Codex was supposed to be more efficient. But in practice, with a single request, it can drain the entire 5-hour limit if things go wrong. That’s because the situation is misinterpreted by looking only at the new tokens, without taking into account the quadratic growth that happens behind the scenes. So, with this kind of quadratic growth, if the model makes 5 function calls vs. 45, the GPU load difference will be extreme. The attention mechanism scales quadratically, meaning that every new token doesn’t just add a small, linear cost — it increases the total cost by the square of all tokens combined. If anyone’s curious about the description, here it is. Strategy Steps (context lengths) Total cost Overhead vs. one-shot 70k Multiplier vs. 70k one-shot This is the attention computation cost for the same total number of tokens: Strategy Steps (context lengths) Total cost Overhead vs. one-shot 70k Multiplier vs. 70k one-shot One-shot: add 50k at once 70,000 4,900,000,000 – 1.00× 5× in 10k increments 30k, 40k, 50k, 60k, 70k 13,500,000,000 +8,600,000,000 2.7551× 20× in 2.5k increments 22.5k, 25k, …, 70k 46,937,500,000 +42,037,500,000 9.5791× > Interpretation: > The “square at the bottom” (self-attention) and the “triangle at the top” (progressively reloading longer context) combine into a sum of squares. > Hence the explosion: 5 steps cost about 2.76× more than a one-shot, and 20 steps cost nearly 9.58× more. !Image That’s correct, right? Design takeaway: If you recompute the full context each time, you move from a pure quadratic cost to a sum of squares. One-shot is always the most computationally efficient, If you factor in the cost reduction for cache, the problem might drop by about 4×, but that’s still not much given the scale of this explosion. The GPU still suffers, and the model itself is weaker. So, introducing GPT-5 Codex doesn’t solve the problem — it actually makes it worse in this situation. Just imagine the scale with several prompts, each running 50 iterations. Stepping must be paired with iterative summarization or RAG to stay in the linear regime — loading only snapshots, not the entire previous buffer every time.

Not sure I fully understood everything here, but I am one-shotting though. Or do you mean the model, behind the scenes, isn't?

@Martibis

Sure, you can send a single prompt, but while generating the response, the model might search through 20 files in the background before returning an answer.
One question, one answer — but 20 iterations behind the scenes.

Notice that even switching between “think” and “response” will trigger the entire round all over again.
And the agent can think, act, think again, and so on — repeating the cycle each time.

Each such transition causes a quadratic increase in usage if you keep everything in the main context.

You asked why GPT-5 Codex runs longer and whether it needs more GPUs, so here’s the answer :)
Compared to GPT-5, GPT-5 Codex triggers more iterations/transitions, which makes the quadratic growth steeper.
GPT-5, with fewer passes, keeps that quadratic factor smaller.

!Image

Abstraction is the cost of generalization

Context Engineering

Antropic Tools Agent

So, what I wrote applies to a single prompt and a single response,
but with a different number of iterations happening in the background during its generation.

So, if you read with a 20k context, two files of 100 lines separately instead of one-shot, you’re increasing the quadratic growth.

That’s why, under the hood, there should be an agent_read that iteratively searches through files, loading only the current fragment without dragging along the previous ones, and then drops a snapshot once it finds what it needs.

Right now, everything gets funneled through the main context, so even unnecessary fragments stay there, inflating the cost.

Here’s a clearer version:

Imagine you go to the kitchen to grab a Coke and bring it back to your room.
Then you go to get a second Coke, but for some reason, you also carry the first one with you.

In the end, you have 2 cans in your room,
but you’ve spent enough energy to carry 3 cans total.
That’s exactly what’s happening under the hood.

With each extra trip, the cost grows quadratically:

On the third trip, you carry the previous two cans with you,
so you end up with 3 cans, but the energy spent equals carrying 6.

Now translate this to files:

You read file 1,

then, when reading file 2, the system loads file 1 + file 2 into context.

So even though you’ve only read 2 files,
the compute cost is as if you had processed 3 files —
and the imbalance only worsens as you keep iterating.

You can easily check this by comparing input vs. cache using /status.
With each iteration and response, you’ll see a massive explosion in the cache size.

The same thing happens with context.
The input value masks this issue, because it only counts the new tokens —
but in reality, that’s not the full picture.

It’s possible that GPT-5 Codex addresses the problem by using fewer new tokens in input/output.
However, the overall consumption is still much higher than with GPT-5.

That actually makes sense, I'll give some thought on how I can improve this from my end as well. I already cut down my initial input tokens by 35% which I assume should help some at least!

I am hoping folks would stop responding to AdsQnn with a full quote and a single line of text.

@Martibis

It’s always worth compacting things before tackling a more complex task, too.
Alternatively, if it’s not an issue, you could start new sessions more often.

One interesting option is that you can, for example, set up Codex as an MCP for Codex itself,
and in one-shot mode, delegate tasks like finding a file or making an edit —
bypassing the main context entirely.
If you delegate each task independently with a clean context,
you’ll achieve, to some extent, the effect of a side agent.

I’ll add more: this isn’t magic.
If you look at the code calmly, without imagining some mystical agents, it’s all straightforward.

Snapshots in context are just a standard computer science practice, analogous to:

pointers,

abstract methods,

or .so libraries.

They simply give you references where needed, instead of overflowing the stack. :)

Here, the context acts as a stack, and the snapshot functions like a pointer.

I hope no one feels hurt by my post — I truly believe I shared it in the right place, expecting that the people here are simply curious and open to discourse.

Maybe someone from the team will see it, and even if not directly, it might inspire them in some way. :)

Thank , and good luck!

I am hoping folks would stop responding to AdsQnn with a full quote and a single line of text.

What is the Quotation tool for if not for quoting?

This kind of ties into the situation, as the context has somewhat exploded :)
The model probably feels the same way when it keeps getting the previous context over and over.

I think this could be a good topic for Discussions.

Models have different behaviors, and each task has randomness associated with it. It's difficult to diagnose the issue without seeing the actual requests.

@dedrisian-oai

https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

We’re now seeing a shift in how engineers think about designing context for agents. Today, many AI-native applications employ some form of embedding-based pre-inference time retrieval to surface important context for the agent to reason over. As the field transitions to more agentic approaches, we increasingly see teams augmenting these retrieval systems with “just in time” context strategies.

Rather than pre-processing all relevant data up front, agents built with the “just in time” approach maintain lightweight identifiers (file paths, stored queries, web links, etc.) and use these references to dynamically load data into context at runtime using tools. Anthropic’s agentic coding solution Claude Code uses this approach to perform complex data analysis over large databases. The model can write targeted queries, store results, and leverage Bash commands like head and tail to analyze large volumes of data without ever loading the full data objects into context. This approach mirrors human cognition: we generally don’t memorize entire corpuses of information, but rather introduce external organization and indexing systems like file systems, inboxes, and bookmarks to retrieve relevant information on demand.

https://github.com/anthropics/claude-cookbooks/blob/main/tool_use/memory_cookbook.ipynb

Computational cost: Processing large contexts is expensive - attention mechanisms scale quadratically

I say:

This causes the growth to be quadratic, meaning the more iterations you have, the heavier the load becomes.

<img width="480" height="98" alt="Image" src="https://github.com/user-attachments/assets/e2767a4e-fc7d-4daa-9813-bcd65a805541" />

In the image you can see a cache that you’d pay millions of tokens × 0.125 for. This clearly shows that the entire context is being reprocessed multiple times. The input tokens are enormous, even though I only asked 2 questions. The cache is exactly 10 times bigger—just as I said. In Claude, the same thing would be only ~150k input tokens.

5× in 10k increments 30k, 40k, 50k, 60k, 70k 13,500,000,000 +8,600,000,000 2.7551×

20× in 2.5k increments 22.5k, 25k, …, 70k 46,937,500,000 +42,037,500,000 9.5791×
If you read everything I wrote, you’ll notice that I was writing about this very thing two months ago.

9.5791× correct ? Input -> cache

The same happens with attention cache on two tokens: instead of q=2, k=2, v=2, after caching it becomes q=1, k=2, v=2 (in simplified terms). But it’s still not 1,1,1. So cache isn’t neutral in terms of speed if you keep iterating with the full context.

I’d call this the “context growth trap” 🚨.

• In a single step, attention is linear in context length

(e.g. q=1, k=N, v=N ⟹ O(N)).

• But if you keep appending tokens and reprocess the full context each time,

the total cost accumulates to quadratic O(N²).

In terms of cost, it’s not neutral either, because it costs 0.125.

You’re right that this thread fits better in the Discussions section. However, I’ve already covered the topic quite extensively, so from now on I won’t bother anyone with it anymore. That’s why I’m attaching it here, hoping no one will mind. I enjoy using Codex, so it would be great if it could run as efficiently as possible. Thank you!