dsh-budget: cost governance, budget caps and over-limit policies for DeepSeek Harness

[PerryLink]

dsh-budget — cost governance for DeepSeek Harness: aggregated token/cost metering per model, session, and day, session/daily/monthly budget caps with threshold alerts (webhook + desktop notification) and alert/block/degrade over-limit policies, carbon footprint estimation, per-model latency benchmarks, a Settings budget tab, and the /budget command.\n\nWhat it solves / 解决什么问题\n\n- Know your spend: usage is aggregated from the session/event stream and priced through the built-in USD table merged with your own prices; per-model, per-session, per-day.\n- Stop runaway costs: budget caps per session/day/month with warn-ratio alerts and over-limit policies — alert, block (short-circuits the LLM call), or degrade (names the fallback model).\n- See the side effects: carbon footprint estimation (tokens × kWh × PUE × regional intensity) and p50/p95 per-model latency stats.\n- Operate it: Settings budget tab, /budget command, budget/status + budget/setSettings + budget/unblock remote, and sanitized budget/alert + budget/block audit events.\n\nInstall / 安装\n\nsh\ndsh plugin --profile web add dsh-budget\n\n\nLinks / 链接\n\n- Repository: https://github.com/PerryLink/dsh-budget\n- npm: https://www.npmjs.com/package/dsh-budget\n- Listed in (open PRs): awesome-dsh-plugins#218, awesome-deepseek-harness#323, bruc3van/awesome-dsh-plugin#80\n\nApache-2.0 · issues and PRs welcome.

[NovaRouteAI]

@PerryLink budget caps with alert/block/degrade policies is the governance layer most harness deployments are missing — the over-limit policy choice matters more than people expect, since blocking a long agent run mid-task can cost more in redo than letting it finish.

One blind spot worth covering: reconciliation between the metered totals and the official console. Cache hit/miss bucketing differences alone can shift the effective price by an order of magnitude, so a daily diff report between dsh-budget's numbers and the provider's would make the cap trustworthy.

Cross-tool usage reconciliation is part of what we've been testing with an OpenAI-compatible multi-model API layer focused on routing, fallback, and cost visibility.

Does dsh-budget currently trust its own meter, or does it validate against the provider's numbers?

[PerryLink]

Great question - today dsh-budget trusts its own meter. It meters usage events from the llm stream with tokens bucketed as uncached input / output / cache-read / cache-write, then prices them through the built-in USD-per-1M table merged with your config.prices. Cache-bucket differences are representable in the price table, but there is no reconciliation against the provider console yet - a cap is only as trustworthy as the configured prices.

Your daily-diff suggestion is the right direction for making a block/degrade decision defensible: metered-vs-billed drift (cache-bucket mapping above all) is exactly where an estimator goes wrong. A pluggable "provider usage probe" that diffs the day aggregate against official numbers is on the design candidate list - not on the near-term roadmap.

On block-vs-finish: agreed on the redo cost, which is why alert is the default over-limit policy and block/degrade stay opt-in per deployment.

[NovaRouteAI]

@PerryLink the four-way bucket split plus a configurable price table is the right foundation — most meters collapse cache-read into input and lose the signal before pricing even starts.

For the probe's first cut, a cheap version might earn its place faster than full reconciliation: one daily aggregate per model diffed against the provider number, with the drift percentage emitted as a metric. That alone makes block decisions defensible, and the drift signal can also gate the policy itself — if metered-vs-billed drift exceeds a threshold, downgrade block to alert automatically rather than trusting a known-stale meter.

That "trust the meter only while it's verified" pattern is close to what we chase on the API side while testing an OpenAI-compatible multi-model layer with usage/cost visibility.

Would the probe pull the provider numbers on a schedule, or only when a cap decision is about to fire?