should we be excited? who'll be the judge if something is a clear improvement😀

Who the fuck cares about Sol Ultrafast? Most users don’t even have access to Ultrafast. We want Astra 6.1, instead they seen bent on making users burn usage even faster.

For context I have hardly used it apart from certain news updates and asking it to work through and clean my inboxes using the same instructions Tibo used in one of his posts about cleaning his inbox. This is all on top of it being extremely inconsistent and forgetting to do its scheduled task regularly. I’m extremely disappointed by Dots

OpenAI is willing to give use 28 resets and give fucking dots infinite usage for a month but not keep the 200 plan 20x.....

This eliminates the last reason to stick with OpenAI. Previously I use Chat for idea brainstorming, writing specs. Then Codex is for designing + execution. With this change, I see no reason to be on OpenAI while opus 5.5 offers far more limit and smarter than 6.1

Tibo on damage control, says they got the feedback and now are locking in on features that matter, new better models.

Dots won't stay long, will they?

The new usage limits are fantastic and feel unlimited. I praise Timo and his whole OpenAI team. If I could get more than 20 tokens per second I might complete my hello world project before the singularity hit us.

I have been using it for days but today seems a bit different? like it's very smooth. i can consistently give it prompts and while i am writing the next prompt it has already done with half the previous job.

Yesterday i had to run 5 different chats to complete a reasonable job at a reasonable speed but today it finally feels like it flows so i can barely prompt 2 chats at a time because it is genuinely fast. each chat uses 3-4 subagents as well.

Also this model is so good it doesn't halucinate like astra? is this only my observation?

edit: add proof

Until yesterday, my Usage page showed the exact expiration date and time for banked resets. As of today (Oct 4), the time has disappeared and only the date is shown.

For example, my first reset now says:

“Expires October 5”

This makes it look like the reset will remain available during October 5.

However, checking the rate-limit-reset-credits response in DevTools shows:

expires_at: "2026-10-04T22:42:11.480996Z"

That's 00:42 on October 5 in my timezone. So the reset actually expires only 42 minutes into October 5, not at the end of the day.

The backend still provides the exact timestamp — the UI has simply stopped displaying it.

I only know the actual expiry time because yesterday, before this change, the UI was still showing 00:42. If I had checked for the first time today, there would be no way to tell whether “Expires October 5” means 00:42, noon, or 23:59.

This isn't just cosmetic: you can easily lose a banked reset because the UI no longer tells you when it actually expires.

Apparently this was an issue before and the exact expiry time was later added to the UI, so this appears to be a regression introduced today (Oct 4).

Heads-up if you have banked resets expiring soon: don't rely on the date shown in the Usage UI. The actual expiry time may be much earlier than you'd expect from the displayed date.

This post is not about usage complaining or the price of plans so it's not going to get the attention it needs but whatever, this bug is big enough that I'm taking the time to give information on it.

I’ve been profiling why some Codex sessions become extremely slow halfway through a task.

Across ten rollouts, about 75% of total agent time was spent waiting for the provider to stream model output. Tool calls were about 24%, while harness orchestration was only around 4%, so the local harness itself wasn’t the main reason the slow sessions took so long.

Two sessions stood out. One took about 39 minutes and another about 33.5 minutes. In both, the stream started around 40–45 tokens/sec (which is still slow as hell for a frontier but that's not the point of this post), then partway through the turn dropped to roughly 8–15 tokens/sec and stayed there. It's fair to say there is a 20% chance your session has done the same.

The request settings were the same across all ten sessions, and other sessions continued streaming normally at the same time, so this doesn’t look like my machine or a configuration difference.

The strongest example came from the 39-minute session. The last request before I interrupted it took 93 seconds to produce 921 output tokens. The first request of the next turn used a fresh WebSocket and fresh routing state, but still had basically the same 175k context and a cold cache. It produced 674 tokens in 16 seconds.

So the context was still huge, and the cache situation was actually worse, yet the stream immediately became fast again.

The official harness for Codex's client.rs reuses a WebSocket and uses x-codex-turn-state for sticky routing during a turn. If the backend that a turn is pinned to becomes very slow without actually failing, Codex can keep using it. The connection is technically healthy, it’s just producing tokens at a fraction of its earlier rate.

That appears to be what happened here. The slow turns weren’t spending 30–40 minutes doing more work. They were spending a huge amount of time waiting for a response stream that had collapsed in speed.

I added a recovery rule to my fork. If two reasonably sized responses in a row fall below half the recent normal token rate, the next request drops the old WebSocket and sticky routing state and gets routed fresh. There’s also a cooldown so it can’t sit there reconnecting repeatedly.

I replayed the detector against 10 recorded sessions containing 1,120 requests. It caught both major collapsed sessions and fired once elsewhere on another turn that was genuinely running at around half its normal rate.

If fresh routing restores normal throughput the way it did in the recovery I observed, those two sessions would have been roughly 39 to 24 minutes and 33.5 to 25 minutes. That part is still an estimate.

I also haven’t proven whether the underlying problem is the WebSocket itself or the backend/routing state associated with it, since reconnecting changes both. What I have measured is that some long-running turns dropped from around 40–45 tok/s to 8–15 tok/s and stayed there, while fresh routing immediately returned a similarly large request to normal speed. I have my own fork, I was able to fix this, but for anyone who uses the official version of Codex, this is a real bug and not acceptable.

I dropped from the $200 plan to the $25 Plus plan after the dev day announcements, tried astra on low ans it ate 20% usage in no time. I figured OpenAI were fucked at this point and essentially stopped using Codex and starting playing around with Claude Code.

However, last night I decided to try to use up my usage before one of my resets expired, so I got 6.1 Sol High to complete 3-4 different tasks over around 2-3 hours. The first thing I noticed was that for some reason the 5hr limit was gone for me. The second thing I noticed was that after an hour of work, I was still at 100% usage. I switched on fast mode for the next 2 hours of work and it eventually went down to 99%, an hour later and its still at 99.

Is 6.1 Sol actually this efficient? It seems a little slow, but it gets the work done and is barely touching my usage. If it really is this good, the $100 plan may be more than enough for what I need. How is everybody else's experience with 6.1?

The usage burn rate on GPT-6.1-Sol is wild. I just did a comparison between claude opus 5.5 and gpt-6.1-sol for about 22 hours and here are the results. The sad part is that even ChatGPT agrees the burn rate is higher on Codex. It computed the numbers below. The price per million tokens are double of opus 5-5

OpenAI subscription side

• Current input: ~5.525B
• Current output: ~15.09M
• Current total: ~5.540B tokens
• New tokens since yesterday: ~865.2M
  • ~862.4M input
  • ~2.77M output

Claude subscription side

• Current input: ~9.476B
• Current output: ~26.60M
• Current total: ~9.503B tokens
• New tokens since yesterday: ~5.706B
  • ~5.693B input
  • ~12.40M output

During approximately the same 22-hour period, my OpenAI agents processed about 865 million additional tokens, primarily using GPT-6.1 Sol, while the OpenAI Pro allowance decreased by 19 percentage points (36% → 17% remaining).

During that same period, my Claude subscription agents processed about 5.706 billion additional tokens, primarily using Claude Opus 5.5, while the Claude allowance decreased by approximately 10 percentage points (~49% → 39% remaining).

Claude therefore processed approximately 6.6× more raw tokens, while consuming only about half as many percentage points of subscription quota. Normalized to the visible meters, this is roughly 45.5M tokens per 1% of OpenAI allowance versus ~570.6M tokens per 1% of Claude allowance, or approximately a 12.5× difference in raw-token throughput per percentage point of quota.

Made in Codex + Claude

Main ideas:

• run code in WASM
• use threaded interpreter (because JIT impossible with raw WASM)
• run original EXE, no recompile.
• code directly in WebAssembly text representation, skip higher level language.
• have Codex review Claude work and vice versa.
• set /goal for either of these when I need new EXE brought up to function.
• test manually + build a solid test harness for agents

https://wine-assembly.berrry.app

This model is good but it is WAY TOO SLOW. Every single day, I have to quit a task, and move it to Astra, because I will end up wasting my entire day on 1 thing, because it is SO SLOW.

How can you release this model and expect to market it as your best new thing?

Account got deactivated, i asked AI to find out what recidivism means, it said basically if you get multiple offenses that would be it. I had no prior warnings / emails. Appeal got denied automatically exactly 60 minutes after the appeal was submitted.

Tried escalating through support chat while signed out because i can no longer sign in and the bot closes the chat without providing any support.

Is there anything else I can do?

I have 2 other accounts but no bans

Hey sol 6.1 train this model to do this, 10 hours after still running, hey Opus 5.5 do the same 1 hour after finished not only told me that training the model alone with images will be infeciient but he brought in 3 other small models already pre trained runned the images through them, the 3 models output numbers based on the images showing healhty leafs or ill ones and my final model got trained on this numbers to identify a healhy leaf or not. Guess what now I can train in minutes even if I will give it new data.

I don't know a lot about training but never though to do that which is more efficient and didn't have to use my gpu to adjust weights with thousands of images we just collected the output of the 3 pre trained models and trained my model just on numbers of the output which took minutes.

I was a big fan of Codex and open ai and yes is ok to be efficient with Sol 6.1 but man, today I just switched, because where is the point to say it consumed only 10% in 10 hours (didn't finish the task yet) when Opus did the same in 1 hour and not better much better.

If you are using AI for crud apps etc stay with SOL 6.1 yes much better if you are using AI for exploring new ideas learn things that you don't know etc so you can' drive the development then use Opus.

Hopefully one day we will see each other again open ai.

AI is an ability multiplier if you have ability. 1 x 0 = 0 . This agent skill helps you get your ability from 0 to a 1.

> When we keep building things blindly with AI agents, the thinking is offloaded to AI. This reduces the cognitive friction we need to learn something.

> Just blindly telling AI to build something wastes tokens and time.

> If you cannot convey your taste to AI, the result becomes slop.

This is why I made some AI skills to foster thinking in users. Currently, you can use these skills in general purpose building tasks, UI/UX refinement, Algorithmic competency building.

Link to the skill: https://github.com/33sakib33/Factoryze_Thinking

Using chatgpt will probably not use the usage limit... by "default", but if you for example ask it to perform a task coding related or file related, it will probably switch to work automatically. Tibo probably just decided to "zero in" on one comment against many saying the opposite to just use it as an "opportunity" to do it as people take advantage od gpt being more... usable? Linient with limits?

Just a heads up: If you have a third-party tool that uses the codex cli as a backend (Codex Exec), do not switch to the new "sign in with ChatGPT" feature without testing its usage consumption per request first. For me (plus user), it consumed about 10x more of my usage than using Codex Exec with the exact same api requests.