What local-first LLM observability means, and what it doesn't

This page exists to define a term honestly, including the part that cuts against the product describing itself with it. Local-first means your call records, prices and history sit on storage you control, so retention is a disk decision and a vendor changing owner doesn't move your data. That's real and it matters. What it isn't is rare. Checked on 2026-08-03 across twelve LLM-native tools, eleven publish a self-hosting option, several under permissive licences, and LangSmith describes it in almost the same words. Among the general observability platforms, Datadog and Grafana both publish on-prem or self-managed options too. So a buyer choosing on local-first alone has narrowed the field barely at all. The second honest point is that local isn't always possible. Where a backend can't reach the machine holding the ledger, records have to transit something, and the sensible design is a write-only relay the local instance pulls from rather than a vendor cloud that reads. Deployment is set by your requirements. It's a constraint to satisfy rather than an argument to win.

• A vendor comparison came down to self-hosting and every option offered it.
• Your compliance requirement is satisfied by several tools and you still have to choose.
• Your backend can't reach the machine you wanted the ledger on.
• Self-hosting is available on a tier you aren't on.
• You chose on data residency and the question you actually have is about margin.

1. Write down your actual residency requirement, and who set it.
2. Count how many candidate tools satisfy it. If it's most of them, it isn't your deciding criterion.
3. Check which plan tier publishes self-hosting for each candidate.
4. Ask what each candidate can answer that the others can't, and decide on that.

Illustrative example

Local-first turns retention into a storage question, so it's worth knowing the size. Take a modelled 5 million calls a month and a priced call row of roughly 200 bytes covering identifiers, token counts, rate and cost. Compare against New Relic's published 100 GB of free monthly ingest and Langfuse's published retention tiers of 90 days on Core and 3 years on Pro, both read 2026-08-03. The row size and call volume are modelled.

The constraint on a year of history was never the cost of storing it. It was a retention policy, and that's the part local-first genuinely changes. Not privacy, which most of the category also offers.

The useful consequence of local-first isn't secrecy, it's permanence and granularity together. Storage you control means you decide how many months to keep and how finely to keep them, so a question nobody anticipated is still answerable next year from rows already written. That's what makes a per-customer forecast possible at all, since a forecast is made of history and most managed tiers expire it. Culpa prices each call from a versioned price book in exact decimal, keeps the ledger on your own infrastructure by default, and where a backend can't reach that machine it sends through a relay that appends and never reads, with your instance pulling records down. Deployment bends to your requirements. The granularity doesn't.

• LLM Pricing Modifiers: Which Ones Stack and Which Ones Conflict
• LLM Observability Consolidation: Six Tools That Changed Hands
• LLM A/B Test Cost: You Shipped the Winner and Not the Bill
• LLM Cost Anomaly Detection: The Aggregate Has a Noise Floor