DeepSeek API token pricing (serverless, off-peak vs peak, 2026-10-04 list price)

USD per 1M TOKENS, LIST PRICE, observed 2026-10-04. Two models, each with an OFF-PEAK and a PEAK rate, off-peak being exactly half of peak. deepseek-flash (DeepSeek-V4.1-Flash): cache-hit input $0.003 off-peak / $0.006 peak; cache-MISS input $0.15 off-peak / $0.30 peak; output $0.60 off-peak / $1.20 peak. deepseek-v4-pro (DeepSeek-V4-Pro-0813): cache-hit $0.022/$0.044; cache-miss $0.66/$1.32; output $1.98/$3.96. price_usd = flash cache-miss input, off-peak. Peak hours are 01:00-04:00 and 06:00-10:00 UTC Monday-Friday excluding Chinese public holidays; every other hour including all weekends and all Chinese public holidays is off-peak. Concurrency limits quoted on the same page: 2500 for flash, 500 for v4-pro PERISHABLE-FIGURE STAMP (added 2026-10-04, uniform across data/supply/ so it is greppable). PRICE CLASS: PUBLISHED LIST PRICE - an asking rate a new customer is quoted, NOT a realised, discounted or negotiated transaction rate. A real bill is at or below this and typically well below it once commitments, credits and committed-use discounts apply. OBSERVED: 2026-10-04 RE-VERIFY BY: 2027-01-04 - the repo's quarterly re-verification bar. After that date this figure is presumed drifted and must be re-checked against its source before it is quoted again. A price without its observation date is noise; this stamp exists so a reader can tell a fresh figure from a stale one without reading prose. UNIT: USD per 1M TOKENS, LIST PRICE, observed 2026-10-04 READING RULE: No further perishable flag is published for this figure.

lead_time_weeks is null because NO NUMBER APPLIES, and the reason is specific rather than generic: this record prices a metered service term (tokens, egress, storage) rather than hardware capacity, so there is no order-to-delivery interval to report at all. Calling this 'no published lead time' would be wrong in the other direction - nothing was withheld.

no EAR citation: no controlled item is transferred by this transaction; not an EAR citation: provider service terms and end-use policy (the AI Diffusion Rule briefly tiered service access before its 2025-05-13 rescission)

MECHANISM: a token-priced API, so no accelerator crosses a border and the 3A090 hardware licence regime does not attach to the transaction. Export control becomes an END-USER AND TERMS question instead: the provider applies geographic and end-use restrictions to service access, and a customer can still be refused under sanctions or end-use policy wherever the compute sits. A reader targeting a restricted destination should read the provider's terms, not the EAR.

This is the only provider in this set with a TIME-OF-DAY PRICE, and it is a 2x swing that no naive cost model captures. A workload that is latenct-tolerant enough to run at night pays half; the same tokens on a weekday morning cost double. For a batch or eval pipeline, schedule against the peak windows rather than averaging them. Second structural point: cache-hit input at $0.003 per 1M is 50x cheaper than cache-miss at $0.15, which makes prompt caching the dominant lever here by a wider margin than at any other provider in this set (Anthropic's best cache read is 40x its input; Google's cache storage is charged per hour instead). Any DeepSeek bill that does not report a cache-hit share is hiding the main cost driver. DeepSeek publishes no GPU hourly rate and no region list. EXPORT CONTROL (2026-10-04): NOT APPLICABLE IN THE HARDWARE-SHIPMENT SENSE - this record prices a token-based API, so no accelerator is transferred across a border and the ECCN 3A090 hardware licence regime does not attach to the transaction. Recorded null rather than false precisely because a token API is where export control instead becomes an END-USER/TERMS question: the provider applies geographic and end-user restrictions to service access (the AI Diffusion Rule briefly put a tiered country structure on exactly this kind of service before being rescinded on 2025-05-13), and a customer can still be refused under sanctions or end-use policy regardless of where the compute sits. Anyone reading this record for a restricted destination should look at the provider's terms, not at the EAR. Sources for the regime: spl-bis-2025-05-ai-diffusion-rescission, spl-bis-2026-05-d5-guidance. EXPORT CONTROL (2026-10-04): NOT APPLICABLE IN THE HARDWARE-SHIPMENT SENSE - this record prices a token-based API, so no accelerator crosses a border and the ECCN 3A090 hardware licence regime does not attach to the transaction. Recorded NULL rather than false precisely because a token API is where export control instead becomes an END-USER and TERMS question: the provider applies geographic and end-user restrictions to service access (the AI Diffusion Rule briefly put a tiered country structure on exactly this kind of service before being rescinded and unenforced from 2025-05-13), and a customer can still be refused under sanctions or end-use policy regardless of where the compute sits. For a restricted destination, read the provider's terms, not the EAR. Sources: spl-bis-2025-05-ai-diffusion-rescission, spl-bis-2026-05-d5-guidance. LEAD TIME: null - correct and not a gap. A token-priced serverless API is provisioned on request, so there is no lead time to publish; the binding constraint when a model is at capacity is provider-side queuing and any per-account concurrency limit, which this repo records in notes where a vendor publishes one (see the DeepSeek concurrency figures already here). Deliberately NOT recorded: any 'model capacity lead time' estimate, because vendors publish none and the SEO 'GPU lead time' numbers that circulate do not apply to a rented endpoint. Probe log in source spl-negative-no-oem-publishes-lead-time. VOLATILE STRUCTURE, RECORDED WHILE IT IS STILL TRUE - observed 2026-10-04. This section exists because the structure is more perishable than the number: it is the PRICING SHAPE, not the rate, that a future reader is most likely to find has changed. AS OF 2026-10-04 DeepSeek is the ONLY provider in this repository whose price varies by TIME OF DAY. The off-peak rate is exactly half the peak rate on every model and every column - cache-hit input, cache-miss input and output alike - so the swing is a uniform 2x rather than a mix. The peak windows as published are 01:00-04:00 and 06:00-10:00 UTC, Monday to Friday, EXCLUDING Chinese public holidays; every other hour, including all weekends and all Chinese public holidays, is off-peak. WHY THIS WILL STALE AND WHY THE DATE MATTERS: peak windows are set to smooth demand against a provider's own capacity and there is no published commitment that they stay put. The window can be moved, narrowed, widened, or the whole mechanism can be retired if capacity improves; the 2x ratio is equally uncommitted. None of that is speculation about DeepSeek's plans - it is the general property of a promotional rate. What the 2026-10-04 observation buys a future reader is the ability to say WHICH shape was true, rather than discovering from a silent price change that the tiering moved. THE STRUCTURAL CONSEQUENCE NOBODY SHOULD RE-DERIVE: a single blended per-token rate is WRONG for this provider by construction. A workload that is latency-tolerant and shiftable to UTC nights pays half; the identical token volume on a weekday morning costs double. Any comparison of DeepSeek against a flat-priced provider is invalid unless it states its assumed duty cycle across the peak windows. That makes the off-peak rate the correct figure to plan against and the peak rate the correct figure to provision for. ALSO VOLATILE AND WORTH WATCHING ON THIS RECORD: the published concurrency limits on the same page (2500 for deepseek-flash, 500 for deepseek-v4-pro), because those are capacity controls rather than price and can move independently of it. No GPU-hour rate is published and none should be inferred.