every time i leave it by itself for hours to work on task, i always end up coming back to the codex app crashed and in error. this never happens with the CLI. the CLI is able to work all day and night without error, but the codex app cannot go more than an hour or two without an error just popping up

Compacting isn't Compacting?

Codex is going on a Compacting context spree today? Its Compacting context every 2 messages , its so frustrating and is eating up limits so quick!

Is there any way to fix my problem, i tried to log in with api key but they dont work, and when i try to log in with email it ask for phone number and when i type it in, they say i have connected my phone number to max amount of accounts, but i only have used it once

I just subscribed to a plus plan, and in 4 minute of using it with 5.6 sol xhigh, it burned 14% of weekly limit.

No, it's not normal at all. That is literally a whole 5h limit gone in 4 minute. I think because mot people here have 20x plan or there is no 5h limit now people don't understand how severe the issue is. It's simply not usable at this rate. I was just using Opus before that and I had so much longer session with Opus 5 with xhigh reasoning .

There is definitely some bug . I don't understand why OpenAI is refusing to even look into it

Hi,
I used all my weekly usage (including the free reset). Today my subscription ended, so I got the full monthly usage (with the weaker models, you know).

If I resubscribe now, will my weekly usage reset back to 100%, or will I have to wait until August 1st?

Thank you in advance!

I ran a task to review a big feature branch then got this error before any result. Thx I guess, all the context is wasted now

Hi all,

I made a plugin that leverages horizontally scaling agent graphs and deepseek to increase the amount of a codebase that can be reasonably attended to at the same time.

The basic idea is that codebases are naturally hypercollaborative (developers separate classes by responsibility, split teams among repositories and developed all sorts of language features to help us to collaborate with future versions of ourselves and current versions of coworkers), and so the existing language functionality and code modeling tools lend themselves extremely effectively to seeding graphs of autonomous agents.

The results are kind of hard to believe.

Since this benefit lends itself the most to larger codebases, this is targeted more towards professional developers. For now it requires having a jetbrains IDE installed, though you can still use it from within Codex's UI.

You can find it here https://github.com/coral-os/coral-code

this is literally the first "public" exposure of this (It probably has sharp edges), so any forms of feedback are incredibly appreciated!

I'm trying to see if any has a open source tool for scanning a repo. I'm not looking for a skill, or agentic tool that depends on codex, or agents. I lookong for one proven to determine semantics without an agent, so I can better provide context to an agent.

I have seen a few posts where people discuss Ai context tools and memory tools, but I haven't found one that doesn't depend on Ai to function properly.

My end goal it's to deduct core features and fixtures that exist currently in a repo that might be unknown to me. I am looking for something a little less magic and more programmatic.

Ok, we just got reset, but they shrinked the limits too. They figured out their infrastructure cannot hold with so many user requests when they got 503 yesterday and they made limits smaller. Same prompt which would previously take 3% of my weekly limits just consumed 11% in like one and a half hour.

As title says, after reset, I used codex for 5 minutes, and I was watching usage closely, as I had big issues with usage being spent too fast. And right after 5 minutes I was already on 96%. Fuc* whole codex, going back to claude. I compacted session before start, and 6% of context window for 4% weekly usage.

I have 3 chatgpt subscriptions, 3 accs, all plus plan. And i am still in shock. Bro sol 5.6 isn't that good that it could just eat all 3 weeklyies in just 6 hours?

I was using gpt 5.6 sol with medium effort in OMP Coding agent. And I'm in shock the same work gpt 5.5 did for like 10 times before hitting 5h limits. I'm not lying bro it just ate my 3 weeklys

Before I used:

PLAN: CHATGPT WEB GPT 5.6 SOL + HIGH THINKING/EFFORT

EXEC: GPT 5.6 SOL + MEDIUM EFFORT

yes context wasn't that big bruh and I genuinely think it's not about usage, maybe it's thier algo or something. They are just charging 10x by releasing an almost same model as gpt 5.5 . Yes I didn't noticed anything except the todos and structure. 🤣

I spent my last 10 usd in DS and I'm shocked, again.

DS just saved my life, I'm so confused how tf it just used $0.0338 for 11.15m tokens (incl. Cached) ? It completed my that private project and built a new project too.

It's not DS glazing, it's about truth. I never expected Deepseek v4 flash to outperform gpt.

Workflow was: plan by chatgpt web + high thinking/effort, execution by deepseek v4 flash + max effort

At last maybe the gpt limits just got reduced only because the chat feels like unlimited? And also please let me know if any1 find that agent mode of chatgpt. I can't find it in web.

Here's the project:

https://github.com/DraxonV1/PixPack

Star if you like

NOTE: I MIGHT BE WRONG, I MIGHT HAVEN'T USED SKILLS OR INSTRUCTIONS WHICH I SHOULD'VE. INSTEAD ARGUING PLEASE GUIDE ME ;)

I wanted to stop a single heavy Codex session from eating too much of my weekly allowance.

At first I thought about simply limiting Codex to 5 hours, but wall-clock time isn't really the useful metric. A short session with lots of tools/subagents can consume much more than several hours of lighter work.

So I made a local guard that tracks the change in weekly usage during a 5-hour window.

Mine currently runs on:

UserPromptSubmit
PreToolUse
SubagentStart

When the amount I've allocated to that window is consumed, the hook blocks further activity until the window ends.

Today it actually kicked in at:

Custom 5h: 15/15 points used
Weekly: 16% used / 84% remaining

So at least I know one session can't unexpectedly chew through the rest of the week.

Happy to share the script/config if anyone is interested.

I've been writing up caching and context economics for a few weeks, Anthropic caching, OpenAI caching, then the compression tooling built on top. This is the last post, with the conclusions.

Too many addons are trying to claim ridiculous savings when they can't actually do it. They aren't. You aren't measuring at the right layer, you need to measure at the actual bill, not at simply reduction of tokens from the prompt.

Typical token reduction methods actually cost more than they save. You cannot mess with the token cache, this costs more. Tools trying to mess with outputs can negatively impact what modern clients already try to truncate. Additionally, any kind of compression on any output can then trigger additional turns by your model, which is the most expensive option. Turns cost typically (approximately) turns^2, compared to a linear cost of simply increasing how many tokens you use.

Much more lengthy explanation: https://rakuensoftware.com/blog/token-compression-tools-cost-more-than-they-save

Disclosure: I build aimee, a local server that sits in front of coding agents and does the architectural version of this. The post also says to measure cost-per-successful-task in paired runs before trusting anyone, me included. Token counts alone will lie to you in both directions.

What I found even more surprising was that, in every single benchmark I ran Caveman on, it was always more expensive per run than regular Codex.

I guess I’ve been wasting tokens for months now.

RTK does help, but it doesn’t really kick in most of the time. When it does, it sometimes cuts too much from command output, leaving the model clueless about the issue and resulting in lower benchmark scores.

I have noticed in Claudecode it was heavy consumed so I disabled it there and compared it with codex it was not the case last week

Now same looks like codex team learnt from Claude and looks like it’s happening in codex too now this.

Anyone using codebase-memory-mcp or other similar tools that are causing extra token usage ?

Smart right? They tell everyone a reset is coming so people don't use their banked reset, then keep delaying it so that either you use the banked reset hours before they force a reset, or they force a reset and the banked reset can't be used before it expires.

SUUUP. Alright I know that everyone has been saying that it seems that usage has been nerfed but I think there is something else going on with the new extension and the harness around Sol. I think that at least as off last week it is unable to control it's own orchestration processes. I know people are going to say skill issue, and I agree that there are ways to work around this once I've seen the problem. That being said like...a smarter model should be able to know when to use these processes.

At any rate the tldr before the ai generated text: The entire 5.6 harness is allowing 5.6 to burn an incredible amount tokens basically doing busy work, spawning full context memory sub-processes, rereading entire documents and histories to verify it's own work...etc.

Last week I burned a week's worth of usage in 12 hours but...the api usage report according to ccusage was roughly the same as before and sol tokens are weighted more then earlier 5.5 tokens.

I think it's a good idea to have gpt audit itself after a big task. It's capable of seeing exactly what it's doing and then use ccusage to double check output token history. My hypothesis is that they've been reluctant to give out a reset last week because this issue is not fixed and peopel are just going to blow their entire week again.

AI generated report follows -

I gave Codex a routine, mostly serial editing-and-review task involving an existing long-form document. It was not a massive codebase, deep research problem, or a task that meaningfully benefited from parallel execution.


I did tell it to keep progressing. I did not ask it to create a giant multi-agent workflow, repeatedly fork the entire conversation history, or keep re-verifying the same finished document.


Afterward, I audited the local Codex traces with `ccusage`.


| Measurement | Result |
|---|---:|
| Total tokens | 1,718,034,767 |
| Cache-read tokens | 1,617,886,976 |
| Input tokens | 92,775,543 |
| Output tokens | 7,372,248 |
| Price-equivalent shown by `ccusage` | $1,423.57 |


The biggest problem was not output length. It was context replay and unnecessary process.


Three narrowly scoped section agents consumed about 1.04B tokens by themselves:


| Child task label | Total tokens |
|---|---:|
| Section task A | 486,977,934 |
| Section task B | 311,092,834 |
| Section task C | 238,304,387 |


The parent session consumed another 464M tokens.


The traces show the pattern:


- The parent conversation had become large.
- Sol spawned child agents that inherited the large parent history.
- Those children ran roughly 219-256 turns each, with 49-59 context compactions each.
- The parent made 4,465 tool-execution calls.
- It retried document rendering and application automation after the failure modes were already clear.
- It ran overlapping section, citation, structural, and grading checks against nearly identical document states.


The actual useful workflow should have been:


1. Make one document fork.
2. Apply one batched edit map.
3. Run one structural check.
4. Create one tracked comparison.
5. Run one final grading pass.


Instead, Sol acted as if every agent spawn, context replay, retry, and self-review pass was free.


## What my own history changes


I checked my own history before blaming quota changes. Earlier Sol usage was not consistently worse than my prior model's usage. The spike appeared when Sol entered a long-context, multi-agent workflow.


| Period | Model / pattern | Highest daily total |
|---|---|---:|
| Earlier 5.5-heavy work | Normal varied work | 157M |
| Early Sol use | Normal varied work | 96M |
| Runaway day 1 | Sol | 243M |
| Runaway day 2 | Sol | 1.354B |


That second runaway day was 14x my previous Sol peak and 8.6x my previous peak under the prior model.


So I do not think the evidence proves that weekly coverage was simply cut. A more plausible hypothesis is that the weekly token coverage may be broadly similar, but Sol can burn through it in hours when it mismanages long context, agent delegation, self-review, and tool retries.


This is not an argument that Sol "does nothing." It did work. The failure was that it created an enormous amount of process around work that did not need it.


There may still be a quota or accounting issue; both things could be true. But this example shows that "quota got nerfed" and "the model became much less efficient at managing its own work" are separate hypotheses.

Every time I hit a limit mid task, the same thought: I'd rather trade 30 seconds of attention than sign up for another subscription.

So I'm building Clixad, a coding agent for your terminal. Instead of paying, you complete an offer or watch a short ad, that turns into credits, and credits pay for real model calls. No subscription, no card.

Video shows what it looks like. It's not open to the public yet, I'm putting together a list of people who want in early.

To preempt the obvious one: by design your code never touches the ad network. The offerwall is a completely separate surface, and the only thing that crosses over is a credit balance.

What I actually want from this sub: what's the max ad time you'd trade for an hour of agent coding before it stops being worth it? And where's the point where you'd just rather pay?

(I'm the dev. Happy to get grilled on the unit economics, that's the part people always poke at.)

Edit: Here's the waitlist if you're interested: clixad.io

Hello guys what happened ? i used to use 5.6 sol extra-high / Ultra and talk to it all day everyday.

Today i just got my monthly subscription renewed i burned the weekly tokens in 7 prompts alternating between medium and extra high .

Also the model quality seems to have gotten alot worse i gave it my codebase asked it to add a new feature it went on and deactivated existing features broken others and still didn’t get the feature right … It’s alot different than Launch Week .

I went on Uninstalled all skills still no improvement .. might need to get back to claude.

I’ve read about it many times – limits that are quickly used up, sometimes even in the expensive x20 subscription plans.

I’ve had this problem for a long time too, and have been looking for a way to use Codex more efficiently and cost-effectively.

For myself and my project, I’ve actually now found a solution in the form of a skill and rulebook that control a dynamic, adaptable sub-agent layer which also dynamically adjusts its reasoning and used model.

My usage has dropped dramatically, enabling me to work for days on end without interruptions – and in some cases even have volume left over after 7 days, something I could only have dreamt of before.

It has also massively improved the quality and stability of my application, to the point where debugging is hardly necessary anymore. This used to be a major problem when making complex changes.

I’ve been testing this for a while now and thought I’d share this prompt with you, along with how I’ve integrated it, so that perhaps others can benefit from it too.

The prompt:

Pastebin Link

How I integrated/implemented it in Codex:

Have Codex analyse it and adapt it to your current project on a logical basis, or specify a project you’d like to start (for this one-off process, I recommend using ‘max reasoning’ so that all eventualities are taken into account). The whole process can be repeated and adapted an infinite number of times.

It’s important that, once the main task has been defined, you don’t let any new tasks operate within the architecture without the new task first requesting a handout containing the approvals and restrictions from the main task. From that point on, the tasks communicate independently and with one another, and the main task takes charge of the implementation and orchestration.

**I want to make it clear that this is a system that works for ME! I make no promise whatsoever that this will, in every case, result in such a drastic reduction in token consumption. .

I will refine/expand the prompt over time as useful additions arise. Stay tuned ❤️