unsnooze Waits Out Your Usage Limit. It Lists Eight Agents and Properly Supports Two.

unsnooze is a free MIT tool that notices when your coding agent stops at a usage limit, then resumes the same session the moment the limit resets. It runs as a daemon, installs with one npm command, carries no telemetry. For anyone running long overnight sessions it solves a real problem. That problem got considerably worse this week.

Its documentation lists eight agents. Two of those have proper detection built for them. Six carry an experimental marker, including one whose limit the docs say cannot be waited out at all, which makes its presence on the list close to decorative. The one line repo description that gets copied into every search result and social post lists seven agents flat with no markers at all.

Best for Claude Code or Codex users running long sessions in a terminal multiplexer. Not ideal for anyone expecting the other six agents to work today.

On Monday, OpenAI halved what the $200 plan buys and removed the five hour window, so a weekly allowance became spendable in one sitting.

By Saturday there was an open source scheduler whose entire job is sitting out the reset.

Nobody builds that for fun. Somebody wrote a parser for the different ways vendors tell you that you are cut off. Then they handled daylight saving on top. Waiting by hand had become part of the working day.

What unsnooze Actually Is

Here is the verified spec, pulled from the project documentation plus the repository itself.

Deliberately absent from that table: star count, fork count plus commit dates. Two reads of the repository returned inconsistent numbers, including zero forks on a repository that demonstrably has forks, so none of it goes in. Nothing in this piece depends on those figures.

Why This Tool Exists Now

Usage limits used to be a thing you noticed occasionally. This week they became the main constraint on a working day.

OpenAI cut the $200 Pro tier from twenty times the Plus allowance down to ten. Weekly GPT-6 Pro messages went from 200 to 100. Then the five hour rolling window was removed entirely. That last change matters more than the first two. A weekly pool with no sub window can be emptied in an afternoon. Several people reported doing exactly that in under an hour on the new $500 tier.

Anthropic sits in the same territory from the other direction, which is why we keep pricing the Claude plans against the API rather than taking tier names at face value.

So the behaviour this tool automates is now routine. You start something long, it stops, you check a clock, you come back and type continue. Multiply that across a week and automating it stops looking like a novelty.

What removing the window changed

There is a second effect that gets less attention. Removing a sub window changes how people work, not only how much they get. With a five hour bucket you naturally pace yourself, because the next refill is close enough to plan around. With a single weekly pool the incentive flips toward spending hard while you have it, which empties the allowance faster and makes the dead time afterwards longer.

Tooling follows behaviour. A tool that waits out a five hour reset saves you a coffee break. A tool that waits out a weekly reset is covering days, which is the difference between a convenience and a scheduler you leave running.

That context is also why the gap in the description matters. A tool arriving in the middle of a genuine pain point gets shared fast, with whatever words came attached to it.

Eight Agents Listed, Two Actually Supported

The supported agents page is honest. It marks what is experimental. Almost nobody reads it though, because the one line description travels instead.

The two that work

Claude Code gets two detection channels. The StopFailure hook is authoritative plus it carries the session id, which is what lets the tool resume the correct session rather than guessing. Pane scraping runs alongside it as a backup.

OpenAI Codex CLI gets scrape based detection only, because Codex fires no event when it hits a limit. The tool reads the terminal pane, finds the banner, then parses the reset time out of whatever string the vendor printed.

Those two are the product. Everything after this point carries a marker.

The six that are marked experimental

Grok Build, Qwen Code, Kimi CLI, OpenCode, Antigravity CLI plus Cursor CLI all appear with an experimental label. The repository README is blunter about one of them, describing Grok support as relying on pattern matching with generic fallbacks and unconfirmed banner text.

Unconfirmed banner text is the honest version of the whole situation. Detection works by recognising the exact words a vendor prints when it cuts you off. If nobody has confirmed what those words are, the tool is waiting for a string that may never arrive.

None of that makes the project bad. Six experimental integrations attempted by what looks like a very small team is ambitious rather than careless. Every label is right there on the page.

The One That Cannot Work

Cursor CLI deserves its own section, because its entry says something the list format hides.

It appears as the eighth supported agent, marked experimental like the others. Then the documentation adds that it is the only agent whose limit is not waitable.

Read that again against what the tool does. The product detects a limit, waits for the reset, then resumes. If a limit cannot be waited out, there is nothing for the core mechanism to do. Cursor’s presence on a list of supported agents is a statement that somebody tried, rather than a statement that it works.

To be fair, the docs say so plainly in the same sentence. The failure is purely one of format. A bulleted list of eight names with small italic markers reads, at a glance, as eight things that work. Nobody skims a list looking for the item that contradicts the product.

This is the same shape we found when counting what shipped inside vendor agent skill collections. The accurate information was published. The format let people take away a bigger number than the facts supported.

Three Repositories, One Original

Before anything else, a practical warning about installing this.

Search for unsnooze on GitHub and at least three repositories come back with the same name plus a byte identical description. They look interchangeable in a results list. Checking one of them directly shows the line forked from saaranshM/unsnooze at the top of the page, which settles it: saaranshM is the original, the others are copies.

That matters more for a tool like this than for most. unsnooze runs as a background daemon, reads your terminal panes, then issues commands into your sessions on your behalf. A fork that has drifted from upstream, or been modified, is a program with that level of access that nobody is maintaining.

The project documentation names the canonical repository plainly, so the information is available. The problem is that a search result does not show you which entry is upstream until you click through, plus the npm install command is identical whichever page sent you there.

So take the install line from the documentation site rather than from whichever repository a search put first. That is thirty seconds of checking against handing terminal access to an unmaintained copy.

Why It Has to Scrape Your Terminal

The technical detail worth sitting with is that only one of these agents gives the tool a proper signal.

Claude Code fires a StopFailure hook when it stops, carrying the session id. That is the clean path. A program can listen for an event, read the id, schedule a wake, then resume exactly the right thing.

Codex fires nothing. So the tool watches the terminal pane and reads the banner like a person would. It then parses whatever format the reset was printed in. The documentation lists clock times such as try again at 3:51 PM, absolute dates plus duration strings. On top of that it handles daylight saving, because a reset time printed before a clock change lands in the wrong place otherwise.

What that tells you about the vendors

Scraping is what you do when there is no interface. A tool that has to read pixels of text off your screen to learn that you are rate limited exists because the thing doing the limiting never offered a way to ask.

That is the genuine finding here. It is also bigger than this one project. Every agent vendor has shipped elaborate plugin systems, hooks, MCP servers plus skill directories. We walked through the sprawl of it in our OpenClaw deep dive. Almost none of them expose the one piece of state that now governs whether you can work: how much allowance you have left and when it comes back.

One agent fires an event. Seven do not. A third party had to write a text parser plus a daylight saving correction to recover information the vendors already have.

What Each Detection Path Costs You

The two working paths are not equivalent, which is worth understanding before you trust either with an overnight run.

The hook path is reliable because it is explicit

Claude Code’s StopFailure hook is an event the agent deliberately fires. It carries the session id, so there is no ambiguity about which session stopped or which one to resume. If you have five panes running, the right one comes back.

That path breaks only if the hook interface changes, which would be a documented change to a documented feature. You would get a release note.

The scraping path is fragile because it is inferred

Codex gives no event, so the tool reads the pane and matches text. Three things can quietly break that.

A vendor can reword its limit message, at which point detection stops and no error appears. A vendor can change the reset time format, at which point the parse fails or produces a wrong time. Anything that alters how text reaches the pane can also stop a pattern matching. A different multiplexer setting will do it. So will an unusual terminal width wrapping the banner mid sentence.

None of those produce a crash. They produce a session that sits there until you come back and notice. For a tool whose entire value is unattended operation, silent failure is the worst available failure mode. That is why the documentation’s experimental labels deserve to be read literally rather than as early access marketing.

The practical upshot is simple. On Claude Code you are relying on an interface. On everything else you are relying on a string match holding, which is a bet on seven vendors not editing their own error messages.

What the Description Field Does to a Project

Worth being precise about where the overselling actually happens, because it is not the documentation.

The repository description reads as a flat list of seven agents, with the environments named alongside, no markers anywhere. That single line is what GitHub search results show, what aggregators copy, what social posts quote plus what most people will ever read about this tool.

The docs page one click away marks six of those agents experimental and flags that one of them cannot work at all.

So the honest layer is the documentation and the lossy layer is a 200 character field that was probably written in thirty seconds. Which is the pattern we keep running into from different directions. A vendor publishes a caveat and transmission strips it. Here the project publishes a caveat and its own metadata strips it before anyone else gets a chance to.

The fix is small enough to be annoying. Two words in the description, experimental support, would carry the whole caveat into every place the line gets copied.

What You Should Actually Do

If you run Claude Code or Codex in tmux and you are hitting limits, install it. Those are the two paths with real detection behind them, the licence is MIT, there is no telemetry plus it costs nothing. Node 20 or newer, zsh or bash, plus WSL if you are on Windows.

If you run any of the other six agents, treat it as a project to watch rather than a tool to depend on. Experimental here specifically means the banner text may not be confirmed, so test it against a real limit stop before you trust it to recover an overnight run. The failure mode is not an error message. It is a session that quietly never resumes.

If you use Cursor CLI, this does not solve your problem, by the project’s own account. Its limit cannot be waited out, so no amount of waiting recovers the session. Your options there are a second account or a different agent for long runs.

If you are building rather than installing

If you are building anything in this space, the gap is obvious and nobody is filling it. The reason a tool has to scrape terminal output is that no vendor exposes allowance state. An agent that could ask how much is left and when it resets would not need any of this machinery. The same information would make scheduling, cost control plus automation routing considerably easier than they currently are.

One more habit worth building if limits now shape your day. Record when your own resets land. None of these vendors surface it programmatically, so the fastest substitute is writing down the time you get cut off plus the time it comes back, twice. After that you can schedule around your own pattern without any tooling at all, which is less satisfying than a daemon but fails in no interesting ways.

And whatever you run, do the thirty second check before installing anything from a search result. Open the docs, count the things marked experimental, then compare that against the description that brought you there. On this project those two numbers are six apart.

What This Says About the Category

Step back from the tool for a moment, because the shape of the problem is the durable part.

Agent vendors spent 2026 building extension surfaces. Hooks, plugins, MCP servers, skill directories, mods, marketplaces. We have covered most of that build out, including the skills marketplaces plus the repos people actually run rather than only star.

In all of that, the single piece of state that now decides whether you can work remains unexposed. How much allowance is left. When it comes back.

Claude Code is the exception, firing an event when it stops. Seven others do not, which is why a third party had to write text matching plus timezone correction to recover a number the vendor already holds.

There is a reasonable argument for the omission. Allowance accounting is messy, varies by plan, changes often, then becomes a support burden the moment it is public and slightly wrong. An endpoint that reports the wrong number is worse than no endpoint.

The counter argument is that users are now reverse engineering it anyway, badly, from error messages. The information is reaching people regardless. It is just reaching them through a daemon that scrapes a terminal and guesses, rather than through anything the vendor controls or can correct.

That is the position the whole category sits in this weekend. Limits are the binding constraint on paid work. The people selling them have not shipped a way to ask about them.

The Part Worth Keeping

A free MIT tool with no telemetry, solving a problem its author clearly hit personally, with documentation that labels its own rough edges accurately. That is a good piece of work and the criticism here is narrow.

What the project cannot fix is the reason it needed to exist.

Somebody spent their weekends writing a daylight saving aware parser for error banners. Eight different vendors sell you an allowance, then give you no programmatic way to know what is left of it. One of the eight fires an event. The rest make you read the screen.

The honest reading is that this tool is a workaround for an interface nobody has built. It will keep being necessary until a vendor decides that telling you how much you have left is worth an API endpoint.

Until then the best version of this is the one that fails loudly. A scraper that cannot find its banner should say so on the spot rather than waiting politely for a string that changed last Tuesday. That is a small ask of the project, plus it is the only protection available while detection depends on guessing what somebody else printed.

Charts and Blocks

Support, as the documentation states it

What the week did to the limits