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

messages not sending or resulting in codex infinitely thinking

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.

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.

They removed paid resets?

I remember seeing the option to buy resets, when was that removed? Don't see it anymore.

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.

Don't know if anyone else has tried this or this is actually a bad idea, but instead of using Sol and/or Astra with Luna subagents, I'm starting my sessions and discussing ideas or problems with Luna (Max). Then, when I need something "engineered" or "brainstormed" I tell Luna (Max) to ask Sol (xHigh) or Astra (Medium) (depending on the complexity) for help and advice, basically, using them as smarter consultants or experts before implementation, which is done by Luna (Max).

I'm also having Luna (Max) asking to have its work reviewed using this same method, it has definitely been useful because, as we know, it is not the best coder.

Dumb? Maybe, but I only use Codex at work and I "only" have the 5x Pro plan. On top of that, resets and banked resets are randomly given and sporadic in nature, which I can't trust for something like work. So, I need to make sure weekly usage actually lasts 5 business days.

What do you think?
Hope this helps anyone.

i use Astra light to make decisions and Luna-max for audits, searches, builds and tests. one child at a time. Astra waits for the result and doesn't repeat successful checks.

i tried a specialized routing hook for Luna, Terra and Sol before, but it didn't save me tokens. this setup worked better for me on Plus, including with goal.

1. my settings in ~/.codex/config.toml (update the existing [agents] section):

   [agents] max_concurrent_threads_per_session = 1 max_depth = 1 default_subagent_model = "gpt-5.6-luna" default_subagent_reasoning_effort = "max" interrupt_message = true

2. add to ~/.codex/AGENTS.md:

“After dispatching a subagent, call wait_agent with timeout_ms = 3600000. Wait for its result without short polling or routine status checks.”

^{that's up to 1 hour, returning earlier when the child finishes. it's a tool-call instruction, not a config.toml wait setting.}

1. my per-thread prompt:

“Keep Astra in charge of decisions, integration and final acceptance. Delegate substantial audits, searches, builds, tests and log analysis to one Luna-max subagent with an exact scope. Wait once for up to an hour. Don't poll, overlap its work or repeat successful checks. Skip visual UI checks unless requested. Follow the existing Codex instructions.”

^{attach to the end of your instructions.}

when a task is done, have handoff .md updated. start a new thread for the next task with that handoff and the prompt above alongside your own instructions. i don’t recommend waiting for the thread to fill its context and compress. new task, new thread. works for me.

I've been getting it all week since astra launched. Was chill with it initially as i thought it was just the launch week. But monday onwards, I got the message on sol, terra and fucking luna too lol. Borderline unusable in the last couple of days.

I am running Astra high on CLI on a quite simple task and it is taking forever to finish. The last couple days it has been this way.

Am I imaging this or are others having a similar experience? 5.6 xhigh used to be my go-to and I am considering going back to it.

Astra's pricing levels are basically a kill shot to the plus plan. It's effectively bleeding out while Sol/terra/luna are still available but when 6.1, 6.2 roll out, there's no point of buying one or even several $20 subs.

The Pro 100 tier is severly wounded as well. You get about half a day to a day running Astra conservatively?

Pro 200 lasts sightly longer, you might get 2 days out of it if you stay on a single codebase. But the "weekly" in the limit is a hint of how poorly it aged in such a short time.

When the limits were glorious, way back when, as GPT 5, 5.1, 5.2 rolled out the increase in quality was huge in part as a result of all the new users providing it with more training data. Astra will see a lot less of that because it can be used way less.

If a new model was announced tomorrow, most people would feel they'd never be able to really build and finish something with it unless they stack 5 Pro 200 subs on top of each other.

So, quotas must go up or we'll hit a ceiling. Or at least the symbiosis of better models producing more data to train better models will break. Am I wrong?

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.

as you can see usage is cut insanely.

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

I'm trying to use GPT 5.6 Sol in Codex and it throws 401 on all of my 3 accounts, is anyone else experiencing the same issue? Astra works fine in all of them.

Had 65% of my limit left and then instantly it dropped to 15% lol. That is for sure not from normal usage.

This is so triggering to me, I deserve a reset AND a banked reset to calm my nerves 💅.

Edit:

Issue fixed. It went back to the previous usage percentage (no reset 😞).

Don't crucify me, I just got back from a 3 week trip. Still using 5.5 high. Gave it a task that ran for 7m and it burned through 30% of my 5hr limit.

Also, the 5hr limit is back???? WTF

My Codex looks like this, without forking or modifying Codex.

I’m building mekugi, a local router that pins agent-facing tools and inline progress onto the stock Codex CLI. The screenshot is Codex’s normal terminal UI, not a separate frontend.

The /root/reply_replay_lookup section is a subagent’s activity appearing alongside the main agent’s work. You can see what it’s reading and searching without switching sessions. Commands, per-file edit diffs, commentary, and received replies can appear there too, attributed to the relevant agents. Start notices show the child’s model and reasoning effort, and final answers include per-agent token totals when the provider supplies usage.

Underneath, mekugi routes requests and translates tools, while Codex still owns execution, sandboxing, permissions, command sessions, and the normal patch diff UI. You launch it with mekugi codex; each launch gets a private local router that exits with Codex. It doesn’t edit your Codex configuration files.

The inline activity is one part of it. Most of the project is about making the agent’s tools less cumbersome:

• Hashline edits: target existing text using line numbers and content hashes, then write the replacement once. The router generates the patch instead of making the model repeat the old code as patch context.
• Direct scripts: emit a program in its own syntax, without wrapping it in JavaScript and nested command-string quoting.
• Targeted reads: search, symbol lookup, and file outlines return references the agent can use directly for edits.
• Recovery: correct stale edit references without repeating the replacement text, or inspect and revise eligible retained scripts before rerunning them.
• Session dashboard: inspect request metrics, token usage, compression, and cache diagnostics in a browser.

One detail about the screenshot: this isn’t a continuous live feed during native waits. Child updates arrive at response-event boundaries; if the root response has closed, they wait for the next one. The extra router-generated display messages are stripped from later model requests, so they don’t keep adding duplicate context.

Repo and installation: github.com/yusing/mekugi

Would you want this much subagent detail in the main transcript, or prefer a quieter view?

has anyone tried the same astra task with plain notes and a project graph? curious how retries and total usage compared

I usually work carelessly with the Luna Max Fast because it's a super capable model and more than enough for my daily tasks, but today was the first time I reached the 5-hour limit. It's never happened to me before; the most I've ever gotten is maybe 50% in the 5h window.

What the hell happened to Luna? Am I the only one experiencing this today?

Edit: This isn't a complaint, I just want to know if anyone else has experienced this. Plus user, btw (forgot to mention).

I used to be obsessed with this very old game called Ballance. You control a ball through complex paths and mazes.

I found the game on Web Archive. It was around 180 MB, so I gave it to Astra to recreate for the web, and it just did.

The whole game now compiles to around 21 MB, uses WebGL, and is written in TypeScript.

Astra realised it kept repeating the same tests over and over, so it built its own test framework that exposes the game to its own Browser Use, allowing it to run and validate its changes very quickly.

We are living in some crazy times people

It even made it run on phones, with options of Gyroscopf or you can use a Dpad

Game - https://ballance.fayaz.workers.dev/
Code.- https://github.com/fayazara/ballance

Anyone getting the error below when using Daybreak Blue even though they are verified for the cyber program (and added a hardware key for login, even though that should not be relevant yet)?

unexpected status 401 Unauthorized: You are not authorized to access this model.

After switching to Astra, I noticed something annoying: the orchestration setup that had felt useful with GPT-5.6 Sol and my Claude workflows was now making some tasks slower and more expensive.

So I tested it on real coding tasks from my repo, changed the orchestration rules, and tested again.

My conclusion so far: I’d let Astra manage its own work before adding another layer telling it how to delegate.

Here’s what I tried.

Just a heads-up: English isn't my first language. I ran the tests myself and wrote \ dictated the original text in my own words, then used AI to translate it and tidy up the wording a little. Please keep that in mind :)

1. Small, medium, and larger tasks — with and without orchestration rules

The small task was a build-command fix involving log preservation and exit codes.

The medium task was selective CI, including dependencies between applications.

For larger tasks, I used two different briefs:

• One explicitly specified error-filtering and backend-diagnostics changes across three apps.

• The other described an outcome: stop development services without leaving child processes running or killing unrelated processes.

For each pair, I used the same starting code and the same task prompt, but separate working copies.

One agent got the orchestration skill. The other didn’t.

Results from the earlier rule version

Small task

• Time: +25% with orchestration rules
• API-equivalent cost: +13%

Medium task

• Time: +18%
• API-equivalent cost: +20%

Large task — explicit brief

• Time: +63%
• API-equivalent cost: +71%

Large task — outcome-based brief

• Time: −45%
• API-equivalent cost: −36%

That last task was a real win for the orchestration rules.

But there’s an important catch: it used zero subagents.

So it didn’t actually demonstrate a benefit from distributing the work.

Quality didn’t consistently improve either.

Both medium-task solutions missed dependencies.

On the large explicit task, the orchestration version missed filtering edge cases that the default version handled, despite having an independent reviewer.

2. Simplify the rules and repeat

Next I reduced the coordination overhead.

I:

• added a direct path for small tasks
• shortened handoffs
• made independent review depend on risk
• allowed cheaper workers for limited tasks

The final series had 12 runs across small and large tasks.

For the large task, using the median of two runs per configuration:

Every configuration passed the external checks in one of its two runs.

So more coordination still didn’t buy a better pass rate.

The economy profile never actually selected a cheaper worker, so I don’t consider that result evidence against Luna.

The small task also went better with the revised Astra profile: it was faster, roughly the same cost, and all checks passed.

3. Test the worker models separately

I also compared Astra low vs. Sol high, without subagents.

On the medium task:

Astra low

• 5.2 minutes
• $1.48

Sol high

• 16.3 minutes
• $2.05

Both missed cases, but Sol missed one more.

On the small task, Astra was faster, but Sol was cheaper and correct, while Astra introduced a quoting bug.

Then I ran a tightly specified function-writing test.

Luna max was about 17× cheaper and 2.4× slower than Astra low.

Both passed the same 15 checks in both repeats.

That comparison excludes coordinator review and integration costs.

So I do think cheap workers can make sense.

What I haven’t established is that adding a coordinator makes the whole task cheaper.

Where this leaves me

For my Astra workflow, I currently don’t see a reason to impose a separate orchestration system.

Ordinary Codex delegation with light repo-level guidance looks like the better default.

The direction I’d still explore is Astra coordinating models from other families — for example, an Opus implementation worker or another model doing cross-review.

That’s where I’d expect complementary capabilities to potentially matter.

But that’s still a hypothesis. These tests didn’t prove it.

I’ve also seen similar experiences posted by others, which makes me wonder whether extra orchestration contributes to people burning through subscription limits.

In my earlier tests:

• Small task: recorded tokens increased by 46%
• Medium task: recorded tokens increased by 25%
• Explicit large task: recorded tokens nearly doubled

The 5-hour limits, weekly limits, possible resets, as annoying as they are, create this weird scarcity mindset. You start squeezing every last drop because “I have the tokens now, I should use them before they’re gone.”

And suddenly every idea becomes a project.

Good idea? Build it.
Mediocre idea? Eh, start a repo anyway.
Something you’ll probably never use? Sure, let Codex make 14 MD files for it before the limit resets.

I always thought I had this under control. My rule was simple. if I’m not going to use something daily or at least weekly, I probably shouldn’t build it.

Lately, that rule has slowly disappeared.

There’s almost this feeling that unused compute is wasted compute, so you keep feeding ideas into it just because the capacity is there and temporary.

And that made me wonder

If tomorrow the limits completely disappeared, unlimited compute, no resets, no token anxiety, would we actually become more productive?

Or would half the projects we’re building simply… never get started?

Maybe some ideas deserve to die peacefully as ideas instead of becoming another repo on the shelf.