Forem: Woojin Ahn

A 13MB Cursor Monitor: AppKit, Undocumented APIs, Zero Dependencies

Woojin Ahn — Fri, 13 Mar 2026 16:54:49 +0000

My company recently started supporting Cursor, so I jumped in. But checking usage meant opening the dashboard every time — and if Max mode was on without me noticing, requests burned through fast.

I wanted a glanceable counter, always visible.

So I built one.

V1: SwiftUI — Done in a Weekend, Regretted in a Week

The first version took two days. SwiftUI's MenuBarExtra made it trivial to get something on screen. I was proud of it.

Then I checked Activity Monitor.

56 MB of memory. For a menu bar app that displays a single number.

I tried to optimize — removed animations, simplified views, cached aggressively. Nothing moved the needle. The SwiftUI runtime itself was the cost. MenuBarExtra allocates a full SwiftUI rendering pipeline whether you need it or not.

For a "set and forget" menu bar app that runs 24/7, 56MB felt like a tax I shouldn't be paying.

The Rewrite: Burning It All Down

I threw out the entire UI layer and rebuilt everything in pure AppKit. NSStatusItem, NSPopover, NSViewController — the APIs your framework tries to hide from you.

It was painful. SwiftUI's declarative bindings became manual NSTextField updates. Layout constraints replaced VStack. Every state change needed explicit UI synchronization.

But the result:

	SwiftUI	AppKit
Memory (RSS)	~56 MB	~13 MB
Lines of UI code	~200	~660

3x more code, 4x less memory. For a menu bar app, I'd make that trade every time.

Other SwiftUI-based menu bar apps I've seen typically sit around 30–50MB. The framework overhead is real.

The API That Doesn't Exist

Cursor has no public API for usage data. But their dashboard has to get the numbers from somewhere.

Browser DevTools → Network tab → three requests:

/api/usage — per-model request counts
/api/usage-summary — billing cycle, plan usage in USD cents
/api/auth/me — user info

No documentation. Cookie-based auth. The response shape has changed at least once since I started.

This meant two things:

1. No hardcoding. The /api/usage response contains model names as dynamic keys. If Cursor adds claude-4-opus tomorrow, the parser picks it up automatically — no app update needed.

2. Expect failure. Both API calls run in parallel. If /api/usage-summary fails but /api/usage succeeds, the app shows what it can. If both fail, it shows the last known data. The app never crashes on an API change — it just degrades gracefully.

Zero Dependencies, on Purpose

The Package.swift imports nothing. No Alamofire, no KeychainAccess, no SwiftyJSON. Just macOS SDK frameworks.

This wasn't ideology. It was pragmatism:

The app does three HTTP requests. I don't need a networking library for that.
Keychain access is ~80 lines of Security framework calls. A dependency would be longer.
JSON decoding is Codable. It's built in.

The side benefit: no supply chain to audit, no version conflicts, no "this dependency requires macOS 15 but I target 14" surprises.

What I Actually Learned

AppKit isn't dead — it's just unfashionable. For long-running, low-footprint apps, the memory savings are real and measurable. SwiftUI is better for most things. But not this.

Swift 6 strict concurrency is worth the pain. The API client is an actor. The UI is @MainActor. All models are Sendable. It took effort to get it compiling, but an entire category of bugs simply can't happen now.

Build for the API to break. When you depend on undocumented endpoints, "it works today" is the only guarantee. Dynamic parsing + graceful degradation isn't a nice-to-have — it's the whole architecture.

The App

CursorMeter is open source (MIT). macOS 14+, zero dependencies, ~13MB memory.

curl -sL https://raw.githubusercontent.com/WoojinAhn/CursorMeter/main/Scripts/install.sh | bash

If you use Cursor daily and want to keep an eye on your usage without opening a browser, give it a try. Issues and feedback are always welcome.

I built a GitHub star monitor in a single YAML file — zero dependencies, zero config

Woojin Ahn — Sat, 21 Feb 2026 09:21:27 +0000

GitHub doesn't notify you when someone stars your repo. Or unstars it. You either refresh your profile page like a maniac, or you just... never find out.

Tools like star-history.com let you look up trends, but you have to visit the site every time. GitHub Apps like Star Notifier automate it, but now a third-party service is handling your tokens. Self-hosted solutions like github-star-notifier need a server running somewhere.

I wanted something automatic that requires zero infrastructure. So I built it using nothing but GitHub Actions.

What it does

GitHub Star Checker monitors star counts across all your public repositories and notifies you when stars change — gains or losses.

Runs every hour by default (configurable from the GitHub UI)
Sends alerts via GitHub Issues or Gmail
Generates weekly and monthly reports
All logic lives in a single workflow file

No server, no database, no dependencies — just one YAML file and GitHub's free compute.

How it works

A cron job triggers every hour on GitHub Actions
Fetches star counts for all your public, non-fork repos via the GitHub API
Compares with the previous snapshot stored in stars.json
If anything changed → sends a notification
Commits the updated data back to the repo

The workflow updates itself — including the schedule and notification settings — so you configure everything from the GitHub UI. No code editing needed.

Since it runs in its own forked repo, your existing repositories stay completely untouched.

What the notifications look like

GitHub Issue alert

Email alert

Weekly report

Setup in 60 seconds

Fork the repo
Enable workflows in the Actions tab
Add your Personal Access Token (repo + workflow scopes) as STAR_MONITOR_TOKEN in Settings > Secrets
Run the workflow — done.

The first run records your current star counts. From the second run onward, you'll get notified about any changes.

That's it. No YAML to write, no config files to edit, no CLI to install.

Why not just use a GitHub App?

Fair question. Apps like Star Notifier are convenient — install and go. But:

They're third-party services processing your GitHub data
You can't customize the logic or notification format
If the service goes down or gets discontinued, you lose it

This project is entirely yours. It's a fork in your account, running on GitHub's own infrastructure. You can read every line of code, modify anything, and it'll keep running as long as GitHub Actions exists.

Interesting technical bits

Self-modifying YAML: When you change settings via workflow_dispatch, the workflow uses sed to update its own cron schedule and env variables, then commits the change. Future runs pick up the new settings automatically.
Zero-conflict git strategy: The workflow stashes local changes, rebases on remote, then pops — handling concurrent scheduled runs gracefully.
32-day history retention: Daily snapshots are stored in stars-history.json for weekly/monthly reports, with automatic pruning.

Limitations

Being honest about the trade-offs:

Not real-time: GitHub Actions cron can delay 5–30 minutes. This is periodic monitoring, not instant webhook-based alerts.
Notification channels: Currently supports GitHub Issues and Gmail. No Slack/Discord/Telegram yet (PRs welcome!).
Commit history: The workflow commits stars.json updates to the forked repo. This is by design (persistence without external storage), but your fork's commit log will grow over time.
API usage: Each run makes one paginated API call. Even with 100+ repos, it stays well within GitHub's rate limits.

Try it out

👉 github.com/WoojinAhn/github-star-checker

Fork it, set one secret, and forget about it. You'll know when your stars move.

If you find it useful, a ⭐ would be appreciated — and yes, I'll get notified about it 😄