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），仅供参考