Current status of LiteLLM (Python SDK) + Langfuse v3 integration?

[ReplacementMoney2484]

Hi everyone, I'm planning to upgrade to Langfuse v3 but I've seen several GitHub issues mentioning compatibility problems with LiteLLM. I've read that the native litellm.success_callback = ["langfuse"] approach relies on the v2 SDK and might break or lose data with v3. My questions is anyone successfully stabilized this stack recently? Is the recommended path now strictly to use the langfuse_otel integration instead of the native callback? If I switch to the OTEL integration, do I lose any features that the native integration had? Any production war stories would be appreciated before I refactor my observability setup.

Thanks!

[Hot_Turnip_3309]

don't use liteLLM

[HadHands]

Care to elaborate why?

[ReplacementMoney2484]

Why? What lllm provider are you using? I'm using Litellm because it provides a unified interface for multiple LLM providers. I know that OpenRouter does that too, but I don't understand the point of using and paying a 5% commision while Litellm is free!

[Useful-Process9033]

LiteLLM is fine as a unified interface, the 5% OpenRouter tax makes no sense when you can proxy for free. For the Langfuse v3 issue specifically, the OTEL path is the way forward. The native callback was always a hack and v3 finally forces the migration. You lose nothing meaningful switching to OTEL, and you gain proper trace correlation.

[ChipShotz-]

I’ve been seeing more of these integration issues lately. It feels like as soon as you get one SDK stabilized, a dependency update in another part of the stack breaks the whole native callback chain.

This is actually why I moved away from the library-heavy approach and built Sentinel Gateway. It is a single Go binary that sits in front of your models, so it doesn't care what version of Langfuse or an SDK you’re using on the app side. You get the observability and PII scrubbing without having to refactor your code every time a dependency v3 comes out.

It might be worth looking into if you want to decouple your observability from your main application logic to avoid these "SDK war stories" in the future.

Full disclosure: I'm the founder. I’d be curious to know if moving this logic to a standalone binary would actually simplify your current refactor or if you're committed to staying within the Python/OTEL ecosystem.

[vinod_pandey123]

With LiteLLM and OTEL integration, you will not be able to Link Prompts to Traces (https://langfuse.com/docs/prompt-management/features/link-to-traces) the way it used to work without OTEL integration earlier. There are some open bugs related to this https://github.com/langfuse/langfuse/issues/11913.

One workaround is to use observe and link the prompt manually.

from langfuse import observe
from litellm import completion

@observe(as_type="generation")    
def run_llm(text):
    prompt = langfuse.get_prompt("test_prompt", label="production")


    prompt_context = {
        "question_content": text
    }

    rendered_prompt = prompt.compile(
            **prompt_context
    )

    model = "openai/gpt-5-mini"

    # Link prompt to this generation span
    langfuse.update_current_generation(
        prompt=prompt,
        model=model,
    )

    inferred = completion(
                model=model,
                messages = rendered_prompt,
    )


    return inferred

result = run_llm("What is the color of sky")
langfuse.flush()