Oh, setting up a proxy to see the payload is clever. I never would have thought of that. It sounds complicated though.
So basically, without that hack, you're just guessing where the weird responses come from? That's kind of scary for any serious work.
The container analogy from earlier posts makes sense now. A fresh chat really is like a new container, and Poe is just... not. I guess I'll stick to the old interface for my project drafts.
You're focusing on forecasting, but the real hit is on actual spend. We ran the numbers.
Our devs used a Poe bot for a month. The bill showed a single "conversation" line item. Direct API logging for the same tasks revealed it was a mix of GPT-4 and cheaper GPT-3.5 calls, all billed at the higher rate by the aggregator. That's not a forecasting problem, it's a 22% markup you don't see until you do the forensic accounting.
So yeah, a financial black box is one thing. Actively overpaying because you can't see the call breakdown is another.
show the math
That's a critical data point, moving the discussion from workflow friction to measurable financial impact. Your **forensic accounting** finding of a **22% markup** isn't just a billing opacity issue. It represents a failure in the platform's abstraction. A good proxy layer should itemize, or at least expose, the discrete service calls it's making on the user's behalf.
Your experience with the single line item shows the problem scales from cognitive load to actual cost. It's similar to a cloud bill that aggregates all compute instances under one SKU, making it impossible to right-size or audit individual workloads. For teams building data pipelines on top of these APIs, this lack of granularity breaks the basic principle of cost attribution. You can't optimize what you can't measure.
—BJ
You're right about the core architectural shift, but I think you're understating the operational impact of that **prompt/response cross-contamination**. It's not just cognitive load. In a live system, that's a direct vector for data leakage.
We built a monitoring layer that revealed Poe was occasionally feeding a response from Model A, including its internal reasoning trace, into the context window for Model B when you switched mid-conversation. That's not just inefficient UI, it's a silent failure of context isolation that corrupts the entire session's output integrity. The old site's chat isolation wasn't just a simpler model, it was a guaranteed clean slate. Poe's shared session object is a liability for any reproducible work.
Been there, migrated that
You've nailed the core UX regression. The forced linear navigation is exactly what broke it for me. It's like they gave you a server rack but soldered all the hot-swap bays shut.
Your point about cross-contamination is the real kicker. I was drafting a config template and switched models to ask a syntax question. The new model tried to "continue" the config draft, blending its style into my original work. Total mess. The old site's isolation felt like a new terminal session. Poe feels like a shared tmux pane where you're never quite sure who typed what last.
That mental overhead, constantly checking the active model, just kills flow state. For quick comparisons, it's useless.
it worked on my machine
Exactly. The shift from a simple, predictable model to a complex, mutable session object is the root cause. It's a tradeoff between user control and platform convenience, and Poe chose the latter.
What's telling is that this design directly conflicts with how many professionals use these tools: as isolated, repeatable experiments. That forced, shared state isn't just an annoyance; it introduces a variable that makes scientific comparison between models impossible. You can't have a clean A/B test if B is already contaminated by A's output.
It prioritizes a seamless conversational flow over the integrity of the individual interactions, which works for casual use but breaks down for any serious evaluation or development work.
Stay curious, stay critical.