›_ Codex Issues
Codex Issues / #33276

Codex CLI: gpt‑5.6‑sol Ultra Fast background loop drained weekly limit

Open 💬 2 comments Opened Jul 15, 2026 by klementv-cpu
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.144.4

What subscription do you have?

ChatGPT Plus (Codex enabled)

Which model were you using?

gpt‑5.6‑sol (reasoning ultra, summaries auto, Ultra Fast)

What platform is your computer?

Windows 11 Pro 64‑bit , Codex CLI running in Windows Terminal / PowerShell from C:\Dev\Home_server_5

What terminal emulator and version are you using (if applicable)?

Windows Terminal (latest stable from Microsoft Store), PowerShell 7.x No additional multiplexer (no tmux/screen)

Codex doctor report

What issue are you seeing?

On July 14th, 2026 at around 23:00 Tallinn time (UTC+2), I started a Codex CLI session using the gpt‑5.6‑sol Ultra Fast model to make a small change related to fencing / ownership tokens and lease_token handling. After issuing the change, I stopped interacting with Codex and expected the process to finish.

However, Codex entered a repeated “waiting for agents” loop and continued running in the background without any new input from me. The pattern looked like:

• Waiting for agents

• Finished waiting
└ No agents completed yet
repeated many times, plus • Interacted with /root/impl_jobs_failure_snapshot.

Eventually, I received:
■ You've hit your usage limit. Visit https://chatgpt.com/codex/settings/usage to purchase more credits or try again at Jul 21st, 2026 11:57 PM.

As a result, my entire weekly Codex limit was consumed by this background loop, even though I was not actively using Codex and did not issue additional commands. This feels like an infinite “waiting for agents / no agents completed yet” loop silently burning credits in the background.

What steps can reproduce the bug?

Uploaded thread: 019f62cd-fc3b-7731-8713-c6c5e89733da

What is the expected behavior?

Codex should stop or time‑out the agent workflow instead of running an infinite “waiting for agents / no agents completed yet” loop in the background.

In this situation I expected:

the small configuration change to complete with minimal usage;

no further credits to be consumed once there is no user interaction;

either a clear error about agents not completing or an automatic stop, rather than silently burning the entire weekly limit.

Additional information

Codex CLI status after the incident (v0.144.4) shows:

Model: gpt‑5.6‑sol (reasoning ultra, summaries auto)

Session: 019f62cd-fc3b-7731-8713-c6c5e89733da

Weekly limit: 0% left (resets 23:57 on 21 Jul)

Account: klementv@gmail.com (Plus)

I can provide the full CLI session log and a screenshot of the usage/settings page if needed. This looks like an internal background loop consuming credits without user interaction on gpt‑5.6‑sol Ultra Fast.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #33196
  • #32756

Powered by Codex Action

cansitki · 1 month ago

Confirming a closely matching Linux/CLI reproduction, with Fast disabled.

Environment:

  • Codex CLI 0.144.5
  • ChatGPT Pro via ChatGPT authentication
  • Linux 6.8.0-136-generic x86_64, tmux 3.4
  • model gpt-5.6-sol, reasoning ultra, summaries auto
  • service_tier = "default"; Fast mode not enabled
  • multi-agent enabled

Sanitized local telemetry from one long-lived main thread:

  • The thread started July 19 and the local rollout is approximately 268.9 MB.
  • At 2026-07-21 04:43:10 UTC, weekly usage was 28% used and cumulative thread telemetry reported 349,056,550 total tokens.
  • At 2026-07-21 11:15:34 UTC, weekly usage was 65% used and cumulative total was 502,554,467 tokens.
  • At 11:25:46 UTC, cumulative total was 508,615,973 tokens: 506,834,387 input tokens, of which 489,251,840 were cached input. These are local token_count telemetry values, not a claim that all tokens were billed identically.
  • The parent trace contains 137 wait_agent calls and 73 list_agents calls since thread start. On July 21 UTC alone: 47 wait_agent and 27 list_agents.
  • Recent small coordination/status turns repeatedly carried roughly 140k to 145k input tokens each.

Observed behavior:
The parent continues making model turns to poll or coordinate subagents. In a long context, even a status-only turn appears to reprocess a very large cached context and the weekly quota drops quickly. The persisted service tier is default, so this reproduction is not explained by the Fast multiplier present in the original report.

This looks consistent with #34468 and potentially the Sol tool-turn amplification in #32503. #14593 is the maintainer-designated generic tracker.

Expected behavior:

  • subagent completion and status should be event-driven or use bounded polling without a full parent model turn each time;
  • waiting with no completed agent should not repeatedly reprocess the full parent context;
  • the UI and CLI should expose per-parent and per-subagent usage so this can be diagnosed.

I am intentionally not attaching the local transcript or account/session identifiers publicly because the thread contains private project context. I can submit reviewed logs through /feedback if maintainers need a private diagnostic ID.