codenotch Review 2026 — A macOS Notch That Shows How Much of Your Claude Code, Cursor and Codex Limits You've Burned

The Problem: Usage Limits You Only Discover Mid-Thought

Every serious AI coding assistant meters you on rolling session windows. The standard way to know where you stand is to interrupt your flow, open the tool, dig into a settings or usage screen — or find out the hard way when the model stops answering because a limit reset. Now multiply that by the actual working pattern of 2026: Claude Code for one project, Cursor for another, Codex for a third, sometimes Antigravity or GLM in the same afternoon. There is no single place that answers the question that actually matters: which one still has room right now?

vinzdg’s codenotch, created September 5, 2026, is a macOS agent app built to answer exactly that. It pins a small black notch to a screen edge — a vertical pill drawn with inverse rounded corners so it reads as part of the hardware bezel — and each provider it tracks gets one cell: a progress ring sweeping clockwise from 12 o’clock, a percentage of the limit you have burned (not what remains), and a glyph. Hover a ring and a tooltip lists that provider’s limit windows and when they reset. In two days it passed 679 stars and 90 forks on an MIT license, which tells you how many people recognized the pain.

What It Reads: A Provider Matrix With No New Logins

The design decision that separates codenotch from a dashboard you configure by hand: it never signs in anywhere. Every reading is borrowed from a credential or session a tool on your Mac already holds, so install and sign in to any of them and its ring appears. The provider table in the README is specific about the source for each:

• Claude Code reads the OAuth token in the login keychain against the same endpoint Claude Code’s own /usage uses — which is why the ring’s headline number always agrees with what the tool itself reports. Two Claude Code logins become two rings: keep a work account apart with CLAUDE_CONFIG_DIR=~/.claude-work claude and you get a Claude (work) ring with its own limits, sessions and Settings row. Any ~/.claude-<slug> directory Claude Code has run against is found at launch; the default ~/.claude always comes first and the rest are alphabetical so rings never swap places.
• Cursor reads the editor’s own signed-in session from its local SQLite state — no separate sign-in.
• Codex asks its own app server live for the current rate limits, falling back to its rollout log when Codex is not running.
• Antigravity queries its local language server first, then Google’s quota endpoint, and falls back to a plain request count when neither will answer for the account.
• GLM reads Z.ai’s Coding Plan monitor endpoint, using a key borrowed from whichever coding tool already holds one — Claude Code’s settings.json, ZCode or OpenCode.

Switching a provider off in Settings stops its credential being read at all and forgets the readings taken from it; it does not sign you out of the tool that owns the account, and the row says so.

Fidelity, States and the Honest Caveat

The README’s architecture section is where codenotch earns its credibility. Every provider implements a UsageProvider protocol and declares its own Fidelity — .official, .derived or .manual — so the UI never presents a guess as if a vendor had published it. A UsageStore polls them on a timer, keeps the last good reading across launches, and degrades every failure to a visible status (stale, needsAuth, error) rather than a made-up percentage. The tooltip shows a ”~” prefix on any number the app derived rather than read from a vendor — the spec requires it, and even the demo fixture renders as “~73% Used” to prove the convention holds.

Then comes the honest caveat, stated plainly: no vendor publishes a clean “your session limit is N% used” API for any of these tools. Each adapter reads whatever the owning app itself reads from — an internal endpoint, a local database, a language server’s own RPC — and those can change without notice. Every adapter’s response shape is pinned by tests, and every failure degrades to a visible status. Two details show the engineering care behind that promise. The app is signed with a stable Developer ID identity so the one-time “Always Allow” grant on Claude Code’s and Antigravity’s keychain items survives rebuilds, and the secret is read only when the owning app has actually changed it — checked via the item’s modification date, which is not behind the same access prompt as the credential. And rate limits are handled with unusual discipline: Claude’s endpoint returns 429 with an unhelpful Retry-After: 0 if polled too hard, so the back-off treats that as a floor-raiser only — 60 seconds, doubling per consecutive 429, capped at 15 minutes — and the deadline is persisted, so relaunching during a penalty waits instead of spending an attempt on it.

The Notch, the Rings and the Live Session Status

The UI is deliberately restrained. At rest the notch is a small pill on the screen edge that unfolds when the pointer reaches it, configurable to always show or hide entirely; settings live in an orb below the notch. It works in one-dimensional stack space regardless of which edge it is on, and NotchPlacement is the only place that maps that back onto real screen coordinates. Right and left edges keep a vertical column; top and bottom lay readings out side by side. It pins to the usable edge, so a bottom notch rests on the Dock and follows when the Dock hides or moves, and on a Mac with a hardware notch the top placement takes its exact shape so the two read as one. Every measurement in NotchLayout is quoted from the design frame (docs/design/frame-124-hover-tooltip.png), and the code deliberately follows the frame where the prose spec disagreed — colour-band thresholds at 50% and 70%, hexes sampled from the frame, and the ring showing the session window rather than whichever limit is most alarming, so a number that means one thing never silently changes meaning.

The second question codenotch answers — beyond “how much have I burned?” — is “is it still working?” A thin arc spins inside a provider’s ring while a session is busy, and the ring becomes a pulsing amber when one is blocked waiting on you. Hover to see every live session by name, where it is running and what it wants. That turns the notch from a limit meter into an always-on status layer for every coding agent on the machine, which is the part usage panels never give you.

Honest Limits and Who It’s For

codenotch is young — 12 commits, 5 contributors and an 11-issue tracker in its first two days — and its open issues read like a healthy backlog rather than a bug list: Grok Build support (#17), a fix for the notch jumping between displays on multi-monitor Macs (#16), reading Codex account limits from the usage endpoint (#14), OpenCode Go plan windows via the official endpoint (#11), and a Windows port (#7) where a contributor is waiting on the maintainer. The TASKS.md file is equally candid about open product decisions: the final app name (Codenotch is a placeholder), whether plan ceilings should be configured by hand or inferred from observed peak usage, and whether web-session adapters (ChatGPT et al.) are in scope for v1 — the README notes Claude now answers that question for itself because its OAuth endpoint is in, which puts the same question live for OpenAI and Perplexity.

This is not a cost-reduction tool — that is Honey for Devs’ territory, which cuts token usage with a cross-tool skill. codenotch is a meter: it tells you where every assistant stands, when limits reset, and whether a session is grinding or waiting on you, without adding a single new login to your machine. For developers who juggle two or three coding agents across a day and have been caught mid-thought by a reset limit, that passive awareness is worth the install — with the honest caveat that the adapters’ underlying endpoints belong to the vendors, and the notch can only be as current as the tools it borrows from.