Frontier Model Is the Wrong Meter for Continuous Security

The economics of continuous security at frontier-model prices, and why the math points back to independence.

The frontier models are astonishing at finding vulnerabilities. That is not in dispute, and it is not what this piece is about. The question is not whether a frontier model can find a flaw in your code. It is whether you can afford to run one as your scanner, continuously, across your entire estate, the way real security actually works. The answer is no, and the reason is worth understanding, because it is one more place where the economics point straight back to an independent layer.

The sticker price of frontier-model security is the easy part

Start with the number. Anthropic prices Fable 5 and Mythos 5 at ten dollars per million input tokens and fifty dollars per million output tokens. That makes them the most expensive generally available models on the market, roughly double the price of Claude Opus 4.8 and about twice the input price of GPT-5.5. Anthropic itself frames this as the affordable tier, less than half the price of its restricted Mythos Preview. Affordable is relative.

For a single task, that premium can be worth it. For a model you point at a problem occasionally, the math is fine. Security is not occasional. Security is continuous, and continuous is where this breaks.

Output tokens are the part you can’t optimize away

Here is the detail most cost conversations miss. Across the entire model lineup, output tokens cost five times input tokens. The expensive half is not the code you send in. It is the analysis the model writes back.

Security scanning is output-heavy by nature. You are not asking the model to read a file and say “fine.” You are asking it to enumerate findings, explain each one, reason about reachability and exploitability, and propose fixes. That is exactly the kind of long-form generation that runs up the bill, and it is the half of the equation the usual discounts do not touch.

Teams point to prompt caching, which cuts cached input reads by ninety percent, and batch processing, which halves everything. Both are real. Neither rescues this use case. Caching discounts the code you send, not the findings the model generates, and the findings are where the cost lives. Batch mode halves the rate but does nothing about the volume, and the volume is the problem.

Continuous scanning volume is the real cost problem

A real enterprise estate is not a tidy benchmark. It is millions of lines across hundreds of repositories, thousands of dependencies, and years of accumulated architecture. Continuous security means scanning that estate again and again, on every commit, every dependency change, every release. Not once. Constantly.

To put a floor under it, a published analysis modeled a single enterprise document pipeline at roughly twelve and a half thousand dollars a month for five hundred million tokens, and that was at the fifty percent batch discount. A continuous scan across a full codebase is not five hundred million tokens. It is orders of magnitude more, run on repeat. You do not need a worst-case story to see where that lands. You only need to do the multiplication, and any CFO will finish the sentence for you.

This is the trap of using a metered frontier model as an always-on scanner. The better it is, the more it generates, and the more it generates, the more it costs. The incentives run exactly backwards from what continuous security needs.

For regulated buyers, data retention takes it off the table

There is a harder wall behind the cost one. Frontier security models carry data-handling terms that a regulated enterprise cannot simply accept. Anthropic now requires 30-day retention of all traffic on its Mythos-class models, on both first-party and third-party surfaces, and that requirement overrides zero-retention agreements some enterprises had already negotiated. Cheaper models like Opus 4.8 still run under zero data retention. Mythos-class does not. Running a continuous scan on one of these models would mean piping your entire proprietary codebase through an external system that holds onto it for a month.

For healthcare, financial services, and the public sector, that is not a line item to negotiate. It is a compliance barrier that takes the option off the table regardless of budget. Cost is the reason most enterprises cannot run frontier-model scanning at scale. Data governance is the reason a large part of the regulated market cannot run it at all.

That is the same independence argument from a different direction. Independence is not only about who you trust to verify the code. It is about whose infrastructure is even allowed to touch it.

Where the math actually lands

None of this means frontier models have no place in security. It means they have the wrong cost and compliance profile to be the meter that runs all day. The sound architecture is an independent layer built for continuous, whole-estate scanning at a cost structure that makes always-on viable, and that runs without shipping your code to a model that retains it. Use frontier capability surgically, for the hard and novel problems where it earns its premium. Do not wire it up as the default scanner and watch the meter spin.

The frontier models changed what is findable. They did not change what is affordable, or what is compliant, to run continuously across an enterprise. That gap is not a temporary pricing quirk that the next release closes. It is structural, and it is the independent layer’s to own.