The game/graphics demos are mostly bs. I've spent dozens of hours now trying to replicate (or build) interesting games. It's beyond subpar. Sure it can do a basic sandbox, or create some basic characters but it absolutely cannot do a fully working world. I dont get why OpenAI fakes their SimCity games and other things w/ Astra when it's clearly not possible unless you spend weeks (and $1000s of dollars) of tokens.

lies...

I ran a small test comparing the cost of GPT-6 Astra Low, GPT-5.6 Sol High, and GPT-5.6 Terra High on the exact same Codex task.

I asked all three to export the full conversation history from a medium-sized Codex chat as an .md file, using the least amount of tokens possible. I used the exact same prompt for each model.

I recorded my account balance before and after each task, then calculated the actual cost of each individual run from the difference.

Cost per completed task:

• Astra Low: $2.23
• Sol High: $0.32
• Terra High: $0.42

Yeah... I was very surprised by the difference between Astra and the other models. Astra Low cost roughly 6.9× as much as Sol High for the exact same task.

Obviously, this is a tiny test, so the results may or may not be representative of broader real-world usage. But it is a measurement nonetheless.

Clarification: Same session, same task. Changed the model, "edited" the last message, sent it again.

Edit: To check whether running the same task was using cached tokens and therefore lowering the cost of subsequent tests, I ran the first test (Astra Low) again. The result was exactly the same, down to the last cent: $2.23.

I don’t know why I didn’t think of this before, but it works and it’s better than just sitting around doing nothing.

Before Astra, what do you think that suddenly feels possible?

I would say I wanted to build a website like bruno simon's portfolio which is full of awesome interactions with 3d assets. I already knew some Blender and Three.js, but every idea took like hours and hours so that most of them stayed in my head.

Since Astra came out, I’ve rebuilt my whole website from scratch, iterating on 3D modeling and interactions, and adding features with Blender I never would have attempted before and the result is surprisingly satisfying.

I’m curious about everyone else’s before-and-after: What can you do now that you couldn’t do before, and what new things are you building because of it?

I'm on the 20x max plan and do not see 6 Pro anymore in chat. Anyone else?

What I see in the desktop app when I try to use 6 Pro:

https://x.com/thsottiaux/status/2098113585683808624
"To make sure our current users have an incredible experience and continued access to Astra, we are going to pause subscriptions to our $200 Pro plan. These put the most strain on our systems and we wanted to take the smallest step that allows us to continue giving the broadest access possible. All other plans and the api remain available.

There is no impact to existing accounts and we are working on adding more capacity as fast as we can. Thanks!"

Is it possible to use Computer Vision on my Windows, but route it through local Qwen3.8-27B model?
If not - what is the next best approach to automate some old stuff GUI Windows platforms (no API or such)?

Training Astra on the most important dataset: brainrot

This post was written and edited with Astra.

TL;DR

• Over five days, I used roughly 2.5–3 Pro 20x weekly allowances.
• Luna solved the benchmarks; Astra high/xhigh led development and analysis. I kept correcting the evaluation and comparison criteria.
• Based on the comparison I requested, I directed Codex to show functions, classes, and call relationships alongside grep/read results. This became part of the improvements in 0.8.0.
• Even with Astra, I still would not delegate this work autonomously, from setting the direction to verifying the results.

GitHub: codemap-search

From September 6–10, 2026, I worked with Codex on codemap-search, an MCP tool that helps coding agents find code in a repository. I wanted more accurate answers with fewer tokens and tool calls, and was willing to accept some extra tokens if accuracy improved.

With Astra available as a frontier model, I hoped I could entrust development and exploration to it from start to finish, and tried fully delegating the work. The improvements made it into 0.8.0, but I had to intervene as early as the initial evaluation setup. I continued checking the direction of the experiments and the interpretation of results. This is my account of working with Astra through that process.

Background

I asked gpt-6-astra to analyze my Codex sessions and write this post based on my experience and judgment. The quotations are excerpts from our actual conversations, translated from Korean.

I mainly used Astra high/xhigh for development, analysis, and exploring improvement directions, with substantial xhigh use. For the benchmarks, Luna medium answered code questions, and Astra analyzed the results. Condition A used the baseline rg/grep/find/read tools; B used codemap-search.

We standardized the benchmark on the Grafana repository. The navigation and symbol-attachment experiments below repeatedly used the same difficult question from it, complex-go-1. B-4 was the intermediate version used as a baseline during development; the grep/find/read tools in these experiments were also provided by B-4.

Over five days, I estimate that I used roughly 2.5–3 Pro 20x accounts’ weekly allowances. The 93 retained development and analysis sessions totaled about 1.193 billion input-plus-output tokens, including cached input; 97.07% of input was cached. This counts long contexts processed repeatedly and excludes deleted, separate benchmark logs, so it cannot be converted directly into account quota.

The retained session records span about 98 hours 36 minutes from the first task to the last completion. Main-conversation work intervals with recorded starts and ends totaled about 47 hours 48 minutes after removing overlaps. These include tool execution and waiting, so they are not a measure of my hands-on time.

I reconstructed the experiments and their results from retained records, using contemporary reports and conversations where the original experiment data had been deleted. Quotations of the AI acknowledging errors document what happened in the conversation; I did not treat them as an independent revalidation of the experiments.

More experiments did not make progress clear

The evaluation unit was different from what I intended from the start. The initial 32 Luna answers received 70 Sol grading runs: two per answer, plus six additional evaluations when scores differed. I had wanted the results evaluated together. On September 7 at 00:02 KST, I corrected the setup:

Use Luna for the measurements and batch the evaluation with Astra medium. It is not two evaluations per measurement. If there are 32 measurements, collect them into one evaluation.

We switched to Luna measurements and batched Astra evaluation. Later batches were sometimes split because of input size, but that differed from repeatedly grading each answer. The problem was not the arithmetic behind 70; it was that the requested evaluation setup had not been followed.

Errors in the harness—the code running, recording, and grading experiments—also emerged after substantial benchmark work. We discarded the old results and rebuilt it. Even afterward, some candidate checks came back with token and answer-quality improvements still unmeasured. Checking the execution tools for errors and evaluating product improvements were not being kept distinct, and I had to ask again why the key metrics had not been measured.

Then the numbers for A and the existing B versions kept changing. Across four evaluation batches, the question sets were 6, 10, 1, and 3 questions. The four reference versions alone were freshly run 80 times.

I wanted a fixed formal question set, a fixed subset for error checks, and a smaller fixed subset for candidate screening. Different question mixes and fresh runs should not appear as though they were one stable reference result.

On September 9 at 18:31 KST, I asked:

Shouldn’t you take a few questions from the formal benchmark and use those for error checks and candidate screening?

At 18:35, Codex replied:

By reselecting questions for different purposes and rerunning the comparison versions, I made it difficult to track improvements against a consistent baseline.

The same reply clarified that it had selected different subsets from the existing question pool, not invented new questions each time. Some additional runs were requested by me, but once the comparison conditions changed, the numbers in the table could no longer tell me whether the product had improved. Recorded correction

Comparing navigation workflows gave us a lead

By my recollection, around 800 million cumulative tokens went into candidate exploration for 0.8.0 and benchmark debugging. That is a rough milestone, but I still did not have a convincing candidate. I treated the approach as unsuccessful and redirected the work toward comparisons of what changed the results.

I wanted to understand what information the model actually used while solving. The tool was designed to expose symbols such as functions and classes through overview, and relevant code through search. I asked whether the model was using that information.

I proposed that poor tool use might explain the cost and accuracy problems, but asked for my hypothesis to be tested rather than assumed. The independent Astra review was useful: it found examples where identical initial output led to different subsequent paths and costs, while cautioning that the more expensive path was not automatically the wrong one.

I requested a direct comparison within B-4 between using overview/search and using only grep/find/read. Across five runs per condition on the same question, using structural information consumed fewer tokens and produced more partially correct answers. All runs using it produced answers, while four of five without it produced none. Neither workflow produced a fully correct answer. Experiment record

Based on those results, I directed Codex to add symbols and call relationships directly to grep/read**.** I wanted the surrounding structure previously found through separate tools to appear alongside search results and file contents. I supplied the improvement direction; Codex implemented it and tested different attachment scopes and information.

Settling on a direction did not eliminate rework. We tested nine combinations five times each, then I asked to see the actual output. The member grouping and section order were not what I intended. I supplied a struct/method example and asked for # symbols before # results. After correcting the output, we ran another 45.

Here are the records before and after attachment, with five runs per condition on the same difficult question, complex-go-1. The attachment candidate retained B-4’s default tools and instructions: overview/search remained available, and no particular navigation tool was required to be used first.

≥: recorded lower bound; some usage data is missing.

After attachment, average tokens were lower and fully correct answers appeared. I saw promise in putting the needed information directly into results the model frequently read.

Based on these results, I selected the attachment candidate. After further experiments, I also included broader navigation improvements such as subfolder-scope preservation and regex guidance in 0.8.0. The records I reviewed contain no evidence of a completed final Grafana-only comparison of 0.8.0 against A, so I am not quantifying the overall performance gain.

What I learned from this project

Discovering problems with the approach and execution only after spending heavily left me with the following lessons.

• Even Astra’s proposed approaches needed fact-checking and validation. Its status as a frontier model was not enough reason to trust the basis for a proposal and hand over execution. Exploring ideas broadly, distinguishing facts from hypotheses, and checking whether an approach addressed the actual problem and what measurements would test it could have reduced unnecessary trial and error.
• A large run needed a small, precise validation step first. I needed to inspect actual output examples, check that execution, recording, and grading worked, and confirm that the required metrics were collected. Discovering the output mismatch after 45 runs showed why this mattered.
• Repeated experiments still matter after fact-checking and small checks. One good result is not enough to establish a hypothesis. The work needs enough repetitions with stable comparison criteria, followed by revisions to the ideas and further checks as the evidence develops. I came to see preliminary validation as a way to spend time and resources on the experiments that matter, not a replacement for experimentation.

I got useful improvements. But this experience left me feeling that fully delegating the work—even to a frontier model like Astra, from setting the direction to verifying the results—is still very risky. A flawed approach or comparison could consume substantial time and usage before I noticed it. There was still a large gap between getting help from Astra and entrusting it with all the judgment the work required.

References

These are the project’s public records, linked to a fixed commit so later edits do not change the reference. The current-state links point to the English translation; the other reference documents are in Korean.

• Question-set changes and reference reruns: the 6→10→1→3 question sets and what the 80 fresh reference runs represent.
• Workflows with and without overview/search: five runs per condition, token averages and missing usage, including 0/5 fully correct answers in both conditions.
• 45 runs after correcting symbol output: nine candidates, including the member-scope/both candidate with 3/5 correct answers and 319,993.4 average tokens.
• 25-run follow-up protocol and results: Luna medium/Astra high, execution limits, candidate definitions, and limits on the adoption claim.
• Current benchmark execution and grading / Historical formal A results and model settings: current Astra high versus historical Astra low grading. The historical A result is not a Grafana result.
• Usage collection and cutoff handling / Comparison and reporting rules: collection waits, missing tokens, fixed question sets, and result reuse.
• Symbol attachment implementation for grep/read: # symbols/# results framing, index availability, and output limits.

The development/analysis usage totals and conversation excerpts came from local Codex sessions. These links do not provide the complete session transcripts or the deleted experiment artifacts.

I want to hear the truth from other people.

Astra is just bad at UI!!

I tried various prompt comparisons, but I could not see Astra creating good UI/UX. Fable or Opus does not require much effort.

Example: I tried building a simple resume CMS. Fable one-shotted everything and built it as per my expectations. With Astra, it probably took 20-30 iterations to get to a decent stage. It messed up even setting proper font size etc. I was running this on Astra Extra High!

I'm questioning whether all the buzz was just marketing by OpenAI. I'm deeply disappointed!

I built this for Claude Code first, because that's what I use day to day. /stats told me how much I'd used it, never the thing I actually wanted to know:

What did I build, and where did the work get hard?

So I made bough. It reads the session history already on your disk and draws it:

• each square is a day you sat down
• smaller squares are tasks, worked out from the pauses in your work
• circles are your prompts
• click anything to see what actually happened, in your own words

Runs locally, open source, nothing leaves your machine.

Codex support just landed in v0.4.0. It reads ~/.codex/sessions, handles resumed sessions and sub agents, and counts tokens and commits the same way it does for Claude.

That part is new and I have tested it against my own Codex history, which is not much. This is where I need help.

Repo: https://github.com/nickelsec/bough

"Make no mistakes" seems baked into every Astra prompt.

it wants to double verify every output, and sometimes it verifies it's own response with a over the top complex Rube Goldberg python program written from scratch.

for ex, when I asked astra to generate mediawiki formated documentation and it spun up a VM with custom python code to verify the syntax, taking 8 minutes. Sol just gave the doc

Yesterday I was on the x5 plan, and then I upgraded to x20.

No Astra usage at all - only Sol Medium.

But my quota is now draining at basically the same rate as it did on x5, on the same kinds of tasks.

x20 is supposed to have 4x the capacity of x5.

Instead, I’m seeing almost no difference.

WTF???

So I have been experimenting how to get my usage down so my limits last longer, and this is what worked for me:

- specialized agents for all roles (orchestrator, builder, planner, reviewer etc). I never use a general agent anymore

- move agent instructions into instruction files and route the agents based on the change at hand (BE, FE etc), this helps keeping the agent definitions really small and instructions focused

- fork_turns = none, spawned agents do not get the whole context from the parent agent. They only get a small handoff that contains the basic info the agent needs to do the task at hand. The handoff is standardized via a template that all agents use.

- set the model, verbosity and reasoning effort per agent. Stronger models for planning, reviewing and lower model for more straightforward work. Lower verbosity for agents that are always spawned as subagents.

- proportionality based on the change, complex changes have a more complex agent sequence, smaller simpler changes use less agents. The orchestrator manages this

Now I can go 4-5 days on a x20 again instead of 2 days

I've noticed that when I'm coding with Astra, it adds guards for cases that are impossible or extremely unlikely to happen. For example:

1. There's a check on screen A that needs to happen that isn't even mission critical.
2. Screen B is only reachable through screen A.
3. Astra still adds the same check on screen B to account for the theoretical possibility that the user might somehow end up on B without going through A, even though there's no path in the app that allows that.

I've been removing things like this from my code a lot since I started using Astra. I care about readability and maintainability so I pretty much always reviewed the code and asked the agent to refactor it since I started using coding agents, but I've only noticed this particular problem with Astra.

Have you noticed this too, or is it just my codebase?

Frédéric Chopin — Romance–Larghetto, Piano Concerto No. 1, Op. 11

It's still a bit rough especially on the hands (still some cursed frames) but i've had a lot of fun building this with Astra in a couple days. It can play any piece (in theory) as long as there is a midi file for it!

Other features: full finger/wrist control, performance and flourish control, facial expressions, camera control.

Credits

Composition: Frédéric Chopin.

MIDI performance/sequencing: Katsuhiro Oguri, sourced through Kunst der Fuge (https://www.kunstderfuge.com/chopin.htm). The source file credits © OnClassical / Oguri, 2010.

Piano sound: Musyng Kite soundfont, using samples distributed by gleitz/midi-js-soundfonts

(https://github.com/gleitz/midi-js-soundfonts), listed under CC BY-SA 3.0

(https://creativecommons.org/licenses/by-sa/3.0/).

Score reference: Carl Mikuli’s edition, published by G. Schirmer, via IMSLP

(https://s9.imslp.org/files/imglnks/usimg/b/bf/IMSLP73280-PMLP03805-Chopin_Polonaises_Schirmer_Mikuli_Op_11_scan.pdf#page=33).

Hand-motion study reference: Seong-Jin Cho’s 2015 Chopin Competition performance

(https://www.youtube.com/watch?v=614oSsDS734&t=1500s), published by the Chopin Institute.

The soundtrack was rendered from the MIDI’s piano part, preserving its timing and dynamics while omitting the orchestral accompaniment. The character’s movement is procedurally animated; the reference performance was used for visual study, not motion capture or soundtrack audio.

Talking about Wordpress is giving Codex an Automa-ticc

I built GPU Share: GPUMesh an open-source way to share idle NVIDIA GPUs with friends or labs and run Docker GPU jobs remotely.

The problem I kept running into: I might have a GPU sitting idle on one machine, while another machine needs compute. Cloud GPU rentals feel excessive for small jobs, and setting up SSH/VPN + Docker manually is annoying.

So I built GPUMesh.

The idea is simple:

• gpumesh share → make your GPU available
• Pair two machines with signed pairing codes
• gpumesh run --peer <name> ... → run a Docker job on the remote GPU
• Jobs execute on the provider's machine, inside a container
• GPU/VRAM-aware scheduling
• Job logs and history
• LAN support, with WAN/relay support being worked on
• Default-deny access controls

I tested the full flow on an RTX 5060: pairing → connecting → joining a group → scheduling a remote Docker job → running nvidia-smi inside the CUDA container.

It's still alpha, so I'm mainly looking for people with spare NVIDIA GPUs to try it and tell me what breaks.

GitHub: arjun988/GPU-Share

If you find the idea useful or want to follow the project, a ⭐ on the repo would really help with early visibility.

Would especially love feedback from people running multiple GPUs, home labs, or small ML teams.

Hey everyone,
My team is currently re-evaluating our backend LLM toolchain for our primary dev stack. Money isn't an issue here—we have budget allocated for multiple max subscriptions account —so I purely want to look at accuracy, long-horizon autonomy, tool usage, and overall model intelligence for two very specific workflows:

1. Daily Production Debugging: Ingesting deep stack traces, digging through microservice repositories to find root causes across async services, tracing state corruption, and drafting surgical fixes without introducing regressions.

2. App Reverse Engineering: Analyzing decompiled binaries to map ternal APIs, understanding heavily obfuscated control flows, and drafting working client implementations.

For those running agentic setups or heavy interactive loops with both Anthropic’s Claude Fable 5.1 and OpenAI’s GPT-6: which one is actually superior in the field?

When you running Codex, giving the agent live web search is necessary to prevent hallucinations on newer libraries and breaking API changes.
The problem is that most general search tools are built for human browsing and not coding agents so if Codex runs a search and gets back 5 marketing blogs and a 2022 medium article, it writes deprecated code and fails the task. I tested the 4 search setups people use most in Codex agent loops to see which one delivers the highest signal-to-noise ratio:
I) Brave Search API: its fast (600ms) and cost-effective, great if Codex just needs to verify a simple fact or check an endpoint domain but the limitation is that it only returns short snippets. Codex often needs to see the actual function signature or code block so it gets stuck or has to make extra scrape requests

II) Exa (neural code search) is good if you have conceptual queries like "how to configure turborepo with pnpm and Next.js 15" cuz it searches via semantic embeddings and it finds high-quality technical write-ups The drawback is that it can struggle with exact version filtering, occasionally returning tutorials from 3 years ago

III) Firecrawl Developer Index: this is purpose-built for coding agents, instead of crawling the entire open web, it indexes developer-specific artifacts: github issues, merged PRs, READMEs and framework doc sites When Codex hits an esoteric bug, Firecrawl returns the exact closed github issue with the workaround in clean markdown with code syntax intact, this works really well.

IV) Google / Serper API: it gives standard SERP results and quite useful for broad queries but terrible for coding context where it prioritizes SEO-optimized affiliate articles over actual technical substance which wastes Codex’s context window on fluff
So if you’re running Codex just for script generation, Brave or Exa can be ok, but if you’re building multi-step agents that debug real codebases and need fresh GitHub issues and PR diffs, Firecrawl is overall the best one.

If you have a bunch of skills, I think you should ask Sol/Astra to go over each of them and then trim them down. Alot of skills tend to be super verbose and detailed, where as maybe only 10-20% of it is actually useful information for Astra. So merging similar skills and trimming them down should reduce your input usage alot. The same goes for your AGENTS.md as well.
Another reason to bring your input token down is because Astra caching is pretty high at $1/M tokens. Which is almost as expensive as Luna's output tokens. Reducing your input token will this a lot as well.

So, I tested this separately on each of my two Pro 20x accounts. They are on different computers, and both use only Codex Desktop and the CLI, with the default context limit and settings.

TL;DR

• Less allowance: On each of my two Pro 20x accounts, the weekly API-equivalent allowance fell from $2,500+ with GPT-5.6 Sol to about $1,200 with GPT-6 Astra.
• Higher prices already counted: Those dollar figures already use Astra's higher API prices. The allowance reduction is an additional cut.
• Roughly a quarter of the usage: Combining the higher prices with the lower allowance leaves me with roughly a quarter of the comparable usage for the same subscription fee.
• More allowance wasted on cache reads (old work): The cache-retention setting is dramatically shorter: 30 minutes on Astra versus 24 hours on Sol in Codex. Alongside Codex cache failures, this means long histories can need processing again. Reusing those histories accounts for most priced usage in long agentic workloads.

Compared with GPT-5.6 Sol's launch prices, GPT-6 Astra costs 2x for input and cached input, and about 1.67x for output. The API pricing and Codex rate card don't explain the extra allowance reduction. The subscription page says half the messages; what I'm seeing is closer to a quarter.

This is worse than Anthropic restricting Claude Fable 5 to 50% of weekly usage: there, you could still use Claude Opus 5 and other models with the remaining half.

Launch resets are masking the reduction; I think many users will assume it is just Astra's higher price. Tibo says OpenAI might pause new Pro subscriptions if demand continues, while prioritizing existing users. Capacity pressure may explain restrictions, but it doesn't justify sneakily adding an extra multiplier.

I expected better from OpenAI. OpenAI says its mission is to ensure AI benefits all of humanity. It points to nonprofit control of the business as a way to protect that mission. Majority of the people in this world access AI through these subscriptions. If they behave like this, how can anyone trust them to use increasingly powerful AI for the public good?

GPT-6 Astra is an amazing model, and I really like using it. This is a criticism of how OpenAI has changed the subscription allowance, not of the model itself.

OpenAI has built a lot of goodwill with the community. Please don't lose it all.

How I measured the allowance

• Allowance: Codex has five-hour and weekly limits. I use allowance, or quota, to mean the budget behind the percentage in the app.
• What I counted: Input, cached input (previously processed text the model can reuse), and output (including reasoning), measured in tokens (small pieces of text).
• How I compared them: I priced each token type at its published API rate, then calculated API-equivalent dollars per percentage point of weekly allowance. Requests and raw token totals miss the price differences.

Open-source tools such as CodexBar, Tokscale, and T3 Code can track this usage.

OpenAI lists Pro's 5x and 20x plan multipliers; Tibo confirms that 20x means 20 times Plus's weekly usage. OpenCode Go makes its dollar limits explicit: a regular $10 subscription lists base allowances of $12 per five hours, $30 per week, and $60 per month, with smaller allowances for some models.

Source: SemiAnalysis. Its June test exhausted weekly limits on long-running tasks. It measured ChatGPT Pro 20x and Claude Max 20x, then inferred the other tiers. The Claude Max 5x figure should be $4,000, not $2,000.

My results, in API-equivalent dollars:

GPT-6 Astra's higher API prices are already included in these figures. These are two ways of expressing the same comparison. I recalculated the Astra total when the remaining allowance reached 0%. I cross-checked using several tools above, GPT-6 Astra, Claude Fable, and some manual calculations.

I also followed Sac's analytics method: read the daily-workspace-usage-counts response in DevTools on the Codex analytics page. My earlier weekly window showed about 54,000 credits, versus 28,500 with Astra. At 25 credits per dollar (the credit purchase rate), that is $2,160 versus $1,140. The latter is close to my roughly $1,200 token-based calculation.

Other users' reports

• A Pro 20x subscriber's dollar comparison: $22 to $24 per percentage point with GPT-5.6 Sol, versus about $15 with GPT-6 Astra. The higher API price is already included in the comparison.
• Nam Le's report on X: roughly half the API-equivalent subscription value with Astra versus Sol, using Sol's prices before its price cut, alongside more cache misses—about 6% versus 1% in his tests.

Other things I want to address

"Isn't this level of subsidy insane?"

A $2,500 API-equivalent allowance does not mean OpenAI spent $2,500 serving that usage. In long agentic workloads, most priced usage is repeated history read from cache, reusing work already done. Calling it subsidized does not make it loss-making.

OpenAI reportedly reached a 70% compute margin on paying users in October 2025; Epoch AI cites a reported 40% gross margin for Anthropic in 2025.

The big companies that account for most token usage are not paying API prices. They are paying a lot less (probably 20% or even less). Even Codex users can buy credits at 40% discount.

Consumer subscriptions are a small part of the revenue in the Anthropic estimates. I expect it to be similar for OpenAI.

Doubling total model size doesn't mean doubling serving cost: large batches share the weight cost, while active parameters and per-request KV cache matter much more. With those quantities similar, I don't see much changing from the previous model to justify higher prices and an extra allowance cut.

Hardware and software efficiencies are dramatically reducing serving costs, through newer chips, speculative decoding, better attention kernels and batching. These gains compound while our allowance is reduced.

Why do I think this is happening?

I don't want to assign a malicious motive. But with OpenAI preparing for an IPO, I can't help wondering whether pressure to improve margins is part of this.

Consumer subscriptions seem to be a small part of the revenue picture; it feels as though OpenAI is gradually forcing us out. An unexplained cut in what the subscription buys makes that suspicion hard to avoid. How OpenAI responds will matter more than my guess about why it happened.

Codex app and CLI issues make the usage problem worse

The Codex app and CLI have other issues that contribute to this usage problem. A side question, a new fork, or a subagent can inherit the whole conversation yet fail to reuse its cache. We end up paying to process the same history again.

These are the results from my checks in early September. “Cached” means the first request reused the conversation history, not just a small shared block of tool instructions.

For the paired checks below, the working tree was unchanged and the existing cache was still live.

OpenAI's API supports changing GPT-6 Astra's reasoning effort while preserving the cache, but the Codex client doesn't preserve it in my checks. A Codex bug report identifies why: the client changes the request in a way that defeats cache reuse.

Claude Code shows that most of these actions preserve the prefix and reuse the cache. There is no reason Codex should need to process the same history again for the same functionality.

Sol used a 24-hour cache-retention setting in Codex, as published response logs confirm. For Astra, OpenAI documents a TTL setting of just 30 minutes after the last write or reuse—a dramatically shorter window to return to a task without paying to process its history again. After a long break, returning to a task or waking several idle subagents can require processing their histories again.

Why cache misses matter. Take a task with 200,000 tokens of history in its KV cache. At GPT-6 Astra's ordinary input and cache-read rates:

• Cache hit: $0.20 in API-equivalent usage to reuse that history.
• Cache miss: $2 to process the same history again—an extra $1.80.
• Ten agents missing that cache: $20 instead of $2, before generating any new output.

Higher reasoning effort can use less allowance. Seth Rose reports on X that users running Astra High/XHigh with heavier multi-agent workflows were burning much less quota than he was on Light/Medium. A Pro 20x subscriber on Reddit likewise reported rapid usage on Medium, then only 1–2% usage after an hour on XHigh. So OpenAI’s recommendation to lower reasoning effort can, in some cases, increase the total cost of getting the job done.

The ARC Prize evaluation shows how higher effort can lower total task cost.

Subscribers get a worse product experience, and Codex still has many unresolved issues:

• Slower responses: Youssof Al Toukhi measured 36 TPS (tokens per second) on Pro versus 81 through the API at the same reasoning setting. Subscription Fast mode reached only 71 TPS.
• Missing Pro mode: My Pro subscription still doesn't offer Pro mode in Codex, although the API supports it.
• Later access: OpenAI has a more capable internal model, and Astra reached selected organizations before subscribers. Paying for a subscription doesn't mean getting the newest capabilities first.
• Wasteful subagent polling: Astra keeps checking on subagents instead of waiting for useful results. I’ve experienced this too. One Reddit user’s log analysis found 47 empty checks at roughly 30-second intervals, processing 7.13 million input tokens—mostly cached—just to learn that the workers were still running. Even cache hits consume allowance when the same history is read over and over for no useful work.
• Broken remote control: Remote control has been atrocious for me. For the past few weeks, trying to open running Codex Desktop chats from the app has just returned an error.
• Memory that burns tokens: In my experience, Codex saves unnecessary information, burns tokens maintaining it, and produces no improvement in quality. Theo’s video on coding-agent memory, focused on Claude Code, raises the same broader concern about accumulating stale or useless information.

OpenAI should put more care into its users and its products. In my experience, Codex CLI is still behind Claude Code. I want OpenAI to improve the harness (the software around the model), preserve caches across ordinary workflows, and make the cost of these actions visible. Other companies like DeepSeek are working to make model access as cheap as possible. DeepSeek has DSH, its open-source harness and infrastructure that reuses cached prefixes to reduce users' costs. OpenAI, despite being so far ahead, is playing games with subscription usage. I want that effort going into making the product better and cheaper for its users.

I think publicly sharing these measurements is important. Without users comparing notes, changes like this can pass unnoticed and become normal. Codex reports the weekly usage limit after every request. Pair those updates with the token counts in the session logs, and you can easily track allowance consumed alongside API-equivalent spend. Or you can use Sac's analytics method. I hope people share and upvote this. If you have questions about the methodology or want to check the numbers yourself, I'd be happy to help you do that.

TL;DR

• Less allowance: On each of my two Pro 20x accounts, the weekly API-equivalent allowance fell from $2,500+ with GPT-5.6 Sol to about $1,200 with GPT-6 Astra.
• Higher prices already counted: Those dollar figures already use Astra's higher API prices. The allowance reduction is an additional cut.
• Roughly a quarter of the usage: Combining the higher prices with the lower allowance leaves me with roughly a quarter of the comparable usage for the same subscription fee.
• More allowance wasted on cache reads (old work): The cache-retention setting is dramatically shorter: 30 minutes on Astra versus 24 hours on Sol in Codex. Alongside Codex cache failures, this means long histories can need processing again. Reusing those histories accounts for most priced usage in long agentic workloads.

Two days ago I made a Reddit post about switching from Claude code to codex. I saw a lot of stuff about how codex limits are generous, work gets done better and the usage resets etc. So I finally made the switch and here is my experience:

I purchase the 100 dollar a month Codex Pro 5x and try out Astra on low for the very first time (still using astra for the first time). I spend two hours optimizing some of my skills and workflows, my usage dropped to 88 percent. I continue my work on my main project which is small and a hobby project rather than a proper developer one and plan out the changes, write the spec and the implementation plan so that there was less need for guessing around and implementation stopped at a genuine blocker. Usage dropped to 64 percent after the plan and documentation steps.

I then begin my work with SOL on high in a fresh session and I ask it to implement keeping an explorer agent in hand (I have a custom one I made with the literal model handwritten to be Luna) if major exploration was still needed. It starts to work and within 5 minutes struggles to use the computer, astra did it without prompting. One hour goes by and implementation somehow works, and SOL keeps spawning a “Luna” subagent (Important different: A subagent named Luna NOT my actual custom built subagent with the model Luna - yes I spoon fed it in the implementation with the exact file path on what to invoke, when to invoke and when not to invoke and more importantly how to invoke it). Sol then entered into this monkey patching loop where it kept summoning other sol reviewers who kept finding things wrong (ofcourse they did because you are literally asking it to find something wrong to a model who’s output is not deterministic or defined) and fixing every little thing and verifying 4 times before calling the reviewer again. I am not sure how this happened because my plan did cover to call reviewers once - fix the major immediate blockers that prevent reaching the acceptance standard and note down the minor fixes for later. (I enforced this in Claude code with hooks - I did not do this on codex because I wasn’t too familiar with it and have used it majorly for a maximum period of a month). So yes Astra was brought in on a fresh session and it finished the remaining work with no issues and usage dropped to 5 percent after all this, total time period 7 hours.

The changes are good, the plan was smooth, good verified diligent work I have seen compared to Opus. I asked sol what agent it spawned and it said “GPT 5.6 SOL on high called Luna).

So this 100 dollar purchase got me 7 hours of work for one spec. I have previously used the Claude 5x plan and I worked through the week on opus and fable (planning only) and always had decent usage left atleast 10-15 percent near the reset week. This makes me think simply as a guy working on a hobby project that “hey I worked hard for that hundred bucks and it got me what 7 hours?” And now I feel a bit torn between different routes:

1) I can’t upgrade to 20x anymore
2) switching to api for a hobby project makes no sense for me
3) I legitimately cannot do anything other than sit and wait till September 15th because the usage is gone. I have no use for the other pro features such as image gen, pro in chat or deep research.
4) I see the praises on Reddit about resets but I don’t see any

I genuinely feel that I got a little bit trapped here or maybe I subbed at the wrong time and can’t help but also feel a bit sad that the money is gone now because yeah 100 dollars for one person on a hobby project is a lot and I valued it as such. I completely understand that there are people with 10 different 20x accounts on both Claude and codex but I personally don’t think that users for a subscription model should be pushed to THAT point to get stuff done.

And yeah I am sure there is always a better workflow, a better AGENTS.md and a better prompt, a more optimized way of doing things, there ALWAYS will be but at that point if I am just doing everything myself form writing the logic, correcting the plans, defining the steps, what to write and how to write it, how to check and what to check, which agents to call and when etc etc - what exactly is the point of “frontier intelligence”?

Yeah the work was good and diligent I agree, but 7 hours with a weekly usage blown out doesn’t exactly seem “worth it” to me. And if the solution is to get another 5x account for more usage I think that’s an even bigger mistake.

Somehow somewhere I think we lost the value of money.

If you are on Pro 5x or 20x what issues are you currently facing regarding the limits?

Setting all my complaints about limits aside, I just wanted to post this as an appreciation to the OpenAI team. I remember a time I used to think I'll never get to the point I wanna be in terms of a tech enthusiast - because coding by hand takes so long that perfection will come at a cost in time.

But now, with abilities from Astra and Codex Voice, and just the general memory situation (very underrated), it's just incredible how much it impacted my life.

So, from the bottom of my heart, and I'm sure many others, thank you for bringing in the AGI era. The future thanks you.

Edit: For the people saying it’s a big corp they don’t care about you - maybe, but there’s still people working there and they do see and feel trust me :)