Why Did Codex Suddenly Become So Slow? A Simple Task Ran for Dozens of Minutes, and I Realized Its Working Style Has Changed

In the last couple of days, while using Codex to build a project, I had a very distinct feeling: Why did it suddenly become so slow?

Before, when using Codex, especially for relatively clear development tasks, I would basically just throw the requirement in. It would read the project code, analyze a few steps, and quickly start modifying files. Simple requirements could be finished in a few minutes, and even slightly more complex ones wouldn't make me feel like I was waiting too long.

But a recent task left me baffled.

I just asked Codex to optimize an image referencing method in the project, which I thought was a fairly routine code adjustment. But once the task started running, a huge list of things appeared on the right side:

Review fallback core spec
Fallback classifier
Review fallback task1 quality
Review action quality
Review virtual backend spec
Virtual material docs
Virtual material frontend
Jieyun action layer
Review action spec
...

Some tasks took minutes, some took dozens of minutes, and some even ran for hours.

The key point is, the left side already showed:

1 file changed +93 -0

In other words, the code had actually been changed long ago, but Codex still hadn't finished; it was still constantly Reviewing, checking, and verifying.

My first reaction was:

I clearly only selected "Plan Mode," when did it switch to Agent Mode?

After studying it carefully and combining it with my recent experience using Codex, I found that the problem might not simply be "the model got slower," but rather Codex's way of handling development tasks is now different from before.

1. The Old Codex Was More Like a Programmer Sitting Next to You

My previous habit of using Codex was actually very simple.

For example, if an interface in the project needed modification, I would directly tell it:

Modify the pagination interface of UserController,
add a status parameter,
and adjust the corresponding Service query conditions.

My feeling about the previous entire process was roughly:

Read relevant code
↓
Understand the requirement
↓
Find the corresponding file
↓
Modify the code
↓
Tell me the modification result

This method was actually particularly suitable for daily development.

Because most of the requirements programmers actually encounter daily are simply not complex enough to require re-analyzing the entire system.

For example:

• Modifying an SQL;
• Adding a field;
• Adjusting an interface;
• Fixing a null pointer;
• Modifying a Vue page;
• Adding a button;
• Adjusting a configuration;
• Modifying a Docker deployment script.

The scope of these tasks themselves is very clear.

What I needed wasn't for the AI to perform a "technical audit" of the project, but rather:

Find the spot, change it, test it, done.

Previously, Codex gave me a very good experience in this regard.

But now it's clearly different.

2. The Current Codex Is Becoming More and More Like a True Agent

What I felt most strongly this time was the sudden appearance of a large number of tasks on the right side.

If it were just an ordinary code assistant, there would be absolutely no need for so many steps.

But from the perspective of an Agent, everything makes sense.

Now it might interpret a requirement as:

Receive user requirement
↓
Analyze requirement boundaries
↓
Scan project
↓
Find relevant code
↓
Judge impact scope
↓
Split tasks
↓
Design modification plan
↓
Execute code modification
↓
Check modification results
↓
Review
↓
Verify if other modules are affected
↓
Review again
↓
Output final result

This is no longer the same working method as before.

Before, it was more like:

"Help me change this piece of code."

Now it's more like:

"I'm handing this requirement over to you; you finish the whole thing yourself."

The latter sounds obviously more advanced, but problems also arise:

Many small requirements simply don't need such a heavy process.

It's like I just asked a programmer to change a field, but he first pulled in the product manager, testers, and architect for a requirements review meeting, then produced a technical proposal, then did a Code Review, and finally ran a round of regression testing.

The process is certainly more complete.

But I just wanted to change a field.

3. Why Is Codex Still Running When the Code Has Already Been Changed?

This was also the most confusing part for me this time.

The left side had already clearly shown:

1 file changed
+93
-0

Normally, the task should be almost finished by this point.

But on the right side, there were still many:

Processing
Review action quality
Review virtual backend spec
Review virtual material frontend
...

After I figured it out later, it was actually easy to understand.

"Code modification complete" and "Agent task complete" might now be two different things.

Previously, Codex's goal might have been:

Complete the code modification.

Now the Agent's goal is closer to:

Completely solve the problem raised by the user and verify the reliability of the solution.

So file modification is just one step in the entire task chain.

Suppose it thinks a requirement needs to go through:

Requirement understanding
→ Plan design
→ Modify code
→ Check code
→ Test
→ Review
→ Risk check
→ Final summary

Then even if the third step, "Modify code," is complete, the subsequent steps will still continue to execute.

Thus, the phenomenon the user sees is:

The code has clearly been written, so why is Codex still spinning there?

In fact, it's not stuck; it just thinks the task hasn't truly ended yet.

4. I Clearly Chose "Plan Mode," So Why Is It Still Like an Agent?

This was the part that most easily misled me this time.

My original understanding was:

Plan Mode = Only provide a plan

Agent Mode = Execute by itself

But based on the current usage experience, it can no longer be fully understood this way.

Now Plan Mode is more like:

Prioritize planning the task, then proceed according to the plan.

Rather than:

Prohibit Agent behavior, only allow outputting a text plan.

The difference between these two concepts is actually very large.

That is to say, what Plan Mode controls might be more about how Codex starts processing this task, rather than deciding whether it is an Agent.

Now Codex's underlying working method itself is becoming more and more Agent-like.

So even if you choose Plan, it might still:

• Read a lot of code;
• Analyze the repository;
• Create tasks;
• Call tools;
• Do verification;
• Do Review;
• Continue processing based on results.

This also explains why, even though I clearly didn't actively choose the so-called "Agent Mode," what I saw in the end was a very typical Agent workflow.

5. Why Did It Take Minutes Before, but Now It Might Take Dozens of Minutes?

There are actually several factors overlapping here.

The first is what was mentioned earlier: The number of task steps has increased.

Before:

Analyze → Modify

Now:

Analyze → Plan → Search → Modify → Verify → Review → Verify again

The single generation speed of the model might not be much slower, but as the number of tool calls increases, the entire task naturally gets stretched out.

The second problem is that the project context is getting larger and larger.

Especially, we programmers easily fall into a habit: using one conversation window continuously.

Today let Codex fix the login, tomorrow let it change the payment, the day after continue adjusting images, and then modify the database.

Slowly, a Session accumulates:

• A large amount of historical conversation;
• Read files;
• Modification records;
• Command execution results;
• Test logs;
• Git Diff;
• Previous task context.

Although long context is very helpful for large tasks, for a small requirement with only a few dozen lines of code, these things might become a burden instead.

So I am now increasingly inclined to:

After a relatively independent requirement is completed, start a new Session.

There's no need to stuff the entire project development lifecycle into the same conversation.

6. Just Because an Agent Is Stronger Doesn't Mean All Tasks Should Use an Agent

This is my biggest takeaway this time.

Everyone is pursuing Agents now.

AI automatically writes code, automatically tests, automatically commits, automatically Reviews, and maybe in the future, you can just throw a requirement in, and half an hour later the entire feature is developed.

This direction is definitely not wrong.

But there is a very real problem in actual development:

Task complexity varies.

For example, a requirement like this:

Add an avatar field to the User table,
and adjust the corresponding Entity, DTO, and Mapper together.

If the model can quickly locate 4 files and then modify them directly, it might be done in two minutes.

But if the Agent first analyzes the database design, then scans all user modules, then studies field compatibility, and then generates Specs, Reviews, tests...

It might end up taking 20 minutes.

From an engineering quality perspective, it might be more rigorous.

But from a development efficiency perspective, it might not be higher.

So the truly good AI programming method shouldn't be:

Hand everything over to the Agent.

But rather:

Decide the Agent's level of involvement based on task complexity.

7. I've Also Started Adjusting How I Use Codex Now

After these few experiences, I now actively control the task scope.

Before, I might have directly written:

Optimize the image referencing method in the experience center.

This sentence might be very understandable to a human.

But for an Agent, the word "optimize" is too broad in scope.

It might think:

What does optimization mean?

Does it need a redesign?

Does the frontend need adjustment?

Is the backend affected?

What about the original image data?

Is historical data compatible?

Is a fallback needed?

How to handle exceptions?

Thus, an originally very simple requirement gets expanded into a system-level task.

Now I prefer to write like this:

Modify the image reference logic in the xxx module.

Only check code directly related to this function,
do not refactor other modules,
do not expand the scope of modification.

Prioritize completing the code modification directly,
and complete the necessary verification.

Even for particularly simple problems, I will directly tell it:

Do not scan the project globally,
only modify the files involved in the current function.

The actual experience is indeed much better.

8. Small Requirements, Medium Requirements, and Refactoring Tasks Are Best Handled Separately

I now roughly categorize Codex tasks into three types.

The first type is daily small requirements.

Like modifying SQL, adjusting interfaces, adding fields, fixing bugs, adjusting Vue pages, modifying configurations.

For these tasks, I care more about:

Speed.

Let the model understand the necessary context and then modify directly; there's no need to re-study the entire project.

The second type is medium-sized features.

For example:

Add an order refund module
Add a new payment channel
Add a user points system
Add backend permission features

This kind is suitable for letting Codex analyze a bit more.

Because it indeed involves multiple modules like Controller, Service, database, frontend, permissions.

The third type is truly large tasks.

For example:

Refactor the payment system
Migrate the database
Split microservices
Upgrade Spring Boot
Redesign the image storage architecture

For this kind of task, I am actually very willing to let the Agent run slowly.

Because if the AI can spend half an hour scanning dozens of files for me, finding potential risks, completing modifications, running tests, and finally Reviewing it all, I think it's very worthwhile.

So the key is not:

Whether the Agent is good or not.

But rather:

Whether this task is worth starting the full Agent workflow.

9. Codex Slowing Down Might Also Mean AI Programming Has Entered Another Stage

From another perspective, this change is actually quite interesting.

At the earliest, our use of AI programming was essentially still:

Programmer writes code
AI helps complete it

Later it became:

Programmer asks questions
AI generates code

Even later:

Programmer describes requirements
AI modifies the project

And now it's gradually becoming:

Programmer defines the goal
AI completes the task itself

This last layer of change is very critical.

Because when AI changes from a "code generator" to a "task-executing Agent," it inevitably needs to add many things it didn't have before:

Planning, tool calling, context management, testing, verification, Review, failure retry...

These capabilities will make AI programming stronger and stronger, but they will also bring new problems:

Latency.

Previously, our measure of AI programming tools was simple:

Is the code generation fast?

In the future, we might have to change the standard:

How long does it take to complete the entire task?

These two metrics are actually completely different.

One model generates code in 5 seconds, but you still need to spend half an hour modifying it yourself.

Another Agent might run for 15 minutes, but in the end, it directly gives you a basically usable result.

Which one is actually faster?

It's really not certain.

10. Finally: It's Not That Codex Simply Got Slower, But That It Has Started "Doing More Things"

So looking back at my initial question:

Why was Codex so slow today?

Now I think the answer cannot be simply attributed to slow servers, slow models, or insufficient computer performance.

At least judging from this task's performance, the bigger reason might be:

Codex is further transitioning from a "code assistant" to an "Agent engineer."

Before, if you asked it to change code, it changed code.

Now, if you ask it to solve a problem, it might really consider itself the person in charge of this requirement:

Analyze the requirement, scan the project, design a plan, modify the code, check the impact, Review, test, and finally tell you:

Done.

The capability is indeed stronger.

But the cost is that sometimes I just want it to help "tighten a screw," but it first performs a comprehensive inspection of the entire project.

So my approach to using Codex has now become very clear:

For small requirements, limit the scope and let it change quickly; for medium requirements, let it analyze appropriately; for large requirements and refactoring, truly leverage the Agent's value.

At the same time, try not to let a Session grow infinitely long. After an independent requirement is finished, starting a new session is often more comfortable than continuing development while dragging tens or even hundreds of thousands of tokens of context.

As AI programming has developed to this point, I think what we need to learn is no longer just "how to write Prompts."

More importantly:

When should we let AI think more, and when should we tell it to cut the crap and just get to work.

This might be what truly affects development efficiency in the Agent era.

Before, we needed to learn how to manage programmers.

Now, we might also need to learn how to manage AI programmers.