Codex Efficiency Handbook

Learn to choose efficient Codex prompts, context, models, and verification.

Introduction

30 Second Summary

A quick software task can become a long back-and-forth when the request leaves too much room for guessing. Extra context can make the same task slower without making the answer better.

In this project, you will read a practical handbook for using Codex efficiently in the ChatGPT desktop app. You will compare realistic software-engineering workflows to see how prompt scope, model choice, reasoning effort, context, and verification affect the result.

What You'll Build

You will finish with a field guide you can scan before each Codex request to choose the lightest workflow likely to meet your quality bar.

By the end of this project, you'll have:

A clear usage map that helps you spot the context, tool calls, retrieval, and follow-up turns making a request heavier.
A set of side-by-side prompt examples that helps you recognize focused requests before unnecessary exploration begins.
A compact decision guide for choosing the lightest model, reasoning level, context source, and chat boundary that can meet your quality bar.
A Secret Mission: Diagnose a bloated refactoring workflow. Turn it into a focused Codex request with lean context, suitable capability, and a verifiable finish line.

Are there any prerequisites?

No repository or coding setup is required. This read-only handbook uses realistic examples that you can follow without running any commands.

Before We Start

Your read-only Codex Efficiency Handbook is open in the ChatGPT desktop app. This checkpoint connects its ideas to the Codex task you expect to use most often before you begin reading.

Build an Efficiency Mental Model

A low token count in the first Codex prompt can still lead to a weak result. Retries can erase that apparent saving.

Efficiency covers the complete task from the first request to an acceptable result. This chapter gives you a three-part balance plus a starting rule for scope and reasoning effort.

In this step, get ready to:

Recognize every source of effort across a complete task.
Separate cost, speed, and quality into distinct measures.
Use focused scope with the default reasoning effort as your starting point.

Measure the complete task

The useful measurement boundary ends when the result meets your quality bar. Every request or correction before that point belongs to the same workflow.

What Counts in the Complete Task?

Total efficiency measures the effort required to reach an acceptable result. The first response is one part of that path.

The initial prompt starts the task.
Relevant file reads provide evidence for the result.
Unnecessary file reads consume effort without improving the outcome.
Tool calls contribute to the complete workflow.
Retries add another attempt to the total.
Corrective turns add work after an incomplete or weak result.

A debugging answer can arrive in seconds and still miss the real cause. Two retries plus several unrelated file reads make that complete workflow less efficient.

Read each part of the complete-task view above.
Apply the complete-task view to the primary Codex task you identified before this step.

Balance cost, speed, and quality

Cost, speed, and quality answer separate questions about the same workflow. Treating them separately prevents one attractive number from hiding a poor overall result.

The Three-Part Balance

Cost measures the total usage or effort consumed across the complete task.
Speed measures the time required to reach an acceptable result.
Quality measures whether the result meets your defined standard.

Three questions turn this balance into a practical decision framework.

Required quality: What quality bar is required? This sets the acceptance threshold.
Needed speed: How quickly is the result needed? This sets the acceptable turnaround time.
Workflow choice: What is the lightest workflow likely to meet both? This combines the first two answers.

Name the minimum acceptable result for your primary Codex task.
Choose the turnaround time that task requires.
Identify the lightest complete workflow likely to satisfy both decisions.

Choose the lightest starting point

A focused scope gives Codex one coherent outcome to pursue. The default reasoning effort provides a sensible starting level before the task reveals a need for more capability.

When to Increase Capability

Begin with a focused scope and the default reasoning effort. Increase capability when the task shows that it needs deeper planning or analysis.

This escalation rule keeps simple tasks light. It still leaves room for difficult work to receive more attention when evidence supports that choice.

Frame a future task around one focused outcome.
Keep the reasoning effort at its default setting for the first attempt.
Increase capability only after the task reveals a need for deeper planning or analysis.

Before you check the chapter summary, which dimension do you expect to describe the elapsed time to an acceptable result?

Return to the The Three-Part Balance summary box.
Match Cost with total usage or effort across the complete task.
Match Speed with the time required to reach an acceptable result.
Match Quality with the standard the result must meet.
Confirm that the starting rule uses focused scope with the default reasoning effort.

You should see three separate meanings in the summary. That distinction gives you a reliable way to judge the complete workflow.

You have the foundation in place. Next, you will trace where Codex usage goes across a real request.

Identify Usage Drivers

Your efficiency model gives every Codex task a quality bar. The next question is where the total usage accumulates before that bar is met.

A request can consume usage through its prompt, relevant files, chat history, tool results, reasoning, retrieval, response, and follow-up turns. This chapter helps you spot those drivers before broad exploration turns into rework.

In this step, get ready to:

Trace usage across the complete request lifecycle.
Compare a broad login-bug request with a focused version.
Identify hidden context multipliers that add work without improving the outcome.

Trace the full request lifecycle

Prompt length is one input to usage. Model choice, context, reasoning, tool use, retrieval, and caching also affect the work required.

Where does the usage go?

The prompt supplies the task description that begins the request.
Relevant files, chat history, and tool results add evidence to the working context.
Reasoning, retrieval, and tool use add processing before the answer is ready.
The response consumes tokens when Codex returns its result.
Follow-up turns can process earlier context again while correcting or extending the result.

Continue to the request lifecycle section in the handbook.
Read the lifecycle in order from the prompt through possible follow-up turns.
Map your primary Codex task from Step 0 onto the lifecycle.

You should be able to point to the prompt, relevant files, chat history, tool results, reasoning, retrieval, response, and follow-up turns as separate usage drivers. A short opening request can still lead to substantial work later in that lifecycle.

Compare broad and focused requests

A broad request leaves Codex to discover the evidence, boundaries, and finish line. That discovery can expand file reads or create corrective turns.

Broad Request Versus Focused Request

Broad request: “Fix the login bug.” Codex must infer the failing behavior before deciding where to investigate.
Focused request: It names the failing behavior. It limits the relevant paths. It states the constraints. It defines the expected output. It includes a success check.

Read the broad login-bug request in the handbook.
Identify the missing evidence that Codex would need to discover.
Read the focused login-bug request in the handbook.
Compare the amount of exploration invited by each request.

The focused request is longer on screen. It is likely to require less total work because it reduces discovery plus corrective turns.

Spot hidden context multipliers

Some context enters every request even when the current task does not need it. These multipliers can increase usage without making the result more useful.

Which Context Multipliers Matter?

An oversized AGENTS.md file loads durable repository guidance that may be unrelated to the current task.
Irrelevant attachments add source material that Codex may need to inspect.
Every enabled MCP server adds context to messages.
Extended chat history carries earlier reasoning into later turns.
Open-ended output requirements leave the response format plus length undefined.

Continue to the hidden context multipliers section in the handbook.
Match each multiplier to the extra work it can introduce.
Relate the multipliers to the complete request lifecycle from the first substep.

Before you read the explanation beneath the worked requests, which login-bug request do you expect to need less exploration?

Read the handbook's explanation beneath the comparison.

You should see that the focused request limits relevant paths plus states constraints. It also defines the expected output plus verification, which gives Codex a smaller search space with a concrete finish line.

That is the hidden-work problem solved: you can now spot where a request may expand before you send it. Next, you'll turn that insight into a four-part prompt structure that prevents rework.

Write Prompts That Prevent Rework

The usage-drivers chapter showed how broad requests can push Codex into unnecessary exploration. You can now recognize why a few useful details may save more effort than an ultra-short request.

The short-prompt trap disappears when a focused prompt supplies the smallest useful set of facts. This chapter gives you a structure for providing those facts without burying the task in irrelevant context.

In this step, get ready to:

Learn the Goal, Context, Constraints, and Done when prompt structure.
Compare ambiguous requests with focused requests across four engineering tasks.
Decide when Plan mode earns an extra planning round.

Build a four-part prompt

A useful Codex request answers four practical questions before work begins. Each answer removes a different source of uncertainty.

What belongs in each part?

The Goal states the change or result you want.
The Context names the evidence that matters to the task.
The Constraints define boundaries that Codex must respect.
The Done when section defines an observable finish line.

Read the focused debugging request below from top to bottom.

A Focused Debugging Request

Goal: Fix login submission so a valid user reaches the dashboard.
Context: The failure starts after form submission. Focus on auth/login.ts plus auth/login.test.ts.
Constraints: Preserve the public authentication interface. Avoid unrelated file changes.
Done when: Existing authentication tests pass. A regression test covers the failed login flow.

The extra details give Codex a starting point plus a boundary. The finish line also reduces the chance of a corrective follow-up turn.

Compare prompts across common tasks

Concise prompting keeps every detail tied to the result. The strongest request may use several short sentences because each sentence removes a specific uncertainty.

Debugging and Refactoring Examples

Debugging, ambiguous: Fix the login bug.
Debugging, focused: Goal: Fix the failed login redirect. Context: The form submits successfully before the route remains unchanged. Constraints: Limit changes to the authentication flow. Done when: A valid user reaches the dashboard while the authentication tests pass.
Refactoring, ambiguous: Refactor the checkout service.
Refactoring, focused: Goal: Extract discount calculation from checkout.ts into a pure helper. Context: Only the existing checkout total path is in scope. Constraints: Preserve exported function signatures. Avoid formatting unrelated code. Done when: Current checkout tests pass. Focused cases cover percentage discounts.

Both focused requests identify the behavior that matters. Their constraints protect unrelated code from unnecessary changes.

Test Writing and Code Review Examples

Test writing, ambiguous: Write tests for coupons.
Test writing, focused: Goal: Add regression coverage for expired coupons. Context: Use the fixtures in coupon.test.ts. Constraints: Keep production behavior unchanged. Done when: The new test fails against the old behavior before passing against the current fix.
Code review, ambiguous: Review this change.
Code review, focused: Goal: Review the payment retry changes for correctness. Context: Focus on the retry diff plus the linked incident. Constraints: Prioritize defects over style comments. Done when: Return findings by severity with file references.

Locate Goal, Context, Constraints, and Done when in each focused request.

You should find a desired outcome plus relevant evidence in every focused request. You should also find a boundary plus an observable finish line.

Why This Prevents Rework

Goal keeps the work pointed at one result. Context reduces broad investigation.

Constraints prevent unwanted expansion. Done when tells Codex what evidence must exist before the task is complete.

Choose when planning pays off

Plan mode adds value when Codex must resolve ambiguity or coordinate several steps. A tiny edit with a clear path plus a finish line can usually proceed without a separate planning round.

When Planning Earns Its Cost

Use Plan mode when the desired outcome is still ambiguous.
Use Plan mode when the work spans several components or tradeoffs.
Use Plan mode when verification requires a deliberate sequence of checks.
Skip a separate planning round when one localized change already has a clear boundary plus an obvious success check.

Plan mode can be toggled with /plan or Shift+Tab. The decision to use it should come from task complexity instead of habit.

Read the three planning scenarios below.

Three Planning Scenarios

Scenario one asks Codex to update one button label in a named file. An existing test already verifies the label.
Scenario two asks Codex to redesign an authentication flow across routing, session storage, plus error handling. The preferred tradeoffs are unclear.
Scenario three asks Codex to investigate an intermittent production failure. Several logs plus competing hypotheses need to be evaluated.

Before you reveal the decisions, which scenarios deserve Plan mode?

Planning Decisions

Scenario one can proceed directly because the edit is localized. Its existing test provides the finish line.
Scenario two benefits from Plan mode because it spans several components. The unclear tradeoffs need to be resolved before editing.
Scenario three benefits from Plan mode because the investigation has multiple hypotheses. A planned evidence sequence can prevent random exploration.

Before the final check, can you point to all four parts of one focused request without relying on the labels?

Return to the focused test-writing request above.
Identify its desired change as the Goal.
Identify its relevant evidence as the Context.
Identify its boundaries as the Constraints.
Identify its observable finish line as Done when.

You should be able to assign every sentence to one of the four parts. You should also be able to explain how each part removes a different source of rework.

That is the prompt-design chapter complete. You can now distinguish a focused engineering request from one that leaves Codex guessing.

Your prompts now define the work plus the evidence required to finish it. Next, you will match model capability and reasoning effort to the task in front of you.

Choose Model and Reasoning Levels

You can now structure a Codex request with a clear Goal, Context, Constraints, and Done when. The next decision is how much capability the task deserves.

Maximum capability on every request wastes time and usage. Too little capability can cause retries that erase the savings.

In this step, get ready to:

Match the right model to each task.
Choose a reasoning level that fits the work.
Compare available speed modes with their usage tradeoffs.

Match each model to the work

Model selection controls how much capability Codex brings to a request. The efficient choice is the lightest model that repeatedly reaches your quality bar.

In the handbook from earlier, continue to the model role table.
Read the Luna, GPT-6.1 Sol, and Astra rows.

Model Role Guide

Luna suits clear repeatable work with narrow boundaries.
GPT-6.1 Sol suits repeated complex engineering work where cost matters. It offers near-Astra performance for complex work at a lower cost than Astra.
Astra suits the hardest end-to-end workflows that need sustained judgment.

Compare your primary Codex task type with the three roles above.
Select the lightest role that repeatedly meets your quality bar.

Scale reasoning with complexity

Reasoning effort controls how much planning or analysis the selected model applies. Higher reasoning can help difficult tasks produce stronger results.

Continue to the reasoning ladder in the handbook.
Read the Light through Extra High levels.

Reasoning Effort Guide

Light suits quick well-scoped tasks.
Medium balances speed with depth for work needing more planning.
High or Extra High suits difficult work with multiple steps, sources, or tradeoffs.

Higher reasoning takes longer. It also uses more tokens.

Start with the default reasoning effort for your task.
Increase the effort only when the task needs deeper planning or analysis.

This keeps a focused task fast. It reserves extra reasoning for work that can use it.

Treat speed as a separate choice

Speed settings change how quickly Codex responds. They carry separate usage tradeoffs from model capability or reasoning effort.

Continue to the speed tradeoff section in the handbook.
Read the Standard, Fast, and Ultrafast comparisons.

Speed Tradeoff Guide

Standard is the conservative default.
Fast prioritizes turnaround. It uses 2.5x included subscription usage relative to Standard. It uses 2x purchased credits or Enterprise pay-as-you-go usage.
For GPT-6.1 Sol, Ultrafast prioritizes turnaround most aggressively. It uses 8x included subscription usage relative to Standard. It uses 6x purchased credits or Enterprise pay-as-you-go usage.

Available speed modes depend on your plan, client, workspace settings, or rollout.

Keep Standard when predictable usage matters most.
Choose Fast when quicker turnaround justifies its higher multiplier.
Reserve Ultrafast for work where its shortest turnaround is worth the larger multiplier.

Before you read the check below, which model do you expect to fit each scenario?

Assign one model to a focused transformation with clear boundaries.
Assign one model to repeated complex engineering work where cost matters.
Assign one model to the hardest end-to-end workflow with sustained judgment.

Check Your Classifications

The focused transformation maps to Luna.
The repeated complex engineering work maps to GPT-6.1 Sol.
The hardest end-to-end workflow maps to Astra.

Each choice follows the same rule. Capability rises when task complexity justifies it.

Your three classifications now follow a consistent decision rule. You can match capability to the work without defaulting to the maximum.

You now have a practical way to avoid spending usage on capability the task cannot use. Next, you'll decide where each piece of context belongs.

Keep Context Lean

You can now match Codex capability to the clarity of a task. The next source of waste is context that follows the task without helping it.

Repeated repository rules make every request longer. Unrelated chat history creates the same problem. This chapter gives each kind of information one clear home.

In this step, get ready to:

Choose the right home for each kind of information.
Keep each chat focused on one coherent outcome.
Prove that the requested behavior works.

Place each fact where it belongs

Useful context removes uncertainty from the current outcome. Extra material makes Codex process information that does not help that outcome.

Continue to the context-placement guide in the handbook.

Where Does Each Kind of Context Belong?

The prompt holds one-off requirements for the current task.
A concise AGENTS.md file holds stable repository conventions.
A separate chat holds a genuinely different objective.
A narrowly useful MCP connection supplies frequently changing external information.

A concise AGENTS.md file keeps durable guidance reusable. Oversized guidance belongs in task-specific referenced files.

Before you check the examples, which home would you choose for each one?

Match a one-time requirement to preserve an existing API to one location.
Match a repository-wide test command to one location.
Match a new billing-design objective to one location.
Match live issue-tracker data to one location.

Check Your Placements

The one-time API requirement belongs in the prompt.
The repository-wide test command belongs in a concise AGENTS.md file.
The new billing-design objective belongs in a separate chat.
The live issue-tracker data may justify a narrowly useful MCP connection.

Set clear chat boundaries

Earlier reasoning earns its place while it still supports the same outcome. A whole-project chat keeps accumulating history after that history stops helping.

Read the chat-boundary section in the handbook.

Before checking the guidance, would you keep each scenario in the current chat?

Decide whether a follow-up test for the same login fix stays in the current chat.
Decide whether a request to redesign billing starts a new chat.

Where Should the Boundary Fall?

Keep the follow-up test in the current chat. The reasoning trail still supports the login fix.

Start a new chat for the billing redesign. That request has a genuinely different objective.

Close with a verification loop

A focused chat still needs a clear finish line. Verification turns completion into observable evidence.

Read the verification-loop section in the handbook.
Locate the instruction that names the relevant check.
Locate the diff-review step.
Locate the requirement for behavior evidence.

What Completes the Loop?

Requested checks tell Codex what to run or inspect.
A diff review confirms that the changes stay within scope.
Behavior evidence proves that the requested result works.

Before you read the final summary, can you assign every context type to one home without looking back?

Check your prediction against the chapter's final summary box.

You should see one-off facts assigned to the prompt. Durable repository guidance belongs in a concise AGENTS.md file.

A genuinely different objective starts a separate chat. Live external information may justify a narrowly useful MCP connection.

Requested checks begin the verification loop. Diff review keeps changes within scope.

Evidence confirms the requested behavior. You now have a complete method for keeping context useful.

Your context now has a clear job in every Codex task. Next, the optional Secret Mission lets you apply the full framework to a solved case.

Secret mission

Diagnose a Wasteful Codex Workflow

Follow a solved refactoring case that begins with a bloated chat, excessive context, maximum capability, and no finish line. Diagnose the waste through four levers, then keep a reusable before-you-send checklist for future Codex requests.

Clean Up Your Resources

This read-only handbook in the ChatGPT desktop app created no local files or cloud resources. The handbook adds no ongoing project costs.

Resources you used:

Confirm that no repository, local project file, cloud resource, or paid service was created for this handbook.

Keep everything running

No action is needed. Choose this option if you want to revisit the handbook.

Keep the handbook available in the ChatGPT desktop app for future reference.
Reuse your before-you-send checklist before future Codex requests.

Pause - I'll come back to this later

There is no running process to pause. This option simply marks a stopping point in your learning.

Close the handbook when you finish this session.
Return to your before-you-send checklist when you resume.

Delete - I don't want to use this again

There are no project resources to delete. Your ChatGPT account requires no cleanup from reading this handbook.

Confirm that there is no repository or local project file to remove.
Leave the ChatGPT desktop app installed for other work.

Nice Work!

You made it! You finished the Read-Only Codex Efficiency Handbook with a practical framework for choosing the lightest workflow that repeatedly meets your quality bar.

Your field guide now helps you spot wasted usage before a request triggers unnecessary exploration or costly retries.

What you learned:

Defined Codex efficiency as the lightest workflow that repeatedly meets your quality bar. You now count file reads. You count chat history. You count tool results. You count reasoning. You count follow-up turns.
Used the four-part prompt structure. Goal states the desired change. Context names the relevant evidence. Constraints set the boundaries. Done when gives the task an observable finish line.
Designed a right-sized Codex workflow. Luna handles clear repeatable tasks. GPT-6.1 Sol supports repeated complex work where cost matters. Astra handles the hardest end-to-end workflows. Reasoning effort rises only when the task needs it. One-off facts stay in the prompt. Durable repository guidance belongs in AGENTS.md. A new objective starts a new chat. MCP connections earn their place by unlocking a real workflow. Verification supplies evidence before acceptance.
Completed the optional Secret Mission by diagnosing a wasteful refactoring workflow. You reduced the request to one coherent outcome. You narrowed the evidence. You selected the model. You set the reasoning effort. You defined observable success. You required verification. Your before-you-send checklist now catches workflow waste before the request starts.

Ready to quiz yourself?