Lilypad

Lilypad sits in an unusual spot: it is the observability half of the Mirascope ecosystem rather than a standalone company product, and that shapes both its strengths and its limits. On the strength side, the design is disciplined. Everything runs through OpenTelemetry, so the question of "which backend?" never gets answered by Lilypad—it gets answered by you. Traces from an @ops.trace-decorated function can land in Langfuse, Jaeger, Zipkin, Grafana Tempo, or Datadog by swapping the TracerProvider configuration, and for development you can attach a ConsoleSpanExporter and read spans straight from stdout, as the quick-start shows. The decorator surface is small and composable: @ops.trace for function-level tracing, ops.session() to group related traces, ops.span() for explicit spans where you want finer control, @ops.version to tag function versions, and instrumentation that captures LLM calls automatically. Context propagation handles the distributed case where a request crosses services and you still want one coherent trace. Because it's MIT-licensed and installs from PyPI as mirascope[otel] (the docs show v2.4.0), there is no seat count, no usage meter, and no vendor that can change its pricing terms on you. The weaknesses are the mirror image. There is no hosted UI, no prompt management layer, and no experiment tracking in what's documented here—if you need to compare two prompts head-to-head or let a non-engineer browse traces, this library alone won't do it. You also pay for the vendor-neutrality in operational cost: someone on your team has to run and maintain the OTel collector and whatever backend you choose, handle retention and sampling, and secure access. For a solo developer or a small team without DevOps capacity, that overhead can outweigh the freedom. The documentation itself is a docs-site module page rather than a marketing site—the /pricing, /changelog, /release-notes, and /docs paths all return "The page you are looking for does not exist,"—so the observable surface for evaluating it is the Ops overview plus the guides under /docs/ops. Integration coverage with specific backends is documented in the Configuration guide rather than on a separate marketplace page, which we did not reach this run. Where it fits: Python codebases that already emit OTel, teams that have standardized on a backend and don't want a second observability silo for LLM traffic, and Mirascope users who want tracing to come along with the framework. Where it doesn't: non-Python stacks, teams shopping for a finished observability dashboard, and anyone expecting Lilypad to host, store, or visualize their traces. Treat it as a well-built instrumentation library with a deliberate scope boundary, not as a platform—and judge it on whether that boundary matches where your stack already lives.