Benchmarks · Scenario library
Every request either passes clean, gets blocked on the way in, or gets blocked on the way out — here’s the concurrency sweep for each, with the rule count, payload size, and flow behind every curve.
These are the same measured runs behind the headline numbers on the main benchmarks page, broken out per scenario so you can see exactly what each one is measuring — not just the fastest numbers.
ValGuard delivers sub-80ms p99 latency in realistic multi-agent flows and blocks bad inputs in under 110ms p99 — even at 1,000 concurrent requests.
Live Metrics: Automatically benchmarked on VMware VM every 48 hours. Last run: Aug 28, 2026.
Bad prompts never reach the LLM — and never hit your bill.
A prompt-injection attempt is rejected by the input guard before any upstream request is made. No model call, no token spend, no wasted round trip.
A broken model response gets caught, not shipped downstream.
The upstream returns non-JSON text where structured output was required. The output guard rejects the response before it ever reaches your application code.
The default shape: one guarded call to a real HTTP upstream.
Full proxy round trip against an HTTP upstream (BYOK custom provider) with a JSON response — the same path most agents run in production, end to end.
Guardrails don't break SSE — the stream still just streams.
Same guarded path, but the upstream responds over Server-Sent Events and the full stream is consumed — proving validation overhead doesn't leak into streaming latency.
No upstream call at all — this is pure ValGuard overhead.
Upstream is mocked in-process (no network hop), isolating exactly what the proxy + validation engine cost on their own, with everything else held constant.
Three agents, three validation gates, still microsecond-scale.
Tightest tail under load — p99 stays ~1.05× p50 at 1,000 concurrent
A 3-step linear playbook (triage → compliance → reply) with a validation gate at every handoff — the orchestration overhead on top of the proxy path.
ValGuard’s numbers are the measured scenarios on this page. “Typical middleware” is a general reference point for classifier- or LLM-judge-based guardrails and synchronous re-check patterns — not a specific named product.
| Signal | ValGuard | Typical middleware† |
|---|---|---|
| p99 latency at 1,000 concurrent requests | 73.82–380.73 ms (measured, path-dependent) | Often 200 ms – 1 s+ under equivalent load |
| Bad input rejected before the model is called | Yes — inline guard, no upstream call | Rarely — usually checked after the model replies |
| Verdict consistency | Deterministic — same input, same result, every time | Often probabilistic (classifier/LLM-judge drift) |
| Added cost per request | ~$0 — no extra model call | Extra LLM call or ML inference per request |
† Illustrative industry reference points for classifier/LLM-judge-based guardrails, not a specific benchmarked product.
