OpenRig 上下文用量监控context-usage 采集与速率限制数据流完整指南【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址: https://gitcode.com/GitHub_Trending/op/openrigOpenRig 是一款把 Claude Code、Codex 等 AI 编码代理组织成持久化团队的开源工具而它最容易被忽略的能力之一就是上下文用量监控系统会持续采集每个代理席位的 context-usage上下文窗口占用、记录速率限制rate limit数据并在用量逼近上限时自动预警。本文用一张数据流图讲清楚这 4 个环节如何协作。为什么你的代理团队需要上下文用量监控大模型代理的工作记忆是有限度的上下文窗口。窗口一旦被填满代理会开始遗忘早期任务要求、压缩历史、甚至输出质量骤降。如果你同时跑着几个代理席位人工盯着每个终端的 token 数字几乎不现实。OpenRig 的做法是把每个席位的上下文占用变成一份可查询、可告警、可自动处置的数据。下面是官方演示动画中 TUI 的席位表——注意其中的ctx列就是本文主角的实时读数数据流全景采集 → 存储 → 轮询 → 决策整条链路只有 4 站理解了这张表就理解了全部机制阶段角色关键文件① 采集各运行时的传感器claude-statusline-context.cjs② 存储SQLitecontext_usage表context-usage-store.ts③ 轮询每 30 秒的上下文监视器context-monitor.ts④ 决策阈值策略、看门狗、自动压缩context-usage-threshold.ts下面逐站拆解。站点一采集——Claude 与 Codex 各有一套传感器Claude Codestatus line 收集器OpenRig 启动 Claude 席位时会往工作区写入一个 statusLine 钩子脚本 claude-statusline-context.cjs。每次 Claude 刷新状态栏脚本就从标准输入读到一份 JSON提取context_window字段窗口大小、已用百分比、输入/输出 token 数等原子写入一个按会话命名的 sidecar JSON 文件路径约定在 telemetry-state-paths.ts 中定义~/.openrig/state/context-usage/会话名.json # 上下文用量 ~/.openrig/state/provider-usage/会话名.json # 速率限制注意第二份文件——Claude 状态栏里的rate_limits订阅五小时/每周用量窗口会被同步剥离出来这就是速率限制数据的入口。Codex直接读线程日志Codex 没有状态栏钩子采集策略不同ContextUsageStore 会打开 Codex 的本地线程数据库拿到线程的 rollout 日志路径再从日志尾部 4MB 里倒序找最近一条token_count事件用total_tokens / model_context_window换算出占用百分比。两种来源最终归一化为同一种结构下游无需关心席位用的是哪家运行时。站点二存储——三层防脏数据守卫采集到的样本由 context-usage-store.ts 按节点 upsert 进 SQLite 的context_usage表表结构定义在 context-usage-store.ts#L44-L60。这张表只保留每个节点的最新读数是时间点快照。为防止旧数据误导决策读取时有三道守卫新鲜度守卫采样超过 10 分钟FRESHNESS_THRESHOLD_MS 600_000即视为过期界面会标注而非直接引用会话不匹配守卫表里记录属于另一个会话名时返回session_mismatch避免跨会话继承旧读数代际守卫席位换人handover时若新占位者启动前采样读数会被标记stale_generation拒用——这是专门修复老代理的 88% 占用残影的机制。站点三轮询——ContextMonitor 的 30 秒心跳ContextMonitor 是这条数据流的调度器默认每 30 秒跑一轮见 context-monitor.ts#L12-L13。每轮做三件事拉取与持久化先查出所有可读取上下文的在跑会话Claude/stub 直接可读Codex 需要已有线程 token读取并 upsert 到context_usage追加时序样本把本次读数送入 UsageSamplesStore。这是一张只进不改advance-only的usage_samples表——只有比上一条前进了的样本才落盘空闲席位一条都不写所以序列长度天然等于真实变化次数触发自动压缩把最新读数交给 compaction enforcer策略命中时自动发/compact且保证策略看到的数和你在 UI 看到的数是同一个观测值。任何单席位的读取失败都被隔离不会拖垮整轮轮询——这是刻意的故障隔离设计。站点四速率限制数据流与阈值告警provider-usage订阅窗口的第二条数据轨速率限制数据与上下文占用走平行的两条轨道入口状态栏收集器把 Claude 的rate_limits写入~/.openrig/state/provider-usage/落库UsageSamplesStore 的provider_window车道按five_hour/weekly两种窗口记录已用百分比 重置时间同样是 advance-only 语义消费健康投影与告警层读取这些窗口数据判断你的订阅额度还剩多少、何时重置而不是只看上下文窗口。看门狗策略超限即送达真正动手的是看门狗。context-usage-threshold.ts 定义的策略逻辑很朴素当会话转录文件字节数越过配置阈值thresholdBytes向目标席位发送一条上下文用量已超阈值的提醒消息。细节上做了很多防误报处理——同一占位者代际内只触发一次threshold_already_fired、转录未就绪时跳过、阈值无效时终止任务。你可以用rig watchdog命令查看所有任务的状态watchdog.ts健康汇总层health-projection.ts也会把上下文占用纳入整体体检。在界面上看到这些数据启动 TUI 是最直观的验证方式席位表的ctx列即实时上下文占用点开单个席位还能看到 token 明细与来源。快速上手路径参考 demo/README.md首屏效果如下命令行侧则有三个常用入口rig ps --nodes查看节点列表含上下文占用列ps.tsrig watchdog查看阈值任务与触发历史TUI 席位详情查看 token 输入/输出、窗口大小与采样新鲜度。小结一条链路四种价值你想知道的数据来自哪这个席位的上下文用了多少context_usage表30 秒刷新它是怎么涨上去的usage_samples的 context 车道我的订阅额度还能撑多久usage_samples的 provider_window 车道超限时谁来提醒我看门狗的 context-usage-threshold 策略OpenRig 的上下文用量监控没有魔法把两种运行时的原始信号归一化、用三层守卫保证读数可信、用 advance-only 时序保证历史诚实、最后交给策略引擎做决策。理解了这条数据流你就能在代理团队跑长任务时从容地知道谁快忘了、谁快没额度了。延伸阅读context-monitor.test.ts、context-usage-store.test.ts、context-usage-watchdog.test.ts。【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址: https://gitcode.com/GitHub_Trending/op/openrig创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenRig 上下文用量监控：context-usage 采集与速率限制数据流完整指南
OpenRig 上下文用量监控context-usage 采集与速率限制数据流完整指南【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址: https://gitcode.com/GitHub_Trending/op/openrigOpenRig 是一款把 Claude Code、Codex 等 AI 编码代理组织成持久化团队的开源工具而它最容易被忽略的能力之一就是上下文用量监控系统会持续采集每个代理席位的 context-usage上下文窗口占用、记录速率限制rate limit数据并在用量逼近上限时自动预警。本文用一张数据流图讲清楚这 4 个环节如何协作。为什么你的代理团队需要上下文用量监控大模型代理的工作记忆是有限度的上下文窗口。窗口一旦被填满代理会开始遗忘早期任务要求、压缩历史、甚至输出质量骤降。如果你同时跑着几个代理席位人工盯着每个终端的 token 数字几乎不现实。OpenRig 的做法是把每个席位的上下文占用变成一份可查询、可告警、可自动处置的数据。下面是官方演示动画中 TUI 的席位表——注意其中的ctx列就是本文主角的实时读数数据流全景采集 → 存储 → 轮询 → 决策整条链路只有 4 站理解了这张表就理解了全部机制阶段角色关键文件① 采集各运行时的传感器claude-statusline-context.cjs② 存储SQLitecontext_usage表context-usage-store.ts③ 轮询每 30 秒的上下文监视器context-monitor.ts④ 决策阈值策略、看门狗、自动压缩context-usage-threshold.ts下面逐站拆解。站点一采集——Claude 与 Codex 各有一套传感器Claude Codestatus line 收集器OpenRig 启动 Claude 席位时会往工作区写入一个 statusLine 钩子脚本 claude-statusline-context.cjs。每次 Claude 刷新状态栏脚本就从标准输入读到一份 JSON提取context_window字段窗口大小、已用百分比、输入/输出 token 数等原子写入一个按会话命名的 sidecar JSON 文件路径约定在 telemetry-state-paths.ts 中定义~/.openrig/state/context-usage/会话名.json # 上下文用量 ~/.openrig/state/provider-usage/会话名.json # 速率限制注意第二份文件——Claude 状态栏里的rate_limits订阅五小时/每周用量窗口会被同步剥离出来这就是速率限制数据的入口。Codex直接读线程日志Codex 没有状态栏钩子采集策略不同ContextUsageStore 会打开 Codex 的本地线程数据库拿到线程的 rollout 日志路径再从日志尾部 4MB 里倒序找最近一条token_count事件用total_tokens / model_context_window换算出占用百分比。两种来源最终归一化为同一种结构下游无需关心席位用的是哪家运行时。站点二存储——三层防脏数据守卫采集到的样本由 context-usage-store.ts 按节点 upsert 进 SQLite 的context_usage表表结构定义在 context-usage-store.ts#L44-L60。这张表只保留每个节点的最新读数是时间点快照。为防止旧数据误导决策读取时有三道守卫新鲜度守卫采样超过 10 分钟FRESHNESS_THRESHOLD_MS 600_000即视为过期界面会标注而非直接引用会话不匹配守卫表里记录属于另一个会话名时返回session_mismatch避免跨会话继承旧读数代际守卫席位换人handover时若新占位者启动前采样读数会被标记stale_generation拒用——这是专门修复老代理的 88% 占用残影的机制。站点三轮询——ContextMonitor 的 30 秒心跳ContextMonitor 是这条数据流的调度器默认每 30 秒跑一轮见 context-monitor.ts#L12-L13。每轮做三件事拉取与持久化先查出所有可读取上下文的在跑会话Claude/stub 直接可读Codex 需要已有线程 token读取并 upsert 到context_usage追加时序样本把本次读数送入 UsageSamplesStore。这是一张只进不改advance-only的usage_samples表——只有比上一条前进了的样本才落盘空闲席位一条都不写所以序列长度天然等于真实变化次数触发自动压缩把最新读数交给 compaction enforcer策略命中时自动发/compact且保证策略看到的数和你在 UI 看到的数是同一个观测值。任何单席位的读取失败都被隔离不会拖垮整轮轮询——这是刻意的故障隔离设计。站点四速率限制数据流与阈值告警provider-usage订阅窗口的第二条数据轨速率限制数据与上下文占用走平行的两条轨道入口状态栏收集器把 Claude 的rate_limits写入~/.openrig/state/provider-usage/落库UsageSamplesStore 的provider_window车道按five_hour/weekly两种窗口记录已用百分比 重置时间同样是 advance-only 语义消费健康投影与告警层读取这些窗口数据判断你的订阅额度还剩多少、何时重置而不是只看上下文窗口。看门狗策略超限即送达真正动手的是看门狗。context-usage-threshold.ts 定义的策略逻辑很朴素当会话转录文件字节数越过配置阈值thresholdBytes向目标席位发送一条上下文用量已超阈值的提醒消息。细节上做了很多防误报处理——同一占位者代际内只触发一次threshold_already_fired、转录未就绪时跳过、阈值无效时终止任务。你可以用rig watchdog命令查看所有任务的状态watchdog.ts健康汇总层health-projection.ts也会把上下文占用纳入整体体检。在界面上看到这些数据启动 TUI 是最直观的验证方式席位表的ctx列即实时上下文占用点开单个席位还能看到 token 明细与来源。快速上手路径参考 demo/README.md首屏效果如下命令行侧则有三个常用入口rig ps --nodes查看节点列表含上下文占用列ps.tsrig watchdog查看阈值任务与触发历史TUI 席位详情查看 token 输入/输出、窗口大小与采样新鲜度。小结一条链路四种价值你想知道的数据来自哪这个席位的上下文用了多少context_usage表30 秒刷新它是怎么涨上去的usage_samples的 context 车道我的订阅额度还能撑多久usage_samples的 provider_window 车道超限时谁来提醒我看门狗的 context-usage-threshold 策略OpenRig 的上下文用量监控没有魔法把两种运行时的原始信号归一化、用三层守卫保证读数可信、用 advance-only 时序保证历史诚实、最后交给策略引擎做决策。理解了这条数据流你就能在代理团队跑长任务时从容地知道谁快忘了、谁快没额度了。延伸阅读context-monitor.test.ts、context-usage-store.test.ts、context-usage-watchdog.test.ts。【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址: https://gitcode.com/GitHub_Trending/op/openrig创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考