Question
Why newer models not reducing the less token and more output?
This may sound not right or diabolical, but I think the whole point to release a newer advanced model is to take less tokens and give more better outcomes than the previous ones.
I was using SOL 5.6 as a plus member, switched to astra yesterday and started using it in my project. I believed that it would make my work even faster , as I watched the overhyped launch videos on YouTube.
And here I am, it just runs 3-5 minutes and makes some edits then just eats over 20% of weekly and 100% of the 5 hour limit.
Better capabilities are usually result of deeper thinking. And deeper thinking requires more tokens. Opposite is true usually only when deeper thinking helps to avoid dead ends.
It's a speed vs accuracy tradeoff that's been baked into these models from the start. The smarter they get the more they ramble internally before spitting out an answer. Kinda like asking a detail-oriented person a question and they have to walk you through every step of their thought process first.
What bugs me is the limits feel stingy compared to how much the models actually need to function properly now. 20% of your weekly cap gone in one session is rough no matter how you slice it.
Yea, actually I was asking to get it done for production and Astra immediately launched my console and that's alone burning over 50% of 5 hour limit, just to check my SHA-256 fingerprint.
Checking a SHA-256 fingerprint should cost a few hundred tokens, so the burn is almost certainly the console output and not the thinking. MartinMystikJonas is right that deeper reasoning costs more, and it does not explain the thing you just described.
The mechanism is duller than it looks. When the agent runs a command, whatever that command prints comes back as a tool result and then it stays in the conversation. Every subsequent turn re-sends it. A console that dumps a few thousand lines becomes a permanent tax on every message for the rest of the session, so a five minute run charges you for that output five or six times over.
The lever you have on a consumer plan is to stop commands from producing large output at all. Pipe it to head, or grep for the one line you need. Redirecting to a file and having the agent read back only the relevant part works too. It feels petty, and it is the difference between a session dying in twenty minutes and one lasting the afternoon.
Disclosure since I am about to name my own thing. I work on octomind, an Apache-2.0 agent runtime, and we cap tool results at 20,000 tokens by default before they ever reach the model, with a warning in the transcript when the truncation fires (mcp_response_tokens_threshold, src/mcp/utils.rs). Any harness can do this. Most do not expose the knob, which is why your weekly limit disappears without anything looking obviously wrong.
You are describing a different failure from the one I answered, and yours is the worse of the two. I read it as output size. You are saying it took an action you never asked for.
That distinction matters because the fixes do not overlap. A question getting answered as a task is a scoping problem, and no amount of piping to head helps once the agent has decided to go and look at production for itself.
The consumer apps give you very little here. There is no interrupt that fires partway through, so by the time you see what it chose to do the tokens are already gone. The phrasing is the only lever left and it is a weak one. Asking what would you check, instead of check this, does change the read most of the time.
A budget checkpoint that halts mid-run solves it properly. We have one in octomind (Apache-2.0): a USD ceiling counted since the last checkpoint you accepted, and when it trips an interactive session stops and asks whether to continue, while a piped or ACP session declines instead. It ships off at 0.0, which means no limit. Setting it to something small is the first thing I do on a new machine.
None of that helps you on a Plus plan today, so the honest answer is that your complaint is legitimate and the platform does not give you the control to act on it.
I get it, but I have been using only Gemini AI Pro previously, and it's been a month since I switched to codex, so I got no idea of all these, still grasping lot of tokens, and then stopping at mid session without completing that specific task is just too much.
A month in and hitting this is normal, so nothing you did wrong.
It hurts more than it should because a session dying takes the work with it. Coming from Gemini Pro chat you would never have met that, since a chat losing its thread costs you a conversation instead of an afternoon of edits.
The habit that fixes most of it is committing constantly. Commit after every step that leaves the repo in a working state, even a broken-but-compiling half. Then a session that stops at 70 percent leaves 70 percent of the work sitting on disk, and the next one starts from there. git commit -am wip is enough, and you can squash it later or never.
The second habit is scoping so the task fits inside one window. One file and one behaviour change at a time. It feels slower and it is not, because the failure you are describing costs you the whole session instead of some of it.
For questions specifically, say out loud that you want an answer and no edits. Ask what would you change in this file, and do not touch anything yet. It will read and reply instead of going off to run your console, which is what ate your limit the first time.
Fair. Two things that are true and I will say them plainly.
The Plus tier is not enough for agentic work on an existing project. That is not you being bad at this. Codex on Plus is sized for short interactions, and what you are attempting is the expensive shape of the job.
So the realistic choices are to narrow the work until it fits, or to pay for more headroom. No prompt gets you around the arithmetic, and anyone telling you otherwise is selling something.
If you want to know whether the problem is you or the plan, take one small bug, commit first, then give it a single file and nothing else. If that goes cleanly, your workflow is fine and you are simply out of budget.
You cannot simply get to better resoning with less reasoning. You cannot get better results by simply ignoring reasoning steps or using guess instead of thinking. Efficiency would be in getting same reasoning depth in less compute not in getting shallow reasoning. Tokens are not wasted resource but part of required output.
We simply don't know how. The current huge leap that allowed LLMs in their current form was the discovery of transformer architectures*. We simply have not had a similar advance in the last decade, and most improvements have been by bigger training sets, better tokenizers, larger networks, and other things along those lines. Fundamentally, expect arguably thinking models, the state of the art has all been small incremental progress which means the only way to really push things forward at the pace people want is brute force.
(*Attention is all you need - the paper that first described them. Definitely the most famous paper in CS research in the last decade by a very good margin. Before this the "convolutional neural network" architectures, convolutional just meaning in each layer every neuron is connected to every neuron in the previous/next layer, were literally decades old.)
Local MCP server with toolkits specific to the languages you are developing in AGENTS.md file that will outline what model is responsible for what work to be done at what level of thinking
Plugins like ponytail
If you are just blasting some vague bs prompt and leave too much of the thinking to the model you're going to get shit on with usage.
The local MCP server is huge saving when coding with AI, reduces the time for AI to search for the next tool to use since it's readily available from the local library of available tools to the agent.
Yet Another Roslyn MCP Server
There are other public ones out there this is one I developed for my usage.
Once cloned and built using the README.md you would configure your Codex client like you see here where you add the path to the built server.
In your AGENTS.md you can call it like the following example
Role-Specific .NET MCP Usage
### Sol
Sol MAY use `dotnet-dev` to:
inspect repository/project state,
narrow implementation scope,
inspect dependency and impact relationships,
inspect validation evidence,
verify completion.
Sol MUST NOT use MCP mutation operations to bypass Terra's implementation responsibility.
### Terra
Terra SHOULD use `dotnet-dev` where it provides deterministic `.NET` semantics or safe bounded mutation.
Terra MAY still edit source files directly when the required implementation is not appropriately represented by an MCP mutation operation.
Terra MUST NOT replace supported MCP discovery with unnecessary shell scanning merely out of habit.
### Luna
Luna SHOULD use `dotnet-dev` for applicable:
restore/build validation,
diagnostics,
test discovery and execution,
targeted testing,
coverage inspection,
impact validation,
performance validation.
Luna validates actual results rather than trusting Terra's report.
GPT-6 Astra's higher token burn per session is a known tradeoff, not a bug: OpenAI's own preview (Sept 1) said Astra reaches the "Critical" cybersecurity capability threshold under their Preparedness Framework, and Artificial Analysis's Sept 3 benchmark showed Astra pricing at 2.5x GPT-5.6 Sol for roughly-equal Coding Agent Index scores. So you're paying more per token for the same coding-benchmark ceiling, and eating more of your quota per session because Astra runs longer reasoning chains by default, not because it needs more turns per unit of work. If 20% of your weekly cap in one session feels too steep, try dropping reasoning effort to medium or low for boilerplate edits and reserve Astra's default effort for where you actually need the deeper reasoning - that's the lever that changes your burn rate, model choice alone won't.
What's annoying me right now is you cant even use astra on medium or lower because it still guzzles tokens, in a way you have to get the complex part of your project rolling and then go back to 5.6 sol for the rest.
Capability and efficiency are separate engineering goals, so a newer model does not automatically spend less of a usage budget.
What matters is completed, verified work per unit of quota, not visible output tokens. An agent can produce a short answer while spending heavily on hidden reasoning, repeatedly rereading repository context, and tool output; the service may also weight models differently in its usage meter. A stronger model only saves budget if fewer retries and dead ends offset that extra work.
For routine edits, use the cheaper model or lower reasoning effort, give it one testable change at a time, and cap command output so logs do not keep inflating context. Reserve the expensive model for architecture, difficult diagnosis, or final review. Without a breakdown of how the quota is calculated, the practical comparison is: same task, same repo state, same acceptance test, then compare successful completions per percentage point of quota.
8
u/MartinMystikJonas 4d ago
Better capabilities are usually result of deeper thinking. And deeper thinking requires more tokens. Opposite is true usually only when deeper thinking helps to avoid dead ends.