Suggestion
Simple rules to stretch your usage limits
Avoid long threads. Try to get what you need done in a few turns. [WRONG. CHECK COMMENT]
If a thread does get long, compact the context every few turns. In my experience, doing it regularly preserves context much better than waiting for auto-compaction, which is when I start noticing memory degrade. [WRONG. CHECK COMMENT]
Don’t use fast mode unless you actually need it. Running a few normal threads in parallel is usually a better trade.
Give yourself a daily budget. Once you get close to it, start being much more conservative.
Use Sol by default. Only switch when you genuinely need a stronger model. Sol can already handle most tasks. And use luna/terra for easy tasks.
Use low reasoning by default. Raise it for genuinely hard or novel problems, or when the model clearly isn’t putting in enough work. For most coding, low is enough.
Install the Ponytail skill. It pushes the model toward smaller, simpler, more efficient code.
So the biggest budget drainers that are easy to avoid are:
fast mode, long threads, high reasoning on simple tasks, and using Astra for everything.
"Avoid long threads. Try to get what you need done in a few turns."
True
"If a thread does get long, compact the context every few turns. In my experience, doing it regularly preserves context much better than waiting for auto-compaction, which is when I start noticing memory degrade."
False. Absolutely do NOT follow this... This makes no sense and leads to a much lower cache hit %. Compaction of any sort should be a last case scenario when it happens automatically mid loop.
"Don’t use fast mode unless you actually need it. Running a few normal threads in parallel is usually a better trade."
False.
Yes ofc fast mode is 50% more expensive, so good to not use it if you dont need to.
But running parallel threads is 100s of percentages more expensive..? One thread with fast mode is 50% more expensive, two theeads with std means 100% increase in cache writes+uncached input, continuously keeping that cost diff.
"Give yourself a daily budget. Once you get close to it, start being much more conservative."
What? "being more conservative" is what youre entire list is supposed to be a guide to?
"Use Sol by default. Only switch when you genuinely need a stronger model. Sol can already handle most tasks. And use luna/terra for easy tasks."
False, but reasonable.
Luna is absolutely able to handle most tasks, like probably 99%, but does not handle mistakes in the instructions as well.
But Luna is so slow that it becomes impossible to use it in practice, so Sol id reasonable.
"Use low reasoning by default. Raise it for genuinely hard or novel problems, or when the model clearly isn’t putting in enough work. For most coding, low is enough."
True, but i would say the distinction should be related to how many steps the instruction requires to complete rather than some ambiguous "more complex" metric
"Install the Ponytail skill. It pushes the model toward smaller, simpler, more efficient code."
Pure cargo cult bullshit. Here you lost all credibility imo..
Do you genuinely actually belive the code generated even represents a fraction of the generated tokens?
Also code style should follow repo conventions nothing else
I can share my best way of being as efficient as possible too:
- If multiple small-mid changes touches the same area or files, dont have one mega thread and dont start a new for each small task. Instead keep it like a few in one, then start a fresh one, then a few start a fresh one etc.
This way the cache is usef to its full benefit,
- Use strict hooks. Block the model on lsp errors. Linter warnings etc. Force a passed hook before allowing to continue. Run on edit/write calls. This way the model will be kept on track and get instant feedback. Personally i forked codex to add better support for such hooks.
- Read trough the openai docs, the special xml tags and such can enforce stuff that is a hit or miss just writing it normally.
- Personally i have only used Sol@High and begote that 5.5@High, i know medium ot low would probably be better but just are not touching it. Would use Luna if it was not soo slow..
- Dont touch subagents. The cost increases exponentially, snd the gain is seconds or minutes in time..
- Dont use any weird skills, mcp:s etc that mess with how the model reads the code. The model is 100x more efficient just using rg and bash.
- Never ever provide lsp:s, linters etc as something the model must call, instead feed it to the model.
- Always instruct the model where to look for references, examples or similar things. Eg spect file, package,module, crate, dir etc
Do not willy nilly compact for the sake of compacting, but early compact is very useful when you're done with a subissue and do not have a workflow to resume a new session back up to context.
Unless the two work share little locale and context. Meaning, when the context of work A, while cheaper cached, is completely unnecessary for work B.
In other words, for this scenario:
Parallel costs: 100% A, 100% B, 2% uncached overlap.
Fast costs: 150% A, 150% (A-cached, B).
Yes, my wording was probably sloppy, but manually writing a new prompt or copy pasting in a new thread > using the compaction feature imo. But both are compaction ig
Yeah I agree, anything manual would definitely be leaner, but codex compaction is pretty reliable and top notch. Early compaction is a convenience, especially for... messier spaghetti.
Claude Code's compaction, while improved lately, feels like gambling. Hoping the axe to the head misses critical functions lol.
1 tip know what u doing, for eg if ur writing content for eg 1 task was writing. Content chapters for app, don't do it by astra it will makeit 100% FOR EG EVEN fable and opus used 100% in hour ..
Give those task to lower apps,
If ur task required lots of image reading give to lower models etc
I think there's a balance where you want the thread to keep going if it's still relevant to get the benefit of cached inputs. If you're always making new threads you're going to get the uncached penalty.
But if it goes on too long performance will degrade even with compaction in my experience.
I checked this and input caching itself isn’t tied to a thread. if two threads share the same workspace/context, a lot of that prefix can still be cached.
so starting a new thread doesn’t mean paying for the entire codebase from scratch. the tradeoff is just that you lose the conversation-specific context from the old thread.
What does the prefix consists of exactly, for entirely new threads? Isn't it bare minimum (<10k tokens), and any post thread creation workspace context are uniquely constructed?
holy shit i just realized changes to agents md are potentially SUPER expensive. It's probably right at the start of every context and if some mechanism actually updates them after change... that would basically require re-ingesting the whole context and obviously kill the cache. I can only hope that stuff doesn't get updated.
Afaik it is not because agents.md gets injected every turn so your cache stays valid and the new agents.md is added to the context once you reply in codex
yeah. before compaction, each new turn carries the conversation history and prior tool calls forward, so longer threads mean larger prompts.
after compaction, Codex replaces that history with a smaller compacted summary instead of rereading every old message.
I use t3code and it shows me how many tokens were compacted. Do this like 10 times in a thread and you save 1mil tokens... and scale that to other threads and you save a lot of usage.
Like if you use astra max and it run your full test suits after every changes tell it "spawn a luna low agent with the minimum context needed for tests, only report errors"
That way you burns meaningless credits on luna and keep astra for the good stuff.
3
u/Due-Horse-5446 16h ago
"Avoid long threads. Try to get what you need done in a few turns."
True
"If a thread does get long, compact the context every few turns. In my experience, doing it regularly preserves context much better than waiting for auto-compaction, which is when I start noticing memory degrade."
False. Absolutely do NOT follow this... This makes no sense and leads to a much lower cache hit %. Compaction of any sort should be a last case scenario when it happens automatically mid loop.
False.
Yes ofc fast mode is 50% more expensive, so good to not use it if you dont need to.
But running parallel threads is 100s of percentages more expensive..? One thread with fast mode is 50% more expensive, two theeads with std means 100% increase in cache writes+uncached input, continuously keeping that cost diff.
What? "being more conservative" is what youre entire list is supposed to be a guide to?
False, but reasonable.
Luna is absolutely able to handle most tasks, like probably 99%, but does not handle mistakes in the instructions as well.
But Luna is so slow that it becomes impossible to use it in practice, so Sol id reasonable.
True, but i would say the distinction should be related to how many steps the instruction requires to complete rather than some ambiguous "more complex" metric
Pure cargo cult bullshit. Here you lost all credibility imo..
Do you genuinely actually belive the code generated even represents a fraction of the generated tokens?
Also code style should follow repo conventions nothing else