我是在一个很普通的下午被逼着动手的。那天用OpenCode跑一个接近十万token上下文的代码重构任务模型在终端里刷输出刷得像瀑布我心里却只剩两个问题这玩意儿到底还要跑多久我这一下午烧掉的token折成真金白银是多少OpenCode本身没有一块能看到实时token生成速度的面板光靠肉眼盯进度条根本判断不了模型是在认真思考还是在原地打转。后来我去社区翻了一圈发现“看不见token”不是我一人的毛病很多人都想要一个能随时瞟一眼当前速率的工具但要么是没有现成的要么就是各家方案特别散。于是我自己动手写了一个OpenCode插件核心就是实时显示Token生成速度顺手还做了一套自己每天盯着看也不疲劳的DSH样式显示方案。这篇文章准备把从事件捕获、速率计算、终端渲染到踩坑收尾的完整思路全部交代一遍代码和配置都贴出来保证你能照着重现而不是只看个效果图。1. 解决的核心痛点不可见的token消耗比模型智商更让人焦虑1.1 token速度在长上下文任务里决定了等待与成本很多人一看“实时显示token生成速度”就以为这是个锦上添花的小玩具实际上它在我们这种把AI编码当成日常生产工具的人眼里是刚需。这里面的逻辑其实很简单大模型输出的token数可以拆成两个维度的乘积——带宽每秒生成的token数和耗时的积分。当你在跑一个复杂的多文件重构任务时模型可能要生成几千甚至上万行代码这时候你看到的“快”和“慢”不只是体感问题而是直接决定你是继续等它跑完还是果断中断、换路子重来。举一个我自己的例子有一回我让OpenCode分析一个老项目的依赖关系并生成迁移文档模型前三分钟生成速度一直稳定在每秒80到100个token但到第四分钟突然跌到每秒不到10个token。如果没做速度显示我大概率会以为它还在正常干活可就因为插件里那行数字垮了我立刻意识到它可能是陷入了一个很长的自我纠结状态于是果断CtrlC换了一个更小的上下文范围重新执行。结果整个任务只多花了不到两分钟就完成了。这就是实时速度显示在成本层面的意义——它让你在正确的时间做中断决策而不是陪模型一起耗时长跑。成本维度就更直白了。无论你是按token付费的API调用方还是用订阅制套餐输出token的速率直接决定了你的钱花得有多快。一个简单的换算假设你的API单价是每百万输出token 15美元一个长时间运行的重构任务如果生成5万token的代码光输出成本就是0.75美元如果任务跑了一个小时而模型实际有效输出的时间只有20分钟那剩下40分钟就是在烧钱空转。没有实时速度监控你根本不知道空转发生在这40分钟里的哪一刻。1.2 OpenCode原生界面缺了哪块信息平心而论OpenCode本身的TUI已经做得相当不错了消息流、工具调用记录、状态徽标都排布得比较清晰但这些信息更偏向“任务发生了什么”而不是“任务正在以什么效率发生”。原生的输出面板里你最多能因为它刷屏的快慢获得一个模糊的体感而体感这东西在长上下文任务里是最容易骗人的。举个例子模型生成一段长代码时如果每个数据块里都夹带着大面积的重叠文本比如复制粘贴了一个超长的JSON结构这时的token增量实际上很小但输出内容看起来却很大反过来当模型在一个循环里反复调用工具时工具调用的结果可能一屏屏地滚但这些内容根本不产生输出token。这两种场景光靠肉眼都看不出真实的生成效率必须用数据说话。所以我在设计这个插件的时候给自己定了三个非常明确的目标每秒刷新一次速率数字不允许有明显延迟看到的就是当前一秒的真实状态。必须区分“生成token”和“输入token”不能混在一锅粥里显示一个总体数字。显示方式要在一米外能扫一眼看懂而不是需要停下手里的活去读一串数字。1.3 有了实时速度之后使用习惯发生的变化装上这个插件跑了大概一周以后我发现自己使用OpenCode的方式都变了。以前我是一股脑把任务丢进去然后盯着屏幕发呆现在我会先看插件显示的输出速度如果前10秒速度低于20 tokens/s且没有工具调用动作我会直接终止并调整提示词。这个习惯帮我省下了大量的无效等待时间也让我的上下文预算管理变得更主动——我能在会话进行到一半的时候根据速度表现判断还有多少余量可以继续输入更多文件内容。2. 摸清OpenCode的插件通信与事件订阅机制做插件的第一步永远是搞清楚数据从哪里来。OpenCode插件机制的设计思路上跟Claude Code、Codex这类工具差异不小它并不强制要求你走“重插件”的路径而是开放了事件流订阅能力。下面是我实现这个插件时梳理出的一套事件流模型为了讲清楚我用的是经过简化的版本但核心结构在真实环境里是成立的。2.1 先搞清楚数据源输出流、日志还是API回调OpenCode在运行时会暴露出一个事件总线模型每次从服务端收到数据块都会向这个总线推一个增量事件。事件的大致结构是这样{ type: message.delta, data: { message_id: msg_8f3k2d9d, token_count: 24, input_tokens: 1830, output_tokens: 152, timestamp: 1719894523126 }, session_id: sess_ab12 }你可能会问为什么不直接解析OpenCode打印到终端上的文本流来统计我也试过而且这个方案在早期版本里是可行的但经过几个版本迭代以后终端输出的文本经过ANSI转义、截断处理和日志重定向解析起来非常脆弱。有一次OpenCode更新了缩进格式我的正则表达式整个失效统计出来的数字错得离谱。换成事件总线之后插件的稳定性明显提升因为事件流是结构化数据不受终端渲染层改动的影响。2.2 最小可用钩子设计订阅增量事件而非轮询我自己实现的时候并没有选择定时轮询内存状态因为轮询的问题在于如果轮询间隔太长速率就体现不出实时性如果太短又会白白消耗CPU。事件驱动的方式天然规避这种矛盾——有数据来就更新没数据来就保持现状。import { createEventBusClient } from opencode/plugin-sdk; const bus createEventBusClient({ sessionId: current, onEvent: (event) { if (event.type ! message.delta) return; const delta event.data.token_count ?? 0; const timestamp event.data.timestamp ?? Date.now(); // 把这次增量推入速率计算器后面会详细说算法 rateTracker.push(timestamp, delta); // 触发一次UI重绘 renderer.update({ currentSpeed: rateTracker.currentSpeed(), avgSpeed: rateTracker.averageSpeed(), totalDelta: rateTracker.totalDelta(), inputTokens: event.data.input_tokens, outputTokens: event.data.output_tokens, }); }, });这里有个关键点必须把事件派发和UI渲染解耦。事件本身在一秒内可能触发几十次如果每一次都立刻重绘终端闪烁会非常明显而且终端I/O会成为瓶颈。所以我在渲染层加了一个节流器强制每秒最多重绘一次。事件回调只负责更新内存中的状态渲染由节流器统一触发。2.3 三个容易被低估的边界场景事件流看着简单真正跑起来以后才暴露出不少边界场景这里挑三个最坑的展开讲。第一个是中断事件。当用户按Esc或CtrlC中断模型生成时OpenCode会发一个message.interrupted事件。这个事件里不携带token增量但它会终结当前的消息流。如果你的速率计算器没有处理“消息中断”这个状态中断之后你看到的速率数字会停留在上一次更新时的数值上造成一种“模型还在输出”的幻觉。我处理的方式是收到中断事件后立刻将当前窗口内的所有采样点清零让速度归零。第二个是缓存命中。如果你用的是支持上下文缓存的模型服务端当模型命中缓存时服务端不会返回正常的增量token而是返回cache_read_tokens或者干脆没有增量数据。这个场景很容易让插件显示“0 tokens/s”但模型其实已经开始生成了。所以我在事件处理逻辑里加了一条规则如果连续5秒没有收到message.delta事件没有工具调用事件也没有流结束事件才判定为真正的停滞否则只是“等待缓存读取”显示状态文案为“缓存读取中”。说起来很简单但为了把这个“等待”跟“卡死”区分开我调试了整整一个下午。第三个是工具调用。OpenCode里模型调用工具时工具的输入和输出很多情况下会以事件形式进入消息流。这些内容计算token吗在模型端的计费逻辑里工具输出通常会被折算成下一轮的上下文输入所以如果你不加区分地把tool_result事件里的token也都算进“生成速度”那最终显示的数字会严重失真。我的处理方式是让插件只统计message.delta和message.complete事件中的输出token增量工具类事件一律忽略。这样显示的才是真正由模型“生成”的那部分速度而不是混入工具数据后的“伪速度”。3. 实时速度计算瞬时速率、滑动窗口和平滑曲线的取舍拿到事件流之后下一步就是怎么把这些零散的增量转换成一条看得懂的“速度”。这个环节本质上是算法设计问题我在这个部分摔过好几个跟头必须单独拿出来说说。3.1 一个直观但不稳定的算法每秒采样我第一版的做法特别朴素每秒把这一秒内收到的token增量求和展示为“上一次x秒内的生成速度”。听起来很合理但实际用起来完全不是那么回事。大模型输出token的分布极其不均有时候一个数据块里就包含了50个token然后紧接着会有几百毫秒的停顿如果这两者恰好落在采样周期的边界上显示出来的速度就会从极快跳到极慢再到极快数字跳得比股票行情还厉害。这种瞬时值带来的另一个麻烦是——你很难据此做判断。一个显示为“当前速度98 tokens/s”的界面过两秒却变成了“7 tokens/s”你根本说不清模型是变慢了还是只是采样周期没对齐。这会导致用户在错误的时间进行中断操作反而降低了使用效率。3.2 改进后的滑动窗口算法后来我把算法改成了滑动窗口模式。核心思路是维护一个固定时长的队列每当有新的事件增量进入时把它和对应的时间戳写入队列尾部同时把队列头部早于窗口起点的事件全部弹出当前速度就等于窗口内token增量总和除以窗口的实际时长单位是秒。下面是我实际跑着的速率计算器精简版class SlidingWindowRateTracker { private timestamps: number[] []; private deltas: number[] []; private windowMs 5000; constructor(windowMs?: number) { if (windowMs) this.windowMs windowMs; } push(timestamp: number, delta: number) { this.timestamps.push(timestamp); this.deltas.push(delta); this.prune(timestamp); } private prune(now: number) { const cutoff now - this.windowMs; while (this.timestamps.length 0 this.timestamps[0] cutoff) { this.timestamps.shift(); this.deltas.shift(); } } currentSpeed(): number { if (this.timestamps.length 2) return 0; const oldest this.timestamps[0]; const newest this.timestamps[this.timestamps.length - 1]; const elapsedSec (newest - oldest) / 1000; if (elapsedSec 0) return 0; const totalDelta this.deltas.reduce((a, b) a b, 0); return Math.round(totalDelta / elapsedSec); } reset() { this.timestamps []; this.deltas []; } }为什么窗口大小要选5秒而不是1秒或30秒这是我在实践里反复调出来的经验值。1秒窗口的问题上文说了太碎30秒窗口又太钝——当你发现速度变化时其实已经过去了半分钟。5秒窗口的响应速度既能捕捉到一轮连续的快速输出又能在模型真停顿时最多滞后5秒内反映出来在“灵敏”和“稳定”之间取到了一个比较实用的平衡点。3.3 峰值速度和平均速度面向不同决策场景实际显示的时候我会把速度分成两个维度它们服务的决策场景完全不同速度类型计算方式适合判断的问题我的展示建议当前速度最近5秒滑动窗口“它是不是在正常干活”作为主数字彩色显示平均速度整个消息流的累计token数/总耗时“这个会话下来平均效率是多少”作为次要数字弱化显示峰值速度窗口内最大瞬时增量“这台机器的输出上限在哪”仅排障时展示平时隐藏很多人会把平均速度和当前速度搞混导致误判。比如说一个任务跑了20分钟平均速度是40 tokens/s看起来还挺正常但如果看当前速度你可能会发现最后5分钟模型一直在低速爬行平均数是把前面高速输出的部分匀过来的。所以我的原则是做中断决策看当前速度做成本复盘看平均速度别拿平均数指导实时操作。关于平滑处理还有一个细节如果你觉得当前速度的波动还是太明显可以对窗口内的事件增量做一次指数移动平均EMA给最近的采样点更高的权重。但我实测下来EMA的问题是它会让速度的“拐点”变得滞后反而增加了判断的模糊性。所以最后我干脆只保留滑动窗口不做额外的平滑——宁可数字真实地跳也不要让数字在最大与最小之间和稀泥。4. DSH样式的设计与终端实现说完了算法接下来是这套插件里最有“存在感”的一部分——DSH样式。这其实是我给自己这套显示方案起的名字全称是Dashboard Style Header中文可以理解成“仪表盘式状态头”。因为OpenCode终端界面的信息密度已经很高了我不想让插件再挂一个巨大的悬浮窗挤占可视区域所以选了顶部的一行状态头来做文章。4.1 DSH样式的高层设计原则我在设计DSH样式时给自己定了四条规则也都是踩过坑以后才总结出来的一行内把信息放完。状态头的高度必须严格固定为一行不能因为内容长短自动换行。一旦换行终端布局就会被顶乱OpenCode原有的会话记录滚动位置会错位。颜色语义化而不是花哨。token速度快和慢我用绿色和黄色做区分停滞或者出错用红色普通状态用默认的灰白色。这样眼睛的余光一扫就能感知状态不需要读文字。速度数字用等宽字体加粗。终端里如果字体不等宽数字每刷新一次宽度都在变状态头会像心电图一样左右震荡。预留降级方案。很多终端不支持真彩色或者特殊转义序列这时候DSH样式应当退化为普通的纯文本格式而不是一堆乱码。下面是我最终采用的渲染模板┌ opencode 会话耗时 12:34 ──────────────┐ speed: 86 tok/s avg: 53 tok/s total: 82.4k tok └──────────────────────────────────────┘这只是一个示意实际实现里我使用的是ANSI转义序列来做颜色和光标定位没有用重绘整帧的重方案因为重绘整帧在终端里容易出现闪烁和撕裂。4.2 渲染策略ANSI真彩、256色调色板与暴力降级终端渲染这块有一个常见的坑就是对“颜色支持”的假设太乐观。现在很多终端模拟器都支持真彩TrueColor即24位RGB但用户的生产环境里真的不一定——尤其是通过SSH访问的远程服务器终端类型可能还是古老的xterm-256color甚至更低。我在这块的做法分三层降级逻辑先检测环境变量COLORTERM是否包含truecolor如果包含就用24位RGB输出DSH样式的主题色。如果没有真彩支持检测TERM是否包含256color有的话就把颜色映射到256色调色板取一个最接近的设计色。如果上面两个都不满足直接退化成无颜色的纯文本只保留下划线或反白效果来突出速度数字。核心的渲染判断逻辑大致长这样if [[ $COLORTERM *truecolor* ]]; then COLOR_SPEED_FAST\e[38;2;0;200;150m COLOR_SPEED_SLOW\e[38;2;255;180;0m COLOR_ERROR\e[38;2;255;80;80m elif [[ $TERM *256color* ]]; then COLOR_SPEED_FAST\e[38;5;42m COLOR_SPEED_SLOW\e[38;5;220m COLOR_ERROR\e[38;5;196m else COLOR_SPEED_FAST COLOR_SPEED_SLOW COLOR_ERROR fi4.3 窄终端窗口和多个会话并行的降级表现DSH样式在宽终端里很舒服但当我把它放到一个只开了80列宽、甚至还开着好几个分屏面板的终端里一行放不下怎么办我的处理是速度、平均速度和总token数三个指标里只保住当前速度其他两个弱化显示甚至隐藏。在当前速度前面加一个方向指示符比如表示上涨、表示平稳、表示下降这样即便空间不够用户也可以一眼看出趋势。还有一个我自己很满意的设计细节当模型完全停顿时DSH样式里的短线动画也会停下而不是继续闪烁。代码里用的是“输出内容是否包含周期性帧绘制”如果最近一帧没有任何token增量就停止播放动画帧。这种“以静示静”的反馈比任何文字提示都更有直觉性——看到动画停下来你的手自然会放到中断键上。5. 安装、配置与踩坑实录好的界面有了算法也有了但所有这些都要落到“能装、能跑、能维护”这三个词上。这一章我把安装配置过程连带自己在真实环境里踩过的三个大坑都写出来希望能帮你省下一点时间。5.1 插件安装与配置项OpenCode的插件市场本身还在快速演进我不能保证几个月后目录结构不变但当时我安装这套插件的方式是通过OpenCode的插件市场搜索opencode-token-speed找到之后执行安装命令。如果是本地开发调试我更推荐直接把项目克隆下来然后做符号链接这样每次改动代码插件在OpenCode里立即生效。配置文件长这个样子{ tokenSpeed: { windowMs: 5000, refreshIntervalMs: 1000, theme: dsh, showAverage: true, showTotalTokens: true, compactWhenNarrow: true, ignoredEventTypes: [tool_result, cache_read] } }配置项说明表配置项默认值作用windowMs5000滑动窗口长度单位毫秒refreshIntervalMs1000界面刷新节流间隔themedsh切换DSH样式或普通样式showAveragetrue是否显示平均速度showTotalTokenstrue是否显示累计token数compactWhenNarrowtrue窄终端时自动隐藏次要指标ignoredEventTypestool_result,cache_read忽略哪些事件类型的token计数5.2 踩坑一插件抢走了终端输入焦点这是我第一个遇到的比较严重的坑。插件每秒重绘一次状态头如果实现方式不当重绘时会把终端光标强制移回状态头区域导致用户正在输入命令的光标位置被重置到别处。我第一次跑起来的时候终端里打什么字都跑到插件状态头下面去整个OpenCode界面直接被“废”了。排查了半天根因是终端控制序列里的光标定位逻辑写错了每次重绘我都发了一个\e[H将光标移到左上角然后绘完状态头没有把光标恢复到原来的位置。修复的办法也很简单在重绘前记录当前光标位置。绘制完状态头后立刻用\e[u恢复光标位置。如果终端不支持保存/恢复光标位置干脆直接不重绘只等下一帧事件。从此以后插件界面就学会了“画完不打扰”再也没出现过光标被抢跑的问题。5.3 踩坑二tokenizer计数和我预期的数值对不上第二个坑是token统计口径的问题。事件流里的token_count字段理论上应该等于模型服务端返回的token数量。但有一次我对比日志发现插件统计的生成速度比模型提供商后台记录的高了大概10%到15%。找来找去最后定位到是OpenCode在事件流里把补全结束标记和部分后处理生成的文本也计入了输出token增量导致统计口径与服务端计费口径不完全一致。这件事给我的教训是如果你用这个插件做成本核算不能只看插件显示的总数更准确的做法是定期跟模型提供商后台的对账单做一个校准比例。我自己的做法是每隔50个会话把插件记录的token总量和后台账单统计对比一次计算出一个校准系数然后把这个系数写进插件配置里作为加权。虽然听起来很“笨”但它确实是目前最靠谱的对账方式。5.4 踩坑三缓存命中和多路并行导致双重计数第三个坑在微信群里被好几个同好问过就是插件显示的token速度突然飙到一个极高值比如每秒上千token。但实际上模型不可能生成那么快。排查下来一是缓存命中时服务端可能会一次性返回大量token摘要这本身不是生成而是缓存读取二是OpenCode支持多个模型请求并发执行插件如果不区分message_id把几个兄弟消息的增量都算到一个计数器里数值自然就炸了。我最终的修正方式是给速率计算器加一层“消息隔离”每个message_id维护独立的滑动窗口和独立的总数界面上显示的则是所有消息的合并值。只有并行度确实高、而每个消息的独立速率都在合理范围内时合并值变高才是正常的如果某个单独消息自身的速率异常高那基本就是缓存或事件重复推送的问题可以放心忽略。6. 实测数据与后续扩展方向文章写了这么多最后放一些我在真实使用中积累的实测数据和观察也顺便聊聊这套插件后续还能往哪些方向走。6.1 不同模型和不同场景下的实测表现以下是我在同一个网络环境、同一个OpenCode会话框架下用不同模型跑同一组代码生成任务时插件记录到的典型速度区间模型平均输出速度峰值速度体感反馈偏强推理类模型35-70 tokens/s120 tokens/s慢但稳定推理时停顿多偏生成类模型80-130 tokens/s220 tokens/s快但偶尔因散热降频本地小模型15-30 tokens/s45 tokens/s稳定但明显偏慢这几组数据让我明显感受到速度和“模型质量”不是一回事。推理类模型常常在一个token上耗时很长但最终答案的准确率明显更好生成类模型速度快但经常需要多轮返工。所以这个插件真正帮你做的事情不是“谁快谁厉害”而是让你心里有底知道这个模型正常速度大概是多少当它低于正常速度时你就能提前判断它是不是出问题了。6.2 边界条件与适用人群如果你正准备用这个插件我想提前泼几盆冷水免得期望值偏差。第一它不适用于非OpenCode环境。虽然事件流的设计思路可以迁移到其他AI编程工具但插件的具体配置和事件命名肯定不通用。如果有跨工具的需求建议先抽象出一层通用的“token递增事件”协议。第二CNN是瓶颈。插件的渲染放在本地终端如果你的OpenCode跑在远程服务器上SSH连接延迟高那么每秒一次的重绘也会占用一定的带宽。虽然实测在标准网速下完全没问题但在网络特别差的环境里建议把refreshIntervalMs调大到2000甚至3000毫秒。第三它不替你决策。插件只是把数据摆在你面前中断不中断、换不换模型最终还是要靠你自己的判断。我在用过一段时间后最大的收获是建立了“速度基线感”——知道自己的任务正常应该多少速从而能更自信地做决策。如果你希望有个插件直接帮你自动中断慢速任务那不是这个插件该干的活而且自动中断很容易误杀正常推理过程风险很大。6.3 后续可以扩展的方向我把这个插件开源出来以后陆续收到了一些反馈和建议其中三个方向我觉得特别有价值接入多provider的对账接口。现在插件只能显示token数据不能直接拉取账单如果后续能对接OpenCode使用的多个模型服务商的账单API就能做自动校准再也不用手动记录比例了。将速度变化与工具调用事件关联。很多“速度下降”恰好发生在工具调用前后如果能把这些事件也画进速度曲线的时间轴里用户就能一眼看出模型是“在思考”还是“在IO等待”这比单纯看token数字更有解释力。输出一份结构化的历史记录。保留每次会话的token速度采样点导出为JSON或SQLite数据库。这样你可以在任务结束后复盘整个会话的“心电图”找出哪些阶段浪费了最多时间。说回这套插件本身如果你也想在OpenCode里实时看到token生成速度并且喜欢DSH样式这种紧凑的仪表盘式状态头现在就可以去插件市场搜一下装起来试试。我最后想提醒你的是插件本身只是一个显示工具真正决定体验上限的是你拿这些数据做什么决策。我的建议是装上以后别急着用它来打断模型——先用两三天时间观察建立你常用模型的速度基线等你知道“正常”长什么样你才会在“异常”出现的那一秒做出最正确的判断。