Session View Redesign Feedback Thread

[bezbac]

See changelog post

We've redesigned the session view to bring messages across traces into one continuous conversation, with a sidebar for navigating messages and tool calls.

How is it working for you? We'd love to hear what's useful, what's confusing, and what's missing. If messages aren't displayed as expected, please share an example or screenshot with sensitive information removed.

FAQ

Why do I see duplicate content in the messages?

The conversational timeline is built from GENERATION observations in the session's traces. If content appears more than once, check the input and output attached to those generations. The data may not be structured as expected.

See our best practices.

Why do I see cryptic data in the messages?

The timeline uses the input and output of GENERATION observations to display messages. If you're seeing raw or unexpected data, check what's attached to those generations.

Use messages with explicit roles, such as system, user, assistant, and tool, in each generation's input and output. See our best practices.

Why do some messages show up as "JSON-only message"?

This can happen when a generation's input or output contains JSON that the timeline can't interpret as messages. Check the data attached to the generation and use messages with explicit roles, such as system, user, assistant, and tool.

See our best practices.

I preferred the old view. Can I get it back?

Yes! You can switch back to the old session view by turning off the feature under User Menu → Feature Preview. You can also turn it off for your entire organization in the Feature Preview organization settings. See the screenshots below.

We'd love to hear what's missing or isn't working for you in the redesigned view. Leave a comment below or reach out through any of our usual channels.

User-wide:

Org-wide:

[IqmalRosli]

Hi team,

This is an example of one of the traces that you see on [this session]:
removed

There's so much clutter on this view. The navigation panel on the left side is nice to have but overall there's too much going on in this view. Please change it back, or at least give us the option to choose a preferred view while you're still working on optimising this new Session View. Thank you

[marliessophie]

Hi there! Thanks for flagging. We have some pages on ingestion best practices that I will leave here. Outside of this, I believe we are in internal conversations to debug your concrete use case already.

[reslleygabriel]

I really like the redesign! It’s a huge improvement. Conversations are much easier to follow, and I really appreciate how clearly I can see which tools were used. Keep up the great work!

[dmladenov-dev]

Agreed, I was just starting to use Langfuse and I hated the old UI so much which is why I was looking for alternatives. The redesign fixed basically everything that bothered me. Now a happy user keep up the amazing work!

[hamza-zafar-319]

I like the new design, but it doesn't show the attached images. I attach the images to the parent trace' output by uploading them to Langfuse.

[bezbac]

Thanks for the feedback! I'll see that we improve the experience around this 👍🏻

[marliessophie]

Hey, to follow up on this; it looks like this image is being generated by your model? If so, why is it not part of a generations output?

We have some guidance on (multi-modal) ingestion here: https://langfuse.com/docs/observability/best-practices#multi-modal-traces

[hamza-zafar-319]

Hey! The this image is not technically generated by the model. The model has access to images the user has already uploaded, it calls a tool view_image to get a signed URL to fetch it. If the model passes a show_to_customer flag, it is sent the to user as well via a async JSON output. So the completed "output" is not generated by any one observation.

however, I can maybe attach it to tool call observation itself. But I rather like having the complete final output on the parent span.

[bezbac]

Attaching the image to the tool observation’s output should make it appear in the session view, and that seems like a natural fit since the tool also retrieves it. You can of course also keep it on the parent span so the complete final output stays together when viewing the traces in the single-trace UI or in annotation queues. If you run into any additional issues, just let me know :)

[hamza-zafar-319]

I think the full parent span output should be displayed in the conversational view as well. It doesn't make sense to have data in there and not show it

If we add filters back users will have the agency to configure the session view as they want it.

[GroCodeJack]

Utter garbage -- seriously among the worst changes I've ever seen on a saas tool. My entire team relied on clicking on a saved view to QA chats, and the saved views have completely vanished. No way to return to the old session view UI either as a cherry on top. I'm in genuine disbelief at how bad this change is. Half of the sessions literally have no way to seeing actual user/assistant message content no matter how hard I look.

[GroCodeJack]

Hoping this helps

Langfuse Telemetry and Chat Replay.md

[marliessophie]

Thanks, we'll check it out and get back to you!

[marliessophie]

Hey, I read through this. Am I correct in understanding that the ability to show only root span IO for each turn in the session view would solve your problem? Also could you please confirm that your root IO has only the first user question and final assistant response and nothing else?

Also could you kindly share why the current session view does not produce a readable conversation? From your explanation I would have expected it would produce a proper conversation, but incl tool calls ie not limited to just the first user question and last assistant response.

[philcicle]

Fully in the same boat as this user. I was at a loss until I realized I could opt out.
It's really unclear what the search is searching through; is it just the I/O? Can I search for trace names?

Feels like the polarisation of this UI change stems from how you set up and use Langfuse traces. We tend to group and nest our traces as we have several agents and processes within one pass. That's one of the benefits of using OTEL, IMHO, but this view seems to favour just conversational LLM traces.

Now, is the original view better? Yes... is it perfect? Heck no! This is a real devil you know is better than the devil you don't.

[bezbac]

Hi @philcicle, thanks for sharing your feedback and for keeping it civil and constructive.

We tend to group and nest our traces as we have several agents and processes within one pass.

You’re correctly observed that this is a workflow the new view doesn’t support well yet. We’re discussing how to better accommodate grouped and nested traces and will share an update here soon. In the meantime, you can switch back to the previous view by turning off the new view in the feature preview settings. Sorry for the friction this caused.

It's really unclear what the search is searching through; is it just the I/O? Can I search for trace names?

Search currently covers the content visible at the top level of the right-hand panel, including I/O, trace names, and tool names. It doesn’t yet include tool I/O, which is collapsed by default. Please let us know if there’s anything else you’d want to see included in the search.

[ilayaraja97]

The change came in just as I was trying to understand what the earlier UX. Really welcome change.

[aaronmaxcarver]

first impression...big improvement. thanks y'all

[GinkREAL]

Our org-default saved view filters the session to Type any of GENERATION, SPAN, AGENT, TOOL (hiding embeddings/retrievers), so the pre-4.54 (specifically 4.53) timeline rendered each agent observation's input/output as clean chat bubbles — just the user's question and the agent's answer. It also let us expand steps in between the user's query and the final answer to see the tool calls. It was absolutely beautiful.

Since 4.54 tho, bubbles come from the generations instead, so we see the raw LLM input including context our app injects (a <current_context> block with app location/document IDs, similar to how opening a vscode claude code session in the standalone claude code shows ugly <user_opened_ide> blocks). Turning off the Feature Preview doesn't get us back to that either — it drops the bubbles altogether and goes back to the old uglier trace UI.

Would be great if we could get 4.53's exact behavior where it has the pretty bubbles but still respects the saved views in the org.

SDK: custom SDK exporting OTEL to langfuse's otel endpoint.

[GinkREAL]

4.53 Display

Utilized Filters

4.54 Display

[marliessophie]

It looks like 4.53 was using the experimental feature preview, is that correct?

The implementation of 4.53 was unfortunately experimental, and not something we can just "bring back".

I'd be curious to learn from your feedback though; could you kindly share your email address or reach out to support@langfuse.com and ask to be connected to me (marlies, langfuse team)? Then we can set up a call and run through this live. Thanks!

[GinkREAL]

hi @marliessophie , i emailed langfuse support but doesn't seem like I had a reply.

To summarize, my issues is similar to this guy: https://github.com/orgs/langfuse/discussions/18687#discussioncomment-18926322. Hopefully thats enough to explain the problem

[guilhermegkurtz]

I personally hated the new UI. It looks like a major step back. The lack of nesting and proper naming for each trace call make it unusable for daily review tasks, it add so much friction and made me lose way to much time.

Being capable to open a conversation and easily/quickly find the exact trace i want to review and go on details to understand the behavior on that moment, is the most important thing for me on a daily basis, and the way the new UI was implemented don't allow it.

[bezbac]

Thanks for the candid feedback. I hear that the missing nesting and clear trace names make it harder to find the exact call you need and understand what happened. You can still switch back to the old view and use the span filtering you relied on, as described here.

To help us understand what would work better: how well do our individual trace pages support your review workflow? Would a similar layout (with Tree, Timeline, and Graph views in a sidebar) help if it covered all traces / observations in a session?

[guilhermegkurtz]

Hey, i saw the switch on another comment and did it right away, helped a lot.

In fact, i kind of use both. I work with CS agentes and i check dozens of conversations a day. In several cases i need to move and cross check things on different message traces/calls, and the speed i can do it is a key factor for it to be viable.

I believe the new UI could kind of work, if some components of the old one could suvive, like nesting calls by message prosessing instead of having it full open on the side bar + the call name, like we have today.

The old UI give me a way to do all of that with way less friction. I agree it might not be the best UI, but it helps get the job done fast, while the new one add friction and slow things down.

Also, it can be a skill issue on my side for somethings, as i just got used to do it in one way and never tried other approaches.

[bezbac]

Thanks for the feedback

[morganednl]

Hello 👋

Thanks for the redesigned session view! Here is some feedback from our setup, where it unfortunately made things harder for us.

Setup

• Python SDK v4.14 for our own spans
• LiteLLM 1.80 with its langfuse_otel callback, which creates the generations
• App: an educational chatbot. Each student message is one trace, and a whole conversation is one session.

Structure of one turn

fer-turn (SPAN, root)        input: student message, output: avatar reply
├── filtering/filter-step (SPAN)
│   └── filtering/filter (GENERATION)     → JSON (moderation verdict)
├── evaluator/evaluate-step (SPAN)
│   └── evaluator/evaluate (GENERATION)   → JSON (answer evaluation)
└── avatar/...-step (SPAN)
    └── avatar/... (GENERATION)           → the reply the student sees

Each generation's input is a single user message holding a compiled Langfuse prompt, with the conversation embedded in it as text. LiteLLM logs the messages exactly as they are sent to the model, so we can't reshape them without changing what the model sees.

Before

In the previous session view, we could filter on spans. We kept only the fer-turn root span, so we got exactly the view we needed: the student's message and the avatar's reply, turn after turn.

Now

That filtering is no longer possible. The new view builds the conversation from generations only, and root span I/O is used only when a trace has no generation. So for each turn we see three threads: the filter, the evaluator and the reply. Each one shows the full compiled prompt as a "user" message, and two of them end with a JSON output. We can no longer follow the conversation.

What would help

• Bring back a way to choose which observations the view is built from, for example a filter by observation name or type, as before.
• Or use root I/O when it's already chat-shaped (a list of messages with user and assistant roles).
• Or an attribute or metadata flag to mark the observation that carries the turn.

We considered making the root observation a GENERATION, so that its thread would be the shallowest and hide the others. But that relies on undocumented behavior and inflates our generation counts, so we'd rather not.

[bezbac]

Hi 👋 Thanks for the detailed feedback and for explaining your setup so clearly. We’re sorry the redesigned session view has made it harder to follow your student conversations.

You can still switch back to the old view and continue using the span filtering that worked for you, as described here.

Please don’t change the root observation to a GENERATION as a workaround. Your root span represents the turn, and you shouldn’t have to change that modeling or inflate your generation counts to get a useful conversation view.

We’ve noted your feedback and will look into allowing observation filtering or providing an alternative view closer to the previous experience. We don’t have a timeline yet, but in the meantime you can continue using the old view and I'll make sure we don't remove it before we have a satisfactory alternative. Thanks again for the concrete examples, they help us understand where the redesign falls short.

[dahnny012]

Not a big fan of removing the evaluation scores. Is there a way to incorporate that in the UX (or maybe its hidden somewhere either way my team used that feature)

[bezbac]

Hi @dahnny012, thanks for flagging this and it’s helpful to know your team used the evaluation scores. They aren’t currently surfaced in the redesigned UI because the relationship between observations and messages can be confusing.

Could you share a quick sketch of where you’d expect to see them? That would help me understand how they could fit into the Langfuse UI and your workflow.

[julian998-dot]

Hi,

Some feedback on the new Sessions view: since the redesign, it’s become very hard to find things there. In practice, we can’t locate what we need anymore.

The previous view wasn’t perfect, as some copy and UX details could have been clearer, but it worked. It was much easier to navigate and find specific sessions.

Could we look at restoring some of the old view’s structure, or adding better search and filters to the new one?

Thanks!

[bezbac]

Thanks for sharing this feedback. I’m sorry the redesign has made it harder to find what's relevant within the sessions. We’re considering bringing back more detailed filtering mechanisms, and your feedback is helpful as we evaluate those changes.

I'd also recommend reviewing your instrumentation, particularly if content appears more than once in the conversational timeline. Could you share which frameworks and SDKs you’re using, including their versions? This would help us better understand your instrumentation setup. The timeline is built from GENERATION observations in the session’s traces, so please check the inputs and outputs attached to those generations—the data may not be structured as expected. Our best practices provide more guidance.

[hbenyamina]

Hi,
This is a feedback on the redesigned session view. I think it's unusable because our agent is a bit complex and we cannot easily navigate this new view.

[BKDDFS]

Feedback from the perspective of non-technical reviewers who read sessions to judge answer quality.

Setup (generic): one trace per user turn, one session per conversation. The root span's input is the user message and its output is the final answer. Each turn makes several LLM calls whose prompts carry a lot of internal context. End-user feedback arrives as a trace score with an optional comment.

What reviewers want per turn: the user message, the final answer, one key intermediate step, and the feedback score with its comment.

What the Session Timeline shows instead: the messages of the individual LLM calls, system prompts included. Root I/O appears only as a fallback when a trace has no generation messages. In Timeline mode there is no "Filter observations", no saved views and no "Show system prompt" toggle, although the Compact view without Timeline still has them. Scores are not shown. Same experience as @GinkREAL and @morganednl describe above.

What would solve it:

1. A view option to render each turn from the root observation's input/output instead of generation messages. transcriptByTraceId already has fallbackToRootIO, so exposing it as a choice might be a small step.
2. Saved views, or at least an org-level default view, in Timeline mode.
3. Trace scores next to the turn they belong to. To answer @bezbac's question to @dahnny012: a small score badge under the assistant message of that turn, with the score comment on hover or expand.
4. Optionally, pinning observations by name so a chosen intermediate step shows as a collapsed row between the message and the answer.

Since per-trace scores and their comments are only visible in the old view, our workaround for now is turning off "Redesigned Session View" as the org default, which means opting out of the redesign entirely instead of configuring it.

[bezbac]

Thanks for the detailed feedback and concrete suggestions. Understanding your reviewer workflow is helpful. I’ll consider making fallbackToRootIO configurable, thanks for the idea!

Displaying scores alongside messages needs some care: scores can be attached to individual observations or an entire trace, and a trace can contain several LLM calls and assistant messages. Placing a score under one message could imply that it evaluates that specific response. I’ll explore how we can make that relationship clear.

The session view is intended to show individual LLM calls, with system prompts and other context presented as structured, collapsible elements. We designed it around progressive disclosure so reviewers can focus on the conversation and expand details when needed. If unexpectedly detailed content appears directly in the message bubbles, I’d recommend reviewing your instrumentation. Our best practices provide more guidance.

Could you share which frameworks and SDKs you’re using, including their versions? This would help us better understand your instrumentation setup.

I’ll update this thread when we release functionality that addresses these points. In the meantime, keeping the redesigned session view disabled is a reasonable workaround for your review workflow.

[michaelschoenbaechler]

We run into the same problem. Each turn of our assistant (sent over OTel) is one trace. The root span is an assistant-turn span, and its input and output are already clean:

• input: {"message": "I am looking for a pediatrician near zurich", "language": "en", ...}
• output: {"message": "Here are pediatricians near Zurich ...", "sessionTitle": "...", "symptoms": []}

Inside the trace, a few small side calls (title generation, symptom classification) run alongside the main agent. They are shallower in the tree than the agent’s generations. So the session view shows only their system prompts and JSON outputs, and the actual conversation (user question → agent answer) doesn’t appear at all.

What would solve it for us, in order of preference:

• A per-project or per-view setting to render turns from root input/output (the existing fallbackToRootIO path, made selectable), ideally with a field selector such as $.message for input and output.
• Otherwise, filtering which generations count toward the transcript, by observation name or type.

As a stopgap, we tested adding a synthetic GENERATION under the root span with chat-shaped input/output. We’d rather not keep it, since it adds a fake generation to every trace.

[bezbac]

Thanks for the feedback, @michaelschoenbaechler. We're working on improving the experience for traces of this shape. I'll let you know once we have some updates here.

What would solve it for us, in order of preference:

• A per-project or per-view setting to render turns from root input/output (the existing fallbackToRootIO path, made selectable), ideally with a field selector such as $.message for input and output.
• Otherwise, filtering which generations count toward the transcript, by observation name or type.

We've been discussing similar ideas internally, and we'll most likely offer something in this direction.

As a stopgap, we tested adding a synthetic GENERATION under the root span with chat-shaped input/output. We’d rather not keep it, since it adds a fake generation to every trace.

I agree. We don't want to push users to ingest a fake generation for every trace if the same data is already present in Langfuse.

[cperriard]

Hi!
Four feedback points:

• Scrolling in the trace/observation list is broken: when scrolling to find an observation it jumps right back to the previously selected one (default is the first) which makes it impossible to inspect observations further down.
• The numbering of the traces/observations is not transparent/intuitive: We have nested LLM calls and/or additional input/output cleaning steps which get collapsed into a long list. Each item gets the same title (trace name?) which makes it hard to navigate.
• I'd love to be able to collapse top level traces in one session: one session has parallel traces that I want to be able to identify and investigate one by one.
• Is flattening the observations and showing generation spans only the right call when agents/sub-agents are not necessarily working linearly?

[bml1g12]

The side panel has no expandable horizontal width so I cannot read the trace ids, and the search bar does not let me search by title so currently the redesign is harder for me to use

[bezbac]

Thanks for the feedback! I’ll make the sidebar resizable and improve the search functionality. I’ll update you here once both changes are available.

[bezbac]

Hi @bml1g12, just wanted to let you know that these two suggestions have been implemented in #19095 and #19027. The changes are already available on cloud or via v4.67.0

[bml1g12]

thanks!

[trinya]

If i'm in a session it got harder to read individual traces belonging to it, idk where to click to just read what's inside.

[bezbac]

Hi @trinya, could you share a little more about your particular setup? What kind of agents are you tracking in Langfuse, which SDKs are you using, and how does the new view change the information displayed compared to the old one?

[juliano09]

It looks nicer, but for the love of God, please bring back the previous view; I simply cannot analyze my multi-agent process—it’s become unusable.

[bezbac]

Hi @juliano09, thanks for the feedback. We understand that the new view is less than ideal, especially for multi-agent processes, and I'm working on improving the experience. For now, feel free to switch back to the old view (see “I preferred the old view. Can I get it back?” in the FAQ above).

[epzee]

Another reviewer use case, from a mental-health chatbot. Each member message is one trace and each conversation is one session. Clinical reviewers read conversations alongside automated evaluator notes, which we post as session comments through POST /api/public/comments

1. A comments panel that stays open. The comment drawer is modal: it dims the conversation and blocks scrolling, so reviewers close and reopen it for every turn while reading evaluator notes. Could it have a docked, non-modal mode? We carry a small patch for this on v3 (modal={false}, no overlay) and would be happy to send a PR
2. Pinned metadata per turn. Pinned JSON paths currently show in the session header, from the first visible observation. We record per-turn context on the trace (update_current_trace(metadata=…)). Showing a pinned path under each turn, read from trace metadata, would let reviewers see it where it applies
3. +1 to rendering turns from root input/output (@michaelschoenbaechler's request above). Each of our turns makes several internal LLM calls, so the transcript shows those instead of the member's message and the reply. +1 to scores next to their turn as well

[philcicle]

Would love to see the push for the session view matched with session-based analytics and alerts.

Having everything pined back to the observations, even though sessions are two orders higher, makes it really hard to reason over.

[wiley-sayvant]

I'm personally not a fan of this change:

• I find the color scheme hard to see, the color palette seems to consist of a sea of light grey and dark grey text, which in dark mode background its not particularly easy to sort out. Compared to the tracing view its pretty dreary.

• The thread (thread seems to be a new concept you introduced?) selector column to the side is nice for jumping around, but the entries dont seem to carry much useful information. Knowing that there was a user message and an agent message isn't particularly interesting.

• Metadata and other information about the traces under the session (or I guess everything is an observation now?) is also under represented, it would be nice to see at a glance things like the model, cost etc. per thread

• The session page itself could be a lot more useful if aggregates about the session were derived, like for example cost, response time, ttfb etc for the specific session

• Surfacing errors prominently would also be nice

[wiley-sayvant]

Also I think for future rollout it would be nice to have a beta group that could test out these changes, opt-in, before hand, instead of making it opt-out. Or at least have a prominent 'Show me the old view' buton

[johnstonshawn991-art]

Love this. Show me more

[rgpass]

Almost unusable. I had to urgently make pages in our admin panel to be able to read conversations at all.

[AleksaBajat]

Much better!

[nimarb]

Hi all,
thank you so much for all of this feedback!

We have now released a new iteration of the sessions view, where you can create and pin different filter sets of observations/traces you would like to see within a session.

Do this by clicking the "+" sign next to the "Messages" tab on the top right of a single session. You can pin the views then for yourself or everyone in your project.
Please feel free to test this out and let us know what you think!

Thank you!