Langfuse vs a local request ledger: do you need a hosted observability stack

Short answer: if you are building an LLM product that other people use, you want something like Langfuse. If you are a developer whose spend comes from coding agents running on your own laptop, a local request ledger covers the questions you actually ask, and a hosted observability stack mostly adds infrastructure you then have to maintain.

The two things get compared because both produce a list of LLM calls. They are aimed at different questions. Langfuse is built around a trace: a user hit your app, a chain ran, six model calls and two retrievals happened, one of them returned garbage, and you want to see the nesting so you can find where it went wrong. A ledger is built around a line item: this call, this model, this many tokens, this many dollars, this process. If your problem is quality of a shipped product, the trace wins. If your problem is why last Tuesday cost four times what Monday cost, the line item wins and the trace is scaffolding you did not need.

What Langfuse is genuinely good at

Langfuse is an open-source LLM engineering platform. The parts people use it for: nested tracing across a chain or agent, prompt management with versioning so a prompt change is a tracked artifact rather than a git diff nobody reviewed, datasets and evaluation runs so you can compare two versions of a pipeline on the same inputs, and a UI where a non-engineer can look at an output and mark it good or bad. It has SDKs for Python and JavaScript, integrations with the common orchestration frameworks, OpenTelemetry-based ingestion, a managed cloud offering, and a self-hosted deployment path for teams that need the data to stay in their own infrastructure. Licensing is split in the usual open-core way, with the core available under a permissive license and some platform features reserved for commercial tiers. Check their pricing page before assuming which side a given feature falls on, since that boundary moves.

None of that is fluff. Human annotation queues and dataset-based regression testing are hard to build yourself and genuinely change how a team ships prompt changes. If two or more people need to look at the same trace and argue about it, you want a shared server, and Langfuse is a reasonable one.

Where an instrumentation platform stops helping a solo developer

The friction is at the point of capture. Langfuse sees what you instrument. That means code you control: your app, your chain, your SDK call sites. Claude Code, Codex and Cursor are not code you control. They are closed CLIs making their own calls with their own retry logic, their own context assembly, their own subagent fan-out. There is no decorator to add. You can sometimes point them at a base URL and get some visibility that way, but at that point you have built a proxy, and you should be honest that the proxy is doing the work rather than the tracing SDK.

The second issue is that a hosted platform is a network hop for data you may not want leaving the machine. Coding agent requests contain your source code. Every prompt is a file, a diff, a stack trace, an internal API shape. Shipping all of it to a third-party ingest endpoint so you can see a bar chart of daily spend is a bad trade for one person. Self-hosting fixes the privacy problem and replaces it with a Postgres instance, an object store, a worker and a container you now own.

Third, the metric of interest is different. Tracing platforms compute cost as a derived attribute of a span. That is fine, but it is downstream of a price table that has to be kept current, and it does not know about the things that actually move a coding agent bill: cache hits, cache writes, whether the same prompt got sent twice by two parallel subagents, whether a request went to a local model instead of the cloud.

The questions a local ledger answers that a trace does not

• Which process made this call. Not which chain, which OS process. When three agent sessions and an editor extension are all live, attribution by process is the only way to know which one is expensive.
• What did this cost in real money after cache reads, not what the token count implies at list price.
• How many of today's calls were byte-identical to an earlier call, and what would you have saved by never sending them.
• How many concurrent calls were duplicates of each other, fired by parallel subagents within the same second.
• What is the ratio of cheap-model work to expensive-model work, and did that ratio drift after a config change.
• Am I on a subscription tier priced above the usage I can prove I have.

Those are ledger questions. They need a complete record of every call made from the machine, including the ones no SDK of yours wrapped, and they need the record stored where you can query it without a login.

How I ended up building the ledger side of this

I built Probe0 because I could not answer the process attribution question for my own machine. Probe0 is a local proxy for macOS, currently in private beta. You run it, install a certificate once, and every coding agent CLI on the machine routes through it. Claude Code, Codex and Cursor, with no per-tool configuration. There is no Probe0 server. Requests do not leave your machine except to go to the model provider they were already going to.

Recording keeps the full ledger: model, tokens, real cost, latency, and which process made each call. The other modules sit on the same path and each reports what it saved, so a change is judged rather than assumed. Exact Cache is local disk and never touches the network. Semantic Cache uses a local vector index with a strict similarity floor, and it refuses to match anything carrying tool calls, because a near-miss on a tool call corrupts a run in a way that costs more than it saves. Request Coalescing collapses simultaneous identical calls into one upstream request. Model Tiering tries a cheap model first. Local Routing sends work to a model already running in Ollama or LM Studio and retries weak answers on the cloud. Spend Guard sets a hard cap per run or per day, warns, then pauses. Because the ledger knows actual usage, it can also tell you when your subscription tier is above what you use.

Limits, plainly. macOS only. Private beta. Not a team gateway, so no shared server, no multi-user roles, no org-level dashboards. Provider coverage is what coding agents call, not a catalog of a hundred providers. Account sign-in is Google or GitHub only and the account system is new. And Probe0 has nothing resembling datasets, human annotation or eval runs. If you need those, you need Langfuse or something like it.

Picking one, or both

Use Langfuse when the LLM calls you care about are inside software you wrote and ship to other people, when more than one person needs to look at the same trace, and when prompt changes need version history and regression runs. Self-host it if the data is sensitive and you are willing to operate the services.

Use a local ledger when the LLM calls you care about come from tools you did not write, when the cost is yours personally, and when the thing you want on screen is a sorted list of what your machine spent today and which process spent it. Running both is coherent: Langfuse for the product you ship, a local proxy for the agents that help you build it. They are watching different traffic.

Instrumentation tells you what your code did. A proxy tells you what your machine did. When the expensive callers are closed-source CLIs, only one of those is available to you.