AIOGen · Au.AI Software Labs
From the founder’s desk · Benchmark checkpoint

A fair, same-hardware benchmark: AIOGen v0.12b-ganesha (Pre-MVP) vs Kyverno v1.18.1

Our earlier note published in April 2026 compared AIOGen against Kyverno’s published numbers on a different environment. This time, in June 2026, we deployed both engines side by side on the same 16-core virtual machine, enforced identical policies, and measured them together — across three latency layers and policy counts from 10 to 50.

~16×
faster end-to-end median (measured, same box)
~30×
faster at the engine handler @ 50 policies
Flat
latency vs. policy count — while the DSL engine climbs linearly

AIOGen is a compiled Kubernetes admission engine: policy logic runs as native code inside the engine. Kyverno is a widely-used DSL engine that interprets declarative YAML policy rules at request time. That single architectural difference predicts everything below — a compiled engine should stay flat as you add policies, while an interpreter should scale linearly. In this run, the data matches the theory.

Why this run is different. Every number here comes from a controlled, apples-to-apples test: the same single-node virtual machine, both engines deployed without CPU limits (matching Kyverno’s own recommended deployment), the identical set of Pod policies, and the allow path — a fully compliant pod that exercises every policy rather than short-circuiting on the first deny. Kyverno version: v1.18.1.

The three latency layers

Admission latency is best read as three nested circles. Isolating them keeps the comparison honest — it separates the policy logic itself from the engine around it, and from the network everyone pays.

Inner End-to-end (http_req) Kyverno 128 ms · AIOGen ~8 ms ~16× advantage Engine handler (outer) Kyverno 127 ms · AIOGen ~4 ms ~30× advantage Pure policy (inner) ~2.5 ms / rule · ~0.1 ms / symbol 50 rules ⇒ ~125 ms of pure logic Both engines pay the same ~3 ms network/TLS floor — it lives in the outer ring.
Figure 1 — The three latency layers at 50 policies (measured). The gap is widest at the engine handler, where compiled-vs-interpreted shows most.

The inner circle is the story in miniature: an interpreted rule costs roughly 2.5 ms each, so fifty of them is ~125 ms of pure logic. AIOGen’s compiled symbols cost a fraction of a millisecond each, so the same fifty barely move the needle. That is the difference between a curve that climbs and one that stays flat.

Latency vs. policy count

This is the decisive picture. As policies are added, Kyverno’s interpreter adds ~2.35 ms of median latency per policy; AIOGen stays essentially flat. Because one line climbs and the other doesn’t, the advantage isn’t a fixed multiplier — it compounds with scale.

Kyverno v1.18.1 (interpreted DSL) AIOGen (compiled native)
0 35 70 105 140 median latency (ms) 1019254050 policies per request 128 ms ~2.35 ms / policy 8.2 ms ~flat (<0.15 ms / policy)
Figure 2 — End-to-end median (k6 http_req_duration) vs. policy count. Every point measured, none projected. Kyverno v1.18.1.
PoliciesKyverno medianAIOGen medianEnd-to-end speedup
1034 ms2.2 ms~15×
1949 ms3.1 ms~16×
2564 ms3.7 ms~17×
40101 ms6.5 ms~16×
50128 ms8.2 ms~16×
0 10× 20× 30× 15×16×17×16×16× 1019254050 policies per request engine handler reaches ~30× @ 50 policies
Figure 3 — End-to-end speedup (Kyverno median ÷ AIOGen median) holds a durable ~16× across scale; at the engine-handler layer the advantage widens to ~30×.
Reading the two multipliers. The end-to-end number (~16×) is dampened because both engines pay the same fixed network/TLS round-trip on every request. Strip that shared floor away and look at the engine itself, and the compiled-vs-interpreted gap opens to ~30× at 50 policies — and keeps widening as policy count grows.

Why latency is a cost, not just a delay

Admission runs on the write path of every workload: each pod creation waits for the policy verdict. Every additional millisecond there is compute time spent evaluating requests and holding resources. In a busy cluster, higher admission latency compounds into more CPU, more memory pressure, more replicas to hold throughput — and a larger bill for the same governance outcome. A governance layer that behaves like efficient infrastructure, rather than recurring overhead, is simply easier to justify — especially at the edge, where every core is scarce.

Methodology

We publish the test profile so the claim is anchored to a defined workload and a disclosed reference version.

ItemDetails
Load generatork6, concurrent direct — 100 virtual users, 1000 requests
PathAllow path: a fully-compliant pod exercising the entire policy chain
EnvironmentSame single-node 16-core virtual machine; both engines deployed side by side, without CPU limits
PoliciesIdentical Pod policy set, measured at 10 / 19 / 25 / 40 / 50 policies
Kyverno versionv1.18.1 (self-deployed on the same host)
Inner-circle metricPure policy-logic latency (per rule / per symbol)
Outer-circle metricFull engine-handler latency (each engine’s own admission histogram)
End-to-end metrick6 http_req_duration median (client round-trip)
Disclaimer. These figures are point-in-time engineering measurements under controlled conditions and are not guarantees of future production performance. AIOGen remains under active optimization, and published metrics may change as the product evolves. Actual performance varies with hardware profile, Kubernetes version, request shape, policy count and complexity, admission configuration, and surrounding system activity. Where a third-party product (Kyverno v1.18.1) is referenced, the comparison is methodology-bound — both engines were run under the identical profile described above — and is provided for engineering context, not as a universal claim across all deployments.

Founder’s note

We share these results to show where AIOGen stands today, not to suggest the journey is finished. The earlier checkpoint compared us against a published benchmark on a different environment; this one puts both engines on the same box under the same load, which we believe is the fairer test. The result we care about most isn’t a single multiplier — it’s the shape of the curve. A compiled engine that stays flat as governance grows is what makes policy affordable at scale, from cloud to edge. Our focus from here is scale and deployment readiness.

— Founder, Au.AI Software Labs