發布日期：2026-07-25
你正趕著用 AI，選單列裡的鳳凰、龍、獅子卻可能反而拖慢電腦。它們只在燃燒 token（AI 處理與計費的文字單位）時動，原本各自用計時器，每秒重排畫面 60 次；連沒有角色換格的時刻也重畫。現在三隻共用一個計時器，最快節奏從 0.05 秒改為 0.10 秒，18px 小圖看不出差別，沒換格就不重畫。原先每 30 秒在主執行緒（程式處理畫面的主要路線）逐一查 2,858 個歷史檔的燃燒速率，也挪到背景更新；選單列的文字與圖像改用快取（把查過或算過的結果暫存直接用）。像三個人各搶同一盞舞台燈，如今輪流走位，動畫照樣在；面板關閉時實測 CPU 從一個核心的 30–33% 降至 4.2–5.9%。
服務明明已恢復，面板卻還掛著警示，現在不會一直嚇你。供應商的狀態頁（顯示服務是否正常的公告頁）有時忘了清掉「效能下降」；usage 新增兩條只針對這個最輕等級的收線規則，部分或重大中斷絕不會被藏起來。第一條是：頁面上所有未結案事件都進入 monitoring（供應商表示修好後持續觀察的階段）超過四小時，警示先隱藏，直到狀態改變。第二條是 usage 自己連續看到同一狀態超過 24 小時，也把它當遺留資訊。為什麼不直接信頁面時間？OpenAI 狀態頁的 25 個元件連正常項目也共用兩週前的時間，那可能只是元件建立時間。這像商店門口忘了收回的「暫時缺貨」牌；只有確定是輕微狀況又久未更新才收起，真停業仍會留下。
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%.
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.
**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%.**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.