半夜 Claude Code 跑到一半 token 斷了？這個方法讓它自己醒來繼續

睡覺前把電鍋設定好，隔天早上起床就有熱騰騰的飯可以吃了。

用 Claude Code 跑長時間任務也可以這樣——睡前設好 /loop，token 斷了它會一直等，reset 之後自己繼續，早上醒來結果已經在那裡了。

筆者平常晚上 10 點睡覺，但有時候一個重要任務偏偏要等到半夜 12 點 token 才 reset。盯著螢幕撐兩個小時，那種賣肝熬夜的噩夢感覺又回來了——明明是 AI 時代，結果還是要熬夜。這篇文章就是為了解決這個問題。

詳細說明怎麼做，包含各種情境模擬、最佳 prompt 寫法，以及這樣做到底違不違反 Anthropic TOS。

Claude Code 有內建自動恢復嗎？

沒有。

Claude Code 沒有任何內建機制可以在 token 限制解除後自動恢復任務。token 用盡就是停住，等人工介入。

但有幾個方案可以繞過這個問題：

本文聚焦最簡單的 /loop 方案。

/loop 的基本行為

/loop 會在同一個 session 裡，按照你設定的 interval 重複執行同一個 prompt。

關鍵行為：根據官方文件：

“If a task’s scheduled time passes while Claude is busy on a long-running request, it fires once when Claude becomes idle, not once per missed interval.”

也就是說：上一輪還在跑時，到期的觸發會等 idle 後補發一次（不是 skip，不是排隊多次，而是等閒置後觸發一次）。

這表示：

• 任何時候只有一個 iteration 在執行
• 任務執行中不論累積幾輪 interval，idle 後只補觸發一次
• Token 限制造成任務中斷後 Claude idle，loop 不會停下來等，而是每個 interval 都主動嘗試一次 resume，直到 token reset 成功為止

場景模擬：用 Opus 跑大型任務，中途 token 限制

Opus 是 token 消耗最快的模型，大型 code review 或長文章批次處理很容易在 1–2 小時內耗盡 Pro/Max 的用量配額。

根據多個來源的一致說法，claude.ai Pro/Max 的用量限制採用 5 小時 rolling window：達到上限後，最長等 5 小時即可 reset。

注意：官方 support 頁面目前對重置週期的措辭不夠明確，且自 2026 年 3 月起有用戶回報 token 追蹤出現 bug（Max 20 用戶最快 19 分鐘就耗盡），Anthropic 已承認並調查中。實際等待時間可能因情況而異。

最壞情況：用 claude.ai Pro/Max 跑 Claude Code，token 限制後最長等 5 小時才會 reset。

情境：用 Opus 批次處理 67 篇文章的 body review，預估跑 3 小時，23:00 開始，凌晨 1:30 token 用盡，reset 在 5 小時後（04:30）。

/loop 30m 繼續 body review 任務，若已完成回報結果

23:00  任務開始（Opus body review，67 篇），執行中...

23:30  Loop 到期 → 還在跑 → 等待 idle
00:00  Loop 到期 → 還在跑 → 等待 idle
00:30  Loop 到期 → 還在跑 → 等待 idle
01:00  Loop 到期 → 還在跑 → 等待 idle

01:30  ⚠️  Token Limited — 任務中斷，Claude idle
       （loop 不會停下來，持續每 30 分鐘主動嘗試 resume）

02:00  Loop 觸發 → 嘗試 resume → token 未 reset，失敗，繼續等
02:30  Loop 觸發 → 嘗試 resume → token 未 reset，失敗，繼續等
03:00  Loop 觸發 → 嘗試 resume → token 未 reset，失敗，繼續等
03:30  Loop 觸發 → 嘗試 resume → token 未 reset，失敗，繼續等
04:00  Loop 觸發 → 嘗試 resume → token 未 reset，失敗，繼續等

04:30  ✅ Token Reset（距 session 開始滿 5 小時）

05:00  Loop 觸發 → idle → resume 成功 → 任務從中斷點繼續，執行中...

05:30  Loop 到期 → 還在跑 → 等待 idle
06:00  任務完成

07:00  你醒來，看到完成報告

最壞延誤：5 小時 reset 週期 + 最多一個 loop interval（本例 30 分鐘）。全程不需要人工介入。

補充：若使用 Anthropic API（非 claude.ai 訂閱），rate limit 採用 token bucket 演算法，容量持續補充而非固定區間 reset，恢復時間因 tier 與用量而異，通常比 5 小時短。

場景模擬：睡前啟動，整夜自動跑

最現實的場景：21:00 設好任務，22:00 去睡覺，不知道幾點 token 會限制，也不知道幾點 reset。

/loop 30m 繼續 build 任務，若已完成回報結果

21:00  任務開始（你還在電腦前）
22:00  你去睡覺，任務還在跑
23:30  任務跑到一半 token limited，Claude idle
       （loop 持續每 30 分鐘主動敲門）
00:00  Loop 觸發 → 嘗試 resume → 失敗，繼續等
00:30  Loop 觸發 → 嘗試 resume → 失敗，繼續等
01:00  Token reset ✅（距 23:30 滿一段時間）
01:00  Loop 觸發 → 嘗試 resume → 成功 → 任務繼續
04:00  任務完成，Claude 等待下一輪 loop
07:00  你醒來，看到完成報告

不需要半夜爬起來手動輸入任何指令。

/loop 與手動插入任務的差異

常見誤解：以為 /loop 排程的任務會「插入」正在執行的任務中間。

實際行為：

所以：

• 掛 /loop 睡覺不用擔心「loop 衝突」
• 但你醒來手動輸入訊息，確實會中斷當前執行中的任務

interval 怎麼設？

先釐清一個關鍵：interval 不決定任務跑完的時機——任務跑完後 loop 會立刻補觸發，不需要等下一個 interval。Interval 只決定一件事：token reset 後最多等多久才繼續。

以一個真實的複雜專案為例——Knowledge Bus，這是一個 FastAPI + SQLite + AI 蒸餾 + Git 同步排程的完整後端服務，用 Opus 開發含測試、DevOps 設定、邊界案例處理，全程可能跑超過 2 小時。

這種任務的 interval 應該怎麼設？

claude.ai Pro/Max 的用量限制採用 5 小時 rolling window，達到上限後最長等 5 小時 reset。interval 設 30m，token reset 後最多再等 30 分鐘，僅佔整個等待週期的 10%——這是合理的代價。

設 5m 有什麼問題？token limited 的 5 小時等待期間，每 5 分鐘觸發一次失敗呼叫，徒增 context 消耗，對縮短等待時間毫無幫助。

注意：自 2026 年 3 月起有用戶回報 token 追蹤出現 bug（Max 20 用戶最快 19 分鐘就耗盡），Anthropic 已承認調查中。實際等待時間可能因情況而異。

來源：How do usage and length limits work

這樣做違反 Anthropic TOS 嗎？

不違反。

Anthropic API 在 rate limit 錯誤（HTTP 429）的回應中，本身就附帶 retry-after header：

“When you exceed rate limits, Claude API returns a 429 error with a Retry-After header indicating when you can retry.” — Anthropic API Rate Limits 文件

retry-after header 的存在本身就是官方設計客戶端自動重試的預期行為。Anthropic 的 Python / TypeScript SDK 也內建指數退避重試邏輯。

Anthropic 使用條款與 API 文件中沒有任何條款禁止：

• 自動重試
• polling
• 定期觸發任務

/loop 屬於「粗糙的輪詢」，不像 SDK 那樣精準讀取 retry-after header，但完全在合規範圍內。唯一的代價是偶爾多等幾分鐘。

邊界情況

Token Limited 期間 loop 的行為

Token limited 後 Claude 進入 idle，loop 不會停下來被動等待，而是每個 interval 持續主動嘗試 resume。每次嘗試都會發出 API 呼叫，被 token 限制擋回後失敗，然後等下一輪再試。

這是預期行為，不會造成任何損害，也不會完成任何有效工作——只是持續敲門，直到門打開（token reset）為止。

Loop 最長能跑多久？

Claude Code session 在沒有互動的情況下可能因為閒置而斷線。目前官方沒有明確說明最長 idle 時間，但實測 Desktop App 在有 loop 持續觸發的情況下，可以穩定運行數小時。

建議使用 Desktop App 而非 Web 版，避免瀏覽器 tab 被休眠。

任務跑完但 loop 還在繼續

Loop 不會自己判斷任務是否完成——除非你在 prompt 裡明確告訴 Claude：

/loop 30m 繼續 body review，若所有文章已處理完畢則回報完成並停止

或手動 /stop 終止 loop。

Prompt 設計不好導致重複執行

如果 prompt 是「執行 build」而非「繼續未完成的 build」，每輪 loop 都會從頭跑一次，不是從中斷點繼續。

寫法建議：

• 好：繼續未完成的 body review，已處理的檔案跳過
• 差：執行 body review

故障排查

Resume 後 Claude 不知道從哪繼續

症狀：token 恢復後 Claude 重新開始，而非從中斷點繼續。

原因：任務本身沒有記錄進度（例如純對話式任務），Claude 無法判斷哪些已完成。

解法：

• 使用會記錄狀態的腳本（如 quality_rate.py 的 skipped-existing 機制）
• 或在 prompt 明確說明如何判斷進度：已有 quality_score 的文章跳過，只處理未評分的

任務一直失敗，loop 空轉

症狀：每輪 loop 都失敗，但 token 應該已 reset。

可能原因：

1. Token 還沒 reset（距上次耗盡未滿 5 小時）
2. 任務本身有 bug，與 token 無關
3. Claude Code session 已斷線，loop 沒在跑

確認方式：看 Claude Code 視窗是否有 loop 觸發紀錄，以及錯誤訊息內容。

Loop 突然停掉

可能原因：

• 瀏覽器 tab 被系統休眠（Web 版）
• 電腦進入睡眠模式
• Claude Code 更新重啟

解法：使用 Desktop App + 關閉電腦睡眠，或改用 /schedule Routines。

最佳 Resume Prompt 寫法

Prompt 寫法直接決定 loop 能不能正確從中斷點繼續，而非每次重頭跑。

核心原則：冪等性（Idempotency）

好的 loop prompt 要讓任務「跑兩次也不出問題」——已完成的部分自動跳過，未完成的繼續執行。

結構模板

繼續 [任務名稱]。
判斷進度的方式：[如何辨別哪些已完成]。
已完成的項目跳過，只處理 [未完成的條件]。
全部完成後回報：[完成摘要格式]。
若遇到錯誤，記錄後繼續下一個，不要中止整個任務。

實際範例對比

差的寫法（每輪重頭跑）：

執行 build-static-website.sh

好的寫法（冪等，能正確 resume）：

繼續執行 build-static-website.sh -no-deploy -no-review-bodies。
若 public/ 目錄已存在且比 content/ 新，跳過 build 直接回報結果。
build 完成後輸出：完成時間、頁面數量、是否有錯誤。

Opus 批次任務範例（body review）：

繼續 body review 任務。
已有 body_reviewed: true 的文章直接跳過。
只處理尚未標記的文章，每篇完成後更新 front matter。
全部完成後回報：處理篇數、跳過篇數、有無錯誤。
若 token 不足中途停止，下次觸發會從相同邏輯繼續。

關鍵要素，以 Evernote 筆記清理為例

最佳 Interval 選擇

GitHub Issue #36320 顯示社群實作的 auto-resume 工具預設為 300 秒（5 分鐘），但這是針對 API 用戶（token bucket 持續補充）設計的。

對 claude.ai Pro/Max 用戶，reset 週期固定 5 小時，短 interval 沒有加速恢復的效果：

注意：近期 GitHub Issue #41788 顯示 Max 20 用戶使用 Opus 可能在 70 分鐘內耗盡 5 小時配額。這表示任務設計比 interval 更關鍵——要確保每輪 loop 的 token 消耗在預期範圍內。

短任務的定時觸發：像 Linux at 一樣用

/loop 是為「長時間輪詢 + 斷點恢復」設計的。但如果你只是想「30 分鐘後做一件事，做完就算了」——用 /loop 反而麻煩，還要記得手動 /stop。

更合適的工具是 /schedule（Routines），它支援一次性定時觸發，行為類似 Linux 的 at 命令：設一個時間點，Claude 到時候跑一次，結束就刪除排程。

# 設定一次性定時任務（自然語言描述）
/schedule  在 30 分鐘後執行 build-static-website.sh -no-deploy，完成後回報結果
/schedule  今晚 23:00 推送 release branch，並確認 CI 是否通過

與 /loop 的差異：

/schedule 的任務跑在 Anthropic 雲端（Routines），即使你關掉電腦也能在時間到時自動觸發——這是 /loop 做不到的。

實際使用方式

長時間任務 + token 斷點恢復 → /loop

以下是一個真實規模的例子：18 年累積的 8 萬筆 Evernote 筆記，要清洗、LLM 深度分析重構、自動分類、加上雙向連結，最後轉成 Obsidian vault。這種任務用人工做要好幾個月，但用 Claude Code + /loop 可以睡著讓它跑完。

整個流程分四個階段，每階段一個 loop：

# 第一階段：透過 Python API 批次拉取筆記並清洗
# 直接呼叫 Evernote API 取得原始內容，拉取與格式清洗同步完成
# 注意：Evernote API 有 rate limit（每小時請求上限），
# fetch_notes.py 遇到 429 會自動退避等待，但整批 8 萬筆拉完可能跨越數個小時——
# 這也是為什麼需要 /loop：不只 Claude token 會斷，Evernote API rate limit 也可能讓任務中斷
/loop 30m 繼續執行 fetch_notes.py，從 Evernote API 批次拉取筆記。
已有 fetched: true 的筆記跳過（依 note GUID 判斷）。
拉取同時清洗：去除廢棄標籤、修復亂碼、統一 markdown 格式，寫入 evernote/cleaned/。
每完成 500 筆寫入 fetch.log。全部完成後回報：拉取筆數、清洗修復數、API 錯誤清單。

# 第二階段：LLM 深度內容分析與重構（最 token 密集，最容易斷）
# 每筆筆記送進 Opus 做以下處理：
#   - 語意摘要：提取核心論點，濃縮為 3–5 句
#   - 知識點拆解：將長篇筆記拆為原子化概念（atomic notes）
#   - 時效性判斷：標記「仍然有效」或「已過時」（附理由）
#   - 改寫重構：修正口語化表達、補充缺漏的上下文、統一術語
#   - 情緒標記：辨識筆記情緒傾向（洞見/疑問/待辦/靈感），寫入 mood 欄位
/loop 30m 繼續對 evernote/cleaned/ 下的筆記進行 LLM 分析重構。
已有 llm_analyzed: true 的筆記跳過。
每筆完成後將摘要、原子概念、時效判斷、重構內容、情緒標記寫入 front matter 與正文。
完成後回報：分析筆數、平均原子概念數、過時筆記比例、錯誤清單。

# 第三階段：自動分類 + 雙向連結推斷
/loop 30m 繼續對 evernote/analyzed/ 下的筆記進行主題分類與連結推斷。
已有 category 和 links 欄位的筆記跳過。
分類依照 taxonomy.yaml 定義的主題體系；連結依語意相似度與概念共現推斷，
只建立雙向有意義的關聯，過濾掉信心分數低於 0.75 的候選連結。
完成後回報：已分類筆數、平均連結數、低信心分類清單。

# 第四階段：匯出 Obsidian vault
/loop 15m 繼續將 evernote/classified/ 轉換為 Obsidian markdown 格式並寫入 vault/。
已存在對應 .md 檔的筆記跳過。
雙向連結轉為 [[wikilink]] 格式，附件複製到 vault/attachments/。
完成後回報：匯出筆數、附件數、broken link 數量、graph 預估節點數。

第二階段的 LLM 分析每筆筆記都要獨立呼叫 Opus，8 萬筆下來 token 消耗極為龐大，幾乎可以確定會在中途斷線多次。這正是 /loop 發揮價值的地方——每次斷線最多等一個 interval，reset 後自動從上次中斷的地方繼續，不需要人工守夜。

短任務，只跑一次 → /schedule

# 30 分鐘後執行 build，不需要持續輪詢
/schedule  30 分鐘後執行 build-static-website.sh -no-deploy，完成後回報頁面數量與是否有錯誤。

# 指定時間推送 release
/schedule  今晚 23:00 推送 release branch 到 origin，並確認最新 commit 是否正確。

確保 Claude Code 視窗保持開啟（Desktop App 最穩），/loop 才能持續觸發。/schedule 跑在 Anthropic 雲端，即使關掉電腦也能在指定時間自動執行。

小結

• Claude Code 沒有內建 token 限制後自動恢復功能
• /loop 可以達到幾乎相同的效果：token 恢復後最多等一個 interval 自動繼續
• claude.ai Pro/Max 的 token reset 週期為 5 小時，interval 設 30m 是合理值
• Loop 觸發遇到任務還在跑，會等 idle 後補觸發一次，不衝突、不疊加多次
• 手動送出新訊息才會中斷任務，loop 本身不會
• 此做法符合 Anthropic TOS，API 官方文件預期客戶端會自動重試
• Prompt 要寫「繼續未完成」而非「重新執行」，避免每輪從頭跑
• Loop 空轉時先確認是 token 未 reset、任務 bug、還是 session 斷線