convex-cost

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<!-- GENERATED from convex-agents content/capabilities/convex-cost.json — do not edit by hand. -->
<!-- 由convex-agents的content/capabilities/convex-cost.json生成——请勿手动编辑。 -->

Preview what this app will cost

预览该应用的成本情况

Cost surprises come from a handful of functions reading far more data than anyone realized — the same read-heavy patterns convex-advisor flags for perf, seen through the money lens. This capability makes spend legible: it reads the deployment's own bytes/documents-read evidence, attributes it to the functions driving it, projects how it grows with traffic, and names the cheapest fix. It also carries the confirm-cost discipline (Supabase's structural consent for paid actions): before anything metered, state the price and get an explicit yes.
成本意外往往源于少数函数读取的数据量远超预期——这些读取密集型模式正是convex-advisor针对性能问题标记的内容,如今从成本视角重新审视。此功能让支出情况清晰可见:它读取部署自身的「读取字节数/文档数」数据,将其归因于对应的驱动函数,预测其随流量增长的趋势,并找出成本最低的修复方案。同时,它遵循confirm-cost规范(Supabase针对付费操作的结构性同意机制):在执行任何计量付费操作前,明确告知价格并获得用户的明确同意。

Workflow

工作流程

  1. GUARD: deploy-guard — a cost read is read-only over dev/prod (insights is cloud+user-auth only; not previews). Announce the deployment.
  2. GATHER the spend evidence via the official MCP:
    insights
    for the bytes-read / documents-read events (the direct cost signal — Convex bills on function calls + bandwidth),
    tables
    for row counts (a table's size bounds its scan cost),
    functionSpec
    for the surface. If there's no usage/traffic yet, say so and estimate from the query SHAPES instead (a
    .collect()
    on a table projected to grow is a future cost even with zero traffic today).
  3. ATTRIBUTE: rank functions by bytes/documents read per call × observed (or asked-about) call volume — the product is the cost driver, not either alone. A cheap-per-call function called constantly can outweigh an expensive rare one; show both factors.
  4. PROJECT: state how the top drivers scale — a full-table
    .collect()
    grows LINEARLY with the table (cost compounds as data accumulates); an indexed
    .take(n)
    stays flat. Give the user the shape of the curve ('this is O(table size) per call — fine at 1k rows, a bill at 1M'), not a false-precision dollar figure.
  5. NAME THE CHEAPEST FIX per driver — index +
    .withIndex
    instead of scan,
    .paginate
    /
    .take
    instead of
    .collect
    , an aggregate component for counts, caching a hot read — and emit it as a cost-class finding on the bus (evidence: the insight event + the projected growth) pointing at convex-expert/convex-advisor for the actual change.
  6. CONFIRM-COST for paid actions: if the flow includes anything metered (a domain purchase, cloud provisioning, a plan change), STATE the price and recurrence explicitly and get an explicit yes BEFORE proceeding — never let a paid action happen as a side effect (the cost-confirm gate).
  7. REPORT: the current cost drivers ranked, each with its evidence + growth shape + fix, and a plain bottom line ('your spend is dominated by messages:list reading the whole table every call; index it and it drops ~100x'). Honest precision: Convex pricing changes and depends on plan — give relative/shape guidance and cite the pricing page for absolute numbers rather than inventing a dollar total.
  1. 防护机制:deploy-guard——在开发/生产环境中,成本读取操作是只读的(insights仅支持云端+用户授权访问;不包含预览环境)。发布部署通知。
  2. 收集支出数据:通过官方MCP获取数据:使用
    insights
    获取「读取字节数/读取文档数」事件(直接成本信号——Convex按函数调用量+带宽计费),使用
    tables
    获取行数(表的大小决定了扫描成本上限),使用
    functionSpec
    获取函数表面信息。如果尚无使用量/流量,则说明情况并根据查询模式进行估算(即使当前流量为零,对预计会增长的表执行
    .collect()
    操作也会成为未来的成本项)。
  3. 归因分析:按「每次调用读取的字节数/文档数 × 实际(或查询的)调用量」对函数进行排序——两者的乘积才是成本驱动因素,而非单一因素。一个单次调用成本低但调用频繁的函数,其总成本可能超过一个单次调用成本高但很少被调用的函数;需同时展示这两个因素。
  4. 趋势预测:说明主要成本驱动因素的扩展趋势——全表
    .collect()
    操作的成本随表大小线性增长(成本会随数据积累而复合增加);带索引的
    .take(n)
    操作成本保持平稳。向用户说明增长曲线的类型(「此操作每次调用的成本与表大小呈线性关系——1000行时成本可控,100万行时会产生高额账单」),而非提供虚假精确的美元金额。
  5. 找出最低成本修复方案:针对每个成本驱动因素,给出成本最低的修复方案——使用索引+
    .withIndex
    替代扫描,使用
    .paginate()
    /
    .take
    替代
    .collect
    ,使用聚合组件统计数量,对高频读取进行缓存——并将其作为成本类发现结果发布到总线上(依据:insights事件+预测增长趋势),指向convex-expert/convex-advisor以执行实际修改。
  6. 付费操作成本确认:如果流程包含任何计量付费操作(如域名购买、云资源配置、套餐变更),需明确告知价格和计费周期,并在执行前获得用户的明确同意——绝不能让付费操作作为副作用发生(成本确认关卡)。
  7. 生成报告:按排序展示当前的成本驱动因素,每个因素需包含相关数据、增长趋势类型和修复方案,并给出清晰的总结(「您的支出主要由messages:list函数每次调用时读取整张表所主导;为其添加索引后,成本可降低约100倍」)。诚实精准:Convex的定价会变化且取决于套餐——提供相对/趋势指导,并引用定价页面获取绝对数值,而非自行估算美元总额。

Rules

规则

  • Cost = data-read-per-call × call-volume — always show both factors; a cheap function called constantly can cost more than an expensive rare one.
  • Read the deployment's own insights/bytes-read evidence for spend; with no traffic yet, price the query SHAPES (a scan on a growing table is a future cost).
  • Give the growth CURVE, not false-precision dollars: O(table) scans compound as data accumulates; indexed access stays flat. Cite the pricing page for absolute figures.
  • Every cost driver names its cheapest fix and emits a cost-class finding on the bus pointing at the fixer (convex-expert/advisor).
  • Confirm-cost for any metered/paid action: state the price + recurrence and get an explicit yes BEFORE it happens — never as a side effect.
  • Read-only over dev/prod (deploy-guard); insights is cloud+user-auth only. Cost composes convex-advisor's evidence but frames it as money, not latency.
  • 成本 = 每次调用读取的数据量 × 调用量——需始终展示这两个因素;一个调用频繁的低成本函数可能比一个很少调用的高成本函数总成本更高。
  • 读取部署自身的insights/读取字节数数据来分析支出;若无流量,则根据查询模式评估成本(对增长中的表进行扫描是未来的成本项)。
  • 提供增长曲线,而非虚假精确的美元金额:与表大小相关的扫描操作成本会随数据积累复合增加;带索引的访问成本保持平稳。引用定价页面获取绝对数值。
  • 每个成本驱动因素都需明确最低成本修复方案,并将成本类发现结果发布到总线上,指向负责修复的组件(convex-expert/advisor)。
  • 对任何计量/付费操作进行成本确认:明确告知价格+计费周期,并在执行前获得明确同意——绝不能作为副作用发生。
  • 在开发/生产环境中为只读操作(deploy-guard);insights仅支持云端+用户授权访问。成本分析整合了convex-advisor的数据,但从成本而非延迟的角度进行解读。