FinClaw V1 Cost and Token Budget Design (B-7)

状态：Accepted Initial Design / V1 工程化前最后一波工程化设计（Wave 2，第 4 份） 日期：2026-05-16 项目：FinClaw 文档级别：项目级工程化设计文档 上游决策：v1-engineering-kickoff-decisions.md D-04 / D-05 / D-08；v1-model-and-provider-policy.md §7（被本文校准与落地） 上游设计：v1-tech-stack-and-architecture-design.md §5（LLM Provider Layer）、v1-data-and-persistence-design.md §3（Trace 对象）、v1-api-contract-design.md §8（错误码 / 限流）、v1-observability-and-telemetry-design.md §10（Cost Telemetry Hook 双向对齐）

1. Purpose

本文件定义 FinClaw V1 在 token cost 与 budget 边界 上的工程化契约：

• 每次 LLM 调用的 token cost 模型与 provider unit cost 占位；
• Provider 路由经济学（何时优先 GPT-5.5、何时优先 Kimi K2.6）；
• Per-user / Per-session / Per-route budget cap 数值与执行机制；
• Failover 路径的 cost 影响估算；
• BYOM 用户的 cost-shift 模型（用户承担）；
• 超预算时的降级路径（不是"硬中断"，而是 graded degradation）；
• Trial 阶段的 budget alarm 与项目发起人 escalation；
• Cost telemetry 与 v1-observability-and-telemetry-design.md §10 的双向对齐。

本文不讨论 provider 选型（已在 D-04 + v1-model-and-provider-policy.md §3 锁定）；不讨论商业信号 / 漏斗指标（属于 v1-commercial-signal-instrumentation-design.md 范围）；不讨论系统健康 / 性能指标（属于 v1-observability-and-telemetry-design.md 范围）。

2. Goals and Non-Goals

2.1 Goals

• Goal-1：让 trial 期 3 人内测的月度总成本可预测、可观察、可硬上限拒绝；
• Goal-2：单次 task / snapshot / advisor 视角的 cost 上限可在 config/cost_policy.yaml 中配置化，无需改代码；
• Goal-3：超预算时优先降级而非直接拒绝（避免 trial 用户体验"突然不可用"）；只有 hard cap 才拒绝；
• Goal-4：BYOM 调用的 cost 不计入 FinClaw budget，但调用元数据（model / tokens）依然落 telemetry；
• Goal-5：所有 cost telemetry event 与 v1-observability-and-telemetry-design §10 中定义的 cost_telemetry event schema 严格一致。

2.2 Non-Goals

• Non-Goal-1：不做 token-level 精确计费表（V1 用 provider 公开 unit price 粗估即可）；
• Non-Goal-2：不引入第三方 cost 跟踪 SaaS（Helicone / LangSmith 等都不接入）；
• Non-Goal-3：不做 trial 用户的 self-serve billing（V1 内测 3 人由项目发起人统一承担）；
• Non-Goal-4：不实现 token-level 实时流式 cost 估算（cost 在 task 闭环结束后写入 trace）；
• Non-Goal-5：不实现跨 user / 跨 month 的成本归因报表（trial 期项目发起人手工汇总即可）。

3. Cost Model and Provider Unit Costs

3.1 Cost 公式

每次 LLM 调用的 cost：

cost_usd = (prompt_tokens * provider_unit_cost_prompt
          + completion_tokens * provider_unit_cost_completion) / 1_000_000

provider_unit_cost_* 单位是 USD / million tokens。

3.2 Provider Unit Cost 占位（需项目发起人确认）

下表是 V1 trial 启动前的 unit cost 占位；trial 启动前必须由项目发起人核对真实 provider pricing 并锁定到 config/cost_policy.yaml：

Provider	Model	unit_cost_prompt (USD / 1M tokens)	unit_cost_completion (USD / 1M tokens)	备注
OpenAI	gpt-5.5 (primary)	5.00（占位）	15.00（占位）	与 v1-model-and-provider-policy §3 Primary Cognition Provider 对应；需以项目发起人 / pricing page 确认日为准
Moonshot	kimi-k2.6 (secondary)	2.50（占位）	7.50（占位）	中文长上下文价格优势；与 v1-model-and-provider-policy §3 Secondary Cognition Provider 对应；需以项目发起人确认
BYOM	user-supplied	0.00（FinClaw 视角）	0.00（FinClaw 视角）	用户自承担；FinClaw cost telemetry 记录但不计入 budget cap

强约束：

• config/cost_policy.yaml 是 cost layer 唯一权威；代码中禁止硬编码 unit cost；
• pricing 每次刷新写入 data/_internal/pricing_history.jsonl（append-only）+ 当前生效一份在 config/cost_policy.yaml；
• pricing 变更触发 hot reload（无需重启）；变更事件落 v1-observability-and-telemetry-design §4 logs/audit.log。

3.3 单 Task Cost 构成

一次完整 task（snapshot / refresh / checkpoint）的 cost 由以下分量构成：

分量	内容	占比经验估算
Main cognition call	Primary provider 一次或多次主调用（含 tool_use 循环）	~60%
Advisor 视角 calls	每个被激活 advisor 一次调用（典型 2~4 个）	~25%
Skill internal sub-calls	evidence_audit 等 Skill 内部子调用（典型 0~2 个）	~10%
System prompt / context overhead	system + skill / advisor 指令重复部分	~5%

实际比例随 route 类型与 advisor 数量浮动；§4 / §5 给出更细粒度的 per-route 估算。

3.4 Cost 估算占位（每 V1 route 一次完成）

下表是基于 §3.2 unit cost 占位 + §3.3 构成比例的 粗估，仅用于 §5 budget cap 设计与 §9 alarm 阈值；真实 cost 由 telemetry 校准：

Route	默认 Primary	典型 prompt+completion tokens	估算 cost (USD)
snapshot.create	GPT-5.5	~12K + 4K = 16K	~$0.08
thread.refresh (diff)	GPT-5.5	~10K + 3K = 13K	~$0.06
checkpoint.create (pre-execution)	GPT-5.5	~6K + 2K = 8K	~$0.04
advisor.view (counter-thesis / market_macro)	Kimi K2.6	~6K + 2K = 8K	~$0.03
skill.evidence_audit (internal)	GPT-5.5	~3K + 1K = 4K	~$0.02

实际 cost telemetry 落 §10；trial 第 1 周后由项目发起人核对真实 cost 并回写本表。

4. Provider Routing Economics

4.1 决策规则

Provider 选择由 v1-model-and-provider-policy §5 Skill / Advisor → Provider 映射 表锁定，本文不重启选型讨论。但 routing 还有 cost-aware 的覆盖维度：

触发条件	路由覆盖	说明
prompt tokens > 32K	强制走 Kimi K2.6 长上下文	长上下文 GPT-5.5 cost 涨幅显著 vs Kimi K2.6
当日 per-user spend > 80% daily cap	后续 advisor 视角降级到 Kimi K2.6	详见 §8.2 degradation
当日 global spend > 80% daily cap	后续 advisor 视角降级到 Kimi K2.6（全 cohort）	§9 alarm
cost_sensitive: true (在 config/agent_routing.yaml 内标注)	优先 Kimi K2.6	例：辅助叙事映射等非主分析
quality_critical: true（仅 snapshot / pre_execution 默认）	锁定 GPT-5.5；不降级	主要结构化对象

4.2 Cost vs Quality Tradeoff

V1 不做自动的 cost-quality A/B；以下原则锁定：

原则	决议
主 Snapshot / Pre-Execution Checkpoint	不允许因 cost 降级到 Kimi K2.6（避免结构化输出退化）
Counter-Thesis / Market-Macro Advisor	默认 Kimi K2.6（已是 cost 优化路径）
Skill 内部子调用	默认 GPT-5.5（小调用，质量重要）
Refresh diff	默认 GPT-5.5；当 prompt > 32K 时强制 Kimi K2.6

4.3 Routing Telemetry Field

每次 LLM 调用必须记录 routing_reason 字段以便后续分析（落 §10 cost telemetry event）：

routing_reason	含义
default_mapping	按 v1-model-and-provider-policy §5 映射表
long_context_override	prompt > 32K 长上下文强制
cost_degradation	per-user 或 global 超 80% cap 后的降级
cost_sensitive_flag	agent_routing.yaml 显式标注 cost_sensitive
failover_chain	主 provider 失败后切换备选（详见 §6）
byom_user_supplied	用户 BYOM 调用

5. Per-User / Per-Session / Per-Route Budget Caps

5.1 Budget Scope Matrix

V1 内测 3 人，daily / monthly cap 较保守。所有数字占位，trial 启动前由项目发起人在 config/cost_policy.yaml 锁定：

Scope	Cap Type	V0 占位上限	触达后行为
Per snapshot.create	hard	$0.20（≈ §3.4 估算的 2.5×）	拒绝 + HTTP 429 + error code quota_exceeded
Per thread.refresh	hard	$0.15	同上
Per checkpoint.create	hard	$0.10	同上
Per advisor view	soft	$0.05	写入 warning 字段；不阻断
Per user / day	hard	$3.00（占位）	后续 task degradation；详 §8
Per user / month	hard	$50.00（占位）	拒绝新 task；已 saved thread 可读
Global / day (3-user trial)	hard	$10.00（占位）	全 cohort 降级；详 §9 alarm
Global / month	hard	$200.00（占位）	全 cohort 进只读模式
BYOM	n/a	用户自承担	不计入 FinClaw budget

5.2 Budget Counter 实现

维度	存储位置	重置周期
Per-route per-call	不持久化（在 task closure 内一次性计算）	n/a
Per-user daily	data/_internal/budget_counters/<user_id>/daily-<YYYY-MM-DD>.json	每日 00:00 UTC+8
Per-user monthly	data/_internal/budget_counters/<user_id>/monthly-<YYYY-MM>.json	每月 1 号 00:00 UTC+8
Global daily/monthly	data/_internal/budget_counters/_global/daily-<YYYY-MM-DD>.json 等	同上

Counter 每次写入 atomic（文件锁，与 v1-data-and-persistence-design §4 文件写入规范一致）。

5.3 Pre-call Estimation vs Post-call Truth

V1 不实现 pre-call 精确估算（避免引入 token 估算器 fix）。决策规则：

检查	时机	字段
Per-user daily cap	task 启动前 读 counter；若已超 cap → 拒绝（HTTP 429 quota_exceeded）	policy.user_daily_cap_remaining_usd
Per-user monthly cap	同上	policy.user_monthly_cap_remaining_usd
Per-route per-call cap	task 结束后算 cost；若超 → 标记 trace over_route_cap: true + 下次 same-route 直接降级	trace.cost_overrun = true
Soft cap	同上；写 warning，不阻断	trace.warnings += ["over_soft_cap_advisor"]

这避免了"pre-call 错误估算导致拒绝合理 task"的体验问题。

5.4 Route 与 Endpoint 对应

v1-api-contract-design §4 中的 endpoint 与 §5.1 route 对应关系：

Endpoint	Route Scope
POST /api/tasks (route=snapshot)	snapshot.create
POST /api/tasks (route=thread_refresh)	thread.refresh
POST /api/tasks (route=pre_execution_checkpoint)	checkpoint.create
internal advisor sub-call	advisor.view
internal skill sub-call	skill.<skill_id>

每个 task 闭环结束时由 cost_telemetry 模块合并所有 sub-call cost，归一到一次 task-level cost 汇总（落 §10）。

6. Failover Cost Impact

6.1 Failover 触发的 cost 影响

v1-model-and-provider-policy §6 Failover and Resilience 定义了 4 类失败处理；本文给出 cost 视角：

失败类型	Cost 影响	是否仍计入 budget
Transient（重试 ≤ 3 次）	重试 cost 不累加（同一 prompt 重发）	仅最终成功一次计入
Provider-specific（切备选 provider）	第二次调用 cost 完全独立	累加（两次 cost 都计）
Persistent（鉴权失败 / 服务下线）	同上，第二次完全独立	累加
Quota / Budget 超限	第二次不发起	第一次（已发起部分）计入；超限错误不二次扣费

6.2 Failover Cost 上限保护

为防止 failover chain 失控（连续切换烧钱）：

• 单次 task 内 failover 最多 1 次；第二次失败直接返回 provider_unavailable HTTP 503；
• failover 切换的 cost 不计入 per-route soft cap（避免被切换 cost "顶上"造成误降级），但计入 per-user daily / monthly cap；
• failover chain 完整记录在 trace.failover_chain[]，落 §10。

6.3 Failover 经济性提醒

如果 trial 期间 GPT-5.5 → Kimi K2.6 failover 频次 > 5%，应触发 §9 alarm 并由项目发起人决定：

• 是否调整 v1-model-and-provider-policy §5 默认 mapping；
• 是否在 D-04 决议中重启 Anthropic 作为应急 provider（v1-model-and-provider-policy §8 O-6）。

7. BYOM Cost-Shift Model

7.1 BYOM Cost 归属

v1-engineering-kickoff-decisions D-05 决议 BYOM 开放但非默认。从 cost 视角：

维度	决议
BYOM 调用产生的 LLM cost	用户自承担；FinClaw 不付任何 provider 费
BYOM 调用是否计入 per-user daily / monthly cap	不计入 FinClaw budget cap
BYOM 调用的 token usage / cost 元数据	必须记录到 §10 cost telemetry，但 cost_usd_source 字段标 byom_self_reported 或 byom_provider_response_extracted
BYOM 用户的 framework 使用 cost（FastAPI server / data 存储等基础设施开销）	V1 trial 不向用户收取（trial 期间项目发起人统一承担）

7.2 BYOM Cost 上报机制

BYOM provider 大多返回 usage 段（OpenAI / Moonshot 协议都有）。V1 实现：

步骤	行为
1	llm_client BYOM adapter 解析 response 中的 usage.prompt_tokens / usage.completion_tokens
2	如果 BYOM provider 不返回 usage：tokens 标 unknown，cost 标 null（不阻断调用）
3	如果 BYOM provider response 有 cost_usd 字段（少见但部分自托管 endpoint 有）：直接采用
4	否则：BYOM cost 在 telemetry 中标 null；用户可在 config/byom.yaml 配置 cost_unit_override，按 §3.1 公式估算（用户自报）

7.3 BYOM Quality / Cost Tradeoff Notice

UI / API 必须在 BYOM 启用时向用户清晰提示（v1-ui-prototype-and-design-system §6 边界 UX）：

• BYOM 输出不保证与默认 provider 同等质量；
• BYOM cost 由用户承担；FinClaw 仅记录元数据；
• BYOM 调用失败不自动 fallback 默认 provider（避免用户成本意外产生，与 v1-model-and-provider-policy §4 一致）。

8. Overrun Handling and Degradation Path

8.1 设计原则

超预算时的处理优先 graded degradation 而非硬中断——这是 trial 用户体验的关键。只有最严重的违约（per-user monthly hard cap、global monthly hard cap）才返回错误码。

8.2 Degradation Ladder

当 per-user daily spend / cap 比率从 0% → 100% 演进：

  0% - 60%   : 正常路径（无降级）
 60% - 80%   : Tier-1 — soft warning 写入 trace.warnings; 用户无感知; 系统记录
 80% - 100%  : Tier-2 — 后续 advisor.view 调用强制走 Kimi K2.6 (cost_degradation routing)
                       新 task 启动前向用户提示「今日预算剩余 X%」（UI banner）
100% - 120%  : Tier-3 — 新 snapshot/refresh/checkpoint 拒绝（HTTP 429 quota_exceeded）
                       已生成 thread 可继续查看; advisor.view 也拒绝
> 120% (per-user monthly) : Tier-4 — 整个 user 进入只读模式；只能查看历史；不能发起任何 LLM 调用

8.3 Tier-2 降级细节

Tier-2 是体验关键。规则：

子规则	行为
主 Snapshot / Pre-Execution Checkpoint	不降级（§4.2 锁定 quality_critical）
Counter-Thesis / Market-Macro Advisor	已是 Kimi K2.6（无变化）
Risk Advisor / Asset Research Advisor	从 GPT-5.5 切到 Kimi K2.6；routing_reason = cost_degradation
Skill 内部子调用	不降级（小调用，质量重要）
用户 UI 提示	[v1-ui-prototype-and-design-system §6 边界 UX](./v1-ui-prototype-and-design-system.md) 中的 BudgetWarningBanner 组件渲染

8.4 Tier-3 拒绝行为

返回 v1-api-contract-design §8 错误对象：

{
  "code": "quota_exceeded",
  "message": "Daily budget exhausted for this user; new tasks blocked until 00:00 UTC+8 reset.",
  "details": {
    "scope": "user_daily",
    "spent_usd": 3.07,
    "cap_usd": 3.00,
    "reset_at": "2026-05-17T00:00:00+08:00"
  },
  "trace_id": "tr_2026-05-16T18-32-00_8f3a2c",
  "retriable": false,
  "user_visible": "今日额度已用完，明天 00:00 重置；已保存的认知线索仍可查看。"
}

HTTP 429（标准 quota 错误码；与 v1-api-contract-design §8.1 错误码表对齐）。

8.5 Degradation 与 cs-event 对齐

每次进入 Tier-2 / Tier-3 / Tier-4 时，必须 emit 一个 v1-commercial-signal-instrumentation-design 事件：

Tier	cs-event name
Tier-2	budget_degradation_started
Tier-3	budget_hard_cap_hit
Tier-4	budget_lockout_started

Tier-3 / Tier-4 退出时（次日 00:00 重置 / 用户充值）emit budget_lockout_lifted。

8.6 全局降级（Global Tier-2/3/4）

§5.1 中的 Global / day 与 Global / month 触达时，全 cohort 进入相应 Tier。Trial 阶段（3 人）这等同于"项目发起人 alarm 必看"，由 §9 处理。

9. Trial-Phase Budget Alarms

9.1 Alarm 矩阵

触发条件	Channel	Receiver	Severity
任一 user Tier-2 进入	structured log + daily digest	项目发起人（次日 09:00 看 digest）	low
任一 user Tier-3 进入	structured log + 立即文件 alarm（logs/alarms.log append）	项目发起人（手工 check）	medium
任一 user Tier-4 进入	structured log + 立即文件 alarm + 强制 daily digest 标 red	项目发起人 + 项目发起人 + Mark.T	high
Global Tier-2 进入	同上 + 立即文件 alarm	项目发起人	medium
Global Tier-3 / Tier-4 进入	同上 + 立即文件 alarm + 强制 daily digest 标 red	项目发起人 + 项目发起人 + Mark.T + Aven	high
Failover 切换 > 5% (24h 滑窗)	structured log	项目发起人	low
单 user 当日 cost > 平均的 3×	structured log	项目发起人（异常使用调查）	medium

V1 不引入 PagerDuty / 邮件 / Telegram 推送（与 D-02 一致）；alarm 仅落 logs/alarms.log 与 daily digest。

9.2 Daily Cost Digest

每日 09:00 UTC+8 由项目发起人手工运行 make cost-digest（与 v1-observability-and-telemetry-design §8 error digest 同一机制）。输出：

字段	内容
period	昨日 00:00 - 23:59 UTC+8
total_spend_usd	global daily total
per_user_breakdown	每 user 当日 spend + 占 cap 比
top_routes_by_cost	cost 最高的 5 个 route
failover_events	当日 failover 次数 + 占总调用比
budget_tier_events	当日触达的 Tier-2/3/4 事件列表
anomalies	单 user > 平均 3× 或 routing_reason 异常分布

输出格式：markdown，落 data/_internal/cost_digests/<YYYY-MM-DD>.md。

9.3 Trial Budget Calibration Loop

Trial 启动后第 1 周内，项目发起人按下表校准 §3.2 / §5.1 数值：

校准项	数据源	调整方式
Provider unit cost	provider pricing page（或实际 invoice）	改 config/cost_policy.yaml
Per-route cap	真实 cost telemetry P95	改 config/cost_policy.yaml
Per-user daily cap	第 1 周实际平均 × 1.5	改 config/cost_policy.yaml
Global daily cap	per-user daily × 3 × 1.2	改 config/cost_policy.yaml

校准操作日志落 data/_internal/cost_policy_history.jsonl append-only。

10. Cost Telemetry Hook

10.1 与 v1-observability-and-telemetry-design §10 的关系

v1-observability-and-telemetry-design §10 Cost Telemetry Hook 定义了 cost telemetry 在 observability 体系中的位置（event schema、SQLite 索引、聚合）。本文是其语义来源：

• B-5 §10 关心 telemetry 系统层（event 怎么落、怎么查、怎么 aggregate）；
• B-7（本文）§10 关心 cost 业务层（事件何时 emit、字段语义、与 budget cap 的关联）。

两者必须字段名 + 单位 + 含义完全一致。任何不一致以 B-7 §10.2 schema 为准。

10.2 Cost Telemetry Event Schema

每次 LLM 调用 closure 时由 cost_telemetry 模块 emit 一次：

event_type: cost_telemetry
emitted_at: <ISO8601>
trace_id: <trace_id>
task_id: <task_id, optional>
route: snapshot.create | thread.refresh | checkpoint.create | advisor.view | skill.<id>
provider:
  name: openai | moonshot | byom
  model: <model_name>
  endpoint: <url, hashed if BYOM>
tokens:
  prompt_tokens: <int>
  completion_tokens: <int>
  total_tokens: <int>
cost_usd:
  value: <float | null>     # null 仅当 BYOM 无 usage 信息
  source: priced_from_config_yaml | byom_provider_response_extracted | byom_self_reported | unknown
  unit_cost_revision: <pricing_history.jsonl 中的 revision id>
budget_impact:
  user_daily_pct_after: <0..1.2+>
  user_monthly_pct_after: <0..1.2+>
  global_daily_pct_after: <0..1.2+>
  triggered_tier_transition: null | "tier_1_to_2" | "tier_2_to_3" | ...
routing_reason: default_mapping | long_context_override | cost_degradation | cost_sensitive_flag | failover_chain | byom_user_supplied
failover_chain: []   # 如有，列出 provider 切换序列
user_id_hash: <hash, per v1-observability-and-telemetry-design §12>
session_id_hash: <hash>

字段命名与单位（USD、token、ISO8601）严格一致；任何字段重命名都必须在两文同步。

10.3 落盘与索引

• 主存：evaluation/runs/<trace_id>/cost_telemetry.jsonl（与 trace 同目录，便于 closure 检索）；
• 旁路索引：data/_internal/observability/cost_telemetry.sqlite（与 v1-observability-and-telemetry-design §3.3 telemetry SQLite 同库不同表 cost_events）；
• SQLite 索引列：(emitted_at, route, provider_name)、(user_id_hash, emitted_at)；
• 查询入口：make cost-summary / make cost-digest（§9.2）。

10.4 与 cs-instrumentation 的边界

v1-commercial-signal-instrumentation-design.md emit 的事件中，budget_degradation_started / budget_hard_cap_hit / budget_lockout_started / budget_lockout_lifted 4 个事件由 cost_telemetry 模块 emit 后 forward 给 cs-instrumentation pipeline（避免双重发射）。

cs-instrumentation 侧只补充 cohort / commercial 维度字段，不重新计算 cost。

10.5 Privacy

cost telemetry 不包含：

• 任何 prompt 原文 / completion 原文；
• 用户 raw ID（仅 hashed，与 v1-observability-and-telemetry-design §12 一致 salt）；
• 凭证 / endpoint URL 原文（BYOM endpoint URL 一律 hash）。

cost telemetry 可以包含：

• token counts、cost、provider model name、routing reason、failover chain、budget tier transition。

11. Acceptance

项	验收
config/cost_policy.yaml 模板存在，含 §3.2 provider unit cost + §5.1 budget cap 全字段	engineering 实施 W-7 时验证
cost_telemetry 模块按 §10.2 schema emit；JSONL + SQLite 双写	unit test + integration test
Tier-1 → Tier-2 → Tier-3 → Tier-4 状态机按 §8.2 实现；transition 触发 cs-event（§8.5）	integration test 覆盖 4 个 transition
Tier-3 拒绝行为返回 §8.4 错误对象 + HTTP 429 + cs-event	integration test
BYOM 调用 cost 不计入 user daily / monthly cap，但 telemetry 仍记录	integration test
Failover 经济性约束：单 task 内 failover ≤ 1 次（§6.2）	integration test
make cost-digest 命令 + daily digest 输出（§9.2）按 schema 落盘	manual check + sample digest
Provider unit cost 与 budget cap 数值不出现 hardcoded 在代码中（全部走 config/cost_policy.yaml）	grep audit
cost telemetry 不写入任何 prompt / completion 原文 / raw user_id（§10.5）	privacy audit grep
§3.2 / §5.1 占位数值由项目发起人 trial 启动前 sign-off（risks_or_debt 单项）	项目发起人 sign-off

12. Open Items

• O-1：§3.2 GPT-5.5 / Kimi K2.6 真实 unit price 需项目发起人在 trial 启动前以 provider pricing page 或实际 invoice 确认（trial 启动硬阻塞项）；
• O-2：§5.1 daily / monthly cap 占位数值（$3 / user / day、$50 / user / month、$10 / global / day、$200 / global / month）需项目发起人 sign-off；
• O-3：§4.1 prompt tokens > 32K 强制 Kimi K2.6 的阈值是否合适 — 待 trial 第 1 周 cost telemetry 校准；
• O-4：§8.2 Tier-2 进入阈值（80%）是否过严 — 待 trial 启动后据用户体验调整；
• O-5：§7.2 BYOM cost_unit_override 配置项是否需要 UI 暴露给用户 self-serve — V1 倾向否（仅 config/byom.yaml 文件配置）；trial 退出前评估；
• O-6：§9.1 alarm 是否需要在 V1 trial 期间接入 Telegram / Slack — 与 D-02 一致否；保留 logs/alarms.log 文件 alarm；
• O-7：Failover 5% 阈值（§9.1）是否合理 — 待 trial 第 2 周校准；
• O-8：是否在 trial 期允许项目发起人 hot reload config/cost_policy.yaml 而不重启 server — §3.2 已倾向支持；具体实现细节由 W-7 工程实施确认。

13. References

• v1-engineering-kickoff-decisions.md（D-04 / D-05 / D-08 / D-12）
• v1-model-and-provider-policy.md（§3 / §5 / §6 / §7 — 本文是 §7 的工程化校准）
• v1-tech-stack-and-architecture-design.md（§5 LLM Provider Layer）
• v1-data-and-persistence-design.md（§3 Trace、§4 文件写入规范）
• v1-api-contract-design.md（§4 endpoints、§8 错误码 / 限流）
• v1-observability-and-telemetry-design.md（§3 / §10 — 与本文 §10 双向对齐）
• v1-commercial-signal-instrumentation-design.md（§8.5 budget cs-event forward）
• v1-ui-prototype-and-design-system.md（§6 BudgetWarningBanner UX）
• v1-task-packet-context-budget-schema.md（frontmatter schema 规范）