How we built a 483 KB zero-WebKit macOS Universal Binary and a single-file Ubuntu HUD with Gemini 4 Argon to track multi-agent token burn pace.
Series 2/2: Multi-Model Collaboration & Quota Management in Practice (Part 1: Building a Cross-Model Collaborative Workflow with Google Antigravity)
When you run tasks in parallel across Google Antigravity (Gemini), Claude Code, OpenAI Codex, and GitHub Copilot, a progress bar that simply says 40% used is not very useful.
Burning 40% in the first 30 minutes of a 5-hour quota window means you will hit a wall in another hour; burning 40% with 20 minutes left before reset means you have more quota than you can finish.
To make an always-on desktop quota monitor answer "At my current pace, how much longer can I keep working today?", I worked with the agents to build two things:
- A time-pace marker (
paceFraction) on every progress bar that calculates the exact clock time a quota pool will run out. - Instead of our original Tauri v2 / WebView plan, a native Swift binary on macOS and a single-file, zero-dependency Tkinter floating bar on Ubuntu—keeping idle CPU at
0.0%.
But... One Dimension Was Still Missing: Right Now, Can We Actually Burn Through Our Tokens in Time?
To know whether a quota pool is about to blow up—or whether it still has plenty of slack—you only need to compare two ratios:
-
usedFraction(colored fill length): The fraction of quota consumed so far. -
paceFraction(white vertical tick): The fraction of the current reset window (5 hours or 7 days) that has already elapsed.
usedFraction = consumed / total
paceFraction = 1.0 - (resetsAt - now) / windowDuration
rate = usedFraction / paceFraction
projectedRunOut = windowStart + windowDuration / rate
For example: suppose a 5-hour window starts at 09:00 and resets at 14:00. At 10:00, one-fifth of the window has passed (paceFraction = 20%, so the white tick sits at 20%).
If you have already used 40% by then, your burn rate is 2x the sustainable pace (rate = 2.0). At that speed, your entire quota will bottom out 5 / 2 = 2.5 hours after the window started—at 11:30.
So on each Leap EDGE card:
- When the colored fill outruns the white tick (
rate > 1.15), the bar shifts color and lights up a red pill:▲ RUNS OUT 11:30. - When the colored fill stays to the left of the white tick, it shows a blue pill:
⏱ LASTS TO RESET.
With a single glance, you immediately know whether to route the next heavy task to another AI subscription.
All of this came out of iterating back and forth with Gemini 4 Argon while designing and tuning the implementation.
Why Not Tauri v2?
I already had a 22 KB vanilla HTML/CSS/JS web dashboard (?mode=edge). My initial idea was to wrap it in Tauri v2 (Rust + system WebView) as a desktop widget for macOS and Linux.
However, this widget isn't used like a normal app: you don't open it for five minutes and close it—it stays pinned to your desktop all day as a background monitor.
After looking into how macOS handles WebView processes, I decided not to put a WebView in the default path:
| Dimension | Electron | Tauri v2 (Rust + WKWebView) | Leap EDGE (Swift Dual-Engine Universal Binary) |
|---|---|---|---|
| Binary size | ~220 MB | ~6 MB (target/ build cache ~800 MB) |
483 KB (arm64 + x86_64 combined) |
| Persistent processes | 4+ (Chromium) | 3 (Host + WebKit.WebContent + GPU) |
1 (pure CoreGraphics by default, zero WebKit) |
| Background wakeups & App Nap | High idle drain | 1s JS setInterval clock keeps waking IPC |
300s data poll + 60s clock tick (with 5s tolerance) |
| macOS desktop integration | Needs plugins | Requires objc2 FFI for low-level window flags |
Native 1-line desktop-level pinning & 👻 Click-Through |
According to Apple's WebKit WKProcessPool documentation and the Apple App Nap Power Efficiency Guide, simply instantiating a WKWebView spawns separate web-content and rendering subprocesses; on top of that, a 1-second JavaScript setInterval for a live clock keeps waking the rendering pipeline.
Just to draw five fixed-format dark quota cards, the default path doesn't need a browser engine running 24/7.
So we built a dual-engine switch inside a single leap-edge.swift file:
-
Native CoreGraphics by Default (⚡ Zero WebKit): Directly parses the
/api/usageJSON and draws the five cards (Copilot, AGY, Claude Pro/Team, Codex) plus live macOS Menu Bar indicators using AppKit andNSBezierPath. Idle CPU stays at0.0%, and it supportswindow.ignoresMouseEvents = trueso mouse clicks pass straight through to the Terminal or IDE behind it. -
On-Demand
WKWebView(🌐 Web Mode): AWKWebViewis created dynamically only when you switch to Web Mode from the Menu Bar; the moment you switch back to native mode or hide the window, it callsremoveFromSuperview()and sets the instance tonil, returning all WebKit subprocess memory to the OS. - One-Line Universal Binary: A single 483 KB executable runs natively on both M1 and Intel Macs.
Bonus: Supporting Landscape & Portrait on Ubuntu Laptops and Tablets
With both Macs covered, I also have two Ubuntu machines on my desk: a ThinkPad X1 Carbon, and a Surface Pro 7 used for demos and meetings.
On Linux, we applied the exact same philosophy—a single-file, zero-third-party-dependency leap-edge.py that supports two modes:
-
Terminal / tmux Mode (
leap-edge.py --statusand--json): Embeds directly into a terminal status bar or lets AI agent scripts query which quota pool still has headroom. -
X11 / Tkinter Minimal Floating Bar (
--gui): Shares the exact samepaceFractionmath and docks flush against the Ubuntu screen edge (automatically adapting between vertical and horizontal layouts when the tablet rotates between Landscape and Portrait).
Takeaway: Decide the Usage Pattern First, Then Pick the Tool
Looking back at this two-day build, the biggest win wasn't saving a few dozen megabytes of RAM—it was clarifying two things:
- Quota monitoring must be tied to a timeline.
- Always-on utilities and regular applications have different architectural boundaries.
Thanks for reading.


Top comments (4)
The
paceFractiontick is the detail that makes this useful — a bare "40% used" bar has caused me to both panic early and sandbag late on the same quota window. Normalizing consumption against elapsed window fraction instead of absolute percentage is the right mental model, and the projected-runout clock is what you actually act on.One thing we learned running parallel agents: burn rate is rarely steady, so a single instantaneous
ratecan whipsaw the pill between "RUNS OUT" and "LASTS TO RESET" when a big task lands. We ended up smoothing over a short trailing window so the warning doesn't flicker every time one agent kicks off a heavy call. Did you consider an EWMA on the rate, or does the glance-ability win out by keeping it instantaneous? Also curious why Tkinter over a menubar-native approach on macOS for the 0% idle CPU goal — SwiftUI menu-bar extras get you close to free when idle too.How does the forecast behave after a long idle stretch? If I leave it alone for three hours, then start several agents, the average since reset could make the remaining quota look comfortable just as usage ramps up. I'd want the widget to flag that the old pace no longer tells me much.
Under 500 KB is a real constraint that forces you to cut the abstraction layers. The interesting failure mode in multi-agent token accounting isn't the total — it's the attribution. Did the per-agent split stay trustworthy across long runs, or did it drift?
The --json mode is the sleeper feature here — a cron job polling quota pools and routing heavy tasks to whichever one has the most headroom left makes the whole setup self-balancing. Also +1 on smoothing the burn rate; a short rolling average would kill most of the whipsaw Max described.