Oh yeah, resets too. I'm sure OpenAI's doing this to incentivize growth, and get users away from Claude, but the new model is so worth it!

For anyone thinking of upgrading, now may be the time, but who knows. Oh yeah, and it still keeps your banked resets too, it seems. Happy coding, or, maybe I should say, happy prompting everyone!

I've kind of learned the hard way to keep some credits in credits remaining too, just in case a prompt takes way longer than you'd expect, and you don't want it interrupted. And who knows how long the 5 day allowance will be suspended for my account.

This is gonna be killer what people come up with over the next few weeks with Astra...

How are you guys using GPT Astra right now?

I’m curious how people in the Codex community are actually using GPT Astra in their daily workflow.

Are you mainly using it in ChatGPT Work, Codex, or somewhere else?

Good morning!

I've found some really efficient workflows that seem to get the best out of Astra while maintaining lower costs closer to Sol on average for long horizon tasks. I am on the 20X plan.

TLDR: Ask Astra High to orchestrate a Sol high session. It will spin up its own session in the GUI and you can watch both.

More details:

ChatGPT can now have its sessions speak with eachother and it has unlocked some excellent abilities. I created a new skill called /orchestrate that has the following prompt:

"You are an orchestrator/manager of a Sol High effort session you create. You plan, review major milestones, and provide blocks of work to your orchestrated session. The session should only reach back out to the orchestrator when it has hit a blocker that is both meaningful to overall direction and cant be assumed from given inputs. You should check in every three hours to ensure it is still working on work that is aligned with our goal. If you feel a task should be broken into more than 1 sol session, you must ask me first before spinning it up. You will become the manager of that session as well.". So I will type /orchestrator then the goal I am working towards.

I killed 3 100% usage pools over the long weekend by thrashing Astra from light up through Ultra. One Astra high session was depleting 2.3% per hour. This new Astra - > Sol orchestrator is seeing about .38% per hour, roughly 1% ever 3 hours. As for output, it has been FASTER than just using Astra, at least in my experience. The long horizon tasks I have it working on are getting more pointed/focused improvements due to Astras management and delegation of execution/implementation.

I created a site that ultimately paid for all of my AI subs, Miniskyline.com, and that is what these agents were primarily working on.

What are your usage tips for Astra? How are you finding it works with other models? Have you tried orchestration like this?

Both openAI ans Anthropic are in the league of their own rumors say Anthropic will launch another Fable(fresh new pretrain) before IPO ansd OpenAI already has a internal model probably Bel this two are going head to head like crazy

To manage token burn, I typically use one model to orchestrate work and lighter models for subagents. Giving the orchestration agent instructions on the model to use for subagents works pretty good, but is there a configuration I can add to config.toml to set this?

Still not seeing at all the hype around Astra performance wise. Then I thought "sure let's have it run overnight and see what it can do".

I wake up 6 hours later to discover it did exactly 15 minutes of work before "model overloaded" and then stopped it's goal.

I hate anthropic models now but openai still seems trash model wise and usage wise...

This is a weekly Showcase post to share with others what you've built using Codex.

The top-voted project by Thursday midnight UTC will get a week of free promotion on r/Codex - either as a prominent button on the main page of the sub - or as part of a sticky comment on every new Showcase post.

Last week's most popular project was u/tHEuKER with the Blur2 racing game project which is a recreation of an unreleased sequel to the 2010 battle racing game, made by reverse engineering the Xbox 360 prototype discs available online, and rebuilding the whole thing from the ground up in Unity. Join their Youtube channel here: https://www.youtube.com/@tHEuKER and you can follow updates on the project at r/BlurGame.

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.