How We Cut Inference Costs and Scaled Our Defenses at Averlon with Cynos

Overview

Cynos is a Cyber Inference Platform purpose-built to understand cybersecurity, DevOps, and IT tasks, select the best-fit open or closed model, and evaluate every result. If a result falls short, Cynos retries the task with additional guidance or escalates it to a more capable model. This makes it possible to deliver frontier-grade cybersecurity outcomes at a fraction of the cost.

Under the hood, Cynos identifies what kind of security work each request represents, weighing the task, its complexity, the capabilities it requires, and the quality bar the result has to meet. It routes to the cheapest model and provider that can clear that bar, uses domain expert judges and fine-tuned models to iteratively improve results, and automatically fails over to an alternate model or provider if one goes down.

We built Cynos for our own security work first. In this post, we walk through three use cases where we run it in production at Averlon today: code scanning, triaging DevOps alerts, and penetration testing.

Use Case 1: Code Scanning

We started with GitHub Dependabot and GitHub Advanced Security, but both are largely pattern-based. They didn't follow the logic of our code, so our engineers spent their time working through false positives. Codex Security, OpenAI's open-source agentic scanner, did far better on frontier models, but one scan of 10 internal repos on GPT-6 Sol cost $49.50, too much to run as often as we wanted.

So we built Cynos Scan, which runs Codex Security on open models through Cynos. A scan mixes planning, file selection, code navigation, labeling and false-positive filtering, and Cynos sends each step to the cheapest open model that handles it well, with a judge checking every response. On open models alone, Codex Security ran about five times slower, spending 81% of agent time rereading source, and scoped its investigations poorly. A precomputed knowledge base fixes both: a code graph of the repository, its entry points, sinks and the paths between them, a threat model, and investigation packets built around attacker goals. It costs cents per repo, is cached between scans, and makes scans almost three times faster with half the model requests.

On 10 internal repos, Cynos Scan scored 52.7 strict F3 for $6.62, against 43.9 for $49.50 on GPT-6 Sol and 50.6 for $63.74 on GPT-5.6 Sol. That's 7.5 to 9.6 times cheaper with a higher score, and level with both on findings with real impact. That cost is what let us move from occasional scans to frequent ones.

Use Case 2: Triaging DevOps Alerts

Our infrastructure alerts flow from Grafana into Opsgenie and an on-call channel in Slack. Traditionally, every alert that fired pulled one or more engineers in to figure out whether it was real, what caused it, and who needed to act.

We took OpenSRE, an open-source harness built to triage DevOps alerts, and plugged it into Cynos. OpenSRE now does the first line of triage on every alert before a human looks at it.

Here's a real example. A Grafana alert fired for error logs on our ClickHouse server in a dev environment and was routed to our on-call rotation as a P1. About four minutes later, OpenSRE on Cynos picked it up, and 120 seconds after that it posted its findings directly on the alert:

1. Verdict: Real failure, not noise. A ClickHouse pod was aborting inserts into the logs table with a memory limit error.
2. Evidence: It pulled the 12 error lines behind the alert, identified the exact pod, shard, and replica, the ClickHouse version, the failing statement, the client IP, and the database user. Notably, the alert rule's own compound filter returned nothing, so it simplified the query to surface the actual errors.
3. Root cause: The insert from one of our data pipeline users carried wide request and response payloads that exceeded its per-query memory ceiling. It also ruled out disk, confirming there was over 180 GiB free.
4. Fix: Raise the memory limit for that user, confirm the pod's container limit allows it, or shrink the insert batch, then re-run the dropped inserts.
5. Confidence and action: High confidence, with the one gap called out explicitly (the alert fired about six minutes after the errors were logged), plus a clear recommendation on who should act and what to verify.

The on-call engineer no longer starts from a raw alert. They start from a verdict, the evidence behind it, and a proposed fix. Noise gets dismissed quickly, real issues get to the right owner faster, and fewer engineers get pulled into every page. Because Cynos routes most of this work to smaller, cheaper models, we can afford to run triage on every alert, not just the critical ones.

Use Case 3: Penetration Testing

For pen testing, we initially tried running agents on OpenAI's Daydream and Anthropic's Claude Fable 5.1. We ran into two problems. First, legitimate offensive security tasks against our own applications kept hitting model safeguards, which stalled the agents mid-test. Second, the cost made continuous testing impractical.

Cynos solves both. Alongside its routing, Cynos serves abliterated models together with models fine-tuned for offensive security tasks. We run Strix, an open-source AI pen testing harness, against Cynos, and it now continuously tests our web applications without being blocked on authorized work, at a cost we can sustain.

What This Means for Us

Across all three use cases, the pattern is the same. We point a strong harness, open source or commercial, at Cynos. That's what lets us scan more often, triage every DevOps alert, and test continuously, scaling our defenses without scaling our inference bill.

If you're running security agents today, you can try the same thing. Sign up at app.cynos.averlon.ai, create a virtual key, and swap your current provider for Cynos in your existing agents.