如果我開了 10 個 thread,結果撞到帳號的每日額度上限,這 10 個 thread 裡已經在跑的工作會不會被中斷、資料會不會遺失?
不會遺失。根據官方說明,一個因為額度而暫停的 thread,是進入等待狀態,不是被終止或清空——它的檔案、工具狀態、對話紀錄都會被保留,額度恢復之後(不管是隔天額度重置,還是你自己調整方案),這個 thread 會自動從暫停的地方繼續,不需要你重新開一次。
這代表撞到 200 上限這件事,實際造成的影響是時間上的延遲,不是工作成果的損失——比較實際會影響你的,反而是「原本預期今天能拿到的結果,現在要等到額度恢復才能繼續」這個時間落差,如果你的任務有明確的時間壓力(例如今天一定要交出某個結果),這個延遲本身就是需要納入規劃的風險,不能只因為「資料不會遺失」就完全放心。
為什麼審核負擔的複雜度,是「接近平方成長」而不是隨 thread 數量單純線性增加?
如果每個 thread 完全獨立、彼此互不相關,審核負擔確實會是線性的——看完第一份 diff 花多少時間,看第二份大概也花差不多時間,總時間就是單一份的時間乘以 thread 數量。但實際情況通常不是這樣:如果好幾個 thread 是圍繞同一個大目標拆分出來的子任務,它們之間很可能有隱性的關聯——例如兩個 thread 都動到了同一段共用邏輯,或是一個 thread 的假設前提,剛好被另一個 thread 的修改推翻了。
這種情況下,你不能只是把每份 diff 獨立審過就結束,還得額外花時間比對「這幾份改動放在一起,會不會互相衝突」——這個比對工作量,理論上是每兩個 thread 之間都要檢查一次,thread 數量增加時,兩兩比對的組合數會比 thread 數量本身增加得更快,這正是複雜度接近平方成長,而不是單純線性增加的原因。
如果我的訂閱方案額度足夠、也還沒接近 200 上限,是不是就代表我可以放心一次開很多個 thread?
不完全是——額度足夠只代表你「技術上」有辦法同時跑很多個 thread,不代表這麼做對你的實際工作流程是最佳選擇。額度是一個相對客觀、可以量化的限制,但審核負擔是另一個維度的限制,兩者不會互相抵消:即使你的額度多到用不完,你能實際仔細審核的 diff 數量,依然受限於你自己每天有多少時間跟專注力可以投入審閱。
比較實際的判斷方式,是把「額度是否足夠」跟「我審得完嗎」當成兩個獨立的問題分別回答,只有兩者都給出肯定答案時,才值得一次開比較多的 thread——如果額度足夠但審核跟不上,結果通常是好幾份改動堆在那裡沒人仔細看過,反而增加了「某個問題被合併進主線但沒被發現」的風險,這種風險不會因為你額度充裕就自動消失。
實務上,有沒有一個具體的判斷方法,幫我決定某個任務適不適合拆成多個平行 thread 來做?
一個比較實用的判斷標準,是先看這個任務本身能不能被拆成「彼此互相獨立、改動範圍不會重疊」的幾個子任務——官方給的例子裡,「在 API、網頁、行動裝置三個不同 repository 裡各自退役同一個舊版 endpoint」就是一個很適合拆的案例,因為三個 repository 本身就是獨立的,thread 之間天生不會互相干擾,審核時也只需要各自確認每個 repository 的改動是否正確,不需要額外比對彼此有沒有衝突。
反過來,如果任務性質是「在同一個 repository 裡,針對同一段核心邏輯做好幾種不同的優化嘗試」,這種情況即使表面上可以拆成多個 thread,實際上因為改動範圍高度重疊,審核時反而要花更多力氣比對哪個版本比較好、有沒有互相矛盾的地方——這類任務通常更適合用循序漸進、一次一個 thread 的方式處理,而不是一次性平行展開,盲目追求「thread 開越多越快」反而可能拖慢整體進度。
Claude Code Projects 重新設計上線後,官方設定了一個明確的硬性上限:每個帳號每天最多能開 200 個新 thread,涵蓋你所有的 project。多篇報導都提到這個數字,但通常只是順帶一提,沒有進一步討論——這個上限實際上該怎麼理解、什麼情況下會先撞到別的瓶頸而不是這個數字本身。
這個上限是「每個帳號、每天、所有 project 加總」計算,不是「每個 project 各自 200 個」。如果你同時有好幾個 project 在跑,thread 數量是共用同一個額度——這代表如果你手上有三個 project 都在密集使用 thread,額度會比只跑一個 project 時更快用完,需要自己在多個 project 之間做取捨,而不是每個 project 都有獨立的 200 個名額。
根據官方說明,一個 thread 如果因為撞到用量限制而暫停,不會直接失敗或消失,而是會等待、之後自動恢復——這代表 200 這個數字造成的是「延遲」,不是「工作遺失」。實務上,如果你的用量模式是集中在一天內密集開很多 thread,比較可能先撞到這個上限;如果你的用量是拆分成好幾天、每天開幾個,通常不容易真的碰到這條線。
200 是一個帳號層級的硬上限,但實務上多數人會先撞到另一個更早出現的限制——你的 Pro 或 Max 方案本身的用量額度。因為每一個 thread 都是一個完整的 Claude Code 雲端 session,消耗額度的速度跟你平常單獨開一個 session 是一樣的,並不會因為它是「project 底下的 thread」就比較便宜。這代表如果你一口氣開 10 個 thread 平行跑,消耗的額度大約等同於同時開 10 個獨立 session——對大多數訂閱方案而言,這個消耗速度會比 200 這個上限更早讓你感覺到限制,200 反而更像是一個理論上限,不是多數人實際會撞到的第一道牆。
比額度更容易被低估的瓶頸,是「審核」這件事本身的人力成本。過去你只需要看一個 thread 的結果,現在如果你同時開了 5 個、10 個並行 thread,你需要看的是 5 份、10 份各自獨立的 diff、各自的執行邏輯、各自可能存在的問題——而且因為每個 thread 是基於各自的假設獨立工作,如果任務拆分得不夠清楚,你收到的可能是好幾份基於重疊或衝突假設做出來的結果,審核的複雜度不是隨 thread 數量線性增加,而是更接近平方成長,因為你還得比對這幾份結果彼此之間有沒有矛盾。
比較務實的判斷方式,不是看你的額度還剩多少、或是離 200 這個上限還有多遠,而是先問自己:如果這幾個 thread 同時回報結果,我有沒有足夠的時間跟精力,一份一份仔細審過?如果答案是沒有,即使額度充足、離 200 上限還很遠,開太多平行 thread 本身就會製造出你來不及消化的審核堆積,實際效益反而比少開幾個、但每個都認真審過的做法更差。