Advanced Tips and Speedup: What Slows You Down is Not the Model, but Your Messy Context
📚 Series Navigation: The previous article "30 How to Choose Models" talked about "which model to send and what inference intensity to configure for the same sentence". This article goes further—choosing the right model is not enough, what really determines how much work you can do in a day is how you feed the context, how you manage sessions, and how you run multiple threads concurrently. The next article "32 Migrate from Claude Code" will discuss how old users can migrate smoothly.
At the end of the last article, I left a sentence: More often than not, what slows you down is not that the model is not strong enough, but that the context you provide is too messy, leading it astray. This article is here to pay that debt.
Let me show you a record of my own first. In March 2025, when I was building a Python utility, a certain feature got me back and forth with Codex for a whole afternoon. I later checked the session history using /status and counted: just this single requirement took 11 rounds. During this time, it modified the wrong file twice, and even "optimized" a configuration I didn't want it to touch. In the post-mortem, I realized: it wasn't that gpt-5.5 was failing, it was that my first sentence was just a lazy "help me add an export feature", and the remaining ten rounds were spent patching up the context I should have made clear in the first place.
To be honest, the biggest slowdown in AI programming is never the few seconds the model spends spinning; it is rework. If you don't make it clear the first time, it goes down a dead end, and you have to pull it back. After three back-and-forth rounds, half an hour is gone. No matter how fast a model is, it can never beat the cycles saved by "getting it right the first time".
This article won't teach you any mystical spells, but instead covers six concrete things that will cut down on rework and make the whole process run smoothly.
After reading this article, you will get:
- An counter-intuitive speedup mindset: less rework > blindly chasing speed; getting it right the first time is the most time-saving form of "speed"
- A fixed recipe for a "good request": Goal + Context + Constraints + Done criteria, along with a Before/After prompt comparison table
- Three ways to manage the context window:
/compactcompression, starting new sessions when necessary, and using@to feed files precisely instead of dumping the whole codebase - Ideas for downgrading resources by task to save time and money (continuing from the model selection in the previous article)
- Advanced techniques for running multiple threads in parallel and letting Codex verify itself
- A hands-on exercise you can follow immediately: rewrite a vague requirement into a four-part format and see for yourself how the rework rate drops
⚠️ The commands, configuration keys, and default behaviors in this article are based on the official Codex documentation. Model names, credit (the billing unit for calculating usage in Codex) multipliers,
/fast, etc., may change with versions, so please refer to your localcodex --helpand the actual official documentation.
01 The Essence of Speedup: Less Rework, Not Blindly Chasing Speed
Let's align on the mindset first, otherwise all subsequent techniques will be in vain.
When beginners think of "speedup", their first reaction is always "switch to a faster model", "lower the inference intensity", or "turn on an acceleration mode". We will cover these later, but they are minor details. The real major factor is rework.
Analogy: Cooking. When you are slow at making a dish, it is rarely because the stove fire is not strong enough. More often than not, it's because you realize halfway through cutting that you forgot to buy green onions, you put in too much salt and have to start over, or you misread the steps in the recipe. What actually consumes time is this "starting over from scratch", not the size of the fire. Turning the heat to maximum cannot save a chef who has to keep reworking while cooking.
AI programming is exactly the same. If Codex goes down a dead end, modifies the wrong file, or misunderstands your intent, and you have to pull it back and say it again—the cost of this back-and-forth far exceeds the few seconds it takes to think a bit longer.
There is a sentence in the official documentation that made a deep impression on me, meaning: Codex produces significantly higher quality outputs when it can verify its own work. In other words, getting it right and steady the first time is far more important than getting it done quickly.
I had a very typical experience myself. Late last year, I asked it to "optimize this function" without specifying what to optimize, what not to touch, or what counts as a successful optimization. It enthusiastically rewrote the function, casually changed my interface signature, and caused all three calling parties to error out. It took me twenty minutes to clean up the mess it "optimized". Since then, I established an iron rule: never say a vague "optimize it", even if it means typing two more lines.
Remember this priority; the next five sections are all expansions of it:
| What You Think is Speedup | Real Speedup |
|---|---|
| ❌ Switch to a faster model and do everything at once | ✅ Make it clear in the first sentence to reduce rework rounds |
| ❌ Brainlessly lower inference intensity to chase speed | ✅ Match compute power to task difficulty (covered in the last article) |
| ❌ Dump the entire project for it to read | ✅ Use @ to feed relevant files precisely |
| ❌ Keep a single session open from morning to night | ✅ One task per session, compress or start a new one in time |
| ❌ Check line by line with your own eyes after changes | ✅ Give done criteria, let it run tests to verify itself |
💡 Summary: The biggest slowdown in AI programming is rework. The first principle of speedup is "getting it right the first time", rather than "running faster".
02 Provide Enough Context, Don't Let It Guess: The Fixed Recipe for a Good Request
The previous section stated that rework is the major factor. So where does rework come from? Most of it comes from not making things clear in the first sentence, forcing Codex to guess. Once it guesses, there is a chance it will guess wrong, and you will have to rework.
Analogy: Writing food delivery notes. If you only write "a plate of fried rice", the rider and the kitchen can only go by defaults—it might have onions, it might be spicy, it might be salty. But if you write "Yangzhou fried rice, no onions, mild spicy, slightly softer rice", it will be right the first time. The same goes for requests to Codex: for every word you save, it has to guess for you, and if it guesses wrong, you rework.
The official "Best Practices" provides a recipe that I have copied to this day. A good request defaults to including these four things:
- Goal: What exactly do you want to modify or build?
- Context: Which files, documentation, or error messages are related to this? Mention them using
@. - Constraints: What conventions or architectures should be followed, and what is off-limits?
- Done when: Under what circumstances is it considered complete? Tested, behavior changed, bug no longer reproducible?
You don't need to fill out every single one of these four, but Goal and Done when can almost never be omitted. Now when I write requirements, no matter how rushed I am, I run through these four slots in my mind.
The comparison table below shows bad prompts I used to write, rewritten. You can feel the difference directly:
| ❌ Before (Vague, destined for rework) | ✅ After (Four-part format, high probability of passing first try) |
|---|---|
| Help me add an export feature | Goal: Add a function to report.py to export reports to CSV. Context: Refer to the existing implementation in @export/json_export.py. Constraints: Reuse the existing Report data class, do not modify its fields. Done when: Can export a CSV with headers, and tests/test_export.py all pass |
| This function is a bit slow, optimize it | Goal: Reduce search() time on 10,000 data items from 2 seconds to under 200ms. Context: The function is in @core/search.py. Constraints: Do not modify the function signature or return structure. Done when: Run pytest tests/test_search.py::test_perf and the assertion for elapsed time < 0.2s passes |
| Fix this bug | Goal: Fix the issue where logging in redirects to a blank page. Context: Reproduction steps are "enter correct credentials -> click login -> white screen", relevant code in @auth/login.py. Constraints: Do not modify the permission validation logic. Done when: Running through the reproduction steps successfully enters the home page |
Do you see? The right column is not just wordier; it completes the information you already had in your head but were too lazy to type out. If you don't complete it, Codex has to guess; if you do, it goes straight to the target.
When I reviewed that Python tool, I calculated that for the same requirement, the left style took an average of 5 to 8 rounds to get right. Switching to the four-part style on the right, it passed in 1 to 2 rounds most of the time. The extra two lines you type save you three back-and-forth trips later.
There is also a lazy but effective trick: when a task is too hard and you haven't figured out how to describe it yourself, don't force it—let Codex help you sort it out first. The official recommendation is to use Plan mode. In the CLI, switch using /plan or Shift+Tab. It will collect context first, ask you a few questions, and lay out a proposal, waiting for your nod before starting. Instead of letting it write the wrong way with a misunderstanding, spend a minute letting it outline the plan first.
💡 Summary: A good request = Goal + Context + Constraints + Done when. Every word you save is a word Codex has to guess, and guessing wrong leads to rework.
03 Manage the Context Window: Don't Dump the Whole Repository
Section 02 addressed "explaining clearly," while this section addresses "not saying too much." These two might sound contradictory, but they aren't—what we want is for relevant information to be fully described, while leaving out unrelated details.
Each session (called a "thread" in Codex) has a limit on the information it can hold. This is the context window, representing the total amount of content the model can "remember" at one time. When it gets full, older information is either compressed or pushed out, and output quality starts to drop.
Analogy: A desk. The desktop is only so big. If you spread out the three files needed for the current task, you work efficiently. If you dump hundreds of documents from the entire file cabinet onto the desk, you won't even find the one you need. Codex's context window is like this desk. The more precisely you feed it, the more focused it becomes; dump an entire repository, and it gets distracted by irrelevant information.
To manage it well, remember three tips:
Tip 1: Use @ to feed files precisely; don't let it search blindly across the whole repository. Since you know exactly which files you are modifying, just @ them directly. It doesn't need to waste context window space grepping around, making it both fast and precise. One root cause of my afternoon struggle was that I didn't specify the files, so it read seven or eight unrelated modules before finding the place to modify—and all those loaded contents occupied the "desk".
Tip 2: Use /compact when sessions get long. When a session has been going on for a while, the earlier content builds up. /compact tells Codex to summarize and compress early context into a condensed version, freeing up space to continue. As the official docs mention, Codex automatically compresses when necessary, but running /compact manually lets you proactively clear the deck before it starts getting slow.
Tip 3, which is also repeatedly emphasized by the official guide: one task per session, don't use a single session from morning to night. The official "Common Pitfalls" specifically highlights: using "one project per session" instead of "one task per session" makes the context increasingly bloated, leading to worse results.
I now have an iron rule: once this requirement is done, I start a brand new session for the next unrelated requirement. The relevant commands in the CLI are very handy:
/compact Compress early context of the current session into a summary to free up space
/status Check current session status, including remaining context window
/fork Start another branch based on the current session, keeping original history
/resume Restore a previously saved sessionA decision principle: Context should be "precise," not "abundant." Stay in the same session for the same problem to maintain the reasoning chain; only /fork or start a new one when the work actually branches.
The criteria is simple: if it is a continuation of the same issue, stay in the original session; if it's an unrelated task, start a new one. Don't cling to that "history"; a bloated context only yields worse results, which isn't worth it.
💡 Summary: Context should be precise, not abundant. Precision feeding with
@, timely compression with/compact, and one task per session are the three-piece suit for managing the context window.
04 Downgrade by Task: Don't Use Flagship Specs for Simple Tasks
This section continues from the previous article, keeping it brief—since the last article explained model selection thoroughly, here we only add the "speedup" perspective.
Analogy: Commuting vehicle choice. You wouldn't drive a car just to buy a bottle of water downstairs; you walk. Nor would you ride a shared bicycle for an intercity business trip. The difficulty of the task determines the amount of compute power to allocate, just like the commute distance determines the vehicle choice.
In terms of operation, there is just one principle: downgrade for simple, well-defined tasks. The inference intensity recommendations in the official "Best Practices" are clear:
- Quick, well-defined tasks: use
low, or even lower for simpler tasks - Complex changes, debugging: use
mediumorhigh - Long, heavy tasks requiring high reasoning: only then use
xhigh
The same logic applies to models. For trivial tasks or exploration runs by subagents, the lightweight gpt-5.4-mini is enough; there's no need to drag the flagship gpt-5.5 out for everything. For typos, renaming variables, or running simple queries, downgrading to gpt-5.4-mini + low is both fast and credit-saving.
My own default in ~/.codex/config.toml is medium, and I only dial it up temporarily in the session when encountering hard cases. Don't lock the default to gpt-5.5 + xhigh like I used to—waiting for it to "deeply ponder" for a minute just to rename a variable is a folly I have experienced firsthand. For details on how to configure it and the four ways to switch, refer back to Article 30.
💡 Summary: Downgrade for simple tasks.
gpt-5.4-mini+lowis fast and economical, saving flagship specs for the real tough challenges.
05 Go Parallel: Run Multiple Threads Concurrently
The first four sections were about making a single thread run smoother. This section shifts dimensions—don't wait for a single thread to finish; get multiple threads spinning concurrently.
There is a very direct point in the official "Common Pitfalls": treating Codex as a tool you must watch step-by-step, rather than a buddy working in parallel with you, is a typical beginner mistake. You can completely let it rebuild in the background while you continue with other tasks.
But there's a prerequisite trap—never let two threads modify the same files concurrently. They will step on each other's toes and mess up your workspace. The official solution is git worktrees, which was covered specifically in Article 25.
Analogy: Multiple trades entering a renovation site at the same time. If plumbing, carpentry, and painting are to run concurrently, they must occupy separate rooms, rather than crowding into one. A worktree gives each thread an independent "room" so they don't interfere with one another.
There are two common parallel workflows, corresponding to the articles mentioned earlier:
| Approach | Isolation Method | Relevant Article |
|---|---|---|
| Running multiple tasks | A git worktree for each thread, occupying separate directories | Article 25 Worktrees |
| Main thread + Sub-contracting | Main agent focuses on core issues, offloading exploration, testing, and troubleshooting to subagents | Article 21 Subagents |
The official recommendation for subagents is: let the main agent focus on the core problem, and offload tasks with clear boundaries—such as code exploration, writing tests, or troubleshooting—to subagents. Keeping the main thread free from these distractions speeds up the overall process.
Now when I work on slightly larger requirements, my habit is: advance core logic in the main session, while opening a separate worktree to let Codex run tests and linting. By the time my main line is written, its checking results are mostly ready. Running them in parallel saves a huge chunk of time compared to doing them sequentially.
💡 Summary: Run multiple threads in parallel. Use worktree for isolation and subagents for division of labor, but never let two threads modify the same files concurrently.
06 Let It Verify Itself: Cut Down on Back-and-Forth Confirmation Cycles
The final trick, which is also the most easily overlooked yet offers the highest return, is: let Codex verify itself; don't do everything by visual checking yourself.
Back to the mindset in Section 01: rework is the biggest slowdown. And you checking back and forth is itself a form of slowdown. It finishes the change, you open the file and look line-by-line, find something wrong, and repeat—these rounds of manual checking consume all the time.
The official docs state clearly: Codex produces better outputs when it can verify its own work, but the prerequisite is that it needs to know what "good" looks like. This criteria comes either from your prompt or the project manual AGENTS.md.
Analogy: A checklist before submitting assignments. When delegating work to a subordinate, you attach a checklist of "verify these five items before delivery." They self-check before submitting, and you only need to spot-check. Without a checklist, you end up checking line-by-line, becoming the bottleneck. Giving Codex done criteria is giving it this self-check list.
Specifically, let it perform these tasks (from the official "Best Practices"):
- Write or update tests for changes
- Run the corresponding test suite
- Run linting, formatting, and type checks
- Confirm the final behavior matches what you requested
- Review the diff itself to find bugs, regressions, or risky implementations
There is a very handy /review command in the CLI that can perform PR-style reviews against a base branch, review uncommitted changes, or audit according to custom rules you provide.
A more permanent approach: write "what counts as done" and "which tests to run" into AGENTS.md. It will automatically follow this verification routine every time, so you don't have to repeat it in the prompt. This was covered in Article 11.
My standard action now is to directly include in the requirement: "Run pytest after modifying, and let me know when it's all green." It returns only after running the tests and confirming they pass, saving me the entire two rounds of "it says it's fixed -> I run tests -> find they fail -> ask it to fix again." Put simply, let it handle the verification step, and only then can you be freed from "babysitting" it.
💡 Summary: Providing done criteria and letting Codex run tests and review by itself can cut down manual confirmation rounds. This is the highest-return speedup tip.
07 In Passing: Minor Tricks Like Fast Mode
The first six sections are the skeleton; this section is a supplement, brief and to the point.
Codex has a Fast mode which speeds up supported models by about 1.5x, at the cost of higher credit consumption. According to official specs, it currently supports GPT-5.5 and GPT-5.4. Using Fast mode with GPT-5.5 charges credits at 2.5x the standard rate, and GPT-5.4 charges at 2x.
In the CLI, use these commands to toggle and check:
/fast on Turn on Fast mode
/fast off Turn off Fast mode
/fast status Check current statusIf you want it on by default, you can persist it in ~/.codex/config.toml:
service_tier = "fast"
[features]
fast_mode = trueNote two prerequisites: First, Fast mode is only available when logged in via ChatGPT. If you connect via an API key, standard API pricing applies, and you cannot use this feature. Second, it trades money (credits) for speed; it is not free.
To be honest, Fast mode is a "last mile" minor trick, not the main course. The time saved by the first six sections (clarifying requirements, managing context, downgrading by task, running in parallel, self-verifying) is measured in "rounds" and "entire blocks of rework"; Fast mode only saves 1.5x on a single response time. Get the first six things right first before considering whether to spend extra credits for this speed. Personally, I don't turn it on often; I only run /fast on temporarily when in a rush and certain that the task is worth the credits.
💡 Summary: Fast mode trades credits for 1.5x speed and is a nice-to-have minor trick. The first six sections save entire rework cycles; get those right before talking about this.
08 Hands-on Session: Rewrite a Vague Requirement into the Four-Part Format
Just reading without practicing won't stick. This five-minute exercise lets you experience the difference between "passing on the first try" and "back-and-forth rework."
Step 1: Find a vague requirement you might typically type. For example:
Help me add a logging feature to this projectStep 2: Rewrite it into the four-part format using the recipe from Section 02. Complete these four slots in your mind (or type it out directly):
Goal: Add a unified logging utility to the project that outputs to both the console and file categorized by INFO/ERROR.
Context: Refer to the config-reading implementation in @utils/config.py; read the log level from config.
Constraints: Use the standard logging library, do not import third-party logging libraries; do not change any existing function signatures.
Done when: Can import and print an INFO log to logs/app.log at the main entry point, and the file is generated normally.Step 3: Send both versions to Codex separately and count the rounds. Start a session with the vague version, wait for it to finish (note if it asks you questions or unilaterally chooses a path), and count how many rounds it took until you are satisfied. Then, start a new session with the four-part version and count the rounds again.
Expected results:
- Vague version: Codex will likely start by asking "where to output", "whether to classify", or "which library to use", or it might just choose a setup you might not want. It usually takes at least 3 rounds of back-and-forth.
- Four-part version: It gets straight to the point, delivering in 1 to 2 rounds most of the time, and the output matches your expectations much better.
The point of this exercise is not how many rounds it actually took, but to let you experience firsthand: the extra four lines you type buy you back several trips later. This trade-off is always worth it.
After completing this exercise, save your most satisfactory four-part constraints and validation habits into AGENTS.md so you won't have to type them out every time.
💡 Summary: Run both the vague and four-part versions yourself and count the rounds. You will see firsthand how typing four extra lines saves you from rework.
Summary
This article pulled "speedup" out of the misconception of "switching to faster models" and landed it on six things that actually save time:
- Mindset: Less rework > blindly chasing speed; getting it right the first time is the most time-saving form of speed.
- Clarifying requirements: Goal + Context + Constraints + Done when; every word you save is a word Codex has to guess.
- Managing context: Precision feeding with
@, compression with/compact, and one task per session. - Downgrading by task:
gpt-5.4-mini+lowfor simple tasks, reserving flagship specs for tough challenges. - Going parallel: worktree isolation, subagents for division of labor; never let two threads modify the same files concurrently.
- Self-verification: Providing done criteria, letting it run tests and review to cut down manual back-and-forth.
- Minor tricks like Fast mode are just icing on the cake; get the basics right before worrying about them.
You should now be able to: run through the four-part recipe in your mind when receiving a requirement instead of blurting out a vague sentence; use @ and /compact to feed the context precisely and cleanly; know when to downgrade simple tasks, when to parallelize complex ones, and let Codex verify all tasks. Turn this routine into muscle memory, and your daily output will visibly increase—not because the model became faster, but because you stopped letting it go astray.
The next article "32 Migrate from Claude Code" is for a specific audience: you are an old user migrating from Claude Code. What does CLAUDE.md map to here? How do concepts like permission modes, Skills, and subagents carry over? Which habits can be brought over directly and which need to change? A quick thought-provoker: which habit you developed in Claude Code might actually hold you back here? Find out in the next article.