Environment
ChatGPT Desktop for Windows
Windows 11
Codex / Work
GPT-5.6 Sol
Local Codex host on Windows
Issue observed with multi-agent security scan / subagent orchestration
Bug:
I’m investigating what looks like abnormal Work/Codex usage behaviour after a full weekly reset.
Plan:
ChatGPT Pro
Incident:
20 September 2026, BST
What happened:
- I used a full Work/Codex reset at approximately 00:17 BST.
- Local Codex rollout telemetry confirms the fresh weekly window started at 0% used.
- The same telemetry shows a 10,080-minute (7-day) primary window.
- The weekly counter reached 100% roughly 44 minutes later.
- An explicit usage_limit_exceeded error followed seconds later.
The important part is what was running during that period.
I had requested one comprehensive local security assessment of a Java web application.
The Codex security workflow expanded into a large worker/subagent tree under one scan ID:
50e37f7f-6173-4df2-87bd-7daaf26bb9d7
The recovered rollout logs show numbered Standard discovery workers from discovery-0001 through discovery-0014.
Workers 0001-0004 existed before the reset.
After the reset, additional discovery workers continued being created, including discovery-0013 very close to weekly exhaustion.
Each Standard discovery worker configuration included:
subagents = 3
The logs also show many additional subagent sessions.
Across the reset-to-exhaustion window I identified dozens of new Codex sessions, mostly security_scan and subagent sessions.
One particularly concerning detail:
discovery-0013 was launched when the weekly allowance was already around 97-98% used, yet it was still instructed to run another Standard scan with subagents.
After the weekly limit had reached 100%, the orchestration later attempted to create discovery-0014. That attempt was blocked by the usage limit.
The local telemetry also reveals a reporting issue.
A diagnostic task eventually told me:
“Current Codex allowance is healthy: 6% used when checked.”
However, that 6% figure came from an earlier reading.
By the time that same task completed, its own rate-limit telemetry showed approximately 69% used.
So the user-facing status was materially stale while concurrent agentic activity was still running.
Another detail I’m trying to understand:
the captured rate-limit telemetry consistently shows:
primary.window_minutes = 10080
secondary = null
I had expected some shorter/5-hour safeguard to limit a runaway burst before an entire weekly allowance could disappear in under an hour.
I am not claiming that no real usage occurred. The logs clearly show substantial model activity.
My concern is that one requested security assessment expanded into a very large automatically orchestrated worker/subagent tree, with continued worker creation right up to the weekly limit.
Questions for OpenAI / other users:
- Is this level of discovery-worker fan-out expected for one Standard security scan?
- Should a security workflow continue spawning new workers when weekly usage is already above 95%?
- Is secondary = null expected for this type of Work/Codex usage?
- Are interrupted/retried/replacement workers all charged independently?
- Has anyone else seen a fresh weekly allowance disappear this quickly because of multi-agent worker fan-out?
- Is there currently any supported usage guardrail or warning threshold for multi-agent Codex tasks?
I already have an open Support case and have provided them a sanitised evidence pack with timestamps, worker IDs, quota progression and hashes of the original rollout logs.
I’m posting here to see whether this is a known orchestration/usage issue and whether others have experienced similar behaviour.
I’m deliberately not posting raw rollout logs because they contain private project data.