Sluis vs LiteLLM: AI gateway comparison

The short version

Both put one OpenAI-compatible endpoint in front of many model providers, with virtual keys, budgets and logging. The difference is where the work lands. For the other gateways on the shortlist, see AI gateways for EU organisations compared.

LiteLLM gives you a broad, MIT-licensed toolkit and leaves the operating model to you: you host it, run its database, wire up PII detection and decide how regions are pinned. Sluis ships the compliance layer as the product: every call is inspected, routed by an EU-first residency policy, sealed in a hash-chained audit log and metered, in a managed service hosted in the EU or on your own servers with Sluis Edge.

Sluis is not open source. The code is all rights reserved, and the self-hosted Edge binary needs an enterprise licence. If source access is a hard requirement, that settles it for LiteLLM.

At a glance

Licence and hosting

LiteLLM's repository is MIT licensed apart from the enterprise/ directory. Its enterprise licence adds SSO beyond five users, SCIM, audit logs with retention, key and team scoped guardrails and a support channel; 24/7 support SLAs cost extra. The documented way to run it is on your own infrastructure, and the vendor states that a self-hosted instance sends no telemetry or data to its servers.

Sluis runs the same gateway two ways. The managed service is hosted in the EU. Edge is one binary on your servers, managed from the same console: prompts do not transit Sluis's cloud, although model-provider egress still follows your configuration. Edge is enterprise-only, with a flat annual licence per gateway.

Data protection and guardrails

LiteLLM's PII masking uses Microsoft Presidio. You deploy the analyzer and anonymizer containers, choose entity types and set each to MASK or BLOCK. A restore flag puts the original values back into the response. Several built-in moderation integrations, such as secret hiding and prompt-injection vendors, need an enterprise licence.

Sluis's Inspect step is part of the gateway. It runs 60 built-in detectors (email, IBAN, credit card, API keys and a national-ID pack that checksum-validates twelve EU countries), plus opt-in name recognition with two model tiers. Policy decides whether a value is blocked, masked, logged or replaced by a stable token such as «EMAIL_1» that is restored in the response. Prompt-injection scanning and a per-workload scope guard are optional. Detection is not a guarantee that every sensitive value is found, and using Sluis does not by itself establish GDPR compliance. See data protection.

Routing and residency

LiteLLM's router is stronger on traffic engineering: weighted and latency-based strategies, cost-based routing, retries, cooldowns and fallbacks across deployments. Keeping traffic in the EU means choosing EU deployments and maintaining that configuration yourself.

Sluis routes by policy. The default is EU-only, jurisdictions such as the US or China are added explicitly, and an EU-owned-only restriction is a separate switch because an EU region does not imply an EU-owned provider. Responses disclose the chosen route and model. Managed aliases such as sluis/auto resolve inside your policy. Within one provider, Sluis spreads calls across several keys by weight, with retries and circuit breaking, but it has no weighted or latency-based balancing across models or deployments. See residency and models.

Budgets, limits and access

Both enforce spend before the call. LiteLLM budgets attach to keys, users, teams and team members, and they require a database: without one, budget checks are skipped. Sluis attaches limits to a workload, which owns requests per minute, tokens per minute, a model allow-list and a total, daily or monthly budget shared by its keys. An organisation cap sits above all workloads. Past the rate limit a call returns 429, past the budget 402, and the request never reaches a provider. If the counters are unreachable the check fails closed.

MCP tools pass through the same gate in Sluis: grants are per key and deny-by-default, and each call is inspected, routed, sealed and metered. See budgets and limits.

Audit and logging

LiteLLM logs requests and responses and exports to observability tools. Its audit logs, which record admin actions and key changes, are listed as an enterprise feature.

Sluis writes every call to a hash-chained ledger that you can verify offline with audit verify-chain, with optional encrypted request and response bodies under a retention period. The same ledger is the billing record.

Performance

Both vendors publish numbers, on different harnesses, so they do not compare directly. LiteLLM states 8 ms P95 at 1,000 RPS. Sluis measured the gate internally: about +1 ms at the median against a mock upstream, and a 9% lower request rate at synthetic saturation. These figures are relative, taken on developer hardware, and measured internally. Details are on the performance page.

Pricing

LiteLLM is free to run, so your cost is infrastructure, a Postgres database and engineering time; the enterprise licence is priced on quote. Sluis has no platform subscription or seat fee and no free tier. Self-service is prepaid, from a €25 credit purchase, with payment-method surcharges. Managed model usage costs the provider's list price plus 10%. With your own keys, the Sluis fee is €0.50 per 1M input and output tokens, with provider charges billed separately. See pricing.

When LiteLLM is the better choice

• You need open source you can read, fork and audit.
• You want one Python SDK and a proxy with the widest provider and model coverage, including day-zero models.
• You need fine-grained traffic engineering: latency-based or cost-based routing, weighted pools and custom fallbacks.
• Your team already runs Postgres and Kubernetes and prefers to own the whole stack.
• EU residency and PII controls are not requirements, or you would rather build them.

When Sluis is the better choice

• You must show where each request was allowed to go, with EU-first routing as the default.
• You want reversible pseudonymization and an offline-verifiable audit chain without assembling them.
• You want a managed EU-hosted service, with a self-hosted option for the same policy.
• Employees and agents, such as Claude Code, should share one policy and one audit trail.

FAQ

Can I move from LiteLLM to Sluis by changing the base URL?

For most OpenAI-compatible clients, yes. Point the client at Sluis and use a new key. Model ids on the OpenAI surface are provider-prefixed, such as mistral/mistral-large-latest, and bare ids return 400. Sluis has a narrower provider catalog, so confirm that your providers are covered.

Can LiteLLM keep data in the EU?

Yes, if you deploy it in the EU, route to EU model deployments and keep the configuration accurate. We found no policy setting for provider jurisdiction or ownership in its documentation, so that discipline is yours.

Is Sluis open source?

No. The source is proprietary and all rights are reserved. You can inspect behaviour through the published API documentation, the audit chain and the console, but not the code.

Does the Sluis gate add latency?

In an internal benchmark on developer hardware, about +1 ms at the median, and 9% lower throughput when the test saturates the gateway. Against a live model the difference sits inside provider variance. Treat these as relative numbers and measure your own workload.

Can I run both?

Possibly. Sluis accepts custom OpenAI-compatible providers and the LiteLLM proxy exposes an OpenAI-compatible API. Test the pairing; the custom-provider fee of €0.50 per 1M tokens applies.

Sources

• LiteLLM on GitHub
• LiteLLM licence file
• LiteLLM Enterprise documentation
• LiteLLM Enterprise page
• LiteLLM routing and load balancing
• LiteLLM budgets and rate limits
• LiteLLM PII masking with Presidio
• LiteLLM data privacy and security
• Sluis API documentation
• Sluis performance