Langfuse 3.188.0 Puts Rate Limits in Front of the In-App Agent Before It Becomes an Expensive Button

Langfuse 3.188.0 adds something every product with an embedded agent eventually needs and usually adds late: rate limits before the expensive work starts.

That ordering is the story. Langfuse’s in-app agent now checks org-level hourly and daily buckets before database writes, MCP key creation, or AI model calls. If the bucket is exhausted, the request gets a normal 429 with Retry-After and X-RateLimit-* headers. No secret little model call first. No “we’ll write the session and then decide whether it counts.” The guardrail sits in front of the side effects.

That sounds obvious. It is not. A surprising number of agent products bolt limits onto the outside of an API while the expensive or sensitive work lives deeper in the service path. By the time the limiter notices, the platform may already have created state, minted a credential, queued a task, or called a model. For normal SaaS endpoints, that is sloppy. For agents embedded inside observability tooling, it is how a helpful button becomes a cost and abuse surface.

Langfuse v3.188.0, published June 17, is not only an agent-rate-limit release. It also adds web-callout rate limits, dependency bumps, blob-storage credential cleanup, better blob-storage error surfacing, and a guarded ClickHouse query rewrite for observations v2. But the in-app agent limit is the publishable hook because it says the quiet part clearly: once observability products add assistants that can inspect traces, create MCP keys, write session state, and call models, those assistants need the same boring controls as any other production subsystem.

The expensive button gets rails

PR #14175 adds two new in-app-agent rate-limit resources: in-app-agent-run-hourly and in-app-agent-run-daily. The plan-tiered limits are explicit. Hobby gets 100/hour and 500/day. Core, Pro, Team, and Enterprise get 200/hour and 1000/day. OSS and self-hosted plans are excluded from these cloud plan limits.

The exclusion matters. If you self-host Langfuse, do not read this release as “rate limiting handled.” Read it as “Langfuse Cloud added product-layer buckets; self-hosted operators still need outer guardrails.” That may mean proxy limits, model-provider spend caps, workload-level budgets, MCP key lifecycle rules, and monitoring for runaway assistant loops. Self-hosted observability tools are often deployed close to sensitive traces, prompts, datasets, evals, annotations, and internal debugging workflows. An unbounded in-app assistant there deserves more scrutiny than a chat widget on a marketing site.

The current cloud limit is org-level rather than per-user. The PR notes a TODO to add per-user capping once RateLimitService supports non-org keys. That is a reasonable first step, but it creates a governance choice for customers. Org buckets are good blast-radius controls: one organization cannot create unlimited agent work. They are less good at fairness: one noisy user can consume shared capacity for everyone. Mature deployments will probably want both: an org-level ceiling for spend and abuse, plus per-user or per-seat ceilings for fairness and incident containment.

The useful takeaway is not that 200/hour is the correct universal number. It is that agent usage needs to be a visible product resource. If an observability assistant can summarize traces, inspect sessions, generate follow-up actions, or create MCP credentials, the product should be able to answer: who used it, how often, what limits applied, what was denied, and whether denial happened before side effects.

Web callouts are where observation becomes action

The same release adds rate limits to web callouts in PR #14280: 30 req/min per user and 120 req/min per endpoint, plus process-local in-flight guards of 25 per process and 5 per endpoint. Redis failures fail closed for five seconds.

That last sentence is doing real work. Failing closed may annoy users during infrastructure trouble, but allowing unlimited outbound callouts because the limiter is unhealthy is a worse default. Observability systems sit at an awkward boundary. They mostly watch. Then features like web callouts, MCP actions, in-app agents, evaluator operations, and automation hooks make them do things. Once the tool can do things, rate limiting stops being “anti-abuse” boilerplate and becomes operational safety.

Outbound callouts are especially sensitive because they turn internal events into external traffic. A bad loop can hammer a downstream endpoint. A misconfigured automation can create noisy incident hooks. A model-assisted feature can repeatedly call the same URL while trying to recover from an error. The per-user, per-endpoint, and in-flight limits are not glamorous, but they map to actual failure modes: one user loop, one endpoint loop, and one process drowning in pending work.

Teams should copy the pattern even if they do not use Langfuse. Any agentic product surface that can call out, create credentials, trigger workflows, write durable state, or spend model tokens needs explicit ceilings. Not in a prompt. Not in a policy document. In the runtime path before work begins.

The ClickHouse flag is production humility

The observations v2 query rewrite in PR #14043 is the release’s other strong engineering signal. Langfuse is testing a path that moves from a CTE plus JOIN late-materialization split to a JOIN-free outer SELECT against events_full, gated by an (span_id, trace_id, start_time, project_id) IN (SELECT ...) subquery. The feature is behind LANGFUSE_OBSERVATIONS_V2_SUBQUERY_REWRITE, defaulting to false.

That is the right posture. Agent observability queries can be huge, nested, and weird. A better ClickHouse plan can materially improve latency and cost. It can also behave differently on production-shaped data than it does in a reviewer’s local test. A kill switch is not fear; it is respect for query planners, data skew, and the fact that observability products often debug incidents while causing their own database load.

The blob-storage fixes are similarly practical. PR #14314 trims credentials before encryption to prevent SignatureDoesNotMatch. PR #14281 walks SDK error cause chains so validation surfaces root causes like SignatureDoesNotMatch or NoSuchBucket instead of generic wrapper messages. That may not sound agent-specific, but agents produce and inspect artifacts: exports, media, logs, trace payloads, datasets, screenshots, and evaluation outputs. Storage errors need to be diagnosable by operators, not hidden behind polite abstractions.

What operators should do

If you use Langfuse Cloud, watch the new agent 429 rates as a product signal, not just an error metric. Are users hitting the hourly bucket during incident review? Is one user starving an org-level quota? Do rate-limit denials correlate with expensive traces, eval runs, or embedded-agent workflows? The first version of a limit teaches you whether the product’s usage model is honest.

If you self-host, add your own ceilings around the surfaces Langfuse Cloud now protects: model calls, in-app agent runs if exposed, web callouts, MCP key creation, and downstream automation hooks. If you test the observations rewrite, use production-shaped data, compare result parity, watch CPU and latency, and keep the flag reversible until boring.

Langfuse 3.188.0 is not a flashy release. Good. The agent stack needs fewer demos and more controls that fire before damage. The assistant inside an operations product should be useful, but it should also be bounded, attributable, and boring under stress. Rate limits first. Side effects second. Kill switches always.

Sources: Langfuse v3.188.0 release, PR #14175, PR #14280, PR #14043, PR #14314