Different jobs. One routes traffic, the other explains it.
LiteLLM is a gateway and Spanlens is an observability platform, so treating this as a head-to-head is slightly wrong from the start. LiteLLM normalises over a hundred providers, handles retries and fallbacks, and hands logging to a backend you choose. Spanlens is a backend of that kind, with cost attribution, agent traces, evaluation, and anomaly detection built in and no config file to maintain. Plenty of teams end up running both.
| Feature | Spanlens | LiteLLM |
|---|---|---|
| Primary job | Observability | Routing |
| Licence | MIT | Custom |
| Self-host | Yes | Yes |
| GitHub stars (2026-07-30) | 10 | 55,038 |
| Providers normalised behind one interface | 10 | 100+ |
| Usable with no config file | Yes | No |
| One-line baseURL swap | Yes | Yes |
| Model registry to maintain | No | Yes |
| OpenTelemetry (OTLP) ingest | Yes | Partial |
| Built-in request log UI | Yes | Partial |
| Full request and response bodies stored | Yes | Partial |
| Per-request USD cost | Yes | Yes |
| Dated model variant pricing | Yes | Partial |
| Cost by prompt version | Yes | No |
| Cost by end user and session | Yes | Partial |
| Requires an external backend to retain logs | No | Yes |
| Agent trace waterfall | Yes | No |
| Critical path marked | Yes | No |
| LLM-as-judge evaluation | Yes | No |
| Prompt versioning and A/B with significance test | Yes | No |
| Statistical anomaly detection | Yes | No |
| PII and prompt-injection scanning | Yes | No |
| Provider fallback and retries | No | Yes |
| Load balancing across deployments | No | Yes |
| Per-key spend caps | Partial | Yes |
| Response caching | Yes | Yes |
Updated 2026-07-30. Scroll for the grouped view with notes below.
LiteLLM records what happened by handing it to something else: you register a callback and pick a backend. Spanlens is that backend, with the request log, cost views, traces, evaluation, and anomaly detection as the product itself rather than as configuration you assemble.
LiteLLM wants a config file describing your models, keys, and routing before it is useful, and that file keeps growing. Spanlens needs a base URL and a key, and the provider is inferred from the path, so there is no model registry to maintain.
Providers return dated ids such as gpt-4o-mini-2024-07-18, and a price table that only knows gpt-4o-mini will quietly produce the wrong number. Spanlens matches exact ids first and falls back to the longest boundary-aware prefix, then rolls the result up by prompt version and by end user.
Spanlens shows a multi-step agent run as a span tree and marks the longest dependency chain, so you know which of five tool calls is actually costing you the wall-clock time. A gateway sees each call separately and cannot reconstruct the shape.
LLM-as-judge scoring, human annotation with judge-to-human correlation, and traffic-split prompt A/B with a Welch t-test all sit next to the requests they describe. With LiteLLM these are separate tools you wire together.
Spanlens writes request logs to ClickHouse and, if that write fails, queues the row in Postgres and replays it when ClickHouse recovers. Silent log loss during an outage is the failure mode that makes observability untrustworthy.
Last updated 2026-07-30 · Spot something inaccurate? Let us know.
We don't think every team should pick us. Here's where LiteLLM legitimately wins.
LiteLLM has 55,038 GitHub stars against Spanlens at 10, verified 30 July 2026, and it ships continuously. If community size and breadth of exercised integrations are your main criteria, this is not a close call.
LiteLLM normalises well over a hundred providers behind one OpenAI-shaped interface. Spanlens proxies ten. If you are calling something unusual, check the Spanlens list before assuming it is covered.
Retries, provider failover, load balancing, rate limits, and per-key spend caps are core LiteLLM features with years behind them. Spanlens deliberately does not try to be your traffic manager.
A common shape is LiteLLM for routing with Spanlens as the observability backend behind it. If you already run LiteLLM, you probably want to add Spanlens rather than replace anything.
LiteLLM records what happened by handing it to something else: you register a callback and pick a backend. Spanlens is that backend, with the request log, cost views, traces, evaluation, and anomaly detection as the product itself rather than as configuration you assemble.
LiteLLM wants a config file describing your models, keys, and routing before it is useful, and that file keeps growing. Spanlens needs a base URL and a key, and the provider is inferred from the path, so there is no model registry to maintain.
Providers return dated ids such as gpt-4o-mini-2024-07-18, and a price table that only knows gpt-4o-mini will quietly produce the wrong number. Spanlens matches exact ids first and falls back to the longest boundary-aware prefix, then rolls the result up by prompt version and by end user.
Spanlens shows a multi-step agent run as a span tree and marks the longest dependency chain, so you know which of five tool calls is actually costing you the wall-clock time. A gateway sees each call separately and cannot reconstruct the shape.
LLM-as-judge scoring, human annotation with judge-to-human correlation, and traffic-split prompt A/B with a Welch t-test all sit next to the requests they describe. With LiteLLM these are separate tools you wire together.
Spanlens writes request logs to ClickHouse and, if that write fails, queues the row in Postgres and replays it when ClickHouse recovers. Silent log loss during an outage is the failure mode that makes observability untrustworthy.
LiteLLM has 55,038 GitHub stars against Spanlens at 10, verified 30 July 2026, and it ships continuously. If community size and breadth of exercised integrations are your main criteria, this is not a close call.
LiteLLM normalises well over a hundred providers behind one OpenAI-shaped interface. Spanlens proxies ten. If you are calling something unusual, check the Spanlens list before assuming it is covered.
Retries, provider failover, load balancing, rate limits, and per-key spend caps are core LiteLLM features with years behind them. Spanlens deliberately does not try to be your traffic manager.
A common shape is LiteLLM for routing with Spanlens as the observability backend behind it. If you already run LiteLLM, you probably want to add Spanlens rather than replace anything.
If your problem is routing across many providers with fallbacks, use LiteLLM. If your problem is knowing what each request cost and why a trace was slow, add Spanlens. The two are not mutually exclusive.
Free tier · No credit card · Self-host with Docker