Claude 2x — Cross-Platform Timer Overlay

The timezone friction that accumulates

I use Claude Code heavily — not occasionally, but throughout the day, planning work around session windows. Claude's usage limits reset at specific UTC times. Working in IST, "when does my window reset" is a calculation I was doing in my head multiple times a day: current IST time, subtract five and a half hours, compare to the UTC reset time, figure out how many minutes remain.

The math is easy. The problem is that I was doing it constantly. Each calculation was four or five seconds of mental overhead that pulled me out of whatever I was actually thinking about. That kind of interruption is hard to notice in isolation — any single instance is trivial. Across a workday of heavy Claude usage it compounds into something that genuinely disrupts focus.

The answer was obvious: a floating timer that shows the remaining window without me asking for it. Always visible, never requiring interaction, zero mental overhead. I built Claude 2x to eliminate that calculation entirely.

Three implementations by choice, not accident

The natural instinct for a small utility is to pick one platform and ship it. I deliberately chose not to do that.

Claude 2x ships three separate implementations: Swift/SwiftUI for macOS, Tauri 2/Rust for Linux, and QML for KDE Plasma. They share the timezone arithmetic via chrono-tz — the conversion from the Claude reset time to local time is the same regardless of UI layer — but every UI is written separately in the platform's native idiom.

This was a learning exercise as much as a tool. When you implement the same problem in SwiftUI, in a Tauri WebView backed by Rust, and in QML, you stop reasoning about UI frameworks abstractly and start understanding what each one is actually optimized for. SwiftUI's declarative model feels natural for a macOS app with system-level integration requirements. Tauri's trade-off — web-rendered UI as a native binary — is correct when you want portability without needing deep platform APIs. QML is explicitly designed for always-on widget use cases, with a compositor model that handles window layering for KDE without the hacks other platforms require.

The objc2 FFI in the macOS build handles native window presentation behavior — the same lesson I'd carried from building HUD overlays with Tauri. Swift gives more direct AppKit access than Tauri's WebView abstraction, so less unsafe FFI is needed in most cases, but the knowledge of when to drop to the native layer transfers across both stacks. GitHub Actions runs the CI matrix across macOS and Linux runners, which validated that the shared timezone logic compiled and tested correctly on both targets.

Honest scale acknowledgment

This is 4,300 lines of code total across three implementations. That's a small project, and I'm not going to overstate it. It solves one specific problem for one specific workflow, and it solves that problem well. What it demonstrates is not architectural complexity — it is a deliberate approach to cross-platform UI development: rather than chasing a single-codebase abstraction that flattens platform differences, I wrote each implementation in the idiom that fits the platform, shared only what was genuinely shareable, and treated the repetition as the point. Understanding SwiftUI, Tauri, and QML from the same concrete problem statement is worth more than having one codebase I only partially understand.