A FourWeekMBA report says DeepSeek nearly matched OpenAI’s cyber model on Vals at about $3 per run, but missing test details limit the claim for builders.

A FourWeekMBA report says DeepSeek came close to an OpenAI cyber model in a Vals evaluation while costing about $3 per run, a result that could sharpen the debate over the price of capable security-focused AI models.
The report is potentially significant for developers and enterprise buyers because cybersecurity workloads often require repeated analysis, code generation, vulnerability review, and testing. A lower-cost model that approaches a leading system’s performance could make it more practical to run those tasks at scale. But the available source provides only the headline and a short summary; it does not disclose the models, scores, test design, or pricing assumptions behind the comparison.
The source item, published by FourWeekMBA and distributed through a Google News query, describes DeepSeek as nearing “OpenAI’s Cyber Model” in a Vals test. It also places the cost at $3 a run. Those are the core reported facts available for this article.
The wording does not establish whether DeepSeek won individual tasks, matched OpenAI on an aggregate score, or simply performed within a narrow range of the OpenAI system. It also does not identify a specific DeepSeek model or an exact OpenAI product. “Cyber Model” may be a descriptive label rather than the formal name of a commercial system, so readers should not treat the comparison as a product-to-product benchmark until the underlying evaluation is published.
The same caution applies to the $3 figure. It could represent an estimated inference cost, a platform price, a fixed evaluation budget, or the cost of one particular workload. Without information about input and output volume, hardware, latency, or access terms, the number cannot be compared directly with a standard API price.
Cost is especially important when AI is used for security operations rather than occasional experimentation. A security team may ask a model to inspect many files, review dependencies, generate exploit explanations, triage alerts, or propose patches. If each run involves long context windows or multiple tool calls, the economics of the underlying AI models can determine whether a workflow remains a pilot or becomes part of routine operations.
A reported price near $3 could therefore attract attention from teams building automated security analysis and from founders looking for a cheaper foundation for specialized products. It could also encourage developers to use a model for more frequent verification rather than relying on a single answer.
However, low cost does not automatically mean lower total cost. A model that requires more retries, produces more false positives, or needs extensive human review can be more expensive in production than a higher-priced model with stronger reliability. For cybersecurity, the cost of a missed vulnerability or an unsafe remediation can outweigh the per-run inference bill.
The strongest performance claim in the available evidence is vendor- or publication-reported rather than independently verifiable here. FourWeekMBA’s headline points to a Vals test, but the source text supplied for review contains no methodology, scorecard, model versions, test date, task list, or independent replication.
That missing information matters because benchmark results can change substantially with prompt design, tool access, context length, grading rules, and whether the system is allowed to retry. Cybersecurity evaluations are particularly sensitive to task selection. A model may perform well at explaining known vulnerabilities while struggling with novel code, complex repositories, defensive prioritization, or safe changes to production systems.
The absence of details also makes it impossible to determine whether the comparison measures raw model capability or the surrounding product stack. If one system had access to browsing, code execution, a repository, or specialized security tools while the other did not, the headline score would not represent a like-for-like test.
The report should therefore be read as a signal that DeepSeek is being considered in the same competitive conversation as OpenAI for at least one cyber-focused evaluation—not as proof that the two systems are interchangeable.
For builders, the immediate lesson is to separate model selection from benchmark headlines. A team evaluating DeepSeek for a coding assistant or security product should reproduce the relevant workload using its own codebase, threat model, and acceptance criteria. Useful measurements would include vulnerability recall, false-positive rates, patch correctness, latency, tool-call reliability, and the amount of human review required.
Teams should also calculate the full workflow cost. A nominal $3 run may be attractive, but production systems may add costs for retrieval, sandboxing, logging, orchestration, storage, and manual escalation. The model’s licensing and data-handling terms are equally important when prompts contain proprietary source code or incident information.
For enterprise AI buyers, the comparison raises a procurement question rather than settling one: whether a cheaper model can meet the organization’s reliability, privacy, audit, and deployment requirements. A model suitable for analyst assistance may not be appropriate for autonomous remediation. Security teams should test failure behavior, not only average benchmark performance, including how the system responds when evidence is incomplete or a requested action could create risk.
The news also adds pressure to OpenAI and other providers to explain the value of premium cyber-focused systems. If lower-cost alternatives perform similarly on narrowly defined tasks, providers may need to differentiate through reliability, tool integration, governance, support, or measurable performance on harder evaluations.
The most important follow-up is the publication of the underlying Vals results. Readers should look for the exact DeepSeek and OpenAI model names, task categories, aggregate and per-task scores, and whether the evaluation was conducted by Vals, a vendor, or a third party.
Pricing details are another key signal. A useful comparison would specify token volumes, hardware or API rates, tool-call costs, rate limits, and whether the $3 estimate includes retries and surrounding infrastructure.
Builders should also watch for independent reproductions on real repositories and security cases. Evidence that DeepSeek can maintain performance across code review, vulnerability triage, patch generation, and adversarial testing would be more actionable than a single composite score. Enterprise buyers should track data residency, retention, logging, and deployment options before treating the result as a procurement opportunity.
The report is notable because it links a relatively low run cost with near-parity against an OpenAI system in a cyber evaluation. But with no accessible scores or methodology, the news is best treated as a prompt for diligence, not a conclusion about model leadership.
For AI builders, the practical opportunity is to test the economics and reliability of DeepSeek against their own workloads. The winning system will not necessarily be the one with the closest benchmark score; it will be the one that delivers dependable security outcomes at a cost and risk level a production team can accept.