update
Jun 3, 2026
By Teun
Codex Reset Watchdog monitors public X for reset signals
A new Codex skill called Codex Reset Watchdog watches public X posts from Codex lead thsottiaux for possible quota reset signals. It can help users spot reset-related changes early and plan how to use any remaining Codex quota, including switching to fast mode when useful.
Show HN: Codex Reset Watchdog is a new skill that monitors public X posts from Codex lead thsottiaux for signs that paid Codex quota may reset soon. The project is designed to surface possible reset-related changes before they happen, so users can plan how to use the rest of their subscription quota more intentionally.
The skill works through Codex Automation, and the author says it does not require registration for any additional API. It also does not add extra costs, although running Codex Automation still uses Codex quota. The source article says users should create a dedicated Codex Project for the monitor, such as “Codex Reset Watchdog,” then start a new chat inside that Project and paste the installation prompt.
⚡ New to this?
This is a small automation project that watches public posts for clues that Codex usage limits may reset. A quota reset is when a service restores the amount of use a subscription allows, so users can decide when to save work and when to spend the remaining quota.
The post also references Codex Automation, which is the part that runs the task on a schedule, and JSON, which is a standard machine-readable data format used here for parsed results. The news matters because it shows how people are building monitoring workflows around platform signals instead of checking manually.
🦞 OpenClaw angle
If you build self-hosted agents, keep the monitoring logic and the execution logic separate, as this skill does with a checker script and an Automation wrapper. Put baseline state in a file and run a dry-run mode before trusting alerts, so your agent can dedupe repeated signals instead of spamming you.
If you are wiring similar workflows, store prompts in a dedicated file and load them at deployment time rather than hardcoding them into the runner. Also prefer a narrow scheduled job with local execution and a dedicated workspace root, so failures are easier to isolate and state writes do not affect unrelated projects.
According to the instructions in the post, Codex will install the skill by itself. The prompt tells Codex to quietly install, initialize, and enable codex-reset-watchdog from a GitHub repository at thinkingjimmy/codex-reset-watchdog, and to avoid progress narration or raw tool output unless approval is needed or a blocker appears.
The setup instructions also ask Codex to confirm that the installed or cloned source directory contains several files, including SKILL.md, scripts/check_once.mjs, references/automation-prompt.md, and .codex/config.toml. The article says the runtime files should then be prepared in the current workspace root, including SKILL.md, README.md, README.zh-CN.md, env.example, .codex/, agents/, references/, scripts/, and images/.
After that, the workflow calls for running node scripts/self_test.mjs, then node scripts/check_once.mjs --prime-state --json to create a baseline state. A second run with node scripts/check_once.mjs --dry-run --json is meant to confirm the public source, JSON parsing, and state deduplication behavior.
The article says the full contents of references/automation-prompt.md should be used as the Automation prompt. It also instructs users to create or update a cron Automation named Codex Reset Watchdog with hourly cadence, local execution, and the current workspace root as its working directory.
If the Automation tool is unavailable, the instructions say to search for automation_update first. If a matching Automation already exists, it should be updated rather than duplicated. The final step described in the post is to click Run Now on the Automation detail page and check the latest chat output inside the Codex Reset Watchdog Project.
