Incorrect default behavior of the parent chat when managing background agents, leading to unnecessary consumption of rate limits and tokens.
What version of the IDE extension are you using?
v26.715.31925
What subscription do you have?
Prolite
Which IDE are you using?
VS code, Version: 1.129.1 (user setup) Commit: 8a7abeba6e03ea3af87bfbce9a1b7e48fed567b8 Date: 2026-07-17T15:35:09Z Electron: 42.6.0 ElectronBuildId: 14623276 Chromium: 148.0.7778.280 Node.js: 24.18.0 V8: 14.8.178.38-electron.0 OS: Windows_NT x64 10.0.26200
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
The inefficiency recurs when using GPT-5.6 Sol and when it creates and orchestrates sub-agents.
When the parent chat delegates a task to a sub-agent, it performs a status check every minute and posts the result back to the main chat. As a result, the entire (potentially very large) context of the parent chat is unnecessarily reprocessed on every status update.
For example, if a sub-agent runs for 30 minutes, the parent chat performs 30 status checks, resulting in 30 unnecessary full-context executions solely to generate status messages. Before I noticed this behavior, this inefficiency increased my rate limit usage by approximately 50%.
The status reporting mechanism should be redesigned to use either:
- a configurable polling interval (timeout), or
- an event-driven approach with a timeout-based fallback for status checks and reporting.
What steps can reproduce the bug?
Feedback ID: 019f761d-7081-7c11-b4e5-ad1ff368f8e9
What is the expected behavior?
_No response_
Additional information
_No response_
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I have a matching macOS/Codex Desktop reproduction with a corrected local
trace. Ultra and multi-agent use were intentional; this report isolates only
the extra model turns spent waiting or checking agent status.
Environment: ChatGPT Pro, macOS arm64, Codex Desktop 26.721.31836 (build
5828), incident runtime
codex-cli 0.146.0-alpha.3.1, mostly GPT-5.6 Sol.From the weekly reset to the first backend 49% observation, the corrected
local trace contains 10,586 genuine model turns and about 1.383B raw local
model tokens. Of those, 985 turns selected only
wait_agentorlist_agents: 142.14M raw tokens, including 139.37M cached input. That is10.3% of all corrected raw volume.
write_stdinand genericwaitaddedanother 983 polling turns, bringing combined wait/status-only work to 1,968
turns and 273.56M raw tokens, or 19.8%.
One representative child ran for about 10h55m. Its 1,417 genuine model turns
included 254
wait_agent, 31list_agents, 316write_stdin, and 12 genericwaitcalls. The 613 wait/status turns consumed about 93.17M raw tokens,roughly 45% of that child's genuine model volume. Most agent waits requested
only 30 or 60 seconds, so the model repeatedly resumed just to decide to wait
again.
I excluded 94,241 copied parent-history token records and 404 duplicate token
snapshots. Those records are persisted in child rollouts but are not treated
here as new model calls or billing events.
The current public Sol/Terra rate card estimates the combined wait/status
traffic at about 3,948 credits; the
wait_agent/list_agentssubset is about2,162 credits. These are local-telemetry estimates, not the subscription
billing ledger or a direct weekly-percentage conversion.
Expected: child completion should wake the coordinator, and quiet waits should
remain runtime-managed. A timeout or unchanged status should not require a new
large-context model inference. Per-root telemetry should separately expose
useful work, agent coordination, terminal polling, compaction, retries, and
restored history.