# What local-first LLM observability means, and what it doesn't > Eleven of twelve LLM tools publish self-hosting. Local-first is a deployment decision set by your requirements, and it settles less than it sounds. URL: https://getculpa.com/what-is-local-first-llm-observability Last reviewed: 2026-08-03 Rates effective: 2026-07-02 ## Answer Local-first LLM observability means the cost ledger and its history live on infrastructure you control rather than a vendor's. Culpa, a local-first LLM cost, margin, and forecast ledger, runs that way by default. It's worth saying plainly that this is close to table stakes in the category rather than the reason to pick any one tool. ## Why this happens 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. ## What this usually looks like - 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. ## Common mistakes - Treating local-first as a differentiator. Why it hurts: Eleven of twelve LLM-native tools publish self-hosting, so it separates almost nothing. Do instead: Use it as a filter for your compliance requirement, then choose on what the tool can answer. - Assuming self-hosting is available on your plan. Why it hurts: It's frequently an Enterprise add-on behind a sales conversation rather than a setting. Do instead: Check which tier publishes it, and confirm in writing before it becomes a compliance dependency. - Making an absolute claim about what stays inside your network. Why it hurts: Almost no architecture is absolute, and an overclaim is the first thing a security reviewer tests. Do instead: State exactly what stays, what transits, and what any intermediate component can read. - Choosing deployment before choosing the question. Why it hurts: Several tools satisfy the same residency requirement while answering very different questions. Do instead: Decide what you need answered, then filter that set by where it can run. ## Self-check - Write down your actual residency requirement, and who set it. - Count how many candidate tools satisfy it. If it's most of them, it isn't your deciding criterion. - Check which plan tier publishes self-hosting for each candidate. - Ask what each candidate can answer that the others can't, and decide on that. ## A year of call-level history, in bytes (illustrative) 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. 5,000,000 calls x 200 bytes = 1,000,000,000 bytes = about 1 GB a month 12 months of call-level cost history = about 12 GB 12 GB sits inside New Relic's published 100 GB free monthly ingest allowance the same 12 months is unavailable on a published 90-day retention tier at any price 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. ## Cost figures Every figure carries its confidence and its source. No figure on this page is provider-reported. - about 12 GB, modelled size of twelve months of call-level cost history at 5 million calls a month [calculated] Source: 5,000,000 calls x 200 bytes per priced row = about 1 GB a month, so roughly 12 GB for a year. Row size and call volume are modelled. Compared against New Relic's published 100 GB free monthly ingest and Langfuse's published 90-day Core and 3-year Pro retention tiers, both read 2026-08-03, to show the binding constraint is retention policy rather than storage cost. ## FAQ Q: What does local-first mean for an LLM cost tool? A: The ledger and its history live on infrastructure you control rather than a vendor's, so retention is a storage decision and a vendor changing hands doesn't move your data. It describes where the records sit rather than any claim about what a tool can compute. Q: Is local-first rare? A: No, and any page telling you otherwise is worth checking. Across twelve LLM-native tools read on 2026-08-03, eleven publish a self-hosting option, several under permissive licences. Datadog and Grafana publish on-prem or self-managed options too. It's close to table stakes. Q: Does local-first mean my data stays entirely inside my network? A: Rarely, and claiming it usually overstates the architecture. Where a backend can't reach the machine holding the ledger, records have to transit something. The design worth asking about is whether that intermediate can READ what passes through it, or only accept and hold it for your instance to pull. Q: So what should I choose on instead? A: What the tool can answer. Use residency as a filter, since most candidates pass it, then compare on the level attribution reaches and whether anything is forecast below the company total. Those differ far more across this category than deployment does. ## Sources - New Relic pricing: https://newrelic.com/pricing - Langfuse pricing: https://langfuse.com/pricing Run the free Cost Leak Scan: https://app.getculpa.com/scan?source=pseo&slug=what-is-local-first-llm-observability&cluster=problem Machine-readable index of every guide: https://getculpa.com/api/pages Human-readable index of every guide: https://getculpa.com/guides Site overview: https://app.getculpa.com/llms.txt Privacy: Culpa runs on your infrastructure. Your prompts and responses never leave it. Culpa counts calls to run your plan, and it fails open, so if it ever breaks your app keeps running.