7 Free Ways to Stop ChatGPT From Eating Your CPU, RAM, and Disk

Start With a ChatGPT Performance Diagnosis#

A slow answer is one problem. A hot local process is another.

Fix 1: Diagnose the hot component before changing anything#

Reproduce the slowdown while watching Task Manager or Resource Monitor on Windows, Activity Monitor on macOS, or a process monitor on Linux. Compare the same action before and after one change.

• Record the process name and its parent process.
• Watch the CPU trend while the action runs and after it stops.
• Note whether memory climbs, settles, or falls.
• Capture disk writes and their destination.
• Write down the exact action that wakes the process.

Keep the monitor open before you trigger the problem and until the system settles again. A brief launch spike differs from sustained load or memory that keeps climbing; for disk, capture both the writer and destination.

When a current Codex CLI is installed, codex doctor --summary is an optional static health and configuration baseline from the official developer commands. It is not a live CPU, RAM, or disk profiler.

codex doctor --summary

Use the table to choose the next test. Its middle column lists hypotheses from affected reports, so process ancestry and a repeated action still have to confirm the candidate.

Local stalls and slow remote answers can look identical inside the chat window. A renderer spike tied to one old thread calls for a thread test, while Git activity tied to one workspace calls for a repository test.

The absence of sustained load leaves the cause unresolved. Compare another workspace or client, and inspect short spikes, I/O wait, GPU activity, and child processes. If every client only waits on answers, check networking and service status.

Cut Thread RAM and Restore Work#

A long active thread carries old messages, tool results, compaction history, and visual context. Starting the next task with New chat leaves the prior session intact while dropping that history from the active job. OpenAI documents New chat as a first-class desktop command.

Fix 2: Start each new task in a fresh thread#

New chat changes the active working context. It does not erase the prior conversation or repair a service incident. That makes it a low-risk test when one task grows heavy and other local Codex work remains responsive.

When one old task is the only place memory keeps climbing, a fresh thread is the safest first test. The old session stays available.

• Goal: the result you are trying to reach now
• Decisions: choices already accepted and why
• Constraints: requirements that still apply
• Relevant files or assets: names and locations for the current task
• Current state: the latest result and failing check
• Next action: the first concrete step in the new thread

The fresh thread removes prior messages and tool output from its active context. Verify whether that lowers the resource trend you recorded. If the old thread will not open, rebuild the short handoff from current files and memory.

Fix 3: Bound retained tool output and compaction#

Large test logs, broad repository searches, and repeated tool dumps can dominate retained history. Narrow the command before changing retention.

These controls affect what the conversation retains. They do not make a slow test, search, or build execute faster. Fix the command when execution is slow, then use retention controls when the completed output keeps swelling the thread.

Codex reads these controls from $CODEX_HOME/config.toml, as documented in the official sample configuration. model_auto_compact_token_limit sets the automatic compaction threshold, while tool_output_token_limit bounds tokens retained from each tool result.

Warning: The values below are documentation examples, not recommendations. Record your current state before editing either key.

# Documentation examples only
model_auto_compact_token_limit = 64000
tool_output_token_limit = 12000

The sample values demonstrate valid integer syntax. They say nothing about the right limit for your model or workload, so the before-and-after process measurement remains the deciding evidence.

1. Record whether each key is absent or note its current value.
2. Start a fresh task and capture the baseline process and memory trend.
3. Change one key only, then rerun the same output-heavy workload.
4. Check whether the measured process improves and required evidence remains visible.
5. Remove the new line or restore the prior value when evidence disappears or the process remains hot.

No universal value fits every model and task. These Codex performance settings affect the local desktop, CLI, and IDE configuration layers. Ordinary ChatGPT web ignores them.

A lower retained-output limit can hide the failure line you needed. Earlier compaction can also drop useful history, which is why the rollback step belongs in the fix.

Fix 4: Split image-heavy work into short visual threads#

In one staged Windows report from the ChatGPT desktop app's Codex view, a window containing two images opened in 21.7 seconds while a different window containing 40+ opened in 313.7 seconds. The model, search use, session profile, record count, and stage order also changed.

Treat the case as an early warning. Reset the visual thread when restore or input lag repeatedly blocks the task, and keep the previous session as the record.

Store accepted images and historical drafts in the project or another external library. The next thread should receive the current visual evidence plus the text checkpoint. Reattach an older frame when comparing it can change the decision.

1. Finish one review pass or visual decision.
2. Write the accepted result, unresolved defect, and next action as text.
3. Open a fresh thread and attach the minimum current visual evidence.
4. Keep older screenshots externally and attach one only when the comparison changes the next decision.

Rollout JSONL edits and session-index repair sit outside supported cleanup. A fresh thread changes active context without hidden-state surgery.

Stop Workspace and Helper CPU Loops#

Local CPU loops usually come from the workspace or a helper process. Separate those paths before changing either one.

Fix 5: Keep generated data outside watched and tracked workspaces#

Generated recordings and build products can make Git or workspace watchers busy. One affected repository report associated about 28,000 tracked generated files with a Git child-process storm. It documents one affected pattern and establishes no safe repository-size boundary.

A high-CPU report becomes actionable when the spike follows one workspace. Repeat the idle test in a small repository or empty folder; if the Git child settles there, inspect the original repository.

Move only regenerable bulk, and first confirm the build can find it elsewhere. Keep source inputs and regeneration instructions in the project. Coordinate repository-wide tracking changes with the team.

1. Identify the directory tied to the repeatable Git or watcher spike.
2. Classify its contents as source, dependency, cache, recording, generated output, or user data.
3. Preserve anything non-regenerable before moving a byte.
4. Move regenerable bulk outside the watched workspace when the build allows it.
5. Reproduce the same action and recheck the Git child or watcher.

Warning: Adding a path to .gitignore does not untrack files already committed. Stopping tracking is an intentional repository change that should be reviewed with the team.

The distinction is mechanical. .gitignore prevents matching untracked files from being added later, while committed files stay in the index. Any removal from tracking changes the repository and can affect teammates, automation, and deployments.

Fix 6: Disable unused MCP servers and verify helper lifecycle#

Local STDIO MCP servers run as local processes for the life of their owning client. Call a helper stuck only when the exact child remains unexpectedly after that client ends or restarts. OpenAI's MCP documentation supports listing and disabling configured servers.

Capture the helper PID and parent before restart. After the owner exits, verify whether the same child survives and stays active. A newly launched child after restart is a different lifecycle observation.

codex mcp list

For a server ID you have confirmed is unused, keep the definition and change its enabled state.

[mcp_servers.example]
enabled = false

Replace example with the configured server ID. Restart the exact owner: ChatGPT desktop app, IDE extension, or the Codex CLI session. Recheck the same child process.

Disabling preserves the server definition. Compare idle use after the restart, then run the workflow that launched the helper. Re-enable the server if the symptom persists and its capability is required.

Reduce Disk Churn Without Deleting Sessions#

Old reports of huge plaintext logs still surface in disk-usage searches. For the CLI/TUI, current OpenAI environment documentation says interactive diagnostics are bounded by default, while plaintext codex-tui.log is opt-in through log_dir.

Fix 7: Stop unnecessary logging growth and clean state safely#

Those three names are CLI/TUI checks. On macOS, desktop app logs are documented under ~/Library/Logs/com.openai.codex/YYYY/MM/DD. For another surface, open its diagnostics and identify the actual writer process and destination.

Check whether RUST_LOG still requests debug or trace output and whether log_dir remains after CLI troubleshooting. Remove temporary verbosity when the run ends. Preserve a needed log and inspect it for secrets before sharing.

• Logs and bounded diagnostics explain behavior on their owning surface.
• Active and archived session transcripts live in separate directories under CODEX_HOME.
• SQLite-backed application state uses CODEX_SQLITE_HOME or sqlite_home.
• Configuration and authentication remain separate state.

The supported command codex archive <session-id-or-name> organizes saved sessions without deleting their transcripts; resolve and verify the exact target first, and preserve anything irreplaceable. Archiving does not stop an active writer or guarantee disk reclamation.

Skip hidden-directory cleanup, generic cache cleaners, rollout edits, and SQLite or WAL surgery. They can destroy history while missing the writer responsible for the churn. Fix the active logging override or component, then reproduce the original disk symptom.

Choose One Fix From the Hot Component#

Branch from the component you verified. Change one related thing, and restart only when that fix calls for it.

After the change, reproduce the same symptom and watch the same process. If the spike remains, return to Fix 1 and verify the next candidate.

An absent sustained spike leaves several local possibilities open, including short bursts, I/O wait, GPU work, or a stalled child. Compare another workspace or client before moving to network, model, or service checks.

The questions below were raised on Reddit, the OpenAI Developer Community, Stack Overflow, and GitHub. Each item links the exact discussion; the answers use current OpenAI documentation, not thread workarounds.

When my machine heats up, I trust the process tree, trigger, and before-and-after resource trend more than another speculative tweak. Save that record for the next recurrence.