PostHog ReviewHog 提示缓存成本计量实战从 gate0 运行看 LLM 代码审查管线的真实成本核算【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog本文基于 PostHog 开源仓库中 ReviewHog 的缓存计量实验运行记录gate0-run1-pr68749-publish.md完整讲解如何在多沙箱、多视角的 LLM 代码审查管线中建立缓存感知cache-aware的成本计量体系区分 fresh / cache-write / cache-read / output 四个计费桶用真实运行数据验证「朴素 token 计数高估真实成本约 4.8 倍」这一关键结论并还原跨沙箱缓存共享的检测方法turn-1 cache read 分布。读完本文你将掌握一套可复制的 LLM 成本归因方法论、Anthropic 提示缓存的计费细节以及如何用「precision-over-recall」原则对 LLM 审查发现的候选问题做验证与取舍。背景为什么 ReviewHog 需要缓存感知的成本计量ReviewHog 是 PostHog 仓库中的自动化 GitHub PR 代码审查器Django 应用位于 products/review_hog。它的审查流程是拉取 PR → 分块chunking→ 为每个 chunk 并行运行多个审查视角Logic Correctness、Contracts Security、Performance Reliability 等→ 盲点扫描blind-spot→ 去重 → 验证 → 生成并发布审查报告。核心痛点在于每一个审查单元每个视角 × 每个 chunk、盲点扫描、验证都是一个全新的沙箱会话——新的 Task → 新的 Modal/Docker 沙箱 → 新的 agent-server → 新的 Claude Code 对话。每个单元都在重复学习同一个 PR 的相同代码上下文。这正是 INVESTIGATION.md 中描述的问题ReviewHogs review units each re-learn the same PR: every unit (N perspectives blind-spot per chunk, validation) is a fresh Task → fresh Modal/Docker sandbox → fresh agent-server → fresh Claude Code conversation.如果这些沙箱会话共享 Anthropic 的提示缓存prompt caching那么重复的上下文读取可以按 0.1× 的缓存读价格计费。但前提是你能够准确度量这些成本。2026 年 7 月PostHog 团队发起了 prompt-caching 实验项目PLAN.md其 Gate 0 的首要交付物就是让每一次未来的成本门禁都可计算、可诚实核算。本文剖析的gate0-run1-pr68749-publish.md就是这个 Gate 0 在真实 PR#68749上的验证运行。运行概况gate0-run1-pr68749-publish本次运行是一次真实的 Reviewer-quality 运行覆盖实时 PR #68749其结果文档记录在 runs/gate0-run1-pr68749-publish.md字段值转储时间2026-07-06T20:48:4500:00Report id019f3911-7629-7348-8448-d1aae91644c5· PR #68749Headb4764b4a9a6f355ed1f230f15ebfd43e3a5c5133· run_count: 1 · status: idleWall-clock1880s约 31.3 分钟运行时/模型/推理力度claude/claude-sonnet-5/xhigh单块门限/块目标/软上限400 / 300 / 600可审查行数这里的「single-chunk gate 400」是分块策略的关键参数当 PR 的可审查新增行数 ≤ 400 时直接作为单个 chunk 处理不调用分块 LLM超过 400 但 ≤ 5000 时使用一次性one-shotLLM 分块再往上则退回沙箱分块参见 ARCHITECTURE.md 的 Preflight 说明。本次运行的审查漏斗funnel为chunksreview unitsraw issuesafter deduppassed validator14884其中review units的定义很关键它等于实际运行的每个 (perspective | blind-spot × chunk) 沙箱审查数即「模型持有不变的」成本代理指标——用单元数而不是 token 数来横向比较不同配置下的成本。本次运行共 4 个单元3 个视角contracts-security、logic-correctness、performance-reliability 1 个盲点扫描blind-spots-general全部作用在 chunk 1 上。缓存感知的成本拆解四个计费桶传统做法是把$ai_input_tokens和$ai_output_tokens简单加总按输入单价估算但 Anthropic 提示缓存使输入侧存在三种截然不同的价格fresh全新输入1× 输入价cache write缓存写入1.25× 输入价5 分钟 TTL 档1 小时 TTL 档为 2×cache read缓存读取0.1× 输入价output输出独立的输出单价dump_result.pyeval/scripts/dump_result.py就是这个计量工具的载体。它以manage.py shell方式运行从本地 ClickHouse 的$ai_generation事件查询数据按 (model × stage) 维度拆出上述四个桶并维护一张镜像 LiteLLM 成本表的价目表# List prices per token, mirroring LiteLLMs cost map (the source of the gateways # $ai_total_cost_usd) as of 2026-07-06: (fresh_input, output, cache_read, cache_write). # The write rate here is the 5-minute-TTL one (1.25× input); 1h-TTL writes bill at 2× input # and the events dont carry the 5m/1h split, so true_usd prices all writes at 1.25× and the # gateways $ai_cache_creation_cost_usd (when emitted) is the accurate write-side cost. _LIST_PRICES: dict[str, tuple[float, float, float, float]] { claude-sonnet-5: (2e-06, 1e-05, 2e-07, 2.5e-06), claude-opus-4-8: (5e-06, 2.5e-05, 5e-07, 6.25e-06), claude-fable-5: (1e-05, 5e-05, 1e-06, 1.25e-05), claude-haiku-4-5: (1e-06, 5e-06, 1e-07, 1.25e-06), ... }即 sonnet-5 为 $2/M 输入、$10/M 输出、$0.2/M 缓存读、$2.5/M 缓存写5m TTLopus-4-8 为 $5/M 输入、$25/M 输出、$0.5/M 缓存读、$6.25/M 缓存写。本次运行的实测成本表modelstagegensfresh incache writecache readoutput200K genstrue $gw $claude-sonnet-5review82119,275606,0519,845,46472,9020$4.45$4.45claude-opus-4-8validation3131,232216,6883,225,15637,1950$4.05$4.05claude-sonnet-5blind-spot2735,868151,8543,349,69522,0070$1.34$1.34claude-sonnet-5dedup16,804004,2880$0.06$0.06claude-haiku-4-5-20251001other14710060$0.00$0.00total142193,650974,59316,420,315136,3980$9.90$9.90读这张表有三个要点缓存读是最大的真实成本桶。16.42M 的缓存读 token 远超 193K 的 fresh token但因其 0.1× 单价占比最大的反而是写入974K × 1.25× $2.44 左右。整个运行的桶拆分约为43% 缓存读 / 33% 缓存写 / 19% 输出 / 5% fresh——缓存读虽然是 token 量最大的桶但真正的成本大头在缓存写与输出。验证阶段validation使用更强的模型claude-opus-4-8与审查阶段的claude-sonnet-5分开计费。这也反映了 ReviewHog 的架构设计审查单元wave blind-spot与验证单元使用不同的模型族详见 ARCHITECTURE.md 的模型选择说明。true $按目录价反算fresh 1× cache write 1.25× cache read 0.1× output与gw $网关记录的$ai_total_cost_usd来自 LiteLLM完全一致Δ 0.0%。朴素计费法为什么不能用运行记录给出了一个震撼的对比naive method (all prompt tokens at input price): $47.52 — 4.8× the true cost; never gate on it.如果把全部输入 tokenfresh write read都按 $2/M 输入价计算会得到 $47.52而真实成本只有 $9.90——朴素方法高估了 4.8 倍。这直接催生了项目的一个铁律见 CANDIDATES.md 的 Measured facts绝不能用未区分的$ai_input_tokens来给任何决策设门禁。任何基于 token 数做成本优化决策例如「这个优化省了多少 token」都必须换成缓存感知的 $ 计量。计量工具的验证逐桶逐侧对账到 Δ 0.0%好工具必须经过验证。dump_result.py增加了一项「每侧交叉核对」per-side cross-check只统计确实产出了对应字段的 genLiteLLM 的input_cost字段是整个输入侧的总和缓存包含在内侧金额142 gen说明输入侧合计fresh write read$7.9812与 true $7.9812 完全一致其中 cache read$4.2516134 gentrue $4.2516Δ 0.0%其中 cache write$3.2491140 gentrue $3.2491Δ 0.0%其中 fresh派生$0.4805142 gentrue $0.4805Δ 0.0%输出$1.9219142 gentrue $1.9219Δ 0.0%这次验证同时终结了一个历史悬案此前的探针曾发现 sonnet-5 的网关成本比目录价反算高出约 28%。PLAN.md 的运行日志明确指出这是一个测量伪影——LiteLLM 的input_cost字段是「整个输入侧」含缓存的价格而目录价反算时却只把输入按 fresh 价计。修正后本次运行的每个桶、每个侧都做到了 Δ 0.0% 的完美对账PLAN.md 运行日志dump_result.pyemits the cache-aware split,true_usd/gw_usd, per-side cost cross-checks ... it matched the gateways LiteLLM costs atΔ 0.0% on every bucket and side跨沙箱缓存共享的探针turn-1 cache read 分布缓存计量的另一个关键用途是检测跨沙箱缓存共享cross-sandbox cache sharing。原理是一个全新的沙箱在 turn 1该task_run_id的第一条$ai_generation就产生cache_read 0只可能来自另一个进程之前写入的缓存——这就是跨沙箱共享信号的「触发器」tripwire。本次运行的 per-unit turn-1 数据unitstagefirst gent1 cache readt1 cache write…e23f6862review20:15:18073,218…5dbd75a0review20:15:1927,61845,603…45201835review20:15:3727,61845,602…ce6cdd06blind-spot20:27:59076,265…423f769bvalidation20:34:34038,613units with turn-1 cache_read 0: 2/5。两个 review 单元在 1s 和 19s 内读取了领导者写入的完全相同的 27,618 token 段——这是 [tools 系统预设块] 前缀因自然供给抖动provisioning jitter使第二个单元成为事实上的领导者leader。运行记录的解读强调Report the distribution, not a median.因为本次运行中 2/5 单元命中了 27,618 token 的 turn-1 读而另外 3 个单元为 0——中位数0会完全掩盖共享已经发生的事实。这正是 HARNESS.md 中「turn-1 cache reads per sandbox unit」查询的设计初衷报告分布units_with_turn1_hit 每单元数值绝不只报中位数。HARNESS.md 还给出了完整的探测 SQL对$ai_generation按task_run_id分组取每个单元时间最早的 gen 的缓存读/写 tokenWITH unit_turn1 AS ( SELECT JSONExtractString(properties, task_run_id) AS task_run_id, extract(any(JSONExtractString(properties, task_title)), \\[sandbox_prompt:([a-z0-9_-])\\]) AS step_name, count() AS gens, argMin(toFloat64OrZero(JSONExtractString(properties, $ai_cache_read_input_tokens)), timestamp) AS turn1_cache_read, argMin(toFloat64OrZero(JSONExtractString(properties, $ai_cache_creation_input_tokens)), timestamp) AS turn1_cache_creation FROM events WHERE event $ai_generation AND timestamp %(run_start)s AND timestamp %(run_end)s AND (JSONExtractString(properties, task_title) LIKE [sandbox_prompt:issues-review-% OR JSONExtractString(properties, task_title) LIKE [sandbox_prompt:blind-spots-%) AND JSONExtractString(properties, task_run_id) ! GROUP BY task_run_id ) SELECT multiIf(step_name LIKE blind-spots%, blind-spot, perspective) AS unit_kind, count() AS units, medianExact(turn1_cache_read) AS turn1_cache_read_median, countIf(turn1_cache_read 0) AS units_with_turn1_hit, medianExact(turn1_cache_creation) AS turn1_cache_creation_median FROM unit_turn1 GROUP BY unit_kind WITH TOTALS ORDER BY unit_kind两个重要的时间信号从上面的 turn-1 表还能读出两个关键时间信号盲点扫描blind-spot在 wave 之后 12 分 32 秒才启动20:15:37 最后一个 wave gen → 20:27:59 盲点首个 gen。由于沙箱路径默认是5 分钟滑动 TTL这个间隔远超 TTL导致盲点单元完整重写前缀76,265 token 写入、0 命中。HARNESS.md 把这类事件定性为「TTL busts are real」并给出工程对策扇出fan-out调度必须立即进行、重叠供给沙箱fresh sandbox setup 本身就要 ~4-6 分钟或用ENABLE_PROMPT_CACHING_1H1对特定单元强制 1 小时 TTL写入价从 1.25× 升到 2×需选择性启用。验证单元validation使用完全新鲜的会话——这是刻意设计validators keep fresh sessions参见 INVESTIGATION.md 的 Precedents and risks验证器永远不从前序审查或预热会话播种。审查发现与验证器裁决8 进 4 出的取舍逻辑成本之外本次运行也是一次完整的审查质量样本3 个视角 1 个盲点共产出 8 条原始发现去重后仍为 8 条最终 4 条通过验证器。passchunkperspectiveraw issues11review-hog-perspective-contracts-security121review-hog-perspective-logic-correctness331review-hog-perspective-performance-reliability210001review-hog-blind-spots-general2从源码结构看pass 序号对应 PERSPECTIVES 注册表 中视角的 1-based 位置盲点扫描使用保留的 pass 号1000参见 ARCHITECTURE.md 的 pipeline 描述。4 条通过验证的发现涉及AccountRelationshipViewSet的 OpenAPI 标注缺失contracts-security、关系侧边栏无法区分「无数据」与「加载失败」logic-correctness、多持有者关系未按定义分组渲染logic-correctness、关系历史端点无服务端分页performance-reliability——后三条都被验证器从 should_fix 降级为 consider仅保留记录。4 条被驳回dismissed的发现则清晰展示了验证器的裁决标准发现类型驳回理由验证器摘要History tab 行序不呈时间线best_practicelogic-correctness 视角展示/品味问题非正确性缺陷后端按definition__name, -started_at排序是合理且可能刻意的布局用户界面文案并未承诺严格时间序Relationships tab 每次展开增加第 6 个 eager 网络请求performance推测性未来规模担忧请求实际上是必需的——常驻侧边栏 ActiveRelationships 依赖同一逻辑的数据建议的「推迟到侧边栏需要时」自相矛盾新 Serializer 重复了既有内联 schemacode_quality盲点视角重复是刻意的注释明示「使生成的 AccountApiProperties 组件保持不变」两个概念语义上独立属 DRY/过度工程范畴ActiveRelationships 无加载态best_practice盲点视角纯加载体验打磨数据正确、无行为差异且 naive 骨架屏对空态账号反而更差这些裁决背后的原则在 ARCHITECTURE.md 的 validation 一节有明确表述默认保留标准是「真实影响用户的正确定性/安全/数据丢失/契约/性能问题丢弃过度工程、推测、防御性偏执、永不发生的边界和风格问题」——precision over recall宁缺毋滥。验证器的评判风格第 75 行等也很有代表性逐条核对前提去源码验证排序逻辑、验证is_single_holder模型字段与测试test_multi_holder_allows_concurrent_assignees、确认前端渲染路径再对严重性做封顶判断。方法论沉淀从一次运行到成本优化的长期实验gate0-run1-pr68749-publish.md不是孤立的运行报告它是整个 prompt-caching 实验项目的 Gate 0 验证锚点。PLAN.md 记录了这次运行的三重意义计量工具正式交付dump_result.py的扩展随本次运行上线并被实测验证Δ 0.0%成为后续所有实验的标准成本仪表。28% 差异悬案结案确认是测量伪影而非真实计费差异。后续实验的基线本次运行的桶拆分43%/33%/19%/5%与 turn-1 命中分布2/5被写入 CANDIDATES.md 的 Measured facts成为评估「warm-up fork」旗舰方案#8的对照依据——即每 chunk 一个中性预热智能体先读取并理解 chunk其会话转录持久化后所有视角从其缓存前缀 fork从而继承 0.1× 的缓存读。从 INVESTIGATION.md 可以提炼出支撑这套计量的 Anthropic 缓存机制事实前缀匹配缓存键 tools→system→messages到某个cache_control断点为止的精确字节模型是键的一部分。「缓存命中要求提示片段 100% 一致」。作用域缓存按组织隔离自 2026 年 2 月起按 workspace 隔离。所有 ReviewHog 沙箱经 PostHog LLM 网关路由进同一个Anthropic workspace因此天然共享命名空间。TTL默认 5 分钟读会免费刷新滑动 TTL1 小时档写入 2×。沙箱路径实测运行在 5m 档通过计费、行为、CLI 反编译三重证明ENABLE_PROMPT_CACHING_1H1可无条件强制 1h。并发写入条目的可读性始于写入方响应开始之后——预热必须完整完成后才能扇出。这些机制直接决定了成本实验的设计边界为什么 fork 方案必须处理Task-Id插值V1 违规与动态系统段V2 违规导致的字节不一致、为什么只能从原始 JSONL 而非有损的 ACP 重建V3 违规播种——详见 HARNESS.md 的补丁面说明与 INVESTIGATION.md 的违规表。结语可以带走的四件事计量先行任何 LLM 成本优化实验第一步都应该是把 fresh / cache-write / cache-read / output 分开记账并让目录价反算与网关账单对账到接近零偏差本仓库做到了 Δ 0.0%。绝不裸看 token 数朴素输入 token 计价会高估 4.8 倍用它设门禁会得出完全错误的结论。分布优先于中位数跨沙箱缓存共享是「部分单元命中」而非「全部或全无」只有 per-unit 分布才能暴露已经发生的共享。质量控制与成本控制并行所有成本实验都必须在「precision-over-recall」的验证器裁决下进行质量对比如 8 进 4 出成本节省绝不能以牺牲审查质量findings 数量与覆盖为代价——正如项目锁定的第一条约束Quality is the moat质量是护城河。如需复现或深入运行脚本见 eval/scripts/dump_result.py实验规划与测量事实见 PLAN.md 与 CANDIDATES.md缓存机制与补丁面细节见 INVESTIGATION.md 与 HARNESS.md管线整体架构见 ARCHITECTURE.md。【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考