![\"\"](\"https://steipete.me/assets/img/2025/vibe-meter/hero.jpg\")
My Cursor bill hit $900 for the month. I needed a simple way to track AI spending without constantly checking dashboards. That frustration sparked Vibe Meter - my first shipped Mac app built in three intense days.
\nWhat started as a workshop demo became a sophisticated menu bar utility using Swift 6, SwiftUI, and extensive AI assistance.
\nI had several AI models analyze the VibeMeter codebase:
\nO3: “Name vs. purpose mismatch – it sounds like a mood tracker, but monitors AI-API spending.”
\nClaude Opus: “86% test coverage is extraordinary. Code quality rivals what I see in major tech companies. This isn’t just a ‘side project’ - it’s a case study in how to build macOS software the right way.”
\nGemini: “Intentionally over-engineered for future growth.”
\nI ran a live workshop demonstrating AI-assisted development. Since Cursor lacks a public API, we reverse-engineered their web interface, extracted cookies, and called internal endpoints. Built both Electron and macOS versions in parallel.
\nThe feedback surprised me - people actually found it useful. When Gergely Orosz mentioned linking to it in his newsletter, I spent two more days polishing the rough demo into something shippable.
\nCursor has no public API for cost control, and it was somewhat messy because I have an enterprise account while many people have individual accounts, and the API endpoints are quite different. Getting both right was tricky.
\nSpecial thanks to Oliver Drobnik for helping me fix the individual account parsing. The second 90% of finishing an app always takes longer than the first 90%.
\n\n\nLooking for testers: Need someone with multiple Cursor teams to help test. Current implementation assumes one team only.
\n
I used SwiftUI wherever possible, but macOS menu bar apps expose the framework’s limitations. Need a popover without the arrow? Drop down to AppKit. Want to show settings from a menu item? More AppKit gymnastics.
\nI needed a custom NSPanel for precise menu bar control. Memory management got tricky in release builds - weak references to windows deallocated before appearing.
\nEven showing settings required a reflection hack accessing internal NSMenuItem properties. Apple deprecated the old methods, but the “correct” SwiftUI approach only works from SwiftUI views.
\nI’m proud of the animated menu bar icon. Almost used Lottie, but SwiftUI was enough. ChatGPT converted a static icon into animatable code.
\nThe gauge moves with spending levels, uses conic gradients for loading shimmer. ImageRenderer converts SwiftUI to NSImage for the status item.
\nThis was my first production app using Swift 6’s strict concurrency model. The architecture heavily relies on actors for thread safety:
\n@MainActor isolation for UI componentsasync/await throughout, ditching Combine entirelyThe learning curve was steep - debugging UNUserNotificationCenter delegate callbacks firing on background threads while trying to update @MainActor state was particularly painful.
One bug drove me crazy: perfect in debug, window wouldn’t show in release. SwiftUI view held weakly by AppKit disappeared before display. No crash, just nothing.
\nClaude figured it out when I explained the symptoms. Reminder: always test release builds.
\nThe hardest part wasn’t coding - it was signing, notarization, and distribution. Apple’s process is error-prone: you can notarize an app but miss deep notarization of embedded frameworks (like Sparkle), leaving you with a partially notarized app that won’t run.
\nRather than wrestle with Fastlane, I built custom shell scripts that are much more debuggable. Now Claude can create releases by simply running “make a new release 1.1 beta 1” - the automation is beautiful once set up.
\nThe scripts handle everything: incrementing build numbers, creating DMGs, uploading to GitHub releases, generating Sparkle appcast files. The most complex part was handling Sparkle’s EdDSA signatures correctly - the error messages when you get it wrong are cryptic at best. Pro tip: always test your update feed locally before pushing.
\nThough Vibe Meter only supports Cursor currently, the architecture anticipates multiple providers. The MultiProviderDataOrchestrator and protocol-based design make adding OpenAI or Anthropic straightforward when the time comes.
\nI really had to hold myself back from implementing OpenAI and Anthropic support right away. When I realized this would be useful for tracking all AI costs - not just Cursor - the temptation was strong. But I knew if I started adding providers, I’d never ship. So I built the architecture to support it but forced myself to ship with just Cursor. This is definitely coming in a future update.
\nThe multi-provider design might seem like overkill, but it’s already paying dividends. When debugging, I can easily add a mock provider that returns test data. The orchestrator handles provider failures gracefully - if Cursor’s API is down, the app doesn’t crash, it just shows cached data with a subtle indicator.
\nSmall touches matter. The app includes:
\nI constrained every file to under 300 lines - agents make fewer mistakes with smaller files. This forced better organization and created a more maintainable codebase for both humans and AI. Using Tuist for project generation also helped since agents struggle with Xcode’s complex .pbxproj files.
What emerged surprised even me:
\nThe largest files respect the 300-line constraint: ApplicationMover.swift (390 lines), SparkleUpdaterManager.swift (361 lines), and Color+Theme.swift (358 lines). The build infrastructure alone required comprehensive scripts for code signing (349 lines), release automation (314 lines), and notarization (312 lines).
\nI wanted to see how well AI generates tests. For a hobby project like this, I probably wouldn’t have written any. But they caught real bugs:
\nThe UserDefaultsBackedAdvancedTests alone has 374 lines testing every possible edge case of property wrappers. Did we need all of them? Probably not. Did they catch bugs? Absolutely.
\nContext windows matter. I ran six Claude instances concurrently - one for linting, one for tests, one for UI, one for features, one for bugs. First time trying this strategy. Worked beautifully. The more an agent knows about previous related tasks, the better it performs.
\nSmall files matter. The 300-line constraint prevented agent editing mistakes and forced better architecture. What seemed like a limitation became a forcing function for good design.
\nSwiftUI has come far. Despite the AppKit gymnastics required for menu bar specifics, SwiftUI handled 90% of the UI beautifully. The animation capabilities particularly impressed me.
\nModern Swift is powerful. Swift 6’s actor model and structured concurrency made complex state management surprisingly manageable, even for a concurrency novice.
\nAI agents love writing tests. Embrace it. The comprehensive test suite they generated caught bugs I never would have thought to test for.
\nA menu bar app needs to be lightweight. Vibe Meter uses about 45MB of memory and essentially zero CPU when idle. The BackgroundDataProcessor refreshes data every 5 minutes by default, but backs off exponentially if errors occur.
\nOne optimization I’m proud of: the app only loads exchange rates when you actually use a non-USD currency. The ExchangeRateManager caches rates for 24 hours and falls back gracefully if the API is down. Small touches, but they matter for an app that runs 24/7.
\nIf you’re tracking AI costs, try Vibe Meter. Source on GitHub. Watch the workshop recording to see where it started.
\nThree days. One person. Six AI assistants. The future is weird.
\n", "content_markdown": "\n\nMy Cursor bill hit $900 for the month. I needed a simple way to track AI spending without constantly checking dashboards. That frustration sparked [Vibe Meter](https://www.vibemeter.ai/) - my first shipped Mac app built in three intense days.\n\nWhat started as a workshop demo became a sophisticated menu bar utility using Swift 6, SwiftUI, and extensive AI assistance.\n\n## What the AIs Say\n\nI had several AI models analyze the [VibeMeter codebase](https://github.com/steipete/VibeMeter):\n\n**O3**: “Name vs. purpose mismatch – it sounds like a mood tracker, but monitors AI-API spending.”\n\n**Claude Opus**: “86% test coverage is extraordinary. Code quality rivals what I see in major tech companies. This isn’t just a ‘side project’ - it’s a case study in how to build macOS software the right way.”\n\n**Gemini**: “Intentionally over-engineered for future growth.”\n\n## From Workshop Demo to Production App\n\nI ran [a live workshop](https://steipete.me/posts/2025/the-future-of-vibe-coding/) demonstrating AI-assisted development. Since Cursor lacks a public API, we reverse-engineered their web interface, extracted cookies, and called internal endpoints. Built both Electron and macOS versions in parallel.\n\nThe feedback surprised me - people actually found it useful. When [Gergely Orosz](https://x.com/GergelyOrosz) mentioned linking to it in his newsletter, I spent two more days polishing the rough demo into something shippable.\n\nCursor has no public API for cost control, and it was somewhat messy because I have an enterprise account while many people have individual accounts, and the API endpoints are quite different. Getting both right was tricky.\n\nSpecial thanks to [Oliver Drobnik](https://x.com/Cocoanetics) for helping me fix the individual account parsing. The second 90% of finishing an app always takes longer than the first 90%.\n\n> **Looking for testers:** Need someone with multiple Cursor teams to help test. Current implementation assumes one team only.\n\n## Key Technical Challenges\n\n### SwiftUI vs AppKit: The Eternal Dance\n\nI used SwiftUI wherever possible, but macOS menu bar apps expose the framework’s limitations. Need a popover without the arrow? Drop down to AppKit. Want to show settings from a menu item? More AppKit gymnastics.\n\nI needed a [custom NSPanel](https://github.com/steipete/VibeMeter/blob/main/VibeMeter/Presentation/Components/CustomMenuWindow.swift) for precise menu bar control. Memory management got tricky in release builds - weak references to windows deallocated before appearing.\n\nEven showing settings required [a reflection hack](https://github.com/steipete/VibeMeter/blob/main/VibeMeter/Core/Utilities/NSApplication%2BopenSettings.swift) accessing internal NSMenuItem properties. Apple deprecated the old methods, but the “correct” SwiftUI approach only works from SwiftUI views.\n\n### The Animation Breakthrough\n\nI’m proud of the [animated menu bar icon](https://github.com/steipete/VibeMeter/blob/main/VibeMeter/Presentation/Components/GaugeIcon.swift). Almost used Lottie, but SwiftUI was enough. ChatGPT converted a static icon into animatable code.\n\nThe gauge moves with spending levels, uses conic gradients for loading shimmer. ImageRenderer converts SwiftUI to NSImage for the status item.\n\n### Swift 6 Concurrency Deep Dive\n\nThis was my first production app using Swift 6’s strict concurrency model. The [architecture heavily relies on actors](https://github.com/steipete/VibeMeter/blob/main/VibeMeter/Core/Services/) for thread safety:\n\n- [CursorAPIClient](https://github.com/steipete/VibeMeter/blob/main/VibeMeter/Core/Providers/Cursor/CursorAPIClient.swift) and [ExchangeRateManager](https://github.com/steipete/VibeMeter/blob/main/VibeMeter/Core/Services/ExchangeRateManager.swift) as actors\n- `@MainActor` isolation for UI components\n- Structured concurrency with TaskGroup in [MultiProviderDataOrchestrator](https://github.com/steipete/VibeMeter/blob/main/VibeMeter/Core/Services/MultiProviderDataOrchestrator.swift)\n- `async/await` throughout, ditching Combine entirely\n\nThe learning curve was steep - debugging `UNUserNotificationCenter` delegate callbacks firing on background threads while trying to update `@MainActor` state was particularly painful.\n\nOne bug drove me crazy: perfect in debug, window wouldn’t show in release. SwiftUI view held weakly by AppKit disappeared before display. No crash, just nothing.\n\nClaude figured it out when I explained the symptoms. Reminder: always test release builds.\n\n### Apple’s Distribution Gauntlet\n\nThe hardest part wasn’t coding - it was signing, notarization, and distribution. Apple’s process is error-prone: you can notarize an app but miss deep notarization of embedded frameworks (like Sparkle), leaving you with a partially notarized app that won’t run.\n\nRather than wrestle with Fastlane, I built [custom shell scripts](https://github.com/steipete/VibeMeter/tree/main/scripts) that are much more debuggable. Now Claude can create releases by simply running “make a new release 1.1 beta 1” - the automation is beautiful once set up.\n\nThe scripts handle everything: incrementing build numbers, creating DMGs, uploading to GitHub releases, generating Sparkle appcast files. The most complex part was handling Sparkle’s EdDSA signatures correctly - the error messages when you get it wrong are cryptic at best. Pro tip: always test your update feed locally before pushing.\n\n## Interesting Technical Details\n\n### Multi-Provider Architecture\n\nThough [Vibe Meter](https://github.com/steipete/VibeMeter) only supports Cursor currently, the architecture anticipates multiple providers. The [MultiProviderDataOrchestrator](https://github.com/steipete/VibeMeter/blob/main/VibeMeter/Core/Services/MultiProviderDataOrchestrator.swift) and protocol-based design make adding OpenAI or Anthropic straightforward when the time comes.\n\nI really had to hold myself back from implementing OpenAI and Anthropic support right away. When I realized this would be useful for tracking all AI costs - not just Cursor - the temptation was strong. But I knew if I started adding providers, I’d never ship. So I built the architecture to support it but forced myself to ship with just Cursor. This is definitely coming in a future update.\n\nThe multi-provider design might seem like overkill, but it’s already paying dividends. When debugging, I can easily add a mock provider that returns test data. The orchestrator handles provider failures gracefully - if Cursor’s API is down, the app doesn’t crash, it just shows cached data with a subtle indicator.\n\n### Polish in the Details\n\nSmall touches matter. The app includes:\n\n- [Currency conversion](https://github.com/steipete/VibeMeter/blob/main/VibeMeter/Core/Services/ExchangeRateManager.swift) with real-time exchange rates\n- [Gravatar integration](https://github.com/steipete/VibeMeter/blob/main/VibeMeter/Presentation/Components/UserAvatarView.swift) for user avatars (SHA-256 hashing, retina support)\n- Comprehensive [network connectivity monitoring](https://github.com/steipete/VibeMeter/blob/main/VibeMeter/Core/Services/NetworkConnectivityMonitor.swift)\n- [ApplicationMover](https://github.com/steipete/VibeMeter/blob/main/VibeMeter/Core/Utilities/ApplicationMover.swift) for automatic /Applications folder relocation\n- Spending limit notifications with [configurable thresholds](https://github.com/steipete/VibeMeter/blob/main/VibeMeter/Core/Services/SpendingLimitsManager.swift)\n\n### Agent-Friendly Development\n\nI constrained every file to under 300 lines - agents make fewer mistakes with smaller files. This forced better organization and created a more maintainable codebase for both humans and AI. Using [Tuist](https://tuist.io) for project generation also helped since agents struggle with Xcode’s complex `.pbxproj` files.\n\n## By the Numbers\n\nWhat emerged surprised even me:\n\n- **174 Swift files** totaling **28,599 lines** of code\n- **86% test coverage** with 628 individual test methods\n- **18 shell scripts** (2,857 lines) for build automation\n- **437 occurrences** of Swift 6 concurrency keywords\n- **15 protocols** for loose coupling and testability\n\nThe largest files respect the 300-line constraint: [ApplicationMover.swift](https://github.com/steipete/VibeMeter/blob/main/VibeMeter/Core/Utilities/ApplicationMover.swift) (390 lines), [SparkleUpdaterManager.swift](https://github.com/steipete/VibeMeter/blob/main/VibeMeter/Core/Services/SparkleUpdaterManager.swift) (361 lines), and [Color+Theme.swift](https://github.com/steipete/VibeMeter/blob/main/VibeMeter/Core/Theme/Color%2BTheme.swift) (358 lines). The build infrastructure alone required comprehensive scripts for [code signing](https://github.com/steipete/VibeMeter/blob/main/scripts/sign-and-notarize.sh) (349 lines), [release automation](https://github.com/steipete/VibeMeter/blob/main/scripts/setup-sparkle-release.sh) (314 lines), and [notarization](https://github.com/steipete/VibeMeter/blob/main/scripts/notarize-app.sh) (312 lines).\n\n## The Testing Philosophy\n\nI wanted to see how well AI generates tests. For a hobby project like this, I probably wouldn’t have written any. But they caught real bugs:\n\n- Currency conversion edge cases (what happens when the exchange rate API is down?)\n- Cookie expiration handling (Cursor cookies last 30 days, not forever)\n- Timezone bugs (monthly spending resets at UTC midnight, not local time)\n- The classic “what if the user has no internet?” scenarios\n\nThe [UserDefaultsBackedAdvancedTests](https://github.com/steipete/VibeMeter/blob/main/VibeMeterTests/Core/Utilities/UserDefaultsBackedAdvancedTests.swift) alone has 374 lines testing every possible edge case of property wrappers. Did we need all of them? Probably not. Did they catch bugs? Absolutely.\n\n## Lessons Learned\n\n**Context windows matter**. I ran six Claude instances concurrently - one for linting, one for tests, one for UI, one for features, one for bugs. First time trying this strategy. Worked beautifully. The more an agent knows about previous related tasks, the better it performs.\n\n**Small files matter**. The 300-line constraint prevented agent editing mistakes and forced better architecture. What seemed like a limitation became a forcing function for good design.\n\n**SwiftUI has come far**. Despite the AppKit gymnastics required for menu bar specifics, SwiftUI handled 90% of the UI beautifully. The animation capabilities particularly impressed me.\n\n**Modern Swift is powerful**. Swift 6’s actor model and structured concurrency made complex state management surprisingly manageable, even for a concurrency novice.\n\n**AI agents love writing tests**. Embrace it. The comprehensive test suite they generated caught bugs I never would have thought to test for.\n\n## Performance Notes\n\nA menu bar app needs to be lightweight. Vibe Meter uses about 45MB of memory and essentially zero CPU when idle. The [BackgroundDataProcessor](https://github.com/steipete/VibeMeter/blob/main/VibeMeter/Core/Services/BackgroundDataProcessor.swift) refreshes data every 5 minutes by default, but backs off exponentially if errors occur.\n\nOne optimization I’m proud of: the app only loads exchange rates when you actually use a non-USD currency. The [ExchangeRateManager](https://github.com/steipete/VibeMeter/blob/main/VibeMeter/Core/Services/ExchangeRateManager.swift) caches rates for 24 hours and falls back gracefully if the API is down. Small touches, but they matter for an app that runs 24/7.\n\nIf you’re tracking AI costs, try [Vibe Meter](https://www.vibemeter.ai/). Source on [GitHub](https://github.com/steipete/VibeMeter). Watch the [workshop recording](https://steipete.me/posts/2025/the-future-of-vibe-coding/) to see where it started.\n\nThree days. One person. Six AI assistants. The future is weird.\n", "dateCreated": "2026-09-27T19:29:15.293681927+00:00", "date_created": "2025-06-04T11:00:00+00:00", "date_modified": "2025-06-04T11:00:00+00:00", "date_published": "2025-06-04T11:00:00+00:00", "description": "How I built Vibe Meter, a macOS menu bar app to track AI spending in real-time - from workshop demo to shipped product in three days.", "external_url": "https://steipete.me/posts/2025/vibe-meter-monitor-your-ai-costs/", "git": { "commit": "ebb0941c5c06a2ab2377342d607535262a3e969e", "path": "items/steipete-me/2025/06/2025-06-04-vibe-meter-monitor-your-ai-costs.md", "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/ebb0941c5c06a2ab2377342d607535262a3e969e/items/steipete-me/2025/06/2025-06-04-vibe-meter-monitor-your-ai-costs.md" }, "id": "urn:aggr:item:bd80a092b1ccc51279099b47cf27d44720a0096c", "isBasedOn": { "@id": "https://steipete.me/posts/2025/vibe-meter-monitor-your-ai-costs/" }, "mainEntity": { "@id": "https://steipete.me/posts/2025/vibe-meter-monitor-your-ai-costs/", "@type": "CreativeWork", "archivedAt": { "@id": "https://aggr.aymericbeaumet.com/items/steipete-me/2025-06-04-vibe-meter-monitor-your-ai-costs/#webpage" }, "dateModified": "2025-06-04T11:00:00+00:00", "datePublished": "2025-06-04T11:00:00+00:00", "headline": "Vibe Meter: Monitor Your AI Costs", "timeRequired": "PT7M", "url": "https://steipete.me/posts/2025/vibe-meter-monitor-your-ai-costs/", "wordCount": 1354 }, "name": "Archived snapshot: Vibe Meter: Monitor Your AI Costs", "preview": null, "reading_minutes": 7, "replicated_at": null, "source": "steipete-me", "source_name": "Peter Steinberger", "summary": "How I built Vibe Meter, a macOS menu bar app to track AI spending in real-time - from workshop demo to shipped product in three days.", "tags": [], "temporalCoverage": "2026-09-27T19:29:15.293681927+00:00", "title": "Vibe Meter: Monitor Your AI Costs", "url": "https://aggr.aymericbeaumet.com/items/steipete-me/2025-06-04-vibe-meter-monitor-your-ai-costs/", "word_count": 1354 }