用途：复现并测量 Mastra Code 运行时缺陷。做法是让真实 TUI 连接用户配置的真实模型，由代理输入提示词，并在每一层记录时间戳，逐层比对即可看出时序或顺序在哪一层出错（提供商、网络封装、流转换、运行引擎或 UI reducer）。建议配合 debugging-difficult-bugs 使用：先埋点、再复现、先读日志后修复、最后清理，并把结论转成确定性的签入覆盖（单元测试加 mastracode/tui/e2e/tui/ 下的 TUI E2E 场景）。实机运行只是证据，不是回归测试。
成本与许可：TUI 使用用户已配置的模型和存储的凭证（例如 Claude Max OAuth 登录），每次提示都消耗其配额。请使用短提示，并告知用户所用模型与大致会话数。
主要步骤：
- 添加临时诊断。用 appendFileSync 把每个事件一行 JSON 追加到 <cwd>/debug-token-rate.jsonl。仅记录元数据（时间戳、事件类型、id、长度、token 数），绝不记录提示、响应或工具内容；每条记录打上唯一构建标记（如 my-bug-diagnostics-v1）；每次追加包裹 try {} catch {}；先取时间戳再写入；在关注层的最早与最晚点记录，便于逐步对齐。钩子点：网络层在提供商的 fetch 封装（如 buildAnthropicOAuthFetch，mastracode/sdk/src/providers/claude-max.ts），记录请求开始、响应头到达、经 TransformStream 的每个 body 分块，并用 new Response(body, { status, statusText, headers }) 重新包装；提供商流层在 convertFullStreamChunkToMastra（packages/core/src/stream/aisdk/v5/transform.ts）；运行引擎层在 processStreamChunk（packages/core/src/agent-controller/session-run-engine.ts）；TUI 层在 mastracode/tui/src/tui/event-dispatch.ts。其他提供商可在 mastracode/sdk/src/providers/ 找对应封装。
- 构建并验证埋点已进入产物：pnpm install --frozen-lockfile；pnpm build:mastracode；用 rg 在 dist 中查找构建标记，找不到则该层不会产生记录。
- 在 tmux 中驱动 TUI：在一次性 git 仓库中启动，逐条发送提示并以单独按键发送 Enter，之后读屏。每次改代码都要重新构建并重启会话。
- 按步骤分析：用脚本按步骤分组日志，比较各层耗时跨度；跨度一致说明管线无失真，跨度收缩或增长处即缺陷所在。可用改变单一变量（如 accept-encoding: identity）验证假设，并以小表格报告正常与异常步骤、所用模型、运行与步骤数以及数据无法证明的结论。
- 清理：kill-session，用 rg 确认无残留诊断标记，检查 git diff 只含预期改动，删除日志文件，回滚实验开关，重新构建使 dist 不再含埋点。
限制：工作目录设置不是沙箱，不要授予额外允许路径；实机运行消耗配额且结果不稳定，需多次采样；日志只应含元数据。其他细节资料暂未提供。