Abnormal token consumption: ~678M tokens used while editing 3 resume versions due to repeated multi-agent polling

Abnormal token consumption: ~678M tokens used while editing 3 resume versions, with repeated wait_agent polling and fork_turns="all"

Summary

On August 20, 2026, I used Codex for a relatively small task: revising three versions of my resume and exporting/checking the resulting DOCX/PDF files.

This unexpectedly consumed essentially my entire weekly Codex usage allowance.

After inspecting my local Codex session logs under .codex/sessions, I found approximately 678.5 million total tokens recorded across 22 sessions on that day.

The overwhelming majority of the input was cached input:

• Total tokens: 678,503,746
• Input tokens: 677,414,215
• Cached input tokens: 666,342,272
• Uncached input tokens: 11,071,943
• Output tokens: 1,089,531
• Reasoning output tokens: 186,964
• Cached input as a percentage of input: approximately 98.4%

For a task consisting primarily of editing three resume variants, this level of consumption appears highly abnormal.

I am requesting:

1. Investigation into whether Codex entered an abnormal multi-agent polling / context replay loop.
2. Clarification on why repeated agent waiting continued consuming very large amounts of cached input.
3. Restoration / recredit of the weekly Codex usage consumed by this behavior, if confirmed to be abnormal system behavior.

---

What I was doing

The actual user task was relatively limited:

• Revise three versions of my resume.
• Generate/check DOCX and PDF outputs.
• Fix formatting/page-break issues where needed.
• Perform some QA on the generated files.

I did not intentionally request hundreds of millions of tokens of work.

During the task, my C: drive also became full, and the resume task did not finish normally.

---

Token usage observed

I parsed the final total_token_usage value from each Codex session on August 20.

Daily totals:

Sessions:       22
Token events:   4967

Input:          677,414,215
Cached Input:   666,342,272
Uncached Input: 11,071,943
Output:         1,089,531
Reasoning:      186,964
Total Tokens:   678,503,746

Some individual sessions recorded extremely high totals.

Examples:

Session starting 15:51:
Input:         58,879,260
Cached Input:  58,111,360
Uncached:         767,900

Session starting 23:37:
Input:         57,277,474
Cached Input:  56,506,368
Uncached:         771,106

Another session starting 23:37:
Input:         57,156,485
Cached Input:  56,411,520
Uncached:         744,965

Session starting 23:12:
Input:         56,454,095
Cached Input:  55,677,440
Uncached:         776,655

The repeated pattern is that around 98–99% of the input is cached.

This suggests that very large amounts of existing context were repeatedly being sent through model calls.

---

Suspicious multi-agent behavior found in the session logs

Inspection of the rollout JSONL logs shows a large number of repeated calls such as:

collaboration.wait_agent
timeout_ms: 60000

These calls occurred repeatedly, often roughly once per minute, while waiting for a child agent to complete.

Example sequence:

wait_agent(timeout_ms=60000)
wait_agent(timeout_ms=60000)
wait_agent(timeout_ms=60000)
wait_agent(timeout_ms=60000)
wait_agent(timeout_ms=60000)
...

There were also repeated:

send_message
list_agents
wait_agent

operations while waiting for the same child agent.

One child agent was named:

resume_doc_repair

The parent repeatedly waited for this agent for an extended period and eventually issued:

interrupt_agent
target: resume_doc_repair

Shortly afterward, Codex spawned another agent:

spawn_agent
task_name: pagebreak_repair
fork_turns: all

The fork_turns: "all" behavior is especially concerning in this case because it appears to have provided the child agent with the complete existing conversation/context.

The parent agent then continued repeatedly calling wait_agent while the child agent ran.

---

Token growth while apparently only waiting

One session clearly demonstrates the issue.

Near the end of the session, cumulative input tokens increased from:

57,098,380

at approximately:

15:37:14Z

to:

58,879,260

at approximately:

15:54:35Z

That is an increase of approximately:

1,780,880 input tokens

in about 17 minutes.

During the same period, output tokens increased only from approximately:

54,865

to:

58,875

So approximately 1.78 million additional input tokens were processed while only around 4,000 additional output tokens were produced.

The surrounding rollout log during this period contains repeated wait_agent calls and agent coordination operations.

This makes me suspect that each polling/wait cycle was triggering another model turn containing a large cached context.

---

Tool activity

The session also performed automated QA and file-management work, including operations involving:

Python
pypdf
PDF page/text checks
Word/PDF export
PowerShell
WINWORD
file enumeration
output audit files

There were signs that Word/PDF generation encountered problems.

Codex also detected and forcibly terminated a WINWORD process during the task.

Later it inspected export error files and restored PDF outputs from backups.

This may have contributed to the task remaining active for a long time.

However, I would not expect a stalled document export or child agent to result in hundreds of millions of model input tokens.

---

Why I believe this may be abnormal behavior

The important pattern is:

small user task
→ child agent spawned
→ full history forked
→ parent repeatedly polls/waits
→ very large cached context repeatedly processed
→ child agent stalls or takes a long time
→ parent continues polling
→ agent interrupted
→ another child agent spawned
→ polling continues

This appears to have caused enormous cached-input accumulation without a corresponding amount of useful user-facing work.

The fact that approximately 98.4% of all input tokens were cached input is also consistent with repeated replay of substantially the same context.

---

Expected behavior

For a task such as editing three resumes, I would expect Codex to:

• edit the files;
• perform a reasonable number of QA/export operations;
• wait efficiently for any child process or agent;
• avoid repeatedly invoking the model merely to check whether a child agent has completed;
• avoid repeatedly replaying a large conversation context while idle;
• terminate or surface an error if a child agent or document process is stuck.

I would also expect multi-agent behavior to avoid consuming an entire weekly allowance for a relatively small document task.

---

Actual behavior

Instead:

• 22 rollout sessions were created on August 20.
• Approximately 678.5 million total tokens were recorded.
• Approximately 666.3 million were cached input tokens.
• Multiple sessions individually reached approximately 40–59 million input tokens.
• The logs show extensive repeated wait_agent polling.
• Child agents were spawned using full conversation history.
• A child agent was eventually interrupted after prolonged waiting.
• Another child agent was then created.
• The task did not complete normally.
• My weekly Codex usage was effectively exhausted.

---

Possible root cause

I cannot determine the internal implementation, but the logs suggest a possible interaction between:

1. Multi-agent orchestration.
2. Repeated wait_agent polling.
3. Full-context agent forking via fork_turns: "all".
4. Large accumulated conversation context.
5. Slow/stalled Word/PDF export operations.
6. Repeated model turns while waiting for agents/processes to finish.

If each wait_agent result causes the parent model to run again with tens of thousands of cached context tokens, a polling loop could generate exactly the kind of usage observed here.

---

Impact

This was not merely a reporting anomaly from my perspective.

The behavior consumed effectively my entire weekly Codex allowance, despite the underlying task being only the modification of three resume versions.

This prevented me from continuing normal Codex work afterward.

---

Request for investigation and usage restoration

Please investigate the relevant server-side usage and session behavior for my Codex activity on:

2026-08-20

In particular, please verify:

• whether the repeated wait_agent operations generated model calls;
• how much usage was generated by the parent agent while waiting;
• how much was generated by spawned child agents;
• whether fork_turns: "all" caused the entire accumulated context to be repeatedly replayed;
• whether stalled/repeated agent coordination caused unintended token consumption;
• whether the reported usage corresponds to billable/allowance-consuming usage.

If this consumption was caused by abnormal agent orchestration or polling behavior, I am requesting that the affected weekly Codex usage allowance be restored/recredited.

I can provide the relevant local rollout-*.jsonl session logs if needed.

---

Environment

OS: Windows
Date of incident: 2026-08-20
Codex data directory: C:\Users\WJ\.codex\
Session directory: C:\Users\WJ\.codex\sessions\2026\08\20\
Number of sessions that day: 22
Task type: Editing and QA/export of 3 resume variants

I can provide the exact Codex version, model, configuration, and additional rollout logs if required.

---

Additional privacy note

The rollout logs contain local file paths, resume information, agent messages, and potentially other personal data.

I therefore prefer not to publicly upload the complete raw JSONL files to GitHub.

I can provide sanitized excerpts publicly and provide the full logs privately to OpenAI support if there is a secure channel for doing so.