Subagent feature: Launching concurrent subagents instantly drains entire Pro plan usage quota

The subagent feature is still under development, but you should assume that even in its final form, it will consume tokens much faster than a single agent. The consumption rate should scale roughly linearly with the number of concurrent agents. You'll need to decide whether that additional consumption is worth it for your personal use cases. If you require additional capacity beyond what's included in your subscription, we recently added the ability to purchase additional credits.

Thanks for the response, but I want to clarify the issue more precisely.

I understand subagents consume tokens faster and that consumption should scale roughly linearly with the number of concurrent agents. That's expected.

However, what I experienced is not linear scaling - it's instant, disproportionate consumption:

• With 1 agent on xhigh: I can work uninterrupted for the full 5-hour Pro limit
• With 8 subagents: The entire 5-hour quota was drained within ~1 minute of launching them

If it were truly linear scaling, 8 agents should give me roughly 37 minutes (5 hours ÷ 8) of usage, not 1 minute. The consumption upon subagent launch appears to be exponential or there's a metering bug causing massive over-billing at spawn time.

I previously used a hand rolled Codex sub agent swarm tool that typically ran 5 to 8 codex agents in parallel. I got used to the linear increase in consumption. I also noticed that native Codex sub-agents could burn through the same plan percentage faster, much faster, like an order of magnitude. If it helps, here's a recent thread ID (not the one where I burned a ton of tokens, but some) 019be876-e799-79f0-8b32-70345919d7c5 (this session also had exceeded retry limit, last status: 429 Too Many Requests, request id: 9c25e1bf387d437a-EWR

To get a sense, all the Exec usage here on a Pro plan was previous Codex "sub agents", and I too thought something was wrong because the native versions burned through tokens so much faster. I'd run some tests, but I don't want to accidentally use up half the weekly quota - as noted, it jumps up almost all at once.

<img width="1079" height="322" alt="Image" src="https://github.com/user-attachments/assets/44c0802a-2e8c-4990-97f9-15c7fce0842d" />

Hello, I am experiencing a similar issue that started occurring after updating to v0.89.0.

Observations:

• Platform: Apple Mac Mini M4 - Darwin 25.3.0 arm64 arm
• Terminal: Interactive zsh session Version 2.15 (466)
• Defined reasoning effort in global config.toml is being ignored and defaulting to medium
• 100% of 5 hour usage(Pro Plan) limit exhausted within 20 - 30 seconds after spawning 12 agents
• error message: exceeded retry limit, last status: 429 Too Many Requests, request id: 9c2611d628b8aadd-SYD
• thread ID: 019bea0d-8b90-7ec3-9a59-f12aab6af0b2

@https://github.com/openai/codex/issues/9763#issuecomment-3789833719

Same here, thread ID: 019beb2d-581f-75d2-9098-f086007c2ec1

我也遇到同样的问题，帖子 ID：019beb2d-581f-75d2-9098-f086007c2ec1

Pro plan users are treated like dogs; I also have a Plus account where the consumption using a sub-agent is normal.

I experienced this as well drained most of my weekly allowance too and I was only using "high" reasoning. In my opinion releasing an experimental feature should have a fixed impact on usage to prevent bugs from draining your allowance. Now i'll be out completely one day into my weekly budget. The cherry on top was they didn't even complete their tasks because a 429 error caused them all to have an error. So usage gone and nothing gained.

To be clear, this feature hasn't been released as "experimental" yet. It's still under active development. I know there's a lot of excitement about this feature, but be aware that if you use it at this stage, you will almost definitely hit bugs or rough edges. We'll document and announce when it's released for experimental use.

We've looked into the issue reported in this thread. The error you're seeing here is not the normal "usage limit hit" error. You're hitting a different rate limiter that is (presumably) in place to mitigate DDOS attacks. Users with pro subscriptions have priority request processing and more throughput. That probably explains why you're seeing this error with pro accounts but not with plus accounts.

We'll need to investigate further, and we'll make sure to get this fixed prior to releasing the feature. Thanks for reporting!

To be clear, this feature hasn't been released as "experimental" yet. It's still under active development. I know there's a lot of excitement about this feature, but be aware that if you use it at this stage, you will almost definitely hit bugs or rough edges. We'll document and announce when it's released for experimental use. We've looked into the issue reported in this thread. The error you're seeing here is not the normal "usage limit hit" error. You're hitting a different rate limiter that is (presumably) in place to mitigate DDOS attacks. Users with pro subscriptions have priority request processing and more throughput. That probably explains why you're seeing this error with pro accounts but not with plus accounts. We'll need to investigate further, and we'll make sure to get this fixed this prior to releasing the feature. Thanks for reporting!

"steer conversation" is also listed in the "experimental" section and promoted on X by the codex team. How is one supposed to differentiate between "experimental" ( but not really experimental and under heavy development ) vs "experimental" ( released for experimentation not under heavy development )?

Yep, it drains accounts instantly which would have lasted for hours, even with multiple manual agents.

What i observed is, that the host agent constantly spams the child agent with calls. Each time the child agent is called, the child agent doubles its requests/sec

How is one supposed to differentiate between "experimental" ( but not really experimental and under heavy development ) vs "experimental" ( released for experimentation not under heavy development )?

Fair question given that both of these feature show up in the "Experimental" menu. We're admittedly not as disciplined as we should be with this distinction.

If someone from the Codex team is talking about a feature on X, it's safe to say that we've announced it and we're inviting users to give it a try. To my knowledge, we haven't made any announcements about the collab (multi-agent) feature yet. We'll make noise about it when it's ready.

> How is one supposed to differentiate between "experimental" ( but not really experimental and under heavy development ) vs "experimental" ( released for experimentation not under heavy development )? Fair question given that both of these feature show up in the "Experimental" menu. We're admittedly not as disciplined as we should be with this distinction. If someone from the Codex team is talking about a feature on X, it's safe to say that we've announced it and we're inviting users to give it a try. To my knowledge, we haven't made any announcements about the collab (multi-agent) feature yet. We'll make noise about it when it's ready.

My advice would be to drop the “experimental” label and use the more familiar “alpha” and “beta” tags. Those set expectations much more clearly. If this were labeled “alpha,” I’d fully expect this kind of bug.

As it stands, I’m now out of usage with five days left before it resets, and to make matters worse I’ll be stuck inside with a foot of snow 😅. That said, my frustration is actually a compliment. You all are doing an excellent job, and I’ve clearly become a Codex junkie. Fingers crossed I don’t start experiencing withdrawal symptoms.

The sad part is that it's likely all of the developers on codex have unlimited usage, which is why such an obvious bug like this one went unnoticed.

> > 如何区分“实验性”（但并非真正意义上的实验性，仍在深入开发中）和“实验性”（发布用于实验，但尚未深入开发）？ > > > 这个问题问得好，因为这两项功能都出现在“实验性”菜单中。我们承认，在区分这两项功能方面，我们做得还不够严谨。 > 如果 Codex 团队的成员在谈论 X 上的某个功能，那可以肯定地说，我们已经正式发布了该功能，并邀请用户试用。据我所知，我们目前还没有发布任何关于协作（多代理）功能的公告。该功能准备就绪后，我们会发布相关消息。 我的建议是去掉“实验性”标签，改用更常见的“alpha”和“beta”标签。这些标签能更清晰地传达预期。如果标记为“alpha”，出现这种bug我完全可以预料到。 目前的情况是，我的使用期限只剩五天了，之后就会重置，更糟糕的是，我还要被困在屋里，外面积雪一英尺厚😅。不过，我的这种沮丧其实是一种赞美。你们做得非常出色，我已经彻底成了Codex的忠实用户。但愿我不会出现戒断反应。

good+1

My weekly limit also went down 30-35% in 2 hrs in pro subscription 😐

I can't share the traces without some redacting I don't have time to review RN (not paranoia as much as legal obligation), but I have experienced similarly and from tapping the tracing, I'm suspecting a lot might have to do with the, by nature, lack of opportunities to leverage prompt caching in concurrent sessions, which would explain the lack of linear scale and seems to in my use case.

I had the same problem, when use multi-agents to work with mcp. I launched 6 agents, and within five minutes, 80% of the five-hour limit and 30-35% of the weekly limit were used up. As a result, the work was not done. Don't add such features if you have such problems. Or at least warn us. @etraut-openai

I will be a counter point to this: we frequently use things via API and the
cost ultimately is usually lower in the end than doing the work stretched
over days or weeks.

I’m not suggesting you’re wrong @laurentzius but that there are many use
cases and users out there for which I would say they also should listen and
consider and just because this is not yours doesn’t mean they should not
innovate.

And, it’s experimental: that’s very heavily warned. Don’t enable
experimental features of this isn’t the outcome you can accept without
becoming obstinate.

On Sat, Jan 24, 2026 at 14:00 Hakon @.***> wrote:

Laurentzius left a comment (openai/codex#9748) <https://github.com/openai/codex/issues/9748#issuecomment-3795505134> I had the same problem, so I decided to use multi-agents to work with mcp. I launched six agents, and within five minutes, 80% of the five-hour limit and 30-35% of the weekly limit were used up. As a result, the work was not done. Don't add such features if you have such problems. Or at least warn us. — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/9748#issuecomment-3795505134>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI2QVZ5M57ENWKRAOMP2L34IPMOHAVCNFSM6AAAAACSUGBQZ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOOJVGUYDKMJTGQ> . You are receiving this because you commented.Message ID: @.***>

I had the same problem, so I decided to use multi-agents to work with mcp. I launched six agents, and within five minutes, 80% of the five-hour limit and 30-35% of the weekly limit were used up. As a result, the work was not done. Don't add such features if you have such problems. Or at least warn us. @etraut-openai

The issue isn’t the feature itself or the bug we ran into, it’s the user experience. We’ve been using features like “shell snapshot” and “background terminal” that have been labeled experimental for months and actively promoted by the team. Because of that, I assumed “experimental” meant something closer to a release candidate, with the expectation that users should try it and report issues.

There’s an important distinction between a release candidate and an alpha feature. Alpha features should be explicitly enabled via a CLI flag and should not appear in menus or configuration by default. Using them should require intentional opt-in, along with clear warnings in the help text or a visible banner once enabled.

This becomes especially important as developers and companies increasingly rely on AI coding agents. Disruptions in workflow, cadence, or bug-fix loops now carry much higher impact than they did in traditional, manual development flows.

To be clear, this feature hasn't been released as "experimental" yet. It's still under active development. I know there's a lot of excitement about this feature, but be aware that if you use it at this stage, you will almost definitely hit bugs or rough edges. We'll document and announce when it's released for experimental use.

1. I'd say it was released as experimental. v0.88.0 (commit 483239d8) moved collab (multi-agents) into the public /experimental menu and added menu metadata, which is what I think users treat as being released as experimental. Internally, it's a bit more complicated, and maybe OpenAI as a whole didn't intend this. In v0.87.0, the user and internal terminology was mis-matched. /experimental exposed features listed as Stage::Beta to users, and Stage::Experimental features were treated more lie a pre-beta / alpha that users could only enable manually. v0.88.0 (commit 070935d5) flipped the internal semantics to fix the mis-match: /experimental began showing Stage::Experimental, and treated Stage::Beta as hidden features. It also edited each feature spec to swap the internal designation, so there would be no visible change in /experimental. But, then 483239d8 switched collab back from Stage::Beta to Stage::Experimental, and because of the terminology fix that put it in /experimental, and led users to view it as being released as experimental.

We've looked into the issue reported in this thread. The error you're seeing here is not the normal "usage limit hit" error. You're hitting a different rate limiter that is (presumably) in place to mitigate DDOS attacks. Users with pro subscriptions have priority request processing and more throughput. That probably explains why you're seeing this error with pro accounts but not with plus accounts. We'll need to investigate further, and we'll make sure to get this fixed prior to releasing the feature. Thanks for reporting!

1. I think we understand that experimental and beta features may have unintended consequences, but I would hope that OpenAI would be willing to fix rate limit issues caused by bugs from users trying either.
2. Is the DDOS mitigation limiter you mentioned something that gets auto-cleared on its own faster, or have the users affected by it actually lost their weekly quota? If it's the quota, I'm surprised OpenAI isn't resetting limits at least for people affected by DDOS limiters. (No, I'm somehow not affected, despite being on pro and having tried collab singe long before v0.88.0.)
3. Can OpenAI publish its Codex limits for plus and pro accounts? I've been working on my own orchestrating program (using codex exec), and have been unable (myself, and asking ChatGPT) to find any Codex concurrency limits by OpenAI. Developers should know what limits to avoid hitting, or we have no idea how many parallel agents can be spawned. I shouldn't have to risk my weely Pro quota to find out on my own what irritates the system.

The sad part is that it's likely all of the developers on codex have unlimited usage, which is why such an obvious bug like this one went unnoticed.

Even though they should have unlimited access, they should be alerted when they've exhausted non-employee quotas so they have a better feel for how the tool works for the rest of us.

Are we going to have usage reset for this? Burned through my entire weekly sub almost instantly

> To be clear, this feature hasn't been released as "experimental" yet. It's still under active development. I know there's a lot of excitement about this feature, but be aware that if you use it at this stage, you will almost definitely hit bugs or rough edges. We'll document and announce when it's released for experimental use. > > We've looked into the issue reported in this thread. The error you're seeing here is not the normal "usage limit hit" error. You're hitting a different rate limiter that is (presumably) in place to mitigate DDOS attacks. Users with pro subscriptions have priority request processing and more throughput. That probably explains why you're seeing this error with pro accounts but not with plus accounts. > > We'll need to investigate further, and we'll make sure to get this fixed this prior to releasing the feature. Thanks for reporting! "steer conversation" is also listed in the "experimental" section and promoted on X by the codex team. How is one supposed to differentiate between "experimental" ( but not really experimental and under heavy development ) vs "experimental" ( released for experimentation not under heavy development )?

Very simple: one is not supposed to nor is such a gradient a reasonable expectation or even possible most of the time. It is not shades of grey. Past performance & "the last experimental feature was safe, ergo...." mean zero about the next one. It is binary: past this line you are leaving the flight envelope. You are a test pilot. On the other side of this line, you have a reasonable expectation and warranty of reasonable safety & due care testing. Simple, clear: black and white.

That said:

1. Codex CLI is open source. You can very easily see the quality & state of code (and actually just ask codex where risk paths are and to help walk you through things before you tread on unfamiliar ground). This is one way one can differentiate and make their own informed risk assessments (I, for one, do not want OAI making risk assessments for me) and not rely on assumptions from past code paths/features that the next will be the same.

1. Use production, supported, test features only. The whole point of experimental is that the necessary experimentation _is in progress_ and by treading on said _experimental_ territory, you're, well, part of the experiment. Part of the experiment is sussing this out, and those of us who opt in to become part of the experiment are the guinea pigs. There are upsides and downsides to that. Expecting it to be all gravy, predictable, and well-signed past the "you're leaving the ski area, there are hidden obstacles past here that will kill you, if you survive, you're lucky!" gate just isn't possible by definition of ungroomed, unpatrolled terrain. Stick to the groomers (which still carry risks, but they're reasonably mitigated) if you need marked hazards with a nice rating system to help you make risk assessments, past the /experimental gate is totally uncharted, and we have to route find (read the source, understand it) yourself, OAI is not here to do that for us (although they have been nice enough to give us the map, they have told us they have not yet validated it or digested it for us, and they could be wrong).

To be clear, this feature hasn't been released as "experimental" yet. It's still under active development. I know there's a lot of excitement about this feature, but be aware that if you use it at this stage, you will almost definitely hit bugs or rough edges. We'll document and announce when it's released for experimental use. We've looked into the issue reported in this thread. The error you're seeing here is not the normal "usage limit hit" error. You're hitting a different rate limiter that is (presumably) in place to mitigate DDOS attacks. Users with pro subscriptions have priority request processing and more throughput. That probably explains why you're seeing this error with pro accounts but not with plus accounts. We'll need to investigate further, and we'll make sure to get this fixed prior to releasing the feature. Thanks for reporting!

Keep up the great work, and specifically, kudos to OpenAI on working to put "open" back into the name. The source, the discussions here, the access to early features and building in the open. Thank you.

> > To be clear, this feature hasn't been released as "experimental" yet. It's still under active development. I know there's a lot of excitement about this feature, but be aware that if you use it at this stage, you will almost definitely hit bugs or rough edges. We'll document and announce when it's released for experimental use. > > We've looked into the issue reported in this thread. The error you're seeing here is not the normal "usage limit hit" error. You're hitting a different rate limiter that is (presumably) in place to mitigate DDOS attacks. Users with pro subscriptions have priority request processing and more throughput. That probably explains why you're seeing this error with pro accounts but not with plus accounts. > > We'll need to investigate further, and we'll make sure to get this fixed this prior to releasing the feature. Thanks for reporting! > > > "steer conversation" is also listed in the "experimental" section and promoted on X by the codex team. How is one supposed to differentiate between "experimental" ( but not really experimental and under heavy development ) vs "experimental" ( released for experimentation not under heavy development )? Very simple: one is not supposed to nor is such a gradient a reasonable expectation or even possible most of the time. It is not shades of grey. Past performance & "the last experimental feature was safe, ergo...." mean _zero_ about the next one. It is binary: past this line you are leaving the flight envelope. You are a test pilot. On the other side of this line, you have a reasonable expectation and warranty of reasonable safety & due care testing. Simple, clear: black and white. That said: 1. Codex CLI is open source. You can very easily see the quality & state of code (and actually just ask codex where risk paths are and to help walk you through things before you tread on unfamiliar ground). This is one way one can differentiate and make their own informed risk assessments (I, for one, do not want OAI making risk assessments for me) and not rely on assumptions from past code paths/features that the next will be the same. 2. Use production, supported, test features only. The whole point of experimental is that the necessary experimentation _is in progress_ and by treading on said _experimental_ territory, you're, well, part of the experiment. Part of the experiment is sussing this out, and those of us who opt in to become part of the experiment are the guinea pigs. There are upsides and downsides to that. Expecting it to be all gravy, predictable, and well-signed past the "you're leaving the ski area, there are hidden obstacles past here that will kill you, if you survive, you're lucky!" gate just isn't possible by definition of ungroomed, unpatrolled terrain. Stick to the groomers (which still carry risks, but they're reasonably mitigated) if you need marked hazards with a nice rating system to help you make risk assessments, past the /experimental gate is totally uncharted, and we have to route find (read the source, understand it) yourself, OAI is not here to do that for us (although they have been nice enough to give us the map, they have told us they have not yet validated it or digested it for us, and they could be wrong).

I don’t think anyone is arguing that experimental means “safe” or “guaranteed.” The point is about signaling and expectations, not eliminating risk.

In practice, asking users to read and fully reason about the source code of every promoted experimental feature before using it isn’t realistic, especially when those features are surfaced directly in menus and workflows and discussed publicly by the team. That presentation implicitly communicates a level of maturity beyond “here be dragons, proceed only after a full code audit.”

I’m also not asking OpenAI to make risk assessments for users. I’m asking for clearer differentiation between alpha-level experiments and features that are intended for broader, real-world use with feedback. When multiple experimental features have been usable for months without major disruption, it’s reasonable for users to infer a gradient, even if you argue one shouldn’t exist.

This matters more now because these tools are increasingly embedded in automated and semi-automated workflows. When an experimental feature can silently disrupt cadence, state, or recovery paths, the cost is higher than “you tried a thing and it crashed.”

So the question isn’t “should experimental be risky?” Of course it should. The question is whether all experiments should be treated as totally uncharted backcountry, or whether some should be clearly marked as alpha-only, opt-in via flags, and kept out of default paths until they’re ready for wider exposure.

I don’t think anyone is arguing that experimental means “safe” or “guaranteed.” The point is about signaling and expectations, not eliminating risk.

I hear that loud and clear and understand that, that is why intimated that asking for expectations in "experimental" code is like a test pilot asking the designers for what is going to happen beyond the flight envelope. As much as they want to tell the pilot, _they simply cannot_. That is the very definition of the test pilot. It's why ski areas have gates with skulls and crossbones to the off-piste areas: because conditions change faster than they can characterize them, assess them, let alone mitigate them. What you're asking for OpenAI can't give you, and if they did, it'd likely be (dangerously) wrong or outdated.

You correctly point out SWE is changing, and I agree, but that's a knife that cuts both ways: it is going to become increasingly _impossible_ to know the risks of AI generated/assisted code that hasn't had sufficient testing.

In practice, asking users to read and fully reason about the source code of every promoted experimental feature before using it isn’t realistic, especially when those features are surfaced directly in menus and workflows and discussed publicly by the team. That presentation implicitly communicates a level of maturity beyond “here be dragons, proceed only after a full code audit.”

Perhaps, but again, you and I agree SWE is changing fundamentally, and you can get a far better understanding of the ground you're about to tread on very easily these days. It's not perfect or failsafe, but you can get a good handle on it pretty quickly & reliably. Again, the route finding analogy off-piste applies here well, I think: yeah, it's unreasonable to ask you to fly over every square foot before hand, but can you survey the terrain, make some informed judgements from your knowledge of the backcountry/risks? Yeah.

I absolutely run through the code paths for experimental features before I bet my or my company's money on things if even a perfunctory analysis in CC/Codex/Amp about what that code does and the nature of how it generates calls to costly (in $$$, tokens, CPU, memory, time) resources. I highly suggest everyone do this if possible to an extent that matches one's risk sensitivity.

It is reasonable these days.

I’m also not asking OpenAI to make risk assessments for users. I’m asking for clearer differentiation between alpha-level experiments and features that are intended for broader, real-world use with feedback. When multiple experimental features have been usable for months without major disruption, it’s reasonable for users to infer a gradient, even if you argue one shouldn’t exist.

I'm not arguing one _shouldn't_ exist, I want one as much as you do! I'm saying _by definition_ one _cannot_ exist because the experiments have not been run. You're asking for the result of the experiment before the experiment has been conducted. AI is good, it's not THAT good yet.

This matters more now because these tools are increasingly embedded in automated and semi-automated workflows. When an experimental feature can silently disrupt cadence, state, or recovery paths, the cost is higher than “you tried a thing and it crashed.”

As I said above, I agree, but this is merely one point in a much broader interconnected change. On one hand, what you say is undeniably true: these trues are more embedded and can be far more dangerous. But our ability to reason about them, their effects, and the like has also commensurately increased. Choose not to adopt those or adapt to that dynamic at your own risk.

So the question isn’t “should experimental be risky?” Of course it should. The question is whether all experiments should be treated as totally uncharted backcountry, or whether some should be clearly marked as alpha-only, opt-in via flags, and kept out of default paths until they’re ready for wider exposure.

Again "should" vs "can". And, if I am not mistaken, this feature was very much an opt-in (it was for me, YMMV or maybe there was a bug or inadvertent release past the opt-in, in which case I agree with you, shame on OpenAI, but if this is just "well, I assumed b/c the last time I pulled the trigger in Russian Roulette nothing happened that this time it won't happen", that's not any shame on OpenAI), no one imposed this on me or made it even easy to accidentally turn it on. It required typing a non-obvious command and literally star on a feature/features.

I feel bad and am genuinely sorry you had harm in this, I take no pleasure in that nor am I trying to minimize that. I hear that this sucks for you and genuinely don't like that! I just don't think what you're asking for is tenable or reasonable nor would be a tenable or reasonable mitigation to this happening again: because the knowledge to make the kind of classifications you're asking for with the confidence you're asking for is only really available IME on the groomed side of the resort (where there still are risks, they're just classified with a certain degree of confidence).

The kind of data that goes into the decisions/calls/classifications you're asking for takes running "in the wild" with real users for some time, that's precisely what we're signing up for when we opt in past /experimental: being their test data so when they open this part of the product up for general use they can call it 'on-piste'.

You're asking for side-country terrain, I hear ya...I just think the analogy breaks down right around there, which, well, maybe it doesn't b/c ski resorts are struggling with side-country and have for some time: people are out there getting themselves in over their head and then mad at the ski resort...feels kinda like this thread, no? I've long argued against side country back when I was in public safety for many of the similar reasons here...not because I'm a binary blockhead who can't see shades of grey, but because I don't think those always exist as much as we want them to as humans, and our decision making is not always as great and rational as we think it is when presented with grey areas on risk assessments with unclear & sparse data (the decision making behind accidents in the back country and side country and the study of it has a lot parallels to this IMO, and the research and practical results there are pretty clear that it is very binary on those gates, and resorts are reconsidering side country quite a bit!).

I respect and appreciate our dialog, and that you have your side and I have mine. I really appreciate civil disagreement + discussion. It's actually more fun than any echo chamber I've been in!

Version 0.91.0 removes the "Multi-agents" feature from the "/experimental" menu. We got ahead of ourselves by adding it there. Apologies for that. We'll add it back once the feature is further along in its development.

We're building these feature in the open because we believe that's the right thing to do for the community. Open development allows us to get early feedback to inform and steer our work on new features. But it also has a downside in that users may run into problems when features are incomplete, unpolished, and undocumented. We'll try to mitigate this downside by setting clearer expectations about each feature as it goes through its phases of maturity.

Thanks for your understanding — and for the continued support, feedback, and thoughtful discussions.

We're working on prioritizing the fix for the rate limit issue that some of you experienced. This change affects our "responses" endpoint which is used for more than just Codex, so it may take a little while for us to identify the correct fix and get it in place.

Maybe add a /here-be-dragons option in the menu

Version 0.91.0 removes the "Multi-agents" feature from the "/experimental" menu. We got ahead of ourselves by adding it there. Apologies for that. We'll add it back once the feature is further along in its development. We're building these feature in the open because we believe that's the right thing to do for the community. Open development allows us to get early feedback to inform and steer our work on new features. But it also has a downside in that users may run into problems when features are incomplete, unpolished, and undocumented. We'll try to mitigate this downside by setting clearer expectations about each feature as it goes through its phases of maturity. Thanks for your understanding — and for the continued support, feedback, and thoughtful discussions. We're working on prioritizing the fix for the rate limit issue that some of you experienced. This change affects our "responses" endpoint which is used for more than just Codex, so it may take a little while for us to identify the correct fix and get it in place.

Is it possible to get usage reset? Had all of my weekly usage ate up instantly before the new update and now Im stuck idle for a week

The bug that caused instant draining of usage quota has been fixed on the server. You may still hit rate limits if you spawn a large number of subagents, but if you hit this condition, it will no longer drain your usage quota.