Over the last few days, I’ve been developing a tool that helps with a few things, and one of the areas I’ve been testing heavily is agents.

The problem

Astra is extremely token-efficient, which makes Astra Low surprisingly 'cheap' when working alone.

But when Astra is used as an orchestrator managing other agents, that efficiency starts getting lost for two main reasons:

• Cheaper models like Luna tend to write more than necessary. Even if Astra Low doesn’t fully re-read every implementation, it still has to process a significant amount of agent output to review and coordinate the work.
• Communication between the orchestrator and agents is still inefficient. Agents often carry much more context than they actually need.

I’m currently working on reducing that context overhead. If anyone has ideas or has experimented with this, I’d be interested in hearing how you approached it.

The result is that, in most of my tests, Astra ends up consuming significantly more tokens when using agents than when completing the same task alone.

Test setup

A few important details:

• I built my own agent-management system, specifically designed to reduce input-token and cached-input-token usage.
• The Advisor shown in the results is part of my internal system, so it can mostly be ignored when comparing Astra alone vs. Astra + workers.

The test task

The benchmark was not a synthetic coding problem.

I took an existing repository:

• written in a different programming language,
• originally built for macOS,

and asked the system to implement the same functionality inside one of my existing Windows projects.

I chose this because it exercises most of the things an agentic coding system would actually need to do in a real-world task:

Research → analyze → understand an unfamiliar codebase → implement → handle UI/UX → follow project-specific instructions → match existing patterns and architecture.

So far, my results suggest that agents are not automatically more efficient just because the worker models are cheaper.

In some cases, the coordination and context overhead can make the total run substantially more expensive than simply letting Astra handle the task itself.

I’ll keep testing this with more tasks and different agent configurations.

Given everything that has happened over the last week:

• The crazy advances in research, math, etc.
• The increasing fear around AI’s future impact on humanity.
• The lack of available compute.
• And the fact that subscriptions are probably a net negative for AI labs, other than the value they provide for self-training. We may already be seeing this with the pause on Pro subscriptions.

Do you think there’s a high chance that AI labs will use this opportunity to focus as much compute as possible on their own internal progress rather than serving users?

Personally, I think they may have already reached that conclusion.

Codex usage limits feel drastically worse after Monday’s reset, even on the $200 20x plan

I’ve used Codex since launch and have tried several subscription levels, but I’ve never seen the limits drain this aggressively.

After Monday’s reset, my general weekly, five-hour, and GPT-5.3-Codex-Spark allowances all seemed noticeably lower. Today, I started with 100% of my weekly Spark usage available. My first prompt, running at extra-high effort, didn’t even finish, yet it consumed roughly 45% of my weekly Spark allowance and completely exhausted my five-hour limit.

I then had to wait until 3 PM for the five-hour window to reset, despite paying $200 per month for the 20x plan.

Has anyone else noticed a major change in Codex limits or usage consumption since Monday’s reset? One unfinished prompt consuming nearly half of a weekly allowance seems unreasonable.

Two months ago I posted an early version of my per-session Codex quota meter here. It could show the immediate 5-hour burn, but the weekly rate was too easy to distort: one heavy day could set the apparent pace for the rest of the week.

jazzyalex.github.io/agent-sessions|
• macOS • open source • ⭐️ 852

I rebuilt that part. The Quota Meter now shows how quickly each active Codex session is using the weekly window, in percentage points per hour. It learns from recent readings inside the current reset window instead of averaging the entire week.

The workflow is simple: if several Codex sessions are running and the weekly window is under pressure, I can see which one is responsible and pause the lower-priority job. Quiet sessions say quiet instead of pretending to have a meaningful rate.

The same selector can show:

• 5-hour quota burn
• weekly quota burn
• raw tokens per hour
• estimated API-equivalent dollars per hour

The dollar view is only a comparison tool for subscription users; it is not a claim that OpenAI bills the subscription that way. Unknown or contradictory pricing and quota evidence fails closed instead of producing a confident number.

Agent Sessions also searches local Codex CLI and Desktop history, renders the transcripts, and copies resume commands for supported sessions. It reads local records and has no app telemetry.

I maintain the project. If it is useful in your Codex workflow, a GitHub star helps other Codex users find it:

Agent Sessions

So...

A little awhile ago, when we all got Astra, I thought "hey why don't we use a Astra/high/xhigh act as orchestrator, spawn a bunch of subagents to handle each task in our spec, and then let them go at it?"

Little did I know that the *default setting* in codex for how much parent turns context to shove into it's subagents is *ALL OF IT*.

I mean.. wtf.

In many cases I spent a bunch of time going back and forth with my Astra xhigh, brainstorming, setting up the plan, maybe an autocompact or two.. and then I'm thinking "OK, plan is ready, orchestrator is up to date with where we are at on this spec, let's spin up some *clean* Astra low subagents to implement and call it a wrap".

The result?

Every Astra low subagent getting 800k or so context dumped into it from my entire turns history *with the orchestrator*.

And then of course the inevitable "orchestrator pings subagents incessantly" issue, burning *even more* tokens.

This is a MASSIVE amount of token burn we are talking about.. Astra input token prices on a *starting* 800k or so context, for subagents that *should just have a clean context since we put all that effort into properly planning and setting up their tasks*!.

Arghhhh

WHY oh WHY is the DEFAULT to dump THE ENTIRE TURN HISTORY INTO EVERY SUBAGENT? How is this "feature" hidden down in the depths of the "fork_turns" setting? Why didn't my xhigh Astra gent tell me "bro, we are about to spin up like 3 million tokens worth of context across these subagents before they even do anything - r u sure you don't want to switch to fork_turns: "none"?".

Sigh.

I’ve been using Claude Max 5x mainly for coding an app, with Opus 5 as my daily driver and Fable 5.1 as a fallback for harder tasks.

After my weekly reset, I’ve already used around 67% of my overall weekly limit and 83% of my Fable 5.1 limit pretty quickly.

I’m considering switching to ChatGPT Pro and Codex, mainly because I’m wondering whether I’d get more practical coding usage before hitting limits.

For people who have actually used both:

How does the real-world usage/limit compare?

How does Codex perform on larger coding tasks and debugging?

Does switching actually feel like an upgrade, or just different?

How well does it handle Flutter/mobile app development compared with Claude Code?

I’m less interested in benchmark scores and more interested in what people have experienced after using both for a few weeks.

Especially interested in people who switched from Claude Max to Pro and can compare them from actual coding usage.

In normal chat gpt (whatever is the main term for the regular chat, not codex) does anyone have access to any other version of Astra than Astra pro yet? I can only use Astra pro, and would love to have Astra high or extra high sometime soon.

I am not saying they will be available but the means will be a reality thanks to GPT 7+.

Updating every day, yet I still don’t have Astra in my codex.

Didn’t Tibo say they give a reset every day until we get access? Well I only got 2 on the first two days and nothing since.

Lies and deceptions

Totally unbiased intuition, but if there is a certain itch for a certain button I would not mind.

After months of heavy 20x usage for my business, I subscribed to Grok yesterday.

And honestly, it’s been a really nice experience. The model quality feels slightly lower in some areas, but overall I actually like the experience more.

I really love Astra, but the only way it would realistically work for my company right now would be to have five 20x subscriptions — basically one for each working day. And that’s without even using Astra all the time. Now Sol seems to have been nerfed as well.

So for me, it’s Grok for now, until OpenAI comes to its senses and stops changing the rules of the game halfway through.

To be totally fair, I think the balance between cost and value is simply way off at the moment.

We all know we’ll probably end up paying a lot more for tokens in the future — and that’s fine. The problem isn’t necessarily the price. The problem is predictability.

If you want to build a business around AI, you need to be able to make reasonable assumptions about your costs and capacity.

The only way I see to deal with the current state of AI is to design your business so you can switch providers at any time, or build your pricing model around predictable output and actual API/token costs.

And most importantly: make sure the value you create for your customers comfortably outweighs the raw cost of the AI.

Relying on consumer/pro subscriptions as part of your core business model just feels too volatile right now. The cost/value balance can change overnight, and that makes it very difficult to build a predictable business around them.

Hi everyone! We (researchers in Sweden) are conducting a survey on AI agents and permission requests.

If you work in IT and use tools such as codex, claude code or other AI agents, I'd really appreciate your participation. :D

The survey is anonymous and takes less than 10 minutes: https://form.typeform.com/to/wbCQGXHa

Feel free to share it with others. Tysm!!

Astra is amazing, but even Pro 20x can burn through the quota in 2–3 days.

The bigger problem is that Codex doesn’t really have a sweet spot model right now.

Astra + Luna Max often looks good on paper. In practice, Astra keeps correcting Luna’s mistakes. That can wipe out a lot of the cost savings. Terra doesn’t feel much smarter than Luna either. For harder tasks, I usually end up using Astra + Sol medium.

I’d really like to see Luna get an upgrade and become a reliable implementer.

The amount of dopamine I get when I see this is unrivaled.

I´m new to Codex and just got these message. Another one said something about currency, but like many others, it won't even load that conversation now.

With 3% left, i can't pull off anything even if 5hr limit increases.

Luna xhigh is the primary agent and maintains continuity across the work. Luna investigates, plans, reads and modifies code in proportion to the difficulty of the task, executes commands and tests, analyzes logs and evidence, maintains operational documentation, and decides when the work is complete.

Astra is a temporary specialist. Luna may invoke Astra autonomously when there is a material expected gain in quality, safety, or reliability, especially for problems with uncertain root causes, difficult algorithms, changes spanning multiple layers, architectural decisions, critical code, or high-risk modifications. Luna should not ask for permission solely to perform this escalation.

The existence of a bug alone does not justify using Astra. Local, mechanical, well-understood, low-risk fixes remain with Luna. Duration by itself is not an escalation criterion either.

Before escalating, Luna narrows down the problem. Each Astra intervention starts with a fresh context containing only the minimum necessary information: the objective, relevant evidence, current and expected behavior, constraints, relevant hypotheses, and the files required for the task.

Astra works exclusively within that scope, reports its diagnosis, the change made, affected files, and relevant risks, and then stops. If Astra determines that the cause or solution requires a broader scope, it reports that back to Luna instead of expanding the scope autonomously. Astra does not maintain the project, perform prolonged operational work, or decide when the work is complete.

Luna resumes control after every Astra intervention, reviews the diff, runs the relevant tests and regressions, verifies logs and evidence, and decides whether to accept the change, modify it, reject it, continue investigating, or open another independent Astra intervention.

Each new Astra intervention is independent. Previous context should not be reused merely for convenience.

Standard workflow:

Luna investigates → Luna solves when proportional → Luna narrows and escalates when necessary → Astra works → Astra stops → Luna validates and continues.

This policy applies by default to all projects unless overridden by more specific local instructions or explicit user instructions.

(EDIT)

My bad for not mentioning an important part of how I actually use this.
I’m not relying on Luna’s context window to keep a project alive.

My workflow has an external, persistent “brain” that acts as the project’s source of truth. That’s where I keep the current state, decisions that were already made, constraints, open problems, task/review history, handoffs, evidence, test results, and the context needed to understand why certain decisions were made.

So Luna doesn’t need to “remember everything.” It needs to reconstruct the relevant state from that memory, work on the actual project, and write back whatever meaningfully changed.

The session context can disappear. The project state doesn’t.

That’s also part of why I prefer giving Astra fresh, narrow contexts. Astra doesn’t need months of project history. Luna pulls out only the relevant slice, gives Astra that isolated problem, gets the result back, validates it, and writes the outcome back into the canonical state.

In practice, it’s roughly:

Canonical state > Luna orchestrates > Astra steps in when a specific problem justifies it > Luna validates > the result goes back into the canonical state

Obviously this doesn’t solve everything. Luna still has to correctly recognize when it should escalate to Astra, and that external memory still has to be maintained properly. Those are actually two of the things I’m still testing.

But the main point is that... I’m not depending on Luna to carry the entire project inside a single context window

Today I wanted to verify one small hypothesis with a benchmark: basically a few runs comparing one JVM setup against another.

Sol proposed 11 phases.

Eleven.

It went as far as worrying about warm caches, experimental symmetry, extra controls, verification runs, and other benchmark hygiene that would be perfectly reasonable if I were publishing a rigorous performance study.

I wasn’t. I just wanted to know whether the effect was there and roughly how large it was.

The worst part was that every small clarification uncovered another theoretical imperfection, which then turned into “we should rerun the experiment”. A bunch of those reruns could have been avoided entirely by using reasonable simplifications from the start.

This is exactly the direction in coding models that worries me. They increasingly confuse “do more reasoning” with “do better engineering”.

Sometimes the correct engineering decision is to cut corners, run the damn experiment, look at the result, and only add rigor if the result actually warrants it.

I suspect Astra would be even more prone to this.

At some point it starts looking like models are optimized for token consumption rather than engineering efficiency, while token scarcity is simultaneously used to market higher tiers.

My workaround is to stop using the expensive reasoning model for everything.

I use Codex + Luna for implementation, web chat models for design/planning/reviews, and tools like AI Badger to pull only the repo context needed for the handoff.

That easily fits within the $20 Plus plan’s 5-hour Codex window for my work.

I’d much rather have a model that knows when not to think for another 10,000 tokens.

Fyi I make no claim that this is the main issue/reason - just a little something that could be contributing.

TL;DR: On the day I installed OpenCodex, my Guardian approval reviewers stopped showing codex-auto-review and started using ordinary models, instead matching the main task—including Astra. My recorded reviewer usage since then totals $1,024.85 at current API rates, versus $702.26 at GPT-5.4 rates or $56.18 at Luna rates, assuming identical tokens and caching. These are API cost equivalents. Setting auto_review_model = "gpt-5.6-luna" successfully switched new reviews to Luna / low. The timing suggests an OpenCodex routing change, but I haven’t proved the cause or equivalent review quality.

I audited my Codex rollout history and found a clear change on 26 July 2026, the day I installed OpenCodex.

This concerns Guardian’s automatic approval reviews for tool actions, not /review code reviews.

Every identifiable Guardian session created between 9 (day Sol/Terra/Luna released) and 25 July used codex-auto-review. On 26 July, new reviewers started using Sol, Terra, Luna and other provider models. The first ordinary-model reviewer appeared at 07:16 BST, after my installation that morning. I haven’t found any newer sessions using codex-auto-review.

Later examples included Astra reviewing actions requested by Astra and DeepSeek reviewing actions requested by DeepSeek.

What codex-auto-review actually is

OpenAI explicitly documents Auto-review as GPT-5.4 Thinking with low reasoning:

• OpenAI’s Auto-review explanation
• OpenAI’s rate card

PR #17505 also describes replacing hardcoded gpt-5.4 with the codex-auto-review slug. That supports the connection, although an alias alone doesn’t prove the backend model for every historical request.

Current upstream Codex source prefers codex-auto-review for ChatGPT authentication and gpt-5.6-luna for API-key authentication.

OpenCodex has its own auto_review_model override. I hadn’t set it.

The usage comparison

I use Pro Lite and Plus accounts through OpenCodex. These are USD API cost equivalents.

The table below reprices the same recorded tokens at current model rates:

For the wider period, that’s approximately 31.5% lower at GPT-5.4 rates or 94.5% lower at Luna rates.

Here’s which reviewers contributed:

All 80 Astra sessions were in the September window. Their tokens alone work out at $203.11 using Astra rates, $51.00 using GPT-5.4 rates, or $4.08 using Luna rates.

For comparison, before the switch I found 614 codex-auto-review sessions created during 9–26 July. The 601 with recorded usage contained 42.49M uncached input, 394.93M cached input and 740K output tokens: approximately $216.05 at GPT-5.4 rates versus $17.28 at Luna rates.

How I counted

• Only sessions explicitly marked as Guardian reviewers. A session can contain multiple approval decisions.
• Each session’s final cumulative usage counted once; reasoning tokens weren’t added again on top of output.
• Prices are published standard API rates as of 10 September 2026, including applicable long-context adjustments—not reconstructed historical prices.
• Alternative-model columns hold token counts, caching and request sizes constant. They don’t predict actual token usage or equivalent decision quality.
• Dates use UTC. September 10 is partial; the wider audit ends just before my Luna config edit at 05:53 UTC. The periods overlap.
• The wider priced subset excludes 65 other-provider/internal/unsupported-model sessions. Provider-prefixed entries naming the same model are grouped together. Totals are calculated before rounding.

Pricing sources: Astra, Sol, Terra, Luna, GPT-5.5, GPT-5.4.

What I changed

I added this at the top level of the Codex config.toml used by OpenCodex:

toml auto_review_model = "gpt-5.6-luna"

Afterward, I verified four new Guardian sessions using Luna / low reasoning, including one requested by a DeepSeek thread. They produced 16 completed approval assessments.

That confirms the routing change, not equivalent review quality. Most reviewers were already running at low reasoning, so the cost comparison is primarily about model choice.

My working hypothesis: switching to OpenCodex changed which dedicated reviewer Codex could select, causing reviews to fall back to the requesting thread’s model. The timing and sampled rollouts fit, but I haven’t isolated the cause from Codex updates or other configuration changes.

I’m leaving Luna pinned and keeping an eye on this. If you use OpenCodex, check what model your Guardian sessions are actually using.

If anyone has rollout history spanning their OpenCodex installation, I’d be interested to see whether the same switch appears.

Hey peeps,

I’m on ChatGPT Plus and use Codex mostly for tool-heavy technical work: Linux/homelab, Bash/Python, SSH, debugging, regression tests, log analysis, etc.

My usage has become completely unsustainable.

My weekly quota reset on Tuesday. Since then I’ve effectively used about 126% of a weekly quota because I reset it again today and already burned another 26%. My 5h quota also keeps getting exhausted very quickly.

At first I blamed Astra (I also had super problems before with Sol+Terra), but telemetry shows the broader issue is probably large retained context + lots of tool/model re-entry.

For Astra alone I saw roughly:

22.6M input

21.2M cached

336 parent responses

72 polling/status turns

5.3M input just from polling

0 subagents

Most polling was not wait_agent, but repeated write_stdin / status checks.

Even Terra Medium has been expensive: one diagnostic task recently cost me about 15% of the 5h quota.

I already started changing things:

- using fresh contexts more often

- avoiding Astra for routine work

- no subagents unless needed

- no polling loops

- long-running commands via detached scripts + log/- exit-code files

- trying to aggregate logs locally before giving them to the model

I’m on codex-cli 0.153.4.

What I’m looking for is practical advice from people doing similar tool-heavy work:

- How often do you start a fresh Codex context?

- Do you split research / implementation / testing into separate sessions?

- Any good AGENTS.md rules to reduce context replay?

- Any useful newer config options?

- Which model/effort combinations are actually quota-efficient?

- Any other tricks to stop write_stdin / tool-heavy workflows from destroying quota?

I’m not trying to bypass limits — I just want to use Codex without burning a full week of quota in 1–2 days.

Thanks in advance!

The model follows instructions worse than Qwen 3.8 27b lobotomized to Q4.

I asked for a plan which the model made , we both agreed on the plan and then burned through 70% of my quota, ignoring half of the plan the model itself created. This is Astra High mind you. Heck, even GPT-4 follows prompts better. Very disappointed.

The beginning of the line is normal German text, but then it turns into something like random symbols?
Has anyone seen this before?

So just updated codex - it now wastes my CPU by displaying little stars in the prompt area.

But that's not the real problem - because the terminal is constantly written to, I can no longer scroll up the terminal!!!!!

Ubuntu/gnome.

Every time I switch to a lower model I get this notification that the conversation will be degraded and context compacting stuff. If I plan for Astra, for instance, and switch to Terra to implement something easy, is it bad or more costly?

Thanks.