睡覺前把電鍋設定好，隔天早上起床就有熱騰騰的飯可以吃了。
用 Claude Code 跑長時間任務也可以這樣——睡前設好 /loop，token 斷了它會一直等，reset 之後自己繼續，早上醒來結果已經在那裡了。
筆者平常晚上 10 點睡覺，但有時候一個重要任務偏偏要等到半夜 12 點 token 才 reset。盯著螢幕撐兩個小時，那種賣肝熬夜的噩夢感覺又回來了——明明是 AI 時代，結果還是要熬夜。這篇文章就是為了解決這個問題。
Claude Code 有內建自動恢復嗎？
沒有。
Claude Code 沒有任何內建機制可以在 token 限制解除後自動恢復任務。token 用盡就是停住，等人工介入。
可用方案有三種：/loop 定期重試（最簡單）、Routines（Anthropic 雲端排程）、或 Hooks 通知後手動恢復。本文聚焦最簡單的 /loop 方案。
/loop 的關鍵行為
/loop 會在同一個 session 裡，按照你設定的 interval 重複執行同一個 prompt。
重要：/loop和/schedule都必須在 token 耗盡之前設定完成。設定指令本身也會消耗 token——token 一旦歸零就無法再輸入任何指令。最佳時機是任務啟動的同時，或預估還有足夠 token 時提前掛上。
根據官方文件：
"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 在執行
- Token 限制造成任務中斷後 Claude idle，loop 不會停下來等，而是每個 interval 都主動嘗試一次 resume，直到 token reset 成功為止
真實場景模擬：用 Opus 跑大型任務
Opus 是 token 消耗最快的模型，批次處理大型任務很容易在 1–2 小時內耗盡 Pro/Max 的用量配額。claude.ai Pro/Max 的用量限制採用 5 小時 rolling window。
情境：用 Opus 批次處理 67 項 Android CTS issue review，預估跑 3 小時，23:00 開始，凌晨 1:30 token 用盡，最壞情況等到 04:30 reset。
/loop 30m 繼續解決 CTS issue 任務，若已完成回報結果
時間軸：
- 23:00 任務開始，執行中
- 23:30 ～ 01:00 Loop 到期 → 還在跑 → 等待 idle
- 01:30 ⚠️ Token Limited，Claude idle
- 02:00 ～ 04:00 Loop 持續每 30 分鐘嘗試 resume → 失敗，繼續等
- 04:30 ✅ Token Reset
- 05:00 Loop 觸發 → resume 成功 → 任務繼續
- 07:00 你醒來，看到完成報告
全程不需要人工介入。
注意：自 2026 年 3 月起有用戶回報 token 追蹤出現 bug（Max 20 用戶最快 19 分鐘就耗盡），Anthropic 已承認調查中。實際等待時間可能因情況而異。
最現實的場景：睡前啟動，整夜自動跑
/loop 30m 繼續 build 任務，若已完成回報結果
- 21:00 任務開始（還在電腦前）
- 22:00 去睡覺，任務還在跑
- 23:30 token limited，Claude idle，loop 持續每 30 分鐘敲門
- 01:00 ✅ Token Reset，loop 觸發 resume 成功
- 07:00 你醒來，看到完成報告
不需要半夜爬起來手動輸入任何指令。
這樣做違反 Anthropic TOS 嗎？
不違反。
Anthropic API 在 rate limit 錯誤（HTTP 429）的回應中，本身就附帶 retry-after header。retry-after header 的存在本身就是官方設計客戶端自動重試的預期行為。Anthropic 的 Python / TypeScript SDK 也內建指數退避重試邏輯。
/loop 屬於「粗糙的輪詢」，但完全在合規範圍內。
Interval 怎麼設？
先釐清一個關鍵：interval 不決定任務跑完的時機，任務跑完後 loop 會立刻補觸發。Interval 只決定一件事：token reset 後最多等多久才繼續。
claude.ai Pro/Max 的 reset 週期固定 5 小時，interval 設 30m，token reset 後最多再等 30 分鐘，僅佔整個等待週期的 10%——這是合理的代價。
設 5m 有什麼問題？token limited 的等待期間，每 5 分鐘觸發一次失敗呼叫，徒增 context 消耗，對縮短等待時間毫無幫助。
建議：
- claude.ai Pro/Max → 30m（reset 最長 5 小時，interval 只影響 reset 後的反應速度）
- Anthropic API（token bucket）→ 5m（容量持續補充，短 interval 有實際效果）
短任務的定時觸發：像 Linux at 一樣用
/loop 是為長時間輪詢設計的。如果你只是想「30 分鐘後做一件事，做完就算了」，更合適的工具是 /schedule（Routines）——支援一次性定時觸發，行為類似 Linux 的 at 命令：設一個時間點，Claude 到時候跑一次，結束就刪除排程。
/schedule 30 分鐘後執行 build，完成後回報結果
/schedule 今晚 23:00 推送 release branch，確認最新 commit 是否正確
/schedule 跑在 Anthropic 雲端，即使關掉電腦也能在指定時間自動執行——這是 /loop 做不到的。
最佳 Resume Prompt 寫法
Prompt 寫法直接決定 loop 能不能正確從中斷點繼續，而非每次重頭跑。
核心原則：冪等性（Idempotency）——好的 loop prompt 要讓任務「跑兩次也不出問題」，已完成的部分自動跳過，未完成的繼續執行。
結構模板：
繼續 [任務名稱]。
判斷進度的方式：[如何辨別哪些已完成]。
已完成的項目跳過，只處理 [未完成的條件]。
全部完成後回報：[完成摘要格式]。
若遇到錯誤，記錄後繼續下一個，不要中止整個任務。
差的寫法（每輪重頭跑）：
執行 build-static-website.sh
好的寫法（冪等，能正確 resume）：
繼續執行 build-static-website.sh -no-deploy。
若 public/ 目錄已存在且比 content/ 新，跳過 build 直接回報結果。
build 完成後輸出：完成時間、頁面數量、是否有錯誤。
Opus 批次任務範例：
繼續 body review 任務。
已有 body_reviewed: true 的文章直接跳過。
只處理尚未標記的文章，每篇完成後更新 front matter。
全部完成後回報：處理篇數、跳過篇數、有無錯誤。
若 token 不足中途停止，下次觸發會從相同邏輯繼續。
實際使用方式
長時間任務 + token 斷點恢復用 /loop：
以下是一個真實規模的例子：18 年累積的 8 萬筆 Evernote 筆記，要清洗、LLM 深度分析重構、自動分類、加上雙向連結，最後轉成 Obsidian vault。整個流程分四個階段，每階段一個 loop：
第一階段：透過 Python API 批次拉取並清洗
直接呼叫 Evernote API 取得原始內容，拉取與格式清洗同步完成，省去 .enex 匯出這一步。
Evernote API 有 rate limit（每小時請求上限），8 萬筆拉完可能跨越數個小時。這裡有兩層中斷風險：Evernote API 的 rate limit 讓 fetch_notes.py 退避暫停，以及 Claude token 用盡讓整個 session 停住。/loop 同時應對這兩種中斷——不管哪一層斷掉，resume 後都從上次的 GUID 繼續，不會重複拉取。
/loop 30m 繼續執行 fetch_notes.py，從 Evernote API 批次拉取筆記。
已有 fetched: true 的筆記跳過（依 note GUID 判斷）。
拉取同時清洗：去除廢棄標籤、修復亂碼、統一 markdown 格式，寫入 evernote/cleaned/。
遇到 Evernote API 429 自動退避等待，不要中止整批作業。
每完成 500 筆寫入 fetch.log。全部完成後回報：拉取筆數、清洗修復數、API 錯誤清單。
第二階段：LLM 深度內容分析與重構（最 token 密集，最容易斷）
每筆筆記送進 Opus 做以下處理：語意摘要（提取核心論點，濃縮為 3–5 句）、知識點拆解（將長篇筆記拆為原子化概念）、時效性判斷（標記「仍然有效」或「已過時」）、改寫重構（修正口語化表達、補充缺漏的上下文）、情緒標記（辨識筆記情緒傾向：洞見/疑問/待辦/靈感）。
/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：
/schedule 30 分鐘後執行 build-static-website.sh -no-deploy，完成後回報頁面數量與是否有錯誤。
/schedule 今晚 23:00 推送 release branch 到 origin，並確認最新 commit 是否正確。
確保 Claude Code 視窗保持開啟（Desktop App 最穩），/loop 才能持續觸發。/schedule 跑在 Anthropic 雲端，即使關掉電腦也能在指定時間自動執行。
總結
- Claude Code 沒有內建 token 限制後自動恢復功能
/loop可以達到幾乎相同的效果：token 恢復後最多等一個 interval 自動繼續- claude.ai Pro/Max 建議 interval 設 30m，API 用戶設 5m
- Loop 觸發遇到任務還在跑，會等 idle 後補觸發一次，不衝突、不疊加多次
- 手動送出新訊息才會中斷任務，loop 本身不會
- 此做法符合 Anthropic TOS，API 官方文件預期客戶端會自動重試
- Prompt 要寫「繼續未完成」而非「重新執行」，避免每輪從頭跑
- 短任務改用
/schedule一次性定時觸發，行為類似 Linuxat命令
本文原載於 blog.stanwu.org，歡迎至原文閱讀完整版本與後續更新：
https://blog.stanwu.org/posts/claude-code-loop-token-limit-auto-resume/
