You built a security audit tool. It finds vulnerabilities. It’s smart. It’s thorough. And it just ate one million tokens to audit a medium-sized codebase.
Congratulations. You’ve built something that works perfectly and fails completely.
This is what happened when Cloudflare shipped their Security Audit Skill. The GitHub comments tell the story the blog post didn’t:
“Uf, how much tokens?”
“I threw 1M tokens for nothing in a medium codebase.”
One million tokens. For a medium codebase. For nothing.
A security audit skill that burns through a million tokens on a medium codebase isn’t a tool. It’s a tax.
Here’s what nobody at Cloudflare seems to have calculated: the real bottleneck for AI security audit skills was never the audit capability. It was always the token economics.
You can build the most sophisticated security analysis engine in the world. If it costs 1M tokens to run on a medium codebase, it is functionally unusable. Not because the analysis is wrong—because no developer is going to pay that token tax on every pull request, every commit, every code review.
The analysis quality is irrelevant if the economics don’t work.
But the token problem is actually a symptom of a deeper issue. Look at what the top comment on the GitHub repo says:
“Hi Cloudflare people, if you are reading this. Please clean up your Cloudflare Skills. There are way too many skills for the platform. You should consolidate all of your skills into a single skill and route everything through that skill. The way it is right now pollutes our context window.”
Context-window pollution is the new technical debt—and nobody’s counting the cost.
Cloudflare fragmented their security capabilities into too many separate skills. Each skill loads its own context. Each skill adds its own overhead. Each skill competes for space in a context window that has hard limits. The result? A developer’s context window gets polluted with skill scaffolding instead of actual code analysis.
This is the dirty secret of AI developer tools: the actual product isn’t the security logic. It’s the prompt and context orchestration.
A security audit skill that doesn’t aggressively minimize token usage isn’t just inefficient. It’s a liability. Every token spent on skill overhead is a token not spent on actual code analysis. Every skill fragment polluting the context window is space taken away from understanding the codebase.
Then there’s this comment, buried in the requirements section:
“Any clues why ‘an OS-enforced sandbox’ is in requirements?”
If your AI security tool requires an OS-enforced sandbox, the biggest vulnerability might be the AI itself.
Think about what that requirement implies. The tool needs to be sandboxed from the operating system. Why? Because the AI has access to your code. All of it. Every file, every secret, every API key, every configuration. The sandbox isn’t there to protect your code from external threats. It’s there to protect your system from the AI.
The implication is staggering: the most dangerous entity in your security pipeline might be the very tool you’re using to find vulnerabilities.
Meanwhile, Synthesia’s team saw the problem and built their own solution. Their comment in the thread: “In case someone finds this requiring too many tokens, we shared the recipe on how we built our own in house audit skill so that it can easily be replicated and tuned to different environments.”
They didn’t just complain. They recognized that the token economics were broken and built something that respects the constraints.
The best AI security tool isn’t the one with the most capabilities. It’s the one that does the most with the fewest tokens.
Here’s what every developer building or using AI security tools needs to understand:
First, token economics IS the product. If your skill burns 1M tokens on a medium codebase, you haven’t built a security tool. You’ve built a cost center. The analysis quality matters less than the cost-per-insight.
Second, skill sprawl is context-window pollution. Every additional skill you add to a platform doesn’t just add capability—it adds overhead. The more skills you fragment your capabilities across, the less effective each one becomes. Consolidate. Route through a single entry point. Minimize context pollution.
Third, the real engineering challenge in AI security tools isn’t building better security logic. It’s building better context orchestration. How do you load only the relevant code? How do you minimize token usage while maximizing analysis depth? How do you keep the context window clean?
The teams that solve these problems will build the tools that developers actually use. The teams that don’t will ship impressive demos that burn tokens and die in production.
Cloudflare built a security audit skill that works. But working isn’t enough. In the age of AI developer tools, the constraint isn’t capability. It’s economics.
Your AI tool’s token bill is its real feature list. Everything else is marketing.
FAQ
Q: But doesn't better security analysis justify higher token costs?
A: No. A tool that costs 1M tokens per medium codebase will never be run consistently. Developers won't pay that tax on every PR or commit. If the economics don't work, the analysis quality is irrelevant—it dies in production.
Q: What should I do if I'm building an AI security tool?
A: Treat token minimization as a core feature, not an optimization afterthought. Consolidate skills into a single routing entry point. Load only relevant code context. The real engineering challenge is context orchestration, not security logic.
Q: Is the OS-enforced sandbox requirement actually about protecting the AI from itself?
A: It's about protecting your system FROM the AI. The tool has access to all your code, secrets, and configs. The sandbox requirement is an admission that the AI's access to your codebase is itself a vulnerability vector. The security tool might be the security hole.