April 23, 2026Introducing Litefuse: Agent Observability and Evaluation Platform, without the Operational Tax
A lightweight, agent-native fork of Langfuse. Two processes instead of six, ~80% less storage, built-in support for popular open-source agents, and full compatibility with the Langfuse SDK.
Today I’m launching Litefuse — an open-source platform for agent observability and evaluation, built as a fork of Langfuse.
The short pitch: the same developer experience you get from Langfuse, with a meaningfully simpler operational story, much cheaper storage, and agent-native support baked in. It is compatible with the Langfuse SDK, so if you’re already instrumented, you can point your existing code at a Litefuse endpoint and keep going.
This post is about why Litefuse exists and what it’s trying to be — short term and long term.
Why fork?
Langfuse is an excellent project, and a lot of what makes Litefuse work sits on top of its foundations. I’m grateful for everything the Langfuse team has built in the open.
I forked because I wanted a different tradeoff curve for self-hosted deployments, and because I think there is a distinctive opportunity in treating agent workloads as a first-class citizen — not as a special case of LLM observability. Langfuse’s goals are broader than that, and that’s fine. Litefuse is narrower on purpose.
The fork gives me the freedom to take that narrower bet and make different decisions about architecture, storage, and out-of-the-box integrations than a project with a wider remit would make.
What “lite” actually means
“Lite” in Litefuse shows up in two concrete places.
1. Fewer moving parts
A production Langfuse deployment runs six processes: the Langfuse web and worker containers, plus Redis, MinIO, Postgres, and ClickHouse. That’s a defensible architecture for a full-featured LLM engineering platform — but it is also a lot of machinery to stand up, upgrade, and debug when something goes wrong at 2 a.m.
Litefuse collapses that to two processes: one Litefuse process, plus Apache Doris as the backing store. Doris handles both the analytical queries that ClickHouse used to serve and the metadata that Postgres used to hold, and it does so as a single cluster that scales horizontally.
The result: fewer services to learn, fewer failure modes to plan for, fewer things in the way of a team that just wants to see their agent’s traces without hiring an SRE.
2. Much less storage
Apache Doris’s columnar storage and compression turn out to be a very good match for trace and observation data, which is repetitive, high-cardinality, and overwhelmingly read-analytical. Litefuse stores the same trace volume in ~80% less space than the classical Langfuse deployment model.
At small scale this is nice. At the scale where agent traces start to dominate your observability bill — and they will, because each agent run generates dozens of observations — this is the difference between observability being an obvious yes and being a line item someone has to defend every quarter.
Agent-native out of the box
The second half of the Litefuse bet is that popular open-source agents deserve built-in support, not SDK wiring that the user has to assemble themselves.
Litefuse ships with first-class integrations for agents like Claude Code, OpenClaw, Hermes Agent, and more. That means: the moment you connect one of these agents to Litefuse, you get structured traces, tool-call visibility, agent-graph views, and cost tracking — without writing instrumentation code or figuring out the right OTEL exporter.
This is the space I think is underserved today. Most observability platforms treat an agent as “an LLM call that happens to loop.” Litefuse treats it as what it actually is: a stateful, branching, tool-using system whose correctness and cost depend on decisions made at every step. The integrations are designed around that shape.
Compatible with the Langfuse SDK
Litefuse preserves wire compatibility with the Langfuse SDK. If you already instrument your code with langfuse, langfuse-python, or langfuse-js, you can change the endpoint and keep going — no re-instrumentation, no migration bridge, no rewrite.
This is a deliberate, long-term commitment. The Langfuse ecosystem — SDKs, integrations, the body of documentation and example code — is too valuable to force users to leave behind. Litefuse is a different operational and product bet, but it stands on the shoulders of that ecosystem and intends to keep doing so.
Practically, this means:
- Existing Langfuse users can evaluate Litefuse without touching their application code.
- New integrations that land in the Langfuse SDK flow through to Litefuse users.
- Framework integrations built for Langfuse — LangChain, LlamaIndex, OpenAI Agents, and the rest — work on Litefuse too.
Where Litefuse is headed
Short term, the four points above — lighter ops, lighter storage, built-in agent integrations, SDK compatibility — are the reason to try Litefuse today.
Longer term, I am betting on a more specific direction: agent observability and evaluation-driven development as independent, first-class problems. Not “observability with some agent features,” but a platform designed from the ground up around the questions agent teams actually need to answer — which reasoning paths lead to which outcomes, which subagents drift over time, how to turn every bad production trace into a regression test automatically, how to tell whether this week’s model upgrade made your agent better or worse across a real workload.
Two companion posts go deeper on the ideas Litefuse is being built around:
If any of that resonates, the fastest way to get a feel for Litefuse is:
I would love to hear from you — what works, what doesn’t, what you wish it did. This is day one.