Most roundups in this category compare feature checklists. Feature checklists are the least useful thing to compare, because every project in this space will eventually have traces, evaluations, prompt management and a dashboard.
The things that actually decide whether a tool survives contact with your infrastructure are duller and more checkable:
- What the licence really says, including any
ee/directory carved out from the headline licence. - Which features stop working when you self-host without paying.
- How many datastores you are signing up to operate.
- Whether traces require you to change application code, or arrive as a side effect of something you already do.
This post covers six tools against those four questions. Every licence, star count, datastore list and price below was checked against the project's own repository, LICENSE file, docker-compose.yaml or pricing page during August 2026. Where something could not be verified from a primary source, it says so.
Prices and star counts go stale. Re-check before you make a decision on them.
The short version
If you want the fastest start, Phoenix runs on SQLite from a pip install, though its licence is source-available rather than open source. If you want the largest community and the most complete self-hosted build, Opik is the obvious first look. If you want the smallest thing to operate, OpenLIT runs on one datastore and has no paid tier at all. If you are already committed to OpenTelemetry and want to keep your data in a backend you already run, OpenLLMetry is instrumentation rather than a platform, and that is a feature. If you want the most mature product and can live with a licence key for governance features, Langfuse is the default for good reasons. If you want cloud and self-hosted to behave identically, Laminar is the closest. And if the observability problem arrives attached to a gateway, runtime and sandbox problem, that is where Everstack is aimed.
Langfuse
Licence: MIT core, plus a separate Langfuse Enterprise Licence over ee/, web/src/ee/ and worker/src/ee/. This is the single most misread fact in the category. The headline "MIT" is true and the core really is free to self-host without usage limits. But nine features are gated behind a licence key when self-hosting: project-level RBAC, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customisation, organisation creators, the Org Management API and SCIM, and the Instance Management API.
Read that list again with a compliance hat on. Audit logs, data retention policies and server-side data masking are exactly the features a regulated team self-hosts for. If that is your reason for self-hosting, budget for the key.
Worth being precise about what is not gated, because it is more than people assume: enterprise SSO, SSO enforcement, organisation-level RBAC, LLM-as-judge evaluators, human annotation queues, datasets, experiments, the prompt playground and custom dashboards all run on the free build. Langfuse states that core features are available in the OSS build without limits, and there is no seat cap, retention cap or evaluator cap when self-hosting. The paid gate is nine admin, compliance and multi-tenancy features, not a crippled product.
Community and backing. Over 33,900 GitHub stars as of August 2026, and ClickHouse acquired Langfuse in January 2026 with a commitment to keep it open source. Prompt management is genuinely mature and the OpenTelemetry ingestion path is well documented.
It is not a gateway. Langfuse's own documentation states that your requests never pass through Langfuse on the way to a provider. That is a deliberate design choice, not an oversight, and it decides how traces get created: you change an import, wrap calls in observations, or ship OpenTelemetry spans yourself. Every service you want traced is a code change.
Cloud pricing, August 2026: Hobby free with 50,000 units per month and 30 days of data access, Core $29/month, Pro $199/month, Enterprise $2,499/month. Discount programmes exist for startups, research, non-profits and open-source projects.
Pick Langfuse when you want the most mature tracing and evaluation product in the category, your model calls already route through something you control, and either the gated features do not matter to you or the licence is in budget.
Opik
Licence: Apache-2.0, copyright Comet ML. No ee/ directory in the repository. Commercial differentiation happens entirely at the hosted-Comet layer rather than through a licence carve-out, which is a meaningfully more honest structure than the alternative.
By far the largest community here: 21,697 stars as of August 2026, and it was pushed the same day it was checked. Actively developed is an understatement.
Self-hosting is nearly complete. Comet's own docs say the self-hosted build gives you all Opik features including tracing and evaluation, but without user management. So you lose RBAC and multi-user administration, not observability. Compare that to gating audit logs and data masking.
The catch is operational weight. The deployment compose file runs MySQL, Redis, ClickHouse, Zookeeper and MinIO. That is five datastores, versus three for Laminar and one for OpenLIT. If you have a platform team that already operates ClickHouse, this is a shrug. If you are two engineers, it is a real cost every week.
Pricing, August 2026: Open Source free and self-hosted with the full feature set, Free Cloud at $0 with 10 members, 25,000 spans per month and 60 days retention, Pro Cloud at $19/month with 50 members and 100,000 spans per month, and Enterprise with SSO and SOC 2, ISO 27001, HIPAA and GDPR coverage.
One thing worth flagging honestly: Opik advertises first-party OpenTelemetry support and ships an otel-collector-config.yaml, and its docs describe setup. Whether it maps the gen_ai.* semantic conventions specifically or uses a proprietary internal schema was not verifiable from the documentation pages checked. If cross-tool span portability matters to you, confirm that before committing.
Pick Opik when you want the biggest community, a self-hosted build that is not crippled, and you can absorb five datastores.
OpenLIT
Licence: Apache-2.0. No ee/ directory. No paid tier exists today at all.
The lightest thing to operate here: ClickHouse, and that is it. The architecture is SDK to OpenTelemetry Collector to ClickHouse. If you are choosing based on how much you want to run at 3am, this wins outright.
Genuinely OpenTelemetry-native, and not just as a marketing line. The project states it follows and maintains the semantic conventions with the OpenTelemetry community, uses the gen_ai.* namespace, and honours the standard OTEL_EXPORTER_OTLP_ENDPOINT configuration.
The broadest scope of any project here for something with no paywall: LLM observability plus GPU monitoring, guardrails, evaluations, prompt management and a secrets vault, all Apache-2.0.
2,731 stars as of August 2026, pushed the day before it was checked.
The honest weakness: there is no managed cloud. "OpenLIT Cloud" is listed as coming soon with no pricing. If you need hosted infrastructure with an SLA, this project alone has nowhere for you to go, and betting on a "coming soon" is not a procurement strategy.
Pick OpenLIT when you want maximum capability per unit of operational burden, you are happy self-hosting permanently, and no paywall matters more than a support contract.
OpenLLMetry
Licence: Apache-2.0. No enterprise directory. 7,409 stars as of August 2026.
This is not a platform, and treating it as one is the main way people get confused by it. OpenLLMetry is an instrumentation SDK. It produces spans. It does not store them, and it has no dashboard. You still need a backend, whether that is Traceloop's platform or any of the 30 or so external backends it exports to: Datadog, Grafana, Honeycomb and the rest.
For a lot of teams that is precisely the right shape. If you already operate an observability stack, adding a second one for LLM calls is duplicated infrastructure, duplicated on-call and a second place to look during an incident. Instrumenting into the backend you already run is strictly less machinery.
Its strongest claim is standards work, and it is a real one. The project's semantic conventions became the basis for OpenTelemetry's official GenAI semantic convention effort. Its README states that its semantic conventions are now part of OpenTelemetry. Spans you emit today are portable, which is the opposite of lock-in.
Traceloop platform pricing, August 2026: Free Forever at $0 with 50,000 spans per month, 5 seats and 24 hours of retention, then Enterprise at custom pricing with unlimited seats and retention, SOC 2, and an on-premise option. Note there is no self-serve paid tier between those two, which is unusual for the category and worth knowing before you plan a rollout. 24 hours of retention is a demo, not a production tier.
Pick OpenLLMetry when you already have an observability backend and want LLM spans inside it rather than beside it.
Laminar
Licence: Apache-2.0, in LICENSE.md rather than LICENSE, which is why some licence scanners misreport it. No ee/ directory. 3,212 stars as of August 2026, pushed the same day it was checked.
Cloud and self-hosted behave the same. The self-hosting docs state that Signals, chat-with-trace and SQL-with-AI all work self-hosted, provided you configure your own LLM API key. No feature was found gated to cloud only. Among the projects here that sell a cloud product, this is the least compromised self-hosted build.
Three datastores: PostgreSQL for relational data, ClickHouse for analytics, and Quickwit for full-text search. Middleweight. More than OpenLIT, considerably less than Opik.
OpenTelemetry ingestion is real: the backend accepts OTLP over gRPC, HTTP protobuf and HTTP JSON, and the docs state span attributes are fully compatible with the gen_ai semantic conventions.
Pricing, August 2026: Free at $0 with 1GB of data and 7 days retention, Starter at $30/month with 3GB and $2 per additional GB and 30 days, Pro at $150/month with 10GB and $1.50 per additional GB and 6 months, and Enterprise with an on-premise option.
The honest weakness: the smallest community of the group, and a recent rebrand from lmnr.ai to laminar.sh has left redirecting and broken legacy documentation URLs. That churn is a small signal about maturity.
Pick Laminar when you want the option to move between cloud and self-hosted without losing features.
Arize Phoenix
Licence: Elastic License 2.0. Not OSI-approved open source, and this is the most misreported fact in the category.
Phoenix gets listed as Apache-2.0 or MIT in roundups constantly. It has never been either. Its LICENSE file has exactly one commit, from January 2023, and it has always been ELv2.
ELv2 is source-available. You can read it, run it, modify it and self-host it freely. What you cannot do is offer it to third parties as a hosted or managed service, or circumvent its licence-key functionality. For almost everyone reading this, that restriction never binds. If you are building an observability SaaS, it binds absolutely.
The licence structure is otherwise the cleanest here. There is no ee/ directory, no carve-out, no feature behind a key. Tracing, evaluations and experiments are one unrestricted codebase under one licence. Compare that to Langfuse, where the licence is more permissive but nine features are gated: Phoenix asks less of you at runtime and more of you at the business-model level. Those are genuinely different trades and which one matters depends entirely on what you are building.
The lightest start of anything here. Default storage is SQLite in the working directory, with PostgreSQL as an option. pip install gets you a full trace UI with no external datastore at all. Self-hosting covers Docker, Kubernetes with Helm, and one-click deploys to Railway, Render, GCP, Azure and AWS.
A convention caveat worth knowing: Phoenix is built on OpenTelemetry but its native vocabulary is OpenInference, Arize's own semantic convention, not the OTel GenAI conventions. It does read gen_ai.* spans and converts them, preferring gen_ai.provider.name and falling back to gen_ai.system, which as of 15.10.0 makes it one of the better citizens on the current spec. But if you are standardising on gen_ai.* across several tools, know that you are working against Phoenix's grain rather than with it.
Around 11,200 GitHub stars as of August 2026.
Pricing is for the separate commercial product, Arize AX, not for Phoenix: Free at $0 with 25,000 trace spans per month, 1 GB ingestion and 15 days retention; Pro at $50 per month with 50,000 spans, 10 GB and 30 days; Enterprise custom, SaaS or self-hosted. Phoenix itself stays free and unlimited as the local-first product.
Pick Phoenix when you want the fastest path from nothing to a working trace UI, you want evals in the same tool, and reselling it as a service is not your business model.
Everstack
Everstack belongs on this list with a caveat, because it is not primarily an observability tool and pretending otherwise would be the exact dishonesty this post is arguing against.
It is an AI gateway, an agent runtime, isolated sandboxes, evaluations and OpenTelemetry-native observability on one self-hosted control plane, Apache-2.0, with no enterprise directory carved out of the repository.
The one structural difference worth knowing about is where traces come from. Every other tool on this list observes an application that calls a model somewhere else, so a trace is the product of instrumentation you add. Everstack routes the request, so the trace already exists before any SDK is involved. Point an existing application at an OpenAI-compatible endpoint and you have traces, latency, token counts and per-provider cost without touching application code. SDK spans are available when you want more detail than the request boundary gives you.
That is genuinely useful when you have services in four languages, or a vendor integration you cannot instrument, or a coding agent whose internals you do not control. It is much less interesting if you have one Python service and adding a decorator is a five minute job.
Do not pick Everstack for observability alone. If tracing is your only problem, the focused tools above are simpler to adopt, have larger communities, and have had longer to polish their trace UIs. The case for a unified control plane needs at least two or three of these problems at once, plus a deployment constraint that rules out someone else's cloud.
How to actually choose
Ask the four questions in order, and stop as soon as one of them rules out an option.
Does the licence gate what you self-host for? There are three distinct patterns here and they fail in different ways. Langfuse is permissively licensed with an ee/ carve-out, so the licence is friendly but nine features need a key. Phoenix is source-available under ELv2 with no carve-out at all, so nothing is gated at runtime but you may not resell it as a service. Opik, OpenLIT, Laminar and OpenLLMetry are straightforwardly Apache-2.0. Work out which of those three constraints actually touches you, because they are not interchangeable.
How many datastores can you actually operate? One (OpenLIT), three (Laminar), or five (Opik) are very different commitments at 3am. Nobody regrets choosing the lighter stack until they need something it does not do.
Do you already have an observability backend? If yes, look hard at OpenLLMetry before you stand up a second platform beside the one you already pay for and already know.
Where do traces come from? Instrumentation is a code change in every service you want covered. Gateway-level traces cost nothing per service but only see what crosses the request boundary. Neither is better in the abstract, and the right answer depends on how many services you have and whether you control all of them.
The projects here are all Apache-2.0 or MIT at the core and all actively developed. This is a good category to be choosing in. Just choose on the four things that are hard to change later, not on the feature grid.
Everstack's observability is documented here, and there is a side-by-side comparison with Langfuse that goes deeper on the licence and gateway differences.