DeepSeek’s October update offers lower-cost access and improved developer-reported results, but federal suppliers must assess model provenance, contract requirements and deployment architecture before adoption.
DeepSeek released DeepSeek-V4.1-Flash-1017 on October 17, promising stronger performance, faster task completion and shorter outputs than its preceding model. The release is available through the company’s applications and API, with downloadable weights also provided.
The technical update coincides with a significant procurement development. A US Department of Homeland Security notice filed on October 19 and scheduled for Federal Register publication on October 20 disclosed an order excluding DeepSeek products from covered federal civilian procurements and requiring their removal from civilian agency IT. Its stated scope includes third-party products and services developed using DeepSeek implementations.
For enterprise buyers, the result is a split assessment: whether the model performs well enough for a workload, and whether that deployment is permitted.
What the new DeepSeek model changes
DeepSeek’s model card reports improvements across several evaluations, including software engineering and terminal-based tasks.
| Evaluation | Previous V4.1 Flash | V4.1 Flash 1017 |
|---|---|---|
| DeepSWE v1.1 | 74.2 | 77.0 |
| Terminal-Bench 4.0 | 31.2 | 42.3 |
| ProgramBench | 20.3 | 29.1 |
Source: DeepSeek’s published model card. These are developer-reported results, not TechLayers testing.
The same model card identifies different agent harnesses for different evaluations. That matters because tools, prompts, execution environments and retry allowances can influence results.
A higher benchmark score is a reason to investigate a model—not proof that it will perform better on every organisation’s codebase.
DeepSeek lists the repository and weights under the MIT licence. That provides licensing information for use and modification; it does not establish procurement eligibility, security approval or suitability for sensitive data.
API pricing needs a workload-based comparison
DeepSeek’s pricing page identifies the current deepseek-flash version as DeepSeek-V4.1-Flash-1017.
Its published rates distinguish cached input, uncached input and generated output:
| Token category | Off-peak, per million tokens | Peak, per million tokens |
|---|---|---|
| Cached input | $0.003 | $0.006 |
| Uncached input | $0.15 | $0.30 |
| Output | $0.60 | $1.20 |
Peak periods are 01:00–04:00 and 06:00–10:00 UTC, Monday–Friday, excluding Chinese public holidays, according to the provider.
For example, one million uncached input tokens plus 200,000 output tokens would cost approximately $0.54 at peak rates:
- Input: $0.30.
- Output: 0.2 × $1.20 = $0.24.
The equivalent off-peak calculation is $0.27. These examples exclude separate tool charges, hosting, retries and operational overhead.
Adding the headline input and output rates produces the cost of one million tokens of each type—two million tokens altogether. It is not a standard price for one million mixed tokens.
The federal restriction reaches beyond DeepSeek’s own app
The DHS notice is important because it expressly includes third-party implementations. Replacing a direct DeepSeek endpoint with another supplier’s interface therefore does not, by itself, establish that a product falls outside the restriction.
Hosting location and model provenance answer different questions.
Hosting can affect data handling, access and operational control. A procurement restriction can instead attach to the underlying technology or supplier. Moving a model to US infrastructure should consequently not be presented as an automatic compliance solution.
The notice concerns covered federal civilian procurement and IT. It is not, on its own, evidence of a blanket prohibition on every private-sector deployment.
Contract details determine supplier obligations
FAR 52.204-30 prohibits providing or using covered products during contract performance when an applicable FASCSA order prohibits them, unless an applicable waiver exists.
The clause also addresses timing: an order issued after solicitation applies through the specified amendment or contract-modification process. Contractors should therefore examine their actual contract rather than assume identical treatment across every engagement.
Where the clause applies, it requires SAM.gov checks at least every three months, or as advised by the contracting officer, and an initial report within three business days when the specified reporting conditions are met.
Defence and intelligence work can involve separate authorities. Exclusion from one order’s jurisdiction is not affirmative approval under another framework.
A practical enterprise review
The following checklist is an engineering and procurement review framework, not a legal determination.
| Review area | Evidence to obtain |
|---|---|
| Model provenance | Base model, version, fine-tunes and upstream dependencies |
| Deployment | Hosting region, operator, subprocessors and support access |
| Contract coverage | Applicable clauses, orders, modifications and written guidance |
| Data handling | Retention, logging, training use and access arrangements |
| Performance | Results on representative tasks, failure rates and review effort |
| Portability | A tested replacement and documented migration process |
An inventory should include internal assistants and subcontractor tools, not just customer-facing products. A dependency may enter through a coding tool, document-processing service or managed platform.
For commercial workloads, separation from government work should be demonstrable through architecture, access controls and operating procedures. A label such as “commercial environment” is insufficient evidence by itself.
Design for a model change before one becomes urgent
Model portability requires more than swapping an API address.
Providers differ in tool calling, output formats, context handling and failure behaviour. A replacement that passes a simple text-generation test may still fail in a production workflow.
Teams can reduce migration risk by maintaining representative evaluations, recording the model actually serving each request and testing an alternative against the same acceptance criteria.
DeepSeek’s pricing documentation also says some legacy model names now route to the newer model. Buyers should verify version behaviour rather than assume an API name permanently identifies unchanged weights.
Performance and permission are separate buying decisions
DeepSeek’s update provides measurable claims worth testing. The federal notice creates a separate eligibility question that benchmark performance cannot answer.
For enterprises, the stronger procurement process evaluates both: whether a model delivers acceptable results at a competitive total cost, and whether its provenance, deployment and contractual treatment fit the intended use.
