GPT-6 Astra High: one multi-agent Work task consumed 86% of weekly Prolite quota in ~4.5h (~198M tokens, 97.4% cached input)

What version of Codex are you using?

Codex Work/Desktop on Windows. The affected rollout metadata reports bundled cli_version: 0.153.4 and originator: codex_work_desktop.

What subscription do you have?

ChatGPT Prolite (€100/month). The rollout telemetry reports plan_type: "prolite".

Which model were you using?

gpt-6-astra, reasoning effort high.

The main thread also spawned three GPT-6 Astra High child agents after delegation was requested. codex-auto-review / guardian activity was present as well.

What issue are you seeing?

A single long-running engineering task consumed almost the entire weekly Codex allowance within a few hours immediately after a fresh quota reset.

The important part is that the local rollout telemetry gives a clean 0% starting point and allows the usage to be quantified precisely.

At 2026-09-12T10:07:46Z, the server-reported primary rate limit was:

used_percent: 0
window_minutes: 10080
plan_type: prolite

10080 minutes is a 7-day window.

By 2026-09-12T14:38:41Z, the same rate-limit telemetry reported:

used_percent: 86
window_minutes: 10080

So 86% of the weekly allowance was consumed in about 4h31m during one task. The task continued for a few more minutes in the supplied rollouts, and subsequent work exhausted the remaining allowance, but the measurements below intentionally use only the locally captured 0% → 86% interval.

Quantified rollout evidence

I parsed the main rollout, its three spawned Astra workers, and the associated guardian rollouts for the task interval. Deduplicating by response_id gives 1,520 distinct model responses.

Aggregate usage recorded by token_usage_record:

Metric	Tokens
Total	198,428,302
Input	197,559,388
Cached input	192,381,312
Non-cached input	5,178,076
Output	868,914
Reasoning output	259,127

Cached input therefore represents 97.38% of all input tokens.

Approximate distribution:

Work source	Total tokens	Share
Main Astra High thread	67.89M	34.2%
3 spawned Astra High agents	123.18M	62.1%
Guardian / auto-review	7.35M	3.7%

The three child agents individually processed approximately:

• 37.14M tokens
• 42.91M tokens
• 43.14M tokens

Most of this was repeated cached context rather than new input.

Quota progression from the rollout telemetry

All timestamps UTC:

Time	Weekly quota used
10:07:46	0%
10:41:13	10%
11:02:39	20%
11:26:26	30%
11:48:43	40%
12:12:32	50%
12:45:58	60%
13:11:39	70%
13:51:15	80%
14:38:41	86%

This is not just a UI percentage jump: the rollout files show a very large amount of actual model traffic occurring behind one user-visible task.

Why this seems worth investigating

The telemetry suggests that the immediate cause is massive context amplification, especially after multi-agent fan-out:

• ~198.4M tokens processed in one task;
• ~192.4M of those tokens were cached input;
• three child agents account for ~62% of the total token volume;
• 1,520 distinct model responses were generated during the measured interval.

So this may not be a simple meter displaying invented usage. Codex really is generating an enormous amount of repeated context processing.

The concern is whether this behavior and its quota accounting are intended. A user can request delegation on one engineering task and silently convert a fresh weekly allowance into hundreds of millions of token-processing events, mostly cached context, with no visible token budget, projected quota cost, or circuit breaker.

It would be useful to verify:

1. whether cached input from parallel Astra agents is weighted toward subscription usage as intended;
2. whether multi-agent child contexts are being resent more often or at larger sizes than necessary;
3. whether there should be a per-task / per-agent token budget or warning before a task can consume a large fraction of the weekly allowance;
4. whether the UI should expose actual token traffic, including child-agent usage, rather than only a percentage meter;
5. whether context reuse across parent/child agents can be reduced so cached context does not dominate total processing at this scale.

Steps to reproduce the observed pattern

This is an observed production incident rather than a minimal deterministic reproduction:

1. Start with a freshly reset weekly Codex allowance.
2. Use a long-running local Work thread on a non-trivial repository with GPT-6 Astra High.
3. Continue an engineering task with substantial accumulated context.
4. Ask Codex to delegate independent portions of the work where useful.
5. Codex spawns several Astra child agents in parallel.
6. Let the parent and children continue normal inspect/edit/validate/tool cycles for several hours.
7. Inspect ~/.codex/sessions/.../*.jsonl, especially token_usage_record and event_msg/token_count.
8. Observe that cached context is repeatedly processed by parent and child agents while the weekly quota decreases rapidly.

Expected behavior

Parallel agents can reasonably consume more compute, but one normal user-facing task should not be able to consume most of a weekly paid allowance without any indication of the underlying scale.

At minimum, Codex should either:

• prevent pathological repeated-context amplification,
• cap / budget child-agent execution,
• warn before launching work likely to consume a large fraction of the remaining allowance,
• or expose enough per-agent token and quota telemetry that the user can make an informed decision.

Related issues

• #44909 — measured cost of false goal continuations / repeated full-context rereads
• #45073 — severe usage drain with mostly cached input
• #42987 — GPT-6 Astra rapidly depleting usage allowance

This report differs by providing a fresh-reset weekly-window trace on a Prolite account, with a parent + three parallel Astra agents and a quantified ~198M-token breakdown.

Additional information / privacy

I have the original rollout JSONL files for the parent task and child/guardian sessions. They contain private project paths, source/tool output, and conversation content, so I am not attaching them publicly. I can provide a sanitized extract or the full logs through a maintainer-approved private channel if useful.

Start with the rollout JSONL files under ~/.codex/sessions/.../*.jsonl and inspect token_usage_record plus event_msg/token_count for the parent, child, and guardian sessions. Compare the measured quota progression with related issues #44909, #45073, and #42987. Done requires identifying whether the accounting or context amplification is faulty and defining a specific safeguard or telemetry change; the payload names no source files or tests.