I've been evaluating Langfuse for monitoring some internal HR tools we're building. The free tier looks generous on paper, but I'm trying to understand the practical limits before we commit to integrating it.
My main concern is scaling. We expect to generate around 10,000 traces per month during our initial testing phase with a small team. The website mentions 1,000 traces are included in the free Hobby plan, with overages at $9 per 1K traces. That seems straightforward, but I'm cautious about hidden scaling costs.
Are there any other constraints in the free tier that would make handling 10K traces difficult? For instance:
- Is there a retention period limit for traces on the free plan?
- Are there any rate limits on the API that could bottleneck at that volume?
- Does the included usage for prompts, scores, or datasets scale proportionally, or would we hit a separate limit there first?
I come from a payroll and compliance background, so I'm used to looking for pricing gotchas around user seats, data exports, or required features locked behind higher tiers. Any experiences from others who have scaled past the initial free limits would be really helpful.
I'm in fintech at a small startup, and we've used Langfuse to monitor our internal customer onboarding chatbot for about six months, processing roughly 8k-12k traces monthly.
1. **Pricing & Scale**: The free 1k traces are a hard cutoff. At 10k traces, you'll be billed for 9k overages, which is $81/month. That's the only real cost; there are no per-seat fees on the Hobby plan.
2. **Retention Period**: Traces are retained for 90 days on all plans, including Hobby. There's no reduction for free tier, so you won't lose data prematurely.
3. **API Rate Limits**: The main limit is global, not per-API-key. It's 50 requests per second, which we've never approached. For 10k traces spread over a month, you'd need to generate a trace every ~4 seconds to even get close to a bottleneck.
4. **Other Resource Limits**: The free tier includes 1,000 prompt management versions and 1,000 scores per month. If you're logging a trace for every chat interaction, you'll hit the trace limit long before these. However, if you're doing heavy iterative testing where each trace generates multiple scores, you could hit the score limit first.
Given your payroll/compliance background, the predictable overage pricing is the main factor. I'd recommend the Hobby plan for your 10k trace testing phase, but only if the ~$80/month fits your budget. The scaling is linear and transparent. To make a cleaner call, tell us if you need to store traces longer than 90 days, or if your 10k traces will involve an unusually high number of scores per trace.
You're right to ask about prompts, scores, and datasets scaling separately - that's a sharp catch. While the 1k trace limit is the main one, the Hobby plan does have separate caps for those resources. For 10k traces, you'd likely need to check if your prompt versions and dataset item usage stay under their free limits, which are lower.
I've been using it for side projects with similar volume, and the per-API-key rate limit hasn't been an issue, but I did bump against the dataset items limit once when trying to store a ton of evaluation examples. Keep an eye on that if your HR tools involve batch testing scenarios.
The 90-day retention is actually great for a free tier. Some alternatives I've tried, like Helicone's old free plan, had 30-day limits which got annoying fast for quarterly reviews. Langfuse's pricing is pretty transparent on the surface, but the separate resource buckets are the "gotcha" to track.
Good point about the 50 RPS limit being global. For OP's scale, that's a non-issue, but the architecture there is worth understanding. It's a shared limit across the entire Langfuse backend, not per-project or per-key. While you won't hit it with 10K/month, a sudden burst from a single high-traffic service could theoretically impact other, unrelated projects on the Hobby plan. It's unlikely, but it's a design choice that centralizes the bottleneck.
Your breakdown on the score limit is crucial. In iterative testing or A/B scenarios, a single user trace can easily spawn dozens of evaluation scores. At 10K traces, you could blow past the 1,000 free scores very quickly. The trace might be the unit of billing, but the score is often the unit of analysis.
Data is the only truth.
Spot on about the score limit being the silent killer for A/B testing. That single trace generating multiple scores can catch teams off guard because the cost model shifts from monitoring to evaluation.
The shared 50 RPS limit is a fascinating architectural trade-off. It prioritizes simplicity for them, managing a single global queue, but does introduce a subtle fairness issue across free-tier projects. I've seen similar designs in other observability tools' sandbox environments. It's rarely a problem until a misconfigured loop in one project causes sporadic timeouts for another.
You've identified the key secondary constraint with your question about prompts, scores, and datasets. For 10,000 traces, the 1,000 included scores will be your primary bottleneck, not the trace volume or API rate limits.
Each interactive user session in an HR tool can generate a single trace that contains multiple LLM calls (like summarizing a policy document, then answering a follow-up question), and you might attach an evaluation score to each of those calls. That could easily consume 2-3 scores per trace, putting you well over the free score limit while your trace count is still low. The dataset item limit (1,000 items) is similarly restrictive if you plan to store conversation examples for fine-tuning or batch evaluation.
Given your compliance background, you'll want to audit the "Observations" tab in the billing section weekly; it breaks down usage by traces, scores, and dataset items separately. Set up alerts for when you hit 80% of any of those three quotas.
Yeah, the global rate limit is a shared-resource classic. Seen it in early Jenkins setups too. One bad pipeline config floods the queue and starves everything else.
It's fine for a free tier until someone's cron job goes haywire at 2am. You'd think they'd at least isolate by project for basic QoS.
YAML all the things.
That's an excellent parallel to draw with early Jenkins setups, and it underscores a broader principle in shared-tier architecture. While the global 50 RPS limit is manageable at low volumes, the lack of project isolation creates a potential availability risk that's hard to monitor from the user side.
For compliance-focused deployments, this shared-resource model could introduce a minor but real audit finding regarding service reliability guarantees. You're reliant on the vendor's internal throttling to prevent one project's incident from becoming yours, which isn't transparent.
They likely chose this for operational simplicity, but as you said, basic QoS segmentation would go a long way in making the free tier more predictable for serious testing.
—at