Why planning can consume so much Codex usage
An instruction such as reduce our API costs does not point to a code change. The agent must inspect the system, retrieve logs and metrics, compare behavior with the code, study earlier decisions, rank possible fixes, and decide what to implement. Only then can it edit a file.
OpenAI's current Codex usage guidance says consumption depends on the model, task size and complexity, local or cloud execution, context, reasoning, tools, retrieval, and caching. Long sessions that retain more context can use much more of an allowance than a small, focused coding task. Moving a genuine planning phase out of Codex can therefore preserve Codex capacity, provided the other surface uses a different allowance for your account.
The source case for this workflow came from a September 17, 2026 article by Khazix. The author described giving ChatGPT access to AIHOT business metrics through a private read-only MCP server while also using GitHub context. ChatGPT produced a cost-reduction plan, which was then handed to Codex for implementation. The author estimated that planning directly in Codex would have used about 10% of a weekly allowance and reported about 4% for the later implementation. No public usage log or controlled comparison accompanied those figures, so they are a case report, not a savings benchmark.
Split the work where the evidence changes
Use ChatGPT for the part of the task that asks, What should we do, and why? Use Codex when the task becomes, What does this repository do now, what exact change is justified, and do the tests pass?
| Stage | Best surface | Required output |
|---|---|---|
| Frame the business question | Chat | A decision, time range, constraints, and success measure |
| Analyze metrics, logs, and change history | Chat with approved files or plugins | Evidence table with source, date range, finding, and uncertainty |
| Rank possible changes | Chat | Expected effect, implementation cost, risk, and verification method |
| Check the repository and implement | Codex | Verified current state, bounded diff, and tests |
| Approve release | Human owner | Reviewed diff, test evidence, rollback plan, and explicit release decision |
Keep repository exploration in Codex when the answer depends on running commands, tracing live code paths, or inspecting uncommitted work. A plan made without current repository evidence can be useful as a hypothesis, but Codex still has to verify it.
Record your starting usage and task boundary
Take a dated note before opening the planning conversation:
- plan and workspace;
- surface: Chat, ChatGPT Work, Codex desktop, Codex cloud, or Codex CLI;
- selected model or mode;
- the limits and reset times shown in the usage dashboard;
- one sentence describing the decision the planning stage must produce.
ChatGPT Work is designed for larger tasks that produce a reviewable result, while OpenAI's pricing documentation states that Work and Codex share usage limits. Moving the planning task to Work does not create a second quota pool. If you use ordinary Chat, compare the dashboard before and after planning instead of relying on an old message count or another person's subscription.
Give ChatGPT the smallest useful evidence surface
A one-time planning task may need only a sanitized CSV export, a short log sample, and links to the relevant pull requests. Remove secrets and unnecessary personal data before upload. The artifact checklist for ChatGPT helps decide which files to block, redact, or replace with approved extracts.
A recurring analysis workflow can justify a private MCP server. OpenAI's plugin documentation says plugins can contain MCP servers and can work across supported ChatGPT and Codex surfaces. MCP can provide a controlled business-data interface. Unrestricted database access is still too broad.
Expose named questions instead of arbitrary SQL. A cost-analysis server might offer:
get_cost_by_service(start_date, end_date)with a fixed maximum range;get_cache_hit_rate(service, start_date, end_date)with aggregated output;get_daily_ingest_volume(source_group, start_date, end_date)without raw customer records;get_recent_deployment_changes(start_date, end_date)with approved identifiers and links.
Run these queries against a read replica, reporting store, or dated snapshot when possible. Cap the date range and returned rows, set query timeouts, and redact fields the planning task does not need. A database user that cannot write still may read secrets, expose personal data, or run an expensive query against production.
For private data, authenticate and authorize every request. The OpenAI authentication guide expects OAuth 2.1 for authenticated MCP servers and access-token verification on each request. Mark a tool readOnlyHint: true only when it cannot change state; the MCP server guide says that annotation does not replace server-side authorization or validation. Test every tool with representative, invalid, and out-of-scope inputs. The MCP server security checklist covers the full review, including the least-privilege and data-minimization controls in OpenAI's plugin security guidance.
Ask for a decision document
Replace the bracketed fields in this planning prompt. List the exact plugins and files ChatGPT may use. OpenAI's usage guidance recommends limiting source material and disabling MCP servers that the task does not need.
Goal Find the highest-confidence ways to reduce [cost or resource] without changing [protected customer behavior]. Decision boundary - Time range: [start date to end date] - In scope: [services, repositories, metrics, or workflows] - Out of scope: [billing changes, customer-facing behavior, schema migrations, deployment] - Decision owner: [name or role] Approved evidence - MCP tools: [exact tool names] - Repository or PR source: [approved source] - Files: [approved files] Evidence rules 1. Cite every important finding to a tool result, file, pull request, and date range. 2. Separate measured facts from estimates and hypotheses. 3. Do not infer a cause from correlation alone. 4. Mark missing or conflicting evidence instead of filling the gap. 5. Do not call write tools or request broader access. Required output 1. A current-state table with metric, value, period, and evidence. 2. A ranked opportunity table with expected effect, confidence, engineering effort, risk, and verification method. 3. One implementation brief for the best-supported opportunity. 4. Acceptance tests, rollback conditions, and unresolved questions. Stop if the evidence cannot support a specific change.
The output should make the next step cheaper to verify. Reject a plan that says only "improve caching" or "optimize database queries." A useful handoff identifies the measured problem, the evidence behind it, the likely code area, the smallest justified change, and how a reviewer will know whether it worked.
Review the plan before it reaches Codex
Check the plan against five questions:
- Does every current-state claim point to a metric, log, file, or pull request?
- Are estimates labeled, with assumptions visible?
- Can Codex test the proposed change without reproducing the entire analysis?
- Are protected behaviors and forbidden actions stated?
- Is deployment excluded until a human reviews the diff and test evidence?
The source article showed an Add to Codex control that moved the conversation into Codex. If that control appears in your interface, use it. Otherwise, paste the reviewed implementation brief and preserve the evidence links. Do not transfer an entire exploratory conversation if most of it is irrelevant to the selected change.
Give Codex a bounded verification and implementation prompt
Do not tell Codex to implement every worthwhile idea and deploy it. That instruction removes the scope boundary that made the planning stage useful. Use the reviewed plan as a hypothesis that Codex must check against the current repository.
Treat the attached plan as an unverified hypothesis. Before editing: 1. Verify each current-state claim against the current repository and available test fixtures. 2. List any stale, unsupported, or contradictory claim. 3. Identify the smallest approved change that satisfies the acceptance criteria. Implementation boundary: - Allowed files or directories: [paths] - Required behavior to preserve: [behavior] - Required tests: [commands or test names] - Forbidden actions: no production credentials, no schema migration, no unrelated refactor, no deployment After editing: 1. Run the required tests and relevant focused checks. 2. Show the changed files and explain how each change maps to an approved finding. 3. Report failed, skipped, or unavailable checks exactly. 4. Stop with a reviewable diff. Do not deploy.
For a longer implementation, add the budget and stop rules from the GPT-6 Astra prompting guide. Use human approval gates for database writes, permission changes, external messages, and release actions.
Measure whether the split actually saved usage
After the planning stage, check the same usage dashboard and record what changed. Repeat after Codex finishes. Keep the task definition, selected model, surface, start and end time, reset window, planning output, Codex actions, and test result together.
One run can show whether the planning route appears to draw from the same allowance on your account. It cannot establish an average percentage saving. A defensible comparison needs equivalent tasks, the same input boundary, multiple runs, and retained before-and-after usage evidence. If the dashboard exposes only rounded values, report the observed range instead of inventing precision.
| Observed result | What it supports | What to do next |
|---|---|---|
| Planning used a visibly separate allowance | This account and surface can shift planning away from Codex | Repeat with another comparable task before claiming a percentage |
| Planning reduced the same shared allowance | The handoff may improve focus, but it did not create a separate quota pool | Use tighter scope or a smaller model instead |
| No visible change or dashboard resolution is too coarse | Savings are unverified | Describe the workflow without a numerical claim |
Where the workflow wastes usage
- Without a before-and-after dashboard record, you cannot tell whether planning touched the same allowance.
- A confident plan based only on source code may miss what production metrics show.
- Arbitrary SQL lets the model request broad, sensitive, or expensive queries even when the account is read-only.
- Connecting every available MCP server adds context and consumes more of the limit. Enable only those needed for the planning question.
- A vague plan forces Codex to repeat the analysis before it can edit, restoring the cost you meant to avoid.
- A sound plan can still target code that changed after the analysis, so Codex must verify the current repository.
- Automatic deployment removes the final review point. Require test evidence and a human release decision before production changes.
When this workflow is worth the setup
The split works best when the decision depends on business metrics, operational history, and code context, while the final implementation is small enough to describe with clear acceptance tests. It is a poor fit for a localized bug where Codex can inspect the failing test and fix the code directly, or for a planning task that would require building an unrestricted production-data interface.
Confirm the allowance boundary before calling the result a Codex saving. If both stages consume the same pool, keep the narrower brief because it can still reduce duplicated exploration, but use OpenAI's documented options for conserving usage: remove irrelevant context, limit source material, disable unused MCP servers, tighten the task, or choose a smaller model for routine work.
