18 Insane Codex Token Hacks Every Developer Should Know

Main idea: “Codex token hacks”

The speaker argues that Codex performs best when its working memory (thread context) and tool access exactly match the job. Most “hacks” are about reducing context pollution, avoiding wrong paths early, and structuring long runs so they don’t drift.

---

Key techniques / recommendations (technically oriented)

1) Use a fresh thread when context grows stale or becomes irrelevant

• Keep tasks with unrelated objectives out of the same conversation.
• Starting a new thread reduces stale assumptions and narrows working memory.
• Also recommended when Codex repeats the same failure 2–3 times or when multiple attempts yield diminishing returns.

2) “Connect only the tools needed” and disable anything that pollutes context

• Codex tool choice impacts reasoning options.
• Practical rule: enable only the MCP servers/tools needed for the current task; disable the rest (via Command + , → MCP servers).

3) Prefer “rewrite and rerun” over stacking repeated micro-corrections

• If Codex is wrong early, multiple short corrections are costly because they remain in the thread.
• Better: rewrite the original prompt into the correct version, then rerun from cleaner instructions.

4) Use prompt editing instead of follow-up message spam

• If you realize you made a mistake mid-run:
  • stop
  • edit the prompt with specific changes (e.g., exact file/function, concrete requirements)
• Goal: avoid extra messages that contaminate context.

5) Use Plan mode to prevent wrong file edits (especially for bigger tasks)

• Plan mode lets Codex inspect, ask only the decisions that matter, and propose the smallest change before altering files.
• Treated as a “checkpoint” before a build/debug or edit-heavy loop.

6) Choose speed/latency settings intentionally (Fast vs Standard)

• “Fast mode” trades higher usage for lower latency; it’s not automatically better or cheaper.
• Use Standard as default for most tasks.
• Use Fast when waiting is expensive (live debugging, rapid edit loops, time-sensitive runs).
• Model + speed both matter; defaults should be conservative unless latency is critical.

7) Provide narrow, structured context instead of dumping whole documents

Codex usually needs:

• the exact excerpt
• file path
• schema
• error text
• function signature

Instead of dumping lots of material:

• “Start narrow; let Codex ask for missing context.”
• Even when adding logs/PDFs/web pages, avoid unnecessary attachments.

8) Define long-running goals with stop conditions (avoid open-ended prompts)

For multi-hour/day work, use a “goal” feature with:

• clear objective
• success conditions
• stop conditions
• turn/checkpoint limit

This prevents drift by forcing Codex to pause for new instructions.

9) Use agents.md as a router-style guide (not an encyclopedia)

Each project can include agents.md to enforce consistent behavior.

• Should contain:
  • core rules
  • key commands
  • important conventions/conversions
  • links to deeper docs
• Avoid stuffing it with unrelated background; keep it navigational.

10) Make prompts specific to reduce “repo searching” cost

• Broad prompts introduce unknowns, and Codex spends tokens discovering likely files/areas.
• Exact references (route/component/error/file) free budget for reasoning and verification.

11) Create handoff prompts to cut context staleness

For long threads:

• produce a focused “handoff” summary:
  • current goal
  • relevant files
  • decisions already made
  • known failures
  • verification commands
  • exact next task
• paste the handoff into a new conversation for a clean restart.

12) Control tool output so terminal logs don’t dominate the context

• Terminal output can become the largest chunk of “context in the thread.”
• Limit logs using targeted commands, filters, short summaries, output caps.
• Ensure external tool runs only return necessary data.

13) Interrupt drift early in long Codex runs

• If Codex starts irrelevant file reads/search/escalating scope creep:
  • stop
  • re-scope to the smallest useful action
• Restart the thread if the same issue persists or repeated attempts fail.

14) Use the right reasoning level for risk

• Don’t always choose highest reasoning.
• Lower/lighter reasoning for low-risk changes (copy edits, formatting, small refactors).
• Higher reasoning for high cost of being wrong (architecture, migrations, security, unclear bugs, multi-step debugging).
• Suggested modes: low/medium/high/extra high (reserve extra high for extreme cases).

15) Use sub-agents sparingly (they cost tokens and add complexity)

• Sub-agents require their own context/instructions and must sync back.
• Worth it only for isolated research, independent review, or bounded work that shouldn’t pollute main context.

16) Convert repeated workflows into “skills”

• If you repeatedly instruct the same workflow, it should become a skill.
• Example: encode a reusable step as a skill and invoke via / instead of re-explaining.

17) Reuse prior solutions via deep links (avoid re-creating context)

When a previous thread solved a similar problem:

• copy deep link
• reference it in the new thread

Use it for approach/decisions/verification path—not as a giant context dump.

18) Ask Codex for setup/mode/checkpoints before building complex features

For scripts/apps/migrations/multi-file changes:

• ask Codex what mode, tools, checkpoints, and verification path it recommends
• the win is “shaping the run before it spends context.”

19) If unsure which model/reasoning mode to use, ask Codex to recommend

• Use a prompt pattern that makes Codex infer the best model + reasoning mode based on problem type.

---

Main speakers / sources

• Main speaker: Not explicitly named in the subtitles (appears to be a single instructor/host guiding Codex usage tips).
• Source: Codex (implicitly) and its UI features: threads, MCP servers, plan mode, reasoning/speed modes, agents.md, skills, sub-agents, deep links.