PicoClaw users expose the cost of tiny-device state

sipeed/picoclaw issue #3351 is the inspected primary source: “自动压缩会物理删除 session 原始记录，失忆后历史无法找回，为什么没有真正持久化存储？.” The related records were inspected as supporting context rather than independent confirmation.

The facts

- sipeed/picoclaw issue #3351 was created 2026-08-30T07:14:24Z and was open at inspection; its title is “自动压缩会物理删除 session 原始记录，失忆后历史无法找回，为什么没有真正持久化存储？.” - sipeed/picoclaw issue #3350 was created 2026-08-30T06:52:52Z and was open at inspection; its title is “嵌入式/低性能设备下 Web UI 输入框打字严重卡顿.” - sipeed/picoclaw PR #3347 was created 2026-08-27T13:23:15Z and was open at inspection; its title is “fix laggy interface.” - The repository reported 29919 stars, 35 open issues, default branch main, and last push 2026-08-27T21:13:30Z. - The latest tagged-release baseline checked was nightly published 2026-07-02T01:26:53Z.

What changed

sipeed/picoclaw issue #3351 reports: 问题描述 长对话下，session 的原始聊天记录会被自动压缩**物理删除**，导致失忆后连历史记录都找不回来。 用户直接查看 session 文件（.jsonl），确认内容**真的变少了**——不是前端显示问题，是文件本身被重写删减了。 根因（源码定位） session 存储 pkg/memory/jsonl.go 的 JSONLStore 不是纯 append-only 日志： 平时 AddMessage 是 append-only 追加 但 **SetHistory → rewriteJSONL 会物理覆盖整个 jsonl 文件**，旧消息被真删除 Compact 也会物理删除逻辑跳过的行 触发路径（pkg/agent/context_legacy.go）： 1. maybeSummarize 检查阈值：默认 SummarizeMessageThreshold: 20、SummarizeTokenPercent: 75（pkg/config/defaults.go） 2. 超过阈值 → 异步 summarizeSession：旧消息喂 LLM 生成 summary，然后 SetHistory(sessionKey, keptHistory) **物理重写 jsonl，旧消息从文件里消失** 3. 紧急情况 forceCompression 更狠：直接丢最老 ~50% 的 Turn，同样 SetHistory 重写 结果：压缩后.jsonl 里只剩「摘要 + 最近保留的消息」，**原始消息永久丢失**，查文件也找不回。 核心问题 1. **为什么 session 原始记录不能真正持久化？** 自动压缩应该只影响「发往模型的上下文」，而不应该物理删除磁盘上的原始记录。 2. **没有不可变的原始记录存储吗？** 目前 meta.json 只存压缩后的 summary，丢了原始消息就没有任何地方能找回。 期望行为 session 原始消息**不可变持久化**（append-only 日志 / 归档文件），压缩只生成独立摘要，不触碰原始文件 或提供开关：preserve_raw_history: true，关闭自动压缩对磁盘文件的物理删除 压缩后用户仍能查看到完整的原始对话记录 环境信息 PicoClaw 版本：0.3.x 访问方式：Web UI 触发条件：单会话消息数 > 20 或 context 用量 > 75%

sipeed/picoclaw issue #3350 reports: 问题描述 在嵌入式设备（如 RV1106、RISC-V 板子等低性能硬件）上运行 PicoClaw Launcher，通过浏览器访问 Web UI 时，聊天输入框打字极其卡顿，每输入一个字符都有明显延迟。 复现步骤 1. 在低性能嵌入式设备上运行 picoclaw-launcher 2. 打开浏览器访问 Web UI（如 http://device-ip:18800/） 3. 进行几轮对话，积累一些聊天记录 4. 在输入框中尝试打字 5. **结果**：每个字符输入都有明显卡顿，CPU 飙升 疑问 为什么输入框打字会受聊天记录长度影响？** 按常理，输入框只是浏览器里的一个 元素，打字应该只涉及浏览器本地的文本编辑，不应该跟「聊天记录盒子」（历史消息渲染区）有关才对。难道不是发送消息时才需要处理历史记录吗？ 推测原因 根据已有 issue #3281 和 PR #3347 分析，这是 React 架构问题： 输入框组件嵌套在 ChatPage 组件内 每次按键触发 setMessage → 导致 **整个 ChatPage 重新渲染**（包括所有历史消息） 桌面端性能强感知不明显，嵌入式设备 CPU 弱，重渲染几百条消息直接卡死 期望行为 输入框打字完全本地化，不触发聊天记录区重渲染 或提供「轻量模式」：虚拟列表、懒加载、输入框状态隔离 低性能设备上也能流畅输入 环境信息 设备：嵌入式板卡（RV1106 / RISC-V / 老旧手机等） PicoClaw 版本：0.3.x 访问方式：浏览器 Web UI 聊天记录：> 20 条消息时明显卡顿

sipeed/picoclaw PR #3347 reports: Description This fix allows the web UI to stop lagging when there's a lot of text in the chat area. I have built and tested picoclaw-launcher and have no more lag either on the desktop and mobile browser (both Brave). I am **no** TS / node developer, this has been analyzed and fixed by Qwen 3.8 27B harnessed on crush, here's what it has to say about it: Root cause The chat input lives in ChatPage (web/frontend/src/components/chat/chat-page.tsx:110). Every keystroke calls setInput, re-rendering the whole page, which re-renders the message list and re-rendered every AssistantMessage – each one re-parsing its markdown via react-markdown + remark-gfm + rehype-sanitize + rehype-highlight. Cost is O(history length) per keystroke, hence the lag once history grows. Fix Memoized both message components so unchanged messages are skipped: web/frontend/src/components/chat/assistant-message.tsx:305 – export const AssistantMessage = memo(AssistantMessageBase) web/frontend/src/components/chat/user-message.tsx:103 – export const UserMessage = memo(UserMessageBase) This is safe because props are plain data (no inline callbacks), and the safe store's streaming updates (features/chat/protocol.ts:163–179) preserve object references for messages that didn't change, so during streaming only the actively-updating message re-renders. Named exports and imports are unchanged. Per your instruction, I did not build or launch – recommend running pnpm build / lint in web/frontend and typing in a long session to

Why it matters

A tiny agent is not operationally cheap if saving memory destroys evidence or the local control surface becomes unusable. The operator test is whether the system stays bounded and whether its receipts still describe the action after failure, retry or restart.

Current

The primary record was open when captured on 2026-08-31. The tagged-release baseline was nightly published 2026-07-02T01:26:53Z. Repository metadata, source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.

Evidence

The primary URL is https://github.com/sipeed/picoclaw/issues/3351. Supporting records are https://github.com/sipeed/picoclaw/issues/3350 and https://github.com/sipeed/picoclaw/pull/3347. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.

Source boundary

Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.

Operator take

Separate durable transcripts from compacted working context, measure low-end input latency and accept interface fixes only with before-and-after device evidence. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.

Caveat

Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.

Source inspected; source state, environment and release boundary remain explicit.