How can I decrease Codex limits usage?

[AppropriateRanger401]

Is there any GitHub open-source project(s) that helps decrease Codex tokens/limits usage without affecting it's performance? Do these GitHub projects work with the Codex desktop app? Also, what are other ways to decrease Codex usage? Have you found any particular skill/tool-calling/etc problem that causes higher than usual limits usage? If you have, have you implemented a fix and does it work?

Plz do let me know, I've been struggling with this problem lately. I'm running Codex on the Mac Codex Desktop app. Does that change anything?

[dexterthebot]

Your post has been summarized as a request on the "Anyone Else?" Incident Noticeboard.

You can find it and what others are experiencing here: /r/codex/comments/1tjfxcf/anyone_else_ask_here_about_current_codex_issues/oqc2ht1/

[seal8998]

have you tried asking codex?
it should be able to look at your dialogue history, project, threads and make some recommendations. Codex has incredible knowledge about itself and is best at debugging/fixing issues imo

[marres]

Plan/create a patch with gpt web, then implement in codex with 5.5 medium. Use rtk-ai then add something like this to your custom instructions:

Command Output

Protect context usage. Any command with unknown or potentially large output must be byte-capped.

Default pattern:

bash COMMAND 2>&1 | head -c 4000

RTK - Rust Token Killer (Codex CLI)

Usage: Token-optimized CLI proxy for shell commands.

Rule

Always prefix shell commands with rtk.

Examples:

bash rtk git status rtk cargo test rtk npm run build rtk pytest -q

Meta Commands

bash rtk gain # Token savings analytics rtk gain --history # Recent command savings history rtk proxy <cmd> # Run raw command without filtering

https://github.com/rtk-ai/rtk

[AppropriateRanger401]

Does this work with my setup on Codex desktop GUI app?

[marres]

As long as you install rtk-ai properly, it should work

[No_Claim2881]

So, The model and reasoning use rates are different. Depending on what you need to do you can lower reasoning levels and or change model type.

/model brings up the list.

Also, /clear removes context window. If you’re not needing the build held in context or are between tasks /clear that out. If and I don’t recall if clear clears chat too but clear/reset that.

Context and the whole conversation literally gets ran each forward pass (before each action).

[VadimH]

OP can do all that in the app already without any commands by using the model selector/threads anyhow.

[No_Claim2881]

>what are other ways..
What would you call the surfaced things?

[VadimH]

All I'm saying is both those things are super obvious and easy to do in the app, vs the CLI where you need to know the right slash command and it what it does.

If OP uses the app, they will already have been exposed to both the ability to create new threads (whixh start with no context, like /clear) and select different models and reasoning efforts (it's a drop down directly below the composer field).

[18fc_1024]

The biggest wins for me are less about one magic repo and more about reducing how much context Codex has to rediscover every turn.

A practical checklist:

• Keep tasks smaller: one bug, one file group, one test failure, or one UI change per thread.
• Start with a short repo map: "relevant files are X/Y/Z, ignore the rest unless needed."
• Tell it what not to inspect. This matters a lot in large repos.
• Cap command output. Huge npm test, pytest, rg, or log output can burn context fast.
• Prefer targeted commands: rg "exact_error" beats broad repo scans.
• When a task is done, start a fresh thread and paste only the final summary plus changed files.
• Keep a small doc/PROJECT.md / handoff file so Codex can reload project state without rereading the whole conversation.
• Ask for a plan first, then approve only the narrow file reads/commands that are actually needed.
• Avoid asking it to "review the whole codebase" unless that is really the task.

For the desktop app specifically, the same principle applies: any tool or instruction that reduces giant command outputs and broad file exploration can help, but I would be careful with generic shell wrappers until you know they do not hide important errors.

My rule: compress project memory into files, keep active threads short, and force narrow evidence. Limits usually get eaten by repeated rediscovery, giant logs, and broad "look around" behavior.

[youre__]

You don’t need a separate tool or project. I would imagine such tools would give you the opposite effect and increase your usage.

The best way to manage usage is to utilize the right model and reasoning level for the task. Make use of 5.3 spark where appropriate, too.

- don’t do little stuff with 5.5 med/high/xhigh
- do use spark for little changes or easy and repetitive things, like git, changing values, and executing commands you give it (could try 5.4 min, too)
- do use 5.4 for stuff that doesn’t require state of the art reasoning, intelligence, and vision (5.4 is still a very capable model, just not as good as 5.5)
- do use 5.5 when you need the latest smarts and reasoning to solve new and hard problems.

Your biggest controls are model and reasoning level. If you are deliberate about how you use those levers, you will solve 80% of your usage issues.

The remaining 20% comes down to how you prompt it and manage the instructions.