compact failed | Friends of the Crustacean 🦞🤝 | Page 1

proven lake Apr 15, 2026, 12:06 AM

#

我最近一直遇到compact失敗的問題：
報錯內容
07:50:04+08:00 [compaction] Full summarization failed, trying partial: Summarization failed: This operation was aborted
07:50:05+08:00 [compaction] Partial summarization also failed: Summarization failed: This operation was aborted
07:50:07+08:00 [compaction] Full summarization failed, trying partial: Summarization failed: This operation was aborted
07:50:08+08:00 [compaction] Partial summarization also failed: Summarization failed: This operation was aborted

rugged iglooBOT Apr 15, 2026, 12:07 AM

#

先查一下 FAQ 路径和源码里的 compaction 报错来源。

#

這個報錯我剛查了下 source，This operation was aborted 比較像是 compaction 的 summarization 請求被取消了，不是單純「摘要內容太大」而已。

先麻煩你貼這 4 個輸出，最好是 重現一次 /compact 同時開 log：

openclaw --version
openclaw status
openclaw models status
openclaw logs --follow

我現在比較懷疑這幾種情況：

run 被外層中止了
- 例如同一個 session 又進了新訊息
- gateway 重啟 / 連線中斷
- 某個 abort signal 把 compaction 一起 cancel 掉

#

模型或 provider 端把請求 abort 了
- 特別是本地模型、OpenAI-compatible backend、或不太穩的代理
timeout / idle timeout
- compaction 有獨立的 agents.defaults.compaction.timeoutSeconds
- 如果是模型卡住，也可能是主 run timeout / idle timeout 先打斷它
只壞在這個 thread/session
- 這種可以先試一次：
```
/new
```
如果新 session 正常，問題就比較像是舊 transcript / session 狀態造成的

如果你現在是用 本地模型或小模型 跑主對話，我會很推薦直接指定一個比較穩的 compaction model，例如：

#

{
  agents: {
    defaults: {
      compaction: {
        model: "openrouter/anthropic/claude-sonnet-4-6"
      }
    }
  }
}

相關 docs:

#

你把 openclaw --version + status + models status + 重現時那段 log 貼上來，我可以幫你更精準縮到是哪一層在 abort。

proven lake Apr 15, 2026, 11:15 AM

#

OpenClaw 2026.3.31 (213a704)

rugged iglooBOT Apr 15, 2026, 11:16 AM

#

我看了一下，你這邊至少有兩個值得先注意的點，我再幫你追一下最近有沒有相關修正。

#

這個資訊很有幫助，我現在先看到兩個重點：

你現在是 2026.3.31，而且已經有 2026.4.14 可更新
- 我剛翻了一下 repo，2026.3.31 之後其實有不少 compaction/abort 相關修正
- 所以我會先建議你 先升到最新穩定版再測一次
2 bootstrap files present 這行有點可疑
- BOOTSTRAP.md 正常應該只在全新 workspace 第一次啟動時存在，完成後就不該一直留著
- 之前確實有遇過 殘留 BOOTSTRAP.md 讓 agent 一直處在奇怪 bootstrapping 狀態 的案例

下一步麻煩你再貼兩樣：

openclaw models status
openclaw logs --follow

#

然後：

開著 openclaw logs --follow
在同一個 thread 裡重現一次 /compact
貼 前後 20 到 40 行 log

我最想看的是失敗前後有沒有這些訊號：

AbortError
timeout
run aborted / superseded
provider/backend 斷線
gateway restart

另外也想確認一下你是不是在用：

本地模型
或 OpenAI-compatible backend（像 LM Studio / Ollama / 其他代理）

#

如果是，我會很懷疑 compaction summarization 被 backend 直接 abort。

如果你想先做個快速排除，也可以先試這兩個：

新 session 測試
```
/new
```
如果新 session 正常，代表比較像舊 transcript / session 狀態問題

指定穩一點的 compaction model

{
  agents: {
    defaults: {
      compaction: {

#

          model: "openrouter/anthropic/claude-sonnet-4-6"
        }
      }
    }
  }

Docs:

你把 models status 和那段 log 貼上來，我可以再幫你縮到更準。

proven lake Apr 15, 2026, 11:17 AM

#

rugged iglooBOT Apr 15, 2026, 11:18 AM

#

沒事，這份其實已經有幫助了。

這裡最關鍵的一點是：

你這個 thread 的 session 是 mimo-v2-omni
而且 token 是 126k / 262k，只有 48%

所以這比較不像是「context 已經炸滿，compact 也塞不進去」那種問題。
更像是 compaction 的 summarization 請求本身被 abort/cancel 了。

我現在比較懷疑這兩個方向：

mimo-v2-omni 這條 summarization 路徑有問題
你目前的 2026.3.31 剛好撞到後面已修掉的 compaction bug

先幫我確認一件事：

#

你這個是 手動打 /compact 就失敗
還是 自動 compact 的時候失敗？

另外因為字數限制，你不用整份都貼，最有用的其實只要這 2 小段：

1) `models status` 裡面跟 `mimo-v2-omni` 有關的那幾行

只要目前 thread 用到的 model / provider / auth 狀態就好

2) compaction 失敗前後的 10 到 20 行 log

只要包含這些關鍵字附近的行：

compaction
abort
timeout
superseded
restart

如果 Discord 不好貼，最省事的方法是：

#

直接把輸出存成 .txt
然後上傳附件

另外我會先建議你做兩個低風險測試：

測試 A, 先更新到最新穩定版

你現在落後到 2026.4.14，而且這中間確實有多個 compaction 修正。
這個我會放在優先級很前面。

更新 docs:
https://docs.openclaw.ai/install/updating

測試 B, 同一個 thread 暫時切別的模型，再跑一次 `/compact`

如果換模型就正常，幾乎可以直接鎖定是 mimo-v2-omni + compaction 這條路有問題。

如果你願意，下一則直接貼：

「手動 /compact 還是自動 compact」

#

mimo-v2-omni 那幾行 models status
失敗前後 10 到 20 行 log

我可以再幫你往下縮。

proven lake Apr 15, 2026, 11:21 AM

#

不是mimo的那個會話出問題，實際上是miss gemin那個會話出問題 02:05:36+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 58ms conn=a2f8705e…17d2 id=82d0444e…ba78
02:43:06+00:00 warn compaction {"subsystem":"compaction"} Full summarization failed, trying partial: Summarization failed: This operation was aborted
02:43:07+00:00 warn compaction {"subsystem":"compaction"} Partial summarization also failed: Summarization failed: This operation was aborted
02:48:04+00:00 info typing TTL reached (2m); stopping typing indicator
03:28:28+00:00 info gateway/ws {"subsystem":"gateway/ws"} webchat disconnected code=1001 reason=n/a conn=a2f8705e-6704-4a6d-8e48-5dd62ebd17d2
03:28:28+00:00 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=8211458a-9c94-45b4-9d34-357ee550338a remote=127.0.0.1 client=openclaw-control-ui webchat vcontrol-ui
03:45:24+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 68ms conn=8211458a…338a id=2e879292…dc7b
03:45:25+00:00 warn compaction {"subsystem":"compaction"} Full summarization failed, trying partial: Summarization failed: This operation was aborted
03:45:27+00:00 warn compaction {"subsystem":"compaction"} Partial summarization also failed: Summarization failed: This operation was aborted
03:48:19+00:00 info typing TTL reached (2m); stopping typing indicator
04:35:55+00:00 error [tools] edit failed: Could not find the exact text in memory/2026-04-15.md. The old text must match exactly including all whitespace and newlines.

rugged iglooBOT Apr 15, 2026, 11:22 AM

#

這段 log 有用，現在方向清楚很多了。

看起來：

出問題的是 miss-gemini 那個 session
你前面貼的 sessions table 裡，它大概率是在跑 glm-5.1:cloud
compaction 失敗時，附近沒有看到 gateway restart / crash
03:28 的 webchat disconnect 跟 04:35 的 memory edit failed，看起來都不是主因

所以我現在會把它收斂成：

預設 compaction 會用當前 session 的主模型。
你的 miss-gemini session 如果是 glm-5.1:cloud，那就是 GLM 這條 compaction summarization 路徑在 abort。

這比起「OpenClaw 整體壞掉」更像是：

2026.3.31 的 compaction bug
或 glm-5.1:cloud 在 compaction/summarization 這條路不穩

#

我會先建議你直接做這 3 件事

1) 先升到 `2026.4.14`

你現在版本真的有點舊，而且 2026.3.31 之後有多個 compaction 修正。

Docs:
https://docs.openclaw.ai/install/updating

2) 幫 compaction 指定一個不同於 GLM 的模型

因為預設就是用當前 session model 做 compaction，這剛好是最可疑的點。

{
  agents: {
    defaults: {
      compaction: {

#

        model: "<另一個你已知穩定可用的 provider/model-id>"
      }
    }
  }
}

Docs:

如果你把 openclaw models status 裡 GLM 那段 或 你想改用的另一個模型那段 貼出來，我可以幫你寫成精確 config，不用你猜字串。

3) 在那個 session 試一次 `/new`

如果新 session 正常，舊 session 不正常，那就代表可能還有 transcript/session state 因素。

#

目前我對這份 log 的判讀

typing TTL reached：只是打字指示器停掉，不是原因
webchat disconnected code=1001：時間對不上，多半無關
edit failed ... memory/2026-04-15.md：這是後面的工具編輯失敗，也不是 compact abort 的根因

如果你願意，下一則最有價值的是二選一：

A. 更新後再試一次，回報還會不會發生
B. 貼 openclaw models status 裡 glm-5.1:cloud 那段，我幫你寫 compaction.model 的精確配置

如果更新後、而且換了 compaction model 之後還會重現，那我覺得就很像該提 GitHub issue 了。

proven lake Apr 15, 2026, 11:23 AM

#

但，蝦哥，我不敢升級，4月後版本在win環境一直出現問題，有時候是discoerd通道出問題，我真不敢升級，社群爆的issue正好跟我的使用環境高度相關

rugged iglooBOT Apr 15, 2026, 11:24 AM

#

這很合理，我不會硬推你升級。

如果你現在的 Win + Discord 環境本來就脆，我也覺得 不要為了追 compact bug 去冒整體升級風險。先走 workaround 比較穩。

我會這樣排優先順序

方案 1，最推薦，先不升級

不要動版本，只把 compaction 改走別的模型。

因為預設 compaction 會用「當前 session 的主模型」，而你現在看起來像是 GLM 那條 compaction 路徑在 abort。
所以最小風險的做法是：

平常對話還是照舊
只有 compaction 改用另一個你已知穩定的模型

#

{
  agents: {
    defaults: {
      compaction: {
        model: "<你另一個已知穩定可用的 provider/model-id>"
      }
    }
  }
}

這種改法的好處是：

不需要升級
不碰 Discord channel 設定
只改 compaction 這一條路

#

Docs:
https://docs.openclaw.ai/gateway/configuration-reference#agentsdefaultscompaction

方案 2，次推薦，先避免常撞到 compaction

開 context pruning，讓舊 tool output 先被裁掉，減少進入 compaction 的機會。

{
  agents: {
    defaults: {
      contextPruning: {
        mode: "cache-ttl",
        ttl: "1h",
        keepLastAssistants: 3

#

      }
    }
  }
}

Docs:
https://docs.openclaw.ai/concepts/session-pruning
https://docs.openclaw.ai/gateway/configuration-reference#agentsdefaultscontextpruning

再搭配：

長對話做到一段就 /new
大量工具輸出後不要硬撐太久

#

方案 3，最保守的臨時操作法

如果你現在連 config 都不想動，那就：

在 那個出問題的 session
先用 /model 切到另一個你信得過的模型
然後再跑 /compact

如果這樣成功，就幾乎能確定是 GLM compaction 路徑 的問題，不是你整個 gateway 壞掉。

我的建議

如果是我，我會先做 方案 1。
因為它的風險遠小於升級，而且最對症。

如果你願意，把你 models status 裡 另一個你覺得穩的模型那一行 貼來，我可以直接幫你把 compaction.model 那段寫成可貼的 config。
這樣你不用自己猜字串。

proven lake Apr 15, 2026, 11:27 AM

#

"models": {
"mode": "merge",
"providers": {
"ollama": {
"baseUrl": "http://127.0.0.1:11434",
"apiKey": "3b71221b70fXXXX",
"api": "ollama",
"models": [
{
"id": "qwen3.5:397b-cloud",
"name": "qwen3.5:397b-cloud (Custom Provider)",
"reasoning": true,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 262144,
"maxTokens": 16384
},
{
"id": "qwen3.5:cloud",
"name": "qwen3.5:cloud (Custom Provider)",
"reasoning": true,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 262144,
"maxTokens": 16384
},
{
"id": "kimi-k2.5:cloud",
"name": "kimi-k2.5:cloud (Custom Provider)",
"reasoning": true,
"input": [
"text",
"image"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 262144,
"maxTokens": 16384
},
{
"id": "glm-5.1:cloud", //這是目前主模型
"name": "glm-5.1:cloud (Custom Provider)",
"reasoning": true,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 198000,
"maxTokens": 16384
},
{

#

"compaction": {
"mode": "safeguard",
"reserveTokensFloor": 25000,
"keepRecentTokens": 50000,
"model": "nebius/Qwen/Qwen3.5-397B-A17B",
"memoryFlush": {
"enabled": true,
"softThresholdTokens": 9000
}
}, 這是compact的配置

rugged iglooBOT Apr 15, 2026, 11:27 AM

#

好，這樣就夠了，不用升級我們也能先試。

你這個 provider id 就是 ollama，所以 compaction model 的寫法應該是：

provider/model-id

也就是像這樣：

ollama/qwen3.5:cloud

我會建議你先這樣配

#

{
  agents: {
    defaults: {
      compaction: {
        model: "ollama/qwen3.5:cloud"
      }
    }
  }
}

為什麼我先推 `qwen3.5:cloud`

跟你現在的 glm-5.1:cloud 是同一個 custom provider 路徑，改動最小
context window 比 GLM 大
比 397b 那顆更適合先做低風險測試，compaction 不需要先上最重的模型

#

最穩的操作順序

先不要升級
先把 compaction 改成：
```
"ollama/qwen3.5:cloud"
```
在那個 miss-gemini session 再試一次 /compact

如果這樣正常，基本上就能確定：

問題不是你整個 Win/Discord 環境炸掉
而是 glm-5.1:cloud 當 compaction model 時會 abort

如果 `qwen3.5:cloud` 還是不行

#

第二順位我會試：

ollama/qwen3.5:397b-cloud

再不行才考慮：

ollama/kimi-k2.5:cloud

小提醒

你剛剛貼的 apiKey 雖然有打碼，但之後貼 config 還是盡量整段遮掉，安全一點。

#

Config docs:
https://docs.openclaw.ai/gateway/configuration-reference#agentsdefaultscompaction

如果你要，我下一則可以直接幫你寫成一段 可貼進 openclaw.json 的完整片段。

#

啊，這個就很關鍵了，我剛剛的判斷要修正一下。

你現在的 compaction 根本不是走 GLM，已經是單獨走：

"model": "nebius/Qwen/Qwen3.5-397B-A17B"

所以現在比較像是：

nebius/Qwen/Qwen3.5-397B-A17B 這條 compaction 路徑在 abort
再加上你這個 config 有點偏激進
- keepRecentTokens: 50000
- reserveTokensFloor: 25000

其中 keepRecentTokens: 50000 我會特別留意，因為 docs 裡的常見值是 20000。你這個值會讓 compaction 保留很多最近內容，等於摘要時要處理的壓力更大。

#

我會建議你先這樣試，先只改一個變數

第一步，只換 compaction model，其他先不動

"compaction": {
  "mode": "safeguard",
  "reserveTokensFloor": 25000,
  "keepRecentTokens": 50000,
  "model": "ollama/qwen3.5:cloud",
  "memoryFlush": {
    "enabled": true,
    "softThresholdTokens": 9000
  }
}

這一步的目的很單純：

#

不升級
不碰 Discord
不一次改太多東西
先驗證是不是 Nebius Qwen compaction path 的問題

第二步，如果還失敗，再把 `keepRecentTokens` 降回保守值

"compaction": {
  "mode": "safeguard",
  "reserveTokensFloor": 20000,
  "keepRecentTokens": 20000,
  "model": "ollama/qwen3.5:cloud",
  "memoryFlush": {
    "enabled": true,

#

    "softThresholdTokens": 9000
  }
}

為什麼我會這樣排

先只換 model，最好定位問題
如果只換 model 就好，主因就是 nebius/Qwen/Qwen3.5-397B-A17B
如果換 model 還是不行，再懷疑你現在的 compaction budget 太大

我現在的主觀排名

第一嫌疑: nebius/Qwen/Qwen3.5-397B-A17B
第二嫌疑: keepRecentTokens: 50000 太高
第三嫌疑: 2026.3.31 本身 compaction bug

Docs:

#

如果你要，我下一則可以直接幫你整理成一段 完整可貼的 openclaw.json 片段，你直接複製就行。

proven lake Apr 15, 2026, 11:31 AM

#

這麼說吧，我換過好幾個不同公司端點的不同模型(qwe死97b/glm5/glm5.1/kimi k2.5)，自從某次ttl timeout之後 compact就一直失效，不管換哪個都不行，我是想問你，會不會是我的那個會話的.jsonl已經毀損？

rugged iglooBOT Apr 15, 2026, 11:32 AM

#

有可能，但我會更精確地說：

比較像是這個 session 的狀態/ transcript 變 stale 或壞掉了
不一定是 .jsonl 檔案本身「語法毀損」

因為如果真的是 .jsonl 結構壞到讀不動，通常你比較容易看到的是：

session load / parse error
transcript read error

你現在看到的是 它還能走到 compaction summarization，那一步才 abort，所以比較像：

舊 session transcript 內容有髒狀態
或 sessions.json 這層 session state 在那次 timeout 之後卡住了
而且因為你說 換很多模型都一樣，這就更像是 session-local 問題，不是單一 provider

OpenClaw 其實就是兩層：

sessions.json，存 session state

#

<sessionId>.jsonl，存 transcript

Docs:

我現在最推薦的驗證法

直接在同一個 chat 送 /new，不要先動檔案。

然後測一次：

新 session 正常 compact
舊 session 還是失敗

如果是這樣，幾乎就能判定：

舊 session 壞了 / stale 了

這是最低風險的驗證方式，也不用升級。

#

我的判斷順位

很有可能是 session 壞狀態，是的
不一定是 jsonl 檔案本身物理毀損
更像是那次 timeout 之後留下的 stale transcript / stale session state

我會怎麼做

先 /new
在新 session 試 /compact
如果新 session 正常，就先把舊 session 視為 tainted，不要再救它了

如果你很在意這個推論，我下一則可以直接幫你整理成：

「怎麼用最小風險確認是舊 session 壞掉」
「如果確認壞掉，後續怎麼處理比較安全」

這樣你就不用碰危險的檔案操作。

proven lake Apr 15, 2026, 11:33 AM

#

怎麼用最小風險確認是舊 session 壞掉?

rugged iglooBOT Apr 15, 2026, 11:33 AM

#

最小風險的確認法，就是 只建立新 session，不碰任何檔案。

最安全測法

在 同一個 chat / thread 送一則獨立訊息：
```
/new
```
不要改任何 config，不要換版本，不要刪檔
- 保持跟現在一樣的 compaction 設定
- 保持同樣的模型環境
在新 session 丟 2 到 3 則很短的測試訊息，例如：
```
測試 1
```

#

   測試 2

然後直接手動跑：

/compact Focus only on these test messages

怎麼判讀結果

情況 A，新 session 可以 compact

這幾乎就表示：

舊 session 壞掉 / stale 了

#

因為你沒有改版本、沒有改 config、沒有換環境，唯一變數只有 session 變新了。

情況 B，新 session 也一樣 compact 失敗

那就表示：

不是舊 session 單獨壞掉
而是更像 compaction model / provider / config 的全域問題

情況 C，新 session 成功，但舊 session 永遠失敗

這是最典型的：

舊 transcript 或舊 session state tainted

為什麼這個方法風險最低

/new 只會開新 session

#

不會刪掉舊 .jsonl
不會動 sessions.json
失敗了也能直接回頭看舊 session

所以這個測法本質上是 只讀式診斷 + 新 session 對照組。

我建議你現在就這樣做

/new
測試 1
測試 2
/compact Focus only on these test messages

然後只回我一句：

新 session 成功 / 失敗

#

我就可以直接幫你判斷下一步。

proven lake Apr 15, 2026, 11:38 AM

#

目前，我還沒/new，這是目前撞到自動compact的狀態：19:36:25+08:00 [agent/embedded] [timeout-compaction] LLM timed out with high prompt token usage (84%); attempting compaction before retry (attempt 1/2) diagId=ovf-mnzz5z7g-8OsMfA
19:36:27+08:00 [compaction-safeguard] Compaction safeguard: no real conversation messages to summarize; writing compaction boundary to suppress re-trigger loop.
19:36:27+08:00 [agent/embedded] [timeout-compaction] compaction succeeded for ollama/glm-5.1:cloud; retrying prompt

rugged iglooBOT Apr 15, 2026, 11:39 AM

#

這段 log 其實是 好消息，而且它會把診斷方向再往前推一點。

這代表什麼

你現在看到的是：

[compaction-safeguard] no real conversation messages to summarize; writing compaction boundary...
[timeout-compaction] compaction succeeded ...

這表示 OpenClaw：

有成功讀到這個 session
有成功執行 compaction safeguard
有成功寫入 compaction boundary
然後才 retry prompt

#

所以這其實 不太像 .jsonl 已經壞到不能用了。
如果是那種真的壞掉的 transcript，通常不會這麼順利走到「寫 boundary 並成功 retry」。

我現在的判讀

這比較像：

這個 session 不是死掉
但它的內容在 compaction 看起來已經變成
- 幾乎沒有「真實對話訊息」
- 或大部分都是 tool / timeout / compaction 相關內容
所以 safeguard 直接走了 「寫 boundary 避免無限重試」 的保護路徑

換句話說：

不像是檔案毀損
更像是 session 內容型態變得很怪 / 很 tool-heavy / timeout 後狀態不漂亮

#

這也代表什麼

你前面懷疑的「舊 session 完全壞掉」這個說法，現在要稍微降一級：

不是完全壞掉
但 很可能已經變成不健康的 session 狀態

如果你要最乾淨的確認

/new 還是最小風險的 A/B test。

因為現在我們知道：

舊 session 還活著
但活得有點怪

所以 /new 的價值變成：

確認「怪的是舊 session 狀態」，還是「整個 compaction 機制都怪」

#

我會怎麼解讀這段新 log

對 .jsonl 物理毀損說法，不利
對 session 狀態髒掉 / transcript 內容異常說法，有利

我的建議

先不要碰檔案
還是照原本計畫做一次 /new 對照
另外我會很想把你的 keepRecentTokens 從 50000 降下來，因為這種 log 很像保留太多 recent 內容，導致真正可摘要的東西很少

如果你願意，我下一則可以直接幫你整理成：

現在這段 log 的白話解讀
接下來最穩的兩步
1. /new 驗證
2. 降 keepRecentTokens 的保守配置

這樣你就可以直接照做。

proven lake Apr 15, 2026, 11:42 AM

#

如果是髒掉，好像沒有必要/new對吧？但我發現一件事，我射的/的是qwen3.5(nebius)，但compact跑去用主模型glm 5.1，這是不是我乾脆把compact模型也換成主模型就好？

rugged iglooBOT Apr 15, 2026, 11:42 AM

#

對，這裡要分開看。

1) `/new` 還有沒有必要？

不是「必要」，但還是有診斷價值。

因為你現在最新這段 log 顯示的是：

舊 session 不是完全壞掉
auto-compaction 有成功
只是走了 boundary-only 的保護路徑

所以：

如果你的目標是先繼續用，那 /new 不是當下必做
如果你的目標是確認「是不是舊 session 狀態有問題」，那 /new 仍然是最乾淨的 A/B 測試

換句話說，/new 現在比較像 診斷工具，不是緊急修復手段

#

2) 那個 log 為什麼顯示 `glm-5.1:cloud`？

這點我剛去看了 source，這裡很容易被誤導。

[timeout-compaction] compaction succeeded for ollama/glm-5.1:cloud; retrying prompt

這行裡的 glm-5.1:cloud，是這次被 retry 的主 run model。
不等於 compaction 一定就是用 GLM 做的。

所以：

不要只因為這一行 log，就推論 compaction override 沒生效

#

3) 那你要不要把 compaction model 直接改成主模型？

我不建議把這當成第一步。

原因很簡單：

你現在已經有太多變數了，session 狀態也還沒完全排除
auto-compaction 剛剛其實有成功，表示當前配置不一定完全失效
這時再把 compaction model 改成主模型，會讓判斷更亂

我會這樣排順序

最穩

先保持 compaction model 不動
把 keepRecentTokens 從 50000 降到 20000 或 30000
看 auto/manual compact 是否還會亂掉

如果你想做 A/B 驗證

再用 /new 做對照

#

最後才是

如果還是不穩，再考慮把 compaction model 改成主模型當測試

我的直接建議

現在先不要動成 glm。
先降 keepRecentTokens，這個比改 compaction model 更像當前症結。

如果你要，我下一則我可以直接給你一段 只改 keepRecentTokens 的最小配置，這樣你只改一個變數，最好觀察。

proven lake Apr 15, 2026, 11:44 AM

#

那我想問你keepRecentTokens這個問題，明明compact模型的上下文窗口試256k，理論上夠用不是嗎？為什麼這樣算太多呢？(主模型總上下文空間才200k)

rugged iglooBOT Apr 15, 2026, 11:45 AM

#

對，你這個直覺很合理，但關鍵在於：

keepRecentTokens 不是在問「compaction 模型 256k 裝不裝得下」
它是在問 「有多少最近的原始內容要完全不壓縮，直接留到之後給主模型吃」

而你真正要 retry 的主模型，是 glm-5.1:cloud，只有 198k。
所以最後真正要 fit 的，不是 256k，而是 主模型那個 198k。

白話版

compaction 流程其實像這樣：

用 compaction model 先做摘要
把舊內容壓成 summary
保留最近一段原始內容不壓
再把「summary + 最近原始內容 + system prompt + tools + 當前訊息」丟回 主模型 重跑

所以 keepRecentTokens: 50000 的意思是：

#

最近 5 萬 token 原封不動保留
這 5 萬不是給 compaction model 的
是留給 後面那次主模型 retry 的

你的數字大概長這樣

主模型：198k

你現在設定：

keepRecentTokens = 50000
reserveTokensFloor = 25000

光這兩個加起來就先吃掉：

50k 保留最近內容
25k 安全緩衝

#

已經是 75k

198k - 75k = 123k

而這 123k 還沒扣掉：

system prompt
workspace/bootstrap
tool schemas
current turn
previous summary
compaction prompt overhead
reasoning 預算
token estimation safety margin

所以實際可用空間，會比你想像的小很多。

#

為什麼我說 50k 偏高

不是說 50k 一定錯，而是：

你的主模型不是 1M context
你的 session 又有 timeout / tool-heavy / compaction weirdness
這時候保留 50k 原文，會讓 compaction 非常容易進入尷尬區間

而 docs 裡常見的 keepRecentTokens 預設是 20k，就是因為這個值通常比較平衡。

一句話總結

compaction model 的 256k，決定「摘要時好不好做」
主模型的 198k，決定「摘要完之後能不能真的塞回去重跑」

所以你這裡真正卡的，更像是 主模型回填空間，不是 compaction model 上下文不夠。

#

如果你要，我可以下一則直接幫你算一版：

保守版
折衷版
你現在這版為什麼容易卡

用你這組 198k / 25k / 50k 直接帶數字給你看。

proven lake Apr 15, 2026, 11:46 AM

#

我理解你的意思了，keepRecentTokens這點事主模型在單的，並非compact是吧？

rugged iglooBOT Apr 15, 2026, 11:46 AM

#

對，你抓到重點了。

keepRecentTokens 主要是站在「主模型 retry 要怎麼塞回去」這邊在算的。
不是說「給 compaction model 多留 50k 上下文」。

更精確一點說：

直接目的：決定 compaction 後，有多少「最近原始內容」不要壓縮，留給主模型
間接影響：它也會影響 compaction 怎麼切邊界、哪些內容被拿去摘要

所以它 不是純 compaction model 參數，而是 整個 compaction 後回填到主模型的 budget 參數。

一句話版：

keepRecentTokens 決定的是 「留多少原文給主模型」
不是 「讓 compaction 模型多吃多少」

#

如果你要，我下一則可以直接幫你配一個 198k 主模型比較合理的 keepRecentTokens / reserveTokensFloor 組合。

proven lake Apr 15, 2026, 11:48 AM

#

這是剛剛手動compact的結果(改成35k保留，並未/new)：misssecretary
應用
— 晚上7:44
⚙️ Compacted (168k → 36k) • Context 36k/198k (18%)
只有您才能看到這個 • 刪除這則訊息然後這是訊息：19:45:06+08:00 [ws] handshake timeout conn=af96ab73-1d16-4d4a-b1e5-bce6ec8f485a remote=127.0.0.1
19:45:07+08:00 [ws] closed before connect conn=af96ab73-1d16-4d4a-b1e5-bce6ec8f485a remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1000 reason=n/a
19:45:58+08:00 [EventQueue] Slow listener detected: InteractionEventListener took 68630ms for event INTERACTION_CREATE

rugged iglooBOT Apr 15, 2026, 11:48 AM

#

這就很關鍵了，漂亮，方向基本抓到了。

目前可以下的結論

不是舊 session 壞掉
不是非得 /new 才能救
keepRecentTokens 太高，很可能就是主因之一

因為你 沒 /new，只是把保留量降到 35k，手動 /compact 就成功了：

168k → 36k

這個證據其實很強。
如果真的是 transcript / .jsonl 壞掉，通常不會因為單純把 keepRecentTokens 從 50k 降到 35k 就突然恢復正常。

你貼的那幾行 log 怎麼看

#

這幾行我反而不太擔心：

handshake timeout ... remote=127.0.0.1
closed before connect ...

這看起來比較像 本機 dashboard / webchat 連線小抖動，不像 compaction 核心錯誤。

Slow listener detected ... 68630ms

這個反而很像是：

這次 Discord interaction 處理花了 68 秒
而 compaction 本來就是一個可能很慢的操作

所以它比較像結果，不是根因。

#

我現在的建議

既然 35k 已經成功，我會這樣做：

先維持 35k 觀察
如果之後 auto-compaction 還偶發失敗，再降到 30k 或 25k

對你這種：

主模型 198k
tool-heavy / timeout-heavy session
又不想升級

我會覺得 25k 到 35k 是比較實際的區間。
50k 對這個環境來說真的偏激進了。

結論一句話

#

你這次測試幾乎已經證明：

問題比較像 compaction budget 配太緊，不像 session 檔案毀損。

如果這樣已經穩了，真的先不用碰 /new。

Glad that helped! 🎉
如果這次調整真的修好了，請 右鍵解答訊息 → Apps → ✅ Mark Solution。
這樣 Answer Overflow 才能把解法收進去，後面的人會少踩很多坑。

proven lake Apr 15, 2026, 11:51 AM

#

我先觀察，蝦哥謝謝，因為這在3.13版本到現在就常常出問題(3.31)，一直時有時無的偶發，以前我沒問妳的時候都是/new就突然好了。然後timeout幾次之後就會一直出問題，所以我想保留這個串，免得我又要重開，如果確認無誤，我會再回報給你，然後做mark

rugged iglooBOT Apr 15, 2026, 11:51 AM

#

好，這樣最穩。保留這個串很合理。

目前至少我們抓到兩個很有價值的訊號：

timeout 之後比較容易開始反覆出問題
/new 或降低 keepRecentTokens 都能把它拉回來

所以現在的假設就比較像是：

長 session + timeout 後，compaction 狀態會變得比較脆
而不是單純某個模型永遠壞掉

你先觀察完全沒問題。
如果它又復發，你回來直接貼這 3 個就好，我就能接著看：

當時的 keepRecentTokens
是 手動 /compact 還是 自動 compact
第一次失敗前後 10 行 log

#compact failed

1) models status 裡面跟 mimo-v2-omni 有關的那幾行

2) compaction 失敗前後的 10 到 20 行 log

測試 A, 先更新到最新穩定版

測試 B, 同一個 thread 暫時切別的模型，再跑一次 /compact

我會先建議你直接做這 3 件事

1) 先升到 2026.4.14

2) 幫 compaction 指定一個不同於 GLM 的模型

3) 在那個 session 試一次 /new

目前我對這份 log 的判讀

我會這樣排優先順序

方案 1，最推薦，先不升級

方案 2，次推薦，先避免常撞到 compaction

方案 3，最保守的臨時操作法

我的建議

我會建議你先這樣配

為什麼我先推 qwen3.5:cloud

最穩的操作順序

如果 qwen3.5:cloud 還是不行

小提醒

我會建議你先這樣試，先只改一個變數

第一步，只換 compaction model，其他先不動

第二步，如果還失敗，再把 keepRecentTokens 降回保守值

為什麼我會這樣排

我現在的主觀排名

我現在最推薦的驗證法

我的判斷順位

我會怎麼做

最安全測法

怎麼判讀結果

情況 A，新 session 可以 compact

情況 B，新 session 也一樣 compact 失敗

情況 C，新 session 成功，但舊 session 永遠失敗

為什麼這個方法風險最低

我建議你現在就這樣做

這代表什麼

我現在的判讀

這也代表什麼

如果你要最乾淨的確認

我會怎麼解讀這段新 log

我的建議

1) /new 還有沒有必要？

2) 那個 log 為什麼顯示 glm-5.1:cloud？

3) 那你要不要把 compaction model 直接改成主模型？

我會這樣排順序

最穩

如果你想做 A/B 驗證

最後才是

我的直接建議

白話版

你的數字大概長這樣

為什麼我說 50k 偏高

一句話總結

目前可以下的結論

你貼的那幾行 log 怎麼看

我現在的建議

結論一句話

1) `models status` 裡面跟 `mimo-v2-omni` 有關的那幾行

測試 B, 同一個 thread 暫時切別的模型，再跑一次 `/compact`

1) 先升到 `2026.4.14`

3) 在那個 session 試一次 `/new`

為什麼我先推 `qwen3.5:cloud`

如果 `qwen3.5:cloud` 還是不行

第二步，如果還失敗，再把 `keepRecentTokens` 降回保守值

1) `/new` 還有沒有必要？

2) 那個 log 為什麼顯示 `glm-5.1:cloud`？