Having spent considerable time evaluating various API-driven platforms for user experience flow, I've been conducting a thorough analysis of Poe's interface as a middleware layer between the user and multiple LLMs. My conclusion is that its UI represents a significant regression in several key architectural principles when compared to the original ChatGPT web interface. The divergence seems to be in its prioritization of feature aggregation over coherent user-task mapping.
The core issues I've cataloged are primarily related to broken data consistency and poor state management:
* **Inefficient Context Switching:** The horizontal model/talker selection carousel forces a linear, sequential navigation that breaks the rapid, comparative testing workflow common among developers and researchers. The old interface allowed for discrete, mentally isolated sessions. Poe's model, where conversation history is often preserved across model switches, introduces significant cognitive load and risks of prompt/response cross-contamination.
* **Opaque System Prompt Handling:** As an integration specialist, the lack of visibility into the system-level orchestration is a major flaw. With the ChatGPT site, the boundary of the conversation was clear. Poe acts as a middleware proxy, but its UI does not expose how it might be transforming requests or managing context windows for different underlying bots, creating a "black box" integration that is difficult to debug.
* **Information Density & Flow:** The UI consumes a disproportionate amount of screen real estate with persistent promotional elements and the talker selector, compressing the actual dialogue pane. This violates a core tenet of conversational interface design: the primary data payload (the conversation) should be the central, dominant element. The experience feels closer to a cluttered messaging dashboard than a focused tool for structured interaction.
A simple comparison of the user's mental model for a task like "Compare responses from GPT-4 and Claude-3 on the same query":
```
// Expected (ChatGPT-like) Flow
1. Open Tab A -> Navigate to GPT-4 -> Submit Query -> Receive Response A.
2. Open Tab B -> Navigate to Claude-3 -> Submit Same Query -> Receive Response B.
3. Visually compare side-by-side. Clean, isolated contexts.
// Poe's Enforced Flow
1. Submit Query to GPT-4 in Poe -> Receive Response A.
2. Click Claude-3 icon in carousel -> Context of previous query may be inherited or unclear -> Submit again or adjust -> Receive Response B in same, linear thread.
3. Comparison requires scrolling within a single, interleaved timeline. State management risk is high.
```
This design actively hinders systematic, repeatable testing and data gathering—cornerstones of any integration work. The platform seems optimized for casual discovery rather than sustained, professional use. I'm interested if other members focused on data workflow integrity have encountered similar friction or have developed effective mitigation patterns within Poe's constraints.
-- Ivan
Single source of truth is a myth.
You're hitting on something critical with the cross-contamination risk. I've seen this exact problem cause real data leakage in testing scenarios. A team member was comparing GPT-4 and Claude outputs for a security logging prompt; Poe carried over a snippet of the previous model's response as context into the next session, which completely skewed the benchmark.
The opaque system prompt layer is even worse from a cost perspective. Without visibility, you can't audit what underlying API calls are actually being made per interaction, which makes accurate unit costing impossible. It's a FinOps nightmare dressed up as a feature.
FinOps first, hype last