Day 15 結尾留下一個刺眼的數字：長存活期快取寫入占了主控重算等價成本的 35.16%，照機制，其中一部分是每開一次 session 就要付一次的入場費。拿這把尺回頭量自己，最先對上的是一個我每天在用的東西。我有一個單輪即滅入口，每叫一次就開一個全新的 session，做完一件事就關掉。它每跑一次，都要把常駐指示、規則檔、工具定義從頭載入一遍——這叫冷啟動，我很清楚。可是從 2026-09-16 到 09-27，它被叫了 348 次（含排程與測試），是我派單件工作的主力。明知每次都重付，我還是這樣用。這篇要回答的就是這個矛盾：那筆錢到底付在哪裡。
先說清楚，這不是哪天突然壞掉的事故，是我自己的一條決策留下來的帳。
2026-05-02 我記過一筆工作法決策：每完成一個小任務就關閉 session、開新 session。理由是長 session 的每一輪都要把前面所有對話再讀一次，輪數越多、每輪越重，累計成本是 O(n²)；拆成很多短 session，用自製記憶系統把該留的東西接起來，累計成本只跟任務數成正比，是 O(n)。單輪即滅入口就是這條決策的極端版本：一輪就結束，根本不讓 context 長大。
這個算式本身沒錯，但它偷偷假設了一件事：開一個新 session 的起跳價很小，小到可以忽略。五月做這條決策時，我沒有量過起跳價，只是覺得它不重要；那時候關心的是長 session 越跑越慢、越跑越貴，新開一個看起來就像把帳歸零。
第一幕我查過一個相關的量：每輪固定基底。當時的筆記記著兩個數字：一個 session 的每輪基底約 48K token，313 輪累計 15.1M，占那個 session 總量的 19%；另一個 session 每輪基底 55.9K token，占 34%。這是 2026-09-01 記下的舊筆記，不是本輪重跑；當時的對話紀錄檔已經不在，數字無法重算，只能照記載引用。
同一份筆記還寫了一句更要緊的話：這個基底是分工解決不了的部分。把工作拆給執行者，能解決的是主控反覆讀回報的那一段；每一輪開頭固定要載入的東西，不管誰來做，都得先付。
矛盾就是這樣成形的。我用「拆短」去躲 O(n²)，而拆短的每一刀，都要把這筆拆不掉的基底重新寫進快取一次。context 是省下來了，代價換個地方付。單輪即滅入口把這件事推到極限：它的每一次，都是第一輪。
新 session 一開門，先付紅框裡的三塊才能開工；做完關掉，下一次再從頭付。藍框是拆給執行者能解決的部分，跟紅框無關。便條上的兩個數字口徑不同，只能並列。
圖一畫的是入場費的組成。可惜三塊各自多少 token 我量不到——手上只有合計量，沒有逐項拆分。我說得出它由什麼組成，說不出各占多少。
本輪能重跑的是另一個量：session 第 1 輪的入場量，也就是一般輸入加上快取讀寫。2026-09-05 到 09-27 之間共 469 個 session，其中 32 個記為 0，幾乎都是 Day 15 提過 token 欄不齊全的回填舊列。以一萬 token 為一桶，中位數落在 660K 到 670K 那一桶；1,000K 以上的有 165 個。按模型看平均值，兩個 Opus 版本分別是 1,216,398 和 1,146,304，Fable 是 1,126,119，Sonnet 是 125,525。同一時間窗，冷啟動那一輪的長存活期快取寫入，平均每個 session 在 61,428 到 184,717 token 之間，最高的是 Fable。
這裡要把口徑劃清。舊筆記的 48K／55.9K 是「每輪固定基底」；本輪的 660K 桶是「第 1 輪整輪的入場合計」，可能還包含同一輪裡的多次呼叫與工具往返，紀錄裡沒有定義可以判斷。兩者只能並列，不能相除，也不能說誰是誰的幾倍。
上排是每天跑了幾次，中排是實際耗時，下排是排隊取鎖的等待；橘線與藍線是當日中位數，灰線是當日最大值。最左邊那天還沒開始記耗時與等待。
圖二是單輪即滅入口本身。348 筆裡，在隔離環境跑的 313 筆、本機 28 筆、未記錄 7 筆；退出碼非 0 的 9 筆，占 2.59%，其中 3 筆是逾時被中止。實際耗時有值的 314 筆，中位數 231.0 秒，最長一筆 67.3 分。取鎖等待中位數 505.5 毫秒，最大 6,195 毫秒。
換算下來，取鎖等待的中位數只占耗時中位數約 0.22%，這是我的推算。排隊不是它的主要耗時。這 348 筆的等價成本紀錄值合計 726.89 美元；本篇不拆類別，也不拿它跟長 session 做比較。這筆金額取自單輪即滅自己的執行紀錄，不經過事後回填，Day 15 查明的那筆口徑落差不影響它；它和逐輪用量紀錄是兩份來源，是否重疊我沒核對，所以不拿來相加。
最不利的一點得寫出來：單輪即滅的逐筆紀錄沒有 token 欄。我量得到它跑了幾次、跑多久、等多久，量不到它每一次重付了多少冷啟動。
證據拼起來，答案其實很樸素，也有點難堪：單輪即滅入口的代價不在排隊，在入場。它幾乎不排隊，但入場那一段每次都從頭付。
解法不是換一個更聰明的入口，而是把帳分清楚：哪一段是每次都要重付的，哪一段是分工能解的，哪一段根本不是問題。所以我先改的是看待方式。第一，入場費是固定稅。常駐指示、規則檔、工具定義，每多寫一段，每一個新 session 都要多付一次；單輪即滅跑得越勤，這三塊就越該精簡。它們不是寫一次就算了的文件，而是每次開門都要繳的東西。
第二，拆短的決策不再無條件成立。O(n) 只保證成本線性成長，起跳價決定斜率；如果起跳價本身就很重，拆得越細，付的次數就越多。適合丟給單輪即滅的，應該是本身夠完整、值得付一次完整入場費的工作，而不是順手就拆的零碎小事。
第三，補量測。逐筆紀錄缺 token 欄，是這條帳目前最大的洞。在它補上之前，「每次重付多少」只能從 session 層級的入場量間接看，我不會把它寫成單筆數字。這也是誠實的邊界：我能證明排隊不重，卻還不能證明入場有多重，只能說它在 session 層級看起來不輕。
每一種省 context 的手段都會在別處付回來。拆短省下的，是對話變長之後每輪重讀的量；付回來的，是每一次開門的入場費。單輪即滅把前者壓到最低，把後者乘上它被叫的次數。冷啟動就是那個別處。
那反過來呢？既然每次都重付，為什麼不養著一個長 session，入場只付一次，後面一直用下去？這條路我在五月就放棄過，理由正是 O(n²)。現在兩邊各自要付什麼都攤開了，問題就不再是「長或短」，而是「哪一個位置該常駐、哪一個位置該用完即丟」。而這又牽涉到每個位置上擺的是哪一個模型——那是下一篇要先講清楚的前提。
明日預告：Day 17｜模型越強，不代表系統越可靠
iThome鐵人賽
看影片追技術