Quick conclusion
Between September 22 and October 4, 2026, my Codex weekly limit kept disappearing faster than I expected, and my scheduled runs kept stopping. I read the local logs and found two separate problems.
First, my automations stopped for several reasons that had nothing to do with token counts. One cause is visible in the logs: I had added a folder on a Google Drive virtual drive as a writable root, and for about half an hour on October 1 the Windows sandbox’s setup failed on exactly that folder, so commands could not run. Second, GPT-6 Sol used about 3 to 4 times as much weekly quota as GPT-6 Luna per input token in my logs, even though Sol’s API price is 20 times higher. That ratio comes from only five Sol sessions, so treat it as a range, not a constant.
I have not re-measured anything since. There is no before-and-after test in this article, only what the logs showed.
The first fix I dropped
The trigger was one evening on September 23. I asked Sol for two small jobs: refill a stock of social posts and run my end-of-session wrap-up. The session took about 45 minutes, and it used 111 model responses and about 23.7 million input tokens. Weekly usage went from 6% to 16%.
I first asked ChatGPT to investigate, and it wrote two reports based only on what it could read on GitHub: public Codex issues and my notes repository. Both missed my local settings and my local logs. Codex writes a record of every session to ~/.codex/sessions/**/rollout-*.jsonl, including input tokens per response and the weekly and five-hour quota percentages. So I had Claude Code read those files instead.
The first proposal was to lower my default reasoning effort from xhigh to medium. The logs did not support that as the main lever. In the Sol session, reasoning output was about 16,000 tokens against 23.7 million input tokens, roughly 0.07%. What drove the quota was the number of responses multiplied by the size of the context re-sent each time: about 213,000 tokens per response on average, with 98.8% of it cached.
I also run Luna at xhigh on purpose, and across September 22 to October 4 Luna accounted for about 85% of the roughly 1.59 billion input tokens in my rollout files, about 54% of the total at xhigh. That is how I use the model, so I dropped the effort change. This does not show that effort never matters. I did not test whether higher effort causes more tool calls, which would raise the response count indirectly.
Why my scheduled runs stopped
The more urgent problem was that unattended runs often did not finish. I found at least four causes.
1. A writable root on a virtual drive (the failure is in the logs; the explanation is mine). I had added a folder on a Google Drive virtual drive as a writable root for the Codex sandbox. The sandbox log shows 19 setup runs that ended with errors, and every one traces to the same step: granting a write permission to that folder failed. All 19 fall between 06:01 and 06:32 JST on October 1. In the same half hour, one scheduled run recorded 18 tool calls that failed to start with “setup refresh had errors.” In the sandbox logs from September 20 to October 7, no other day contains an error naming that folder.
My explanation is an inference: a virtual drive may not accept the permission change the sandbox applies, and one failing root may be enough to stop the whole sandbox from starting. I did not test that directly, and the timeline argues for caution. The folder stayed in my configuration until I replaced it with a local mirror of the same folder on October 3, yet the errors stopped after 06:32 on October 1, and later sessions ran without them. So the logs show the failure and the folder it named. They do not show that this folder was the only thing keeping commands from running, or that the later switch fixed anything. Setup errors of this kind also appear at other times in my logs, in August and on September 10 for other folders, and on October 10 and 12 for a different reason. I did not run a clean on/off test, so I treat the link between the folder and the stall as likely, not proven.
2. A tool mismatch. My automation instructions assumed dedicated file read, write, and edit tools. Codex exposed only a shell command tool and a patch tool. Two scheduled runs stopped for that reason, on September 30 and October 2. A manual run on October 1 succeeded, and I do not know what differed.
3. Approval prompts with nobody to answer them. A fixed network command failed on its first attempt with WinError 10013 and succeeded when retried with elevated permission. Across four runs of those routines, 36 commands ran with elevated permission in total, these retries included. In an interactive session I click approve. In an unattended run nobody can. This matches the structure of the logs, but I did not capture a single run that was actually stopped on an approval prompt, so I list it as likely, not confirmed.
4. Scheduled runs did not behave like my interactive session. In one check on October 3, a read-only fetch from a scheduled run failed DNS lookup on all five sites it tried, and it was not waiting on an approval. The settings I see in my interactive session did not seem to carry over, and I did not isolate why.
I did not fix all four. I moved those scheduled tasks to a different tool instead of keeping them on Codex.
How fast Sol and Luna drain the weekly limit
Sol’s API price is $2 per million input tokens and $10 per million output tokens. Luna’s is $0.10 and $0.50. That is a 20x gap. I wanted to know whether my subscription quota followed the same ratio.
I took the GPT-6 sessions from September 22 to October 4 that did not overlap with another session and did not cross a weekly reset, and divided the weekly quota points they used by their input tokens. That left six Luna sessions and five Sol sessions.
| Model / effort | Sessions | Input (millions) | Weekly points per 10M input | Five-hour points per 10M input |
|---|---|---|---|---|
| Luna / xhigh | 6 | 63.6 | 1.1 | 4.1 |
| Sol / medium | 4 | 40.3 | 4.0 | 27 |
| Sol / high | 1 | 23.7 | 4.2 | 28 |
Per input token, Sol used roughly 3 to 4 times as much weekly quota as Luna at xhigh, and the five-hour window pointed the same way at a larger multiple. Total input was almost the same on both sides, 63.6 million for Luna and 64.0 million for Sol. Luna wrote about 643,000 output tokens against about 159,000 for Sol, and it still drained less.
The caveats are large. Five Sol sessions is a small sample, and weekly usage is reported in whole percents: the six Luna sessions add up to just 7 points. I left out every session that overlapped with another one, which removes most of my heaviest runs, so this sample is not typical of my total usage. My settings also changed during the period (the auto-compaction limit and the default effort), and I did not control for that. My plan is ChatGPT Plus, and I cannot say how these numbers would look on another plan.
With those caveats, the gap in quota was about 3 to 4 times, well short of the 20 times gap in API prices. The logs record usage percentages but not how Codex weights each model when it counts them, so the cause of the gap stays open.
The shape of the work mattered too, separately from the model. In the September 23 Sol session, once my wrap-up routine began, it took about 64% of the five-hour usage and about 80% of the input. That routine archives files, runs lint checks, stages changes, scans for secrets, and commits, one small step per response, while the context was already above 200,000 tokens. The actual job I had asked for used far less than the routine that closed it.
What I looked for and did not find
My working suspicion was that Sol forces some hidden repeated reading. I did not find evidence of that, which is not proof it does not exist. The fixed-context, image-read, and instruction-file figures below come from my earlier working notes, and I did not re-measure them for this article.
- Fixed context. Every response carried about 85,000 to 93,000 characters of fixed instructions and tool descriptions, roughly 25,000 to 30,000 tokens, on every model I checked. That is a fixed cost, not a Sol-specific one.
- Serial round trips. In one 132-response session there were 117 tool calls, close to one command per response. Batching several commands into one step would lower the response count. I do not know whether the model or my workflow is the bigger reason they were not batched.
- Large reads. One Luna session read image output equal to about 9 million characters. Viewing images to check diagrams can be expensive.
- Instruction files read at startup. My unattended runs read roughly 180 to 210 KB of instruction files before doing any work, and every later response re-sent them. I did not measure how much of the weekly drain that explains.
I also compared token volume with Claude Code. Over the same period and in the same Vault, Claude Code processed roughly 1.9 to 2.1 billion input tokens, cache reads included (two counts made days apart differed by that much), against about 1.59 billion in Codex’s rollout files. The two were in the same range, with Claude somewhat higher. That compares token volume only. It says nothing about quota share, and I do not know the size of my Claude quota. It does suggest that Codex reading far more than Claude is not what explains the drain.
Check your own rollout logs
You can reproduce this without special tools.
- Collect the
rollout-*.jsonlfiles for your period from~/.codex/sessions/. Older sessions may have been moved to~/.codex/archived_sessions/, so check both folders. - In each file, read the
token_countevents. Each one haslast_token_usage(input, cached input, output, and reasoning tokens for that response) andrate_limits, wheresecondary.used_percentis the weekly percentage andprimary.used_percentis the five-hour percentage. - Per session, total the input tokens and count the responses.
- Take the change in
used_percentbetween the first and last event of the session. - Throw out sessions that overlapped in time or crossed a reset, then divide points by input tokens.
Step 5 is where most of the noise comes from, because overlapping sessions and resets mix quota points from different work. Whole-percent rounding means short sessions tell you very little.
What I have not measured
This covers September 22 to October 4, 2026, one account, one plan, and one Windows machine. I made no change aimed at the quota afterwards, and my settings were already moving during the window (the auto-compaction limit went from 900,000 to 300,000 tokens on September 24, and the default effort changed several times), so there is no clean before-and-after comparison. I did not capture an automation stopped on an approval prompt. The virtual-drive explanation is untested. The Sol ratio rests on five sessions. I will re-measure only if I start running automations on Codex again.
FAQ
Does a higher reasoning effort drain the weekly limit?
In my Sol session, reasoning output was about 0.07% of input, so effort was not the main driver there. I did not test whether higher effort leads to more tool calls and therefore more responses.
Is Sol a worse deal than Luna?
Per input token it spent more quota, about 3 to 4 times in my small sample. The API price gap is 20 times, so the quota gap is much narrower than the price gap. Which one is better depends on the task, and I did not compare output quality.
Can I use a Google Drive folder as a writable root?
In my case the sandbox setup failed on that folder for about half an hour on October 1. My explanation, that the virtual drive rejects the permission change, is an inference, and I did not run a clean test. I have not seen the same failure with a local folder.
Why did my unattended run stop with no clear error?
It can be any of the four causes above. Check the sandbox log in ~/.codex/.sandbox/ for permission errors first, then look for retries that needed elevated permission.
Next steps
I will re-measure the same kind of work only if I run automations on Codex again. For how I divide work among ChatGPT, Claude, and Codex in the first place, see ChatGPT vs Claude vs Codex: How I Actually Use All Three to Run My Blog.