observed reset log

Resets we saw land

One poller on a home Mac reads a handful of Claude Code and Codex subscriptions every quarter hour and writes down every reset that actually arrives: when, on which plan, how full the window was before and after, and how many accounts moved at once. Announcements say a reset is coming. This is where it landed. No names, no emails: each account is a short anonymous key.

3What a reset is worth

How much of a window a reset gives back depends on how much of it was used, so one reset says little. Once three early resets or credit spends have landed on the same plan and window, the median points restored shows here.

Not enough yet: no plan has three resets on one window.

4How this works

ovm limits keeps each subscription signed in to a home of its own and asks the products themselves: Claude Code hands its usage windows to its statusline in a throwaway session, Codex answers over codex app-server. Every poll is compared with the one before. Inside a window usage only climbs, so usage that fell before the window was due is an early reset. If the account's own reset credits dropped at the same moment, it is a credit spend. A window that sat at 100% and rolled over is a limit lifted. Scheduled rollovers below that are the clock and stay off the page.

Several accounts moving within ninety seconds of each other is the provider handing out a reset; one account on its own is usually its owner spending a credit. The announcements column is agentresets.com's list, fetched by the poller at most once an hour and matched to a reset when one landed within 36 hours of it. The plan is the tier the product reports for the login. Accounts appear only as a salted key, so the same account keeps the same key and nothing else.

curl -fsSL https://ovm.sh/install | sh
ovm limits                       # register, sign in, poll
ovm limits hook ntfy <topic>     # phone push on an early reset
ovm limits agent install --every 15m

The feed itself is a small JSON file: resets.json.