abtop上下文窗口计算原理为什么cache_creation token会被重复计数以及如何避免【免费下载链接】abtopLike htop, but for AI coding agents. Monitor Claude Code Codex CLI sessions, tokens, context window, rate limits, and ports in real-time.项目地址: https://gitcode.com/gh_mirrors/ab/abtopabtop是一个面向 AI 编程智能体的实时监控系统就像经典系统监控工具 htop 之于 CPU 和内存——它让你在一块屏幕上同时查看所有 Claude Code、Codex CLI 与 OpenCode 会话的 token 消耗、上下文窗口占用百分比、速率限制和开放端口。在它的 context 面板 中上下文占用率只用input_tokens cache_read_input_tokens来计算刻意排除了 cache_creation。为什么这么做如果天真地把三种 token 相加会发生什么这篇指南带你彻底搞懂 abtop 上下文窗口的计算原理。先认识 abtopAI Agent 版的 htopabtop 全程只读本地文件与进程状态不需要 API 密钥也不需要登录。启动后你会看到每个会话一行状态模型版本、运行时长、上下文百分比、token 速率以及每个会话独立的上下文窗口进度条。要理解上下文计算原理先要知道 abtop 的数据来自哪里。对 Claude Code 而言每个会话都会把完整对话记录追加写入一个 JSONL 转录文件格式见 AGENTS.md。每条assistant消息里都带着一段usage统计字段含义input_tokens本轮未命中缓存、按全价重新发送的输入 tokenoutput_tokens本轮模型生成的输出 tokencache_read_input_tokens本轮命中提示缓存、直接读出的输入 tokencache_creation_input_tokens本轮新写入提示缓存的输入 token提示缓存prompt caching是 Anthropic 的计费与加速机制把冗长的系统提示、工具定义和历史对话缓存起来下一轮直接读取既快又省钱。上面四个字段就是 abtop 计算上下文的全部原料。abtop 上下文窗口占用的计算公式abtop 的核心规则只有一句话上下文 最近一条 assistant 消息的 input_tokens cache_read_input_tokens。对应的源码在 src/collector/claude.rs// Context input_tokens cache_read (excludes cache_creation, #54) let current_context if cr 0 cc 0 { inp cc } else { inp cr }; result.last_context_tokens current_context;得到last_context_tokens后再除以该模型的上下文窗口上限就得到面板上那根百分比进度条窗口上限由 context_window_for_model() 决定默认200K当模型名带[1m]标记或实测上下文已超过 200K 时自动切换为1Mcontext_percent last_context_tokens / context_window × 100超过 75% 会显示!、超过 90% 显示⚠警告渲染逻辑在 src/ui/context.rs。为什么 cache_creation 会被重复计数这是整篇文章的关键问题。先看一个正常轮次的 token 分布input_tokens 2 ← 少量新增内容 cache_read_input_tokens 11313 ← 大部分历史走缓存命中 cache_creation_input_tokens 4350 ← 本轮新内容写入缓存直觉上上下文总大小似乎应该是三者之和。但项目维护文档 AGENTS.md 明确指出在compaction上下文压缩轮次中同一批 token 会同时被报告为cache_creation和cache_read——旧缓存被作废旧重写写入了新的缓存条目同时新前缀又被命中。三项相加这批 token 就被计了两次。这正是 abtop 历史上 issue #54 的根源如果简单相加一次压缩之后上下文占用率会瞬间虚高甚至突破窗口上限你会误以为会话要爆了其实真实占用根本没变。所以 abtop 选择只信input cache_read这个口径——它也与 Claude Code 自带的 statusline 显示保持一致参考 scripts/abtop-statusline.sh。特例新会话为什么又要加 cache_creation如果永远排除 cache_creation会漏掉另一种场景。会话刚开始时还没有任何缓存可命中第一条 assistant 消息的报告通常是cache_read 0而cache_creation很大整个初始提示正在被写入缓存。此时真正代表当前上下文大小的就是input_tokens cache_creation_input_tokens若仍按input cache_read算会读出接近 0% 的假象。所以源码里那个if就是干这个的当cache_read 0且cache_creation 0时改用input cache_creation相关测试见 test_parse_transcript_fresh_session_uses_cache_creation_for_context。一句话总结这套口径场景缓存状态上下文取法常规轮次有缓存命中input cache_read压缩轮次同一批 token 双份上报input cache_read不能加 cache_creation新会话首轮无缓存、正在写缓存input cache_creation如何避免重复计数4 条实用建议✅自己写状态行/监控时坚持input cache_read口径。这是与 Claude Code 官方 statusline 对齐的做法天然免疫压缩轮次的双份上报。✅用断崖式下跌识别 compaction而不是绝对值。abtop 的判断条件是上下文相比上一轮骤降超过 30%且cache_read相比上轮跌至原来的 1/5 以下旧缓存被整体作废。单看某一项波动都可能误报两个条件同时成立才算一次真正的压缩检测逻辑在 src/collector/claude.rs。压缩次数会显示在上下文栏的C2这类标记里。✅区分缓存命中波动和真实上下文变化。普通对话中缓存命中率自然起伏总上下文量会有正常抖动只要没有断崖式下跌就不该当作窗口将满的信号。✅留意窗口上限会动态变化。同一模型在[1m]配置下上限是 1M 而非 200K固定写死 200K 会在新会话里算出虚高的百分比。abtop 的做法是同时参考转录中的模型名与实测最大值自动选择上限。小结abtop 的上下文占用 input_tokens cache_read_input_tokens÷ 模型窗口上限cache_creation 默认不计入重复计数发生在 compaction 轮次同一批 token 被同时报成cache_creation与cache_read三项相加即虚高#54唯一例外是新会话首轮cache_read 0的场景此时cache_creation才代表真实上下文大小记住两项之和 一个例外你就能在任何 AI Agent 监控工具里算出不会骗人的上下文窗口占用。【免费下载链接】abtopLike htop, but for AI coding agents. Monitor Claude Code Codex CLI sessions, tokens, context window, rate limits, and ports in real-time.项目地址: https://gitcode.com/gh_mirrors/ab/abtop创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
企业数字化 ERP 产品动态
相关推荐
租电脑踩过的坑和选对商家后省下的钱，聊聊我的真实经历 去年接了个视频剪辑的私活，甲方要求4K素材AE特效，我那台用了四年的笔记本直接罢工，导出一个三分钟的视频要等四十分钟。买一台能跑动的新机器？看了看价格，一万二起步。但这个项目做完下一单什么时候来还不知道… · 2026/9/27 4:35:06
硬件架构系统学习指南：从数字电路到微架构的完整路径 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/9/27 4:34:54
做soho怎么建立网站：3步搞定域名服务器与性能优化 做soho怎么建立网站：3步搞定域名服务器与性能优化 做SOHO建站，最让人头疼的不是设计，而是 域名服务器搞不懂 ，以及网站上线后打开像蜗牛一样慢。很多新手刚起步，预算有限，却容易被各种技术名词绕晕，导致网站不仅没带来流量，反而因为… · 2026/9/27 4:34:54
Storm 序列化优化：自定义 Serializer、Kryo 注册与零拷贝 Storm 序列化优化：自定义 Serializer、Kryo 注册与零拷贝1. Storm 序列化瓶颈分析Storm 作为实时计算框架，序列化性能直接影响整个应用的吞吐量和延迟。默认的 Java 序列化机制存在以下问题：反射机制导致性能开销未注册类型导致序列化失败内存… · 2026/9/27 5:13:37
建站避坑指南：一文搞懂cms的功能有哪些及选型全解 建站避坑指南：一文搞懂cms的功能有哪些及选型全解 找建站公司怕被坑高价，这是很多老板和设计师的噩梦。报价单上写满“智能系统”、“无限扩展”，交钱后才发现只是个套壳模板，改个颜色都要加钱。今天不玩虚的，咱们直接拆底裤， 一文搞懂… · 2026/9/27 5:13:13
无人机声音识别系统：MFCC+CNN 特征工程与模型实战 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/9/27 5:13:06
10年老兵揭秘：关键词seo排名优化如何不花冤枉钱，源码下载后避坑指南 10年老兵揭秘：关键词seo排名优化如何不花冤枉钱，源码下载后避坑指南 找建站公司最怕什么？不是技术差，而是被高价坑。很多老板为了省事，几万块扔出去，网站建完排名还是零，想改个标题还得求着服务商。这时候你才会意识到，手里没攥着 源码下载… · 2026/9/27 5:13:06
wordpress制作小说网站模板下载免费工具推荐与避坑注意事项 wordpress制作小说网站模板下载免费工具推荐与避坑注意事项 改个需求建站公司拖一周，这种憋屈事儿谁没遇见过？很多河南的老铁在郑州、洛阳搞网文推广或者个人创作，想自己弄个小说站，找外包报价几千块，改个按钮颜色还得等三天。其实真不用这么被… · 2026/9/27 5:13:00
签对公司网站建设合同书，实战案例教你拒收拖延 签对公司网站建设合同书，实战案例教你拒收拖延 上周刚帮一个客户从烂尾的建站项目里“抢”回数据，起因简单得让人想笑：对方改个需求，拖了一周还没动静，邮件石沉大海，电话不接。很多老板以为签了 公司网站建设合同书… · 2026/9/27 5:12:54
MATLAB雷达信号脉冲压缩仿真：LFM线性调频、匹配滤波与距离分辨率实现 简介：这套Matlab仿真工具完整呈现雷达信号脉冲压缩过程，从线性调频（LFM）信号生成、目标回波仿真到匹配滤波压缩处理均有可运行代码支撑，面向电子信息工程、计算机、数学等专业学生，适用于课程设计、期末大作… · 2026/9/27 0:00:01
汕头网站建设制作厂家避坑指南：5大注意事项救急 汕头网站建设制作厂家避坑指南：5大注意事项救急 改个需求建站公司拖一周，这种憋屈事我见得太多了。 很多汕头老板找本地建站团队，签合同前看着方案挺美，一上线就变脸。 今天不聊虚的，直接拆解找 汕头网站建设制作厂家 时的5个核心 注意事项… · 2026/9/27 0:00:01
多模态虚假新闻检测实战：BERT+ResNet双塔与对比学习 简介：基于PyTorch的多模态虚假新闻检测项目完整代码包，面向自然语言处理与计算机视觉交叉方向的开发者、科研人员及毕业设计选题者，解决社交媒体中文本与图像联合识别虚假新闻的问题。系统以BERT预训练模型提取文本语义特征，以Res… · 2026/9/27 0:00:01
MATLAB雷达信号脉冲压缩仿真：LFM线性调频、匹配滤波与距离分辨率实现 简介：这套Matlab仿真工具完整呈现雷达信号脉冲压缩过程，从线性调频（LFM）信号生成、目标回波仿真到匹配滤波压缩处理均有可运行代码支撑，面向电子信息工程、计算机、数学等专业学生，适用于课程设计、期末大作… · 2026/9/27 0:00:01
汕头网站建设制作厂家避坑指南：5大注意事项救急 汕头网站建设制作厂家避坑指南：5大注意事项救急 改个需求建站公司拖一周，这种憋屈事我见得太多了。 很多汕头老板找本地建站团队，签合同前看着方案挺美，一上线就变脸。 今天不聊虚的，直接拆解找 汕头网站建设制作厂家 时的5个核心 注意事项… · 2026/9/27 0:00:01
多模态虚假新闻检测实战：BERT+ResNet双塔与对比学习 简介：基于PyTorch的多模态虚假新闻检测项目完整代码包，面向自然语言处理与计算机视觉交叉方向的开发者、科研人员及毕业设计选题者，解决社交媒体中文本与图像联合识别虚假新闻的问题。系统以BERT预训练模型提取文本语义特征，以Res… · 2026/9/27 0:00:01
