Multiple instances of Langfuse client in PythonSDK

[mturzynski-xelerit]

Describe your question

Hi,

In my app, I configure a Langfuse instance with tracing_enabled=false. This allows me to use prompt management features. But I also want users to have the ability to share feedback. I can't collect traces for all queries due to privacy reasons. Whenever they share feedback, I add a trace manually through the SDK and score that trace. I don't have many details stored, mostly input and output, but it's fine.

The problem is that after I migrated from SDK v2 to SDK v3, this no longer seems possible. I have one main instance of the Langfuse client that I use in the app (for the prompt management feature), and I have another one with tracing_enabled=true to create a trace whenever a user decides to share feedback. The tracing_enabled setting seems to be ignored for the client that I use to write traces. My best guess is that both instances use the same OTEL settings under the hood. How do I isolate them from each other?

Best Regards,
Mateusz

Langfuse Cloud or Self-Hosted?

Self-Hosted

If Self-Hosted

No response

If Langfuse Cloud

No response

SDK and integration versions

Python v3

Pre-Submission Checklist

• I have checked for existing issues/discussions and consulted Langfuse AI.

[inkeep-ai-assistant[bot]]

You've identified the core issue correctly. In Python SDK v3, the tracing_enabled parameter is managed at the global OpenTelemetry TracerProvider level, which means you cannot have multiple Langfuse clients with different tracing settings in the same process(1).

From the available sources, there is a confirmed limitation: "Sampling is being managed on the global OTEL TracerProvider, and thus only one sampling setting is possible per process"(1). This same constraint applies to the tracing_enabled setting.

Your use case is not directly supported in SDK v3. The sources confirm that "you can't configure multiple clients with different sample rates for the same public key in the same process"(1), and this extends to tracing enablement as well.

Potential workarounds:

1. Manual trace creation approach: Instead of relying on tracing_enabled=True for your feedback client, you could manually create traces using the SDK methods when users share feedback. With your main client set to tracing_enabled=False, you can still explicitly create traces using methods like start_observation() or start_as_current_observation()(2)(3).

2. Environment variable control: You could set LANGFUSE_TRACING_ENABLED=False (note: it must be capitalized "False", not lowercase "false")(4) globally, then manually create traces only when needed for feedback.

3. Process separation: The only robust way to have truly isolated tracing settings is to separate these concerns into different processes(1).

The manual trace creation approach would likely work best for your scenario - keep tracing disabled globally, use the client for prompt management, and explicitly create traces only when users provide feedback.

(2)(3)(1)(4)

📚 Sources:

1. Multiple clients with different settings in v3 SDK
2. Instrumentation
3. Advanced features
4. bug: LANGFUSE_TRACING_ENABLED need to be "False" to disable tracing but docs say "false" instead

---

Have another question? Just tag @inkeep.

[mturzynski-xelerit]

I'm afraid I can't create traces through start_observation() or start_as_current_observation() as they are not sent to Langfuse server when tracing_enabled is set to false.

[jannikmaierhoefer]

Hi @mturzynski-xelerit, we have docs on setting up isolated tracer provider here: https://langfuse.com/docs/observability/sdk/advanced-features#isolated-tracerprovider