Repository navigation
DeepSeek new pricing since August 16, 2026 #1643
Description
Activity
Assessment
This issue is actionable. The current embedded fallback still prices the direct
deepseek-v4-flashanddeepseek-v4-proentries at the pre-August 16 rates, while the current LiteLLM data exposes only the peak rates. Neither LiteLLM nor models.dev represents the time schedule, so refreshing either upstream snapshot alone cannot produce accurate historical totals.The official DeepSeek pricing page confirms the reported rates and specifies that peak pricing applies Monday through Friday from
01:00–04:00 UTCand06:00–10:00 UTC; all other times are off-peak. The issue should therefore be implemented as timestamp-aware pricing, not as a single replacement rate.Proposed Plan
- Define a small, hand-maintained DeepSeek schedule in
ccusage-corebecause the upstream pricing schemas cannot encode effective dates or peak windows. Cover the directdeepseek-v4-flashanddeepseek-v4-promodel IDs and intentionally supported date/version spellings. Preserve the pre-change rates before2026-08-16T00:00:00Z, use the supplied rates after that date, and map cache-miss tokens to input pricing and cache-hit tokens tocache_readpricing. Keep provider-specific reseller entries on their own static rates rather than applying the direct DeepSeek schedule to every fuzzy match. Encode cache creation consistently with the upstream direct entry, which currently publishes a zero rate. - Extend the core cost calculation path to select the schedule from each usage event’s absolute timestamp. Add UTC peak detection with explicit boundary tests, including weekday versus weekend behavior, the two peak windows, the cutover instant, and timestamps carrying non-UTC offsets. Keep existing
DisplayandAutobehavior for storedcostUSD; scheduled rates should affect recalculated costs. - Thread the parsed event timestamp through every adapter path that calculates token-based costs, including candidate-model helpers and advisor/derived usage entries. The affected code is centered in
ccusage-core/src/cost.rsandpricing.rs, with call-site updates across the Rust adapters; aggregation should continue summing already-calculated per-event costs so mixed pre/post-change and peak/off-peak reports remain correct. - Add regression coverage for both models and all token buckets at old, off-peak, and peak rates; exact model matching versus reseller/provider-prefixed models; offset timestamps normalized to UTC; and
Display,Auto,Calculate, offline, and refreshed-pricing paths. Add at least one fixture or CLI-level assertion proving a report containing events from different pricing periods produces the sum of per-event rates rather than applying one rate to the whole day. - Regenerate or review the committed models.dev artifact only if upstream changes its model metadata. Do not rely on that artifact to carry the schedule, and audit user-facing pricing documentation for any needed clarification; no CLI option or output-schema change is expected.
No implementation has been started in this evaluation.
Task list (3/3 completed)
- Read issue details and repository guidance for pricing changes
- Trace DeepSeek pricing implementation, data sources, and tests
- Post an actionable plan or analysis on issue DeepSeek new pricing since August 16, 2026 #1643
⚠️ this action is pinned to a commit SHA, which freezes the cleanup step — switch to@v0or keep the SHA fresh with Dependabot ｜ Implement plan ➔ ｜ View workflow run ｜ via Pullfrog ｜ UsingGPT Luna(free via Pullfrog for OSS) ｜ 𝕏- Define a small, hand-maintained DeepSeek schedule in
This issue was auto-closed. Issues from new contributors are auto-closed by default.
Maintainers review auto-closed issues and reopen worthwhile ones. Issues that do not meet the quality bar in CONTRIBUTING.md may not be reopened or receive a reply.
Keep the issue short, concrete, and written in your own voice.
If a maintainer replies
lgtmi, your future issues will stay open. If a maintainer replieslgtm, your future issues and PRs will stay open.See CONTRIBUTING.md.
@pullfrog Triage this issue using the repository standing issue-triage instructions. Inspect the full issue body, comments, current main branch, and related issues or pull requests. Choose exactly one priority label. If the issue is clearly unresolved and is priority:critical or priority:high with safe and well-scoped requirements, implement it and open a focused pull request. Otherwise, only triage it. Keep the explanation short and use simple English.
Reacted by pullfrogTriage:
priority:medium.Main already has the old DeepSeek v4 rates. The requested historical and UTC peak/off-peak pricing needs timestamp-aware changes across core cost calculation and adapters. The issue does not clearly define how provider and model aliases should behave, so this is not a safe, focused high-priority fix. No PR opened.
⚠️ this action is pinned to a commit SHA, which freezes the cleanup step — switch to@v0or keep the SHA fresh with Dependabot ｜ View workflow run ｜ via Pullfrog ｜ UsingGPT Luna(free via Pullfrog for OSS) ｜ 𝕏Automatic implementation was not started because the issue author GitHub email could not be resolved reliably for co-author attribution. A maintainer can implement the issue manually or provide a verifiable author email.
Historical audit: this discussion was auto-closed by the legacy contributor gate. That closure did not assess technical importance.
Audit result: resolved. A later merged change or the current
mainimplementation covers this request. This item is kept for history and does not need to be reopened.
What do you want to change?
Right now it still uses the old pricing pre-August 16, Below is a table with the new pricing.
Keep in mind the new prices vary based on the following peak hours:
01:00–04:00 UTC
06:00–10:00 UTC
Why?
Inaccurate pricing display for
deepseek-v4-*models.How? (optional)
No response