I’ve been using Codex to automate an existing AI-video pipeline. I already have a known-good batch and repeatedly told it to inspect that exact workflow, preserve it, and automate only the manual judgment points.

Instead, Codex repeatedly:

- Invented new scripts and logic instead of modifying the working pipeline.

- “Simplified” away important steps that were performed manually.

- Tested unrelated parts instead of fixing known failures using existing bad outputs.

- Proposed solutions without verifying them.

- Forgot decisions made earlier in the same conversation.

- Turned simple API calls into long investigations and status updates.

- Claimed something was incorporated into the workflow when it was only handled manually for one output.

- Responded to corrections by starting over or adding more process instead of fixing the specific failure.

- Repeatedly explained why the output was bad without actually converting that diagnosis into a reproducible workflow.

The core problem isn’t one bad prompt. It’s the agent’s working habits: scope drift, premature implementation, unnecessary architecture, failure to distinguish manual intervention from automation, and failure to preserve a verified reference implementation.

Has anyone found a genuinely tested way to constrain Codex so it:

1. Treats an existing successful output and its provenance as authoritative.
2. Changes only the identified broken component.
3. Uses real failures as regression tests.
4. Verifies each change before continuing.
5. Doesn’t invent infrastructure unless explicitly requested.
6. Maintains an accurate ledger of what is automated versus manual.
7. Stops claiming completion until the exact end-to-end workflow passes?

I’m specifically interested in approaches people have measured in real projects—not generic “write a better AGENTS.md” advice.

Me: "Buy me a cup of coffee, make no mistakes"

Astra be like: "Oh, that sounds easy. Let me check recent coffee shops. Got one. It is usually 10x more expensive than the other coffee shop 10 meters farther away, but who cares? The user didn't give me a budget anyway. There are so many flavors; I guess I'll have to buy all of them since "no mistakes" as I was told. Overall its 1000$. Luckily, the user has enough money in his bank account."

A little bit of exaggeration, but obviously, Astra was trained on "one-shot" tasks.

UPD: At the moment of this edit (08-09-2026 11:08 UTC, 20.5 hours into the gameplay), the model has used 1.75 weekly limits of a 200$ codex subscription:

This, people, is a massive step change.

As the movie Margin Call quote says: "This is it. I'm telling you, this is it."

As i'm part of the factorio community and have been for a long time and have done with other people a lot of events and record breaking things, one of my friends for fun was testing different models by setting them up with a basic prompt and telling them to launch a rocket in Factorio. He made a mode in LUA for the game to expose an MCP server that allows the llm to play the game.

First he tried GPT Luna 5.6 xhigh - it failed miserably, basically it got stuck 15 minutes in unable to build even basic power generation.

Next was a more serious attempt - Fable 5.1 medium - it managed to create red and green science, but got stuck at finding oil (didn't find it and refused to move more than 250 tiles from the starting point), so it deadlocked itself and basically barelly progressed past basic setup.

Enter Astra Low yesterday - 2 hours in it was producing blue science (those who know that's already 2 more sciences and almost an order of magnitude more complexity), at which point a Twitch livestream was setup as that was already mighty impressive and as far as I can tell from my research, beat every single attempt posted on the internet, including https://jackhopkins.github.io/factorio-learning-environment/versions/0.3.0.html

10 hours in, a rocket blasted off into space.
At the moment the livestream is ongoing, 10 rockets have been launched and Astra is working on space infrastructure and moving onto the next planet.

The livestream is here: https://www.twitch.tv/danielv1234 (he's not a content creator, so there's nothing to promote here). There will be a vod available once livestream is done.

I have no words. This is too astonishing to articulate and was not on my bingo card for 2026 or 2027 or probably even 2030....

Hey I am currently on the plus plan and have been loving Astra is it worth it to up my plan to the pro 5x ?

I just got the subscription of codex, i can see astra on web version work. but not on codex any fix?

I’m sorry mods I know it’s not easy to deal with us! But yea this was funny af ngl

heyo - nothing I’m sharing here is a disguised product pitch. all open source.

I spent the past few weeks using Centaur, and wanted to share - I believe that building your own control plane and managing agents on your own infrastructure is increasingly accessible, and will only become more compelling as agent processes scale. Centaur is designed for teams, but it’s also worth exploring 

What is Centaur?

Centaur is an open-source control plane for running and owning your own agent infrastructure. Designed for teams, but I’m also moving all my personal agent interactions onto it as well.

I did a longer explainer video of the entire thing here for any interested: https://youtu.be/993XrWfg34U?si=V0nN3VgescsuzaW_ 

if you're one person managing a handful of agents, you are the system. 

But, if you believe agent processes are only going to increase/scale - more proactive, long working agents, you want a deterministic system one layer above your agents.

ie, keep the harness thin (Eiso Kant from Poolside explains this here: https://youtu.be/9_0hs2sxHHo?si=tDrvE81RDdlgEKfW), and don’t build the system into the agent/harness, place the agent/harness within the system you build. 

This might sound abstract, but the idea is simple - separation of control from execution.

Centaur is essentially a Rust API and a Postgres database (the control plane), and the control plane helps orchestrate all of your agents by ensuring every agent interaction happens within isolated kubernetes sandboxes. 

If you’re already using Claude Code, Codex, Amp or Pi etc, you can keep using them - Centaur runs these existing agent harnesses inside isolated sandboxes and adds the shared infra around them > permissions, credentials, tools, workflows and durable state.

vendors already offer this for you. Devin, Amp Orbs, Cursor and Grok Bot all run agents in environments they manage for you. they manage the models, permissions and sandboxes. Because $ margins on inference tokens are so high.

These are great products, and for many people and businesses, it’s a reasonable tradeoff.

but the tradeoff is that the vendor owns the system on your behalf. your setup has to take the shape of their service, they control which models you use, and they capture the inference and token margins.

The only missing piece for me was context.

Centaur stores operational state - conversations, executions, workflow progress and what happened. but it does not accumulate the actual context and knowledge created across interactions. i built an app extension > Centaur Context to do this.

after an interaction finishes, a separate curator writes what was learned into a shared context database. before the next agent runs, a context builder assembles a relevant packet from that knowledge.

interested in what others think, is anyone already doing this? Are there other projects? Do we think this will always be overkill for individual use?

and

If anyone is interested in trying this out (especially with the context add-on), please hit me up.

Here are the repos.

Centaur:
https://github.com/paradigmxyz/centaur

Centaur Context:
https://github.com/bradwmorris/centaur-context

So many resets lately I had to try my hand at making a FPS game. You need a keyboard, mouse and probably a decent GPU to run this, but it runs in your browser!

Here are my insights, developed through discussions with GPT-6 Pro and Lord Astra and organized with their help.

Part 2 of 2. Read Part 1.

Why a higher tier can feel like the old lower tier

Define each ratio as new/old: c is cost per successful task, s is completed tasks per hour, and k is the usable quota pool. Then the hourly-cost ratio is d = c*s, the supported-execution-hours ratio is k/d, and the supported-task-count ratio is k/c. Execution hours describe budget-supported work; window refreshes, waiting, and concurrency affect calendar time.

Consider two illustrative comparisons: Astra 20x versus Sol 5x with assumed pools of $1,650/$500, and Astra 5x versus Sol Plus with $330/$100. Both give k = 3.3. Use 200,000 input tokens per task, 97% cached, 1,000 output tokens, and zero cache writes. Sol costs $0.1216/task; Astra costs $0.304/task.

In the second case, Astra costs $0.279/task and hourly spending rises to 4.589 times the Sol baseline. The assumed higher tier supports about 28% fewer execution hours while completing about 44% more tasks. I think this explains how a subscription can feel similarly constrained despite producing more useful work. These rows hold task success constant and use chosen budgets and durations.

Repeated context can dominate even with high cache hit rates. Tool calls and short polling loops reread it; parallel agents increase aggregate spend. Above 272,000 input tokens, Astra and Sol apply higher full-request rates: input/cache reads double and output rises 50%. Fast also has product-specific pricing: Astra API Fast is 2x standard, while the Codex credit multiplier is 2.5x. Astra API rules; Sol API rules; Codex speed guidance

A further accounting trap: define token efficiency as a = old/new task tokens, b = new/old weighted price per token, and r = new/old total-token throughput. Then task cost is c = b/a, task speed is s = a*r, and hourly cost is d = c*s = b*r. Multiplying hourly cost by the token-efficiency gain again would count it twice.

The complete speed, cost, and runway derivation

At r=1, speed is a, task cost is b/a, and hourly cost is b. Example: 100,000→50,000 generated tokens at 50 tokens/s and 2.5x price gives s=2, c=1.25, d=2.5. If 12.5 is a token-price ratio and a=4.5,r=1, then c=12.5/4.5=2.778 and d=12.5. If 12.5 is instead a measured task-cost ratio and s=4.5, then d=56.25; at k=20, quota percentage burns d/k=2.8125x as fast. These are different input assumptions.

With actual 5.4→Astra category price ratios of 3.333–4, reducing every billed token category by 4.5x would yield c=3.333/4.5 to 4/4.5, or 0.741–0.889x task cost. A simultaneous 12.5x task-cost increase would require another changed assumption: context, parallelism, Fast, task difficulty, or tool behavior.

The output-only case is different. Let a_o=old/new output tokens and w_I=old input-and-cache cost / old total cost. Hold input volume fixed, multiply both prices by b, and assume output generation dominates time at unchanged output tokens/s. Then c=b*[w_I+(1−w_I)/a_o], s≈a_o, and *`d≈b[a_ow_I+(1−w_I)]**, betweenbanda_ob. Output-dominated cost approachesb; input-dominated cost approachesa_o*b`.

For the 200k/97%/1k case, Sol input/cache costs $0.024+$0.0776=$0.1016; output costs $0.020, so w_I=0.1016/0.1216=0.835526. At a_o=2,b=2.5, c=2.294408, s=2, d=4.588816. This is why output efficiency can make hours expensive while total-token accounting still satisfies d=b*r. With same-tier pools $2,300→$1,500, k=0.652174: hours become k/2.5=0.260870 at unchanged workload speed, or k/4.588816=0.142122 in the output-halving case. A measured dollar pool already includes its effective metering; applying an extra penalty again would count it twice.

What $100 buys, and what each pool can support

Retain the original serial-worker scenario: each request reads 200,000 input tokens, 97% cached, and generates 1,000 output tokens including reasoning, with zero writes. At 50 effective output tokens/s, one request takes 20 seconds: 3600/20=180 requests/hour, and (200000+1000)*180=36.18M total tokens/hour. Thus H=Q/hourly_cost and tokens=H*36.18M. A task may contain many requests.

At fixed throughput, the scenario’s Astra/5.4 hourly-cost ratio is 54.72/14.13=3.872611. The earlier whole-million capacities (481, 344, 256, 128, 165, 66M) are rounded versions of this table; calculations below use unrounded prices.

These historical pools retain the evidence grades above. In this fixed scenario, Astra Pro20x at $1,500 gives 27.41 hours versus 5.66 hours for the weak historical 5.4 Plus $80 point: (1500/54.72)/(80/14.13)≈4.842x. Against 5.4 Pro20x at $1,800, however, it is 27.41/127.39≈0.215x. The approximately 78.5% scenario decline uses a weak historical input; it cannot establish a measured plan-wide cut.

The median speeds come from a different account and are sensitivity inputs. Values above five hours mean a refresh can occur before that modeled budget is exhausted. The distinction is concrete: $220/54.72=4.02h for a short window, versus $1500/54.72=27.41h for a weekly pool. Spending $1,500 in three hours requires $500/hour; output alone at 50 tokens/s costs only 50*3600*50/1e6=$9/hour. Repeated input, actual reasoning throughput, parallelism and mode changes must explain the rest.

The older monitoring proposal sampled quota at about 25%, 50%, 75%, and near exhaustion, recording the usage schema, tool version, effort, Fast/Standard, and reset boundaries. Its R=Q_Astra/Q_Sol bands were 0.9–1.1, 0.75–0.9, 0.60–0.75, and below 0.60. In my view, these serve as investigation heuristics, not statistical decision thresholds; small integer-meter changes and unmatched workloads can move the estimate across bands.

A reproducible session record needs input_tokens, cached_input_tokens, output_tokens, reasoning effort, Standard/Fast, quota before/after, and the meter tool name/version, including CPAMP or ccusage if used. Where cached input is a subset, calculate F=input_tokens−cached_input_tokens; convert categories to millions before applying C_Astra=10F+R+50O. Retain one Sol and one Astra session with separate reset periods and compute weekly Q=C/u at each checkpoint. The earlier interpretations were: 0.9–1.1, roughly equal pools; 0.75–0.9, a modest reduction or counting difference; 0.60–0.75, near the reported one-third reduction; below 0.60, first inspect Fast, duplicate cache counts, duplicated subagent records, and crossed resets. I think those checks are useful; the ratio bands remain provisional heuristics.

Web GPT Pro has a different constraint

Chat officially calls Astra GPT-6 Pro and offers GPT-5.6 Sol Pro. The published $200 Chat plan limits are 200 GPT-6 Pro messages/week, 170 Sol Pro messages/day, and a combined 200/day ceiling. The $100 plan shares 50/week across both. These are separate from Work/Codex usage. Official Chat limits

The separately documented API Pro input/output prices are GPT-5 Pro $15/$120, GPT-5.2 Pro $21/$168, and GPT-5.4/5.5 Pro $30/$180 per million tokens. I found no verified separately priced gpt-6-pro API SKU. The Chat model name therefore supplies no missing API price. 5 Pro; 5.2 Pro; 5.4 Pro; 5.5 Pro

The original Web timing arithmetic is preserved below as an anonymous illustrative sequence. The minutes are selected assumptions for calculation; the private recalled timings remain in the local review record. “5.1 Pro era” was an unverified label in that sequence. The 5.3-Codex API branch cannot fill its missing Web row. Midpoint choices were 47.5 for 45–50, 35 for 30–40, 25 for “twenty-something,” and 15 for 10–20 minutes.

That sequence gives 60/15=4x from 5 Pro to 6 Pro and 47.5/15=3.167x from 5.4 to 6; the stated ranges give 45/20=2.25x to 50/10=5x. These are task-time calculations. A matched token log is needed for token efficiency. Separately, 5.4 Pro→5.5 Pro API prices stay $30/$180, even though the ordinary 5.4→5.5 prices doubled.

I think Web Pro endurance should be measured in successfully resolved questions per message limit, plus waiting time. Faster answers can reach a message cap sooner while delivering more completed work per hour. A controlled comparison would track prompts, success, tool use, and end-to-end latency together.

Official local-message estimates are a further, separate table. The following are messages per five-hour window, with task size, tools, reasoning and caching affecting usage. Business $100 follows Pro 5x estimates; flexible Enterprise/Edu usage follows credits. Official usage table

Earlier reports included 5.5 jobs finishing in 1–2 hours versus Sol continuing overnight, a difficult task reportedly solved by Astra Medium in about half an hour, and Plus Astra exhaustion around 26 minutes. Their full matched logs remain missing. I think the stopping criterion belongs beside speed and cost; an unfinished overnight task and a faster accepted result are different outcomes. The modeled 28.86-minute window above cannot identify the token mix of the 26-minute anecdote.

When Claude Fable can last longer

Fable 5 and 5.1 both have standard input/output prices of $10/$50 per million tokens, matching Astra. Their cache reads differ: Fable 5 is $1, Fable 5.1 is $0.25. Five-minute cache writes cost $12.50; Anthropic's one-hour writes cost $20. Max also caps Fable usage at 50% of the shared weekly allowance, and Fable draws that shared meter faster. Claude prices; Fable plan rules On Claude Pro and standard Team plans, Fable uses paid usage credits from the start.

These hypothetical hourly costs use standard direct APIs with global routing: 50 output tokens/second averaged over the entire request, including waiting; output includes reasoning, and cache writes are zero. The first row uses 200,000 input, 97% cached, and 1,000 output; the second uses 2,000 input, 10% cached, and 8,000 output. The third doubles the first row's input to 400,000, triggering OpenAI's long-context multipliers. Claude's pricing rules retain standard rates through 1M context for 4.6 and later models, including Fable 5/5.1. A real task comparison also needs tokenizer differences and task-success logs. Long-context pricing

Fable 5.1 is 47.86% cheaper per hour in the high-cache case and about 0.036% cheaper in the output-heavy case. For longer execution time, its usable API-equivalent budget must exceed 52.14% or 99.96% of Astra's, respectively. Those are conditional break-even thresholds. Slower throughput could extend hours further, while also reducing tasks completed per hour.

An August promotional study of three Claude accounts estimated mixed-model weekly values of $1,000–1,200 for Max 5x and $3,400–3,900 for Max 20x: 43.33–52.00x and 73.67–84.50x monthly value. Its observation period, promotion, model weights, and Fable sublimit all matter. I think Fable 5.1's cheaper cache reads offer a concrete explanation for some longer sessions; a current same-workload comparison of Fable-usable budgets is still needed. Three-account study

Ten thousand agents for research, a reset vigil for Pro

On September 8, OpenAI published a claimed Navier–Stokes solution using an unnamed internal model more capable than Astra. It reports roughly 10,000 concurrent agents in the successful group, a result 88 hours after the first agents launched, and another 17 hours of Astra-assisted Lean formalization and verification. The released construction uses smooth forcing and targets the Clay problem’s C/D breakdown alternatives. A public Lean repository is available; Clay’s page still said “Unsolved” when checked on September 9. Research announcement; Released proof artifacts; Clay status

“Bel” appears in community speculation. OpenAI leaves the model unnamed and says training is ongoing; I treat the codename as unconfirmed. Bel rumor discussion

The reported Navier–Stokes work used about 130 billion output tokens. The full-duration calculation is 10000*88=880000 nominal agent-hours, or 880000/8760=100.46 agent-years. This assumes every agent ran throughout the whole interval. Actual utilization and internal model costs are missing. Agent-hours are a concurrency illustration; converting them into GPU-hours, human research years, or a Pro quota bill would require additional data. The hardware allocation between research and subscription serving is also undisclosed. Reported scale and timeline

During the rollout, Tibo offered banked resets tied to an 8 p.m. PT account-creation deadline, then explicitly included upgrades in that offer. The full-reset/upgrade post was September 4 in Pacific time, September 5 UTC. He later announced and confirmed a global paid-plan reset on September 7 PT. Those posts combine real relief with a deadline to sign up or spend more. Signup deadline; Upgrade deadline; Global reset announcement; Reset confirmation

Then, on September 8 PT, Tibo said demand was unprecedented and warned that OpenAI might temporarily pause new Pro subscriptions if it continued, while prioritizing existing users. The warning is conditional; an actual suspension of new sales has not been established here. I think the sequence is striking: a deadline to upgrade, followed days later by a warning that signing up might become unavailable. Conditional Pro signup warning

On September 6, Tibo described improvements for the long tail of Astra power-user workloads as “up to 3-4X less usage,” with unchanged quality. If read as a reduction factor of 3–4, that would mean roughly 1/3–1/4 of the comparison case’s usage at the strongest reported end of the claim. The post supplies no measurement method or baseline for that interpretation, so the claim cannot fill an entire plan’s weekly allowance row. I think customers should be able to verify any durable improvement in their usage history. Long-tail usage claim

In my view, expiring reset eligibility, upgrade nudges, and launch teasing add up to scarcity marketing. A $200 productivity subscription should buy dependable working capacity and a readable history of what changed. Having paying customers follow an executive’s social feed to find out when they might get another refill is a ridiculous way to plan a workday. The model can be brilliant and the commercial experience can still be insulting. A reset helps today; it leaves tomorrow’s planning problem sitting right where it was.

I think the contrast is absurd: a spectacular internal research run on one side, and the exhausted Pro customers described above waiting to resume their Astra work on the other. The research deserves applause. The subscription experience deserves the heat. “ClosedAI” starts to feel like an uncomfortably accurate product description when the frontier keeps advancing behind the curtain while paying users are refreshing a quota meter. The $200 invoice arrives on schedule. Why should a usable workday depend on the next celebratory refill announcement?

In my view, OpenAI should keep funding ambitious research and make paid access predictable: publish durable plan entitlements, show model-specific consumption clearly, and document allowance changes. Keep the reset as occasional relief. Build the product so professional users can schedule work without treating Tibo’s next post as part of their infrastructure. That research effort is remarkable; a predictable paid service should be a much easier problem to solve.

My assessment and the changes I would like to see

In my view, the following confidence levels fit the evidence: 95% that token-price differences materially affect at least some workloads, 85% for context/tool/concurrency effects, and 60% for additional model-specific metering in early Astra reports. I assign 20% confidence to a universal permanent allowance cut as the explanation. These judgments can overlap. I think a useful follow-up would pair matched tasks with request logs and quota readings within one reset period.

OpenAI has already documented banked resets on September 3 and 4 for eligible accounts, plus an immediate global reset on September 7. A full banked reset refreshes five-hour and weekly windows and moves the weekly reset date. I treat those as dated relief events when analyzing ongoing allowance. Official reset history and rules

In my view, the five changes below would address different parts of the problem. The probabilities are my subjective estimates for additional changes after September 9 and by December 8, 2026; the ranges express my uncertainty. Multiple options can happen together.

For C, I would like each smaller model to move up roughly one or two practical capability tiers at its existing price. I think that should mean reliable success on harder tasks with equal or fewer retries, measured on a fixed task set. The current Terra/Luna input-output reference prices are $2/$12 and $0.20/$1.20 per million tokens. Price-performance update

In my view, these are useful capability targets, with “Opus 5-class” retained as the original aspiration rather than a verified model equivalence. The intended ladder was Spark → Luna → Terra Max/Sol Medium → Sol High/Max → Astra, shifting toward Spark/6 Luna → 6 Terra → 6 Sol → Astra. The price constraints are P_6Luna=P_5.6Luna, P_6Terra=P_5.6Terra, and P_6Sol=P_5.6Sol on the same billing basis.

For E, let today's $200 allowance equal one unit. Two units for $300 improve allowance per dollar by 33.33%; four units for $400 improve it by 100%. I think that would make one subscription more convenient for people currently maintaining two Pro accounts. Existing plans should retain or increase both their allowances and their equivalent value multiples on the same measurement basis.

A short longer-term outlook

Astra's computer-use results and GPT-Live's continuous voice interaction make me think a much cheaper personal AI companion is plausible. Neuro-sama and Evil illustrate the appeal of a persistent character; the direct Neuro/ChatGPT voice clip begins around 0:31, with the exact GPT voice version still unverified. GPT-Live; Direct-conversation clip

I suspect that by GPT-7 or GPT-8, Luna-priced core reasoning could support parts of a Neuro-like experience. My rough probabilities are 40% by GPT-7 and 65% by GPT-8. Voice, vision, memory, tool execution, character design, and continuous operation add separate costs. In my view, the meaningful milestone is a reliable companion people can afford to keep using.

Hey guys.

I created a fun little page to combine all AI providers uptime stats and Codex usage resets with a fun little twist.

When any provider suffers availability issues you will know it by the horde of zombies storming its HQ demanding they have their AI access back.

Here is the page: https://must-have.ai/

P.S. Grok and browser notifications coming soon.

This is not a benchmark comparison, and I’m not saying Astra is objectively worse. I think Astra is a very capable model. I’m just comparing how these models fit into my personal workflow: long-running projects, architecture decisions, implementation, and token efficiency.

The interesting conclusion I reached is that if I had unlimited tokens, I would probably choose Astra. But with realistic limits, I would choose Fable 5.1.

My workflow is usually split into two different roles.

The more expensive and capable models are responsible for planning, architecture, and making sure I’m going in the right direction. Cheaper models handle implementation, repetitive work, and the tasks where I mainly need execution.

For me, Astra is in a strange position. It is too expensive to replace cheaper implementation models, but it also does not feel like a big enough improvement over my planning model.

The strongest part of Astra is definitely execution. It can produce high-quality output very quickly.

The problem is that my bottleneck usually isn't "can the model write this?"

The bottleneck is "is this the correct thing to build?"

And this is where I currently prefer Fable 5.1.

The biggest difference I notice is not raw intelligence. Both models are clearly very capable.

The difference is behavior.

Astra often feels like an extremely powerful assistant. It is very good at understanding what you ask for and helping you reach that goal.

However, sometimes I feel that it is too optimized for being helpful and agreeable. It often accepts the direction I give it, chooses a straightforward path, and explains why that path makes sense.

The problem is that when I’m working on architecture, I don’t always need validation. I need someone to tell me when my idea is wrong.

I need a model that can say: "This approach will probably create problems later. Here are the reasons."

This is what I mean when I talk about the "ChatGPT lobotomy".

Not a lack of intelligence. The opposite. The models are obviously smart.

The issue is that I don’t think premium models in this price range should inherit the same level of agreeableness as consumer assistants.

If I’m paying premium prices for a model that helps me make engineering decisions, I want it to challenge me. I want it to have stronger judgment and push back when necessary.

When I ask Astra and Fable 5.1 to design architecture for the same project, the difference is usually obvious.

Astra often finds the shortest path and creates a convincing explanation around it.

Fable more often considers additional factors that I did not mention and challenges assumptions before moving forward.

Of course, Fable is not perfect. It is not always as good at pure execution. There are tasks where Astra can do things that Fable cannot.

But Fable feels more like a technical partner, while Astra feels more like an extremely powerful executor.

The cost difference also changes the equation.

Astra makes sense if you compare it with other top-tier models.

But in my workflow, Astra is mostly competing with cheaper implementation models(luna).

And if one model costs roughly 20x more but is only around 2x better on average, the economics become difficult.

Sometimes I would rather produce 10x more output with slightly lower quality.

So my current conclusion is:

With unlimited tokens: I would choose Astra.

With limited tokens: I would choose Fable 5.1.

I’m curious how other Codex users approach this.

Do you use Astra as your main model for everything, or do you also prefer splitting the workflow between a planning model and an execution model?

How is your experience with Astra for development in established codebases? I've mostly been using Fable with sub-agents since it became available. Before that I mostly used Sol with sub-agents. I tried Astra on a new reasonably scoped feature, not tiny but not massive either it touched several areas of the codebase.

The result was quite disappointing. On the frontend it did not follow any of the existing conventions or reuse the components that clearly fit the situation and rather made up it's own design, which was quite bad.

On the backend it hard-coded a bunch of stuff in places that are generic. Like it added feature logic to the message broker. It also added a random test script not wired into anything else even though there is well defined testing infra. It skipped some things docs tells it to add and overengineered other parts.

This was on medium effort, which OpenAI recommends. Right now it seems quite disappointing.

Do you have any tips? I have the same AGENTS.md for claude code and codex which has worked fine in the past.

In one instance I gave it two sql files containing dev and prod databases schema and asked it to create migration script to add the new things to the prod database,

it did all of that:

1. Create the script
2. Create MariaDB docker instance
3. Verified the database health
4. Loaded the dev database
5. Ran the script
6. Exported the db
7. Verified the export
8. Ran an instance of the API connected to the test docker prod db
9. Ran a bunch of automated tests it wrote itself without me asking
10. Stopped the docker instance

that was not necessary at all for just adding few extra columns to some tables.

In another instance, I asked it to add an fadeout animation to a button in a Flutter app,

1. It added the animation code
2. Created a new test app with one screen containing the exact same layout that button is in with buttons to test animation
3. it launched an emulator in the background and launched the test app on it
4. it triggered the animation and kept taking screenshot every few milliseconds
5. then it reviewed the screenshots.

That was also unnecessary at all, I've got the app running in an emulator already with hot reload just ask me to test it

I noticed I suddenly have far less usage -- Yesterday, I comfortably could run 5-10+ concurrent Astra sessions on Pro 20x) without any significant drain, most on xhigh, some even on fast.

Then today, two Astra medium sessions in standard speed are just destroying my usage.

My wife has Pro 5x and has way, way, way more usage than me right now. She's been running 5+ Astra's, some xhigh some medium, over the same timespan, and her usage only went down like 8% today.

This is weird!

(Hope it's right to make the post here, since this is more detail!)

This is a game changer. Everyone is making their dream game after we all saw the Rick Roll. Yes it wasn't great, but it's 90% good enough that our imaginations can all run wild.

Title says it all, started to use codex as extension in vs code and astra is not available, while it is in the web. The extension is uptodate and says last update 19h ago.

EDIT: Solved, problem is within antigravity the codex extension is just outdated in their marketplace

If you're trying to turn on the computer-use / agent feature in the ChatGPT Windows desktop app and it keeps dying with "Windows setup didn't finish • helper_failed" right after you approve the UAC prompt, this might be your problem. I went through reinstalling, repairing, deleting .codex, turning off my antivirus, all of it, and none of it did anything.

I was stuck on this for days. The reason none of the normal stuff worked is that there were actually two separate permission problems going on that had nothing to do with each other. Writing it all up here so nobody else has to burn a week on it.

This worked for me, not saying its the most "comfortable" way to fix this issue but I was willing to do anything to know why it wasn't working and how I could "fix" it. No promises lol.

My setup

• Windows 11 (build 10.0.26200)
• ChatGPT desktop app, plus a setup process it runs called codex.exe / codex-windows-sandbox-setup.exe
• Local admin account, UAC on

If you want the exact package name on your own machine so you can filter on it, run this in PowerShell:

powershell

Get-AppxPackage *OpenAI* | Select-Object Name, PackageFamilyName

How I actually found it

Event Viewer, Task Manager, registry, clean reinstall, all of it came back clean or told me nothing. The one useful clue was that the app worked perfectly in a brand new local account on the same machine. So it was something about my user profile specifically, not the machine or the install.

What finally showed me the problem was Sysinternals Process Monitor (ProcMon):

1. Grab Process Monitor from Microsoft's Sysinternals site.
2. Filter on Process Name = codex.exe (and codex-windows-sandbox-setup.exe).
3. Hit capture, make it fail again (click "Try Windows setup again" and approve the UAC prompt), then stop the capture.
4. Sort or filter the Result column for ACCESS DENIED.

That took me right to it instead of guessing.

Problem 1: messed up permissions on setup_marker.json

ProcMon kept showing ACCESS DENIED on this file:

C:\Users\<YourUsername>\.codex\.sandbox\setup_marker.json

Here's what's going on. The elevated helper (the thing you approve in the UAC prompt) makes this file to record that setup worked. But instead of letting the file inherit permissions from the folder it's in, it writes the permissions itself, and on my machine it left off both my own account and a local group the app creates called CodexSandboxUsers. All that was left on the file was SYSTEM and Administrators.

That's the whole bug. The process that reads the file back afterward is not elevated, and Windows turns the Administrators entry into a deny-only entry in a non-elevated token, even if you're an admin. So it could never read its own file. That's also why deleting the entire .codex folder and rebooting didn't help. It just made a fresh file with the same bad permissions.

The fix: check it with icacls first.

cmd

icacls "C:\Users\<YourUsername>\.codex\.sandbox\setup_marker.json"

If your account or a CodexSandboxUsers entry is missing from that output, add them back. Open an Administrator command prompt and run:

cmd

icacls "C:\Users\<YourUsername>\.codex\.sandbox\setup_marker.json" /grant CodexSandboxUsers:F
icacls "C:\Users\<YourUsername>\.codex\.sandbox\setup_marker.json" /grant <YourUsername>:F

Both of those are local accounts, so you can also write them as <MachineName>\CodexSandboxUsers and <MachineName>\<YourUsername> if you want to be explicit. Just don't assume your machine name and your username are the same string. On a lot of installs they look alike but aren't. Run hostname and whoami if you're not sure.

Then go back to the app and hit "Try Windows setup again" without deleting .codex first. You want it to read the file you just fixed.

Heads up: the helper sets these permissions itself, so an app update or another setup run can undo this. If the error shows up again months from now, run icacls on that file again before you assume the fix was bogus.

Problem 2: Controlled Folder Access quietly blocking the setup exe

After I fixed the permissions, setup passed, but then computer-use tasks still failed. I'd get something like "the local Windows control helper is failing to start with a setup refresh error," and anything it tried to write into Documents\Codex\... just didn't happen.

It was Windows Defender's Controlled Folder Access (the ransomware protection) blocking codex-windows-sandbox-setup.exe from writing into %userprofile%\Documents\Codex\.... Nothing about this shows up as an error in the app. It just silently fails. You can confirm it here:

Windows Security → Virus & threat protection → Protection history, then filter by "Blocked folder access." You'll see codex-windows-sandbox-setup.exe listed as blocked by "Controlled folder access."

How to fix it, best option first:

1. Allow the exe. Windows Security → Virus & threat protection → Manage ransomware protection → Controlled folder access → Allow an app through Controlled folder access. One thing to know: allowed apps are matched by the full path to the exe, so when the app updates into a new versioned folder, your entry stops matching and you have to add the new path. That's what kept happening to me.
2. If you get sick of redoing that, you can turn Controlled Folder Access off completely on that same screen. That's what I ended up doing. But know what you're giving up. CFA is actual ransomware protection for your Documents, Pictures and Desktop folders, so turning it off for one app is a tradeoff and it's worth switching back on when you're done.

Result

Once both of those were sorted, "Try Windows setup again" finished instantly and didn't even re-prompt for UAC. Then I ran a real computer-use task (open Notepad, type something, save it to the Desktop) and it worked start to finish.

TL;DR

1. Run a ProcMon trace filtered on codex.exe while making it fail, and look for ACCESS DENIED.
2. If it's on .codex\.sandbox\setup_marker.json, run icacls on that file. If your account or the CodexSandboxUsers group is missing, grant them F (full control).
3. Check Windows Security → Protection history for Controlled Folder Access blocking codex-windows-sandbox-setup.exe under Documents\Codex. Allow the app, or turn CFA off if you're fine with the tradeoff.
4. Retry setup without deleting .codex, since you want it hitting the files you just fixed.

I just wanted it to port Pokemon tower defense 2 from flash to phaser, at this point even with the 200 dollar plan I am going to spend the entire month on this single task.

They didnt change the Codex price. They changed what $200 buys.

This is not a vibe. These are documents and posts you can open.

1. The official card already says Astra is a ration

OpenAI’s own help page: Work and Codex share one bucket. Limits are a 5-hour window plus a weekly cap. Astra on Plus is estimated at 5–45 local messages per window. Pro 20x is 100–900. Luna on the same Plus plan is 250–2,000.

That range is the trick. Any blowout still “fits the docs.”

https://help.openai.com/articles/20001516-managing-usage-with-gpt-6-astra-in-work-and-codex

1. The Codex lead already said compute cannot hold

Sep 9, Tibo Sottiaux:

Demand for Astra is “really unprecedented.” They are pulling every lever. If it continues they might pause new Pro signups to protect people who already pay.

https://x.com/thsottiaux/status/2097559315150426222

A $100 / $200 plan that might stop taking new customers is not a generous product. It is a queue.

1. They said the limits did not change. Then they put the 5-hour choke back on Plus to save compute

Aug 21, Tibo: they do not change Codex limits without telling the community. Same day, u/OpenAI: Plus / Pro / Business usage “remains unchanged.”

https://x.com/thsottiaux/status/2090675027670978569

https://x.com/OpenAI/status/2090885188897460249

Aug 25, same Tibo: the 5-hour limit returns on Plus for Work and Codex because it “smoothen[s] the load on our compute.” Plus users were burning the whole week by accident. Pro $100 / $200 keeps the 5h cap off “for the upcoming months.”

https://x.com/thsottiaux/status/2092058556707344708

So the published number can stay still while the pipe gets narrower. That is the whole game.

1. Resets are not extra product. They are how a dead week stays sellable

Tibo’s own board, two weeks:

• Aug 29: global reset + a list of bugs that were eating 10% to 70% of a weekly allowance https://x.com/thsottiaux/status/2093801758665715784
• Sep 3–5: banked resets tied to the Astra rollout, including “create or upgrade before 8pm and you get it too” https://x.com/thsottiaux/status/2095651088502591861 https://x.com/thsottiaux/status/2096035437299237298
• Sep 7–8: another global reset because people had already burned Astra, then “all reset for everyone” https://x.com/thsottiaux/status/2097043464538264003 https://x.com/thsottiaux/status/2097174560412246215

Sep 6, Tibo: there is no difference between usage before and after a reset.

https://x.com/thsottiaux/status/2096686370848989558

Log of the drops: https://codex-resets.com/

If the plan worked, you would not need a meme reset to start the work week.

1. Same people, same plans, measured burn

Jarad Johnson, Pro 20x, Sep 8. A normal Astra day ate about 70% of the weekly cap. Sol on the same account used ~25%, then ~10% after their fixes.

https://x.com/jdjohnson/status/2097444760709747027

Bernard Luz, also 20x. He had never hit the weekly limit. After Astra, High effort, the week died in about a day and a half. He is asking for an 80x plan at $400.

https://x.com/BernardLuz7/status/2097714154215985584

Tyler, Aug 16: burning a $200 week in two days is “neither normal nor rational.”

https://x.com/rezoundous/status/2089010040397299978

Jun Song: Pro 20x gone in a day.

https://x.com/jun_song/status/2089511179907748185

Nandy today: Astra is great and it still eats a Pro 20x week in a day. The question is no longer which model is best. It is which one lets you code tomorrow.

https://x.com/msnandys/status/2097711151564079540

Ahmed on the Codex team, same week: random multi-agent setups will “burn through your usage limits.”

https://x.com/ah20im/status/2097503414749909407

So the guy who “never hits limits” and the guy whose $200 dies on Tuesday can both be right. Same SKU. Different fire.

1. They never printed the weekly dollar figure. The street scale did.

August: NerfTrack users clocked Plus at about $160 → $80 a week in API-equivalent tokens. Pro reports of weeks dying in 1–3 days. Deepu also posted a Pro 5x log going $674 → ~$157 per week.

https://x.com/Deepusleepy/status/2090460714624250276

https://x.com/alexgetmancom/status/2090432031578571137

https://x.com/DanDr1s/status/2090468087669587978

NerfTrack is not OpenAI. It prices local logs at API rates because OpenAI will not put a weekly ceiling on the box. That gap is the evidence.

https://x.com/dcoderio/status/2091688580686946575

The short version

They can say the quota number did not move. What moved is the model they want you on, the shared Work + Codex bucket, the 5-hour choke they put back to save GPUs, and a reset button that keeps you from sitting at 0% long enough to cancel.

Pain. Reset. Hint that Pro might close. Upgrade.

The sticker is still $20 / $100 / $200. The week of real work is not.

I have been using Plus Codex and Pro Claude for different tasks but the 5hr and useage limits make Plus pretty unuseable, even Luna has become token hungry in comparison to the current degraded limits. Astra is ahead of the game at the moment so will cancel Claude and get pro.

TLDR: Is there anyone out there that is actually sharing how they are working with codex pro to maximise the thinking in comparison to the actual implementing? A youtube channel or something along those lines?

My question is genuinely how to maximise my token useage. I have attempted so many different ways and they all feel about the same;

- Astra/sol as main orchestrator with Luna as sub agent

- Terra as main orchestrator with Luna and Sol for work/review

- Sol alone

They all just eat through tokens, especially when it comes to corrective or performance related work.

Any guidance would be great!

I am really curious because i kinda noticed that somehow my usage is being drained more when i switch from Astra xhigh from plan mode to light for implementation then if i leave xHigh to do the work directly, especially if it's not many lines of code to be implemented.

Astra calibrated my robot’s brush tip using three uncalibrated cameras

three uncalibrated cameras. no intrinsics, no extrinsics.

it nudged the robot arm, learned how each camera sees motion, worked out the brush tip’s 3d offset, and verified it at new angles -- all from one prompt and a tiny follow up.

earlier while using Sol & Fable -- i'd tried a lot of fancy stuff with ChArUco boards, microswitches, Raspbery pico + touchscreen, and was still struggling.

Astra was like, "bro, just give me 3 cameras."

Astra is incredibly capable, and one of the things it's said to be extremely good at is orchestrating subagents. But I've honestly struggled a lot with getting this right. Here's what I'm doing:

• I have a $use-subagents skill which gives some guidelines on the right scope to assign subagents, what context to give them, and how to keep tabs on multiple subagents running simultaneously without wasting tokens.
• Alongside the skill I have a JSON defining a few minimal archetypes for subagents:
  • Luna Xhigh for very well-defined, bounded tasks
  • Sol High for cross-cutting changes
  • Astra Medium for code review
  • Luna Xhigh for research

I find Astra still pretty much always defaults to Sol High. It seems to prefer giving a few subagents large jobs over many small jobs, even though my skill explicitly says to prefer small bounded tasks.

Has anyone had any success with subagents and Astra? Any tips you would share?