用于编码和 AI 应用的统一控制台：有哪些变化以及如何使用

当编码助手模式和 AI 应用模式合并为一个工作界面后，TokenLab Console 对我们来说就不再仅仅是一个仪表板了。在我们的流水线中，请求、回复以及围绕它们的账户状态现在汇集在一起。这消除了每次会话中的上下文切换，也改变了我们阅读缓慢回复的方式。

主要内容

• 编码助手模式和 AI 应用模式现在都存在于 TokenLab Console 中；这两个旧的入口点已合并为一体。
• 现有的链接仍然有效，之前的对话也依然存在。无需手动迁移任何内容。
• 回复会随着模型的生成实时流式传输，而不是仅在最后才显示。界面会显示首字时间（first-token timing）。
• 首字延迟是一个记录在案的请求信号（请求日志中的 ttft_ms），而不仅仅是界面上的装饰。
• 当对话中途余额不足时，充值入口就在对话旁边，而不是在单独的账单页面中。
• 控制台的模型选择遵循公共目录；请查看模型目录以获取当前选项。当前的目录示例包括 Claude Sonnet 5 和 DeepSeek V4 Pro。

TokenLab Console 发生了什么变化，以及什么没有变

此次变更通过两条变更日志条目发布。控制台融合（2026-08-04）将两个旧的入口点合并为一个控制台。控制台聊天流式传输（2026-08-18）为聊天增加了流式传输功能。这两项变更相隔一个月发布，因此错过第一条消息的团队仍然可以免费获得第二条。

这是一个界面上的变化，而不是行为上的变化。模型调用、密钥和计费保持不变。旧链接继续有效，现有的对话在合并过程中得到了保留。没有手动迁移步骤。

融合步骤是关于入口点的，而不是关于模型访问权限的。流式传输步骤是关于回复如何显示的，而不是关于计费哪些 token 的。这一点很重要，因为产品界面的变化可能会掩盖行为上的变化，而这次并没有。编码助手模式和 AI 应用模式现在共享同一个位置，因此会话中的第一个决定不再是关于打开哪个入口点。

如果您的团队有指向旧入口点的运行手册（runbooks），请在有空时更新标签。旧链接仍然有效，因此运行手册不会中断。控制台是您进行新工作时应收藏的页面。当您在任一模式中选择模型时，该选择遵循公共目录，因此请查看模型目录。当前的目录示例包括 Claude Sonnet 5 和 DeepSeek V4 Pro。

TokenLab Console 中的流式传输改变了您阅读会话的方式

流式传输改变了您感知处理进度的时间点。在我们的流水线中，控制台网关客户端构建流式聊天请求，回复会增量呈现。界面显示首字时间，因此您可以查看模型何时开始回答。控制台还将该信号记录为 ttft_ms，这是请求日志中的一个可选列。

首字时间告诉您第一个 token 何时到达，而总延迟告诉您整个回复何时完成。这是两个不同的问题，因此当回复感觉缓慢时，请先检查 ttft_ms。如果第一个 token 到达较晚，则等待发生在生成之前。如果第一个 token 到达较早但回复拖沓，则等待发生在流的其余部分。

当我们观察缓慢的会话时，我们会将 ttft_ms 与请求的其他证据进行比较，而不是通过加载图标进行猜测。请求级证据的作用域限定为组织，涵盖了路由、计费状态、缓存状态以及请求背后的模型和密钥上下文。控制台展示了您本需要从日志中挖掘出的相同请求记录。

阅读首字信号的工作示例：

# 控制台请求日志将 `ttft_ms` 作为可选列公开。
# 1. 将请求日志过滤为您正在检查的请求。
# 2. 读取 `ttft_ms`。
# 3. 将 `ttft_ms` 与同一行中请求的总延迟进行比较。

有关确切的流式请求格式，请使用当前的 TokenLab API 文档。复制一个带有虚构字段的请求示例，其作用不如拥有这些名称的文档页面有用。

流式传输不会改变您的计费方式，因为产生的 token 相同，只是它们在到达时可见。由于回复现在是流式的，即使会话中断，也会显示部分回复而不是什么都没有。这改变了您诊断会话中途失败的方式。对于聊天流无法覆盖的长时间运行的任务，请参阅异步图像生成任务指南。

如何验证缓慢的会话而不进行猜测

从请求日志开始，而不是从加载图标开始，因为 ttft_ms 列会告诉您第一个 token 何时到达。如果该数字很高，说明模型尚未开始回答。如果该数字很低，说明模型开始得早，而剩余的流花费了时间。这种拆分使您不会责怪路径中错误的部分。

请求记录的作用域限定为您的组织。它包括服务于该请求的路由、计费状态、缓存状态以及模型和密钥上下文。这些字段汇集在一起，因此您可以将该会话作为一个事件来阅读，而不是拼凑不同的页面。相同的请求记录可在仪表板中获得，这有助于比较控制台视图与账户级数据。Request Console 指南解释了这些证据所在的位置。

例如，如果第一个 token 到达较早但回复拖沓，ttft_ms 就不是主要信号，因为流的其余部分才是。您可以在同一个请求记录中查看路由和缓存状态。您可以检查请求是命中了缓存还是发送到了模型。您可以查看附加了哪些密钥和模型上下文。

这些信息本身并不能说明全部情况，但放在一起为您提供了查看的方向。当我们观察缓慢的会话时，请求日志提供了我们需要的所有细节。在得出结论之前，我们会将 ttft_ms 与其他请求级证据进行比较。

当请求因余额不足而失败或暂停时，相同的工作流程也很有帮助。请求记录包含计费状态，因此失败不再是一个谜。充值入口就在对话旁边，因此修复操作保留在同一个窗口中。您无需离开会话即可找到下一步，因此您可以充值然后继续。

如果余额没问题，您可以继续检查路由、缓存状态或模型选择。关键是要按顺序阅读请求级证据。首先询问第一个 token 何时到达，然后询问是哪个路由提供了服务，最后询问记录中关于计费、缓存、模型和密钥上下文的其他信息。这个顺序很简单，并且与控制台呈现数据的方式相匹配。

限制

流式传输显示的是进度，而不是吞吐量，因为流可以快速开始但仍需很长时间才能完成。快速的首字并不证明整个请求都很快。首字时间也取决于模型和路由。请在同一模型内进行比较，而不是跨模型比较。

ttft_ms 的变化可能反映了路由、缓存状态或模型选择，而不仅仅是提示词。将 ttft_ms 视为请求日志中的一个信号。在得出结论之前，请将其与其他请求级证据配对。这是一个用于阅读会话的界面，而不是用于对模型进行排名的基准测试。

控制台不会将聊天流变成作业运行器。如果您有长时间运行的图像任务，请使用异步图像生成任务指南，而不是保持聊天流打开。流式界面适用于逐个 token 到达的回复。异步指南适用于在聊天回复之外运行的工作。

还要记住，请求级证据的作用域限定为组织，这会将请求与其周围的账户上下文联系起来。这也意味着您不应将一个请求视为全局基准。该记录涵盖了该请求的路由、计费状态、缓存状态以及模型和密钥上下文。这是开始诊断的有力起点。它不是提供商或模型的排名。当我们比较会话时，我们在同一个模型和同一个路由系列内进行比较，这保持了比较的公正性。

常见问题解答

我的旧控制台链接还能用吗？

是的。旧链接继续有效，现有的对话在合并过程中得到了保留。无需手动迁移任何内容。如果您收藏了控制台页面，它仍然有效。

首字时间实际上测量的是什么？

它测量的是流式回复中第一个 token 到达的时间，控制台将其显示在界面中，并将其记录为 ttft_ms（请求日志中的一个可选列）。它不测量总延迟或吞吐量。

当对话余额不足时，我在哪里充值？

使用对话旁边的充值入口，该入口会在对话中途余额不足时出现，因此您无需离开会话即可处理余额。仪表板中的账单页面仍然是处理更广泛账户工作的地方。

我可以跨不同模型比较首字时间吗？

不可以，这不是一个清晰的比较。首字时间取决于模型和路由，因此请在同一模型内进行比较，而不是跨模型比较。将 ttft_ms 用作一个请求级信号，而不是模型排名。

创建一个 API 密钥并在仪表板的新控制台中运行一个会话。