生成过程中可以点停止；输入框里只留文字和一个按钮；每周额度约 2000 万 token，不同模型按各自倍率消耗。
停止正在进行的回答
Agent 工作时，发送按钮会变成停止按钮。点击后这一轮会尽快收尾：
- 模型正在输出文字时，立刻停在当前位置，已经写出的内容会保留为这一轮的回复，并标注「已停止」。
- Agent 正在执行某个工具时，会等这个工具执行完再停，不会把它打断在一半。
- 停止后的会话可以照常继续，之前的上下文都在。
更简洁的对话框
输入框里现在只有文字和一个发送按钮。原来放在框里的模型和思考强度，移到了输入框下方，以纯文字显示：右侧是「模型 思考强度」，左侧是当前额度还剩多少。点击任意一项仍然可以切换或打开设置。
额度按 token 计
以前按「轮数」计：不管一轮对话多长，都算一次。现在按模型实际消耗的 token 计：
- 每周额度约 2000 万 token，滚动计算，用掉的部分七天后恢复。
- 不同模型有不同倍率，消耗更高的模型会更快用完额度；倍率显示在模型菜单里。
- 输入和输出的 token 都计入。Agent 每调用一次模型都会带上之前的上下文，所以长对话和多步骤任务消耗更多。
- 使用自己配置的模型不占用额度。
设置里的额度页会显示已用和总量。
已知限制
- 桌面端使用本地 Docker 沙箱时暂时不能停止，额度也仍按每轮一个固定值估算。
- 个别上游模型不返回 token 用量，这时按文本长度估算。
- 额度在一轮开始前检查，一轮进行中即使用完也会让它跑完。
每次发布后节点要重新下载约 80 MB 的沙箱镜像，新会话的第一条消息因此会慢约 6 秒。现在每次发布只需下载约 6 MB。
现象
新开一个会话发第一条消息时，状态有时会在「等待工作区空闲」停留六七秒。
原因
这段时间其实是沙箱在启动，而且慢在下载镜像：沙箱镜像里有一层约 70 MB 的运行时（系统包和 Pi），内容没有变，但每次重新构建都会被当成新的一层，于是每发布一次，集群里的每个节点都要把它重新下载一遍。
现在的行为
- 运行时单独做成一个固定版本的镜像，只在升级 Pi 或系统包时才重新发布。
- 每次发布的沙箱镜像只在它上面叠加约 6 MB 的内容，节点下载通常不到一秒。
已知限制
- 等待沙箱启动时，状态文字仍可能显示为「等待工作区空闲」，这个文案会在后续版本改准确。
- 升级 Pi 版本的那一次发布，节点仍需要下载完整的运行时。
现在可以公开查看每个组件是否正常、响应有多快，以及每次发布改了什么。
服务状态
status.tjuclaw.cloud 显示各个组件的实时状态：
- 对外入口：Web 客户端、官网与文档站、API、登录、客户端下载
- Agent 执行链路：沙箱网关、模型上游、模型网关、镜像仓库
- 核心服务：业务 API、身份服务、人机验证、公开情报采集
每个组件都有当前、中位和 P95 响应时间、24 小时可用率，以及最近一百次左右探测的延迟曲线，失败的探测会单独标出。探针部署在腾讯云北京，每分钟测量一次，页面每分钟自动刷新。
更新日志
你正在看的这个站点。以后每一次改动都会在这里留下记录：改了什么、为什么改、还有哪些已知限制。
已知限制
- 延迟曲线只覆盖最近约一百次探测，更长的历史趋势暂时没有公开展示。
- 探针和核心服务在同一台机器上，这台机器整体宕机时状态页也无法访问。
生成回复时显示当前卡在沙箱、Pi 还是上游模型；Agent 新建或修改的笔记会刷新到侧栏，并以链接形式列在回复下方。
处理状态
以前等待回复时只有一句笼统的「正在思考」。现在状态文字会按云端的真实阶段变化，等待超过两秒还会显示已经等了多久：
- 正在连接云端：请求已到服务端，正在联系沙箱
- 等待工作区空闲：你的上一个操作还占用着工作区
- 等待沙箱就绪：沙箱正在创建或启动
- 正在启动 Pi：沙箱已就绪，正在准备工作区并启动 Agent
- 等待模型回复：请求已发给上游模型，还没收到第一个字
- 模型正在思考 / 正在回答：模型正在输出
- 正在调用工具：工具执行中
Agent 写的笔记
- 回复结束后，知识库侧栏会自动刷新，Agent 新建的笔记不用再手动刷新页面才能看到。
- 这一轮新建或修改过的笔记会列在回复下方，标注「新建」或「已更新」，点击直接打开。
- 链接保存在会话里，刷新页面或翻看历史对话时仍然可用。
已知限制
- 桌面端使用本地 Docker 沙箱时，暂时还是原来的状态文字。
- 如果 Agent 修改的正是你在编辑器里打开着的那篇笔记，需要重新打开才能看到新内容。
一条回复已经生成、却没能存进会话时，后续每条消息都会失败。现在会自动补回丢失的那一轮并继续对话。
现象
个别会话在发出第一条消息之后，再发任何内容都提示「Agent 沙箱暂时不可用，请稍后重试」，重试也没有用。
原因
那一轮回复其实已经在沙箱里生成并保存，但服务端没能把它写进会话记录。之后的每条新消息都被当成「同一轮的不同内容」，沙箱拒绝执行，而这个拒绝在途中被统一报成了「不可用」。
现在的行为
- 沙箱遇到这种情况会把已经保存的那一轮原样交还，而不是只报失败。
- 服务端先把丢失的那一轮补进会话，再把你刚发的消息作为下一轮发出。
- 受影响的会话不需要任何手动操作，直接再发一条消息即可恢复，之前丢失的回复也会出现在记录里。