My Codex weekly usage meter went from 0% to 100% in about 11 hours on 8 September 2026. Scheduled content work was running alongside interactive tasks. Rather than assume a billing bug or change every task to Astra Extra High, I audited the local logs, model routing, context settings and the community claims circulating on X and Reddit.
Updated 10 September: newer scheduled-run records, experimental-context enablement steps and a tested configuration fix are included below. The original September 8 measurements remain separate.
The clearest result came from three scheduled DMT content runs: 901 Astra parent responses accumulated 129.16 million input tokens, even though every recorded request stayed below 272,000 input tokens. Almost all of that input was cached. Cached input still represented 76.7% of the estimated text cost at current standard Codex rates.
This is an observational case study of one account, with AI-assisted log analysis. It explains what I changed and why. It is not a controlled comparison of reasoning levels, an exact reconstruction of OpenAI’s subscription billing, or a claim of proven savings after the changes.
What the audit actually measured
The wider audit inspected locally available rollout files, runtime model identities, scheduled-task configuration and account-level allowance observations. For the context analysis below, I isolated the three DMT parent runs on 8 September. Each used GPT-6 Astra High. Their research workers are counted separately when comparing orchestration costs.
A response here means a recorded model response, including responses used during tool-driven work. It does not mean a user message, article or completed assignment. I deduplicated records by response ID, used per-response token usage, and did not add repeated cumulative usage snapshots together. Output totals already include reasoning tokens; adding the reasoning subset again would double count it.
| Observed parent run | Responses | Median input/request | Largest input/request | Logged compactions |
|---|---|---|---|---|
| Morning | 213 | 124,805 | 236,773 | 1 |
| Afternoon | 510 | 151,361 | 244,871 | 3 |
| Evening | 178 | 152,292 | 249,265 | 1 |
The morning and afternoon runs included published articles and refreshes. The evening task ended with a usage-limit error. A subsequent review of its consolidated capture record confirms 59 successful source results and no failed or missing required sources. Completing source capture is separate from finishing research and publication. These were different workloads with different outcomes, so treating them as three equivalent completed jobs would misrepresent the evidence.
The weekly meter is a separate observation. It moved from the first recorded 0% reading at 08:32 IST to 100% at 19:42 IST: approximately 11 hours and 10 minutes. Interactive work accounted for 51.5% of the wider day’s estimated text cost. I cannot assign a matching percentage of the weekly allowance to that work or blame the entire exhaustion on schedules. The account meter is shared, and the logs do not expose a complete per-task subscription ledger.
Five numbers that should not be called “context usage” interchangeably
| Number | What it tells you | What it does not tell you |
|---|---|---|
| Advertised model capacity | The model’s documented capacity on a particular product or API. | The window your current Codex client actually uses. |
| Configured or effective window | The capacity or working limit available to a request. | That all of those tokens are present or charged on every request. |
| Actual input tokens | The serialized input counted for one recorded response. | How much of it was new, cached or useful. |
| Cumulative input | Input added across many requests, including repeated context. | A single enormous prompt. |
| Weekly allowance percentage | The account’s reported consumption against its plan window. | A universal conversion from tokens to percentage points. |
The distinction explains how a roughly 258K working window can coexist with 129 million cumulative input tokens. A 150K context sent through 100 recorded requests contributes 15 million input tokens before considering output. Caching changes the processing and price of the reusable portion; it does not make that portion disappear from the input count.
The audited runs used a 258,400-token effective window
The current local Astra model catalog reported a 272,000-token default context window and a 95% effective-window factor. Their product is 258,400. All 910 window observations in the three historical parent logs reported that same effective value. The 910 observations include repeated status events; the cost sample contains 901 unique responses.
I found no explicit global model_context_window or model_auto_compact_token_limit override in the configuration inspected on 9 September. That current snapshot alone would not prove every historical project or profile setting. The historical window observations are the stronger evidence for these three runs.
OpenAI’s Codex configuration reference describes the first setting as the model’s available context window and the second as the automatic-compaction threshold, with a model default when unset. The threshold’s scope can also matter. A copied number should be interpreted alongside the model, client and configuration it belongs to.
The API is a different surface. The Astra API model card lists a 1,050,000-token context window, with separate input and output limits. That does not prove that this Codex installation used that capacity. For the broader settings explanation, see the existing Astra context and Codex settings guide.
The context traces explain the repeated-input problem
The afternoon run is especially revealing: 510 responses, with context growing and being compacted three times. A large retained history was present through hundreds of model requests. The trace demonstrates repeated input accumulation inside the default working window; an enlarged 400K setting is not required to produce it.
Across the five logged compactions, the neighbouring recorded requests fell from roughly 229K–249K input tokens to 37K–40K. For example, one morning transition went from 236,773 to 37,676 tokens, an 84.1% drop. That is a useful description of the trace, not an 84.1% saving on the whole task.
Compaction has its own processing cost. A changed history can affect cached prefixes, and a condensed record may require later retrieval or correction. The adjacent requests do not establish the exact trigger, isolate the compaction request’s cost, or test whether every fact survived. A lower threshold could reduce repeated input, but premature compaction could also create more rework.
The practical question is therefore: how much context must remain active to finish the next piece of work reliably? A finished article’s detailed drafting history is different from the source evidence, decisions and unresolved questions needed for the next article. Keeping those distinctions explicit offers a more defensible starting point than maximizing or minimizing the window by habit.
Why a 98.1% cache rate did not make the run cheap
The three parents recorded 129,163,778 input tokens, of which 126,690,944 were cached, plus 276,744 output tokens. The cached fraction was 98.1% of input. To compare the components, I repriced those counts using the current standard Astra text rates in OpenAI’s Codex pricing documentation: 250 credits per million uncached input tokens, 25 per million cached input, and 1,250 per million output tokens.
The calculation is straightforward:
Uncached input = 129,163,778 − 126,690,944 = 2,472,834
Estimated credits = (2,472,834 × 250
+ 126,690,944 × 25
+ 276,744 × 1,250) / 1,000,000
= 4,131.4Cached input is much cheaper per token in this comparison. Its sheer volume still makes it the largest component. The estimate excludes any separately charged cache-write category not resolved in these records, processing-mode differences and additional tool or image accounting. It must not be converted into a claimed number of subscription percentage points.
OpenAI’s prompt-caching guide explains reuse of an unchanged prefix. New input still has to be processed. A prefix change can reduce reuse from the changed point onward. It also describes an API configuration-update mechanism for changing Astra effort while preserving the prefix; that is not a guarantee that every client or top-level configuration change follows the same path.
What changing context length can change—and what it cannot
Increasing the ceiling does not, by itself, charge you for an empty window. The potential cost comes when more history remains in actual requests, or when different pricing conditions apply. A larger usable window may avoid compactions and retain useful detail. It may also allow an agent to carry unnecessary material through many more calls.
This illustration holds request count, output and cache share constant. It answers one narrow question: what happens to a text-rate estimate if actual repeated input grows? It does not assume that 350K fits this client’s default window, predict how many requests a real task would need, or prove that reducing context preserves quality.
There is an additional, documented API pricing boundary. For Astra API requests above 272K input tokens, the full request receives higher input/cached-input rates and a higher output rate. Current standard API prices are $10/$1/$50 per million input/cached-input/output below that boundary, and $20/$2/$75 above it. Cache writes are a separate category. See OpenAI API pricing and the worked Astra API budget guide.
Using the same warm-cache illustration, 100 requests at 250K input and 1K output each total $34.50 at standard API rates; at 350K input they total $90.10 after applying the full-request long-context rates. These are hypothetical API calculations. No recorded request in the audited parent sample exceeded 272K, and an API pricing rule is not evidence for how this account’s Codex plan allowance was deducted.
I therefore left the current default context and compaction settings in place. The saved Brandon Galang post recommends a 400K window and 360K compaction threshold, but his clarification calls the choice a heuristic. It is a practitioner hypothesis worth testing, not an established optimum for these content jobs. Experimental notes are another separate option; the Astra notes guide explains their evidence and stale-memory risks.
Does Astra Extra High really use less allowance than Medium or High?
The evidence inspected here does not establish that. Higher effort could finish a difficult task with fewer calls or retries, so a lower total task cost is possible. That possibility is different from a discounted Extra High rate or a universal ranking of effort levels. OpenAI’s Codex model guidance recommends the lowest effort that meets the task’s needs and notes the token and time tradeoff of greater reasoning.
The saved Fandu post on X reproduces a screenshot from a Reddit self-audit. Those are one source lineage, not two independent experiments. The screenshot describes Medium as cheaper per response while reporting more responses and a faster consumption rate than Extra High.
| Reported comparison | Recalculation | Interpretation |
|---|---|---|
| 122 vs 65 responses | 1.88× | Total response-count ratio. |
| 4.7 vs 1.5 responses/minute | 3.13× | Response-rate ratio, not the same denominator. |
| Implied observation duration | 26.0 vs 43.3 minutes | The reported count/rate pairs describe unequal windows. |
| 17.3 vs 8.7 consumption units/minute | 1.99× rate | The unit and completed-work denominator are insufficiently defined. |
Combining those rounded durations and burn rates gives approximately 449 versus 377 units: a 19% difference across unequal windows. This establishes neither equal work nor equal quality. Faster burn can mean more activity per minute; the operational measure is total usage for a result that passes the same review.
There is also a separate upstream change to consider. In his usage-improvement announcement, OpenAI’s Tibo Sottiaux described reductions for some long-tail power-user subscription patterns. The announcement did not identify Extra High as the cause or publish a universal context threshold. Reports made across that change can confound effort effects with backend changes.
My historical sample cannot settle the effort question either: the three comparable scheduled parents all ran at High. Extra High appears in this active audit, which has a different workload. I did not turn that into a fake High-versus-Extra-High benchmark.
What other users’ reports add
A detailed Codex GitHub issue describes a multi-agent workflow with substantial repeated input, large tool-output budgets and episodic cache misses. It supplies useful hypotheses to investigate in client logs. It is still a user report, and its different model mix and workload are not a reproduction of this account’s behaviour.
Other reports question allowance draw, including the Reddit claim of a much larger multiplier. I could not retrieve the claimed underlying CSV from the inspected page, so I cannot verify that multiplier. Discussions on Hacker News and LinkedIn add practitioner experiences, not a representative survey.
Together, these sources justify checking request counts, retained context, worker duplication, cache behaviour and client version before changing effort. They do not prove a universal billing bug, a hidden fixed multiplier or a single configuration that saves everyone money.
The changes I made to scheduled work
The audit pointed first to the model coordinating the work. Within the DMT parent-plus-worker text estimate, the Astra parents contributed about 98.3%; Luna research workers contributed about 1.7%. Removing the research workers would target a small component while risking useful research separation.
| Scheduled work | Applied model/agent decision | Reason |
|---|---|---|
| DMT content runs | Sol High orchestrator; retain Luna Max research, normally one reused worker with a bounded brief. | Reduce expensive coordination and duplicated history while retaining research and publication checks. |
| Gaming-site planning | Sol High, no routine subagents. | Planning does not need automatic parallel delegation. |
| Gaming-site publishing | Sol High; one Astra High critic when a publication package is ready. | Concentrate stronger review on a concrete deliverable. |
| Routine inbox triage | Luna Medium, no subagents. | Bounded extraction and categorisation. |
| Weekly growth brief and event detection | Retain Sol High for the brief; Luna Low detectors escalate to Sol Medium on material change. | Preserve existing task-specific routing that already separates detection from analysis. |
The changes preserve the existing source, duplicate, editorial and live-publication checks. That is a design decision to protect quality, not evidence that quality equivalence has already been demonstrated.
Repricing the identical historical DMT tokens with Sol parent rates and the same Luna workers reduces the estimate from 4,204.0 to 1,725.2 credits, or 59.0%. This is a same-token counterfactual. Sol may use a different number of requests or tokens, need corrections, or miss something Astra would catch. No 59% reduction in actual allowance usage has been measured.
I made no further blanket effort change after the context research. The stronger next decision would come from matched jobs: identical source packets, required evidence, output requirements and review criteria, with all retries and reviewer work counted. Change one factor at a time—model, effort or context threshold—and compare total usage per accepted result. Record failures and missing evidence alongside speed and tokens.
Experimental context management: how to enable it and test it usefully
Update, 10 September: experimental context management is different from increasing the window or changing the compaction threshold. OpenAI describes Astra keeping notes across context windows and searching earlier messages and tool results from the same task. That creates another way to recover details; it does not make retrieval free, guarantee perfect recall, or turn task history into cross-task memory. See the official experimental-context section.
The feature is off by default and requires a supported client and eligible ChatGPT sign-in. The Models page lists Plus/Pro; the current configuration reference also names Pro Lite. The Models page excludes Business, Enterprise and API-key sign-in at launch. Because that wording is not fully aligned, check the current client/account rather than infer eligibility from Astra appearing in the model picker.
1. Edit the configuration used by the client you actually run
The usual user file is ~/.codex/config.toml, or %USERPROFILE%\.codex\config.toml on Windows. A custom CODEX_HOME changes that location. Trusted project files and CLI overrides can take precedence; verify the intended layer using the configuration basics. Back up the file before editing.
Use one dedicated table. If it already exists, edit its value rather than adding a second copy:
[features.context_management]
experimental_mode = trueIf you already have a [features] table, you can instead merge the relative dotted key into that existing table:
[features]
# Keep your existing feature entries here.
context_management.experimental_mode = trueChoose one form. Do not combine a root-level features.context_management.experimental_mode = true assignment with a later [features] declaration. That exact combination failed in my current configuration. I moved the flag into its own nested table, preserved its intended true value, and verified that all other parsed settings were unchanged.
2. Verify syntax, client recognition and a new task separately
A valid file is only the first check. In this setup, the older codex command on PATH reported version 0.140.0 and rejected the nested feature map. The desktop’s 0.153.4 runtime accepted the file and listed context_management as enabled. I aligned the command with that verified runtime; existing terminals or their parent app need to reload their environment. This observation is not a universal minimum-version claim.
Use codex --version and codex features list in the client you intend to use. An enabled result confirms that client’s configuration recognition. OpenAI then requires starting a new task; continuing an existing one is not activation proof. Look for actual note/history behaviour during a genuine context transition before declaring a successful trial.
For an isolated CLI trial, current Codex supports a separate file such as ~/.codex/astra-context-trial.config.toml, selected with codex --profile astra-context-trial. Put the feature table in that file and keep it out of the shared base config if an older client must still read the base. A profile containing the flag cannot repair an already incompatible base file. Follow the current profile format, not older nested profile examples.
3. Keep the trial focused on context management
My recommended starting point is to leave the context-window and auto-compaction overrides unset, retain the same Astra effort as the comparison task, and change only the experimental mode. Do not simultaneously adopt a 400K window, a new effort level and extra workers. That would make any difference difficult to interpret. These are experimental-design choices, not measured optimal settings.
Make notes useful enough to replace re-reading, while preserving the evidence needed to check them. The following is a proposed task instruction, not a tested performance result:
Keep concise task notes covering the goal, constraints, accepted decisions, source paths or URLs with dates, unresolved questions and the next action. Preserve exact identifiers and facts needed for the next step. Treat current files and freshly checked sources as authoritative. After a context transition, retrieve the relevant history and recheck facts that may have changed. Keep full evidence in its source instead of copying entire logs into every note.
Use a small local facts file for the first trial. Record several exact fields and their source, then test recall after a real transition. Change one source field and ask again: a useful answer should use the current value and identify the stale note. Record retrieval calls, repeated reads, missing facts, corrections and total tokens as well as the final answer. The existing Astra notes guide contains the longer freshness fixture.
For content work, keep source research and factual review requirements intact. Return relevant excerpts and file pointers from tools, but do not impose such a small output limit that evidence becomes unusable. A short note that causes repeated searches can cost more than a longer useful one. Extra note-writing and history retrieval must be included in the result’s total usage.
Rollback is the same flag set to false in the same table, followed by a new task in a compatible client. If an old client cannot parse the nested table at all, remove the experimental table from the config it reads or isolate it in a supported-client profile; changing the boolean alone will not fix that parser error.
What the newer scheduled logs show so far
A separate snapshot at 09:15 IST on 10 September confirmed the revised runtime identities below. It is not part of the original 901-response sample. Counts include unique responses observed after the routing change, and the unfinished DMT row is a partial count.
| Newer work | Observed runtime | Responses / workers | What can be concluded |
|---|---|---|---|
| Gaming-site planner | Sol High | 109 / 0 | Completed planning receipt; queue and validation results recorded. No article published by this planner. |
| Inbox intake | Luna Medium | 19 / 0 | Completed task reported one verified intake item and no mailbox mutations. This is not a content-quality benchmark. |
| DMT content run | Sol High | 19 / 0 observed | No completed root-turn receipt at this cutoff; publication coordination was still constrained by the active case-study work. |
I inspected the planner’s saved receipt, including its source distinctions, retained performance-evidence block and recorded passing checks. The inbox statement is attributed to its completion record. The account allowance read 16% used during this follow-up, but it includes shared activity and this audit in a different weekly window from September 8. Neither that meter nor these different jobs establishes a before/after saving.
The evidence now supports that the intended routing is executing and that two early tasks reached completion records. It still does not establish equal quality across models, an Extra High advantage, or savings from experimental context management. I kept the scheduled model routing and context-size defaults unchanged.
A practical audit you can repeat
- Record the environment. Note the client version, actual runtime model/effort, processing mode and resolved context behaviour. Saved configuration is not always proof of the model that executed a historical request.
- Separate the counters. Keep unique response usage, cumulative status counters and the account allowance meter in different datasets. Deduplicate before aggregating.
- Plot input against response sequence. Mark compactions and task boundaries. Look for histories that remain large while unrelated work continues.
- Include every worker and retry. A cheap draft that needs expensive correction can cost more overall. A useful research worker can also save parent effort.
- Use honest denominators. Compare accepted work with the same review requirements. Requests per minute and quota movement during unequal windows answer different questions.
- Test the smallest useful change. Reduce unnecessary repetition or narrow orchestration first when the logs support it. Measure any context or effort change before recommending it broadly.
The case supports a specific conclusion: long-running orchestration can accumulate expensive repeated context even with a high cache rate and a default-sized working window. It does not support “always use Extra High,” “always use 400K,” or “smaller context always saves allowance.” Better routing, bounded context and a completed-work measure provide a more testable basis for decisions.
Method and disclosure
This case was prepared by Tayeeb Khan from his own Codex content-operations logs, with AI assistance for parsing, calculations and writing. Historical context findings cover three DMT Astra High parent runs on 8 September 2026. The original settings and source review was checked on 9 September. Newer run records, experimental-context documentation and executed configuration checks were added on 10 September; the historical 901-response sample is unchanged. Median values in the table are rounded to whole tokens; cost estimates are rounded after calculation.
The charts are original plots of sanitized measurements or explicitly labelled arithmetic illustrations. The settings image shows the local audit report; the API pricing screenshot shows the cited official page. The cover is an AI-generated editorial illustration and contains no measured data. Private prompts, account identifiers and raw operational logs are not reproduced.
No matched effort benchmark or post-change quality/savings study was completed for this article. Token-rate estimates are incomplete proxies for a subscription allowance. Community reports are attributed observations, and source availability may change. The useful outcome is a documented diagnosis and a reversible configuration decision, with the limits of the evidence visible.
