Performance

A lock you don't feel.

One millisecond at the median, measured, with every compliance gate on.

How it worksRead the quickstart
CONTROLLED FAST PATH · GATE ON
requestproviderinspect01route02seal03out04requestproviderinspect01route02seal03out04

Inspection runs in-process, restoration happens inside the stream, and the data plane is Rust: the gate costs one millisecond at the median.

4,046 RPSPeak throughput
+1 msMedian gate overhead
13.6×vs. LiteLLM throughput

One upstream. Identical hardware. The same load.

Every gateway fronts the same keep-alive mock at the same concurrency, isolating gateway overhead from provider variance.

  • One shared mock upstream

    All four gateways hit the same Node mock: keep-alive on, one fixed 60 ms delay.

  • Isolated, identical hardware

    Each runs in a CPU/memory-pinned container, hit by oha at 256 connections.

  • Gate-off baseline

    Allow-all policy, DLP observe-only, audit content off: Sluis as a plain OpenAI-compatible proxy.

  • Gate-on: the real product

    EU residency, DLP masking, content retention, hash-chained audit: every gate on the hot path.

01 / PRODUCT

What you don't give up.

A lock lets the ship through: nothing you rely on is traded away for compliance.

  • Streaming stays streaming: tokens leave as they arrive, restored inside the stream.
  • Caching answers repeats: exact and semantic caches, per tenant, encrypted at rest.
  • Failover stays in policy: Sluis reroutes only to a fallback your policy allows.
02 / METHOD

Built so the result can't be quietly rigged.

Every config is pinned and identical across gateways, so the comparison can't be quietly tilted.

  • All gateways pinned to identical CPU and memory cgroups.
  • The mock upstream is byte-identical and shared; one fixed delay for everyone.
  • LiteLLM and Bifrost run identical configs, with no hidden flags.
  • Equal discarded warmup and equal measurement window per gateway.
  • Every run is gated on status codes: anything but 100% HTTP 200 is discarded.
Results

The numbers, exactly as measured.

Two Sluis columns: gate-off, an apples-to-apples proxy comparison; gate-on, the compliance overhead against our own baseline.

Measured 2026-07-04 on identical hardware (one Apple Silicon Mac, Docker) at 256 connections; a relative comparison. Every run verified 100% HTTP 200, repeat variance under 1%. Peak RSS wasn't captured this run, so that row stays TBD.
MetricSluis gate-offSluis gate-onLiteLLMBifrost
Throughput (RPS)4,046
3,678
298
3,148
p50 latency (ms)62
63
743
80
p99 latency (ms)77
130
4,584
118
Peak RSS (MiB)TBD
TBD
TBD
TBD
Success rate100%
100%
100%
100%

Latency is end-to-end through the gateway over the shared fixed-latency mock: the differences are the gateways' own overhead.

The gate-on column is compliance overhead versus gate-off, not a head-to-head.

Against a live model (rate-capped at 10 RPS so the provider never throttles), the gate adds nothing at the median: 305 ms gate-on versus 304 ms gate-off. The p99 tails in that lane belong to the provider, not the gateways.

An honest claim, or none at all.

A benchmark you can't trust is worse than none, so we set the rules before any number ships.

  • The head-to-head “fastest” claim is gate-off only: Sluis as a plain proxy versus LiteLLM and Bifrost.
  • Gate-on is overhead against our own baseline: one millisecond at the median, nine percent throughput, p99 130 ms versus 77 ms.
  • The rate-capped live lane adds nothing at the median; its p99 tails are provider variance.
  • If gate-off Sluis isn't clearly faster, the headline becomes “compliance at negligible cost”.

Built for the regulator in the room, not just the load test.

Read how the gateway works, then see how the compliance gate performs.

Read the quickstartHow it works