Session becomes extremely slow in v1.37.0 after extensive MATLAB work

[proccl]

Bug Report: Session Becomes Extremely Slow in v1.37.0

Summary

After upgrading to kimi-cli v1.37.0, a specific session becomes extremely slow (several seconds per token, even loading animation is laggy), while other sessions and the CLI itself remain fast.

Environment

• OS: Windows 10/11
• kimi-cli version: 1.37.0 (upgraded from 1.30.0)
• Python: 3.13.3
• Model: kimi-code/kimi-for-coding

Problem Description

Symptoms

• Token generation is extremely slow (several seconds per token)
• Loading animation stutters/lags
• Only affects one specific session; other sessions work fine
• kimi --version responds instantly (not a system performance issue)

Session Details

The affected session was used for:

• MATLAB development (7R robotic arm kinematics)
• Bayesian optimization tasks
• Multiple background MATLAB training jobs

Investigation Results

We performed extensive debugging:

1. Context files: Cleaned from 66MB → 63KB (99.9% reduction)

   • Deleted all context_X.jsonl files
   • Cleared wire.jsonl
   • No improvement

2. Task logs: Cleaned from ~60MB → 2MB (96% reduction)

   • Cleared huge output.log files (44MB, 10MB, 4MB)
   • No improvement

3. Additional directories: Removed from state.json

   • Removed D:\Document\code\Matlab\7Rmatlab from additional_dirs
   • No improvement

4. AGENTS.md files: Temporarily renamed 3 large AGENTS.md files in project

   • Total ~22KB of project documentation
   • No improvement

5. Moved entire MATLAB directory: Eliminated any file scanning issues

   • No improvement

Key Finding: Encoding Corruption

In context.jsonl, we found encoding corruption:

{"role":"user","content":"���"}  // Should be "你好"

The file contains invalid UTF-8 sequences, suggesting encoding issues during session persistence.

Current Session State

• context.jsonl: 109 lines, ~63KB
• state.json: 1.5KB
• wire.jsonl: ~23KB (cleared)
• Tasks directory: ~2MB (cleaned)
• Total: Well under normal limits

Reproduction Steps

1. Create a session with extensive MATLAB/technical work
2. Run multiple background tasks that generate large outputs
3. Upgrade from v1.30.0 to v1.37.0
4. Resume the session
5. Observe extreme slowness in token generation

Expected Behavior

Session should remain responsive regardless of history, or provide tools to properly clean/reset session without losing core state.

Actual Behavior

Session becomes unusably slow despite all cleanup efforts.

Workaround

Downgrading to v1.30.0 resolves the issue (confirmed by user).

Additional Context

• The session was working fine in v1.30.0
• Only this specific session is affected; other sessions work normally
• System resources are normal (CPU 13-19%, plenty of RAM)

Possible Causes

1. v1.37.0 streaming/rendering changes: New version may have introduced performance regression with certain session states
2. Encoding handling: Corrupted UTF-8 in context.jsonl may cause parsing overhead
3. Background task scanning: Even with cleaned logs, task metadata scanning may be inefficient

Attachments

N/A (session contains sensitive project data)

Checklist

• I have searched existing issues
• I have provided detailed environment info
• I have tested with a fresh session (works fine)
• Downgrading resolves the issue

[proccl]

Update / 更新：根因已查明 — 本地文件 I/O 開銷，非 token 數量或編碼問題
Root cause identified — local file I/O overhead, not token count or encoding

---

原問題回顧 / Original Problem Summary

症狀 / Symptoms：

• 升級到 kimi-cli v1.37.0 後，特定 session 變得極慢（每個 token 需數秒）
• 加載動畫卡頓
• 僅影響一個 session，其他 session 和 CLI 本身正常
• v1.30.0 降級後問題消失

After upgrading to kimi-cli v1.37.0, a specific session became extremely slow (several seconds per token), loading animation stuttered, while other sessions and the CLI itself remained fast. Downgrading to v1.30.0 resolved the issue.

初步排查 / Initial Investigation：

• 清理 context 文件：66MB → 63KB ❌ 無改善
• 清理 task logs：~60MB → 2MB ❌ 無改善
• 移除 additional_dirs ❌ 無改善
• 發現 context.jsonl 中有編碼亂碼 ���

Context files cleaned from 66MB → 63KB, task logs from ~60MB → 2MB, additional_dirs removed — no improvement. Encoding corruption ��� found in context.jsonl.

---

新發現 / New Findings

卡頓是由 Kimi CLI v1.37.0 恢復 session 時的本地文件 I/O 開銷導致，而非 API token 處理或編碼問題。

The slowness is caused by Kimi CLI v1.37.0's local file I/O overhead during session resume, not API token processing or encoding issues.

指標 / Metric	清理前 / Before	清理後 / After	/fork 分支 / Fork
Session 總大小 / Total size	2,739 KB	127 KB	131 KB
tasks/ 目錄數 / Directories	67	0	0
subagents/ 大小 / Size	343 KB	0	0
首次響應時間 / First response	0.85s	0.01s	~0.1s
Token 數量 / Token count	31,935	31,935	32,389

---

關鍵發現 / Key Discovery

/fork 創建的分支會丟棄 tasks/、subagents/ 和 notifications/，但保留 context.jsonl。分叉後的分支立即變得流暢，儘管其 token 數量比原始 session 還要高。

/fork creates a branch that drops tasks/, subagents/, and notifications/ while preserving context.jsonl. The forked branch became immediately smooth, even though its token count is higher than the original session.

隨後我們手動刪除了原始 session 目錄中的 tasks/、subagents/ 和 notifications/。響應時間從 0.85s → 0.01s，改善了 85 倍。

We then manually deleted tasks/, subagents/, and notifications/ from the original session directory. Response time dropped from 0.85s → 0.01s — an 85x improvement.

這證明了三點：

1. Token 數量不是瓶頸 — fork 的 token 更多卻更快
2. 編碼損壞不是原因 — 清理後 UTF-8 完全正常，問題依然存在
3. 本地文件掃描才是真正元凶 — Kimi CLI v1.37.0 每次恢復 session 時會掃描/解析所有累積的 tasks/* 目錄和 subagents/ 文件。當累積 60+ 個 task 目錄和 subagent 上下文時，產生嚴重 I/O 開銷

This proves:

1. Token count is NOT the bottleneck (fork has more tokens but is faster)
2. Encoding corruption is NOT the cause (UTF-8 is clean after cleanup, issue persisted)
3. Local file scanning is the real culprit: Kimi CLI v1.37.0 appears to scan/parse all accumulated tasks/* directories and subagents/ files on every session resume. When 60+ task directories and subagent contexts accumulate, this creates severe I/O overhead

---

/fork 的實際行為 / What /fork Actually Does

~/.kimi/sessions/<work_dir_md5>/<session_id>/
├── context.jsonl      ← 保留 / kept (核心對話歷史 / core conversation)
├── state.json         ← 保留 / kept (元數據，todos 清空 / metadata, todos cleared)
├── wire.jsonl         ← 保留 / kept (消息流 / message stream)
├── tasks/             ← ❌ 丟棄 / DROPPED (67 個目錄, 2.1MB 日誌 / 67 dirs, 2.1MB logs)
├── subagents/         ← ❌ 丟棄 / DROPPED (1 個目錄, 343KB 上下文 / 1 dir, 343KB context)
└── notifications/     ← ❌ 丟棄 / DROPPED (81KB)

---

已驗證的解決方案 / Confirmed Workarounds

1. /fork — 最簡單。創建一個內容相同但無累積數據的分支，性能立即恢復。
   Easiest. Creates a clean branch instantly with identical conversation history but no accumulated task/subagent data.

2. 手動清理 / Manual cleanup — 直接刪除 session 目錄中的 tasks/、subagents/、notifications/。
   Delete tasks/, subagents/, notifications/ from the session directory directly.

3. 定期 /fork / Periodic /fork — 當 session 在大量工具調用後變慢時執行。
   When a session slows down after extensive tool/subagent usage.

---

更新後的復現步驟 / Updated Reproduction Steps

1. 創建 session 並大量使用工具/subagent
   Create a session and use it heavily with tools/subagents
2. 累積 50+ 個 task 目錄和 subagent 上下文（總計 ~2-3MB）
   Accumulate 50+ task directories and subagent contexts (total ~2-3MB)
3. 在 v1.37.0 中恢復該 session
   Resume the session in v1.37.0
4. 觀察 token 生成極慢（每個 token 數秒）
   Observe extreme slowness in token generation (several seconds per token)
5. 執行 /fork 或手動刪除 tasks/ + subagents/ + notifications/
   Run /fork or manually delete tasks/ + subagents/ + notifications/
6. 觀察性能立即恢復
   Observe immediate performance recovery

---

對 v1.37.1+ 的建議 / Suggestion for v1.37.1+

建議優化 session 恢復流程，避免掃描所有歷史 tasks/ 和 subagents/ 目錄；或提供內建的 /cleanup 或 /compact 命令，安全丟棄累積的輔助數據而不丟失核心對話狀態。

Consider optimizing session resume to avoid scanning all historical tasks/ and subagents/ directories, or provide a built-in /cleanup or /compact command to safely drop accumulated auxiliary data without losing core conversation state.

---

環境 / Environment: Windows 11, kimi-cli 1.37.0, Python 3.13.3

[proccl]

Update / 更新：根因已查明 — 本地文件 I/O 開銷，非 token 數量或編碼問題
Root cause identified — local file I/O overhead, not token count or encoding

---

原問題回顧 / Original Problem Summary

症狀 / Symptoms：

• 升級到 kimi-cli v1.37.0 後，特定 session 變得極慢（每個 token 需數秒）
• 加載動畫卡頓
• 僅影響一個 session，其他 session 和 CLI 本身正常
• v1.30.0 降級後問題消失

After upgrading to kimi-cli v1.37.0, a specific session became extremely slow (several seconds per token), loading animation stuttered, while other sessions and the CLI itself remained fast. Downgrading to v1.30.0 resolved the issue.

初步排查 / Initial Investigation：

• 清理 context 文件：66MB → 63KB ❌ 無改善
• 清理 task logs：~60MB → 2MB ❌ 無改善
• 移除 additional_dirs ❌ 無改善
• 發現 context.jsonl 中有編碼亂碼 ���

Context files cleaned from 66MB → 63KB, task logs from ~60MB → 2MB, additional_dirs removed — no improvement. Encoding corruption ��� found in context.jsonl.

---

新發現 / New Findings

卡頓是由 Kimi CLI v1.37.0 恢復 session 時的本地文件 I/O 開銷導致，而非 API token 處理或編碼問題。

The slowness is caused by Kimi CLI v1.37.0's local file I/O overhead during session resume, not API token processing or encoding issues.

指標 / Metric	清理前 / Before	清理後 / After	/fork 分支 / Fork
Session 總大小 / Total size	2,739 KB	127 KB	131 KB
tasks/ 目錄數 / Directories	67	0	0
subagents/ 大小 / Size	343 KB	0	0
首次響應時間 / First response	0.85s	0.01s	~0.1s
Token 數量 / Token count	31,935	31,935	32,389

---

關鍵發現 / Key Discovery

/fork 創建的分支會丟棄 tasks/、subagents/ 和 notifications/，但保留 context.jsonl。分叉後的分支立即變得流暢，儘管其 token 數量比原始 session 還要高。

/fork creates a branch that drops tasks/, subagents/, and notifications/ while preserving context.jsonl. The forked branch became immediately smooth, even though its token count is higher than the original session.

隨後我們手動刪除了原始 session 目錄中的 tasks/、subagents/ 和 notifications/。響應時間從 0.85s → 0.01s，改善了 85 倍。

We then manually deleted tasks/, subagents/, and notifications/ from the original session directory. Response time dropped from 0.85s → 0.01s — an 85x improvement.

這證明了三點：

1. Token 數量不是瓶頸 — fork 的 token 更多卻更快
2. 編碼損壞不是原因 — 清理後 UTF-8 完全正常，問題依然存在
3. 本地文件掃描才是真正元凶 — Kimi CLI v1.37.0 每次恢復 session 時會掃描/解析所有累積的 tasks/* 目錄和 subagents/ 文件。當累積 60+ 個 task 目錄和 subagent 上下文時，產生嚴重 I/O 開銷

This proves:

1. Token count is NOT the bottleneck (fork has more tokens but is faster)
2. Encoding corruption is NOT the cause (UTF-8 is clean after cleanup, issue persisted)
3. Local file scanning is the real culprit: Kimi CLI v1.37.0 appears to scan/parse all accumulated tasks/* directories and subagents/ files on every session resume. When 60+ task directories and subagent contexts accumulate, this creates severe I/O overhead

---

/fork 的實際行為 / What /fork Actually Does

~/.kimi/sessions/<work_dir_md5>/<session_id>/
├── context.jsonl      ← 保留 / kept (核心對話歷史 / core conversation)
├── state.json         ← 保留 / kept (元數據，todos 清空 / metadata, todos cleared)
├── wire.jsonl         ← 保留 / kept (消息流 / message stream)
├── tasks/             ← ❌ 丟棄 / DROPPED (67 個目錄, 2.1MB 日誌 / 67 dirs, 2.1MB logs)
├── subagents/         ← ❌ 丟棄 / DROPPED (1 個目錄, 343KB 上下文 / 1 dir, 343KB context)
└── notifications/     ← ❌ 丟棄 / DROPPED (81KB)

---

已驗證的解決方案 / Confirmed Workarounds

1. /fork — 最簡單。創建一個內容相同但無累積數據的分支，性能立即恢復。
   Easiest. Creates a clean branch instantly with identical conversation history but no accumulated task/subagent data.

2. 手動清理 / Manual cleanup — 直接刪除 session 目錄中的 tasks/、subagents/、notifications/。
   Delete tasks/, subagents/, notifications/ from the session directory directly.

3. 定期 /fork / Periodic /fork — 當 session 在大量工具調用後變慢時執行。
   When a session slows down after extensive tool/subagent usage.

---

更新後的復現步驟 / Updated Reproduction Steps

1. 創建 session 並大量使用工具/subagent
   Create a session and use it heavily with tools/subagents
2. 累積 50+ 個 task 目錄和 subagent 上下文（總計 ~2-3MB）
   Accumulate 50+ task directories and subagent contexts (total ~2-3MB)
3. 在 v1.37.0 中恢復該 session
   Resume the session in v1.37.0
4. 觀察 token 生成極慢（每個 token 數秒）
   Observe extreme slowness in token generation (several seconds per token)
5. 執行 /fork 或手動刪除 tasks/ + subagents/ + notifications/
   Run /fork or manually delete tasks/ + subagents/ + notifications/
6. 觀察性能立即恢復
   Observe immediate performance recovery

---

對 v1.37.1+ 的建議 / Suggestion for v1.37.1+

建議優化 session 恢復流程，避免掃描所有歷史 tasks/ 和 subagents/ 目錄；或提供內建的 /cleanup 或 /compact 命令，安全丟棄累積的輔助數據而不丟失核心對話狀態。

Consider optimizing session resume to avoid scanning all historical tasks/ and subagents/ directories, or provide a built-in /cleanup or /compact command to safely drop accumulated auxiliary data without losing core conversation state.

---

環境 / Environment: Windows 11, kimi-cli 1.37.0, Python 3.13.3