Why Codex tasks slow down: When to split long conversations and how to hand them off

July 30, 2026Articles

When you keep using Codex, a task that felt fast at first can gradually start taking longer to answer.

The command itself may finish quickly, but Codex can take a long time to decide what to do next. It may also forget an earlier decision or repeat an investigation.

I often keep one task open for a long time, carrying the same conversation from design to implementation, fixes, and additional research. Keeping the history feels reassuring, but I had not paid much attention to when a task had become too large to continue.

Then I came across an X post that investigated a Codex task running continuously for eight days and summarized why it became slow and what to do about it.

This article explains why long tasks become heavy, and how to choose between /compact, fork, and handing the necessary context to a new task. The examples are based on the AI Jiten production environment. The information is current as of July 29, 2026.

Here is the story behind this article

The starting point was an X post by 智见AI-大鹏.

According to the author, the task under investigation had been running for eight days. Its record file had grown to 1.3 GB, and even after compaction it processed about 98,000–117,000 tokens per run.

The total time spent on Git commands was less than 11 seconds, but the full sequence took 43 minutes.

This suggests that the main delay was not Git or shell commands, but the decisions Codex made before and after each tool call.

Codex decides what to do next after every command

Codex does not execute one instruction from beginning to end in a single step. Roughly speaking, it repeats the following loop:

Check the current state
Have the model decide what to do next
Read or edit files and run a command
Add the result to the task
Have the model decide what to do next

For example, searching for related files, reading configuration, changing code, running tests, and fixing a failed test can require many separate model decisions.

A short task contains a relatively small amount of information. As past conversations, research notes, command output, errors, and reasons for changes accumulate, the context that must be considered at each decision grows.

When a model is called repeatedly with a context of around 100,000 tokens, each command can still finish in seconds while the overall task develops a long wait time.

The entire 1.3 GB history was not sent to the model every time

The numbers need to be separated here.

The 1.3 GB mentioned in the post was the saved task record. It does not mean that the entire 1.3 GB was sent as model input on every request.

The reported model context after automatic compaction was about 98,000–117,000 tokens. That is still very large, but it would be inaccurate to interpret it as “the model reread 1.3 GB of text every time.”

OpenAI also provides Prompt Caching, which can reuse the beginning of an identical prompt to speed up processing.

So the model may not process everything from scratch on every call. Even so, maintaining and compacting a huge context, then searching it for the information needed to make a decision, still creates overhead.

It is also impossible to say that all 43 minutes were caused by context handling. Server wait time, network conditions, retries, and the depth of reasoning may all contribute.

The natural interpretation is not that this case discovered the single cause of all Codex slowdowns. Rather, in an unusually large long-running task, work outside the tool commands had become the main bottleneck.

Long tasks affect judgment, not only speed

More context can cause more than slower responses.

OpenAI documentation explains that continually adding research notes, test logs, stack traces, and command output to a long task can bury important information and reduce reliability.

This state is often described with these terms:

Context pollution: important information is buried under a large amount of noise
Context rot: low-relevance history accumulates and the model’s judgment quality declines

If Codex forgets an earlier decision or proposes a rejected approach again, it does not necessarily mean that the history disappeared.

The information may still be present, but it may be harder for the model to retrieve the right parts consistently.

Keeping one task for a long time is not automatically wrong

It may sound as though every task should be split quickly. Splitting too often, however, means explaining the reasoning and current state again and again.

The useful criterion is not the number of days or messages. It is whether the task still represents one coherent outcome.

Keep the same task when	Consider a new task when
You are investigating and fixing the same bug	The original problem is solved and you are moving to a different improvement
You are designing, implementing, and testing the same feature	Research logs and error output have become extensive
The previous decision is needed for the next step	Most of the past trial and error is no longer relevant
Response speed and recognition are still fine	Responses are slow and the same investigation repeats
You can explain the completion condition in one sentence	It is unclear what the task is supposed to complete

“What is this task meant to complete?” is usually a more practical question than “How many days has it been open?”

One outcome per task, not one task per project

You do not need to put every piece of work for one website into the same task.

For a WordPress site such as AI Jiten, the work might be divided like this:

AI Jiten
├─ Fix a layout problem on the article page
├─ Improve the search feature
├─ Investigate page speed
├─ Check a custom plugin for vulnerabilities
└─ Review changes before publishing

“Investigate the article-page layout problem, fix the CSS, and check it on a smartphone” is one coherent outcome, so keeping it in one task makes sense.

Once the layout is fixed, starting a search-feature rewrite and a server-speed investigation in the same task adds old CSS research and screenshots as noise. That is a good point to start a new task.

Choose between /compact, fork, and a new task

There is more than one way to organize a task that has grown too long.

Use /compact when you want to continue the same problem

In the Codex CLI, /compact replaces past conversation with a shorter summary and makes more room in the context.

/compact

It is useful when you want to continue implementing the same feature or investigating the same bug, but the conversation has become long. Codex can compact automatically, and the CLI also lets you do it manually.

Compaction is a summary, so detailed decisions and temporary information may be omitted. After compaction, check that important constraints are still being followed.

Use fork when you want to try another approach

fork duplicates the current task or chat so that you can try a different direction.

You can keep the original history while creating one task for approach A and another for approach B. Because the history is also copied, however, fork is not a way to make a huge context smaller.

Use a new task when you want to leave old trial and error behind

If you are continuing the same project but want to separate a large history and failed approaches, create a new task with only the state that is still needed.

The codex-handoff project introduced in the post describes this as moving to a new “cabin” of context. Keep the old task as history, and pass only the information needed for the next task.

Pass the current state and the next step

When handing work off manually, a template like this is useful:

Goal:
Write what this task is meant to complete.

Current state:
Write what is working and where you are now.

Completed:
Write what has been investigated, implemented, and verified.

Important decisions:
Write the chosen approach, constraints, and rejected options.

Changed files:
Write the files and directories that should be checked.

Verified:
Write the tests run, display checks, and anything that could not be confirmed.

Uncommitted changes:
Write what remains in the working tree and any cautions.

Remaining work:
Write what is not finished.

First action:
Write what the new task should check or run first.

Adding the following sentence makes it easier to notice when the handoff and the current files no longer match:

Do not rely only on the information above. First check the current Git diff and the target files before continuing.

If the new task opens the same working directory, it can inspect the current files and uncommitted changes. It may not be able to tell why those changes were made just from the files.

The key is to leave the reasoning and places to verify, not a full copy of every change.

codex-handoff automates handoff-task creation

codex-handoff extracts the following information from the current task and creates a compact handoff prompt:

The goal and the first action for the new task
Completed work and the current state
Important decisions, constraints, and rejected options
Files, issues, repositories, and URLs to reference
Checks that were completed and failures that occurred
Remaining work, blockers, and unstable temporary files
Skills that will be needed in the next task

It then creates a new user-visible task and ends the old task. This is different from a full-history fork, delegating to a subagent, or moving a Git environment.

The post recommends installing it with this command:

npx skills add zjp1997720/zhijian-skills \
  --skill codex-handoff \
  --agent codex \
  --global \
  --copy \
  --yes

However, this is a third-party Skill, not an OpenAI product. Before installing it, read the SKILL.md and changelog on GitHub and check what it creates and which tools it calls.

Depending on your Codex environment, the task-creation feature required by the Skill may not be available. You can practice the same approach with the manual handoff template without installing the Skill.

Keep long-lived rules out of task history

When splitting work into new tasks, you may worry that rules written in the previous task will be lost.

Rules needed every time should live in a place suited to their purpose, rather than only in a conversation.

Coding conventions and prohibitions: AGENTS.md
Specifications and design decisions: README or design documents
Current progress and remaining work: the handoff prompt
Detailed trial and error: the old task
Change history for reverting: Git

For AI Jiten, continuing rules such as “do not deploy to production without approval” and “check smartphone layouts after changing the WordPress theme” belong in AGENTS.md.

Task-specific information, such as “leaving this CSS causes Safari-only width breakage in the search form,” belongs in the handoff prompt.

Separating rules, specifications, progress, and history makes it easier to resume work reliably in a new task.

Task organization still matters after Codex improvements

Codex CLI 0.145.0, released on July 21, 2026, improved response handling for long conversations, command-output limits, overhead from huge contexts, and remote compaction.

Codex Changelog (OpenAI)

The current Codex may not handle a huge history in exactly the same way as earlier versions. Behavior also changes across the app, CLI, model, and version.

Even so, leaving irrelevant logs and finished trial and error in the same task can still bury the information that matters.

Updating to the latest version and organizing tasks around outcomes are practical steps to take together.

Summary

As a Codex task grows, the time spent handling a huge context and deciding what to do next can become longer than the command execution itself.

That does not mean every long task should be split into small pieces. When you are completing the same bug fix or feature, keeping the history can still be valuable.

The useful question is whether you can describe the task as one coherent outcome.

Use /compact to continue the same problem, fork to try another approach, and a new task when you want to leave old trial and error behind and move to the next outcome.

In my own workflow, I want to stop treating one project as one giant task and use one task per outcome instead.

Start by choosing one task that has clearly become heavy. Pass only its goal, current state, important decisions, and remaining work to a new task. This can make it easier to organize not only the speed of the work, but also what Codex is actually trying to complete.

References

Official information and public repositories were checked on July 29, 2026. The processing times and token counts in the post come from the author’s individual task and may not be the same in every Codex environment.