我家裡的 NAS 上跑著大概十幾個 OpenClaw cron job，晨間新聞摘要、股票 watchlist 掃描、smart home 狀態巡邏，全部都是 isolated cron agentTurn 設定，丟上去讓它自己跑。

一直以為自己設得還算聰明，system prompt 認真寫，每個 job 結構很固定。心想 prompt cache 應該有在幫我壓成本。

上個月整理 gateway token 使用紀錄的時候，發現不對勁。

每一次 run，輸入 token 全部都是 uncached。沒有一個 cache hit 紀錄。一次都沒有。

我以為是 system prompt 寫法有問題，拆來拆去測了半天。後來搜了一圈，才搞清楚真正的問題在哪。

問題在 TTL。

OpenClaw 的 isolated cron 確實有處理 prompt cache 這件事，有一個機制叫做 resolveIsolatedCronPromptCacheKey()，會用 jobId、agentId、provider、model 這些欄位組出一個穩定的 cache key，設計意圖就是讓同一個 recurring job 在不同 run 之間共用 cache。Key 的設計邏輯上是對的。

但 TTL 怎麼算呢？

現在的邏輯大概是：只有在 retention 或 cacheRetention 設成 long 的時候才給 1 小時 TTL，不然就 fallback 到 provider 預設，大概是 300 秒，也就是 5 分鐘。

而 cron payload 根本沒辦法指定 promptCacheRetention 或 cacheRetention: "long"，查遍 cron 設定格式找不到這個欄位。

所以現在的情況是：只要你的 cron 間隔超過 5 分鐘，無論 cache key 算得多穩定，下一次 run 到的時候 cache 已經過期了，每次都是全額 uncached input cost。

我的晨間新聞摘要間隔 24 小時，股票掃描每 15 分鐘一次，smart home 每 30 分鐘一次。全部都超過 5 分鐘，全部都在乖乖付全額費用，一次 cache 都沒有用到。

等一下，我數了一下我的 job 數量，這樣算下去持續燒了幾個月的 uncached token 費⋯⋯算了，不算了，算了很難受。

resolveIsolatedCronPromptCacheKey() 顯然是為了解決「recurring job 要怎麼共用 cache」這個問題而存在的，但沒有配套的 long retention 選項，cache key 再穩定也沒用。有點像是設計了一個完美的倉庫索引系統，但貨物每 5 分鐘自動清空。

目前我想到的暫時解法有幾個方向：

把部分 job 改成 sub-5-min 頻率，試著在 cache 過期前就重新 hit。但這個做法真的很蠢，增加 run 次數不說，也不是所有 job 都適合這樣搞。

另一個方向是把大型的 context 資料從 system prompt 裡挪出去，用外部檔案或 context slot 載入，讓 uncached token 數量本身變少，算是治標。

治本的做法應該是在 cron payload 開放 promptCacheRetention: "long" 的設定，或是讓 OpenClaw 依照 cron interval 自動判斷，超過 5 分鐘就自動用 long retention。

還有一個我覺得蠻重要的點：現在 UI 上根本看不到 cache hit/miss 率，也看不到 TTL 是多少。我是翻 log 才發現這件事。如果 dashboard 有地方顯示「你的 cron cache 命中率是 0%，原因是 TTL 設定」，問題早就被抓到了。

如果你有在跑 recurring isolated cron，建議去翻一下 token 使用紀錄，確認 cache hit 紀錄是不是空的。我猜很多人在默默付這筆費用但完全不知道原因。

突然想到一個有趣的副產品：如果哪天 OpenClaw 真的支援 per-job 的 cacheRetention: "long"，理論上可以設計出一批 high-frequency small-job 的架構，讓 cache 長時間 warm，把真正複雜的任務分散到多個 job 去做，整體 token 效率會好很多，有點像是 CDN warm cache 的概念。

不過那是之後的事了，現在先去想辦法把 token 帳單壓一壓再說。🔧