每天早上跟 Claude 說聲早安 — 把 5 小時 session 用好用滿的小習慣

我現在每天早上打開 terminal 的第一件事，是跟 Claude 說早安。

這不是在跟 AI 培養感情。是在按碼表。

這篇最早是 2025 年 6 月寫的，後來補過幾次。5 小時視窗這個核心機制到現在沒變，但有兩件事是後來才長出來的：壓在視窗之上的週上限，還有 /usage 那份會告訴你額度到底花去哪的歸因報表。官方也在這中間把「每 5 小時幾則訊息」的數字從說明頁上默默拿掉了。

這個情境你可能很熟

下午三點多，你正在改一個急著要交的東西。改到一半，Claude 跟你說額度用完了，請等視窗重置。

你第一個反應是：不對啊，我今天才用多久？

明明十點半才坐到電腦前，中間還開了一個小時的會，滿打滿算也才三個多小時，怎麼會爆？

答案通常在你已經忘掉的地方——早上七點多，你在床上用手機問了一句話。可能是某個 CLI 參數怎麼寫，兩行就講完了，你當下還覺得省了自己五分鐘。

那一句，就是你當天的第一個請求。

視窗從七點多就開始跑了。等你十點半坐下來，已經沒了三個半小時。而你完全沒感覺，因為那一句是在手機上打的，畫面上什麼倒數都沒有。

搞懂這件事之後我的結論有點好笑：這個機制能控制的地方本來就不多，而唯一能控制的那一點，我一直在隨便亂丟。

你的 5 小時，是從你第一句話開始算的

先把機制講清楚。

Claude 的訂閱制不是按月給你一大桶額度讓你自由分配。它是一個滾動的 5 小時視窗——視窗一開，倒數五小時，用完就等下一個。

關鍵在於，這個視窗不是跟著時鐘走的。它不從整點開始，不從午夜開始，也不從你的訂閱日開始。

它從你這一輪的第一個請求開始。

官方說明頁的寫法是「你的 session-based 用量限制每五小時重置一次」，沒有逐字寫死起點在哪。但你自己跑一次 /usage 就看得到答案：畫面上是「這個 session 用掉多少」加上「這個 session 還剩多久」。那個倒數不會在早上八點自己冒出來，它是你送出第一則訊息之後才開始跑的。

然後是我那天踩到的那條：額度是跨產品共用的。claude.ai 網頁版、Claude Code、Claude Desktop，全部算在同一份用量上。

所以你在床上、在捷運上、在馬桶上用手機隨口問的那一句，跟你坐在電腦前敲的指令，是同一個池子。

而手機上不會有倒數提醒你這件事。

flowchart TD
    A["claude.ai 網頁版<br/>Claude Desktop"] --> Q["同一份用量額度"]
    B["Claude Code"] --> Q
    Q --> S["你送出的第一個請求<br/>視窗在這裡開始倒數"]
    S --> T["接下來 5 小時<br/>你有沒有在用，時間都照走"]

所以真正的技巧是：那個起點要你自己挑

攤開來看就很清楚了。

假設你今天什麼都不管，自然開工。你第一次真的問 Claude 事情是 9 點 47 分——因為前面在收信、開會、找咖啡。那你今天的邊界長這樣：

09:47 → 14:47
14:47 → 19:47
19:47 → 00:47

這組邊界超級難用。14:47 卡在你下午會議中間，19:47 卡在吃飯。更煩的是它每天都在漂——因為你每天真正開工的時間都不一樣，所以你永遠不知道現在這個視窗還剩多少，只能等它跳出來罵你。

換個做法。早上八點整，打開 terminal，說早安。

08:00 → 13:00
13:00 → 18:00
18:00 → 23:00
23:00 → 04:00

整點。好記。而且終於可以規劃了——早上那段是主戰場，13:00 開的新視窗剛好接下午，18:00 那個接晚上。如果你有「排一個長任務讓它自己跑」的習慣，23:00 睡前還有第四個。

一天四個視窗，睡覺時間也算進去的話勉強能碰到第五個。這就是社群裡那個「一天四到五個 session」算法的來源。

不過先別急著照這個數字排你的一週。等一下會講為什麼。

「225 則訊息」這個數字，別拿來算

你大概在很多地方看過這組：Pro 每 5 小時至少 45 則、Max 5x 至少 225 則、Max 20x 至少 900 則。

我剛開始也是抱著這個數字在過日子。心裡有一本帳：今天大概還能問幾次，這題要不要問，值不值得。

後來我發現這本帳從第一頁就記錯了。

這幾個數字當時確實掛在官方說明頁上。但我後來再去翻，它們已經被拿掉了。現在 Pro 的頁面只寫「相較免費版，每個 session 至少五倍用量」，Max 的頁面只寫「Pro 的 5 倍或 20 倍」，一個具體則數都沒有。

而且官方還主動補了一句，大意是：你能送幾則訊息，會隨著訊息長度、附件長度、當前對話的長度、以及你用哪個模型而變。

這句話才是重點。「則」根本不是一個有意義的單位。

在 Claude Code 裡尤其誇張。你打一句「修一下這個 bug」是一則訊息，但它背後可能是讀十個檔案、跑三次測試、開兩個 subagent。你打一句「這行是什麼意思」也是一則訊息。兩者成本可以差兩個數量級，但在你那本帳上，都記一筆。

所以拿 225 去除以今天要做的事、算出「我還能問幾次」，這個算式從一開始就是錯的。它給你的不是控制感，是假的安全感。

至於「Max 5x 每 5 小時大概值 $40」那種說法——那是社群拿 API 牌價回推的換算，不是官方數字。當個量級的直覺可以，當預算表就不行了。

真正該建立的直覺是：一個視窗能做完多少件事。而這件事沒人能幫你算，只能你自己跑一週 /usage 才會知道。

後來又多長出來的第二層天花板：週上限

這一段是對前面那個「一天四到五個 session」算法最大的修正。

除了 5 小時視窗，Max 方案上面又壓上了兩條週上限：一條算所有模型，另一條單獨算 Opus——撞到它不會整個停掉，切回 Sonnet 還是能繼續做事。Pro 也有一條全模型的週上限。

兩層是同時生效的。也就是說，就算你每個 5 小時視窗都乖乖沒爆，你還是可能在週四下午撞到週上限，然後整個週末被請去放假。

flowchart TD
    A["第一層：5 小時視窗<br/>用完等下一個視窗"] --> C["兩層同時生效<br/>先撞到哪層就卡在哪層"]
    B["第二層：兩條週上限<br/>全模型一條、Opus 一條"] --> C
    C --> D["每個視窗都沒爆<br/>還是可能週四下午就動不了"]

所以「一天跑滿四到五個視窗」這件事，在週上限底下基本不成立。真這樣跑，你大概撐不完一週。

我一開始知道有週上限的時候有點沮喪，覺得那早安術不就沒意義了嗎，反正天花板在那裡。

後來想通了，其實剛好相反：

它從來就不是讓你用得更多，是讓你用得更準。

當你知道這個視窗是 08:00 開的、13:00 會關，你才有辦法在早上十一點半判斷「這件事現在做，還是留到下午那個視窗做」。邊界在漂的時候，你連這個問題都問不出口。

早安之後的第二個習慣：別讓 session 開一整天

這件事我自己踩過，後來才在官方文件裡找到解釋。

我以前的習慣是：早上開一個 Claude Code，就讓它掛在那裡一整天，想到什麼問什麼。感覺上這樣最省，畢竟 context 都在，不用重講一遍。

結果這是最貴的用法。官方在成本管理那頁把原因列得很清楚：

• 長 context。Claude Code 每一次請求都會把整段對話送出去。你在一個開了一整天的 session 裡問一句一行的問題，帳單是照整段對話算的。
• Cache miss。訂閱制的 prompt cache 存活時間是一小時。你去開個兩小時的會回來，第一句話就是一次完整 context 重算。這一句可能比你整個早上都貴。（順帶一提，如果你已經在用 usage credits，cache 存活時間會掉到五分鐘。）
• 排程任務。掛在 session 上的 scheduled task 會照間隔自己觸發，即使你人不在，它每次都帶著完整 context 送出去。
• Agent teammate。每個還活著的 teammate 都在燒 token，直到它結束或 session 收掉。

最違反直覺的是第二條。開完會回來的時候，你很容易覺得「還好我沒關，context 都還在」，然後很順手地丟一句「剛剛講到哪」。

那一句在我心裡是最便宜的一句。實際上它是那個早上最貴的一句。

還有一個很多人搞反的：/clear 是免費的，/compact 不是。compact 要先把整段對話讀進來才能總結，本身就是一個大請求。所以想省的時候按 compact，其實是在花錢。

做完一件事、要切到不相干的下一件事時，正確動作是 /clear，不是硬撐。如果那個 session 之後還要回去，先 /rename 給它一個名字，之後用 /resume 找回來就好。

用 /usage 看真相，不要憑感覺

我想不到比這更划算的兩分鐘投資了。

在 Claude Code 裡跑 /usage，訂閱用戶會看到用量條、活動統計，還有一份歸因報表——它會告訴你最近的用量分別花在哪些 skill、subagent、plugin、MCP server 上，各佔幾 %。另外它還會標行為層面的問題——long context、cache miss 這類，只要其中一項佔了最近用量 10% 以上就會被點名。

按 d 看最近 24 小時，按 w 看最近 7 天。

最容易有收穫的是 MCP server 那一欄。裝完就忘、根本沒在用的 server，會安安靜靜地佔著位置吃你的額度。/mcp 關掉之後就乾淨了。

那種感覺有點像整理房間，翻出一台你完全不記得自己買過、但一直插著電的東西。

一個但書要注意：這份數字是從這台機器的 session 紀錄本機算的。你在另一台電腦、或在 claude.ai 網頁版用掉的，不會出現在這裡。所以它是趨勢診斷工具，不是對帳單。

（/usage 最上面那個 Session 區塊會顯示一個美金數字。訂閱用戶可以直接無視——那是給 API 用戶看的，用標準牌價本機估算的，跟你的訂閱帳單沒關係。第一次看到的時候不用嚇到。）

不過 /usage 要你自己想到才會去按。真正每天在提醒我的是狀態列——我把它設成一直顯示目前這個 block 還剩多久，我還自訂 status bar 將用量換算成 API 價格，token 燒得更起勁更過癮~ 哈：

block (4m left) 那一段就是這篇在講的 5 小時視窗。看到只剩四分鐘，你就知道現在不是開一個大重構的時機，該收尾、/clear、等下一個視窗。

同樣的但書：那幾個美金數字是本機用牌價估的，訂閱用戶當相對量級看就好，別當帳單。真正有意義的是括號裡的倒數。

我實際的一天

時間	動作
08:00	說早安，同時做 warm-up
08:00–12:30	主要開發，中間 /clear 兩到三次
13:00	新視窗開始，接下午的工作
18:00	新視窗，通常是寫作或整理
23:00	睡前排一個能自己跑的長任務

這張表不是重點，你的作息跟我一定不一樣。重點是邊界是我自己選的這件事。

早安那句話，該說什麼

如果你真的只打兩個字「早安」，那有點浪費一次 round trip。

我的做法是讓那一句順便有產值，把今天的 context 一起載進來：

早安。先幫我看一下這個專案現在的狀態：
git log 最近 10 筆、目前分支、有沒有未 commit 的變更，
還有 TODO.md 裡還沒完成的項目。
講重點就好，不要開始動手。

最後那句「不要開始動手」不是廢話。沒加的話它很可能會很熱心地直接開始改，然後你早上第一件事就變成 review 一份自己沒要求的 diff。

這一句同時做了三件事：開了視窗、載入了專案脈絡、給了我一份今天的起跑點報告。

也要老實講：這句話本身也吃額度，它不是免費的。但它算便宜的——fresh context、CLAUDE.md 剛載入、沒有累積的對話歷史，成本大概就幾千個 token。用這個換一整天可預測的邊界，我覺得很划算。

（如果你有裝 warm-up 之類的 skill，直接叫那個也行，效果一樣。）

什麼時候不要用這招

這招有一個很明顯的自傷模式，講清楚比較好：

視窗一開就在跑，不管你有沒有在用。

你很有儀式感地八點說了早安，然後被臨時的事情拉走，十點才真的坐下來。等於用最標準的姿勢，親手燒掉兩個小時。同一個視窗只剩三小時，而且是自己點的火。

所以正確的說法不是「一起床就說早安」，是：

在你即將開工的那個整點說早安。

你是十點才開工的人，那早安就該十點說，邊界是 10 / 15 / 20。八點說早安對你不只沒幫助，是純扣分。

同理，如果你今天只打算摸個兩小時，那根本不用管邊界在哪，開心就好。這招是給那種一天要用滿好幾個視窗的人的，不是給所有人的。

最後

整件事其實只有一句話：這個五小時視窗的起點，是你唯一免費就能控制的變數。

用量多少你控制不了，那看你今天要做的事有多重。週上限你控制不了。模型成本你控制不了。官方什麼時候把說明頁上的數字拿掉，你也控制不了。

但視窗從幾點開始，你說了算。那就別把這個決定權，交給「今天早上剛好第一次問 Claude 是幾點」。

這個習慣養成之後唯一的副作用是——我現在跟真人說早安的時候會愣半秒，因為腦子會先跑一次「這句開了什麼視窗」。

好消息是，跟人說早安不用錢，也沒有週上限。

壞消息是，也沒有 /usage 可以查你這禮拜到底把耐心花在誰身上，以及哪一個佔了超過 10%。

明天早上八點見。

早安。