Codex, Woohoo-!

created: 2026.05.31. 00:33 · modified: 2026.09.25. 22:11 ·  · license
license

This post was automatically translated and has not yet been reviewed by me. Please read with discretion.

Lately, I’ve been using Codex to help modify codebases for my research, and I keep running into its usage limits. The way those limits work is interesting:

Usage is measured at two levels: five hours and one week (I understand Claude Code has a similar system). There are two straightforward ways to define the interval used to determine whether a limit has been exceeded. Taking the 5h level as an example:

1. Fixed intervals, such as 9 a.m.–2 p.m., 2 p.m.–7 p.m., and so on (fixed window)
or
2. The 5h immediately preceding a usage request (moving window)

Codex works somewhere between 1 and 2. If a user stops using it for a while and then resumes, a 5h window starts when they resume and resets five hours later. If someone used Codex around the clock, this would work much like option 1, but that’s not realistically possible.

This odd way of measuring usage creates a paradox: by using Codex more (strategically), you can actually increase how much you get to use it. Here’s a simple example:

Suppose someone arrives at work, does something that doesn’t require Codex, then uses up 100% of their 5h allowance on a Codex task at 11 a.m. Unless they buy additional credits, they can’t use Codex again until 4 p.m. But if they had done a quick task with Codex as soon as they arrived at 9 a.m., they could do another task at 11 a.m. that uses nearly 100% of the allowance, and their usage would reset at 2 p.m., giving them another full allowance.

You can exploit this to stretch your usage as far as possible. The key is to schedule a cron job that has Codex perform a task at set intervals starting early in the morning. That way, the reset happens automatically in the middle of the hours when I expect to be working most intensely. For me, 10 a.m., 3 p.m., and 8 p.m. would be good. The lighter the task, the better. I simply set it to shout “Codex, woohoo-!”:

This fixes the daily reset times at hours divisible by five without using even 1% of the 5h allowance.

In conclusion: Codex, woohoo-!

Update #1

Someone saw this post in my Instagram story and tipped me off: more than six months ago, someone had exactly the same idea and posted a GitHub Gist with a cron job script and an explanation of why they developed it. It also includes scheduling for Claude Code, so take a look if you’re interested.

Update #2

The cron job in the main post is just a baseline meant to illustrate the idea; you can add a few more features. Here’s the job I actually set up on my computer:

#!/bin/bash

LOGFILE="$HOME/logs/codex.log"

{
    echo
    echo "=================================================="
    date '+%Y-%m-%d %H:%M:%S'
    echo "=================================================="

    codex exec \
        '"Codex 야호-!"라고 출력해.' \
        --config model_reasoning_effort="low" \
        --skip-git-repo-check
} >> "$LOGFILE" 2>&1

chmod +x /Users/gunheeyi/bin/codex-log-test.sh

56 4 * * * /Users/gunheeyi/bin/codex-log-test.sh
58 9 * * * /Users/gunheeyi/bin/codex-log-test.sh
0 15 * * * /Users/gunheeyi/bin/codex-log-test.sh
2 20 * * * /Users/gunheeyi/bin/codex-log-test.sh

This adds the following:

1. exec mode & the --skip-git-repo-check flag: To run reliably as a cron job, it needs to run in non-interactive mode and skip the directory check.
2. >> "$LOGFILE" 2>&1: Saves the output to a log file so I can check whether cron ran successfully.
3. echo ~: Records the date and time in the log alongside the output.
4. --config model_reasoning_effort: Sets reasoning effort to its lowest level to minimize token usage.
5. The jobs run 5 hours and 2 minutes apart, rather than exactly five hours apart, in case a job runs faster than the previous one and therefore falls within the previous window without resetting it. (I haven’t tested this.)

One minor caveat: cron is configured on the local computer, so it won’t run while that computer is off. If you want the job to run reliably, you should leave the computer on or, ideally, schedule it on a server if you have one. Usage is shared among sessions on the same account rather than measured per device, so opening a window on a server should make that same window apply on other computers too. I haven’t rigorously verified this yet.