Usage 0.29.3: Menu bar critters stop hogging your CPU

Release notes

FEATURE

Menu bar critters stop hogging your CPU

When you are busy using AI, the phoenix, dragon, and lion in the menu bar used to slow your Mac down at exactly the wrong moment. They animate only while you burn tokens, but each had its own timer and together forced 60 full redraws every second, even when no critter had moved. Now they share one timer, the quickest frame interval changes from 0.05 to 0.10 seconds with no visible difference in an 18px sprite, and unchanged frames skip redraws. The burn-rate lookup no longer checks 2,858 history files on the main thread every 30 seconds; it refreshes in the background, while text and sprites are cached. Like three performers fighting over one spotlight, they now take turns. The animation remains, while measured CPU use drops from 30–33% of one core to 4.2–5.9%.

FEATURE

Stale service alerts now clear themselves

A service can be back to normal while its panel still shows a warning. Usage now clears that kind of leftover alert without hiding a real outage. A provider status page may forget to remove a mild degraded-performance notice, so two retirement rules apply only to that lowest severity; partial and major outages always remain visible. First, if every unresolved incident has been in monitoring — the provider saying the fix is in and it is watching — for over four hours, the alert hides until something changes. Second, if Usage itself sees an unchanged status for more than 24 hours, it treats it as residue. Why not trust the page timestamp? All 25 OpenAI components, including healthy ones, share a timestamp more than two weeks old. It may mark when a component was created, not when its status changed. Like a shop's forgotten “temporarily out of stock” sign, only an old minor notice comes down; a real closure stays posted.

Original changelog

Original changelogMenu bar critters stop hogging your CPU

**The menu bar critters no longer cost a third of a CPU core**: the phoenix, dragon and lion each drove their own timer, and every single frame re-sent the whole status item title to AppKit — which re-typesets the entire string through CoreText and re-measures the item's width, asking the system for its preferred languages along the way. With all three animating at full speed that came to 60 full relayouts a second, measured at 30–33% of a core with the popover closed; the cost arrived precisely when you were busiest, since the critters only animate while you are burning tokens. They now share a single timer, the fastest frame interval widens from 0.05s to 0.10s (indistinguishable on an 18px sprite), and a tick where no critter advances skips the redraw entirely. The burn-rate lookup that used to sit on the animation path — stat-ing 2,858 history files on the main thread every time its 30-second cache expired — moved to the background refresh, and the menu bar's text and sprite fragments are now cached instead of rebuilt per frame. Same animation, measured 4.2–5.9%.

Original changelogStale service alerts now clear themselves

**A service alert the provider forgot to clear no longer sticks around**: a status page can leave a component marked as degraded long after the incident is over, and the panel had no way to tell that apart from a live problem. Two rules now retire such an alert, both limited to the mildest *degraded performance* level so a partial or major outage is never hidden. First, if every unresolved incident on the page has sat in *monitoring* — the provider's own word for "the fix is in, we are watching it" — for more than four hours, the alert is suppressed until something changes. Second, a status observed unchanged for more than 24 hours is treated as residue. The second rule times what usage itself has seen rather than trusting the page's own timestamps: on OpenAI's page all 25 components, the operational ones included, share one timestamp from over two weeks earlier, so that field records when a component was defined, not when its status last moved.