@stmol/dsh-rub-cost

LIMITATIONS

Known limitations

* PRC statutory holidays are not modelled. The plugin keeps one year-agnostic rule — Beijing weekday plus peak window — so it needs no annual edit, and a holiday weekday is therefore priced as a peak day. DeepSeek bills those days at the off-peak rate, so on such a day the amount and the countdown are both too high until the holiday is over. The official dates live in the State Council notice published every November, which is the only source; the client bundle ships no year-specific table on purpose. * The ruble total is not a sum of per-request bills: the whole session is repriced at the tariff in effect when the card renders, so a peak/off-peak switch doubles or halves the amount without a single new token. The tariff and the price rows name what is in effect, which is exactly what the countdown counts down to. * `tokenUsage` holds a whole-session total with no per-route split, so after a mid-session model change everything is estimated with the last used model. * Cache writes are billed at the cache miss rate: DeepSeek publishes no separate price, and on DeepSeek routes that counter is zero anyway. * Subagents use their own last used model at the current tariff, and a child that has not chosen a route yet falls back to the parent's. * The balance request pins `x-client-version`. The version is hardcoded in `client.js` and has to be updated by hand after a DSH upgrade. * The clock zone comes from the browser, not from the DeepSeek account: the account profile (`remote.account.getProfile`) exposes no timezone. When the browser reports no zone at all, the card falls back to `DEFAULT_OFFSET_MS` (UTC+3).