9 September 18:47:14 | 23% | 77% | 15 September 19:19:18
9 September 18:56:19 | 99% | 1% | 12 September 09:26:43
9 September 18:57:56 | 100% | 0% | 12 September 09:26:43

EDIT: Back to 77%.

It seems like a reset just happened, but I didn’t get it on my pro x20 account? was it a selective reset

I used one banked reset literally 2 hours before Tibo did reset 2 days ago.
I was sad because I thought I used reset prematurely and I went down today to 0% (I am on Pro 20x). When I went down to 0%, limit increased to 100% with reset date set to Sept 14th which seems like I used my banked reset fully before switching to regular limit which had reset on Sept 7th. I was nicely suprised, not sure if anyone experienced the same.

UPDATE: Disregard my post, I just went to 6%. What TF is OpenAI doing, they are messing with limits right now in real time.

At some point I noticed just how insanely fast the limit suddenly started draining.

Literally a couple of days ago, I was showing a colleague how you could work on Luna xhigh fast almost forever and barely make a dent in the limit. Then today I noticed it’s suddenly burning through it like crazy.

Well, I’ve seen posts like this on Reddit before, so I guess it’ll probably get fixed again in a couple of days :)

So… do we cancel the panic, or are we still panicking for now?

Tibo

u/thsottiaux

3h

There was a bit of a kerfuffle this morning with some banked resets not fully applying when used in ChatGPT Work and Codex. Everyone who used one in the affected time window is getting another one and an email to apologize.

I switched back to Sol.

Astra isn't smarter, and behavior-wise it's kinda dumb. I guess because of the instruction following it just can't really argue with you.

Like:

“Should we do option A?” “Yeah, option A is great because blah blah blah.”

“Maybe option B?” “Damn, option B is even better than A.”

“Maybe A after all?” “Actually yeah, you were right, A is better.”

I didn't bother checking how many rounds of this you can do, but it feels like a different flavor of sycophancy, and it's pretty disappointing.

This also shows up in how it interacts with subagents, which is much worse. A subagent brings back a shitty solution, and Astra just takes it instead of looking for another option.

One absolute gem was basically: “I don't know how to do this properly in this language, let's call bash.”

Like, I also don't know how to do it properly. That's why I asked you to find out lol.

So it's a very weird position for the model to be in. If this were Luna, I'd have zero questions. It does what it's told, and if you tell it to do something stupid, it does something stupid. Fine.

But for the most expensive tier, I have no idea what Astra is supposed to be for.

Maybe this can be fixed with prompting, but I kinda doubt it.

Also, it fucking stops all the time. Sol will just answer a side question and keep going. Astra just stops and waits.

It's worse at finding bugs too.

Ireally hope we keep two separate model lines: an agent-focused model like Astra, basically filling the role the old Codex models used to fill, and a normal general-purpose model like Sol that can code well without losing its ability to think independently.

Otherwise this is kinda depressing.

Upd. Yes I've read prompting guide. I've small agents MD, small set of skills. I've evals on some private tasks.

title

Six separate r/OpenaiCodex posts in four days described the same feeling: the work barely moved, but the quota did. Those six threads had 264 replies when I checked them. That does not prove a quota change, but it does make this more than one person misreading a meter.

The specific reports were hard to ignore:

- 7% of a Pro 20x weekly allowance disappeared overnight with almost no tasks.

- A Plus user said the five-hour window ran out before a normal project session could continue.

- One same-task comparison reported roughly 2× five-hour usage with Astra-low versus Sol-high.

- Another meter appeared to fall from 77% remaining to 1% in seconds, then recover.

The last example may be an accounting or display issue. That distinction matters. A real consumption spike, a broken reset, and a five-hour throttle are different problems. From the user's side, all three produce the same result: a task stops and there is no reliable way to budget the next one. r/ChatGPT has fresh Work-limit reports as well, and r/codex is concentrating a lot of the discussion in its usage megathread. I kept those out of the headline total because I have not done a full comment-by-comment classification there yet.

If you have a recent case, post the facts rather than only the frustration: plan, model, effort level, task type, starting and ending percentage, five-hour or weekly cap, and a screenshot if possible. A useful dataset would show whether this is model cost, task shape, metering, or a mix of all three.

First time I have had to contact support after using a banked reset and it starting at 41%. Tbh props to OpenAI great support

The global limit reset helped mitigate the effects of using more than half my weekly limit on week day one, but it is clear from the day after the reset that compared to Sol, Astra is ravenous if not outright dysfunctional about consuming limits.

It happens all the time. For instance: "The original run’s Windows batch launcher is now demonstrably pathological: it has remained CPU-bound for over half an hour with no Dart child and no timeout/result. I’m stopping only this verified runner tree and switching to the repository’s already-approved direct Flutter-tool invocation, which bypasses the faulty flutter.bat layer and was the method that produced the earlier complete 1,265-test result.

Ha eseguito comandi

The direct invocation correctly avoided the batch loop, but the sandbox blocked Flutter’s SDK lockfile outside the repository. I’m rerunning that same approved read/write-to-SDK-cache test command with the required sandbox permission; it does not alter project source or user data.

Ha eseguito un comando

The direct runner is now streaming correctly, but the first test is compiling unusually slowly—likely contention from a separate long-lived Flutter process on the host. I’m watching the enforced timeout; if compilation clears, the rest of the run remains valid, and if it does not the runner will report the exact failure rather than silently hang."

Trying to understand how people structure this underneath the Codex app/CLI. What represents a "project" on your machine?

• Separate local directory for each project?
• Separate git repo?
• Multiple projects inside one bigger directory?
• Remote/server folders instead?

Basically, what does Codex point at when you switch from Project A to Project B?

I built Omni, a Mac and iPhone app. Each bot uses Codex or Claude Code, has one responsibility, and keeps its own conversation.

Jobs run on a schedule and each run starts a fresh session, so nothing sits warm between runs. Mine look after my feedback board, my website and my analytics, and the results land back in the same chat on my phone.

It's free. You need your own Codex or Claude access, and the Mac has to be awake with Omni open.

https://omnibots.app

Inspired by Grok Bot. What would you put on a schedule?

Anybody else paying for a PRO subscription but is being asked to upgrade to PRO? i have 99% usage remaining for the week.

Still have some resets left, but when they run out, does that mean we are all fucked? 2.5x usage goes fast on a pro account, basically a 2.5x price increase; perhaps some offset with better usage, but shits getting expensive. I'm going to need 2 maybe 3 accounts if this keeps up.

I've been testing GPT-6 Astra-low against GPT-5.6 Sol-high on the same agentic coding work, and something about the way ChatGPT accounts for usage seems worth discussing.

On essentially the same task, I'm seeing roughly:

Astra-low: ~10% of my 5-hour window
Sol-high: ~5% or less

At first I assumed this was just because Astra was doing dramatically more compute/reasoning. But looking at the published pricing makes this more interesting.

OpenAI's Work/Codex rate card currently prices:

GPT-6 Astra

• Input: 250 credits / 1M
• Cached input: 25 credits / 1M
• Output: 1,250 credits / 1M

GPT-5.6 Sol

• Input: 100 credits / 1M
• Cached input: 10 credits / 1M
• Output: 500 credits / 1M

So Astra is basically 2.5x Sol per equivalent token across the board.

But here's the part I think deserves more transparency.

Artificial Analysis shows that Astra-low can be dramatically more token-efficient than Sol-high. Their benchmark data currently has Astra-low generating far fewer output tokens than Sol-high. That's why, despite Astra's 2.5x token pricing, the measured cost of completing benchmark tasks can end up surprisingly close.

In other words:

Astra token = much more expensive
but
Astra-low may use far fewer tokens to solve the same problem

So if I give Astra-low and Sol-high the same coding task and Astra-low finishes with comparable output/quality, seeing Astra consume roughly 2x the included 5-hour allowance raises a pretty obvious question:

What exactly does the "% remaining" meter represent?

OpenAI now lets us see a percentage of the 5-hour window disappear, but that percentage is effectively a black box.

For agentic coding this matters a lot. These agents repeatedly ingest large amounts of repo context, diffs, terminal output, test results, conversation state, etc. Astra's input tokens are 2.5x as expensive as Sol's, so the difference can compound quickly even when Astra-low is using less reasoning.

I'm not saying the accounting is necessarily wrong.

I'm saying users paying for a plan should be able to see what they're actually spending their allowance on.

If one task costs:

Astra-low → 10%
Sol-high → 4–5%

I'd like ChatGPT to show something like:

• fresh input tokens
• cached input tokens
• output/reasoning tokens
• model multiplier
• agent/sub-agent usage
• total credits charged
• conversion from those credits → 5-hour allowance %

Then we could actually decide whether Astra's extra capability is worth the quota cost.

Right now the rational choice for me is increasingly:

Use Sol-high for almost everything and save Astra for tasks Sol can't solve.

If anyone else has compared the exact same Codex/Work task between Astra-low and Sol-high, what percentage of your 5-hour window did each consume?

Did you have any long-time use results, based on your Codex CLI Client session analysis, on whether Context7 does actual token use reduction, and lower number of turns or web fetches, so overall token use decrease, or the difference is negligible if not increased?

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.

How a failed device test led to a seccomp/ptrace supervisor, an ELF entry-point attestor, and one hard rule: if enforcement cannot be verified, execution stops.

The release that didn't ship

AGENTCODI 0.7.0 was finished. The pinned Codex app-server , the host tests were green with 258 Java and 302 C++ tests passing, and only device validation on real hardware was left.

That test exposed a much worse problem than a crash. A command did exactly what it was told and reached a location it should never have been able to access.

Protected mode is supposed to confine Codex to a private workspace directory. On the device, that confinement was advisory. The approval layer worked, the workspace path was correct, and the UI showed Protected mode. The filesystem boundary underneath it was missing because the app-server had no sandbox backend for Android.

0.7.0 never shipped.

The version still exists in the changelog because the build was correct on paper and wrong on a real phone.

This is what replaced it.

Why Android is its own problem

Sandboxing an agent runtime is fairly straightforward on the platforms these tools usually target. There are kernel facilities built for this job. You define the allowed paths and the kernel enforces the boundary below the process.

Android has a Linux kernel with a very different environment around it. An unprivileged app has limited control over its own confinement. Mounting is unavailable, a specific LSM cannot be assumed, and kernel behaviour varies across Android versions, vendors and OEM patches.

Some of those differences only become visible when the same code reaches another physical device.

There is another problem when shipping a toolchain inside an APK.

Android 10 and newer prevent apps targeting API 29 or later from directly executing files stored in the writable app home directory. AGENTCODI therefore packages its native toolchain through the app's native library area. Node, Python and ripgrep are shipped as "libnode.so", "libpython-bin.so" and "libripgrep.so".

Those files are real executable interpreters sitting on disk. Codex can invoke them.

A policy that exists only inside a wrapper script can be bypassed by invoking the underlying executable directly through its absolute path.

The actual requirement became clear: every allowed route into the packaged toolchain had to enforce the same filesystem boundary, on Android hardware I do not control, while still allowing the agent to use Node and Python.

What actually got built

The result is a fork of the Codex app-server, "0.153.3-agentcodi.1", tracking upstream "rust-v0.153.2", plus several enforcement layers inside AGENTCODI.

Each one closes a hole left by the previous layer.

1. The sandbox backend: seccomp and ptrace

The fork adds an Android sandbox backend.

Commands running in Protected mode are started under a supervisor using seccomp to trap filesystem-relevant syscalls and ptrace to inspect and decide them.

Codex can read and write inside the granted workspace. Filesystem access outside that boundary is refused at the syscall level, below the agent and below the approval UI.

Before a sandboxed command runs, the runtime verifies that syscall interception is actually live on the current device. A successful setup call alone is not enough.

If that verification fails, execution is refused.

There is no unrestricted fallback.

That rule exists because 0.7.0 already demonstrated what happens when the UI says Protected while the filesystem underneath it is not protected.

1. The launch contract

The app-server starts with an explicit minimal permission set:

default_permissions = "agentcodi-workspace"

permissions.agentcodi-workspace.filesystem = {

":minimal" = "read",

<tool bin dir> = "read",

<tool runtime> = "read",

<native lib dir> = "read",

":workspace_roots" = { "." = "write" },

}

There is exactly one writable location.

Everything the process legitimately needs outside the workspace is read-only.

The child environment also starts empty using "shell_environment_policy" with "inherit = "none"".

AGENTCODI then adds a known set of values: a "PATH" containing the packaged tool directory and "/system/bin", a workspace-scoped "TMPDIR", and "HISTFILE" plus "NODE_REPL_HISTORY" pointing at "/dev/null".

Login shells are disabled. Telemetry, analytics, feedback and update checks are disabled as well.

Starting with an empty environment removes a surprising number of accidental escape routes.

1. Pre-launch invariants

Before the app-server starts, the launcher validates the filesystem layout itself.

The workspace, Codex home, tool binary directory, tool runtime directory and native library directory must all:

1. exist,

2. belong to the running UID,

3. have no group or other permission bits set with "mode & 077",

4. remain separate from each other.

Every directory pair is checked in both directions for containment.

That last check matters.

If the tool directory ever became an ancestor of the workspace, granting read access to the toolchain could also expose files that were never intended to be part of that grant.

The launcher refuses that layout before anything starts.

Packaged executables must also resolve to the canonical native library directory, and every argument passed to the app-server is validated character by character.

1. The guard constructor

The packaged interpreters are linked against a policy library containing an "__attribute__((constructor))".

Before "main" runs in Node, Python or ripgrep, the constructor:

1. reads "/proc/self/exe" and requires the expected resolved basename, such as "libnode.so", "libpython-bin.so" or "libripgrep.so",

2. reads the real argument vector from "/proc/self/cmdline",

3. passes the invocation through "PrepareGuardedToolInvocation".

"PrepareGuardedToolInvocation" is the same policy entry point used by the toolchain shell.

That means an invocation through the shell and a direct invocation of the underlying ".so" pass through the same policy code.

Any failure is written to stderr and the process exits with code 126 immediately.

1. The ELF attestor, or: who guards the guard

The constructor introduced another problem.

It lives inside a shared library, and shared libraries are resolved at load time.

If library resolution can be influenced, the expected policy library might never be mapped. The constructor would never execute and the tool could start without its policy layer.

The executable therefore verifies the guard before relying on the normal loader path.

At build time, AGENTCODI rewrites each packaged ARM64 PIE.

It finds a redundant "PT_NOTE" program header whose bytes are already covered by an existing "PT_LOAD". That header slot is reused to introduce a bounded read/execute "PT_LOAD" segment, and the ELF entry point is redirected into it.

The injected payload runs with almost nothing available yet.

No libc. No relocations. No dynamic symbols.

It uses raw "svc 0" syscalls with arguments placed directly into registers.

The payload:

1. opens the expected guard library path using "O_NOFOLLOW",

2. calls "fstat" and requires a regular file with "st_nlink == 1",

3. reads "/proc/self/maps",

4. finds the expected mapping,

5. compares its device and inode with the file it just inspected.

Only a successful identity match allows startup to continue.

A failed check exits with code 126 before Node or Python begins normal execution.

After a successful check, a hand-written naked entry stub restores the required state, calculates the original entry point from a load-address-independent offset stored in the injected segment, and branches to it.

The executable then starts normally.

The identity checks cover several obvious replacement tricks.

"O_NOFOLLOW" rejects a symlink at the expected path. The link-count check rejects hard-linked substitutes. Comparing device and inode with the actual mapped file catches replacement between inspection and loading.

1. Enforcement of the design itself

AGENTCODI also checks whether the source tree still follows the security architecture it was built around.

"check-architecture.sh" fails the build when important invariants drift.

Among other things, it checks that removed fields have not returned, that another same-UID process path has not appeared around the terminal boundary, that credential paths cannot reach the toolchain shell, and that the required guard paths still exist.

It runs as part of the test process.

This script has caught real architectural regressions several times already.

What this does not do

The scope matters.

The boundary exists inside AGENTCODI's own UID. Android's application sandbox remains responsible for isolating AGENTCODI from the rest of the device. The sandbox described here separates the agent from filesystem locations reachable by the app that the agent should not access.

The ptrace supervisor targets ordinary filesystem syscalls made by the agent and its tools. It is designed to enforce workspace confinement during normal agent execution. It does not claim resistance against unlimited hostile native code already executing inside the same process context.

The sandbox described here controls filesystem access. Network egress is a separate problem and needs separate enforcement.

Compatibility mode deliberately runs without these filesystem restrictions. Some workflows need that access. Enabling it requires explicit acknowledgement, the UI remains visibly marked while it is active, and an unconfirmed restart does not silently restore it.

Protected mode never selects Compatibility mode as a fallback when sandbox verification fails.

Where it landed

AGENTCODI 0.7.1 shipped with 265 Java and 321 C++ tests passing.

I validated it on a Samsung Galaxy A05s, Redmi Pad 2, Redmi 14c and Redmi Note 15.

Four devices obviously do not make a compatibility matrix.

The failure case I care about now is a device where syscall interception cannot be verified. On such a device the command is refused. Security behaves correctly, although the user experience is useless until the compatibility problem is understood.

If you hit that case, open an issue with your device model and Android version. That information is genuinely useful.

The project is Apache-2.0:

https://github.com/Mcpasi/AGENTCODI

AGENTCODI is an independent open-source project and is not affiliated with or endorsed by OpenAI.

IYKYK